about NetApp

К пользующимся у меня тут, судя по вебсатистике, бешеным спросом статьям о начальном запуске и настройке новых систем NetApp (часть 1 и часть 2), в закладки админу добавились в интернете новые тексты:

Настройка NetApp FAS – Часть 1 

(Описание контроллера FAS2040, возврат к заводским настройкам, базовая настройка файлера, настройка BMC, обновление Data ONTAP, NTP сервера).

Настройка NetApp FAS – Часть 2

(Multimode VIF и его виды, балансировка нагрузки, интерфейсы-партнер в кластере, псевдонимы aka IP Aliasing, flowcontrol и MTU, настройка Static и Dynamic VIF с  коммутатором Cisco Catalyst).

Настройка NetApp FAS – Часть 3

(disk ownership, raid group, aggregate, volume, qtree, lun).

Настройка NetApp FAS – Часть 4

(iSCSI, настройка iSCSI, безопасность iSCSI, iSNS)

Все это – в блоге http://twistedminds.ru.

Если вы интересуетесь темой, то сходите, посмотрите, может быть полезно. Автор раскрывает тему в несколько ином ключе, и пишет, например, гораздо больше о сетевых настройках и VIF, о которых я в своих постах “самого начала” не говорил (отчасти намеренно).

Ожидается продолжение. да и вообще заглядывайте туда, интересный ресурс.

UPD: Пока пост отстаивался в “отстойнике”, как это обчно и бывает с написанными мной текстами, автор удвоил количество своих постов на данную тему. Шоназывается “респект”.

Я не первый раз рубликую тут переводы постов инженера NetApp – Dimitris Krekoukias, ведущего автономный, и крайне интересный блог http://recoverymonkey.org/ (другие мои переводы его постов вы можете найти в рубрике “переводы”)

После долгого молчания, Dimitris опубликовал пост, вызванный публикацией отличных результатов кластера FAS6240 в Data ONTAP 8.1.1 Cluster-mode в бенчмарке блочного (FC) доступа – SPC-1, о котором я уже написал в понедельник. Однако вопросу почему он так хорош, и насколько именно он хорош – посвящен сегодняшний перевод.

NetApp опубликовал великолепные результаты тестирования Cluster-Mode в бенчмарке SPC-1

Опубликовано June 20, 2012

Мы тут в NetApp были довольно сильно заняты… заняты совершенствованием единственной в отрасли масштабируемой платформы хранения с универсальным доступом к данным, даже не считая множества разных других имеющихся в ней полезных штук.

Мы недавно выпустили ONTAP 8.1, которая, в Cluster-Mode, позволяет создать 24-узловой кластер (каждый узел которого может иметь до 8TB кэша) для задач NAS, и 4-узловой кластер для блочного доступа (FC и iSCSI).

А с выпуском ONTAP 8.1.1 (выпущенного 14 июня), мы увеличили лимит узлов для блочного доступа до 6, плюс добавили ряд дополнительных оптимизаций и возможностей. Между прочим, число узлов в кластере это пока только условный лимит официальной поддержки, это не жестко заданное ограничение.

После публикации нашего рекордного результата в бенчмарке NFS, люди спрашивали, как обстоит дело с производительностью блочного ввода-вывода в ONTAP Cluster-Mode, поэтому мы провели тестирование и опубликовали результаты бенчмарка SPC-1, используя часть той же системы, что уже была протестирована на SPEC sfs2008 NFS.

Для тех кто до сих пор думает, что NetApp не подходит для блочного доступа (это типичный FUD наших конкурентов): Это, на сегодня, лучший результат SPC-1 среди всех дисковых систем хранения, из расчета на уровень latency при достигнутом уровне IOPS (то есть возможно получить даже более высокие показатели IOPS на бОльших лимитах по latency, как я покажу далее в этом посте).

Вот ссылка на результаты и еще одна ссылка, на полную версию со всей доступной информацией.

В этом блоге я уже говорил о том, что представляет собой бенчмарк SPC-1 . Вкратце: Бенчмарк SPC-1 это общепринятый в индустрии, аудируемый, бенчмарк блочного доступа к системе хранения (по Fiber Channel) который проводит стресс-тестирование дисковой подсистемы большим объемом записей, перезаписей, локальных "хотспотов" и смешанной произвольно/последовательной, чтение-после-записи, запись-после-чтения нагрузкой. Около 60% рабочей нагрузки это операции записи. Размеры используемых в бенчмарке операций ввода-вывода различны, от маленьких до больших (таким образом IOPS в бенчмарке SPC-1 не идентичны и не могут быть сравнены напрямую с классическим тестом IOPS в full random блоками 4KB).

Если сторадж успешно работает на нагрузке SPC-1,, он, обычно, также крайне производительно работает на сложной, чувствительной к показателям latency, динамично изменяющейся нагрузке типа баз данных, в особенности OLTP. Полная спецификация для смертельно любопытных может быть найдена здесь.

