about NetApp

Некоторые новости с прошедшего в Риме 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” (я специально делаю это замечание для “паникеров” ;) или признание его неэффективности, это, скорее дополнение в ранее незакрытом сегменте рабочих нагрузок и специфических решений.

Хотя эта функциональность появилась еще в 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.

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

Упоминание mailbox disks вы можете встретить в выводе команд, показывающих системный статус кластера, и, как правило, в качестве mailbox disks называются диски, на которых располагается root volume системы.

У меня сложилось также впечатление, что mailbox disk это также “рудимент” времен давних, когда кластер у NetApp в целом работал через такие “псевдо-кворумные диски”, без кластерного интерконнекта вовсе, и остался в системе с тех давних пор, но, увы, это пока лишь гипотеза.

Тем не менее, в случае неисправности mailbox disks (их в кластере, если он не использует SyncMirror – по два у каждой ноды), перестает работать cluster takeover, даже при нормальной работе cluster interconnect cable, а это уже серьезно. К сожалению никаких подробных руководств как работать с mailbox disks, что делать в случае проблем с ними, у NetApp в документации нет (отсюда моя гипотеза о “рудиментарности”, то есть “остатках хвоста”, в существовании mailbox disk вообще). ??з maintenance mode его можно удалить, и тогда при перезагрузке контроллера он создастся заново. Но, в общем, это все.

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

Вот вам перевод найденного в недрах NetApp KB документа NetApp Mailbox disks FAQ.

Continue reading ‘Что такое Mailbox Disk?’ »

Хотел бы обратить внимание тех, кто планирует использование новой возможности на системах хранения NetApp – WAFL online compression, то есть сжатия данных “на лету”, для хранения их на диске в сжатом виде. В настоящий момент блоки, которые были компрессированы таким образом, не кэшируются в Flash Cache / PAM.

Как вы знаете, у NetApp есть сейчас две основных технологии снижения storage footprint, то есть объемов хранения, занимающих физическое дисковое пространство, это давно существующая и хорошо себя зарекомендовавшая во многих случаях дедупликация, и появившаяся сравнительно недавно онлайн-компрессия. Две эти технологии существуют и работают независимо друг от друга, и даже дополняют друг друга. Каждая из них имеет свои предпочтительные области применения. Например, дедупликация хорошо работает для сред виртуализации, где ее эффективность (величина экономии после ее применения) может достигать 70-85% от первоначально занятого на дисках, но в рядя других применений, например для баз данных, ее эффективность (по разным причинам, на которых мы не будем сейчас подробно останавливаться) значительно ниже, часто не более 10-20%.

Напротив, компрессия довольно неплохо уменьшает объем хранения для пользовательских файлов и баз данных (35-50%). Она также сравнительно неплохо работает даже и на уже дедуплицированных данных, что может еще повысить результаты экономии.

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

Это диаметральным образом противоположно ситуации с дедупликацией, так как дедуплицированные блоки, напротив, попадают в dedupe-aware кэш, который знает о их дедуплицированности, и умеет ее использовать (например блок, на который на диске имеется десять ссылкок из десяти разных VMDK, будет считан и находиться в кэше не в 10, как в традиционной форме кэширования, а всего в одном экземпляре, что, очевидно, увеличивает эффективную емкость кэша).

Если у вас система с Flash Cache, и вы одновременно собираетесь использовать компрессию для данных – то будьте внимательны. Компрессированные тома в системе с Flash Cache могут иметь значительно отличающуюся от некомпрессированных производительность, за счет того, что с некомпрессированными томами работа будет идти через Flash Cache, а с компрессированными – нет. Эта разница, не слишком заметная для систем без Flash Cache, за счет такого поведения для систем с Flash Cache, может быть неприятным сюрпризом.

Эта особенность работы компрессии описана в новом TR-3958 Compression and Deduplication for DataONTAP 8.1 operating in 7-Mode на странице 22:

7.6 PAM AND FLASH CACHE CARDS

