about NetApp

 

Природа не терпит пустоты: там, где люди не знают правды, они заполняют пробелы домыслом.
Джордж Бернард Шоу

В прошлом посте я начал детальный разбор довольно объемного текста, написанного специалистами компании HP о том, как и в чем они видят недостатки систем хранения NetApp. Так как с их стороны это оказалось крайне субъективное и неточное изложение вопроса, грешащее многочисленными ляпами, более или менее неосознанными заблуждениями и непониманием ряда основополагающих технологий, использованных у NetApp, я счел себя обязанным не оставлять его без ответа, и написать эту комментрованную рецензию, которую и предлагаю вашему вниманию. Это – вторая половина текста, смотрите первую часть в предыдущем посте.

Я намеренно выбрал тут тактику “чистой обороны”, и ничего, или почти ничего не говорю о свойствах и недостатках систем “противной стороны”, хотя, безусловно, у NetApp есть что острого и ехидного спросить у HP на их счет. Я лично считаю жанр “говнилок”, в котором написан исследуемый текст, довольно-таки “грязным”, он пишется, как правило, анонимно, и, по законам жанра, изобилует полемическим передергиванием, лично я считаю, что писать такие тексты – западло (давайте я уже скажу это слово ;). Но – “с волками жить – по волчьи выть, иначе будешь сидеть без бонусов”, я понимаю что именно заставляет такое писать.

А теперь давайте продолжим разбор обсуждаемого документа.

14. Отдельно нужно сказать про реализацию блочного доступа в системах NetApp (т.е., по протоколам FC/iSCSI). ??значально ONTAP разрабатывалась для файлового доступа, т.е. как NAS система. Затем NetApp добавил в ONTAP возможность работать с данными на блочном уровне, но реализовано это поверх файловой системы WAFL, т.е., тома в NetApp на самом деле являются файлами в WAFL.

Это не так, автор вновь, как и в случае с RAID-DP, не имеет представления о том, как именно работает с данными WAFL. О том, как именно работает блочный доступ в WAFL, и почему LUN-ы в WAFL это полноценный блочный доступ в семантике SCSI, а НЕ “являются файлами в WAFL” даже я писал в блоге не раз, например смотрите перевод статьи инженера Костадиса Руссоса “Почему я считаю, что WAFL это не файловая система”, опубликованном в этом блоге еще 4 года назад. Стыдно должно быть инженеру за четыре года так и не разобраться в теме.

LUN-ы а томах NetApp действительно “видны” как “файлы” для “стороннего наблюдателя”, который смотрит на содержимое тома через NAS-шару, но это забавный side-effect используемого “API” работы с метаданными на WAFL, и из этого не следует, что использующие LUN хосты в самом деле обращаются к нему как к файлу. Вовсе нет. То, что в Linux, зайдя в директорию /dev вы увидите там “файлы” /dev/cpu или /dev/ram ведь не убеждает вас, что под Linux в компьютере CPU эмулируется на файловой системе?

Такой подход имеет ряд негативных моментов и для производительности, и для надежности. Проблема заключается в том, что WAFL в силу своей «природы» обеспечивает эффективное управление метаданными только на уровне файлов и не может реализовать столь же эффективное управление для LUN, «маскирующихся» под файлы. По этой причине, для гарантированной бесперебойной работы блочных приложений (СУБД, почта и т.д.) в системах NetApp должен присутствовать некоторый объем свободного дискового пространства.

…и сделав неправильное допущение, исходя из неверной предпосылки, нагромождаем вымысел, не имеющий ничего общего с реальностью. Потому что, если, как я показал выше, LUN-ы в WAFL НЕ являются файлами, значит все написанное автором, исходя из неверного посыла – неверно.

Наличие свободного дискового пространства регулируется параметром fractional space reservation, который по умолчанию выставлен в 100%. Т.е., для блочного доступа требуется 100% резервирование емкости: если у вас 2 том по 1ТБ каждый, вам настоятельно рекомендуется зарезервировать еще 2ТБ! ??наче вы просто можете потерять все ваши данные…

Снова “это не так”. Господа из HP, срочно обновите ваши Competitive materials. :) Fractional reserve (LUN overwrite reserve) не имеет ничего общего с вашим вымыслом на его счет. Это резервирование, которое МОЖЕТ (не “требуется”, а “может”) использоваться, и позволяет обезопасить данные в случае если: 1. Вы используете LUN на томе с резервированием пространства, 2. Вы сделали с этого LUN хотя бы один снэпшот. 3. Вы полностью перезаписали все 100% блоков этого LUN новыми данными. 4. У вас на томе при этом отключены все другие средства для обеспечения достаточного объема свободных блоков на томе, например volume autogrow и snapshot autodelete. Только в этом случае Fractional Reserve (он же LUN Overwrite reserve) необходим. Во всех прочих случаях это резервирование необходимым не является. По дефолту Fractional Reservation не устанавливается для тома со времен Data ONTAP 7.3.3 (сегодня, напомню, актуальной версией является 8.2), то есть свыше трех лет, и даже в те времена его можно было изменять и выключать.