Трюк с бенчмарками обычно состоит в интерпретации результатов. Сама по себе величина достигнутых IOPS, хотя и полезна, но не показывает всей картины, и того, как данный результат соотносится с реальной жзнью и реальными приложениями. Мы попытаемся помочь расшифровать результаты в этом посте.

Перед тем, как мы перейдем к анализу и сравнению результатов, несколько замечаний для неверующих:

1. В тестах NetApp не используется диски "с коротких ходом" (short-stroking), так часто любимые многими вендорами, проводящими тестирование, при котором используется только внешняя, наиболее быстродействующая часть диска, где сочетается максимальная линейная скорость и малый разбег механики коромысла жесткого диска, на чем можно показать наилучшие результаты. Вместо этого мы используем настройку параметров системы , чтобы использовать всю поверхность дисков, и не зависеть от того, насколько заполнены данными диски. Смотрите полный отчет здесь, страница 61. Для любителей распространять FUD: это эффективно "старит" состояние WAFL, приближая его к реальному состоянию реально эксплуатируемой системы. Мы также не используем оптимизацию размещения блоков путем их реаллокации.
2. Падения производительности в ходе продолжительного тестирования не наблюдалось.
3. Средняя величина latency (“All ASUs” в результатах) была плоской и оставалась ниже уровня 5ms на протяжении нескольких итераций теста, включая sustainability test в течение 10 часов (страница 28 полного отчета).
4. Не использовался дополнительный кэш, кроме того, который поставляется в базовой поставке FAS6240 (Контроллеры 6240 поставляются с Flash Cache емкостью 512GB, при максимальной возможной емкости данной модели 3TB на ноду (контроллер), то есть для работы с большими нагрузками есть еще значительный запас).
5. Это не "звездолет", построенный исключительно для завовевания победы и установления рекорда в бенчмарке. Мы использовали сравнительно немного дисков, в сравнении с конфигурациями других вендоров, и это не самая быстрая наша модель контроллера (еще есть 6280).

Анализ

Когда мы смотрим на результаты бенчмарка, следует сфокусироваться на следующих моментах:

1. Высокий уровень установившейся производительности в IOPS (нестабильность показателей показывает на наличие проблем).
2. IOPS/диск (это показатель эффективности – 500 IOPS/drive это вдвое лучше и эффективнее, чем 250 IOPS/drive, что, как следствие, означает меньше необходимых дисков в системе, снижает ее стоимость, уменьшает физический занимаемые в датацентре объем, и так далее.)
3. Стабильно низкая latency (пики показывают наличие проблем).
4. IOPS связан и зависит от latency (Получили ли вы высокие показатели IOPS вместе с высокой latency на максимуме? Это практически используемо?)
5. Какой тип RAID использовался (RAID6? RAID10? RAID6 обеспечивает значительно лучшую защиту данных и лучшие результаты эффективности использования дискового пространства, чем зеркалирование, что ведет к снижению стоимость даже более надежного хранилища данных).
6. Какие диски использовались? Хотите ли вы покупать такие диски?
7. ??спользовался ли autotiering? Если нет, то почему нет? Разве он не помог бы в такой сложной ситуации?
8. Какое оборудование потребовалось, чтобы получить стабильную производительность (сколько дисков и контроллеров потребовалось для построения системы? Означает ли это более сложную и дорогую систему? Как это все будет управляться?)
9. Цена (некоторые вендоры указывают цену уже с учетом дисконта, в то время как другие публикуют цену в list price, так что будьте тут внимательнее).
10. Цена/IOPS (наиболее полезная метрика – но следует сравнивать цену list price с list price).

SPC-1 это бенчмарк НЕ для измерения максимума потока данных; для измерения чистого GB/s смотрите другие бенчмарки. Большинство систем не дает больше 4GB/s в этом бенчмарке, так как много операций в нем рандомные (и 4GB/s это довольно много для рандомного ввода-вывода).

Сравнение систем

В этой части мы сравним дисковые системы хранения. Предсказуемо "чистые SSD" (или RAM) системы хранения имеют, конечно, очень высокие показатели производительности, и могут подойти, если ваша задача - обеспечивать работу с небольшим объемом данных очень быстро.

Но мы сосредоточимся на задачах высоконадежных систем общего применения, которые обеспечивают одновременно и высокую производительность, и низкую latency, и большую емкость, за разумную цену, а также, одновременно, большое количество функциональных фич(снэпшоты, репликация, кэширование в flash (megacaching), thin provisioning, дедупликация, компрессия, многопротокольность, включая NAS, и так далее). Опа – оказывается никто из конкурентов не может сделать сразу все что умеет делать NetApp.

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

• NetApp 6240
• IBM SVC with V7000
• IBM SVC with DS8700
• HDS VSP
• HP 3Par V800
• Huawei Symantec S8100