In environments with high amounts of shared blocks that are read repeatedly, the PAM or Flash Cache card can significantly reduce the number of disk reads, thus improving the read performance. The PAM or Flash Cache card does not increase performance of the compression engine or of reading compressed data. The amount of performance improvement with the PAM or Flash Cache card depends on the amount of shared blocks, the access rate, the active dataset size, and the data layout. The PAM or Flash Cache card has provided significant performance improvements in VMware® VDI environments. These advantages are further enhanced when combined with shared block technologies, such as NetApp deduplication or NetApp FlexClone® technology.

Так что обратите внимание на этот момент, и не применять компрессию для томов, производительность которых для вашей задачи критична, и которые вы планируете ускорить с помощью Flash Cache

UPD: Попросили уточнить. По-прежнему кэшируются во Flash Cache НЕсжатые блоки на сжатом томе (например, если эти блоки были исключены из процесса сжатия в результате плохого compression rate на этапе estimate для этих блоков). Но, так как нет механизма управлять тем, какие именно блоки или файлы будут компрессированы на томе, а какие - нет (компрессия назначается на том целиком), то это, в общем, довольно теоретическая поправка, не меняющая моей итоговой рекомендации.

Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по ценам изготовителя blades, может вылиться в экономию, за которую можно пострадать, но при всего 2-4 серверах в SAN это обычно не стоит выделки. Однако если вы все же решили заняться SAN boot, то вот какие полезные сведения я обнаружил в блоге группы поддержки решений Microsoft, сформированной в NetApp.

Во-первых, следует знать, что на сегодняшний день загрузка из SAN для актуальных OS Microsoft полностью поддерживаемое решение. См. статью из Knowledge Base.

Во-вторых, следует помнить, что проблемы с зонингом – есть “номер один” всех проблем с SAN boot. Если у вас что-то не работает – начните с проверки зонинга. Чаще всего разрешение проблемной ситуации с зонингом и есть решение проблемы загрузки из SAN. Если ваша система на поддержке – обратитесь в поддержку NetApp, они “знают много гитик”. Проверяйте и перепроверяйте все настройки зонинга ДО того, как начнете долбить поддержку.

Третий момент, который стоит помнить, это то, что поддержка MS MPIO на этапе загрузки крайне ограничена. ??спользуемый в MS на этапе инсталляции WinPE (Windows Preinstall Environment) не рассчитан на работу с MPIO, и подключение LUN по нескольким путям может давать непредсказуемые результаты. При первой загрузке этапа установки, инсталлятор Windows загружает модуль boot.wim (это и есть WinPE) и начинает копирование файлов из дистрибутива в “локальный диск”, который в вашем случае будет SAN LUN-ом. После копирования загрузится уже собственно Windows. Поддержка рекомендует на время работы WinPE физически отключать второй путь, который можно будет подключить назад позже, когда у вас уже будет работающий MPIO.

Также стоит помнить, что MPIO не поддерживается в sysprep. Вам придется настроить MPIO непосредственно на том образе, с которого будут грузиться система, но официально не поддерживается его конфигурирование непосредственно в syspreped образе. Оно работает, как показывает опыт. Но не поддерживается MS. Be warned, есличо.

MPIO, несмотря на написанное выше, настоятельно рекомендуется для загрузки SAN boot! Если в момент загрузки вы потеряете связь с SAN LUN, с которого система загружается, она упадет в BSOD Inacessible boot device. Смотрите по этому поводу статью в TechNet.

Для того, чтобы LUN в SAN был увиден системой на этапе инсталляции, он должен быть подключен из BIOS карты HBA. Это поддерживается для “аппаратных” HBA FC (FCoE), а также для hardware HBA iSCSI. Теоретически есть методы загрузки из SAN и для Software iSCSI, но рассмотрение этой темы выходит за рамки данной статьи.

Напомню еще раз, что, для двухпортовых карт, вы должны активировать поддержку загрузки в BIOS только для одного из двух имеющихся портов HBA! Реализация отличается в зависимости от вендора HBA, так что внимательно проследите эту тему самостоятельно по документации. На этапе загрузки не работает MPIO, и LUN должен видеться только по одному пути!

