about NetApp

Как-то довольно давно у меня в блоге не появлялось постов про технические фичи. Оно и понятно, блог ведется с 2007 года, и наверное уже про все в той или иной мере я уже или писал, или упоминал в предыдущие годы, сколько можно-то уже.

Тем не менее все равно остаются темы, на которые хотелось бы иметь больше информации “простым человеческим языком”, многие фичи NetApp, как я заметил, именно поэтому и не используются широко, потому что раз никто не пользуется – мало информации, а раз мало информации – вот никто и не пользуется. Так что начнем со сравнительно  неплохо известного в принципе: с средства репликации SnapMirror.

SnapMirror это средство синхронной или асинхронной репликации данных как между двумя физическими системами хранения, так и для томов внутри одной системы хранения. Репликация идет по IP-сети, и в этом ее существенное отличие от других решений репликации, других вендоров, которые часто предпочитают FC.

Для начала несколько слов о том, в чем разница между двумя системами репликации, имеющимися у NetApp. Это SyncMirror и SnapMirror.

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

• Плюсы: Мы гарантированно имеем два стораджа в синхронной, идентичной копии. Если блок не записан на удаленную систему, то и на локальной он не записан, и приложение об этом знает. Никакой потери данных и рассинхронизации из-за обрыва связи между стораджами нет “по определению”. Это самый надежный способ.
• Минусы: Это, одновременно, и самый медленный способ с точки зрения приложения. Нетрудно видеть, что скорость работы с приложением, bandwidth между приложением и стораджем, равен скорости работы, bandwidth между локальным и удаленным стораджем. Если у вас приложение подключено к стораджу по 8Gb FC, а канал между стораджами, находящимися в синхронной репликации, составляет 10Mb/s, то максимальная скорость передачи данных между приложением и локально подключенным по FC 8Gb стораджем будет составлять не более 10 мегабит в секунду, то есть будет равным скорости межстораджевого канала репликации.

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

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

• Плюсы: Производительность работы приложения с локальным стораджем максимальна, канал репликации не ограничивает производительность приложения. Кроме того существенно экономится и ресурсы самого канала. Представим себе, что приложение каждые несколько миллисекунд изменияет один блок данных. В случае синхронной репликации, каждое такое изменение должно быть передано на удаленную систему. А в случае асинхронной репликации – только одно, состояние этого блока на момент начала репликации, или же итоговое его значение после всех изменений.
• Минусы: Удаленная копия никогда не становится идентичной локальной. Она ее всегда догоняет, но, если изменения непрерывны, всегда отстает, и этот интервал отставания называется “лагом репликации”. Более того, если не предпринимать специальных мер, то приложение может и не узнать, что каких-то данных на удаленной системе нет, или они не соответствуют данным локальной системы.

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

Так вот, в свете всего вышеизложенного, SyncMirror это в чистом виде синхронная репликация, причем на достаточно низком уровне. Так как вы помните, что в NetApp его RAID это просто то, как функционирует его файловая система WAFL, можно считать, что SyncMirror это просто в этой файловой системе функция RAID-1, “зеркалирование”, “мирроринг”, или, вернее будет, RAID-41 или RAID-61, как принято называть комбинированные уровни, одни, поверх уже имеющихся других.

На сегодня SyncMirror в ее изначальной форме широко применяется только в Metrocluster.

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

Обратите внимание также, что в текущей лицензионной модели SyncMirror бесплатно входит в Data ONTAP Essentials, то есть присутствует бесплатно на любой системе хранения, а вот SnapMirror стоит денег, причем довольно существенных, и это отдельная лицензия.

Ну и, наконец, слово Snap в названии как бы намекает нам, что за технология использована при реализации репликации – это снэпшоты, или разностные “снимки состояния” соответствующего тома. При организации репликации сначала осуществляется так называемый baseline transfer, то есть передача исходного состояния. Это довольно продолжительная и емкая по ресурсам задача, когда целиком весь объем данных реплицируемого тома передается с локальной на удаленную систему. Зато потом, когда завершен baseline transfer на удаленную систему по каналу репликации передаются только изменения от одного цикла репликации до другого, они, обычно, сравнительно невелики по объему. Технически сторадж для этого делает специальный служебный, обычно невидимый пользователю снэпшот с реплицируемого тома, а затем получившиеся изменения передает на удаленную систему, “накатывая” их на тот том, находящийся в специальном состоянии restricted, после чего служебный снэпшот удаляется, на следующий цикл обновления операция повторяется.

