about NetApp

Итак, в прошлом посте этой темы я вкратце остановился на предыстории Data ONTAP 8.x Cluster-mode.

Еще в прошлом году я перестал в этом блоге называть “классическую” структуру из двух контроллеров в системах хранения NetApp “кластером”, с тем, чтобы вам было проще “переключиться”. Пару контроллеров под управлением Data ONTAP 7.x и Data ONTAP 8.x 7-mode следует правильно называть HA-pair (HA – High Availability), HA-парой, или, в крайнем случае, HA-кластером, ясно отделяя это от “кластера” в 8.x Cluster-mode. Словом “кластер” у NetApp теперь называется совсем иная структура. Дабы не путаться, буду следовать этому правилу именования и я.

В настоящий момент можно построить кластер, работающий как NAS-сервер (NFS или CIFS) из 24 узлов-контроллеров (nodes), то есть из 12 HA-пар контроллеров.

В версии Data ONTAP 8.1 появлась также поддержка блочных протоколов (iSCSI, FC, FCoE). Однако при использовании блочных протоколов (только их одних, или в комбинации с NAS) максимальный размер кластера на сегодня поддерживается в размере четырех нод, или двух HA-пар. Эта величина, как я думаю, будет расти, как только будет все отлажено и обеспечена надежность, все же 8.1 это первая версия с такой функциональностью, но пока – имейте это ввиду. Связано это, прежде всего, с тем, что файловые протоколы, такие как NFS или CIFS, по сути, полностью управляются и контролируются на стороне стораджа, и проще обеспечить все необходимые процедуры работы и синхронизацию процессов между узлами кластера.

Прежде всего, следует осознать разницу, между понятиями Global Filesystem и Global Namespace.  Data ONTAP 8.1 Cluster-mode это Global Namespace, но НЕ Global Filesystem.
Global Namespace позволяет вам видеть кластер и его пространство, как совокупность нодов его составляющих, как единую “сущность”, целостное пространство, вне зависимости от того где и как хранятся ваши данные. Однако с точки зрения хранения, каждый нод-контроллер, по-прежнему оперирует данными, хранящимися на его aggregates и томах. Один единственный файл не может располагаться более чем на одном aggregate/ноде-контроллере. Также он не может мигрировать, распределяясь частью на одном, частью на другом ноде-контроллере.

Это, как мне кажется, очень важно понимать, поэтому на этом я так заостряюсь.

Безусловно, устройства, реализующие Global Filesystem, имеют в этом месте меньше ограничений (например EMC Isilon с его OneFS это как раз Global Filesystem), однако, в нашем мире, как вы помните, ничего не дается бесплатно, и реализация Global Filesystem влечет за собой ряд весьма неприятных побочных негативных эффектов, в первую очередь для производтельности. Isilon весьма хорош, но он хорош на определенных типах рабочей нагрузки (преимущественно последовательном доступе). Насколько в вашем конкретном случае важна возможность хранить огромного размера файл(ы), превосходящие по размерам емкость дисков, подключенных к одному контроллеру, и распределенные на несколько узлов кластера, и готовы ли вы за такую возможность заплатить ухудшением характеристик рандомного доступа к ним – решать вам. На сегодня на рынке имеется как тот, так и другой вариант.

Преимущество же в производительности довольно убедительно показал NetApp в недавнем тестировании SPECsfs2008 на протоколе NFS, где 24-нодовая система FAS6240 под управлением Data ONTAP 8.1, почти в полтора раза превзошла 140-нодовую систему EMC Isilon S200.

При этом, следует отметить, что, в случае NetApp, тестировался worst case, “наихудший случай” то есть только 1/24 часть всех операций шла на контроллер-owner, 23 из каждых 24 операций шли через “неродные” контроллеры, через cluster network, и не использовались никакие существующие у NetApp средства оптимизации, такие как, например, Load Sharing Mirrors (RO-копии) на “неродных” узлах кластера, которые, безусловно, увеличат производительность в реальной жизни.

Напомню, что тест SPECsfs2008 это классический и авторитетный тест, имитрирующий усредненный типовой файловый доступ по протоколам NFS (и CIFS), сгенерированной смесью операций соответствующего протокола, и там, понятное дело, много операций с метаданными и, преимущественно, рандомный доступ.

Итак – Data ONTAP 8.1 Cluster-mode это Global Storage Namespace, но НЕ Global Storage Filesystem. Несмотря на то, что вы видите кластер как единую сущность, отдельный файл, на нем хранимый не может превышать емкость аггрегейта одного контроллера. Однако вы можете получать доступ к данным этого файла через любой из контроллеров кластера. В этом заключается разница между Global Filesystem и Global Namespace.

Второй момент, на котором мне хочется подробнее остановится, это то, как именно строится кластер физически.

Несмотря на то, что, формально, “единицей измерения” размера кластера является одна нода, представляющая собой один физический контроллер, ноды эти всегда включены в HA-пары. По этой причине количество нодов в кластере NetApp Data ONTAP 8.x Cluster-mode всегда четное. Таким образом обеспечивается надежность и высокая доступность (High Availability) ноды, тем же методом, как это делалось для контроллеров в 7.x.

Поэтому вы не можете сделать 5- или 15-нодовый кластер, а 4-, 6- или 16-нодовый можете.

Третий момент, который мне бы хотелось подробнее осветить, есть то, что в настоящий момент NetApp предъявляет довольно строгие требования к оборудованию для реализации кластерных коммуникаций. Для построения Cluster network, то есть внутренней сети самого кластера, в настоящий момент поддерживаются только две модели 10-Gigabit коммутаторов, это Cisco Nexus 5010 (20 портов, кластер до 12/18 нодов) и Cisco Nexus 5020 (40 портов, кластер более 18 нодов), их продает NetApp со своими партномерами, в составе общей квотации такой системы. Причем использовать эти коммутаторы можно только под задачи внутренней кластерной сети, совмещать их с другими задачами, например для подключения в них клиентской сети – нельзя. Даже если там еще остались порты.