Я писал про Fractional Reserve также около 4 лет назад, например тут: Загадочный fractional reserve (часть 1). Также полезно почитать это: Usable Space у NetApp – что стоит за FUD? (часть 2)

15. Любимая технология NetApp – snapshots. Помимо прочих проблем здесь также есть серьезные недостатки, связанные с не эффективным использованием дисковых ресурсов. Snapshots NetApp требуют резервирования дисковой емкости примерно 20% от емкости исходного тома (в массивах НР вообще не требуется резервировать емкость для snapshots).

Вновь “это не так”. Даже если мы оставим непрокомментированными “прочие проблемы”, так как неясно, что именно под этой FUD-фразой имел ввиду автор, и это невозможно прокомментировать, то зато можно указать, что снэпшоты NetApp НЕ требуют “резервирования 20% от емкости исходного тома”. Вы можете, для собственного удобства, для облегчения управлением пространством на томе, выделить определенный объем (любой), который будет гарантированно доступен для хранения данных в снэпшотах. Но вы НЕ “должны” этого делать. При конфигурировании тома с настройками “по-умолчанию” том действительно создается со включенным резервированием пространства и установленными Snapshot Reserve на 20%, но если вы не собираетесь использовать снэпшоты, или знаете, что их объем будет невелик, то вы можете изменить это значение для тома, без влияния на уже записанные на том данные, на любую желаемую величину, вплоть до 0%. Но, кстати, даже с полностью отключенным snapshot reservation вы по-прежнему сможете использовать снэпшоты.

В любом случае, если вы намерены использовать снэпшоты, данные в них надо где-то хранить. Возможно у HP просто никто не пользуется их снэпшотами ;), поэтому резервирование места под снэпшоты там и не установлено по умолчанию.

Кроме того, при создании нескольких snapshots с одного тома удаление любого snapshot в массивах NetApp приводить к удалению всех последующих (созданных после удаляемого) snapshots, что существенно снижает ценность использования технологии snapshots в массивах NetApp.

Снова “не так”. Возможно имелось ввиду использование функции SnapRestore, которая восстанавливает том целиком из сделанного снэпшота, при этом, разумеется, в снэпшот тома входят и существовавшие на этот момент снэпшоты, а те, что были сделаны после, разумеется, в том томе еще не существуют. Но функция (опция) SnapRestore не есть “снэпшоты”  сами по себе. В случае обычного удаления снэпшотов командой snap delete <имя-снэпшота>, можно удалить любой из снэпшотов тома по выбору, не затрагивая остальные, так что в сформулированном выше выражении оно неверно.

Собственно – вот пруф:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2013.07.25 15:26:22 =~=~=~=~=~=~=~=~=~=~=~=
login as: root
root@192.168.0.231’s password:

ntap-sim-7A> snap list vol0
Volume vol0
working…
  %/used       %/total  date          name
———-  ———-  ————  ——–
13% (13%)    3% ( 3%)  Jun 21 00:00  nightly.0     
17% ( 6%)    4% ( 1%)  Jun 20 20:00  hourly.0      
20% ( 4%)    5% ( 1%)  Jun 20 16:00  hourly.1      
23% ( 4%)    5% ( 1%)  Jun 20 12:00  hourly.2      
26% ( 4%)    6% ( 1%)  Jun 20 08:00  hourly.3      
29% ( 6%)    7% ( 1%)  Jun 20 00:00  nightly.1     
30% ( 2%)    8% ( 0%)  Jun 19 20:00  hourly.4      
30% ( 1%)    8% ( 0%)  Jun 19 16:00  hourly.5      

ntap-sim-7A> snap create vol0 snapshot1
ntap-sim-7A> snap create vol0 snapshot2
ntap-sim-7A> snap create vol0 snapshot3

ntap-sim-7A> snap list vol0
Volume vol0
working…

  %/used       %/total  date          name
———-  ———-  ————  ——–
  0% ( 0%)    0% ( 0%)  Jul 25 15:28  snapshot3     
  0% ( 0%)    0% ( 0%)  Jul 25 15:28  snapshot2     
  0% ( 0%)    0% ( 0%)  Jul 25 15:28  snapshot1     
13% (13%)    3% ( 3%)  Jun 21 00:00  nightly.0     
18% ( 6%)    4% ( 1%)  Jun 20 20:00  hourly.0      
21% ( 4%)    5% ( 1%)  Jun 20 16:00  hourly.1      
23% ( 4%)    5% ( 1%)  Jun 20 12:00  hourly.2      
26% ( 4%)    6% ( 1%)  Jun 20 08:00  hourly.3      
29% ( 6%)    7% ( 1%)  Jun 20 00:00  nightly.1     
30% ( 2%)    8% ( 0%)  Jun 19 20:00  hourly.4      
31% ( 1%)    8% ( 0%)  Jun 19 16:00  hourly.5
      
