about NetApp

Пост вида “просто так”. Фотографии найдены в блоге инженера, работающего в CBS, и занимающегося администрированием HPC-кластера NetApp GX.

В датацентр приехали новые 6080.

Получаются в результате вот такие штуки:

Впрочем кластер на 100TB выглядит на деле совсем не страшно.

NetApp GX cluster 100TB

Continue reading ‘NetApp FAS6080 GX в CBS’ »

??так, в предыдущих двух постах этой темы (часть 1, часть 2) я постарался показать, что такое usable space по сравнению с raw space, почему первое всегда меньше чем второе, и почему мы, заплатив за полновесные терабайты получаем на выходе якобы совсем не те терабайты, за которые мы заплатили.

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

Один из блоггеров NetApp, которого я постоянно читаю, Костадис Руссос, использует в своих постах, в особенности в своих спорах с EMC, термины “Real Fibre Channel” (который так любят Наши Уважаемые Конкуренты) и “Better Than Real FibreChannel” :)

Давайте посмотрим, где же NetApp является “Better Than Real FibreChannel”.

Пост планируется длинный, я разбил его на несколько частей, которые будут идти в несколько приемов, так что готовьте кофе ;)

??так, как уменьшается пространство по пути от “raw data” к “usable data + функционал”?

Первый аспект относится скорее не к нашему случаю, но перечислим и его. Это так называемые “маркетинговые байты”. Большинство из читателей знает, что сто лет как существует проблема перевода из “двоичных” в “десятичные” байты. То есть “килобайт” это не 1000 байт, а 1024 байта.

Бородатый анекдот: “Шофер думает, что в килобайте 1000 байт, а программист - что в километре - 1024 метра”

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

Строго говоря уже в обед как сто лет принято решение ISO (International Standartization Organisation) для “двоичных байт” использовать специальные приставки, чтобы отличать двоичные и десятичные множители, звучат они непривычно, и немного смешно: не кило- а киби- (би - “бинарные”, двоичные единицы), “мега” - “меби”, и так далее.
Но пока есть что есть, и из диска на один “терабайт” (как называет его производитель), который на деле “тебибайт”, “исчезает” за счет этого почти сто мегабайт.

Аспект номер два - сектор 520 байт на 8 байт больше обычно используемого. Зачем это так сделано я писал тут и тут. Это уменьшает емкость диска примерно на 1/64 долю, повышая надежность хранения и позволяя использовать дедупликацию.

Далее переходим к RAID-ам. Как вы знаете уже, на системах NetApp используется RAID тип 4 (чередование с четностью, с выделенным диском четности), который имеет емкость X*N-X, где X - это емкость одного диска, а N это число дисков в RAID-группе, то есть на обеспечение отказоустойчивости занимается один диск.
Второй применяемый тип RAID, это вариант RAID-6 под названием RAID-DP, в нем на обеспечение отказоустойчивости занимается два диска (X*N-2X). Такой тип RAID рекомендуется использовать по умолчанию.

Максимальный размер RAID для дисков FC и SAS - 28 дисков. Для SATA - 16. Меньший размер RAID в случае SATA диктуется меньшей надежностью дисков, более высокой вероятностью выхода из строя и ошибок, что потребовало ограничить размер RAID. Кроме того, скорость rebuild на длинном RAID для относительно медленных дисков SATA может быть неприемлимо низкой.
При необходимости использовать большее количество дисков необходио создавать две и более группы, на каждую из которых будет потрачено по 2 диска четности (в случае RAID-DP).
Обратите внимание, что максимальный размер RAID для группы типа RAID-4 в два раза меньше, то есть 16 для SAS и FC, и 8 для SATA! Большая разрешенная длина группы RAID-DP также связана с его более высокой надежностью и отказоустойчивостью.