Также есть несколько других дисковых систем хранения, со значительными результатами по IOPS, но если мы посмотрим на их результаты sustained latency (“Sustainability – Average Response Time (ms) Distribution Data” в любом из полных отчетов) мы увидим, что общие показатели latency чересчур высоки и наблюдается значительная неравномерность, в особенности в начальной фазе, с пиками до 30ms (что крайне много), поэтому мы не взяли их в расчет.

Вот краткий перечень систем и их параметров, отсортированных в соответствии с latency. Кроме этого показана и их стоимость в ценах list price (это можно найти в полном отчете о тестировании) плюс стоимость операции $/IOPS, посчитанная исходя из list price (многие вендоры приводят в отчетах цену с уже введенной скидкой, чтобы цена выглядела пониже):

…но ведь тут показано, что некоторые системы быстрее NetApp… Как так?

Это зависит от того, насколько важен для вас показатель latency и его низкая величина (и от того, принимаете ли вы в расчет используемый тип RAID). Для подавляющего большинства нагрузок типа баз данных, низкая latency операций ввода-вывода гораздо предпочтительнее высоких показателей latency.

Вот как это увидеть:

1. Выберите один из приведенных выше линков на полные отчеты Допустим это будет 3Par, так как он показывает одновременно и высокие показатели производительности, и высокие значения latency.
2. Найдем в отчете главу под названием "Response Time – Throughput Curve". Например это страница 13 в отчете по системе 3Par.
3. Проследим, как latency резко растет при повышении загрузки системы.

Например посмотрим на кривую 3Par:

Заметьте то, как latency резко растет после некоей точки.

Теперь сравним с результатом NetApp (страница 13):

Отметьте, что результат NetApp не просто имеет хорошие показатели latency, но, что еще более важно, latency остается хорошей и растет исключительно медленно по мере увеличения нагрузки на систему.

Вот почему колонка“SPC-1 IOPS around 3ms” была добавлена в таблицу. Фактически это ответ на вопрос что бы было, если бы уровень latency был в тесте одинаков для всех протестированных систем?

Когда вы примете эту позицию, вы увидите, что система 3Par фактически медленнее, чем NetApp, если сравнить их на одинаково низком желаемом уровне latency.

Вы можете взять точные показатели latency из графика на странице 13, у NetApp таблица выглядит так (озаглавлено "Response Time – Throughput Data"):

Действительно, при сравнении результатов мы видим, что только IBM SVC (с кучей стораджей V7000 за ним) оказывается быстрее NetApp при столь же хороших показателях latency. Что плавно подводит нас к следующей главе…

Сколько железа обеспечивает такую производительность?

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

• 8 SVC контроллеров (virtualization engines) плюс…
• …16 отдельных систем V7000…
• …каждая состоящая из еще 2 контроллеров SVC и 2 контроллеров RAID
• 1920 дисков 146GB 15K RPM (не так-то просто такие купить нынче, не так ли?)
• ??того 40 контроллеров SVC (8 больших и 32 поменьше), 32 RAID-контроллера, и все это битком наполнено дисками.

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

Сравним эту кухню с вариантом конфигурации NetApp:

• 6 контроллеров в одном кластере
• 432 диска 450GB 15K RPM (самый распространенный и массовый наш диск по состоянию на июнь 2012).

Вопросы (с удовольствие увижу ответы на них от других вендоров):

1. Что произойдет при использовании RAID6 у других вендоров? NetApp всегда тестирует системы с использованием своей версии RAID6 (RAID-DP). RAID6 значительно надежнее, чем зеркалирование, особенно в больших пулах (не говоря уже о более эффективном использовании пространства дисков). Большинство клиентов не хотят покупать большую систему в конфигурации только-RAID10… (пользователи - задавайте вопросы вашим вендорам. Тут нет никакого волшебства – ручаюсь, у них есть внутренние результаты для RAID6, попросите показать их вам).
2. Autotiering это одна из самых раскрученных сегодня фич, с признаками того, что это достижение, превосходящее изобретение пенициллина, или даже колеса, а может даже и огня… Однако никто из дисковых массивов не рассматривает использование SSD для autotiering (IBM опубликовала однажды результат – не впечатляет, делайте выводы). Это при том, что бенчмарк, по своей спецификации активно создающий "горячие точки" (hotspots) нагрузки, должен бы быть здесь идеальным кандидатом для демонстрации эффективности…
3. Почему EMC и Dell не желают публиковать результаты SPC-1? (Они оба, кстати, члены SPC, Storage Performance Council). Только два этих вендора, из крупных игроков на рынке, кто еще не опубликовали свои результаты. EMC ранее говорила, что SPC-1 это нереалистичный тест – ну, типа только ваше приложение с вашими данными на вашем сторадже может показать по-настоящему реальные результаты. Это так, однако SPC-1 это общепринятый индустрией стандартный бенчмарк для блочного доступа произвольного характера, и отличная "лакмусовая бумажка".
4. Для системы, которая регулярно позиционируется для нагрузки Tier-1, IBM XIV, результаты бенчмарков, увы, отсутствуют также, даже для самой новой ее Gen3. Неужели IBM стесняется показать свои результаты SPC-1 для этой системы?
5. Наконец – некоторые наши конкуренты продолжают утверждать, что NetApp, дескать, это "не настоящий SAN", что это, якобы "эмуляция SAN", и так далее. Что бы это все ни значило на самом деле – может быть подход NetApp, с такой "эмуляцией" оказывается, по факту, лучше?… Максимальная write latency в этом тесте составила 1.91ms для в основном записываемой нагрузки!