??так, разобравшись с тем, что является, и что не является SnapMirror, перейдем к деталям. Продолжение следует.

SnapMirror, Часть 2.

Одной из специфических особенностей “инженерного мЫшления”, исторически присущего компании NetApp, является зачастую весьма странные и вызванные какими-то глубинными процессами названия фич. Зачастую они закрепляются как официальные, видимо выйдя из недр программистских групп, а создаватели брендов и торговых марок из программтстов – те еще.

Вспомните хотя бы загадочный Fractional Reserve, над которым сломал голову не один человек, включая в свое время и меня самого (сегодня он в документации постепенно заменяется на гораздо более понятный LUN Overwrite Reserve). Оттуда же, допустим, vif, и прочие загадочные аббревиатуры, последние были некоторое время назад официально переименованы в куда более понятный ifgrp.

Дошел черед и до VServer, краеугольного понятия Clustered ONTAP. Даже за вычетом того, что нынче в начале термина “V” – значит Вендетта почти что зарегистрированная торговая марка VMware, сам по себе термин “VServer” – крайне неясен и несамоописывающ.

?? вот, я с радостью отметил, что в новых материалах NetApp наметилось новое переименование – VServer теперь SVM – Storage Virtual Machines. Я давно, объясняя людям то, как работает Cluster-mode, делал это через аналогию с куда более знакомым и понятным кластером VM в VMware VSphere. Отрадно видеть, что теперь одним инженерным непонятным термином в лексиконе NetApp стало меньше.

Опять же, это торит интересную тропинку к новому баззворду индустрии – Software-defined Storage.

Я бы хотел отдельно, и явно видимо для всех указать на существование отныне в блоге особого полиси на комментирование.

В этом блоге, как вы заметили, вы можете комментировать без регистрации (зарегистрироваться, впрочем, тоже можно). Однако обязательным условием для этого теперь без исключений будет предоставление в форме комментария реального email для обратной связи.
Сам этот email не публикуется в комментарии, и вижу его только я.

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

Очень редко я бываю вынужден поставить на премодерацию отдельных комментаторов. Обычно это результат несогласия их с другим основным правилом полиси комментирования этого блога: “ведите дискусию вежливо, уважительно, даже если придерживаетесь по обсуждаемому вопросу иных взглядов, и будьте аргументированны в высказываемых утверждениях.”.
Могу отметить, что за 6 лет существования этого блога, таких набралось всего трое, так что это случаи исключительные, что меня, надо сказать, радует. Значит моя аудитория все же состоит из джентльменов. :)

Что же касается “политики реального емайла”, то, прежде всего,
Обратите внимание, что иногда, в особенности если у меня будут сомнения по поводу того, что указанный в комментарии адрес pupkin@hotmail.com - ваш реальный, читаемый адрес, не удивляйтесь, если я на него напишу. ?? не обижайтесь если, не получив ответа, или получив mailbox does not exist, сочту вас спамером.

Кроме того, ряд явно фэйковых емэйлов, вида xxx@xxx.xxx или 123@abc.com, и прочее такое же, автоматически отбрасывается моим спамфильтром. Это значит, что даже если вы написали интересный комент, я смогу извлечь его из горы спама только когда (или вернее будет сказать “если”) вдруг зайду в папку spam, в которой у меня еженедельно скапливается по 250-300 комментов про ca$h l0ans v!agra c1al1s дeвчёнки с вeбкaми, и которые вы не видите только потому, что спам-фильтр в блоге не дремлет. Захожу я туда скорее случайно, и очень редко. Делайте выводы.