ntap-sim-7A> snap delete vol0 snapshot2
ntap-sim-7A> Thu Jul 25 15:29:03 ICT [ntap-sim-7A:wafl.snap.delete:info]: Snapshot copy snapshot2 on volume vol0 NetApp was deleted by the Data ONTAP function snapcmd_delete. The unique ID for this Snapshot copy is (13, 10899). 

ntap-sim-7A> snap list vol0
Volume vol0
working…

  %/used       %/total  date          name
———-  ———-  ————  ——–
  0% ( 0%)    0% ( 0%)  Jul 25 15:28  snapshot3     
  0% ( 0%)    0% ( 0%)  Jul 25 15:28  snapshot1     
13% (13%)    3% ( 3%)  Jun 21 00:00  nightly.0     
18% ( 6%)    4% ( 1%)  Jun 20 20:00  hourly.0      
21% ( 4%)    5% ( 1%)  Jun 20 16:00  hourly.1      
23% ( 4%)    5% ( 1%)  Jun 20 12:00  hourly.2      
26% ( 4%)    6% ( 1%)  Jun 20 08:00  hourly.3      
29% ( 6%)    7% ( 1%)  Jun 20 00:00  nightly.1     
30% ( 2%)    8% ( 0%)  Jun 19 20:00  hourly.4      
31% ( 1%)    8% ( 0%)  Jun 19 16:00  hourly.5      
ntap-sim-7A>
ntap-sim-7A> exit
logout

16. Чтобы закрыть тему эффективности использования дисковых ресурсов в системах NetApp - пример расчета доступной емкости: имеем 14 дисков, два диска уходят под parity (RAID-DP) и 1 диск под hotspare; резервирование под WAFL - 10%, резервирование под aggregate - 5%, резервирование под snapshots - 20%, резервирование под performance buffer - 20%, и самое ужасное - под block enviroment (FC/iSCSI) рекомендуется 100% резервирование емкости, т.е., для тома 100ГБ нужно зарезервировать еще 100ГБ… Можно посчитать, сколько доступной емкости останется… Да, и еще надо не забыть: на каждый контроллер нужно резервировать по 3 диска – для root volumes…

NetApp – лидер по не-эффективному использованию дисковых ресурсов!

Ну и что у нас остается после всего этого “сеанса черной магии с последующим его разоблачением” в моих комментариях выше? Не так уж много, давайте посчитаем правильно. Для RAID-DP на 14 дисках действительно два диска уйдут под parity, но если у вас не 14 дисков, вы же не MSA2000-class систему покупаете, мы тут про хайенд говорим, с V400/V800-class начали тему, кажется, то все выглядит несколько иначе:  О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1). Так, например, у конкурентов, при использовании единственного эквивалентного RAID-DP по быстродействию и надежности, из доступного у HP варианта – RAID-10, вы уже сразу должны отдать под “RAID” половину дисков. ?? эту половину вы должны  (не “можете”, а “должны”) всегда отдать и на 14, и на 1920 дисках. В отличие от NetApp.

Дальше следите за руками ;) Вы теряете на WAFL reserve 10% – это так, верно. Но это единственное обязательное резервирование. Резервирование под aggregate используется только в Metrocluser и SyncMirror, поэтому устанавливается в значение 5% по умолчанию (значения по умолчанию это просто “защита от тупого дурака юзера”, максимально безопасные для ваших данных при самом идиотском способе использовать сторадж, не прочитав ни одной страницы документации), но оно может быть (и это рекомендуется в официальных best practices)  отключено полностью, если у вас НЕ метрокластер – 0%.

Резервирование под snapshots может быть установлено в 0% без вреда для данных и системы, 20% это просто удобное значение по умолчанию, см. выше.

Что такое performance buffer это я не знаю, это вымысел HP, такого термина в документации NetApp нет, оставим на совести фантазеров из competitive-отдела HP. 0%.

С самым ужасным мы тоже разобрались – Fractional reserve это deprecated опция, в настоящий момент редко используемая в реальной жизни. 0%.

Вот и все. Практические результаты подобный расчет подтверждают. В 2011 году NetApp опубликовал запись в своем блоге, что для 7600 эксплуатируемых клиентами и регулярно присылающих отчеты о своем состоянии в систему AutoSupport стораджей NetApp фактическая заполненность данными (usable) относительно raw (голых установленных в системе дисков), составила 66,27%.

Как насчет публикации такого же подсчета для систем HP? ;)

17. Еще одна любимая технология NetApp – дедупликация. Дедупликация - полезная вещь, несомненно, но не в дисковых массивах…

“Голодная лисица увидела виноградную лозу со свисающими гроздьями и хотела до них добраться, да не смогла; и, уходя прочь, сказала сама себе: "Они еще зеленые!"

В свете того, что HP делает дедупликацию для бэкапов, и пока этим и ограничивается, довольно забавно выглядит попытка убеждать всех, что вы ищете других дроидов “это вам не нужно”. Помнится MS настойчиво убеждала всех, что Live Migration для VM “не нужно”, до тех пор, пока не реализовала это “не нужно” у себя в новой Hyper-V. ;)