Однако есть и хорошая новость. Сейчас NetApp и Cisco, в качестве time-limited promotion, при заказе cluster-mode стораджа у NetApp, отдает необходимое инфраструктурное оборудование за символическую цену 1$ за Cisco Nexus для Cluster network и Cisco Catalyst 2960 для Cluster management network, плюс необходимые SFP и кабеля. При этом цена на систему Data ONTAP 8.1 Cluster-mode из двух нодов, для промоушна, уравнена с ценой аналогичной конфигурации 7-mode, а инфраструктурная часть придет по цене 5$, за пять девайсов (два Nexus 5010, два Catalyst 2960, сет кабелей), плюс сервисные платежи.

Прежде чем у вас как следуют загорятся глаза и затрясутся руки “купить Нексус 5010 за один бакс”, я бы хотел отдельной строкой уточнить, что это предложение действует только для покупки системы cluster-mode, и, по условиям покупки, не может использоваться ни для чего другого.

Купленную по промоушну систему на две ноды можно расширить до 12 нодов (6 HA-pair) докупая только SFP и кабеля.

Структура cluster-mode кластера такова (на рисунке, для примера, показана двухузловая система):

В качестве коммутаторов клиентской сети можно использовать любые коммутаторы, Ethernet или FC, в зависимости от потребностей пользователя.

В качестве коммутаторов Cluster network switch могут использоваться только Cisco Nexus 5010 (для кластеров с числом нод до 12/18) или 5020 (для большего числа нод).

В качестве Cluster Management Switch NetApp рекомендует Cisco Catalyst 2960, но, в настоящее время, не обязывает покупать именно эту модель, при необходимости использовать имеющуюся у клиента иную модель, это может быть оформлено через заведение PVR, специального запроса на проверку и аппрув конфигурации у NetApp. NB: SMARTnet для такого свитча – обязателен!

Cluster Network это выделенная только под эту задачу сеть 10Gb Ethernet. Единственное исключение – FAS2040, которая может использоваться в Cluster-mode с использованием Gigabit Ethernet, но не рекомендуется ее использование с другими контроллерами. Обратите внимание, что даже для 2040 и ее Gigabit Ethernet, другие коммутаторы, кроме Nexus 5010/5020, не поддерживаются!

Ноды кластера могут быть различными по модели. Вы можете объединить в единый кластер любые контроллеры, для которых объявлена совместимость с cluster-mode (с единственным исключением в виде FAS2040, использование которого с контроллерами другого типа не рекомендуется (хотя и возможно), по вышеописанной причине отсутствия портов 10G)

Вы также можете объединить в кластер и системы с дисками различных типов, например вы можете построить систему с дисками SAS, SATA и SSD в рамках одного единого кластера, и организовывать миграцию данных между разными колнтроллерами-нодами и дисками разных типов.

Далее кратко и бегло:

Какие контроллеры в настоящее время поддерживаются для работы в Cluster-mode?

FAS/V62×0, FAS60×0, FAS/V32×0, FAS31×0, FAS3070, FAS3040, FAS2240, и FAS2040.
Для 2040 есть ограничения, связанные с отсутствием 10G Ethernet, для 3040 и 3070 ограничено максимальное количество нодов в использующих их кластеров. Помните, что для работы Cluster-mode нужна пара портов 10G Ethernet и несколько дополнительных портов для сетевых интерфейсов cluster management и сети собственно доступа к данных с клиентов.

Какие возможности “традиционной” Data ONTAP 7-mode поддерживаются, и какие – не поддерживаются?

Поддерживаются:

• Доступ к данным по:
  • файловым протоколам (NFSv3, NFSv4, NFSv4.1/pNFS, CIFS(SMB1.0), SMB2.0 и SMB2.1), c размером кластера до 24 нодов.
  • по блочным протоколам (iSCSI, FC, FCoE), с размером кластера до 4 нодов (кроме FAS2040, FAS3040/3070 и FAS6030/6070, для них SAN в cluster-mode не поддерживается) .
• Репликация SnapMirror – только асинхронная и только Volume SnapMirror. Репликация совместима только между системами Cluster-mode.
• Снэпшоты
• Компрессия и дедупликация
• FlexClone
• NDMP

Не поддерживаются:

• Синхронный SnapMirror, Qtree SnapMirror (сами qtree как объект иерархии поддерживаются), SnapMirror между системами 7-mode и cluster-mode
• SyncMirror
• Metrocluster
• SnapVault
• SnapLock
• IPv6

Каковы основные преимущества и цели системы Cluster-mode?

• Балансировка и масштабирование для больших нагрузок
• Непрерывающее работу наращивание производительности и миграция данных
• Единая, с точки зрения управления и администрирования “сущность” – кластер нодов.
• Поддержка привычных средств и фич NetApp – RAID-DP, FlexClone, Snapshots, SnapMirror Async, дедупликация, компрессия.

Что такое Vserver?

Оставайтес с нами, об этом – в следующих постах :)

Есть/будет ли FlexPod под Cluster-mode?

Пока – нет, но, возможно, будет.

Какие диски и полки поддерживаются?

Все, любые существующие на сегодня в продаже (не поддерживается интерфейсный модуль ESH2 и еще более старые).

Можно ли включать в кластер системы V-series и сторонние стораджи через них?

Да, можно V3200/6200 c EMC DMX4, CX4 и HP EVA. Остальные, может быть, через PVR. Однако даже для перечисленных систем нужна полка с дисками NetApp для хранения root volume.

Каков максимальный размер aggregate?

• 2040/3040/3070 – 50TiB
• 2240 – 60TiB
• 3210/3140 – 75TiB
• 6030/6040/3270/3170 – 105TiB
• 6070/6080/6210/6240/6280 – 162TiB

Каков максимальный размер тома?

Как максимальный размер 64-bit aggregate в 7-mode для соответствующих контроллеров

Каково максимальное расстояние “разноса” нодов кластера?