Если вдруг у вас возникнет вопрос “зачем?”, хотя, как мне кажется, вопрос “почему комментариям требуется подпись?” для джентльменов, из которых состоит моя аудитория, не должен возникать по определению, то ответ, думаю, будет всем прост и понятен. Также как я подписываюсь под всеми моими текстами, также и любому пишущему реплику в ответ не должно быть стыдно под своими словами поставить свою подпись, не правда ли, джентльмены?

Так как я теперь, стихийным образом (вернее будет сказать попустительством EMC, похоже положившим на продвижение VNX в русскоязычном интернете крупный дюймовый болт) являюсь, в некотором роде, неожиданно для себя, авторитетным источником информации про эту модель стораджей, будем пользоваться сим фактом. ?? сегодня вам очередной перевод из блога Recoverymonkey, с очередными укусами за жёппу ;).

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

Еще несколько предостережений про EMC VNX

http://recoverymonkey.org/2013/05/06/more-emc-vnx-caveats/.

Недавно, когда мне по работе пришлось столкнуться с конкурентным предложением нашим клиентам в виде системы хранения EMC VNX, я заметил, что EMC использует несколько утверждений для доказательства своего превосходства (или, хотя бы не отставания).

Я уже писал в недалеком прошлом вот эту статью (есть перевод, прим. romx), и сегодня я хочу углубленнее рассмотреть несколько аспектов. Обсуждаемые сегодя темы:

1. Эффективность хранения на VNX
2. Утверждение, что LUN-ы могут обслуживаться обоими контроллерами
3. Утверждение, что autotiering помогает в большинстве задач
4. Утверждение, что сторадж-пулы – это просто
5. Производительность thin provisioning
6. Новые снэпшоты VNX

Я буду указывать по каждому утверждению ссылки на актуальные документы EMC, а то иначе это ничем не будет отличаться от работы “маркетингового робота”.

Эффективность хранения на VNX

EMC любит утверждать, что на ее системах не требуется отдать 10% пространства в “налог” OS, как это требуется у NetApp (WAFL reserve, прим. romx). Однако, как утверждается по  ссылке рекомендации best practices указывают, что на autotiered pool, как минимум 10% свободного места должны быть всегда доступны на каждом из tier-ов, для обеспечения его нормальной работы.

Также присутствует минимально 3GB оверхеда на каждом LUN, плюс оверхед на метаданные, который вычисляется по формуле, приведенной в статье по ссылке. Плюс дополнительно метаданные, если вы используете дедупликацию.

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

LUN-ы могут обслуживаться обоими контроллерами, обеспечивая “load balancing”

Вот тут пошло веселье. Утверждается, что LUN ownership может быть мгновенно переключен с одного контроллера VNX на другой, чтобы обеспечить балансировку их загрузки. Ну, как всегда тут есть тонкости. Важно также отметить здесь, что на момент написания этого поста, в VNX не было никаких средств для организации автоматической балансировки LUN ownership в зависимости от загрузки контроллеров.

1. Если это делается с традиционными RAID LUN-ами: Передача LUN ownership делается без проблем. Это так, как было всегда.
2. Если же LUN находится в пуле – это история другая. Нет способа быстро переключить LUN ownership для такого LUN, без существенного влияния этого процесса на производительность системы.

Обильная информация по тому поводу может быть найдена здесь. Говоря коротко: Вы не можете менять LUN ownership, при использовании пулов, вместо этого вам придется перенести содержимое LUN, на другой LUN, на другом контроллере (именно на другой LUN, перенос LUN-а “как есть” может создать проблемы), в противном случае готовьтесь заплатить производительностью.

Утверждение, что autotiering помогает на большинстве задач

Не торопитесь. (в оригинале: “Not so FAST”, прим. romx). Собственные документы EMC, такие как “best practice guides” полны предупреждений и замечаний, относительно использования autotiering. Несмотря на то, что эта фича фактически пропагандируется в каждой кампании продаж, как создающее множество преимуществ гигантское достоинство.

Вот, например, очень подробный документ “EMC Scaling performance for Oracle Virtual Machine“, этот график найден там на странице 35:

Стрелки добавил я. Отметьте, что наибольшее преимущество в производительности достигается тогда, когда кэш правильно сконфигурирован с точки зрения сайзинга. Дополнительные 5 SSD для VNX tiering (FAST VP) почти не дают существенного повышения производительности на задаче с нагрузкой типа базы данных.

Можно только гадать, какой прирост дали бы эти 4 SSD, если бы были установлены не в autotiering, а увеличили бы кэш…

Быть может, если бы все 8 SSD были бы использованы как all-flash-storage, это было бы даже еще быстрее, чем 4 cache SSD и 5 tier SSD, но это просто лишний раз продемонстрирует слабый “замах” autotiering-а FAST-VP и недостатки его маркетинга.

Утверждение, что storage pools это упрощение работы со стораджем

Типичный подход сэйла EMC к пользователю для продажи VNX это: используйте единый, суперпупер-простой пул дисков с автотирингом данных на нем. Однако вопреки тому, что утверждает маркетинговое шоу, к сожалению, с использованием пулов VNX сложность снижается совсем не так, как это обещается, наприме просто потому что пулы рекомендуются совсем не для любой задачи и не для любой рабочей нагрузки. Рассмотрим типовой сцеарий развертывания VNX, смоделированный по документам best practice:

1. Журнальные LUN-ы RecoverPoint рекомедуется держать на отдельной группе RAID10
2. LUN-ы SQL log на отдельной группе RAID10
3. Exchange 2010 log LUN-ы на отдельной группе RAID10 
4. Exchange 2010 data LUN-ы могут находиться в пуле, но лишь в случае, если он состоит из однотипных дисков, в противном случае нужно использовать несколько традиционных RAID-групп
5. SQL data могут быть помещены на autotiered pool
6. VM могут быть на отдельном пуле, или жить совместно на пуле SQL
7. Репозиторий VDI linked clone может использовать SSD в отдельной группе RAID10

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

?? что получится, если вы отдали лишнего на диски под традиционные RAID-группы в примере выше? Как насчет вернуть или перераспределить это неиспользуемое там пространство другим задачам?

А что насчет варианта, когда места не хватает, как просто вам будет добавить немножко пространства или производительности? (Не в 2-3 раза, допустим, а всего на 20% больше). Сможете вы расширить традиционные VNX RAID-группы на несколько дисков?

?? как там насчет общей эффективности хранения, если все эти задачи нам придется держать отдельно друг от друга? Хмммм…

Для подробностей смотрите документы по дизайну хранилища под Exchange и SQL.

Производительность thin provisioning

О,это просто здорово. Производительность VNX thin provisioning сильно хуже в сравнении с thick, а они оба – в сравнении с традиционными RAID-группами. Проблема с производительнстью возникает прежде всего вследствие того, как VNX выделяет пространство при записи на thin LUN. При этом используются блоки, размером 8KB. Хорошее описание того, как распределяется пространство на сторадж-пуле можно найти здесь (у меня есть перевод, прим. romx). VNX пишет в пулы сементами, размером 1GB. Thick LUN-ы резервируют столько сегментов, размеров 1GB, сколько необходимо, и производительность получается вполне приемлемая. Thin LUN-ы не резервируют место, и, тем самым, не имеют возможности оптимизировать записи и чтения – в результате начинается фрагментация, вдобавок к более высокой загрузке CPU, дискового оверхеда, больше занимается памяти контроллера, все это для обслуживания thin LUN-ов.

Вновь смотрим документ по дизайну хранилища под Exchange 2010, страница 23:

Снова, стрелки на скриншоте, выделяющие важные моменты, добавлены мной:

1. Thin provisioning не рекомендован для высокой нагрузки на VNX
2. Конечно, он такой медленный сам по себе, что вы должны делать ваши thin pools хотя бы на RAID10!!!

Но погодите, thin provisioning придуман для экономии места на дисках, а теперь я должен использовать его на RAID10, который это место просто пожирает?

Какой-то нонсенс.