??зложенная ниже информация основана на 46-страничном документе NetApp озаглавленном: «NetApp Deduplication for FAS and V-Series – Deployment and Implementation Guide». http://media.netapp.com/documents/tr-3505.pdf.

Спасибо, что указываете источники (почаще бы), но следует также помнить,что документы у NetApp обновляются часто, и было бы неплохо также указывать какую версию вы использовали, от какого года. См выше историю про Fractional Reserve и Data ONTAP 7.3.3 трехлетней давности (вышла в релиз в июне 2010 года, судя по release notes). Потому что текущая версия (о, ужас) имеет уже 75 страниц. ?? это не единственный документ про дедупликацию, например для текущей Data ONTAP 8.x написан TR-3958 для 7-mode и TR-3966 для C-mode, и там и там за 80 страниц.

· ??нтересно, что объяснение того как работает дедупликация требует разъяснений на 46 страницах… Вряд ли такую технологию можно назвать простой и понятной! ?? помимо всего прочего, дедупликация работает по разному и требует различных настроек (!) в зависимости от того какие приложения используются и в каких условиях: файловый доступ или блочный доступ (LUN), MS Exchange или VMware и т.д.

?? именно потому, что это “любимая технология”, в приведенных выше документах содержится подробнейший разбор механизмов работы этой технологии, а большую часть самого документа составляют подробные рекомендации NetApp по ее применению с различными типами данных и приложениями: MS Exchange, SQL Server, Sharepoint, Hyper-V,  Oracle DB, VMware vSphere, даже Lotus Domino и Symantec Backup Exec!

Безусловно, разные типы данных и приложения с разным характером доступа к ним требуют внимания и настройки для достижения наилучших результатов. Этому всему стоит уделить внимание, так как дедупликация NetApp работает с primary, активными, “боевыми” данными, производительность доступа к которым критически важна. Это не бэкапы, чем только лишь и занимается дедупликация HP, и где производительность не настолько уж и важна. Однако обычно даже в состоянии установок по умолчанию, дедупликация работает вполне неплохо, о чем еще несколько слов ниже.

· Самое главное, дедупликация приводит к очень существенному снижению производительности: согласно официальным данным NetApp дедупликация приводит к замедлению на 35% (для FAS6080), HP проводила свои тесты, которые показали, что дедупликация приводит к падению производительности на 65% (для FAS2050)! ?? что самое неприятное – после завершения процесса дедупликации производительность остается на низком уровне.

Начнем с того, что хитро построенное предложение заставляет читающего его “чайника” думать, что речь идет о снижении производительности дедуплицированных томов как таковых, просто по факту их дедуплицированности, хотя в исходном контексте, откуда вырвано это утверждение говорится лишь о возможном снижении производительности во время работы процесса поиска и сравнения дубликатов блоков. Этот процесс обычно назначается на выполнение по расписанию на периоды малой загрузки, идет с фоновым приоритетом, и, обычно, занимает время от минут до нескольких часов, в зависимости от интенсивности записей на сторадж за прошедщий с прошлого запуска интервал времени.

Оставим без комментариев эксперименты специалистов HP, уже не раз показавших в этом документе “глубокое понимание устройства” и особенностей настройки систем хранения NetApp. :)

Что касается процитированного - снова посоветую обновлять ваши материалы :) Если вы посмотрите в текущий документ о дедупликации, сегодня им является NetApp Data Compression and Deduplication Deployment and Implementation Guide. Data ONTAP Operating in 7-Mode. Sandra Moulton, Carlos Alvarez, NetApp April 2013 | TR-3958, то на счет performanse impact там указано (глава 9.2, стр.23), ниже в моем переводе, также как и выделение важного болдом:

“Вот некторые ориентировочные данные о работе дедупликации на FAS3140 (это, напомню, самая слабая модель midrange предыдущего поколения, примерно эквивалентная сегодняшней FAS2240 и в полтора раза слабее текущей, самой слабой в midrange, FAS3220).

• При восьми (максимальное число, прим romx)  параллельно работающих процессах дедупликации, без каких-либо других работающих процессах, дедупликация использует 15% CPU в своей наименее вторгающейся в работу системы фазе (least invasive phase). Процесс будет занимать практически все имеющиеся ресурсы CPU в период наиболее активной фазы (most invasive phase), пока у системы не появится процесс с более высоким приоритетом (напомню, так как процесс дедупликации в системе исполняется с фоновым, понижеными приоритетом, то любой процесс работы с данными системы хранения будет иметь для CPU более высокий приоритет, чем дедупликация. Прим. romx).
• Когда работает один процесс дедупликации, то падение производительности для других приложений (NB: НЕ системы хранения, а приложений на ней, например онлайн-компрессии, репликации или работы встроенного антивируса. прим.romx) может составлять от 0 до 15%.
• При восьми одновременно запущенных процессах дедупликации, может быть от 15% до более 50% падения производительности для других приложений, работающих в системе.

Это о работе процесса дедупликации, запускаемого периодически в периоды низкой загрузки системы с фоновым приоритетом. Теперь о влиянии самого факта дедупликации на производительность записи и чтения:

Производительность на запись