Если после всего перечисленного выше, инсталлятор по прежнему не видит диск, на который он может установить OS, то, скорее всего, в дистрибутиве проблема с драйверами для данного типа HBA. Можно попробовать вставить правильные драйвера непосредственно в инсталлятор, в модули boot.wim и install.wim, либо подставьте драйвера вручную, когда это запрашивает инсталлятор. Опять же тема интеграции драйверов в дистрибутив Windows достаточно хорошо рассмотрена в интернете.

Помните, что если вы вынули CD/DVD-диск, чтобы вставить на его место диск с драйверами, то не забудьте вернуть назад диск с дистрибутивом для продолжения установки. :)

Обратите внимание, что в Windows Host Utilities Installation and Setup Guide со страницы 95 идет очень детальное и подробное описание настройки SAN Boot.

Для практической проверки и отработки решения группа построила стенд из 22 серверов Fujitsu RX200, снабженных двухпортовыми FCoE HBA Brocade 1020, включенных в два коммутатора Brocade 8000 FCoE, куда также подключены два контроллера FAS6030 с дисками. HBA обладают возможностью загрузки из SAN в их BIOS, а сервера имеют средства управления Fujitsu iRMS (аналог HP iLO и DELL DRAC). Система хранения NetApp имеет активированную лицензию FlexClone, используемую в дальнейшем процессе. В принципе, описываемые процессы могут быть реализованы и без FlexClone, но с ним они куда эффективнее расходуют пространство хранения, так как место на диске занимают только изменения относительно мастер-LUNа.

Начнем с создания пустого volume и на нем LUN-а, который будет мастер-образом. Смонтируем данный LUN на один из серверов, заполним и сконфигурируем его, а позже склонируем для остальных серверов. Не забудьте установить в этот образ OS все нужные роли, драйвера и приложения, в данном случае были установлены NetApp DSM, Host Utilities, а также драйвера и приложение управления HBA от Brocade.

Запустим sysprep с опциями –generalize и –shutdown, после чего сервер отключится и LUN необходимо отмапить от сервера. Эталонный мастер-образ подготовлен.

Теперь подготовим остальные сервера на загрузку из SAN. Помните, что в BIOS HBA необходимо включить загрузку с SAN LUN только для одного порта! Смотрите ссылку на документ Boot from SAN in Windows Server 2003 and Windows Server 2008 из MS Download Center.

В имеющемся HBA в BIOS была выбрана опция загрузки “First visible LUN” (эти настройки могут отличаться для разных HBA, решайте по аналогии) с тем чтобы обеспечить наиболее простую загрузку, которая не потребует в дальнейшем перенастройки при изменениях, как в случае опции “Preferred LUN”. Вариант First visible LUN, разумеется, требует некоторых предосторожностей, например дисковый массив с загрузочным LUN должен располагаться в ближайшей к серверам фабрике, чтобы минимизировать задержки, а также иметь LUN ID 0.

Создаем клон тома мастер-образа, например с помощью FlexClone. Маппим LUN в клоне тома (не оригинальный мастер-образ, а клон!) на сервер. Включаем сервер с использованием iRMC и подключаемся к серверной консоли.

Сервер загружается и запускается mini-setup после sysprep. В нем вы можете задать пароль, изменить имя сервера, назначить IP-адрес, и так далее (если вы знакомы с развертыванием образов Windows с использованием sysprep, это не должно быть неожиданностью). После завершения mini-setup вы получаете созданную из мастер-образа индивидуальную копию установки Windows.

??так, мы за несколько минут получили полностью загруженный в индивидуальный образ Windows физический сервер, загружаемый из SAN.

Немного иначе происходит процесс для загрузки виртуальных серверов из SAN.

В случае pass-through disks Hyper-V все происходит также, как и в случае физического сервера, но нужно создать для VM еще один клон, и назначить ему LUN ID отличный от 0, чтобы он не пересекся с LUN, используемым для загрузки физического сервера. ??спользуя LUN FlexClone вы можете создать клоны мастер-LUN непосредственно на том же volume, где он сам и находится. Следите, чтобы на volume либо было достаточно места для записи хранимых “разностных” изменений, или чтобы была активирована опция “volume autogrow” и места было достаточно уже на aggregate этого тома. Если вам понадобится создать больше VM, просто создайте еще несколько клонов мастер-LUN.

