about NetApp

Стала доступной к заказу, новая дисковая полка “четырехзначного” семейства.

Напомню расшифровку новой номенклатуры: первая цифра – высота в U, вторая и третья – максимальное количество дисков, четвертая – скорость работы SAS-интерфейса.
Таким образом это полка в 2U, на 24 диска, с интерфейсом SAS 6Gbit/s.

Ключевые особенности полки:

• 24 диска SAS 2.5” размером
• Новый модуль IOM6 с 4 портами SAS 6Gbit/s
• Вес 22 кг (у DS4243 – 49 кг)
• Доступны диски 450GB и 600GB, 10KRPM
• Могут использоваться с FAS2040, FAS2050, и всеми более старшими (FAS31xx и FAS6xxx)

Ограничения:

• Только SAS, диски SATA в 2.5” NetApp в данный момент не поставляются. Также не будет поддержки в этих полках дисков SSD, по той же причине.
• Нельзя стекировать в один порт SAS вместе с DS4243, так как используется более скоростной порт SAS, это может ограничить гибкость конфигурации для FAS2040, у которой порт SAS на контроллер всего один.

Несколько слов о такой теме, которая, как я заметил, часто вызывает замешательство и непонимание.

Для начала кратко о том, что такое aggregate и как они соотносятся с RAID-группами (например для тех, кто тут впервые, пришел из поисковика, и еще не разглядел, что тут порядка двух сотен постов, в которых о многом написано не по разу).

Aggregate это “уровень виртуализации” для физических дисков в системах хранения NetApp, это своеобразный виртуальный мета-том, на котором можно размещать уже непосредственно адресуемые пользователем тома, сетевые шары для NAS или LUN для SAN. ??спользование такого уровня виртуализации, например, позволяет равномерно распределять операции ввода-вывода по всем нижележащим дискам, увеличивая общую произвдительность, а также с легкостью увеличивать и уменьшать в объемах лежашие поверх него ресурсы – тем самые тома, LUN, сетевые шары, и так далее. Aggregate это одна из самых полезных и эффктивных “фич” систем хранения NetApp.

Однако вопросы возникают вокруг темы создания, и дальнейшего увеличения самого aggregate, путем добавления в его структуру физических дисков. Как это делать правильно, и почему часто это проделывается неправильно – об этом сегодня и пойдет речь.

В физической иерархии aggregate находится на уровне, на котором в традиционных системах хранения находится volume. Ниже него лежат непосредственно физические диски, на которых организованы RAID-группы. Каждый aggregate может занимать одну или, обычно, несколько сконкатенированных RAID-групп, причем размер этих групп в количестве дисков может быть разным. NetApp рекомендует, если нет каких-то особых причин, создавать минимально возможное количество максимально “длинных” aggregate. Это повышает производительность ввода-вывода всех лежащих на них томов и LUN.

Для OS Data ONTAP семейства G7 (версий 7.х.x) максимальный размер aggregate был равен 16TB.
В версиях семейства G8 (8.x.x), для нового формата, под названием 64-bit aggregate, его размер варьируется в зависимости от мощности контроллера, и достигает 100TB для систем FAS6080, самых мощных на сегодня.

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

Для того, чтобы создать aggregate, надо отдать команду в командной строке админской консоли, или запустить мастер в FilerView web-GUI. ?? там и там от нас потребуется задать величину RAID-групп.

Какой же должна быть величина этих RAID-групп в количестве дисков?
На сегодня, максимальный размер RAID-групп для дисков FC и SAS равен 28 дискам (то есть, например, для RAID-DP это 26 дисков данных и 2 диска parity), а для дисков SATA – 16 дисков (в версии 8.0.1 будет увеличена до 20).
Однако “рекомендованные величины”, выбранные “по умолчанию”, несколько меньше, это 16 и 14 дисков соответственно. (Все для типа RAID – RAID-DP).

“Если не знаете что делать – не делайте ничего” гласит по легенде главное правило в учебнике по пилотированию самолетов. Последуем ему и мы. Если вы не знаете, какие параметры при создании aggregate нужно выбрать, например размер RAID-групп – рекомендую вам оставить параметры по умолчанию.

Однако какие параметры стоит рассмотреть в том случае, если мы хотим разобраться и создать максимально оптимизированную структуру RAID?

Прежде всего, рекомендуется создавать RAID-группы, на которых лежит aggregate, по возможности равного размера. Причины этому понятны. Сильный дисбаланс в размерах может ограничить производительность aggregate производительностью самой маленькой RAID-группы.