??тоговые мысли

В накануне опубликованном результате бенчмарка SPC-1, NetApp показала вновь, что Data ONTAP в Cluster-Mode это высокопроизводительная и масштабируемая система, одинаково подходящая как для SAN, так и для NAS задач. Суммируя все вышесказанное, можно сказать, что ONTAP Cluster-Mode:

• Позволяет строить высокопроизводительные и динамически-масштабируемые кластеры хранения для FC, iSCSI, NFS и CIFS.
• Демонстрирует низкую latency при высокой производительности.
• Предлагает исключительно хорошее соотношение price/performance.
• Позволяет доступ к данным одной ноды с любых других нод.
• Перемещает данные между нодами, не прерывая работы с ними (включая CIFS, что ранее не было практически невозможно).
• Поддерживает традиционные для NetApp возможности (оптимизацию процессов записи, взаимодействие с приложениями, снэпшоты, дедупликацию, компрессию, репликацию, thin provisioning, и кэширование во flash (megacaching).
• Может работать на в точности тех же самых контроллерах FAS, что и в 7-mode, что защищает инвестиции.
• Может виртуализовывать системы хранения, расположенные за ними.

??сточник <http://recoverymonkey.org/2012/06/20/netapp-posts-great-cluster-mode-spc-1-result/>

На днях, NetApp официально опубликовал результаты бенчмарка SPC-1, главного бенчмарка по демонстрации производительности на блочном (SAN) доступе.

Как вы знаете, в Data ONTAP 8.1.x Cluster-mode появилась новая возможность – кроме доступа к системе хранения как к NAS, по протоколу NFS или CIFS/SMB, теперь возможна и работа с блочным стораджем, то есть как SAN-утройства. В версии 8.1 кластер SAN был ограничен 4 узлами (2 HA-парами), но, как я и предполагал, этот размер будет постепенно увеличиваться, и вот уже в 8.1.1 он был увеличен до 6 узлов (нод) в кластере. Напомню, что для NAS (NFS) максмальный размер кластера составляет 24 узла.

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

?? если для NAS NetApp достаточно давно показывал свои результаты в бенчмарке SPEC sfs2008, в том числе и для Cluster-mode, то для блочных протоколов, таких как FC или iSCSI, или FCoE, таких данных не было. А отсутствие результатов бенчмарков всегда тревожит, как же оно там, на самом деле, не на бумаге маркетинговых буклетов?

Наконец, на прошлой неделе, NetApp показал свои (почти)топовые результаты, для 6-узлового кластера, с использованием контроллеров FAS6240, под управлением Data ONTAP 8.1.1.

??нтересно, что бенчмарк SPC-1 требует публиковать цену тестируемой конфигурации (в терминах SPC-1 – TSC, Tested Storage Configuration), и, следовательно, вычислять параметр $/IOPS, “цену транзакции”. Но тут следует обратить внимание, что не запрещается искусственно занижать “листовую” цену продукта (например указав в цене уже некий “дисконт” относительно листпрайса), получая более “выгодно выглядящие” $/IOPS. Показатель $/IOPS приводится вместе с показателем IOPS, достигнутым на тестировании, даже в короткой версии результата, так называемом executive summary, в то время, как за полной конфигурацией тестируемой системы и за опубликованными на нее ценами, надо идти в full disclosure report.

NetApp на тестировании SPC-1 всегда приводит в качестве цены на систему полный, официальный листпрайс на момент тестирования, без дисконтов, и, что интересно, со включенным SupportEdge 24×7х4h на 3 года. Специально хочу напомнить, что листпрайс в реальной жизни не является реальной ценой продажи, так как в подавляющем числе случаев при продаже для конечного пользователя из цены вычитаются разнообразные, порой значительные, в десятки процентов, дисконты (скидки).

Поэтому если вы хотите просто тупо сравнить циферку $/IOPS системы одного вендора, с опубликованным $/IOPS у NetApp, обязательно посмотрите, исходя из какой цены было это значение вычислено, и, соответствующим образом, скорректируйте результаты.

18 июня 2012 года NetApp опубликовал официальный отчет о тестировании 6-узлового кластера в SAN, на протоколе доступа FC 8Gb/s и тестируемом объеме ~72TB (~193TB raw, 36% от raw), 432 диска SAS 450GB в 18 полках, показав результат 250 039,67 IOPS, и, при листпрайсе $1 672 602, показатель $/IOPS составил 6,69$/IOPS SPC-1.

За подробностями – в executive summary и в full disclosure report.

Несмотря на то, что современные модные тенденции в софтостроении требуют выпускать новую мажорную версию при списке whatsnew: [*] исправлена грамматическая ошибка в панели About программы, NetApp все же следует классической модели именования  изменения версий. Однако иногда эта консервативность, на мой взгляд, бывает даже чрезмерна, так, напрмер, между Data ONTAP 8.1 и 8.1.1 в функцональность были добавлены весьма существенные, важные и интересные штуки (про одну из них – Flash Pool мы уже говорили ранее). Так, например, это фича, под названием Infinite Volume. Не то чтобы это была сверхнужная для каждого возможность, но тема любопытная, и, возможно, читателям будет интересно узнать, чем же там занимаются, за закрытыми дверями отдела разработки Data ONTAP, и в какую сторону идет направление работ.

Infinite Volume – это новая возможность для кластерных систем (под Cluster-mode) NetApp, позволяющая строить очень большие тома, с доступом по NFS v3. На сегодня лимит для Infinite Volume это 20PB и 2 миллиарда файлов в одном “томе”, то есть в одном маунте (экспорте) NFS, на 10-нодовом кластере. Разумеется эти файлы распределены по множеству томов и aggregates нод кластера, но монтируются они при этом через одну точку монтирования. Таким образом, например, 200 томов по 100TB каждый, по 20 томов на каждой из 10 нод кластерной системы, будут смонтированы на сервера по единственному пути cluster:/vol/infivolume/, а не в виде 200 экспортов, на каждом из множества frontend-серверов системы, как это бы пришлось делать в “классическом” варианте.

Infinite Volume, как вы понимаете, это достаточно специализированное решение, ориентрованное на задачи секвентального чтения больших файлов, и сравнительно редкой их записи. Мне видится, что это задача похожа на что-то типа Youtube, или сходного функционала онлайнового файлового или видеохранилища, что-то такое, где себя сейчас хорошо чувствует EMC Isilon. Infinite Volume занимает нишу, в настоящий момент незакрытого в продуктах компании участка, разделяющего задачи систем E-series (бывших LSI/Engenio) и решений на его базе, подобных NetApp FMV solution и прочих StorNext с одной стороны, и “классических” FAS в Cluster-mode с другой.

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

Однако тут я слегка ошибся. Я продположил, что DS4486 будет сдвоенной по высоте полкой DS2246, то есть полкой для 2,5” дисков удвоенной высоты (и гадал, что за странную цель преследовали конструкторы такой необычной моделью).

Однако это оказалось не вполне так. Да, это действительно была полка c с интерфейсом SAS2 6Gb/s, для 48 дисков, высотой 4U, но не для 2,5"-дисков, а для 3,5"-дисков SATA!

А как же они там поместились? Оказывается для этого был придуман специальный хитрый “трей” на два диска, расположенных в нем друг за другом, “в глубину” . Спорная конструкция, но уж какая есть. ?? придумана она была для очень узкого сегмента сверхъемких систем, так как на сегодня полка DS4486 поддерживает только диски SATA 3TB, то есть самые плотные и емкие из имеющихся. Больше никаке другие диски для данной полки в настоящий момент не поддерживаются.

В результате можно создать систему, которая будет иметь емкость в 480 дисков 3TB в 19" шкафу 40U, что составляет около 1440TB, почти полтора петабайта в одном шкафу. Наверное кому-то такое пригодится, нельзя сказать, что многим, но все же.

Фото новой полки, а также вид нового трея пока я не нашел, но как только появится фото – покажу.

Полка поддерживается только новыми системами, и только в самой новой версии Data ONTAP – 8.1.1

Третья часть серии постов в блоге Wahl Network, посвященных вариантам использования NFS в Vmware и организаци балансировки трафика по нескольким физическим путям.

NFS в vSphere – погружение в детали: часть 3, VMware Load Balancing Teaming

В предшествующих трех постах этой серии мы рассмотрели основные ошибки и заблуждения, связанные с использованием NFS в VMware, а также рассмотрели два варианта построения сети хранерия с использованием NFS - с единой подсетью, и с множественными подсетями. Если вы не слишком хорошо знакомы с тем, как NFS работает в vSphere, рекомендую вам начать с чтения этих статей. Выводы, к которым мы пришли, состоят в том, что NFS в vSphere требует использовать множественные подсети, чтобы использовать множественные физические линки к системе хранения, за исключением, когда EtherChannel правильно настроен правильно используется на одной подсети. Однако, даже при использовании static EtherChannel, множественные таргеты на стороне стораджа, и правильно спланированные least significant bits в адресе необходимы для использования более одного физического пути к системе хранения.

Continue reading ‘VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming’ »

Я попросил одного пользователя NetApp, расположенного вне Москвы (с Москвой как раз все просто, и не слишком интересно  да?) поделиться информацией об оперативности работы службы сервиса NetApp. Как вы помните, стандартный сервисный уровень по доставке вышедших из строя запчастей у NetApp, это Next Business Day (NBD), что в условиях страны, растянутой на 9 часовых поясов и с отдаленными точками, куда “только вертолетом можно долететь”, представляет собой известный челлендж для любого сервиса.

Городок с населением 250 000 чел, 660 км Москвы, пользователь - крупное промпредприятие.

Вылетало за время эксплуатации системы три диска.

Далее выдержки из логов кейсовой системы NetApp по этому стораджу (форматирование потерялось, но не суть), я выделил даты событий, дата и время даны по калифорнийскому (PST) времени, в котором работает саппорт NetApp. Первая – регистрация события по отчету autosupport, второе – реакция человека в саппорте, командующего складу на отгрузку. Далее – когда запчасть доставлена на сайт фактически. Доставка производится со склада в Москве (и Петербурге).

1) Case #: 2xxxx Status:
Closed
Priority:
Occasional disruption or problem (P3)
Symptom:
DSKFLT:Disk /aggrsata/plex0/rg0/0a.19 Shelf 1 Bay 3 [NETAPP X269_SMOOS01TSSX NA01] S/N [9QJ7W7V4]
System Name: NETAPP2040-2 Bug #: Reference #:
Serial Number: 200000xxxxx Part Number: FAS2040-R5 System ID: 135xxxx OS Version: 8.0.1RC1 7-MODE AutoSupport: ON
Case text : Customer Input - 03/10/2012 12:52:00 PST
Visibility  : PUBLIC     Note :
I need help. My disk drive has failed. Help me. Send me new disk.
RMA  DSKFLT:Disk /aggrsata/plex0/rg0/0a.19 Sh - 03/10/2012 18:27:30 PST : WF_BATCH   Status: Delivered    Assigned To:  Ahamed Hussain
Update : ‘Return Order from PR ‘80009xxxx - 03/10/2012 22:15:59 PST : TPL_APL   Status: Closed    Assigned To:  Ahamed Hussain
1. We will ship one
SP-269A-R5
to replace the failed part. This part w ill be shipped to the following address and contact:

12 марта – диск у нас

2) Case #: 20027xxxx Status:
Closed
Priority:
Occasional disruption or problem (P3)
Symptom:
DSKFLT:Disk /aggrsas2/plex0/rg0/0d.01.10 Shelf 1 Bay 10 [NETAPP X410_S15K7288A15 NA00] S/N [3SJ0VS340000xxxxx]
System Name: NETAPP2040-2 Bug #: Reference #:
Serial Number: 200000xxxx Part Number: FAS2040-R5 System ID: 135xxx OS Version: 8.0.1RC1 7-MODE AutoSupport: ON
Update : Case text : Symptom - 12/24/2011 18:23:47 PST : ASUP_PP   Status: Assigned To:  RAI Ranjit Visibility  : PUBLIC     Note :
DSKFLT:Disk /aggrsas2/plex0/rg0/0d.01.10 Shelf 1 Bay 10 [NETAPP X410_S15K7288A15 NA00] S/N [3SJ0VS3400009034xxxx]
Update : ‘Return Order from PR ‘8000869583 - 12/26/2011 00:50:51 PST : TPL_APL   Status: Closed    Assigned To:  Kabra Mitesh Visibility  : PUBLIC

28 декабря – диск у нас.

3) Case #: 200275xxxx Status:
Closed
Priority:
Occasional disruption or problem (P3)
Symptom:
DSKFLT:File system Disk /aggrsata/plex0/rg0/0a.24 Shelf 1 Bay 8 [NETAPP X269_SMOOS01TSSX NA01] S/N [9QJ7WHD6] failed.
System Name: NETAPP2040-2 Bug #: Reference #:
Serial Number: 20000xxxx Part Number: FAS2040-R5 System ID: 13509xxxxOS Version: 8.0.1RC1 7-MODE AutoSupport: ON
Update : Case text : Symptom - 12/17/2011 14:33:21 PST : ASUP_PP   Status: Assigned To:  Dey Tanmoy Visibility  : PUBLIC     Note :
DSKFLT:File system Disk /aggrsata/plex0/rg0/0a.24 Shelf 1 Bay 8 [NETAPP X269_SMOOS01TSSX NA01xxx] S/N [9QJ7WHD6xxx] failed.
Update : ‘Return Order from PR ‘8000865813 - 12/19/2011 01:36:21 PST : TPL_APL   Status: Closed    Assigned To:  Rao Sandeep Visibility  : PUBLIC