В случае использования VHD, следует создать LUN для физического сервера, содержащий файлы VHD для находящихся на нем виртуальных. Также можно использовать возможности sub-LUN клонирования FlexClone, создав один клон LUN-а с множеством клонов VHD в нем.

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

??спользование же FlexClone в данном случае поможет значительно сократить занятый объем. Например, в описываемом случае, около 50 LUN-ов разлчных проектов данного стенда имеют совокупную емкость около 5TB, занимая при этом на диске всего около 300GB.

Ранее я уже писал о том, что такое Multi-Path High Availability (MPHA) – методе подключения дисковых полок к контроллеру, сделав перевод официального FAQ. Однако обещал, что чуть позже напишу еще некоторые мои соображения на этот счет. Вот они.

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

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

Проблема тут возникает для систем “малого класса”, а именно для FAS2040, у которой всего два порта SAS на систему (один на контроллер), и FAS3210, которая, как вы помните, имеет два порта SAS в контроллере и всего два слота расширения (и нет возможности поставить блок расширения портов IOXM, который есть только для 3240/3270).

FAS2040 совсем не может использовать “классический” рекомендованный вариант MPHA, а FAS3210 может его использовать только в варианте с дополнительной платой интерфейсов SAS, которая занимает один из двух слотов расширения.

(исправлено 30.09 romx, Теперь эта проблема в конфигураторе с неотключаемым для 3200 MPHA изменена)

Таким образом у покупателя FAS3210, например, есть выбор поставить в оставшийся слот плату Flash Cache ??Л??, например, 10Gb Ethernet, но НЕ одновременно.
Проблема заключается в том, что, если ранее, MPHA в конфигураторе была отключаемой опцией, и можно было снять эту галку в чекбоксе, и при этом освобождался искомый слот, то теперь, увы, MPHA это обязательная опция конфигурирования, и, следовательно, в один слот из двух у 3210 в обязательном порядке будет поставлена карта SAS-портов, оставляя доступной пользователю и его выбору только один слот.
??менно этим объясняется отказ пресейла партнера NetApp отключить MPHA и сделать вам, допустим, FAS3210 с Flash Cache и 10Gb Ethernet одновеменно. Ему просто не дает это сделать конфигуратор.

Однако вариант подключения без MPHA, хотя MPHA и настоятельно рекомендуемый, навязываемый конфигуратором и “обязательный”, как о нем пишет переведенный ранее FAQ, все же работает, поддерживается NetApp, и, более того, именно такой вариант сконфигурирован, например, в конфигурации FlexPod (что можно посмотреть в опубликованной спецификации на FlexPod), где используется как раз 3210, как раз с Flash Cache ?? двухпортовой 10Gb Ethernet Unified Target card в одном контроллере (и без MPHA полок, соответственно).

То есть, безусловно, MPHA это хорошо, это правильно, но отказ от всех других вариантов подключения это, как я понимаю ситуацию, политическое, а не техническое решение (по крайней мере на сегодняшний день).

Несколько A на различные Frequently Q:

Q: Означает ли, что отказавшись от MPHA мы получим не-multipath или не-high available подключение полок, а, следовательно, “единую точку отказа” и прочие корпоративные IT-ужасы?

A: Нет, не означает. Не-MPHA подключение также и отказоустойчивое и многопутевое, просто в некоторых специальных случаях сбоев для продолжения доступа к данным при подключении не-MPHA может потребоваться cluster failover, а MPHA сможет работать по дополнительному оставшемуся пути, не проводя cluster failover, и, тем самым, экономя время и не обрывая CIFS-сессии, например. Для небольших систем хранения, например на всего одну-четыре полки на систему, случаи такого вида сравнительно малораспространены. Стоит ли жертвовать ради потенциального устранения этих редких случаев одним слотом из двух на 3210 – решать вам.