То есть  между вариантами распределения 26 дисков в виде: 22 диска (RAID-DP 20+2) и 4 (RAID-DP 2+2) или же 13 и 13 (RAID-DP 11+2), следует предпочесть второе, несмотря на то, что в первом случае одна из групп будет значительно крупнее, второй вариант будет иметь в целом гораздо более стабильное быстродйствие в IOPS.

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

Допустим, у нас есть 6 дисков, на которые мы хотим увеличить наш aggregate, лежащий на двух группах RAID-DP по 13 дисков каждый.

У нас есть два варианта:

Вариант 1. Мы може просто, не особо думая, добавить эти диски командой aggr add <aggrname> 8a.1, 8a.2, 8a.3 (и прочие необходимые нам диски), или соответствующим GUI-мастером. Если ранее мы задали, что наш aggregate имеет размер RAID – 13 дисков, то вновь добавленные диски образуют третью RAID-группу rg2 (вдобавок к имещимся rg0 и rg1) размером 6 дисков (RAID-DP 4+2). Если в дальнейшем мы будем добавлять в этот aggregate еще дисков, то диски автоматически станут наращивать эту группу, пока она не достигнет размера 13 дисков, после чего начнется новая группа rg3.
Результат в целом простой, но не совсем для нас желательный. Для системы с высокими требованиями по производительности мы можем столкнуться с ситуацией, когда производительность ввода-вывода системы будет заметно колебаться в зависимости от того, какая порция данных на каком RAID окажется.
Хотя этот эффект часто не слшком ярко выражен, и часто переоценивается, но мы хотели бы его избежать.

Вариант 2. Несколько более хитрый. Как я уже сказал выше, мы не можем вывести уже введенные в aggregate диски. Также мы не можем уменьшить уже установленный в aggregate размер RAID-групп (ведь на дисках уже могут располагаться данные). Однако мы можем увеличивать размер RAID-группы в параметре входящих в нее дисков, вплоть до максимального размера, равного 28 для SAS/FC и 16/20 для SATA. Как вы уже знаете, особенностью использованного у NetApp типа RAID, как RAID-4, так и RAID-DP, является то, что добавление в них новых дисков и увличение RAID производится без необходимости полного перестроения RAID, как это привычно при использовании, например, RAID-5. Новый диск добавляется в RAID-4 или RAID-DP, и сразу же на него можно писать, расширив RAID-группу на размер этого диска.

Начнем с того, что зададим в свойствах aggregate размер его RAID-групп больше, чем было установлено ранее (13), в случае необходимости добавления 6 дисков зададим их величину в 16 дисков.

fas1> aggr options aggr1 raidsize 16

После выполнения этой команды мы получаем тот же aggregate, только теперь вместо двух заполненных RAID-групп на 13 (11d+2p) дисков, мы имеем две неполных RAID-группы по 13 дисков (11d+2p), с максимальным размером 16 (13d+2p). Слдующей командой мы добавляем 6 наших дисков в aggr1:

fas1> aggr add aggr1 8a.1, 8a.2, 8a.3, 8a.4, 8a.5, 8a.6

Логика добавления дисков неполные RAID-группы проста. Если в aggregate имеются неполные группы, то сперва системе следует заполнить эти группы до максимального зачения, начиная с самой младшей, затем переходя к следующей. Таким образом диски 1, 2, 3 добавятся RAID-группе rg0, а 4, 5, 6 – группе rg1. При необходимости можно и вручную задать какой диск в какую группу будет добавляться.

В итоге мы добились нужного нам. Мы добавили 6 дисков, расширили aggregate, и избежали создания неравномерно разбитых RAID в этом aggregate. Обратите внимание, что все эти действия по изменению размеров RAID-группы и добавлнию дисков осуществляются “на ходу”, не прерывая работы системы, перестроения RAID не требуется, и емкость добавленных дисков становится немеленно доступна системе.

??з рубрики “это любопытно”:

На недавней встрече с журналистами и аналитиками глава Oracle, Larry Elisson, сказал, что по его сведениям до 60% бизнеса NetApp это хранение баз Oracle.
Сказано это было в контексте ответа на вопрос, кого еще Oracle собирается купить, в том смысле, что “было бы неплохо купить производителя стораджей, который столько с нами работает”.

