about NetApp

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

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

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

Release Candidate (RC)

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

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

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

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

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

Ну, потихоньку-полегоньку надо начинать привыкать к “восьмерке”.

Еще 3 сентября на NOW появилась версия под названием 8.0.1RC1 и я уже сталкивался с некоторым непониманем того, что такое теперь у NetApp RC.

Если вы знакомы со старой моделью именвания релизов, то помните названия GA – General Availability и GD – General Deployment.

Начиная с июня 2010 года, то есть с версии 7.3.4 и также для всех дальнейших 8.0.х действует новая, упрошенная модель именования релизов. Теперь, если по простому, то нынешний RC это старый GA, а нынешний GA это старый GD.
Теперь версии будут называться RC – Release Candidate, наиболее свежие версии, опубликованные, протестированные, и предназначенные для  ознакомления, использования и годные для установки в продакшн; и GA – General Available, протестированные всеми способами, в том числе подтвержденные на “пять девяток”, что занимает определенное дополнительное время, и GA становятся доступны несколько позднее. Добавление функциональности между RC и GA не производится.

Что же добавилось в 8.0.1?

• Поддерживается новое “железо”, о котором нам объявят в ноябре.
• Появилась поддержка Flash Cache АКА PAM-II, который не поддерживался в версии 8.0.0, что многих сильно огорчало. Теперь поддержка есть для всех PAM, причем как для 7-Mode, так и для Cluster-Mode.
• Теперь есть поддержка SMB 2.0 для 7-Mode. Ранее она была доступна только в “семерке”, а недавно опубликованные результаты показывают значительные преимущества использования SMB 2.0, причем в сетях с задержками в десятки миллисекунд (например распределенные и соединенные через WAN и VPN сети Windows ) разница в производительности с SMB 1.0/CIFS по настоящему огромная.
• Теперь возможно использования root vol (vol0) на 64-bit aggregate, то есть нет нужды держать отдельный “старый” маленький aggregate только ради root vol, жертвуя минимум двумя-тремя дисками на каждом из двух контроллеров. Однако помните, что это не позволит вам “откатиться” на старую версию, только с полной переустановкой системы.
• Появилась поддержка в 7-Mode возможности Volume Snapmirror Compression, которая уже была в наиболее свежих версиях ONTAP “седьмой” ветки, а также (ограниченно) поддерживается Multistore (на уровне 7.3.2). Правда Data Motion для vfiler, базирующийся на функциональности 7.3.3, пока не поддерживается.
• Зато (в 7-Mode только) появилась возможность под названием Data Motion for Volumes, при котором можно мигрировать тома, содержащие LUN (то есть только блочный доступ), не прерывая к ним доступа, на ходу, на другие aggregates. Обратите внимание, типы aggregates должны быть одинаковы, то есть это НЕ способ мигрировать с 32-bit на 64-bit. Средство преобразования типов aggregates вновь обещается, и вновь задерживается.
• Увеличен верхний лимит длины RAID-группы типа RAID-DP для SATA: с 16 до 20.
• В 7-Mode поддерживается онлайн-компрессия данных на WAFL, но только на 64-it aggregates.
• Наконец то увеличен размер тома, на котором возможна дедупликация, для всей линейки, начиная с 2040 (напомню, что 2020 и 2050 в 8.0 не поддерживаются), теперь дедупликация возможна на томе размером 16TB, для всех контроллеров (только для 7-Mode).
• Поддерживается VAAI – VMware vStorage API for Array Integration, новый API для offload операций хранения с хоста VMware ESX, например создание eager zeroed thick volume, а также новый метод локирования данных на LUN при совместном к ним доступе через VMFS (только для 7-Mode).
• Много добавлений по мелочи, например появилась поддержка CDP – Cisco Discovery Protocol, полезного для разбирательств с сетевой инфраструктурой. Команда работы с VIF (Virtual Interface, нетапповским названием для EtherChannel) теперь не vif, а ifgrp. Появилась полезная команда storage show fault, а также поддержка SSL v2 и v3.

Пока нет:

• IPv6
• SnapLock
• Не изменились доступные данному типа контроллера размер 64-bit aggregate, то есть по прежнему: 2040 – 30TB; 3040,3140,3160,3070 – 50TB; 6030,6040,3170 – 70TB; 6070,6080 – 100TB.

В связи с приближающейся долгожданной Data ONTAP 8.0.1 со множеством плюшек и бонусов, хочу обратить внимание владельцев систем хранения NetApp FAS на то, что 8.0.х принципиально работает только на 64-bit процессорах (это связано со сменой внутренней архитектуры), а это значит, что она не пойдет на 32-х разрядных системах в линейке FAS. К 32-разрядным относятся такие системы, как: FAS2020, FAS2050, FAS3020 и FAS3050. Для этих систем следует либо остаться на “ветке” 7, которая пока еще продолжает развиваться и поддерживаться, либо провести аппаратный апгрейд.

Так, FAS3020 может быть проапгрейжена заменой контроллера существующей системы в 64-битную FAS3040, 3050 – в 3070. Но 3020, и уж того паче, 3050, это системы достаточно старые, а более современные 3040/3070 (а также системы линейки 3100) существуют уже около 3 лет. Сложнее ситуация в low-enterprise, с системами серии 2000, успешно и активно продающихся и по сей день.

Если для FAS2020 и есть теоретическая замена контроллера на 64-bit FAS2040, правда за вполне солидные для систем этого сегмента деньги, то FAS2050 пока остается “сбоку”. Есть некоторая надежда на появление аналогичного апгрейда для этого конструктива, назовем его условно “FAS2070”, но пока никаких известий нет, и многочисленные покупатели довольно удачной системы 2050 пока остаются без “восьмерки”. Ждем осени и предполагающегося, подобно прошлому году, объявления новых продуктов.