Q: Обязательно ли использование MPHA?

A: NetApp считает что обязательно (см. FAQ) для тех систем, где MPHA может быть реализован (исключение, таким образом, только для 2040). Но варианты без MPHA по прежнему поддерживаются. Решение, как я понимаю, за пользователем.

Q: Как же нам все же получить FAS3210 с Flash Cache и 10G Ethernet?

A: Проблема с конфигуратором существовала, но сейчас ее нет. Сейчас в штатном режиме можно получить от партнера спецификацию 3210 с двумя любыми картами внутри, без MPHA. (исправлено 30.09 romx.)
Попросите сконфигурировать вам FAS3210 с Flash Cache и закажите в том же заказе дополнительно плату 10G Ethernet, которая придет отдельно, не установленная в контроллер. Далее вы сможете самостоятельно вынуть карту портов SAS и поставить на ее место карту 10G Ethernet, далее подключите дисковые полки в обычной, не-MPHA, в “традиционной” отказоустойчивой, двухпутевой конфигурации.

Q: Не даете ли вы в данном случае дурного совета?

A: Даю :) Помните, что вы читаете не официальный блог NetApp, а просто заведомо ложные, порочашие измышления на тему, данный пост написан не сотрудником NetApp, и NetApp не несет ответственности за что либо публикуемое в данном блоге. Вышеприведенный совет не является официальной рекомендацией NetApp. Хотя подключение не-MPHA в настоящее время по прежнему поддерживается в существующих системах хранения, и отказ он MPHA на системе хранения не является причиной отказа в поддержке.

Q: Но, все-таки…

A: См. спецификацию FlexPod, валидированную Cisco и NetApp, с использованием FAS3210 без MPHA, в как раз описываемой конфигурации с Flash Cache и 10G Ethernet.

Ну и, чтобы не превращать этот блог в одни сплошные опросы, вот вам сегодня и новая статья.

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

В двух словах, Multistore (можете также посмотреть мою заметку о нем ранее) это способ создать “виртуальные мини-нетаппы” внутри физического, которые будут почти полностью такие же, как и физические, за исключением отсутствия в них протокола FC, но с наличием iSCSI, NFS, CIFS и так далее, если они лицензированы на “большом” нетаппе.

Такие “виртуальные файлеры” можно применять, например, при необходимости разделять данные по зонам безопасности (secure multi-tenant). Например на одной системе хранения могут располагаться виртуальные файлеры с данными внутренней сети, и “внешние”, например для DMZ или данными внешнего вебсайта, или же между разным клиентами, использующими один сторадж (что полезно, например, при построении “облака”). ??золяция между такими виртуальными файлерами достаточно безопасна для такого использования и независимый аудит безопасности показал отсутствие проблем с безопасностью и изоляцией данных. vFiler также может располагаться в своем собственном IP space, то есть независимо маршрутизируемом пространстве, и даже на отдельном физическом интерфейсе.

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

Наконец, как я также уже немного рассказывал ранее, с помощью vFilers можно использовать сравнительно новую возможность, под названием NetApp Data Motion.

Data Motion это возможность делать с виртуальными системами хранения vFiler то же, что VMware делает с виртуальными машинами при VMotion, то есть не прерывая их работы мигрировать их с одного физического контроллера на другой. Эта возможность работает для любых приложений, использующих сторадж NetApp с Data Motion, не обязательно для виртуальных машин, например. Также обратите внимание, что при такой миграции мигрируют, например, и отношения репликации. То есть если у вас мигрируемый vFiler располагался на контроллере fas1, и реплицировал через SnapMirror свои данные в резервный датацентр на контроллер drnetapp, а потом был мигрирован с помощью Data Motion на контроллер fas2, например чтобы снизить нагрузку на загруженный fas1 и сбалансировать ее на недогруженный fas2, то его данные по прежнему будут, без вмешательства администратора и перенастройки, реплицироваться на drnetapp уже с контроллера fas2.

Но для того, чтобы всем этим воспользоваться, надо, во-первых, vFiler-ы создать.
Continue reading ‘Multistore и использование vFiler’ »