Следующий этап - диски hot spare. Система NetApp назначает все неиспользуемые в действующих RAID-группах диски в Hot Spare. Затем из пула hotspare-дисков вы можете их забрать, создавая RAID-ы, aggregates тома. Более того, эксплуатация системы без Hot Spare дисков вообще - настоятельно не рекомендуется. Это, в принципе, наверное возможно (например какая-нибудь тестовая инсталляция с абсолютно неценными данными, но ограниченная по дисковым ресурсам), но это должно быть осознанное решение, риск которого полностью возлагается на администратора системы. Для отключения весьма надоедливого уведомления о работе без hot spare необходимо установить одну из системных опций в настройках (курите маны, если что - я ни при чем.).
Но это, повторюсь, не рекомендуется, и является нештатным и рискованным режимом.
В нормальном состоянии необходим один hot spare на каждый контроллер кластера, причем для каждого используемого типа дисков.
Например, если у вас “двухголовая”, двухконтроллерная кластерная система, в которой используется два типа дисков, например 300GB и 450GB FC, или 300GB SAS и 750GB SATA, то вам нужно будет иметь spare каждого из типов, то есть отдельно 300 и отдельно 450, или отдельно 300 SAS, и 750 SATA.

С некоторых пор Data ONTAP предлагает иметь два hot spare на контроллер минимум.
Это связано с некими внутренними “маневрами” системы, и в принципе, как и в случае с работой без hot spare вообще, это может быть отключено в системных опциях ONTAP.
Лично вот мне, как частному лицу, кажется, что держать _четыре_ hot spare на систему (по 2 на контроллер) это уже откровенный перебор, даже для достаточно крупной системы, что уж говорить о наиболее популярных у нас “голова плюс одна или две полки”.

* ??зменить установку по умолчанию в 2 spare можно установив опцию raid.min_spare_count в 1, однако добавлять диски в aggreate придется в командной строке, так как для FilerView установку в 2 spare для ONTAP выше 7.3 изменить не удается (она просто не даст вам в GUI использовать дисков больше чем “все диски головы минус два”).
> aggr add [aggrname] -d [diskname]

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

Продолжение следует.

Вообще же полемика между “Настоящим FibreChannel” и “Ненастоящим” (или как говорит NetApp - Лучше Чем Настоящим FibreChannel) сводится к допустимости или недопустимости виртуализации ресурсов, допустимости или недопустимости использования “абстрактного представления” в системе хранения.

С этой точки зрения ситуация довольно забавна. Представьте себе, что нынче, в 2009 году кто-то начнет пропагандировать какой-нибудь, например, MS-DOS, с аргументами вида: “Только у нас - Настоящее прямое управление памятью! Не какая-то там жульническая “виртуальная память” где-то на каких-то дисках, или еще черт знает где, которая то есть, то нет, она ненадежна, она тормозит, и так далее. Только у нас - Настоящая Оперативная Память!”

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

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

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

Сайзинг под базы Oracle есть критически важный параметр для создания системы хранения достаточной производительности. Сбор данных perfstat* и Oracle STATSPACK позволит выбрать правильно сконфигурированную систему хранения NetApp, как в плане размера, так и производительности.

Важно помнить несколько вещей, когда вы собираете статистику системы:

• Собирайте данные, когда система под большой нагрузкой
• Собирайте данные со всех хостов инфраструктуры
• Собирайте данные в perfstat и STATSPACK за один период времени

Установка Oracle STATSPACK.

STATSPACK это утилита диагностики произвдительности СУБД, которая доступна начиная с Oracle8i. STATSPACK это дальнейшее развитие утилит BSTAT и ESTAT. Рекомендуется установить timed_statistics в true. Для установки STATSPACK выполните следующие шаги:

1. Создайте PERFSTAT Tablespace:

SQL> CREATE TABLESPACE statspack
DATAFILE ‘/path_to_file.dbf’ SIZE 200M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K
SEGMENT SPACE MANAGEMENT AUTO
PERMANENT
ONLINE;