Процедура полного обновления OS и firmware системы хранения NetApp FAS

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

Загрузите с now.netapp.com:

• свежие прошивки для полок (all shelf firmware updates)
• свежие прошивки дисков (all disk firmware updates)
• прошвку firmware контроллера CFE
• новую версию DataONTAP
• документацию соответствующей версии DataONTAP

Рекомендуется: Сообщите в саппорт о том, что вы приступаете к обновлению. Сгенерируйте письмо в AutoSupport с темой Maintenance или Upgrade, иначе вы можете получить кучу открытых кейсов для вашей системы и обеспокоенные звонки из техподдержки “чего это у вас там все ребутится в кластере?”
( > option autosupport.doit maintenance )
На крайний случай просто временно выключите AutoSupport (не рекомендуется, можно забыть включить назад)
(> option autosupport.enable off)

Смонтируйте на вашем компьютере как сетевой диск ресурс \\filerA\c$ и \\filerB\c$
Данное монтирование (C$) возможно в том числе, если вы не используете и не имеете лицензию CIFS.
Аналогично это возможно и с NFS в случае Linux/UNIX.

Сделайте резервную копию содержимого c$\etc\ на обоих системах

Скопируйте эту резервную копию в папку c$\backup\etc_хх-хх-хххх

Распакуйте архив прошивок полок в etc\shelf_fw на обоих контроллерах filerA и filerB

Распакуйте архив прошивок дисков в etc\disk_fw на обоих контроллерах filerA и filerB

* Обновление прошивки полок

Войдите в админскую консоль системы хранения.

Проверьте текущую версию shelf firmware ( > sysconfig -v )

Войдите в режим с повышенными привилегиями ( > priv set advanced )

Запустите обновление прошивки полок ( > storage download shelf )
Этот процесс обновит прошивки всех дисковых полок системы. Если вы хотите обновить только какие-то определенные, то используйте команду
> storage download shelf adapter_number.

Согласитесь на обновление, нажмите “y” и Enter.

После завершения проверьте версию прошивки полок ( > sysconfig -v )

Выйдите из режима повышенных привилегий ( > priv set admin )

* Обновление прошивки дисков

Прошивки дисков автоматически обновятся во время перезагрузки, если новые версии на этот момент будут лежать в папке disk_fw. Чтобы предотвратить такое поведение, например в случае очень больших систем с большим количеством дисков, можно изменить следующую системную опцию:
( > options raid.background_disk_fw_update.enable), она может быть в состоянии on или off. Рекомендуется оставить ее в on.

* Обновление Data ONTAP

Проверьте соответствие вашей системы опуликованным для полученного релиза Data ONTAP. При необходимости обновить версии прошивок полок и дисков сделайте это как описано выше.
Проверьте разделы known problems and limitations сопровождающей релиз информации. Проверьте списики исправленных багов между вашей рабочей системой и обновляемой.

* Процесс обновления

Распакуйте полученные архивы с новым дистрибутивом OS на смонтированные диски C$ обоих контроллеров в соответствуюшие папки (\etc\boot). Если вы проделываете это из под Windows, то рекомендуется воспользоваться стандартным путем, запустив на локальной машине самораспаковывающийся архив дистрибутива Data ONTAP и указав смонтированный на локальную машину диск \\filer\c$, как это указано в подсказке распаковки.

Запустите установку обновления новой OS на обоих системах ( > download )

Проверьте состояние кластера ( > cf status ) чтобы быть уверенным, что кластерный файловер работает

Выполните перехват системой filerB сервисов системы filerA ( > cf takeover )
Это отправит filerA в перезагрузку

Во время перезагрузки filerA нажмите ( ctrl-c ) для входа в maintenance mode
Вы должны делать это подключенным консольным кабелем к системе хранения, или через RMC (Remote Management Controller).

Находясь в maintenance mode наберите ( > halt ) чтобы выполнить полную перезагрузку

Нажмите ( del ) во время теста памяти, чтоы получить консоль CFE

Запустите прошивку нового firmware в flash командой CFE ( CFE> update_flash )

Перезагрузитесь командой ( bye ) на консоли и дождитесь завершения нормальной загрузки OS системы хранения filerA
Система filerA должна находиться в состоянии …waiting for giveback state

Для возвращения кластерных ресурсов на filerA мы должны дать команду
( > cf giveback –f ) с консоли filerB
Это необходимо сделать вручную, так как у нас сейчас различные версии Data ONTAP на контроллерах кластера.

После завершения giveback, проверьте версию прошивки и OS системы filerA
( > sysconfig –v )

После проверки успешности обновления повторяем действия с системой filerB:

Система filerA перехватывает сервисы filerB ( > cf takeover –n )

Наберите ( > halt ) в консоли filerB для перезагрузки

Во время перезагрузки filerB нажмите ( ctrl-c ) для входа в maintenance mode.
В maintenance mode наберите в консоли ( > halt ) для выполнения полной перезагрузки.
Нажмите ( del ) по время тестирования памяти чтобы получить консоль CFE.
Запустите обновление firmware командой ( CFE> update_flash )

Введите ( bye ) в консоли после завершения перепрошивки и выполните перезагрузку filerB

Если система filerB находится в состоянии …waiting for giveback state сделайте ручной giveback ( > cf giveback –f ) с контроллера filerA
Если процесс giveback завершен успешно, проверьте firmeware и версию OS на filerB при помощи ( > sysconfig –v )

Обе системы полностью обновлены.