Ларри конечно не IDC и не Gartner Group (и язык у него без костей;), да и TheRegister пресса довольно желтая), но что-то мне подсказывает, что public person такого уровня в компании все же владеет цифрами.
Это тем более интерено, что сам NetApp никаких цифр по долям своего рынка систем хранения не называл.

…А ведь еще у NetApp есть VMware, бизнес с которой стремительно развивается, настолько, что по неподтвержденным слухам до 70% всех инсталляций VDI (VMware View) строится на системах NetApp.

Цитаты: http://www.theregister.co.uk/2010/09/24/oracle_netapp/
He was speaking to analysts at a meeting yesterday and responded to questions about mergers and acquisitions in storage and networking. According to Aaron Rakers, a Stifel Niclaus analyst, Ellison said that Oracle will need differentiation in the high-end storage business in which it competes. He added almost immediately that some 60 per cent of NetApp’s business is in the area of storing Oracle database data. “We [Oracle] love that business. We would love to have that 60 per cent. Do we need to acquire? I think there are some interesting technologies we’d like to acquire … I think it is possible.”

Что там с покупкой это еще бабушка надвое сказала, они там все выбирают, кого бы из чимейкеров им теперь купить, AMD или nVidia ;), но такое признание о значимости NetApp для Oracle от главы компании дорогого стоит.

