Здесь я специально говорил не совсем уж про все на свете коммутаторы. Но для тех, которые я привел в пример, проверял на сайте производителя. Идея была донести, что МТУ может быть разный, для разных устройств и его стоит подбирать в зависимости от того какой свич и узлы у вас есть чтобы значение совпадало на всем пути следования фрейма. И думаю мне эту мысль удалось донести.
Да, нетап проводил тест для нагрузок баз данных и виртуализации, т.е. мелких блоков с случайной записью и порядка 70/30 R/W. Не уверен что могу их здесь выложить, так как такие документы нужно адекватно интерпретировать.
Но для нетапа к примеру nfs на 10 гб должен давать одинаковые показатели латенси и iops по сравнению с fc8. Если это не так, то точно есть проблема с сетью.
Могу сказать относительно латенси, что можно получить 0.5 мс (для этого нужен будет флеш) отклик для чтения и записи на езернет.
Скорость отклика от приложения до хранилища через езернет сеть как правило практически такая же как и в Fibre Channel, иногда такая-же, в случае использования соответствующих датацентровых свитчей. Разница как правило на столько не велика, что ею можно пренебречь. Но это касается нетапа и свичей DCB, о других решениях не могу ничего сказать.
NetApp не использует Trim, так как это фича для жестких дисков «юзерского» уровня. Выполнение очистки от мусора у нетапа выполняется на уровне прошивки диска, а не на уровне ОС.
Как долго после написания статьи вы пользовались функцией Smart Будильника в гаджете?
На сколько качественной и удовлетворяющей является функция Smart Будильника для вас?
Спасибо.
Когда говорят про «запись повсюду» в WAFL имеют ввиду, что метаданные (иноды) файловой системы хранятся в буквальном смысле повсюду на дисках, а не в выделенном специальном месте, как это часто устроено в традиционных Файловых Системах (ФС).
В виду того, что запись всегда происходит в новое место, функция снапшотов (и соответственно клонов) очень легко реализуется в такой ФС. Когда новые данные перезаписываются при помощи «записи в новое место», старые данные по сути не затираются, при этом указатели инодов переставляются в «новое место» указывая на перезаписанные данные, таким образом происходит высвобождение нового места. Другими словами эта особенность работы WAFL (перезапись при помощи записи в новое место) является базой для работы нетаповских снапшотов по соответствующему принципу «Redirect On Write». В связи с чем на любом доступном количестве снапшотов (максимум 255 на том для DataOntap) или клонов, нет необходимости выделять специальный резерв пространства под снапшоты, а также нет падения производительности. Такая возможность WAFL должна быть очень востребована тестерами.
Т.е. выделение пространства под LUN о котором я говорю в статье не связанна с особенностью работы нетаповских снапшотов, а скорее с устаревшим принципом работы SAN, который не так давно, к счастью был доработан новыми, весьма не плохими костылями (SCSI SBC-3). Другими словами WAFL не знает о содержимом LUN'а и какие блоки там актуальные, а какие уже не нужны, а новые «костыли» позволяют ей это узнать, не захватывая мусор в снапшот и высвобождая пространство по мере удаления дынных на LUN'е. В то время как NAS имеет намного менее выраженные «проблемы поедания пространства» в сочетании со снапшотами, так как ФС WAFL взаимодействуя с хостом по SMB или NFS прекрасно знает о том, какие блоки данных более не нужны, этот функционал был заложен так сказать «By Design».
Как известно слова WAFL и Snapshot являются торговыми марками патентованными технологиями нетапа. В связи с чем слово снапшот не применяется в официальных названиях других продуктов и применяется в «не официальной терминологии». Но оно уже как-бы адаптировалось, и теперь оно как правило применяется в более «широком смысле».
Относительно снапшотов хочется отметить то, что «традиционные снапшоты» устроены по принципу COW (Copy On Write), где название отражает принцип работы: так как традиционные исполнения ФС «перезаписывают» изменённые данные на «прежнее» место, такому спаншоту необходимо выделять специальное место в ФС. Следующей особенностью работы COW является то, что для перезаписи новых данных (изменения данных) в захваченном снапшоте, такие данные для сохранности содержимого снапшота, должны быть сначала скопированные в выделенное для этого место, собственно от сюда и название Copy On Write. Таким образом самым главным недостатком такой технологии является падение производительности с ростом числа снапшотов, генерируя всё больше и больше накладных операций копирования при (пере)записи.
По поводу работы СХД и снимков могу вам достоварно заявить, что скорость не упадёт на любом доступном количестве клонов, тут у нетапа магических костылей никаких нет. Так устроен внутренний механизм файловой системы WAFL. Если хотите могу поверхностно объяснить.
С тем подходом как вы начали этот тред, вы вряд-ли добьетесь моей преклонности и моего желания разбираться в вашей проблеме.
Еще раз: здесь топик не про траблшутинг, а я не техподдержка и даже не сотрудник нетапа, а тема про тюнинг езернет.
Статья никаким боком не касается вашего вопроса, кроме картинки NetApp FAS.
На сим прошу оффтоп закончить.
Но для нетапа к примеру nfs на 10 гб должен давать одинаковые показатели латенси и iops по сравнению с fc8. Если это не так, то точно есть проблема с сетью.
Могу сказать относительно латенси, что можно получить 0.5 мс (для этого нужен будет флеш) отклик для чтения и записи на езернет.
Если да, то на сколько «качественно» срабатывает будильник?
На сколько качественной и удовлетворяющей является функция Smart Будильника для вас?
Спасибо.
В виду того, что запись всегда происходит в новое место, функция снапшотов (и соответственно клонов) очень легко реализуется в такой ФС. Когда новые данные перезаписываются при помощи «записи в новое место», старые данные по сути не затираются, при этом указатели инодов переставляются в «новое место» указывая на перезаписанные данные, таким образом происходит высвобождение нового места. Другими словами эта особенность работы WAFL (перезапись при помощи записи в новое место) является базой для работы нетаповских снапшотов по соответствующему принципу «Redirect On Write». В связи с чем на любом доступном количестве снапшотов (максимум 255 на том для DataOntap) или клонов, нет необходимости выделять специальный резерв пространства под снапшоты, а также нет падения производительности. Такая возможность WAFL должна быть очень востребована тестерами.
Т.е. выделение пространства под LUN о котором я говорю в статье не связанна с особенностью работы нетаповских снапшотов, а скорее с устаревшим принципом работы SAN, который не так давно, к счастью был доработан новыми, весьма не плохими костылями (SCSI SBC-3). Другими словами WAFL не знает о содержимом LUN'а и какие блоки там актуальные, а какие уже не нужны, а новые «костыли» позволяют ей это узнать, не захватывая мусор в снапшот и высвобождая пространство по мере удаления дынных на LUN'е. В то время как NAS имеет намного менее выраженные «проблемы поедания пространства» в сочетании со снапшотами, так как ФС WAFL взаимодействуя с хостом по SMB или NFS прекрасно знает о том, какие блоки данных более не нужны, этот функционал был заложен так сказать «By Design».
Как известно слова WAFL и Snapshot являются торговыми марками патентованными технологиями нетапа. В связи с чем слово снапшот не применяется в официальных названиях других продуктов и применяется в «не официальной терминологии». Но оно уже как-бы адаптировалось, и теперь оно как правило применяется в более «широком смысле».
Относительно снапшотов хочется отметить то, что «традиционные снапшоты» устроены по принципу COW (Copy On Write), где название отражает принцип работы: так как традиционные исполнения ФС «перезаписывают» изменённые данные на «прежнее» место, такому спаншоту необходимо выделять специальное место в ФС. Следующей особенностью работы COW является то, что для перезаписи новых данных (изменения данных) в захваченном снапшоте, такие данные для сохранности содержимого снапшота, должны быть сначала скопированные в выделенное для этого место, собственно от сюда и название Copy On Write. Таким образом самым главным недостатком такой технологии является падение производительности с ростом числа снапшотов, генерируя всё больше и больше накладных операций копирования при (пере)записи.