Производительность на запись для дедуплицированных томов –  если загрузка системы низка, например если загрузка CPU контроллера 50% и менее – мало или вовсе не отличается от производительности на недедуплицированном томе, нет заметного влияния на работу других приложений, работающих на системе.
На сильно загруженной системе, где производительность ограничена производительностью полностью загруженного процессора контроллера, влияние на производительность при записи может быть заметно. Например, в экстремальном случае, при 100% random overwrite на томе с 95% дедупликацией его объема, FAS3140 демонстрирует снижение производительности на 15%. Влияние было ниже при работе на нескольких томах. <…> Влияние на производительность при последовательной записи, такой как запись новых файлов или дописывание к уже существующим, было ниже 5%, при сравнении с томами без проведенной дедупликации.

Производительность на чтение

В случае, когда эффект экономии от дедупликации невысок, дедупликация не оказывает никакого или оказывает небольшое влияние на производительность последовательного чтения. В тестовом сценарии с высоким значением экономии при дедупликации, например 100%, было получено улучшение производительности на 50% (за счет лучшего попадания в dedupe-aware кэш, прим. romx); Всценарии наихудшего варианта, в котором интеллектуальный кэш (Flash Cache или Flash Pool) обходился путем принудительного последовательного чтения незакэшированных блоков, наблюдалось снижение производительности до 25% на систсеме с контроллером, упершимся в 100% загрузку CPU. Наличие запаса по CPU в 15% и 10% по дисковой загрузке (disk busy <90%) обычно будет поглощать возможный негативный эффект на производительность при последовательном чтении. Типичный сценарий реальной жизни будет находится где-то между этими двумя крайними точками, описанными выше, и должен быть предварительно протестирован.”  Конец цитаты TR-3958.

Рандомное же чтение, как нетрудно понять, остается рандомным в любом случае и с дедупликацией и без, и никакого отличия в производительности дедупликация для random read обычно не привносит.

Все это настолько плохо, что инженеры NetApp предупреждаю заказчиков о необходимости предварительного тестирования того, как дедупликация скажется на производительности их приложений…

Да, NetApp стоит на позиции, что лучше клиенту сразу знать в полном объеме не только о достоинствах решения, но и о потенциальных недостатках и возможных сложностях его использования. Пусть даже если в своей реальной задаче он с ними и не столкнется, но знать о ограничениях технологии он должен в полном объеме, до покупки. ?? это не “настолько плохо”, это, на мой взгляд – хорошо, что вендор говорит максимально откровенно со своими партнерами и покупателями, а не кормит их маркетинговой засахаренной лапшой (а с проблемами клиента после покупки пусть разбирается бангалорский саппорт, деньги-то уже получены). ??нтересно, а HP, например, рассказывает своим потенциальным клиентам не только о достоинствах и преимуществах, но и о возможных засадах использования Thin Provisioning? ;)

· Сама по себе дедупликация также не отличается высокой производительностью: по данным NetApp на дедупликацию 1ТБ тома требуется 2,5 часа.

Это, как нетрудно догадаться, сильно зависит от характера данных, от текущей нагрузки на сторадж и от мощности контроллера (его модели), Без учета всех трех параметров приведенное время бессмысленно. (в оригинале сразу после процитированного указывается: “This scenario is merely an example. Deduplication typically completes much faster following the initial scan, when it is run nightly.”) Следует понимать, что процесс дедупликации данных при начальном запуске состоит из двух основных частей. ??з (1) обработки данных, уже находящихся на диске в момент начала работы дедупликации, и эта обычно довольно объемная работа, но выполняемая один раз, и из (2) дедупликации измененных блоков, записанных с момента предыдущей дедупликации, например за сутки, если этот процесс запускается ежесуточно. Вторая, регулярная часть, не требует полной обработки всего диска, работает только со сравнительно небольшой частью измененных блоков, и выполняется обычно довольно быстро.

· Дедупликация не полностью совместима со snapshots – две самые любимые технологии NetApp плохо интегрированы друг с другом… Согласно NetApp Best Practices: если требуется создать snapshot, тогда процесс дедупликации должен быть запущен до создания snapshot, в противном случае эффект от дедупликации будет мало эффективным.

Не вполне ясно, что именно в данном случае имели авторы текста ввиду. Понятно только, что, вновь, с механизмом работы что дедупликации, что снэпшотов, они разобрались “не очень”. Снэпшоты – это, “по определению” read-only объекты, они так задуманы. Они, и составляющие их дисковые блоки данных никак, ни при каких условиях не могут быть изменены, пока не будут удалены с тома. Если на диске у вас лежит терабайт данных и терабайт read-only снэпшотов, то, понятное дело, дедупликация не имеет никаких средств дедуплицировать данные, уже находящиеся и “запертые” в терабайте снэпшотов, и половина объема диска останется для нее недоступной (коэффициент дедупликации будет хуже, чем мог бы быть). Поэтому снэпшоты, уже сделанные до того, как для тома была включена дедупликация, разумеется останутся неизменными и недедуплицированныем. Но если вы возьмете снэпшот с уже дедуплицированного тома, то он конечно же останется дедуплицированным. Отсюда рекомендация включать дедупликацию на томе до начала использования снэпшотов, что улучшит коэффициент дедупликации. В чем здесь “не полная совместимость” по мнению HP – для меня загадка :)