Максимальное допустимое расстояние от ноды до коммутатора cluster network – 300 метров.
Расстояние между redundant коммутаторами cluster network – 300 метров.
Расстояние между двумя нодами в HA-паре – то же, что и для 7-mode.

FlashCache поддерживается?

Да!

Есть ли non-disruptive upgrade для систем 7-Mode?

К сожалению – нет. Только через полную разборку-сборку.

Есть ли non-disruptive expand или reduce для кластера новыми нодами?

Да.

Можно ли слить вместе два кластера?

В настоящий момент нет, только через копирование, разборку второго и добавление его нод.

Нужен ли коммутатор для Cluster network в случае использования всего двух нод в кластере?

Да, все равно нужен даже для всего двух нод.

Работают-ли на Cluster-mode системах дедупликация, компрессия, thin provisioning, снэпшоты?

Да, все это работает.

Каким образом можно управлять кластером в Cluster-mode?

• GUI: NetApp System Manager 2.0
• CLI: SSH к кластеру, ноде или Vserver
• OnCommand 5.0
• NetApp Management SDK

FilerView (web-интерфейс, встроенный в контроллер) начиная с 8.1 не поддерживается.

Должен ли я управлять каждой нодой в отдельности?

Нет, кластер управляется как целостная сущность, без разделения на ноды. Каждая нода, при включении в кластер, получает и наследует глобальные настройки данного кластера.

Как обеспечивается антивирусная защита хранимых данных для кластера?

Тадааам! Теперь у Data ONTAP есть встроенный в OS движок антивирусного контроля и защиты. В настоящий момент лицензированы продукты Sophos и McAfee

Больше о работе и управлении в кластере – в следующем посте этой серии.

Я уже писал про то, что такое OnCommand – новое объединяющее семейство софта производства NetApp. В него входят (и называются теперь OnCommand что-нибудь) как ранее известные продукты, так и вновь разрабатываемые, а также недавно приобретенные компанией.

Таким образом, OnCommand это не новый продукт, это новое общее название  для уже существующих (и будущих) продуктов, название программного семейства. Часть продуктов, в него входящих, является бесплатным, часть – платным, и лицензируемым по разному.

Все семейство делится на три основных области использования:

• Control – управление системами хранения NetApp
• Automate – автоматизация, представлена продуктом OnCommand Unifed Manager, и занимается серверной автоматизацией, созданием и применением политик, SLA.
• Analyze – анализ и оценка работы, которой знимается продукты OnCommand Insight. Анализ производительности, конфигураций, емкости для NetApp и других систем.

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

Control

OnCommand System Manager – установка и первоначальная настройка новой системы хранения, а затем управление отдельно взятым контроллером/системой. Бесплатно.

OnCommand My Autosupport – web-based инструмент для оценки состояния здоровья, рисков, емкости и эффективности работы системы хранения. Бесплатно при наличии действующего контракта поддержки.

OnCommand Report – создание настраиваемых отчетов о работе системы хранения.  Бесплатно.

Automate

OnCommand Unified Manager – ранее три продукта: Operations Manager, Protection Manager и Provision Manager. Построение централизованного RBAC, мониторинга, службы уведомлений и отчетов. Разработка политик защиты данных на системе хранения. Автоматизация процессов распределения емкости на системе. Бесплатно.

Virtual Storage Console – ранее так и существовала под этим названием, но теперь формально входит в семейство OnCommand Automate. Позволяет администраторам виртуальной инфраструктуры создавать и распределять датасторы для VMware ESX непосредственно из интерфейса vCenter, упрощает и оптимизирует настройку системы хранения. Бесплатно.

SnapManager product suite – также хорошо известное семейство, теперь входит в OnCommand Automate. Упрощает создание автоматизированных application-consistent backup, уменьшает RTO приложений. Лицензируется либо на контроллер (unlimited hosts), либо по хостам.

Workflow Automator – Обеспечивает разработку процедур workflow в сложных случаях, которые не под силу Provisioing Manager. Бесплатно, но требует поупки услуг Professional Services.

Analyze

OnCommand Insight Discover – бывший SANscreen Service Insight. Необходимый компонент для работы идущих ниже продуктов Assure, Perform, Plan. Лицензируется по емкости  raw TB.

OnCommand Insight Assure – бывший SANscreen Service Assurance. Полный обзор всей IT-инфраструктуры в деталях, того, каким образом инфраструктура поддерживает приложение. Анализ областей повышенного риска для системы и приложений. Обнаружение “заброшенных” и неиспользуемых ресурсов в системе. Интеграция CMDB/ITIL. Лицензируется по емкости raw TB.

OnCommand Insight Perform – бывший SANscreen Application Insight. Анализ и настройка необходимых уровней хранения с точки зрения производительности, поиск источников проблем с производительностью. Лицензируется по емкости raw TB.

OnCommand Insight Plan – бывший SANscreen Capacity Manager. Планирование и отчет по емкости хранения для всей IT-инфраструктуры компании, учет расходов емкости, динамика, отчеты  о расходовании пространства. Лицензируется по емкости raw TB.

OnCommand Insight Balance – бывший Acorri BalancePoint. Глубокий анализ вопросов производительности виртуальной машины, углубленный на уровень ее OS и работающих в ней приложений. Оптимизация рабочих нагрузок виртуальной серверной инфраструктуры. Лицензируются системы серий FASx2xx  - на контроллер, старые FAS или сторонние стораджи – по емкости usable TB.

Дополнительно к трем перечисленным подсемействам следует упомянуть “объединяющий” их продукт управления – NetApp Manageability SDK, обеспечивающий программный интерфейс управления всеми продуктами OnCommand, и позволяет сторонним компаниям встраивать поддержку софта семейства OnCommad в свои продукты, или строить программные функциональные надстройки над теми или иными продуктами.

Некоторые новости с прошедшего в Риме NetApp Insight 2011, главного мирового мероприятия NetApp, на котором, обычно, представляются все новинки года. На этот раз я обратил внимание на объявленную любопытную технологию, которая появится в Data ONTAP 8.1.1, под названием Hybrid Aggregate.
Вот что это такое.