А что если пользователь желает повышенную надежность и, поэтому, хочет использовать RAID6 на весь пул? Как быстро с этим будет работать thin provisioning?

А, вдобавок у VNX нет способа устранить фрагментацию, которая бесчинствует на их thin LUN-ах. Только через миграцию на другой LUN.

Новые снэпшоты VNX

В VNX появился способ облегчить удар по производительности, присущий традиционным снэпшотам FLARE, перейдя от метода создания снэпшота COFW (Copy On First Write) на ROFW (Redirect On First Write).

Проблема?

Новым снэпшотам VNX требуется использование пулов и thin LUN-ов. Это кажется только технической особеностью, но…

Это те самые две фичи VNX, которые существенно понижают его производительность.

Есть и другие существенные проблемы с новыми сэпшотами VNX, но это тема другого поста. Так что ничего удивительного, что EMC проталкивает RecoverPoint гораздо активнее, чем свои снэпшоты…

??того

Существует маркетинг, и существует “инженерная” реальность.

Поскольку VNX может работать как с пулами, так и с традиционными RAID-группами, маркетинг мудро выбрал не слишком вдаваться в детали о том, что с чем там у него работает.

Реальность же состоит в том, что все новые фичи работают только с пулами. Но тут есть несколько весьма существенных засад.

Если вы рассматриваете вариант покупки VNX – по меньшей мере убедитесь, что понимаете, какая из проталкиваемых маркетингом фич будет работать для конкретно вашей задачи. Попросите сделать полную схему разбиения системы на LUN-ы (LUN layout).

?? опять же, мы никак еще не говорили про использование RAID-6 для защиты данных в пуле, это опять же отдельная история для отдельного поста.

D

Как вы уже, наверняка, знаете, после выхода версии ESXi 5.1, VMware объявила, что это будет последняя версия, поддерживающая “толстый клиент” vSphere. В дальнейшем поддержка традиционного, “толстого” клиента будет прекращена, и вся работа с vSphere будет происходить через так называемый Web Client UI, работающий в веббраузере.

Все бы хорошо, но есть существенная сложность – многочисленные, написанные вендорами плагины для VCenter, в частности NetApp Virtual Storage Console – VSC. Подобные плагины, для работы с системой хранения из интерфейса клиента VCenter, написали под свои стораджи почти все крупные вендоры. Но все они работают с “толстым клиентом”. По этой причине для тех, кто использует соответствующие стораджи, и управляет ими через пдобные плагины, наступают тревожные времена. Успеют ли соответствующие вендоры выкатить новые версии своих плагинов до того, как наступит время отказаться от “толстого клиента”?

NetApp пока неофициально объявил, что в среде Web Client UI будет работать новая версия VSC 5.0, она запланирована к выходу в конце этого года. Это будет существенно переработанная версия, что связано с тем, что изменяется сама логика работы и интеграции подобных плагинов. Так, например, ресурсы стораджа (контроллеры и VServers в Cluster-mode) будут интегрированы в стадартный inventory VCenter. Также, наконец, закончится процесс интеграции модулей VSC в “единое операционное пространство”.

Как вы, возможно, помните, нынешняя ситуация, с отдельными модулями Monitoring & Host Configuration, Provisioning & Cloning, Optimization & Migration, и Backup & Recovery, это отголосок того, что раньше VSC был надстройкой над несколькими различными продуктами, такими как SnapManager for Virtual Infrastructure (SMVI), Rapid Cloning Utility, и так далее, которые существовали отдельно, сами по себе, как отдельные продукты. Потом поверх них надстроили интеграционный плагин VSC, некую общую консоль, но продукты, тем не менее, еще долго оставались самостоятельными, даже когда они впоследствии вошли в состав VSC как его компоненты. Однако логически это разделение функциональностей по модулям еще сохранялось (и сохраняется сейчас), когда никакой физической разделенности на фактические модули за этим уже нет. Вот, наконец, в VSC 5.0 нам пообещали, что от этого намерены избавиться.

Кстати, кто в курсе темы, прокомментируйте, а у EMC уже есть плагин для VNX под VCenter Web Client UI?