· Дедупликация, мягко говоря, не очень эффективна на уровне томов (LUNs): эффекта от дедупликации можно и совсем не обнаружить.

Ничего я не стану по этому поводу больше говорить, кроме этой вот глумливой, мягко говоря, мем-картинки. Просто сошлюсь на свой пост, в котором, было дело,  разыграл приз среди приславших свои результаты по дедупликации. Вот этот “конкурс”. Свое слово в комментах к нему говорят реальные пользователи систем NetApp, это не маркетинговый шорох – реальные “боевые” данные на реальных живых системах в эксплуатации. Если типичные 35-40% экономии в среднем на LUN-ах с primary data, без существенной потери в производительности (!) это, “мягко говоря не очень эффективно”, то что же HP вообще называет “эффективно”?

Вот цитата из упомянутого выше документа: «If the data in [a 500GB] LUN is reduced through deduplication, the LUN still reserves the same physical space capacity of 500GB, and the space savings are not apparent to the user». Т.е., при дедуплицировании данные занимают меньший объем, но в то же время вся емкость тома остается зарезервированной и эффект от дедупликации пользователи не видят…

…но если читающие данный документ действительно сходят и прочитают это утверждение в контексте, то увидят, то речь идет о частном случае LUN “с резервацией”, со включенной опцией space reservation, то есть это о так называемых thick LUN, который создается фиксированного размера, и, конечно, формально занимает место на дисках, даже если он пуст или целиком дедуплицирован. Он, LUN, так устроен, независимо от дедупликации или чего-то еще. Если требуется получить экономию места от дедупликации на LUN, то надо просто использовать “тонкие” LUN, тем более, что “тонкость” на NetApp практически не влияет на производительность, и она может по желанию включаться и выключаться, то есть LUN-ы становятся “толстыми” и “тонкими” установкой одной галочки в настройках, причем без влияния на уже записанные данные, “на ходу”.

К тоиу же следует понимать, что not apparent to the user в контексте относится к приложению, использующему LUN, администратор же системы хранения в любом случае получит назад высвобожденное пространство и сможет его использовать, например размещать там данные снэпшотов или создавать новые тома.

· При восстановлении данных с лент необходимо иметь свободную емкость, равную полному объему восстанавливаемых данных (дедупликация выполняется только после завершения записи данных на диски, при копировании данных с дисков на ленты эффект дедупликации пропадает: на ленты записывается полный объем данных). Поэтому, если требуется восстановить с лент целиком все данные массива или большую часть этих данных – это может оказаться не возможным из-за нехватки свободного места в массиве.

Это так только в случае использования традиционного способа резервного копирования и восстановления. Но, во-первых, резервное копирование в NetApp обычно выполняется иным способом кроме как тупым копированием всех данных наружу на ленты (см, например, SnapVault), а во-вторых, если уж ленты в удаленном хранилище необходимы и надо сохранить дедупликацию, то существует решение под названием SnapMirror-to-Tape (SM2T), которая позволяет выполнять резервное копирование и восстановление данных томов с сохранением их дедупликации, компрессии и прочих штук и экономий.  Подробнее в документе SnapMirror Async Overview and Best Practices Guide, глава 5.1, страница 44

· Дедупликация несовместима c режимом синхронной репликации между массивами NetApp.

Что, в общем, логично. Синхронная репликация предъявляет высокие требования к быстроте обработки операций записи, происходящей на диск, и в тех случаях, когда вам нужна максимальная производительность, то вам в этот момент не до экономии. Однако вы можете на одной и той же системе иметь часть томов синхронно реплицируемых, а другие, где важнее хранящийся объем – дедуплицирующиеся. Ваш выбор.

· Дедупликация несовместима c утилитой дефрагментации (см. выше). Можно использовать либо дефрагментацию, либо дедупликацию.

Что такое “утилита дефрагментации”? 8-| О реаллокейте блоков, неверно называемой специалистами HP “дефрагментацией” – уже писал выше.

· Flexclones можно дедуплицировать, но это ведет к существенному снижению скорости клонирования.

Обычно такие утверждения предполагают ссылки на подтверждающие материалы. :) В оригинале это звучит так: You can create FlexClone files or FlexClone LUNs on FlexVol volumes in which deduplication is enabled. The -I option of the clone command enables change logging on the FlexVol volume. Enabling change logging slows down the clone creation process. You must enable change logging only if there is a huge amount of data overwrites to the source file or LUN and you want to share these new data blocks during the deduplication operation.

Перевод (корявость обусловлена дословностью, с целью быть максимально точным к тексту): Вы можете создавать клонированные с помощью FlexClone файлы или клонированные с помощью FlexClone LUN-ы на томах типа FlexVol, на которых дедупликация включена. Опция –I команды clone включает процесс change logging (одна из составляющих процесса дедупликации, прим. romx) на томе FlexVol. Включение процесса change logging замедляет процесс создания клона. Вы должны включить change logging только если у вас огромный объем данных перезаписан на исходном файле или LUN-е, и вы хотите использовать эти новые блоки данных в процессе дедупликации.