Как вы знаете, NetApp использует flash, прежде всего, в форме “расширения кэш-памяти”, а не как “эмуляцию диска” – SSD – Solid State Disk, у такого решения множество преимуществ на практике, и широкий успех Flash Cache, устройства для систем хранения NetApp, представляющего собой плату с 256/512/1024GB flash на ней, и устанавливаемую внутрь контроллера FAS3200/6200, тому подтверждение.

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

Hybrid Aggregate это, как нетрудно догадаться из названия, “составной” aggregate, состоящий из обычных “врашающихся” дисков и SSD. В такой структуре диски SSD обеспечивают “кэш на запись” для традиционных, “вращающихся” дисков в составе этого aggregate.

Основные отличия Hybrid Aggregate от Flash Cache следующие:

• Работает в том числе и на запись. В тех случаях, когда характер нагрузки системы пользователя представляет собой, преимущественно, большое количество операций записи сравнительно небольшими блоками, Flash Cache неэффективен, так как практически не ускоряет записи (в определенной степени он их ускоряет, но только за счето того, что, высвобождая ресурсы дисков за счет кэширования чтения, оставляет больше на обработку операций записи). Следует отметить, что рабочая нагрузка, представляющая собой, главным образом, объемный random write мелкими блоками, это довольно специфическая и не слишком массовая задача.
• Hybrid Aggregate может быть несколько на одной системе, каждый из них может быть настроен индивидуально и независимо от других. Flash Cache работает на все aggregate разом, хотя и можно политиками FlexCache настроить приоритеты и политики кэширования для разных томов.

Как мне видится, преимущества от Hybrid Aggregate получат прежде всего большие и очень большие системы, с сотнями дисков, с большими aggregates и очень большим трафиком ввода-вывода, или же системы со специфической рабочей нагрузкой (большой объем преимущественно записей мелкими блоками), кроме того следует помнить, что Hybrid Aggregate не исключает использование и Flash Cache, он вполне может использоваться вместе с Hybrid Aggregate на той же системе. Таким образом, появление Hybrid Aggregate не стоит трактовать как “отказ от Flash Cache” (я специально делаю это замечание для “паникеров” ;) или признание его неэффективности, это, скорее дополнение в ранее незакрытом сегменте рабочих нагрузок и специфических решений.

Объявлены новые, последние розничные цены на преконфигуренные бандлы FAS2020.

И хотя 2020 это совсем не “звездолет”, это все же вполне себе NetApp, и для многих применений он может вполне удовлетворительно подойти.

Обратите внимание, что откладывать покупку уже времени нет, это последние FAS2020, “распродажа товарных остатков”, с ноября месяца официально “младшим” в семействе FAS2000 назначен FAS2040, который мощнее, но и дороже. Если вы хотели 2020, то вот время купить его. Это задняя цена и заднее не бывает :)

В бандлы включена фиксированная конфигурация на 1 или 2 контроллера, и 12 дисков разной емкости, а также набор лицензий на функциональность, гарантия на “железо” на 3 года, с доставкой замены в режиме Next Business Day, а также трехлетняя попдписка на обновления ПО (SSP – Software Subscription Program) и сопровождение систем (техподдержка через сайт now.netapp.com / support.netapp.com).

В состав лицензий входят:

• все доступные протоколы доступа: CIFS, NFS, iSCSI, FCP
• Base pack – основной набор функциональности, такой как:
  • Snapshots – до 255 снэпшотов на каждый том, не влияющих на производительность
  • Thin provisioning не зависящий от хост-OS
  • Дедупликация – блочная, с размером блока 4KB
  • SyncMirror – синхронная репликация как внутри, так и между системами по IP
• Wndows bundle это Base pack плюс :
  • SnapRestore – быстрое восстановление тома целиком из снэпшота
  • SnapVault – D2D backup
  • SnapMirror – асинхронная/синхронная/полусинхронная репликация по IP
  • SnapManager – семейство продуктов для создания консистентной резервной копии в снэпшоте и восстановления из нее для MS SQL Server, MS Exchange, MS Sharepoint, Oracle DB, SAP, VMware ESX и MS Hyper-V.
  • SnapDrive – средство создания и управения снэпшотами на системе хранения с хост-OS (сервера) для Windows и UNIX/Linux.
  • NetApp DSM – Device-specific module для Windows MPIO.
• Complete bundle это все перечисленное выше, плюс еще несколько лицензий:
  • FlexClone – возможность создавать томы-клоны данных
  • Multistore – создание независимых “виртуальных систем хранения” внутри одной физической
  • SnapLock – средство неизменяемого хранения данных (WORM – Write-once, Read-many)

Перечисленные бандлы по новым ценам доступны к заказу партнерами у дистрибуторов, цены со склада в Москве и включают в себя НДС.

Позволю себе также некоторые пояснения и уточнения тут привести.

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

Если вы не будете гнаться за эфемерностью “кластерной отказоустойчивости” и “отсутствию единой точки отказа™” а предпочтете одноконтроллерную конфигурацию, то вы можете получить больше места и бОльшую производительность за меньшие деньги. При этом, напомню, все системы NetApp поставляются с трехгодичным гарантийным сервисом по “железу” уровня NBD onsite delivery, и это в самом деле NBD – Next Business Day delivery (не просто “время реакции”). NBD = Next Available Flight для территорий “вне Москвы”, по понятным причинам. Это значит, что в случае выхода из строя контроллера, замена для него будет доствлена на следующий рабочий день.

Помните также, что диск “на один миллиард байт”, с маркетинговым названием “1TB”, в реальной жизни меньше на 9,96% (за счет разницы между двоичной и двоично-десятичной арифметикой), а так как NetApp использует для ряда внутренних функций увеличенный сектор, то диск “1TB” будет иметь “полезный” объем 827,6Gib, а “2TB” – 1655,7GiB, именно исходя из этих величин и надо считать usable space системы хранения.