2. Запустите catdbsyn.sql и dbmspool.sql как SYS из SQLPLUS

$ sqlplus "/ as sysdba"

SQL> @?/rdbms/admin/dbmspool.sql

3. Запустите скрипт

$ sqlplus "/ as sysdba"

SQL> @?/rdbms/admin/spcreate

Можете начинать пользоваться Oracle STATSPACK.

Сбор Oracle Statspack с помощью Perfstat с хоста Unix.

Как я могу собирать данные Oracle Statspack и Perfstat одновременно?

Для Perfstat версии 6.28 или позднее мы можем собирать данные Oracle Statspack из Perfstat используя единую команду Perfstat. Это работает для версии perfstat под unix, и не работает для версии perfstat под Windows.

Небольшая выжимка их манов к Perfstat:

Требования:

1. Perfstat может собирать данные Oracle STATSPACK только с одного хоста.
2. ??нстанс Oracle должен быть запущен до того, как будет вызван Perfstat.
3. ??спользуйте флаг -o чтобы передать специфические опции statspack в perfstat.

Опции и значения по умолчанию:

oracle_host=`hostname`
sqlplus=”sqlplus”
oracle_login=”perfstat/perfstat”
runas=”"
sysdba=”false”

-oracle_host - умолчание для localhost, может быть одним из хостов, определенных с помощью -h из команд perfstat

-sqlplus - может быть использован для того, чтобы определить абсолтный путь к команде ’sqlplus’

-runas - может использоваться для запуска sqlplus от имени другого пользователя (то есть пользователь Unix, где установлен Oracle, обычно не root.)

-sysdba - может использоваться для подключения к oracle как sysdba, игнорируя параметр oracle_login. Ключ sysdba вводит следующие команды в логин к sqlplus:

• a. sqlplus /nolog
• b. connect / as sysdba.

Примеры:

perfstat.sh -a oracle
perfstat.sh -h host1 -a oracle -o oracle_host=host1
perfstat.sh -h host1 -a oracle -o oracle_host=host1,sqlplus=/oracle/bin/sqlplus/
perfstat.sh -a oracle -o oracle_login=user/pass
perfstat.sh -a oracle -o runas=oracle,sysdba=true

Более сложные примеры:

perfstat.sh -a oracle -t 5 -i 5 -f filer -o runas=oracle, sysdba=true >/opt/perfstat.out

Note: Для того, чтобы собирать статистику самого файлера вместе с данными статистики Oracle, должен быть использован ключ -f.

Пример приведенный выше запускает perfstat и statspack 5 раз по 5 минут. Он переключает пользователя в oracle (с помощью команды su - oracle), и входит в sqlplus с помощью:

• a. sqlplus /nolog
• b. connect / as sysdba.

Еще почитать:
http://www.akadia.com/services/ora_statspack_survival_guide.html
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb9096
http://www.dba-oracle.com/art_statspack.htm
http://www.datadisk.co.uk/html_docs/oracle/awr.htm

Взято тут:
http://blogs.netapp.com/databases/2009/07/gathering-oracle-statspack-data-for-netapp.html

* perfstat - собственная утилита - shell-script NetApp для сбора статистики, может быть скачана с вебсайта NOW: http://now.netapp.com/NOW/download/tools/perfstat/

Несколько слов о том, почему, собственно, именно NetApp занял сейчас такую значительную долю рынка дедупликации, и что мешает сделать то же самое другим вендорам.
Ну конечно, в значительной мере, свою роль сыграло бесплатное предложение данного функционала, как я уже говорил ранее, лицензия на Deduplication поставляется бесплатно. ?? это, безусловно, способствовало широкому распространению технологии. Та же история была сыграна в свое время с рынком iSCSI, на котором NetApp так же занял значительную его часть (увы, не в России, которая до сих пор для себя iSCSI и его преимущества, по существу, не открыла)

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