??так, в предыдущем посте я показал вам, почему "диск на два терабайта" вовсе не обладает емкостью в "два терабайта" (по крайней мере с точки зрения устройства, использующего "двоичную" арифметику. Однако в случае NetApp это не единственный "сюрприз" для новичка.

Я уже рассказывал в этом блоге, почему NeApp, наряду с некоторыми другими вендорами, использует на дисках сектор размером 520 байт, то есть на 8 байт больше, чем "традиционный", 512 байт. ??спользование такого сектора обеспечивает лучшую сохранность данных, устойчивость к некоторым специфическим дисковым ошибкам, и позволяет организовать, например, дедупликацию данных.
Однако использование такого сектора, и получение всех связанных с ним плюсов, также приводит к увеличению расхода raw-пространства, прежде чем оно станет usable.

Если в случае использование дисков SAS или FC мы можем просто задать необходимый размер сектора при низкоуровневом форматировании, то все сложнее с дисками SATA. Диски SATA имеют фиксированный сектор, размером 512 байт, и не имеют возможности задавать его размер произвольно, таково ограничение и негибкость протокола SATA.

Поэтому для того, чтобы обеспечить идентичный функционал как для SAS/FC, так и для SATA, в системах NetApp используется следующий метод.
Как вы уже знаете, логический сектор WAFL в OS Data ONTAP равен 4096 байт данных, то есть состоит из восьми "низкоуровневых" секторов диска. Если в случае SAS/FC мы храним дополнительную информацию о секторе в дополнительных 8 байтах на каждый из 8 секторов (суммарно на логический сектор WAFL мы получаем 64 байта таких данных), то, поскольку SATA нам такой возможности не предоставляет, мы вынуждены под хранение этих 64 байт занять отдельный сектор на диске, размером 512 байт. Таким образом, на каждые 8 секторов по 512 байт на диске SATA, мы занимаем один сектор, размером 512 байт, под хранение 64 байт служебных данных. Не слишком экономично, но у нас нет иного варианта.

Однако это, как нетрудно заметить, на 1/9 уменьшает доступную для хранения данных емкость диска SATA.

Технология "расширенного сектора" для FC и SAS-дисков принято называть "Block Checksum (BCS)", технологию "девятого сектора" - "Zone checksum" или "8/9th"

Для того, чтобы посмотреть сколько же в распоряжении NetApp оказывается емкости на диске, можно использовать команду sysconfig -r, которая покажет "правильную" (rightsized) емкость дисков в MiB и блоках.

Вот каковы результаты для диска SATA на "2TB"

Phys (MB/blks)
————–
1695759/3472914816

В прошлом посте я уже приводил выдержку из техспеки диска WDC RE4 на "2TB". В ней указывалось, что диск содержит 3 907 029 168 секторов. Почему же NetApp видит тут только 3 472 914 816?

Посчитаем:

Эффект "отбрасывания" каждого девятого сектора это будет для числа секторов коэффициент 0,88 "в периоде".
Умножим паспортное количество секторов на 0,88… и получим:

3 907 029 168 x 0.88… = 3 472 914 816 секторов размером 512 байт для хранения непосредственно данных.

Сколько же это в мегабайтах, или правильнее - в "мебибайтах"?

3 472 914 816 доступных секторов x 512 байт = 1 778 132 385 792 байт

1 778 132 385 792 байт/1024 = 1 736 457 408 kiB/1024 = 1 695 759 MiB = 1 656 GiB

Таким образом, в "двоичной арифметике", принятой в компьютере (и OS Data ONTAP в том числе), мы получаем доступной в NetApp емкость одного диска "SATA 2TB" равной чуть более 1,65 "тебибайт".

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

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

Все описанное выше не является недостатком систем хранения NetApp (как это, зачастую, желают представить некоторые из наших уважаемых конкурентов и оппонентов). Все описанное выше это не НЕДОСТАТОК, это СВОЙСТВО. Точно также, как "свойством", а не "недостатком" является описанное в предыдущем посте "уменьшение" размера диска при переходе от измерения емкости диска "в попугаях" к емкости "в слоненках".

Да, сперва нам кажется, что отдать 15% от "паспортной" емкости это довольно жестокое требование, в особенности по сравнению с другими системами, которые, как будто, такого "налога" и не требуют. Но помните, что всегда вы что-то получите назад (это свойство любых налогов, по крайней мере в нормальной стране;).

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

В итоге, как показывает практика, вы получаете обратно в usable, заметно больше, чем эти отданные сперва "15%".
Обратите также внимание, что "15%" это только при использовании Zone Checksum на SATA.

При использовании дисков SAS/FC, использующих Block Checksum, например дисков SAS "450GB", их rightsized-емкость для системы будет равна 408,2GiB, что составляет уменьшение примерно на 9,5%.

В следующем посте мы обсудим формирование и ограничения aggregates и flexvol-ов.

Напомнинаю, крупнейшее публичное мероприятие года в российском NetApp – конференция NetApp Innovation 2010 состоится через неделю, 28 сентября. Если кто еще раздумывает, или отложил это и забыл в текучке – самое время поспешить с регистрацией.

Страница регистрации:
http://www.netapp.com/ru/forms/ru-201009-innovation-regform.html

Программа:
http://communicate.netapp.com/content/emea-ru-201009-agenda-innovation

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

Об опасности, связанной со смешением результатов "двоичной" и "десятичной" арифметик при расчете емкости я уже также писал, а сегодня углубимся в эту тему отдельно.
Как вы все, наверное, знаете, в IT исторически принято считать в "двоичной" арифметике, то есть "килобайт" у нас равен не тысяче, как следовало бы из использования приставки kilo- во всех прочих случаях, а 1024-м байтам. Казалось бы, какая ерунда, всего 24 байта на каждой тысяче, можно не обращать внимания. ?? мы часто не обращали, пока не выросли объемы.
В ранее опубликованной записи я уже показывал, как эта "незначительная разница" достигает 10 процентов на емкостях в терабайт и более.

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

С этой особенностью ближе всего знакомы те, кто используют жесткие диски. Производители жестких дисков указывают емкость своих продуктов в "десятичных" единицах (и при этом абсолютно правы, формально, кроме того, "в попугаях" их емкость "гораздо длиннее";), в то время, как в компьютере у нас всюду используются "двоичные" меры исчисления. Килобайт там состоит не из 1000, а из 1024 байт, мегабайт из 1024 килобайт, и так далее.

Если мы посмотрим на спецификации жестких дисков (возьмем для примера WD RE4 на "2TB") , то мы увидим там следующее:

Sectors per disk drive = 3 907 029 168
Formatted capacity = 2 000 398MB

Давайте проверим приведенные значения:

3 907 029 168 секторов x 512 байт = 2 000 398 934 016 байт
2 000 398 934 016 байт /1000 = 2 000 398 934kB /1000 = 2 000 398MB

Таким образом все верно, WD указал емкость в десятичных единицах, и емкость в них диска WD RE4 действительно равна 2 000 398 Мегабайт.

Однако для компьютера, который считает в "двоичной арифметике", в которой в “килобайте” не 1000, а 1024 байт, та же емкость будет следующей:

3 907 029 168 секторов x 512 байт = 2 000 398 934 016 байт
2 000 398 934 016 байт /1024 = 1 953 514 584 kiB /1024 = 1 907 729 MiB = 1 863 GiB

Обратите внимание на то, что, в отличие от компьютера, чтобы не путать вас, я указал в качестве единиц измерения именно "бинарные" приставки: kiB, MiB, GiB - "кибибайты", "мебибайты" и "Гибибайты".

??того, ваш компьютер, считающий в "двоичной" (Base2) арифметике, покажет вам емкость вашего диска примерно на 10% меньше. В этом нет никакого обмана (если этим не пользуются в корыстных целях), но не надо удивляться полученному результату. Однако 10% емкости “двухтерабайтного” диска это совсем не "24 байта на тысячу", которыми можно пренебречь, это без малого 200 "гигабайт".

Все только ухудшается, если емкости растут, например если вы собираетесь делать RAID из множества дисков 2TB, причем желали бы получить в итоге строго определенную емкость.

В эту ловушку попадали на моей памяти уже многие, при планировании емкости системы хранения.

"Если нам надо 50TB, то возьмем 2 полки DS14mk2-AT c 14 дисками 2TB в каждой, итого будет 28 помножить на 2 - 56TB, минус два на RAID parity, минус один на hot spare - вот и получается 50".

Не получается. Помните об этом.

Но это еще не все.

О затратах емкости на Zone и Block checksum - в следующем посте.

Хотя я обычно воздерживаюсь от публикации “пресс-релизов”, я считаю, что обойти вниманием такую новость нельзя.

Компания NetApp объявила о своих позициях на рынке открытых систем сетевого дискового хранения данных в странах Европы, Ближнего Востока и Африки (EMEA). Согласно оценкам IDC, представленным в «Ежеквартальном рейтинге дисковых систем хранения данных в странах EMEA» за второй квартал 2010 г., компания NetApp - единственная из рейтингового списка top-8 увеличила свою долю рынка.

Уже второй квартал подряд компания занимает вторую строку рейтинга. В настоящее время ее доля рынка достигла 16,4 %, тогда как во втором квартале 2009 года она составляла 11,7 %. Темпы роста компании NetApp превышают темпы развития рынка открытых сетевых дисковых систем хранения данных. Рост за год составил 76,1 %.
Наиболее сильны позиции компании в Германии, где она занимает первое место в рейтинге (sic!), а также в Великобритании, ??рландии и Франции, в этих странах она занимает вторую строку. На данный момент компания имеет долю на рынках 32 из 40 стран и регионов EMEA, отслеживаемых IDC. Более того, в 29 из этих стран темпы роста компании NetApp превысили темпы развития рынка.
«Мы сохранили динамику развития в странах EMEA и даже увеличили свою долю на рынке. Нам определенно есть, что сказать, и наши заказчики ценят усилия, которые мы предпринимаем, стремясь сделать их ??Т-инфраструктуру более гибкой и эффективной, - заявил Андреас Кёниг (Andreas König), старший вице-президент и генеральный директор компании NetApp по делам в странах EMEA. - Во втором квартале нам вновь удалось сократить разрыв между своей позицией и первым местом, а это значит, что мы на пути к поставленной цели: стать к 2012 году ведущим поставщиком систем хранения данных в странах EMEA».

Напомню, что 2009-й год компания завершила в мире третьей по объемам продаж (в $) после EMC и с незначительным отрывом от IBM, идущей второй, и с тех пор показывала значительный, относительно IBM, рост, так что стоит ожидать теперь и стабильного второго места в общемировом рейтинге.

Кто следит за объявлениями эвентов долно быть уже знает, что в ноябре нас ждет большое событие, NeApp Insight 2010, на котором, срди прочего, будет объялено множество новых продуктов, как “железных”, так и “софтовых”.

Расписание: 1-4 ноября – Лас-Вегас, 16-18 ноября – Прага, 7-10 декабря – Макао, Китай.

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

Ждем ноября. Будет интересно.

ACP (Alternate Control Path) это автономная, out-of-band, архитектура управления, которая обеспечивает изоляцию канала управления от канала передачи данных. Ранее использование управления out-of-band использовалось только на некоторых high-end системах хранения. В такой архитектуре состояние дисков и дисковой полки мониторится по выделенному каналу, отдельному от канала данных. Полка DS4243 использует для этого пару портов Ethernet. При использовании традиционной технологии FC-AL, где “канал” управления передается в том же потоке данных, что и “канал” данных, ряд операций или видов ошибок мог вести за собой прерывание соединения между дисками и контроллером. Переход на SAS, и одновременно разделение канала управления от канала передачи данных, позволяет повысить надежность решения.

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

Что такое alternate control path и почему он нужен?

ACP позволяет реализовать:

• Автоматизированное восстановление после сбоев
• Лучшее отлавливание ошибок на уровне полки
• ??нфраструктуру для будущих разработок

??з чего состоит ACP?

• ACPP (ACP Processor); обычно это аппаратное устройство встроенное в контроллер дисковой полки
• ACPA (ACP Administrator); обычно это программное устройство, в случае NetApp - код в Data ONTAP

Обязательно ли использование ACP в DS4243?

??спользование ACP настоятельно рекомендуется, но не является обязательным условием. Например у вас могут использоваться с новыми полками старые системы, просто не имеющие свободных портов Ethernet. В настоящий сосент NetApp планирует установить выделенный порт ACP на контроллеры всех новых системем, которые будут доступны в будущем. В настоящий момент выделенный порт ACP имеется у системы FAS2040.

Сколько портов необходимо для ACP?

Требуется только один порт Ethernet на контроллер, на все DS4243, подключенные к данному контроллеру.

Можно ли обновить firmware полки по ACP?

Нет, shelf firmware обновляется только через контроллер SAS.

Как обновляется ACP firmware?

ACP firmware обновляется через сеть ACP (Ethernet).

Что можно сделать через ACP (в текущей реализации DS4243)?

Через ACP можно:

• Провести сброс для SAS expander-а внутри модуля IOM3 (SAS expander reset/SAS expander power cycle)
• Считать shelf POST data.
• Записать firmware ACPP (не самой полки!)

Чем ACP не является?

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

Что из себя представляет сеть ACP?

• Сеть ACP это специальная выделенная подсеть Ethernet
• IP-адреса для входящих в нее устройств задаются Data ONTAP из специального диапазона адресов
• Сеть имеет топологию “цепочка” (daisy-chain)
• Сеть ACP не соединена с сетью передачи данных
• Будет работать в том числе и при подключении в “общую” сеть (не рекомендуется)
• ??спользует для передачи данных специальные порты
• Передаваемые данные шифруются с помощью SSL после начального установления соединения между IP

Как подключить ACP? 

Обратите внимание на то, как и куда подключен левый порт ACP (“квадрат”) на верхней полке.

Еще один рисунок схемы подключения ACP на полках DS4243 и двух контроллерах.

В Data ONTAP появились новые и внесены изменения в ряд некоторых старых команд.

Обновленные команды:

• sysconfig
• storage show disk
• environment shelf

Новые команды:

• storage show acp
• storage download acp
• acpadmin list_all
• acpadmin expander_reset
• acpadmin expander_power_cycle
• acpadmin post_data
• acpadmin voltage_status

Пример вывода команды storage show acp

Alternate Control Path: enabled
Ethernet Interface: e0b
ACP Status: Active
ACP IP address: 198.15.1.212
ACP domain: 198.15.1.0
ACP netmask: 255.255.255.0
ACP Connectivity Status: Full Connectivity
Shelf Module    Reset Cnt    IP address       FW Version   Status
———————————————————————
7a.001.A        002          198.15.1.145     0.6          active
7a.001.B        003          198.15.1.146     0.6          active
7c.002.A        000          198.15.1.206     0.6          active
7c.002.B        001          198.15.1.204     0.6          active


Значения параметров:

• Alternate Control Path: “enabled” или “DISABLED”
• Ethernet Interface: порт, назначенный для ACPA
• ACP status: ”Active” или “Inactive”

Состояние ACP Connectivity Status:

• ”No Connectivity” – не подключен ACPP
• ”Full Connectivity” – подключен как data path (SAS), так и control path (Ethernet)
• ”Partial Connectivity” – у некоторых  IOM подключен только data path (нет соединения с ACP)
• ”Additional Connectivity” – у некоторых IOM подключен только ACP (нет соединения с data path)
• "NA” – ACP недоступен или выключен

Состояние поля Status для полок:

• [0x5] “active”
• [0x1] “inactive (initializing)”
• [0x2] “inactive (not ready)”
• [0x3] “inactive (waiting for in-band information)”
• [0x4] “inactive (no in-band connectivity)”
• [0x6] “not-responding (last contact at: "Sat Jan 31 21:40:58 GMT 2010”)
• [0x7] “inactive (upgrading firmware)”
• [0x8] “not-responding (last contact at: "Sat Jan 31 21:40:58 GMT 2010")

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