Давайте, для примера, посчитаем.

12 дисков “1TB”, физической реальной емкостью 828GiB. Один диск на HotSpare, два – на RAID-DP parity. Так как для SATA допустимый размер RAID-группы типа RAID-DP равен 16, то мы можем все оставшиеся диски поместить в одну группу, и распараллелить ввод-вывод по ним всем, минимально потеряв на дисках parity. 12 дисков – 1 Hot Spare – 2 parity = 9 дисков

827,6GiB x 9 = 7452 GiB – 10% WAFL overhead = 6703 GiB usable space для ваших данных, пока без учета дальнейшего возможного выигрыша от deduplication, thin provisioning и snapshots. При этом ввод-вывод вашей задачи будет параллельно осуществляться на все 9 дисков системы хранения.

При этом в случае двухконтроллерной конфигурации вы будете вынуждены из 12 дисков отдать два hotspare (каждому контроллеру свой) и два раза по 2 на RAID parity. В результате вы получите всего три диска под данные на каждом из контроллеров. Очевидно, что это не только уменьшит доступную емкость, но и снизит возможное быстродействие, так как ввод-вывод буде распараллеливаться на втрое меньшее число дисков (3 против 9).

827,6GiB x 3 = 2484GiB – 10% WAFL overhead = 2234,5GiB usable space на каждом из двух контроллеров, то есть:
2234,5GiB х 2 = 4469GiB на обоих, на тех же дисках, при использовании двухконтроллерной конфигурации.

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

Так что выбирайте, но острожно, но выбирайте :) И помните, что это последняя возможность купить FAS2020.

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

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

Хотя эта функциональность появилась еще в Data ONTAP 8.0.1, она все еще не слишком известна и не слишком широко используется, отчасти из-за некоторых ограничений, а, по большей части, все же из-за малознакомости “широкому кругу” юзеров NeApp.

Слегка сокращенный мной перевод статьи из TechONTAP возможно позволит кому-нибудь повнимательнее присмотреться к этой новой возможности систем хранения NetApp.

Что такое DataMotion for Volumes?

DataMotion for Volumes это новая возможность, появившаяся в Data ONTAP 8.0.1 7-Mode. Она позволяет вам переносить, не прерывая работы с ними, LUN-ы на томах с одного aggregate на другой, в пределах одного контроллера системы хранения (нельзя перемещать тома между разными контроллерами, например составляющими HA-пару). DataMotion for Volumes может быть использован для миграции томов, содержащих LUN-ы с “блочным” доступом по FC, FCoE, или iSCSI. Не поддерживаются “файловые” тома, с доступом по NFS или CIFS.

Рис. 1 NetApp DataMotion for Volumes позволяет вам не прерывая доступа переносить данные LUN и его том на другой aggregate, на том же контроллере NetApp.

Ключевой особенностью DataMotion for Volumes является то, что также переносятся все детали, связанные с томом:

• Снэпшоты и их расписание
• Настроенные отношения SnapMirror®, SnapVault®, и MetroCluster™
• Настройки Thin provisioning
• Состояние дедупликации (для продолжения работы дедупликации для новых данных необходимо восстановить базу фингерпринтов на новом aggregate путем запуска полного сканирования)

Вы можете перемещать данные между любыми типами дисков, подключенных к контроллеру. Например, вы можете перемещать данные с aggregate на дисках FC или SAS на aggregate, состоящий из дисков SATA, и наоборот. В текущем релизе (8.0.1) вы не можете перемещать данные между разными типами aggregate (“32-bit” и “64-bit” aggregates).

Как работает DataMotion for Volumes?

DataMotion for Volumes использует хорошо известную технологию NetApp SnapMirror для миграции данных тома. Весь процесс делится на три фазы:

• Setup
• Data copy
• Cutover

В фазах setup и data copy, исходный том продолжает обслуживать операции ввода-вывода без их прерывания.

Рис.2 "Циклограмма" процедур DataMotion for Volumes.

Фаза Setup

В фазе setup, производятся важные предварительные проверки, чтобы убедиться, что вся процедура может быть выполнена успешно. Эти проверки проходят каждый раз, когда DataMotion for Volumes запускается, и проходят вторично, когда начинается фаза cutover.

Проверка анализирует состояние всех объектов (исходного тома, aggregate на котором располагается исходный том, и aggregate-получатель) участвующих в перемещении. Если какая-то из проверок пройдет неуспешно, вы будете уведомлены и процесс не будет запущен. Все ошибки, выявленные проверками, будут выведены в консоль и записаны в лог-файл root-тома (/etc/log/ndvm).

Если все предварительные проверки пройдены успешно, процесс DataMotion for Volumes:

• Создает временный том на aggregate-получателе, с именем, сформированному по следующему правилу: ndm_dstvol_<timestamp>
• Запускает начальную (baseline) передачу, устанавливая репликацию SnapMirror между источником и получателем в виде созданного выше тома. Это самая длительная фаза; длительность ее прямо пропорциональна размеру исходного тома, так как требуется передача всего его содержимого.

Фаза Data Copy

После того, как будет проведена репликация уровня baseline, начинается фаза data copy, during which successive SnapMirror updates are initiated to synchronize the destination volume with the source, which remains active. По завершении каждого успешного обновления репликации SnapMirror, DataMotion for Volumes оценивает так называемый delta lag между двумя томами. Вы получите уведомление о величине delta lag, который будет оценочным временем для следующей операции обновления. DataMotion for Volumes остается в фазе data copy так долго, пока величина delta lag остается высокой. Когда величина delta lag уменьшается, система переходит к фазе cutover.

Фаза Cutover

Процесс фазы cutover может быть выполнен вручную, или автоматически ( по умолчанию - автоматически).

Период Pre-cutover. DataMotion for Volumes переходит к фазе cutover на томе-получателе, если том-получатель может быть полностью синхронизрован в заданный интервал, называемый “окно cutover”. Фаза pre-cutover это период времени, в который проводятся предварительные проверки описанные выше, и проводятся важные проверки состояния NVLOG и уровня загрузки CPU.