А дело вновь в “волшебных пузырьках”, которые называются WAFL. :)

Один из блоггеров NetApp, за которым я внимательно слежу и читаю все его выпуски, уже не раз тут упомянутый Костадис Руссос, полемизируя с “блогорупором EMC” Чаком Холлисом, который использовал в одном из постов в приложении к продуктам EMC слова “Настоящий FibreChannel” (Real FibreChannel), в противовес “всяким там эмуляциям, SAN-ам из NAS-а, и прочим ‘виртуальным’ стораджам”, стал использовать термин “Лучше Чем Настоящий FibreChannel” (Better Than Real FibreChannel).

??так, чем же NetApp Лучше Чем Настоящий FibreChannel.

Вы уже знаете, что система хранения NetApp для организации и доступа к данным на дисках использует специальную логическую структуру, особую “файловую систему”, под названием WAFL - Write Anywhere File Layout. К подробностям о ней, ее устройстве и всяких интересных штуках, отсылаю к моим предыдущим постам на эту тему.
Для нас сейчас интересен один аспект.

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

Это настоящий кошмар для любого “класического стораджа”, который любой ценой стремится минимизировать random-компоненту доступа, так как на нем эффективность его резко падает как на записи (особенно), так и на чтении (большое “замусоривание” кэша и отсутствие эффективного “предсказания”/”read ahead”).

Но ведь вспомните, такой режим “постоянно-рандомной записи и чтения” есть по сути “нативный” режим для WAFL! Блоки WAFL записываются и считываются произвольно и рандомно не только в случае дедуплицирования данных, но и при обычной, естественной работе, которой стораджи NetApp занимаются уже много лет!
То есть переход от “классического” к “дедуплицированному” хранилищу, и вызванная этим “фрагментация данных”, такая катастрофическая для “классического” стораджа, вполне обычна и повседневна для NetApp, и включение дедупликации на быстродействии системы хранения никак не отразится!

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

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

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

По ряду просочившихся слухов, уже в этом году NetApp выкатит следующее поколение своей OS Data ONTAP версии 8. Напомню, что при переходе от 6.х.х к 7 мы получили aggregates и FlexVols, не считая множества более мелких новинок (давших впоследствии и Thin Provisioning, и дедупликацию).
Переход с “семерки” на “восьмерку” будет не менее революционным: в версии 8 будут слиты в единый продукт линейки ONTAP “classic” и ONTAP GX - версия OS, работающая ныне на многоузловых кластерны системах GX, наследник многострадальной покупки Spinnaker Networks в 2004-м, которую все так прожевать с тех пор не удавалось.

Более подробная статья про GX на русском найдена здесь: Распределенное grid-хранение: настоящее и будущее.

Таким образом, в основную “линейку” OS попадут такие возможности, как поддержка grid (напомню, на сегодня 7G поддерживает только двухузловые, “классические” кластеры, а GX до 24 узлов), возможности плавного масштабирования системы хранения без прерывания работы, путем добавления дополнительных “узлов” кластера; Global Namespace в файловой системе, на все узлы грида; “volume moves” - перемещение хранимых данных между узлами системы, в зависимости от уровня их загрузки, чем-то похожее на Vmotion и Storage Vmotion у нынешних VMware; страйпинг данных по всем входящим в grid системам хранения, балансировка нагрузки, и так далее.

??звестно также, что группа Advanced Technologies group, в составе NetApp, занимается задачей создания OS ONTAP, работающей под гипервизором виртуализатора (совместно с разработчиками XEN), что в перспективе может открыть новые возможности, например интеграции новых функциональных модулей без ущерба для стабильности и безопасности базового функционала системы хранения. Напомню, что Data ONTAP, несмотря на то, что в консоли можно сказать ifconfig, и при определенных условиях, даже ps :), не является “UNIX-ом”, так как, среди прочего, например, не имет user space, и работает в “чистом” kernel space, что значительно затрудняет добавление нового кода, в особенности third part.
Если эти разработки закончатся успешно, то NetApp сделает еще один шаг на своем последовательном пути виртуализации “всего и всюду”.

