about NetApp

Официально NetApp поддерживает совместимость только с UPS компании APC, до версии 7.2.1 это были модели SmartUPS (и Symmetra), с версии 7.3.2 добавились модели семейства Silcon. Вот официальный список:

После 7.2.1 официальный список был упразднен, и теперь базовая поддержка со стороны ONTAP осуществляется для всех моделей указанных выше линеек APC. Понятие “поддержка в OS” означает, что Data ONTAP может осуществить корректное завершение работы (shutdown) при использовании UPS перечисленных типов.

??спользуя возможности взаимодействия с UPS в ONTAP следует учитывать, что NetApp не использует SNMP Trap при работе с UPS, вместо этого он использует SNMP Get. Состояние UPS проверяется каждые 5 минут по сети Ethernet, в которую подключен UPS, с использованием SNMP. При этом Data ONTAP получает следующие параметры UPS:

• Работает ли он от сети, или находится на батареях
• При нахождении на батареях, каково оценочное оставшееся время

Когда обнаруживается переключение на батареи, интервал проверок состояния сокращается до 10 секунд. Когда уровень батарей достигает уровня, определенного как “Warning-Low” начинают поступать сообщения в систему EMS (Enterprise Messaging System), когда уровень заряда батарей снижается до “Critical-Low” отсылается сообщение в EMS и начинается процедура shutdown.

Если контроллер NetApp отслеживает состояние нескольких UPS (например отдельно для контроллера, для дисковых полок, и для сетевого оборудования), то процедура shutdown начинается при достижении уровня “Critical-Low” на любом из этих UPS.

Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились в той же IP-подсети, что и контроллер NetApp, а сетевое оборудование также должно быть подключено к UPS, чтобы, в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.

Для управления UPS в консоли администратора есть команда ups:

ups add [-c <community>] <ip address>
ups [ disable | enable ] [ all | <ip address>]
ups status
ups set-limits [ all | <ip address>] <critical-time  (secs)><warn-time  (secs)>
ups print-limits [ all | <ip address>]

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

В прошлый раз мы нашли и посмотрели команду filersio – внутренний генератор нагрузки ввода-вывода. Однако оказывается, такая штука, как stress test tool, внутри Data ONTAP есть не одна.

Еще один инструмент нагрузочного тестирования системы хранения – hammer

hammer это в чистом виде stress load generator, не делающий ничего, кроме нагрузки. Если вы хотите не просто “подвесить систему”, но еще и наблюдать за тем, что эта нагрузка дает вам в плане показателей, воспользуйтесь средствами sysstat или stats.

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

Управление Role-Based доступом в Data ONTAP 7G
Ron Demery | NetApp | Декабрь 2009 | TR-3358
Данный документ адресован администраторам системы хранения, администраторам системы безопасности, и системным администраторам. Он описывает представленную в Data ONTAP® 7G ролевую систему разграничения доступа (RBAC - Role-based Access Control), и содержит обзор преимуществ ее использования, а также некоторые примеры решения с ее помощью задач разграничения администраторского доступа к системе хранения.

От практических админов NetApp часто слышал сетования, что, мол, недостатком управления нетаппом является существование самодержавного “рута” - пользователя консоли admin, создаваемого по умолчанию, который “может все”.
Как создать отдельного “ограниченного”, “дежурного администратора”, который может, например только создавать и подключать новые диски с системы хранения на хосты-сервера, но не сможет устроить на системе хранения никаких опасных “экспериментов”, типа описанных у меня ранее изысканий в advanced mode? Создать специального пользователя для выполнения задач бэкапа (и больше ничего, такого “backup operator”)? Создать логин “наблюдателя”, с правами “только просмотр”?
Обо всем этом - в переведенном на русский документе.
http://www.netwell.ru/docs/netapp/role-based_access_control.pdf

Полная библиотека по адресу:
http://www.netwell.ru/production/techbiblioteka.php

Крупный и авторитетный интернет-журнал Storage magazine/SearchStorage.com объявил о публикации результатов очередного, ежегодного, и уже пятого по счету, Quality Awards в области Enterprise Storages.

Данный отчет готовится по результатам анкетирования использующих тот или иной продукт пользователей, и в анкету входят такие вопросы, как: Sales Force Competence (компетентность продавцов продукта), Product Features (богатство функциональности), Initial Product Quality (базовое качество поставленного продукта), Product Reliability (эксплуатационная надежность), Technical Support (качество техподдержки), и, наконец, “Would you buy this product again?” - “Купите ли вы такую систему в дальнейшем еще?”.
252 респондента оценили суммарно 392 системы (количество оцененных респондентами систем было от 1 до 14).