Я в этом блоге уже несколько раз упоминал тот факт, что жесткий диск имеет определенную “конструктивно заданную” величину параметра IOPS – Input-Output Operations per Second – число операций ввода-вывода в секунду для random-операций. Отдельный жесткий диск имеет производительность в IOPS сравнительно небольшую. Так, для дисков SATA говорят о 75 IOPS, то есть отдельный диск может произвести за секунду 75 операций чтения или записи блока данных с “блинов”. Несколько производительнее диски SAS или FC, до 175 IOPS при скорости вращения 15000 оборотов в минуту. Это совсем не грандиозные объемы операций. Ну представьте, 75 операций ввода вывода (записи и чтения) в секунду. Всего лишь. Если у вас на компьютере работает примерно 30 процессов (программ и системных сервисов), то на каждый такой процесс приходится всего две с половиной операции чтения или записи в секунду.

??менно для повышения производительности в дисковых системах хранения данных используется множество дисков. Совсем не ради емкости, по крайней мере сегодня – как правило. Ведь чем на большее число физических дисков (на нашем птичьем языка-жаргоне прижилось калькированное с английского, и отдающее машинным маслом токарного станка словечко “шпиндель” (spindle), означающее физический жесткий диск) мы можем разложить наши данные, чем больше дисков задействовать для обслуживания ввода-вывода, по 75 (или 175) с каждого, тем выше получится суммарная производительность системы хранения на операциях random read/write.

Но откуда же берется это мистическое число “IOPS со шпинделя”, чем оно так жестко определяется?

На самом деле формула, определяющая эту величину довольно проста.

IOPS Estimated = 1 / ((seek time in ms / 1000) + (latency in ms / 1000))

Как вы видите, двумя основными параметрами диска, задающими величину в IOPS являются величина времени seek, то есть перехода магнитной головки от одной позиции до другой, и latency, то есть величины задержки от момента отправки команды, до получения запрошенного на выходе.

Возьмем, для примера диск Seagate SATA 1TB, 7200RPM:

Estimated IOPS = 1 / ( ( (average read seek time+average write seek time) / 2) / 1000) + (average latency / 1000) )

или с указанными в спеках данных для данного диска:

Estimated IOPS = 1 / ( (9.00 / 1000) + (4.16 / 1000) ) = 1 / ( (0.009) + (0.00416) ) = 75.987 - ~ 75 IOPS

??ли для диска Seagate SAS 600GB 15KRPM:

Estimated IOPS = 1 / ( (3.65 / 1000) + (2.0 / 1000) ) = 1 / ( (0.00365) + (0.002) ) = 176.99 - ~ 175 IOPS

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

Самый удобный вариант – организовать подключение по SSH, однако, для того, чтобы не передавать пароль, сгенерировать заранее public key, и авторизоваться на консоли NetApp с его помощью.

Вот как это сделать с помощью популярного PuTTY.

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

Выберите пользователя, для которого мы будем устанавливать ключ. Помните также, что если вы используете выполнение каких-то скриптов от стороннего, специально сконфигурированного пользователя (например используя RBAC – Role-based Accees Control), то это надо будет также проделать и для него. Закрыв доступ для всех ключей, кроме заранее сконфигурированных, вы заблокируете таких пользователей также.

Далее нам надо создать на контроллере поддиректорию для файла ключей, она должна располагаться внутри директории sshd
полный путь, таким образом, с точки зрения стораджа будет выглядеть примерно так (для пользователя root):

/vol/vol0/etc/sshd/root/.ssh/

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

Смонтируйте root-vol в директорию на вашем компьютере по NFS или CIFS.

Перейдите в директорию /mountpoint/etc/sshd и создайте в ней директорию с именем нужного пользователя, например мы будем использовать для администрирования пользователя romx, а для исполнения скриптов пользователя scripter.

Перейдите в созданную директорию и создайте в ней поддиректорию с именем .ssh (с точкой в начале!)

Убедитесь, что директория успешно создалась, выйдите на уровень /mountpoint, например командой cd ../../../ и размонтируйте шару.