21 декабря – диск у нас.

Отмечу –что все три диска вылетали на выходных, а NBD начинался в понедельник.

С батарейкой (питание для NVMEM, другой кейс. прим. romx) все печальнее – пришлось 2 дня сильно пинать саппорт (пороли чушь) через русский netapp, огромное спасибо Роману Ройфману и Денису Атаманенко за оперативную помощь и участие - короче, супер саппорт!

Вот такие результаты, по моему вполне неплохие, и приятный отзыв.

Отдельно хочу объяснить лишний раз то, как исчисляется в сервисе Next Business Day.

Во-первых, как я уже сказал выше, в стране российских размеров любая ограниченная временем доставка вынуждена учитывать самолетные расписания. Поэтому Next Business Day трактуется как Best Available Flight (ближайший самолет), это нормально, у UPS нет штата гарипоттеров на метлах, они вынуждены работать с рейсами гражданской авиации. Если на Краснодар есть 10 рейсов в день, а на, допустим, Салехард, только один рейс “Когалымавиа” в два дня, то это также накладывает свои возможности на сроки доставки, ничего тут не поделать. Смотрим реалистично на окружающий мир, да?

Во-вторых о том, когда начинается и когда заканчивается Business Day. Бизнес день начинается утром, в 8 утра, и заканчивается в 5 вечера. Если гарантийный эвент происходит после окончания рабочего дня (или не успевает  попасть в отгрузку в российский UPS до конца этого рабочего дня) , то он обрабатываетя, как произошедший в рабочее время следующего рабочего дня. Если поломка происходит в выходные, или, допустим, в 8 вечера в пятницу, то бизнес-день, которым будет начата реакция на данное событие, будет понедельник. Что, собственно, вытекает из названия Business Day. Соответственно Next Business Day для события, случившегося вечером в пятницу, будет вторник.