??з перевода очевидно, что речь идет о некоем частном случае (клонирование с включенной опцией –I и большим предшествующим объемом изменений на клоне), а НЕ о замедлении клонирования дедуплицированного тома вообще. Физически это объясняется тем, что, по сути, клонирование и дедупликация есть на физическом уровне один и тот же процесс, и также как обычно бессмысленно зиповать уже зазипованный архив, так и дедупликация клонов FlexClone дело в целом не несущее большого смысла и не дающее существенного выигрыша в объеме.

· При разрыве связи клона с исходным томом (a cloned volume is split from its parent) клон автоматически становится не дедуплицированным. Значит, в этом случае нужно предусмотреть достаточные свободные дисковые ресурсы.

Это естественно, потому что, по своей физической сути, клон и дедупликация это один и тот же механизм, просто по разному названный. Отделение клона в отдельный том физически эквивалентно копированию дедуплицированного тома “наружу”, на другой том или внешнее хранилище (clone split обычно делается именно для этого, иначе зачем делать split? Работать с клоном можно и без сплита.). Так как при этом необходимо создать полностью “автономный” том, файл или LUN, который был раньше чьим-то клоном, и теперь не завиcящий больше ни от каких других совместно используемых другими клонами на томе блоков, то 100% всех блоков надо физически скопировать в новое расположение этого отделенного клона, создать ему их приватную копию. После создания сплит-клона его можно, конечно, в свою очередь дедуплицировать уже индивидуально. 

Неудобство? Ну, возможно, ну, вот так оно работает, считать это недостатком это все равно что считать недостатком воды то, что она мокрая. Это ее физическое свойство. ?? это – тоже “физическое свойство” дедупликации/flexclone. Решение: работать с клонами не делая им split.

Дедупликация может применяться к зашифрованным данным, но в этом случае эффект от дедупликации будет нулевым.

Вероятно это так, это зависит от применяемого способа шифрования, но в общем случае – да. Насколько это актуально – оставляю судить вам. При этом таке отмечу, что шифрование отдельного тома с данными никак не влияет на остальные. Вы можете шифровать отдельный том с чувствительными данными (например: пользовательскую информацию), и не дедуплицировать его, и не шифровать другие тома с не такими конфиденциальными данными (образы виртуальных машин, например, без пользовательских данных в них), и весьма эффективно их такие дедуплицировать на одной и той же системе хранения. Снова - ваш выбор.

18. Система управления NetApp для среды VMware позволяет управлять только дисковыми массивами. Для VMware более эффективно и более важно иметь единую интегрированную систему управления для серверов, сети и дисковых массивов – как в HP Insight Control.

Наверное нужно и то, и то. Но решать, что более важно и эффективно, я полагаю, должен клиент, а не вендор, продающий ему свой софт. ?? если клиенту нужно только управлять дисковыми массивами, например с помощью бесплатного VSC, то может не стоит ему навязывать весьма платный HP Insight Control? ??ли как сказал в своем блоге Dr.Dedupe: “Если для танцевальной вечеринки достаточно джазбэнда, то почему HP обязательно хочет продать своим клиентам симфонический оркестр?” Кстати, встречный вопрос: У HP по-прежнему нет плагина для vCenter для управления стораджем в среде vSphere, администратором виртуальной инфраструктуры?

19. NetApp MetroCluster – позволяет кластеризовать дисковые массивы между двумя площадками, но при этом на каждой площадке поддерживаются только ОДНОКОНТРОЛЛЕРНЫЕ – не отказоустойчивые конфигурации массивов (см. п.1)! Т.е., используя NetApp MetroCluster, заказчик отказывается от отказоустойчивости дисковых массивов на каждой из своих площадок. Кроме того, простой обрыв связи между площадками приводит к полной потери отказоустойчивости как на уровне обоих площадок, так и на уровне каждой площадки. Решение NetApp MetroCluster нельзя считать “site-disaster, zero-downtime, high-availability product designed for customers mission critical data”. Любые дисковые массивы НР, начального, среднего и старшего уровней, позволяют строить кластеризованные решения между двумя площадками и при этом использовать отказоустойчивые двухконтроллерные конфигурации массивов на каждой площадке.

Это не так. В документе Best Practices for MetroCluster Design and Implementation на странице 26 и странице 37 можно посмотреть на схему Dual и Twin Metrocluster, которые состоят из двух двухконтроллерных конфигураций.