Вы можете задать пороги использования CPU и диска (в процентах) для выполнения операции DataMotion for Volumes. (по умолчанию порог задан в 100 для обеих опций):

vol.move.cutover.cpu.busy.limit
vol.move.cutover.disk.busy.limit

Автоматический Cutover. Когда все проверки фазы pre-cutover проходят успешно, фаза cutover начинается автоматически. Процесс cutover должен уложиться в окно длительностью 60 секунд. Когда том-получатель полностью синхронизирован, идентификатор тома-источника переносится на том-получатель, и операции ввода-вывода продолжаются с системы-получателя.

В ходе фазы cutover выполняются следующие действия:

• Все LUN-ы на томе-источнике переводятся в режим задержанных операций ввода-вывода (quiesced). Состояние quiesced препятствует поступлению новых операций ввода-вывода к LUN, при этом опустошается (и не пополняется новыми операциями) текущая очередь операций с данным LUNом.
• Операции на исходный том приостанавливаются (quiesced). Как часть этой операции приостановки, последняя "дельта" (разностная часть) фиксируется в снэпшоте, который называется ndvm_final_<timestamp>.
• Том-получатель полностью синхронизируется с томом-источником с учетом полученной "дельты" из снэпшота ndvm_final_<timestamp>. Это будет последняя порция репликации SnapMirror между двумя томами, перед тем, как операции ввода-вывода будут переданы на том-получатель.
• Временный том на получателе переименовывается в соответствии с именем тома-источника и его file system ID (FSID), и наоборот; то есть идентификаторы тома-источника и временного тома меняются местами.
• Перенесенный на получателя том переводится в онлайн с идентификаторами исходного тома и LUN становятся активными.
• Исходный том удаляется (если вы не задали в параметрах его сохранить).

Неудачный автоматический Cutover. Если процесс cutover завершается неудачей, DataMotion for Volumes пытается повторить фазу data copy и пробует еще раз некоторое время спустя (делается три попытки выполнить cutover). Если ничего не удалось, то процесс cutover прекращается, и операции ввода-вывода возобновляются на том-источник. Для продолжения работы DataMotion for Volumes требуется вмешательство оператора.

Ручной Cutover. В случае выполнения cutover в ручном режиме, DataMotion for Volumes остается в фазе data copy, продолжая выполнять репликации SnapMirror. В ходе этих репликаций он записывает их результаты в лог, и ориентируясь на эти данные вы можете самостоятельно выбрать момент для проведения ручного cutover.

Возможные области применения

Существует несколько областей, где может применяться DataMotion for Volumes.

• Балансировка нагрузки. Переместите том с нагруженного aggregate на менее загруженный.
• Балансировка емкости. Переместите том с заполненного aggregate на тот, где больше доступного пространства.
• Перенос данных со сторонних дисков на диски NetApp в системе V-series. Если вы используете NetApp V-Series как front-end к дисковому массиву стороннего производителя, вы можете воспользоваться DataMotion for Volumes для миграции этих данных на диски NetApp на этом контроллере V-series.
• Изменение типа дисков. Переместите том с дисков одного типа на другие. Например с дисков FC на SAS или SATA.

Использование такого способа для непрерывающего работу переноса данных с дисков FC, выходящих из употребления, на диски SAS, может помочь для критически-высокодоступных систем обеспечить нужный SLA при такой миграции. Также это может помочь пользователям шире начать использовать системы с дисками SATA (также SATA + Flash Cache). При этом пользователи будут знать, что, в случае необходимости, они могут быстро и не прерывая работы перенести данные, которым потребуется большая производительность, чем могут обеспечить диски SATA, назад на диски SAS.

Рекомендации и наилучшие практики

Обратите внимание на следующие рекомендации и наилучшие практики при использовании DataMotion for Volumes:

• Вы можете производить только один процесс миграции DataMotion for Volumes одновременно.
• Не делайте vol rename или изменение атрибутов тома или LUN на томе-источнике, когда выполняется DataMotion for Volumes.
• Не запускайте какую-либо операцию, которая может вызвать конфликт процесса выполнения операций DataMotion for Volumes. Если какие-то действия начинаются до того, как процесс вошел в фазу cutover, DataMotion for Volumes прервет свои операции (abort). В состоянии cutover, DataMotion for Volumes прервет (fence) сторонние операции администрирования.
• При использовании HA-кластера, убедитесь, что обе ноды кластера используют Data ONTAP 8.0.1 7-Mode или новее.
• Проверьте отсутствие вышедших из строя компонентов системы и загрузку ее процессоров, перед запуском DataMotion for Volumes.
• Для того, чтобы предотвратить ситуации с конфликтами в фазе cutover, не планируйте занимающие много времени процессы управления или защиты данных параллельно процессу DataMotion for Volumes.
• Не изменяйте параметры конфигурации исходного тома, во время выполнения процесса DataMotion for Volumes.

SNAPMIRROR и SNAPVAULT

• В период выполнения операций DataMotion for Volumes, не изменяйте конфигурацию SnapMirror, не редактируйте файл snapmirror.conf.
• Пока процесс DataMotion for Volumes не достиг фазы cutover, процессы SnapMirror или SnapVault updates успешно завершаются.
• Если процессы репликации происходят в фазе cutover, то передача данных может быть неуспешной, так как cutover прервет операцию. После того, как cutover будет завершен, репликация продолжит следующий цикл передачи обновлений.
• В случае выполнения ручного cutover, не делайте его, пока не завершены операции передачи реплик SnapMirror и SnapVault.

SNAPDRIVE и SNAPMANAGER

В фазе cutover:

• Не работают процессы LUN provisioning и управления снэпшотами в SnapDrive® for Windows® (SDW).
• Не работают процессы резервного копирования и восстановления данных в продуктах SnapManager® (SME, SMSQL, SMVI, SMHV, SMO, SMSAP, and SMOSS). После окончания фазы cutover, например на следующей запланированной операции создания резервной копии, эти процедуры успешно выполнятся.