Каждая категория подразумевает ответ в диапазоне от 1 до 8, и в отчет, опубликованный в марте 2010 года, вошло семь хорошо известных вендоров (в скобках число обработанных отзывов):

• 3Par с продуктами InServ Storage Server S400 и S800 (14)
• EMC Symmetrix 3000 series, 4000 series, DMX/DMX-3/DMX-4 и V-Max (92)
• Hewlett-Packard StorageWorks XP series (70)
• Hitachi Data Systems c Lightning 99xx, USP/USP-V/USP-VM (46)
• IBM DS8000 series, XIV, ESS800 (64)
• NetApp FAS3000/3100/6000 и V6000 (81)
• Sun StorageTek 99xx series (20)

Не вошел в итоговый список ранее планировавшийся Fujitsu Eternus 8000 series по причине отсутствия статистически значимого объема отзывов.

По клику на картинке итогового результата вы получите PDF со всеми пятью оцененными категориями, а я не могу не привести только один из графиков (цветовое кодирование вендоров см. выше). Процент ответивших “Да” на вопрос: “Купите ли вы еще такую систему?”:

Как пишет об этом сам Storage Magazine: “91,4% это самый высокий результат ответа на этот вопрос, который мы видели за пять лет проведения наших опросов”

Хотелось бы отметить, что в опросах по Enterprise Storages 2005 и 2006 года NetApp даже не фигурировал, а в опросе 2009 года уже шел “ноздря в ноздрю” с EMC, то есть всего за 3-4 года компания завоевала лидерство в таком чрезвычайно консервативном рынке.
Отличный результат.

В недрах Data ONTAP кроме малоизвестных команд можно отрыть и какие-то совсем загадочные вещи. Занятие по отрыванию таких загадок никак нельзя рекомендовать как безопасное, но иногда находятся интересные штуки.

Вот, например, команда filersio (доступна в advanced mode)

filer1*> filersio
The following commands are available; For more information
filersio help
asyncio_pause asyncio_active spc1
status stop


Эта команда включает встроенный генератор ввода-вывода нагрузки на систему хранения.

filer1*> filersio asyncio_active 50 -r 50 4 0 10m 60 5 /vol/vol0/filersio.test -create -print_stats 5
filersio: workload initiated asynchronously. Results will be displayed on the
console after completion
filersio: starting workload asyncio_active, instance 0

Read I/Os       Avg. read       Max. read       Write I/Os      Avg. write      Max write
                latency(ms)     latency(ms)                     latency(ms)     latency(ms)
6087            0               11              6216            3               981
4410            0               471             4300            5               1551
5323            0               11              5375            4               1121
5439            0               113             5379            4               1151
4354            0               105             4304            5               1674
4307            0               411             4300            5               1171
5459            0               20              5371            5               1260
5384            0               180             5379            4               1071
5439            0               211             5375            4               1011
4396            0               71              4300            5               1311

Statistics for active_active model, instance 0
Running for 60s
Total read latency(ms) 16383
Read I/Os 51687
Avg. read IOPS 861
Avg. read latency(ms) 0
Max read latency(ms) 471
Total write latency(ms) 286501
Write I/Os 51413
Avg. write IOPS 856
Avg. write latency(ms) 5
Max write latency(ms) 4891
filersio: instance 0: workload completed successfully


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

“Эффективность” это, в общем случае, соотношение между “вложенным” и “полученным”.

В случае если мы говорим об “эффективности хранения”, то это соотношение между количеством купленных байт (raw) и тем объемом, который в результате можно записать вашими данными (usable).

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

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

Мы узнаем, что диски вендора А стоят по 1000$ за TB. А диски вендора Б стоят 1500$ за тот же TB. На 50% дороже! Казалось бы вопрос решен, решение от Вендора А обойдется нам на 50% дешевле. Часто на этом выбор и останавливается. Но не спешите.

Углубляясь в тенические характеристики мы узнаем, что система Вендора А на нашей задаче имеет эффективность хранения 30%, то есть из купленного десятитерабайтного стораджа нам достанется всего 3ТB, а система Вендора Б – 70% = 7TB.

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

Получающийся usable space у Вендора А будет стоить 3333$, а вот usable space у Вендора Б - 2142$.

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

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

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