Также следует учитывать разницу в часовых поясах, время в кейсах саппорта NetApp дается по Стандартному Тихоокеанскому американскому времени (PST, GMT-8:00), так как головной офис расположен в Калифорнии. Однако поддержка для EMEA это Бангалор, ??ндия (GMT+5:30). Это смещение таже следует учитывать при исчислении Business Day, потому что если у нас рабочий день еще в разгаре, в Калифорнии (или ??ндии) он мог еще не начаться или уже закончиться, и они прочитают ваш кейс (и отдадут команду на отгрузку со склада) только когда наступит  рабочий день. Может повезти, но общее правило таково.

Если такой режим не устраивает – есть круглосуточный вариант (SupportEdge Standard и Premium, за деньги), но при этом помните, что и вы, в свою очередь, должны иметь круглосуточную службу, например, если запчасть приезжает в 4 утра в субботу, курьера надо встретить и запчасть у него принять, что логично, то есть 24х7 сервис требует такого же участия и вас. Оно логично, как мне кажется. Просто это надо хорошо осознавать заказывая такой уровень поддержки. ??ли же каждый раз договариваться с курьером службы доставки о переносе сроков. ?? нельзя, если у вас по кейсу выставлен priority – high, и индусы работники техподдержки сели решать вашу проблему, сказать им вечером пятницы, “чуваки, давайте, пока, у меня, там пиво, девки, рокенрол сегодня, давайте там, до встречи в понедельник”. В этом случае ваш кейс просто бросят, и вы будете его всю следующую неделю поднимать и требовать к себе внимания. Круглосуточная поддержка она с обеих сторон круглосуточная.

В общем, вот такие вот “вести с мест”. Спасибо пользователю за предоставленные материалы и возможность написать этот пост.

Ранее я уже интересовался темой, и писал аналгичный пост в 2010 году, с другими похожими примерами, и сходными результатами.

Продолжаем публикацию переводов серии постов в блоге Wahl Network, посвященных вариантам использования NFS в VMware.

NFS в vSphere – погружение в детали: часть 2, порты vmkernel и экспорты NFS в разных подсетях

Apr 27, 2012

Ранее мы уже рассмотрели некоторые ошибочные концепции относительно NFS в vSphere, а также убедились в том, как трафик NFS идет при использовании одной подсети. Сейчас давайте посмотрим, как трафик NFS в vSphere пойдет в случае использования множественных подсетей. Хотя мы говорим тут прежде всего о NFS, это все также применимо и в случае iSCSI, если для него не используется binding.

Continue reading ‘VMware и использование NFS: часть 3c – Трафик NFS в разных подсетях’ »

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

Не секрет, что с уходом крайне популярной в стране FAS2020 (популярной, прежде всего, за счет цены), и грядущем, вот уже в этом месяце, уходе из продажи FAS2040, в продуктовой линейке опять обнаружился слабый “левый фланг”. FAS2240-2 и FAS2240-4 это, конечно, прекрасные продукты, сами по себе, но они никак не укладываются в психологически важные для данного сегмента лимиты 10-15 тысяч USD.

При этом на рынке обострилась борьба именно в “дешевом” сегменте, в котором нынче заиграли почти все “гранды”, тут и EMC VNXe, и HP MSA2000 и P2×00, и Dell Equallogic PS4100 и Dell Compellent S30. Снизу же сегмент теснят из крайнего low-end и SOHO продукты, широко известные в определенных кругах, QNAP, IOmega и Synology, пытающиеся выбраться из своего “гетто” домашних торрентокачалок.

Поэтому сложившаяся ситуация с исчезновением предложения на “дешевом” конце не могла продолжаться слишком долго. ?? вот ситуация исправлена: FAS2220.