Настройки таймаутов SCSI

• NetApp рекомендует устанавливать на OS хост-системы NetApp Host Utilities Kit, для предотвращения ошибок таймаута. Смотрите "NetApp Host Utilities Installation and Setup Guide" для вашей хост-OS http://now.netapp.com/NOW/cgi-bin/software.

FLEXVOL и FLEXCLONE

• DataMotion for Volumes может перемещать только тома FlexVol; Тома FlexClone® не могут быть перемещены.После завершения DataMotion for Volumes, исходный том FlexVol остается в состоянии offline и отношения child-parent не изменяются.
• Тома FlexClone должны быть отделены (split) от породившего их тома FlexVol , перед тем, как вы начнете перенос тома FlexClone.

Дедупликация и компрессия

• Если на томе-источнике идет активный процесс дедупликации, он должен быть остановлен для успешного выполнения фазы cutover.
• DataMotion for Volumes не переносит базу fingerprint и change logs дедуплицированного тома FlexVol. После завершения процесса DataMotion for Volumes, пользователи должны запустить команду sis start -s для того, чтобы перестроить fingerprint DB на томе-получателе.
• Компрессированные тома не перемещаются.

Дополнительные рекомендации по использованию DataMotion for Volumes для Oracle® Database и Microsoft® Exchange можно найти в TR-3881.

Итак, об этом можно рассказать. Официально объявлено о новой модели, или вернее даже двух моделях – FAS2240-2 и FAS2240-4, о самом факте их существования я уже упоминал, теперь объявлены детали.

Как мы и предположили раньше, это модели систем хранения, представляющие собой, фактически, контроллер для дисковой полки DS2246 и DS4243 соответственно, продаваемые как отдельная модель системы хранения, и состоящие из знакомого конструктива дисковой полки с дисками, и контроллера в них. Такая конструкция позволяет легко, в дальнейшем, апгрейдить такую систему, просто вынув из нее контроллер и вставив на его место интерфейсный модуль IOM-3/6, превратив такую систему с ее дисками и данными на них, в дополнительную дисковую полку

Вид спереди FAS2240-2

Continue reading ‘FAS2240 - новинка модельного ряда NetApp этого года.’ »

В марте этого года я уже рассказывал о проводимом интернет-журналом SearchStorage опросе пользователей, призванным выявить самую удачную, по мнению самих пользователей, систему хранения в highend, и вот, ближе к концу года, были подведены итоги другого такого опроса, о системах хранения в сегменте midrange, 457 участников оценили 797 систем хранения сегмента Midrange, разных производителей.

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

Я всегда говорю, что в таких опросах и отчетах самый смысл не столько непосредственно в самих абсолютных цифрах, сколько в динамике изменений. И если в highend NetApp в бесспорных лидерах уже второй год, то в midrange борьба куда напряженнее. В прошлом таком обзоре лидерство было за системами Compellent, ныне принадлежащим Dell, однако, даже несмотря на это, NetApp сделал, в глазах пользователей, огромный скачок, поднявшись за год с четвертого места, за HP и HDS, на первое.

Стоит отметить, что лидирующая восьмерка показывает в целом очень близкие и высокие результаты, и разница между ними, будем откровенны, весьма невелика. Тем не менее, всего на одну сотую балла NetApp в этом году обошел Dell-Compellent, а с учетом динамики своего роста, нельзя не признать, что это победа совсем не просто “в одну сотую”.

К сожалению, в этом году SearchStorage решила не предоставлять подробный PDF с описанием, ограничившись только результатом, но, например, в тексте статьи можно найти некоторые интересные детали. Так, за Dell выступала “сборная команда” Dell CX + Compellent +Equallogic PS (93 системы), за EMC учитывались Clariion CX и VNX (184), за HP – EVA, P4000, 3Par E200/F200/F400 (129), IBM был представлен Storwise V7000, DS3950, DS4000, 5000 и 6000 (84), Oracle моделями 6000 и 7000, но без Pillar, который, посчитанный отдельно, не набрал статистически значимого количества отзывов (43), и Nexans E-series (15). Количество участвовавших в оценке систем NetApp составило 124, то есть по текущей “популяции” и распространенности у пользователей они уступили только EMC и HP. Стоит отметить также, что по сравнению с результатом прошлого года, количество систем NetApp у пользователей увеличилось почти вдвое (с 69 до 124)

И, наконец, самый важный, на мой взгляд, результат всего опроса, показывающий непосредственную удовлетворенность пользователей их системой хранения -  ответ на вопрос: “Купите ли вы такую систему снова?”

На днях я завершил перевод Best Practices по наилучшим методам конфигуирования, сайзинга и использования систем хранения NetApp для построения виртуальных десктопных инфраструктур (VDI) в среде VMware View. В ближайшие дни он будет доступен по обычному для всех таких переводов адресу, на сайте дистрибуторской компании Netwell. Переводы, напомню, делаются по заказу Netwell и компании A-systems, мир с ними обоими;), так что если вы хотите написать пожелания, благодарности, или, например, высказать предложения о дальнейших темах таких переводов, то пишите на info@netwell.ru и info@a-systems.ru.com. Не забывайте, что от вашего фидбэка напрямую зависит дальнейшее продолжение работ по переводу Best Practices. Отсутствие видимого отклика, зачастую, создает впечатление, что это никому не нужно и не интересно, и непонятно зачем на это тратить деньги и время, ведь все могут свободно прочесть это на английском, с сайта NetApp.

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

Использование систем хранения NetApp для решений VMware View 5
Chris Gebhardt, NetApp
Сентябрь 2011 | TR-3705
Версия 5.0

UPD: Уже доступен для скачивания!

Обратите внимание, это на самом деле документ за сентябрь этого года, и на самом деле уже для VMware vSphere 5 и View 5!

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