Возьмем некоторую практическую задачу построения enterprise-class системы ERP, использующей Oracle RAC, работающий с ним слой приложений и middleware (Oracle Fusion Middleware suite и Oracle Weblogic), отдел тестирования и разработки приложений. Кроме того, не забудем про резервное копирование и DR. Для правильного распределения данных по быстродействию и приоритетам, в используемой системе хранения применяются диски FC (полки голубого цвета) и SATA (черного)

Рассмотрим подробнее:

СУБД на двухузловом кластере RAC с ASM на Oracle Enterprise Linux, хранит свои данные в LUN-ах, подключенных по FC (линии красного цвета) через дублированную по путям FC-фабрику.

Для правильного распределения и использования ресурсов, большая часть оставшейся инфраструктуры, такой как middleware и приложения, а также сервер управления и отдел dev/test преимущественно расположены в среде виртуализации VMware ESX. Часть критичных приложений же, как мы видим на рисунке, оставлены в физических серверах OEL.

Все перечисленные сервера работают со своими данными через сеть Gigabit Ethernet. Сеть передачи данных хранения, в которой движется трафик iSCSI или NFS, отделен в отдельную физическую сеть (на рисунке “Gigabit Storage Network”) от локального интранета приложений и клиентов.

Давайте сперва грубо прикинем емкость. Допустим, для хранения баз данных RAC нам нужно не менее 8TB usable space. Давайте прикинем, какой уровень RAID сколько raw disks потребует (например, возьмем FC-диски 300GB 15KRPM).

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

Так, например, если задаче требуется терабайт места на диске, никто никогда из сисадминов не “нарежет” ей LUN размером ровно терабайт. Необходим объем на возможный прирост данных, чтобы не оказаться в какой-то момент с вставшей системой оттого, что логи внезапно заполнили все свободное место на рабочем диске. По этой причине LUN для записи N гигабайт данных займет на usable space дисковой системы емкость N+XX%, где XX, в зависимости от решения систадмина, может быть от 10-20 до 100%, так как увеличение LUN-а на традиционных системах обычно сопряжено с кучей сложно решаемых, а иногда и совсем не решаемых проблем, и многие админы предпочитают создать LUN заранее, “раз и навсегда”, и в дальнейшем не возиться с потенциально трудоемкими и небезопасными процедурами увеличения. А так как это распределенное, но незанятое данными место естественным образом вычитается из пространства доступного для записи на диски, то снижается и эффективность.

Эффективность хранения, напомним, это соотношение места, которое мы можем использовать, заполнив своими данными, к общему купленному объему raw data на жестких дисках.

Решением данной проблемы является так называемый принцип “thin provisioning”, или “экономного распределения места”. При таком подходе LUN с данными на дисках занимает ровно то место, сколько занимают записанные  него данные, а при необходимости динамически расширяется за счет свободного пока никем не занятого на дисках пространства, но не занимает на нем “выделенного, но неипользуемого” места заранее, не отбирает его у других задач, и не снижает эффективности. Метод thin provisioning довольно активно внедряется производителями систем хранения в своих продуктах, некоторые, такие как 3PAR, в принципе построены вокруг этой парадигмы. Одним из первых, наряду с 3PAR, thin provisioning внедрили и NetApp, тем более, что принципы работы WAFL, структуры размещения данных, используемый в системах хранения NetApp, позволяет легко этот принцип реализовать.

??так, давайте примерим, что же получится при размещении данных.

В рассматриваемой схеме thin provisioning рекомендуется для данных серверов приложений и middleware. Предположим, что у нас есть 20 виртуальных машин VMware, несущих разнообразные приложения Oracle на Linux и Windows. Каждой виртуальной машине выделен файл виртуального диска, размером 80GB. Но в действительности на этом диске занято 60GB, остальное выделено как резерв на случай увеличения занимаемого объема (это может быть, например, необходимость установить на OS этой виртуальной машины обновления и патчи, рост объема хранимых данных, и так далее). Таким образом на диске каждой машины мы имеем примерно 25% запас неиспользуемого места.

Суммарный объем данных всех 20 виртуальных машин равен 60х20=1200GB, а объем занятого на дисках системы хранения этими виртуальными машинами равен 80×20=1600GB.

Допустим, что сисадмин системы хранения выделил на размещение виртуальных машин application and middleware, объемом 1600GB раздел равный 2TB.
Давайте сравним эффективность решения от NetApp, с использованием RAID-DP и thin provisioning, и “классического” размещения.