Вы получили следующую структуру на контроллере NetApp: /etc/sshd/romx/.ssh и /etc/sshd/scripter/.ssh соответсвенно.

Теперь сгенерируем пары ключей. Запустите программу puttygen.exe, входящую в состав пакета PuTTY.

Убедитесь, что используете security algorithm SSH2-DSA (Data ONTAP умеет использовать cipher для SSH только TripleDES), щелкните “Generate!” и поводите мышкой для генерации случайной инициализацонной последовательности.

Ключ сгенерирован, теперь надо указать контроллеру NetApp использовать для аутентификации этот ключ. Запишите его в файл с расширением .ppk, например romx.ppk

Не указывайте никакую passphrase.

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

Теперь включите на контроллере режим использования преконфигурированных ключей:

filer1> options ssh.pubkey_auth.enable on

Давайте протестируем подключившись с помощью программы plink из состава PuTTY, и запросив что-нибудь из консоли:

c:\putty> plink.exe -i romx.ppk romx@filer1 vol status

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

Также рекомендуется для аккаунта, исполняющего скрипты, из соображений безопасности, запретить “лишние” возможности. Подробнее об ограничении прав аккаунта смотрите в документе RUS TR-3358 Role-Based Access Control for Data ONTAP 7G.

Продолжаю свои изыскания в теме технологий EMC. На этот  раз я заинтересовался механизмом, лежащим в основе всех новых фишечек EMC CLARiiON/VNX – так называемым Storage Pool. Самым интересным и понятным для меня объяснением оказалась статья блоггера virtualeverything (он не сотрудник EMC, а, как я понял, работает в партнере-интеграторе, и имеет довольно широкое поле зрения, в котором и продукты EMC, и NetApp, и, например, Hitachi). Незначительно сокращенный перевод этой его заметки я предлагаю вашему вниманию.

Глубокое погружение в тему EMC Storage Pool.

Posted by veverything on March 5, 2011

??спользование Storage Pools это довольно частая тема для дискуссии с моими коллегами и пользователями. Многая информация о устройстве и механизмах работы не слишком распространена или известна, поэтому я решил провести мое собственное исследование на этот счет, и поделиться его результатами.

Некоторое время назад EMC представила в своей линейке систем хранения CLARiiON новый принцип так называемого Virtual Provisioning и Storage Pools. Основная идея заключалась в упрощении администрирования системы хранения. Традиционный метод управления хранилищем это взять дисковый массив, наполненный дисками, создать из них дискретные группы RAID, и затем нарезать из этих групп LUNы, которые, затем, предоставляются хостам. Дисковый массив, в зависимости от своего размера, при этом может содержать до нескольких сотен таких групп, и часто превращается в архипелаг разрозненных "островков хранения" на этих RAID-группах. Это может вызывать серьезные затруднения при планировании пространства хранилища, чтобы устранить проблему нерационально потраченного при таком разбиении места, так как у большинства пользователей их потребности к хранилищу, и планы как разбить под задачи, меняются со временем, и, обычно, еще не ясны до конца в "день 1". Нужны были средства гибкого и простого администрирования, и родилась идея Storage Pools.

Storage pools, как следует из его имени, позволяет администраторам создавать "общий массив" (pool) хранения. В ряде случаев вы даже можете создать один большой, общий пул, куда входят все диски системы хранения, что значительно упрощает процессы администрирования. Больше нет отдельных пространств, не нужно углубляться в "тонкие материи" устройства и организации RAID group, схем разбиения, и так далее. Кроме того, появилась также технология FAST VP, которая позволяет перемещать блоки данных в соответствии с их активностью, по уровням хранения, например на более емкие и дешевые, или более быстрые и дорогие диски. Просто выделите и назначьте пространство из такого "пула" вашей задаче, динамически, гибко, и при этом еще и позволяя использовать auto tiering. Звучит здорово так? По крайней мере так утверждает маркетинг. Давайте разберемся с тем, как это работает "физически", и нет ли не вполне очевидных "подводных камней".

Continue reading ‘EMC Storage Pools – как это работает “под крышкой”.’ »