Также, если вы здесь впервые, и пропустили в начале поста собственно ссылку на большое собрание переведенных на русский NetApp Best Practices на разные темы, то вот вам она еще раз: http://www.netwell.ru/production/techbiblioteka.php

Вы всегда можете ее найти в этом блоге справа в блоке “Ссылки” под названием “техбиблиотека на русском”.

Например в ней вы можете найти сейчас такие полезные документы, как:

Руководство по развертыванию Citrix XenDesktop 5 на VMware vSphere и Citrix XenServer, c использованием систем хранения NetApp

Citrix XenServer V5.0 и системы хранения NetApp: наилучшие практики

Руководство по наилучшим способам использования систем NetApp с VMware vSphere v4.1

Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V

Использование NFS в VMware

Ethernet для систем хранения: наилучшие методы.

Ну и, конечно, на многие друге темы, не только про виртуализацию.

Не стесняйтесь оставлять фидбэк в адрес Netwell и A-Systems, основных спонсоров проекта перевода.

Вышел долгожданный 8.1

Напомню, что по введенной с июля 2010 года модели именования релизов, выпуск под названием RC (Release Candidate) является полноценным релизом, оттестированным и готовым в продакшн.

Цитата с сайта:

Release Candidate (RC)

All Data ONTAP releases are made available first as release candidates (RCs). The RC classification indicates that NetApp has completed the internal testing of the major release. RCs are provided primarily to customers who want to start exploring the major or maintenance releases for either new features or bug fixes early on. RC releases are fully tested and are suitable for production usage. (выделение мое, romx)

NetApp might provide multiple RCs, as necessary, to address any specific issues found before the release becomes a general availability (GA) release. NetApp Global Services (NGS) provides support for RCs. After RCs move to GA, all maintenance and patch releases are based on the GA release and not on the RC.

Релизы “цифра после запятой” (Major Release) выходят каждые 18 месяцев, после их выпуска, каждые 6 месяцев выпускаются так называемые Maintenance Release.

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

Continue reading ‘Вышел Data ONTAP 8.1 RC’ »

Давно у нас не было переводов по средам. И вот сегодня – перевод, посвященный выходу в начале сентября новой версии Virtual Storage Console – VSC – плагина к VMware vCenter, позволяющего непосредственно из среды vCenter управлять системой хранения NetApp.

Это бесплатный продукт, и однозначный мастхэв, если вы используете систему хранения NetApp вместе с VMware.

А вот, что появилось нового. Для начала – сам VSC 2.1

А что нового – в посте Криса Гебхарда.

NetApp Virtual Storage Console 2.1.1 - Now Available

Posted by Chris Gebhardt on Sep 8, 2011 5:18:01 AM

Конечно, мне тоже кажется, что за последнее время я говорю в своем блоге “я рад объявить о выходе” довольно часто, но в данном случае я правда рад и счастлив рассказать о выходе этого продукта! Сегодня (8.09) NetApp выпускает в свет новую версию Virtual Storage Console 2.1.1. Выход этой версии на самом деле довольно важное событие и новые технологии помогут пользователям в их работе с их серверными и десктопными виртуальными системами. Ниже список новых возможностей этой версии VSC 2.1.1.  Я хотел бы особо выделить некоторые из новых возможностей, которые, как мне кажется, наиболее важные, но так получается, что мне придется выделить почти все. Этот релиз, несмотря на минорность, на самом деле очень важен, так как начал поддерживать vSphere 5 и View 5, и ряд новых технологий, которые позволят пользователям улучшить эффективность хранения с помощью thin provisioning для виртуальных машин, а также улучшить ряд аспектов эксплуатации, развертывания и обслуживания виртуальных инфраструктур.

На протяжении следующих нескольких недель я опубликую у себя в блоге демонстрации работы некоторых новых возможностей VSC 2.1.1.

Скачать  VSC можно по ссылке: http://now.netapp.com/NOW/download/software/vsc_win/2.1.1/ <- У вас должен быть логин на NetApp NOW для скачивания!

Итак, что нового:

Virtual Storage Console 2.1.1 включает в себя все что уже было выпщено в VSC 2.1, плюс добавлены новые возможности. Список ниже объединяет новинки 2.1.1 и 2.1:

• Поддержка vSphere 5.0, включающая vCenter Server 5.0 и ESXi v5.
• Базовый модуль Virtual Storage Console переименован в Monitoring and Host Configuration для лучшего понимания его функций.
• Панель Monitoring and Host Configuration Tools теперь имеет две кнопки для скачивания и установки утилит MBR tools: одна для хостов ESXi, другая для ESX. Выберите соответствующую вашей системе версию.
• В Monitoring and Host Configuration добавлены следующие возможности:
  • Можно назначить хост как skipped
  • Отображаются контроллеры системы хранения, работающие в 8.х Cluster-Mode
  • Обеспечивается быстрый поиск (discovery), кроме того, discovery может работать как фоновый процесс
  • Отображается информация о статусе хоста, в колонке Status Reason для хостов
• Модуль Provisioning and Cloning теперь умеет следующее:
  • Высвобождает свободное место (reclaiming space) после удаления данных в guest OS *
  • Предотвращает неверное смещение партиции VM перед клонированием
  • Позволяет задать число CPU и настройки оперативной памяти для новых виртуальных машин
  • Умеет добавлять существующие датасторы новым серверам ESX в кластерах и датацентрах *
  • Сохранение учетных данных View Server для клонирования
  • Позволяет клонировать датасторы в пределах всего сайта vSphere
  • Поддерживается создание, именование, управление виртуальных машин в новых пулах View Server
  • Поддерживает импорт в Citrix XenDesktop и VMware View (расширен API)
  • Сохраняются настройки BIOS при клонировании из шаблона
  • Система хранения добавляется из под доменного аккаунта
  • Catalog-based API provisioning
  • Поддерживается Citrix XenDesktop 5.0
  • Поддерживается Data ONTAP 8.1.0 (7-Mode)
  • Поддерживается VMware View 4.6 и 5.0

* Об этом подробнее в следующем переводе, прим. romx