Собственно, зная номенклатуру и принципы именования моделей у NetApp, вы уже сами обо многом можете догадаться.

Это система “младше” FAS2240, но имеющая контроллер, построенный на той же платформе FAS2200. Разумеется, ради удешевления системы потребовалось чем-то пожертвовать.

В первую очередь, это возможность установки расширения, в контроллере FAS2220 не поддерживаются mezzanine card (по крайней мере на момент объявления системы, но “физически” эта возможность не убита, может быть решение и будет пересмотрено в будущем), на которой расположены порты 10G Ethernet или 8G FC. Зато остались 4 порта Gigabit Ethernet, которые были и на FAS2240, аналогично FAS2040. На HA-пару вы получаете 8 портов GigE, что, в общем, для бюджетного стораджа, вполне неплохо.

Во-вторых, корпус, хотя  представляет собой 2U модуль, не может быть переконвертирован в DS2246, как это можно сделать с FAS2240. В корпус можно установить 12 расположенных горизонтально дисков SAS или SATA (а также и SSD, в составе нового Flash Pool!). Однако, обратите внимание, что диски SAS по какой-то причине нельзя при будущем апгрейде снять и переставить в отдельную дисковую полку. Однако можно это проделать с дисками SATA и SSD.

Помните также, что вы не можете в один корпус включить диски SAS и SSD, так как интерфейс NetApp SSD в настоящее время SATA, а смешивать разные интерфейсы в одной полке нельзя. Таким образом, конфигурация с дисками SATA (и, возможно, SSD), плюс, при необходмости, SAS в полке расширения, в этом случае представляет наибольший интерес. Вы получаете емкое и недорогое хранилище, возможно ускоренное с помощью Flash Pool, плюс, при необходимости, производительное пространство на SAS во внешней полке. При необходимости апгрейда вы сможете перенести диски SATA (и SSD) в полки новой системы, сохранив данные, а дисковую полку просто переключить на новый контроллер, также с сохранением всех данных на них.

В третьих, следует помнить, что емкость новой сстемы составляет всего 60 дисков. Для некоторых, особенно в бюджетном сегменте это не “всего 60”, а “целых 60!”, тем не менее об этом нужно помнить. Это только 12 дисков в “голове”, плюс две полки DS4243 (24+24). Кому-то этого хватит на многое, а кому-то – нет. Здраво оценивайте перспективы роста вашей компании и ее требования к объемам и “шпиндельной” производительности системы.

Плюсы новой системы весьма значительны.

Во-первых это новый контроллер, идентичный FAS2240 по процесору (по-видимому) и по емкости кэш-памяти (6GB/контроллер). Это дает от 3х до 7х прирост производительности на операциях контроллера, по сравнению с FAS2020 (я специально отметил, что прирост контроллера за счет более производительного процессора возможен только для операций контроллера. Если вы используете FAS2020 c 12 дисками SATA, и его производительность ограничена bottleneck-ом этих дисков, то, конечно, просто за счет более быстрго процессора в контроллере 12 дисков быстрее не закрутятся.

Обратите также внимание, что минимальная версия Data ONTAP для FAS2220 – 8.1.1 (как 7-mode, так и Cluster-mode). Все, G7, то есть OS ветки 7.x, на нем не поддерживается.

Во-вторых это поддержка Flash Pool, то есть кэша на дисках SSD, поддержка которого появляется в ближайшие месяцы для систем хранения NetApp, что расширяет возможности очень хорошо принятого рынком Flash Cache, и позволяет использовать возможности кэширования во Flash даже для не поддерживавших Flash Cache систем 2240 и 2220.

В третьих, несмотря на то, что в FAS2220 нет 10G Ethernet, она будет поддерживать Cluster Mode, примерно как он поддерживался в FAS2040, то есть с использованием Gigabit Ethernet. Если вы ориентированы на Cluster mode, это может быть вам особенно интересно. ??спользование для Cluster Interconnect портов Gigabit Ethernet конечно влечет за собой некоторые ограничения, но сама возможность, например включить FAS2220 в качестве вспмогательной системы в “большой” кластер может быть полезна.

Емкость памяти, как и на 2240 – 6GB, из которых 1,5GB – NVMEM. Процессор, как и у 2240, новый Intel, 64bit, 2 процессорных ядра (4 ядра в HyperThreading), 1,7GHz. Для пары контроллров все это богатство, понятно, удваивается.

Модель лицензирования аналогична FAS2240. То есть ВСЕ протоколы в “базе”, плюс Data ONTAP Essentials. За допденьги SnapManager Suite (на все applications разом), SnapMirror, SnapVault, FlexClone и SnapRestore. Либо все разом в составе Complete Bundle по цене дешевле чем “поштучно”.

С “морды”, крышкой, система идентична FAS2240-2.

Под крышкой – 12 дисков, расположенных горизонтально.

Сзади – как FAS2240-2.