NetApp декларирует, что MetroCluster обеспечивает автоматическое и прозрачное переключение на резервную площадку, но это опять не соответствует реальности – достаточно обратиться к руководству по настройке MetroCluster «Best Practices for MetroCluster Design and Implementation» (http://media.netapp.com/documents/tr-3548.pdf) , стр.39: «Upon determining that one of the sites has failed, the administrator must execute a specific command on the surviving node to initiate a site takeover» и стр.40 «Although a complete site failover can be performed with a single command, there are cases in which another step or two might be necessary before data is accessible at the surviving site» - т.е., администратор должен выполнить одну или несколько команду по переключению на резервную площадку. Такая «автоматизация» приводит к существенным задержкам при переключении между площадками. В отличие от NetApp, такие решения НР, как HP MetroCluster, HP Cluster Extension и HP ContinentalCluster обеспечивают действительно автоматическое переключение между площадками для массивов P6000/EVA, 3PAR F/T/V-class, P9500/XP. Автоматическое переключение между площадками поддерживается также и массивом НР Р4000 без дополнительного ПО.

Вновь последствия чтения “по диагонали”. Дело в том, что речь идет о ситуации, когда ручное переключение предпочтительнее автоматического, дабы избежать ситуации split brain. Если ваш кластер случайно, по какой-то причине, связанной со срабатыванием автоматики, “порвался”, и обе площадки распределенного кластера решили, что они – единственные выжившие, и продолжили работу, например, с базой данных, то вы получите две копии рассинхронизированной базы, что, вообще говоря, в реальной жизни, катастрофа похлеще падения самолета. Проблеме split brain подвержен ЛЮБОЙ кластер, любого вендора, не только NetApp, но и HP, и любой другой. Для устранения такой ситуации нужен внешний “менеджер” ситуации, так называемый tiebreaker, человек или программа, который, на основании имеющихся у него данных принимает решение о переключении кластера. Это может быть администратор системы (в рассмотренном случае), а может быть отдельная автоматизированная система, такой вариант описан в TR-3660 An Automatic MetroCluster Site Failover Solution.

20. Асинхронная репликация SnapMirror – задержка при реплицировании составляет 60 сек, что приводит к потере большого объема информации при отказе одного массива. В массивах НР Р10000 (V400 и V800), P9500, F200 и F400, Р6000 задержка при реплицировании данных измеряется долями секунд.

Это не вполне так. Да, действительно, в случае асинхронной репликации можно по желанию настраивать интервал обновления на удаленной системе, этот интервал изменяем и в гораздо более широком диапазоне, что позволяет использовать репликацию Asynchronous SnapMirror для разных применений (так, например, один из клиентов NetApp использует SnapMirror для content delivery, раз в сутки реплицируя ночью базу документов из головного офиса в филиалы). Так, SnapMirror может работать и в синхронном режиме (Sync), при котором обновления передаются на удаленную систему немедленно, так и в так называемом “полусинхронном” (Semi-Sync), при котором репликация происходит в синхронном режиме, а в случае невозможности продолжения синхронного режима, например из-за увеличившихся задержек в сети, не останавливать запись на первичную систему, как сделала бы чисто синхронная репликация, а делать fallback в асинхронный режим, с последующим возвратом в “синхронизм”. Все эти варианты являются режимами работы одного и того же SnapMirror, и переключаются установкой ключей в текстовом конфиге. Таким образом, утверждение выше в приведенном виде вновь неверно. Для деталей смотрите официальный SnapMirror Async Overview and Best Practices Guide. Для Sync и Semi-Sync смотрите SnapMirror Sync and SnapMirror Semi-Sync Overview and Design Considerations.
Кроме того, в NetApp есть и чистый Synchronous replication, под названием SyncMirror, доступный для владельцев систем NetApp бесплатно, в базовой поставке.

В общем, массивы НР Р10000 (V400 и V800), P9500, F200 и F400, Р6000 обладают более высокой производительностью и надежностью по сравнению с сопоставимыми моделями массивов NetApp.

В общем, господа пресейлы HP, неудовлетворительно. Незачот. Работайте лучше. “ТщательнЕе” (с). ?? обновите уже, бога ради, ваши competitive материалы, ну неужели не стыдно пользоваться данными времен царя Гороха, давно устаревшими, и выдумывать из детородного пальца недостающие сведения? Это же прокатит только совсем чайнику, неужели вы за таких совершенно чайников никелированных держите ваших заказчиков? Нежнее надо, тоньше. :) Если уж пишете FUD, то он должен хотя бы поверхностную проверку проходить, учитесь у EMC ;). Так что предлагаю фэйлы с фейспалмами списать на то, что HP внезапно вылезла из берлоги на солнышко, и обнаружила, что все уехали далеко. Господа, догоняйте!

Далее в документе идет длинная сравнительная таблица систем NetApp FAS6240/FAS6280 и HP V400/800, также полная недочетов, в особенности в комментариях к графам, но таблицы ужасно трудно вставлять в блоги и комментировать, поэтому я хотел бы от этого уклониться, тем более, что почти обо всем там упомянутом уже написал выше. ?? о том, что контроллеров в системе теперь у NetApp не 2, как утверждает HP, а 8 для SAN и 24 для NAS, и пресейлы из HP (все еще) не понимают, чем отличается Flash Cache от SSD и NVRAM от кэша, и так далее, и так далее.

Спасибо за внимание, комментарии по существу – приветствуются.