Многие пользователи NetApp, в особенности их младших моделей (Low Enterprise Class, FAS2020 и FAS2050) часто жалуются на большие потери при создании usable space. Зачастую usable space может составлять всего 50% от raw, а иногда бывает и того менее.
Действительно, на системах с малым числом дисков, а зачастую именно такие попадают в сравнительно небольшие компании и проекты, величина пространства, которая отнимается по умолчанию из дискового пространства такой системы довольно велика. Чем больше в системе дисков, тем меньшую роль это играет, однако на небольших системах этот эффект довольно значителен.

Что с этим делать, и насколько это серьезная проблема?

Как вы уже знаете, индивидуальные настройки системы хранения NetApp находятся на создаваемом при первом запуске системы томе vol0 в директории /etc. В отличие от решений конкурентов, этот том не какой-то специальный, а самый обыкновенный, и все содержимое его за исключением занятого под /etc мы можем использовать для хранения пользовательских данных.

Однако такой том нужен для каждого из двух контроллеров, и, в случае использования RAID-4 мы потратим на их создание как минимум 2 диска на parity disks для их RAID-групп (и 4 в случае RAID-DP), плюс еще диски на parity для RAID-групп данных. Плюс hot spare. Вот и убегает, при создании системы с настройками “по умолчанию”, половина всех доступных дисков. Хотя, говоря начистоту, при использовании RAID-10 в “других система хранения” мы тоже получаем 50% usable от raw, но в данном случае все равно как-то жаба грызет.

??так, каким хитрым способом можно получить максимально возможное количество usable space на системе типа FAS2020A, с, допустим, дисками SATA 1TB 7200RPM?

С самого начала скажу, что нижеописанная схема никакой не Best Practices (а скорее даже Bad Practices), но тем не менее позволят получить максимум usable space на небольших системах, типа FAS2020. Если вас угораздило купить такую, да еще с небольшим количеством больших дисков SATA в базе, невзирая на все, что вам говорили при этом при продаже - читайте дальше.

Можно создать aggr0 из всего пары дисков в RAID-4 (1 диск данных и 1 диск parity), и разместить на нем vol0 для первого контроллера. На этом vol0 находится служебная информация, необходимая для загрузки и работы контроллера, директория /etc, поэтому создавать его придется на “полностью чистой” системе из меню Maintenace mode. Служебная директория займет примерно мегабайт 30. Остальное место, почти терабайт, мы можем использовать для хранения каких-нибудь наших данных. По умолчанию на vol0 создается директория home, в которой можно разместить homedir подключенных к NAS пользователей. Однако следует помнить, что быстродействие тома, построеного на RAID из всего двух дисков будет невелико. Так что лучше если это будут какие-нибудь не критичные к быстродействию данные

Оставшиеся 10 дисков мы распределяем таким образом: 1 диск оставляем в hot spare*, а все оставшиеся 9 помещаем в один большой aggregate, в одну RAID-группу типа RAID-4 или RAID-DP (1 или 2 pariy, 8 или 7 дисков данных). ?? на этой большой группе создаем vol0 для второго контроллера.
А все оставшееся место, за вычетом 30Mb на содержимое /etc, мы можем занять нашими данными, причем они будут распределены уже по “длинному” и, следовательно, более быстродействующему RAID.

Disk layout

Отмечу, что, если не ошибаюсь, начиная с ONTAP 7.3, для системы хранения NetApp назначается 2 диска hot spare на каждый контроллер, что для малых систем, на мой взгляд, чересчур расточительно. Это значение можно изменить в системных опциях*.

Преимущества:

1. Мы получаем величину usable space равную 75% от raw (из 12 дисков выпадают 3: 1 на parity на первом контроллере, 1 на parity на втором контроллере, 1 на общий spare)
2. Мы получаем большой раздел “одним куском”, и можем, например, создать на нем LUN размером 8TB (больше все равно не поддерживается на 2020)
3. Этот большой раздел получается относительно быстродейстующий, так как распределен на максимально возможное в данном случае количество дисков.

Недостатки:

1. Мы, по сути, делаем резко асимметричную систему, в которой контроллер 1 практически не занят, и вся рабочая нагрузка по обслуживанию доступа к данным ложится на второй.
2. RAID-4 менее отазоустойчив, чем RAID-DP, в особености на SATA, и обеспечивает более долгое время ребилда в случае сбоя.
3. 1 spare на 2 контроллера это “не рекомендованная” NetApp конфигурация.
4. Такая схема разбиения “не рекомендуется” NetApp для использования.

Так что на свой страх и риск.

* Необходимо изменить системный параметр:
set options raid.min_spare_count 1

Я, конечно, совершенно не аналитик, но тем не менее.
Ситуация с проигрышем NetApp-ом ценового боя с EMC за DataDomain, на мой взгляд очень хорошо описывается словами старой песенки: “Если к другому уходит невеста, то неизвестно кому повезло” ;)

А вот, кстати, и биржа с мной согласна.

NTAP quotes on Yahoo! Finance after 8 july

Continue reading ‘Несколько слов про DataDomain’ »

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

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

В контроллерах NetApp, так как это, по сути, “сервер”, есть “BIOS”. Это не совсем то, что мы привыкли под этим словом видеть на x86-серверах. Но он будет очень сильно знаком админам sparc-серверов, так как сделан в виде привычного для них OpenBoot.
Это некая модульная pre-boot программа, которая много что умеет.
Попасть в нее можно подключив к системе хранения консольный кабель (а также через RLM, по моему, тоже можно), остановив и перегрузив контроллер.

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

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

??нтересные посты с кратким описанием имеющихся команд консоли Maintenance Mode можно почитать в блоге A NetApp Technical Diary независимого блоггера Криса Кранца, этот же блог сейчас транслируется и в общую директорию блоггеров NetApp.

Несмотря на то, что на сайте NetApp в Tecnicl Library можно найти множество интереснейших материалов Best Practices и прочих Guides по применению и настройке систем NetApp с различными системами и продуктами, иногда хочется большего.
Да и иногда некоторые из имеющися документов бывают заметно outdated.
Так, когда я переводил Best Practices по Oracle, был неприятно удивлен, как плохо был обновлен соответствующий документ, который, хоть и в редакции от середины 2008 года, а все еще рассматривает у Линукса ядро ветки 2.4, Solaris поминается аж версии 8, а iSCSI Initiator для него все еще называется unsupported (хотя он для “десятки” уже года два минимум как идет “искаропки”).

Но тут я вспомнил, что партнер NetApp, компания IBM, продающий сейчас их системы в своей линейке продуктов под названием N-series, имеет отличное хранилище доков, знаменитых RedBooks. Вот что-что, за что можно ругать IBM, но только не за отношение к документации.

?? действительно, зайдя на сайт IBM Redbook и введя в поиске “N AND series” я нашел изрядну кипу независимо написанных инженерами IBM доков по применению и настройке систем хранения N-series, которые, как не секрет, являются закомыми нам системами NetApp FAS разных моделей, поставляемыми IBM по особому соглашению, по своим каналам.

Так что если вы ищете какие-либо документы типа Best Pracices для NetApp, в особенности по каким-нибудь IBM-специфическим технологиям типа DB2 или Lotus, впрочем и по тому же Oracle или Microsoft там также они есть, то обязательно проверьте сайт RedBooks.
Доки свежие, отлично оформленные и подробные.

Не так много, как на NetApp, но в отношении документации “два” источника лучше чем “один”