Обратите внимание, что в случае “RAID-DP w/thinpro” объем занятого в usable space места меньше, чем allocated, а allocated space выше, чем raw. Это связано с работой thin provisioning, когда место занимает только действительно записанные даные, несмотря на то, что объем представленного OS раздела жесткого диска, во избежание “системной паники”, может быть больше, чем реально занимаемое этими данными на диске место.

Таким образом, вы видите, что с использованием новых технологий повышения “эффективности хранения” нам удалось решить ту же задачу, на которую нам бы пришлось потратить 4TB raw-дисков при использовании RAID-10,  всего на 1350GB raw disks, при использовании RAID-DP и thin provisioning.

Вот что такое высокая эффективность хранения.

Администратору системы хранения иногда приходится перебрасывать данные с тома на том. Чуть ранее я уже рассказал про один из способов решения, инструменте ndmpcopy, позволяющий произвести копирование данных тома силами самой системы хранения, по протоколу NDMP.

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

ndmpcopy это копирование по сетевому протоколу NDMP. Даже когда это происходит в пределах одной системы, все равно это копирование происходит по сетевому сокету, и, как правило, этот процесс медленнее, чем копирование vol copy, который осуществляется непосредственно, а не по сети.

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

Ограничения при использовании vol copy таковы:

• Том-источник данных и том-получатель данных должны быть одного типа. ??ли оба flexible, или оба traditional
• Том-получатель должен быть равен или больше по объему, чем том-источник
• Обе системы хранения, участвующие в копировании, должны быть в доверительных отношениях (trust relationship), на обоих должен быть включен доступ по rsh (Remote Shell)
• Том-получатель на момент начала копирования должен существовать
• Нельзя скопировать root volume
• Том-получатель будет полностью затерт содержимым тома-источника
• Состояние тома-источника на момент запуска процесса должно быть online, а тома-получателя – offline.

Основной лог в Data ONTAP, как у “правильной юниксподобной OS”, ведется в виде syslog. ??, как правильный syslog, он может передаваться на удаленную машину для сборки-разборки его в спциализированных программах.

Для того, чтобы настроить логи на передачу их на удаленную машину, надо изменить настройки в /etc/syslog.conf
Его синтаксис идентичен таковому в Linux/UNIX.

# Log all kernel messages, and anything of level err or higher to the console.
    *.err;kern.*                  /dev/console
# Also log console messages to a remote loghost system called adminhost.
    *.err;kern.*                  @adminhost

То есть: выводим все сообщения уровня ядра, а также все сообщения с уровнем err и выше в системную консоль, а также передаем их на систему adminhost (где его должен принимать syslog-сервер).

На указанной машине запустим сервер syslog (например Kiwi Syslog Server), и будем получать и обрабатывать эти логи, настроив по ним желаемые алерты и репорты.

Смотрите также статью: Swatch and Kiwi Syslog Daemon. К сожалению, за время, прошедшее с ее публикации, компанию-производителя Kiwi Syslog Daemon купили, и теперь их продукт платный, что, впрочем, не может помешать найти множество бесплатных вариатов той или иной степени удобности.

“Просто картинка” о сравнении функциональности систем NetApp FAS (и IBM N-series) и систем EMC всех линеек.

Найдена тут: http://blogs.netapp.com/virtualstorageguy/2010/04/blogging-with-integrity.html

На сайте компании-дистрибутора Netwell, на страничке переводов официальных Best Practices, выложен наш новый большой перевод:
Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V и Hyper-V R2
Это почти 100-страничное руководство по наилучшим способам настройки и использования систем хранения NetApp FAS и системы серверной вируализации Microsoft Hyper-V/R2.
Кстати говоря, многие главы будут полезны и “в отрыве” от NetApp, тем людям, кто хочет побольше узнать о том, как работает Hyper-V сам по себе, и могут быть применимы к использованию с любыми системами хранения.

Краткая его аннотация выглядит так:
Этот документ содержит руководство и описание наилучших методов для построения интегрированной архитектуры и внедрения Microsoft Hyper-V с использованием систем хранения NetApp. Технологии NetApp, рассматриваемые в этом руководстве важны для создания эффективного с точки зрения затрат, производительности, гибкости и дружественности к окружающей среде интегрированного решения хранения данных виртуальной серверной инфраструктуры.

Будем считать, что публикация приурочена к Microsoft Virtualization Summit в Москве. :)