Как обновить ONTAP

Введение

Сам по себе процесс обновления достаточно прямолинеен и происходит on-line без необходимости отключать что-либо.

Но вот подготовка к обновлению это самый трудоемкий процесс

Впрочем, давайте по порядку. Разделим все на следующие пункты

• Планирование

• Подготовка

• Обновление

• Пост-проверка

• Траблшутинг

The план

Планирование

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

Пример:

Нам нужно обновиться с версии ONTAP 9.1 до ONTAP 9.7, а значит необходимо выполнить 3 цикла обновления

1. Обновляемся с 9.1 до 9.3

2. С 9.3 до 9.5

3. С 9.5 до 9.7

Желательно обновляться последовательно, а не скопом до последней прошивки. Так мы лучше контролируем процесс

Релизы с приставкой Р например 9.7Р4 - технические релизы, они фиксят баги внутри GA релизов и обновляться на них или нет вы решаете самостоятельно предварительно заглянув в соответствующий release notes

ONTAP 9.* - general avaliability (GA) релиз ONTAP 9.*P* - технический релиз ONTAP 9.*RC* - релиз кандидат

У каждого релиза есть свой срок поддержки

Второе, проверяем матрицу совместимости

Важнейший шаг для тех кто использует native FC!

Loading...

Что нужно знать для успешного обновления в среде FC? Совместимость ONTAP и :

1. SAN Switch/Fabric firmware

2. Host HBA firmware

3. Host hypervisor version

4. Host OS version

Именно в таком порядке важности

Пример:

У нас есть - SAN свитч Cisco MDS 9148 - firmware 5.2 - ONTAP 9.1

Нам нужно обновиться до ONTAP 9.7, смотрим по матрице совместимости, и видим, что для обновления до ONTAP 9.7 нужна версия прошивки на свитче 6.2(17) и выше

Третье, качаем прошивку

Как скачать прошивку

Опционально, генерим план апгрейда в AIQ

Active IQ

Почему опционально?

• Апгрейд план показывает процесс обновления только через CLI. Если вы уверенный админ ONTAP он вполне подходит, но для всех остальных лучше воспользоваться web GUI

• Нужен разве что для revert upgrade, по нашему это откат на предыдущую прошивку, когда что-то пошло не так

• Банально не все настроили AIQ. А зря. Shame on you!

Подготовка

Прошивку скачали, матрицу прочекали. Приступим к подготовке

На этом этапе нам нужно проверить:

• Состояние кластера

• Производительность

• Протоколы

• Запущенные задания

Состояние кластера

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

Проверяем кластер

cluster show

Cluster ha show

storage failover show

Проверяем нет ли неисправных дисков

storage disk show -state broken

DNS сервер

dns check -vserver vserver_name

Проверяем failover группы для NAS протоколов

network interface show -role data -failover

Производительность

Достаточно выжный пункт

Конечно, беспрактис и здравый смысл подсказывает, что обновляться (даже пусть и non-disruptive) нужно в наименее загруженные часы.

Как вам уже известно, контроллеры обновляются по очереди и "подхватывают" нагрузку друг-друга. Соответственно если оба контроллера загружены на 90%, то в момент апгрейда вся эта нагрузка приедет к одному контроллеру и будет беда.

По-этому, перед апгрейдом стоит всегда быстренько проверить текущую загрузку каждного контроллера. По своему опыту скажу что по 60% (120%) на каждую ноду это нормально для апгрейда, все что выше - ждите подлагов в сервисах

node run -node node_name -command sysstat -c 10 -x 3

И смотрим на CPU и Disk Util параметры

Протоколы

В зависимоти от используемых протоколов, нам необходимо провести некоторую подготовку

Statless. Не сессионные протоколы

• NFSv3 - так как трафик ходит по UDP нам ничего не нужно делать, разве что проверить failover group на предмет доступных портов на контроллере-партнере для переезда lif. И в очень редких случаях когда вы используете hard mounting. Cамый беспроблемный протокол в плане апгрейда 💙

• FCP - проверьте чтобы LUN был виден по всем путям, в зависимости от количества lif на СХД. Со стороны СХД и Хоста

• iSCSI - аналогично FCP, SAN-lif не переезжают

Вбиваем комманды и сверяем

iscsi initiator show -fields igroup,initiator-name,tpgroup
fcp initiator show -fields igroup,wwpn,lif

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

• CIFS - Для Hyper-V на SMBv3 с Continuous Available shares проблем не будет, а вот для всех остальных реализаций или с отключенным CA нужно будет терменировать все сессии пользователей

• NFSv4.x - тут дела обстоят получше, мешать апгрейду этот протокол не будет. Но вот пользователей повыкидывает и им нужно будет ждать таймаут подключения. В общем стоит держать это в уме и заранее отключить телефон

Запущенные задания

Все Jobs которые стоит отключить перед обновлением

Для начала проверьте что вообще сейчас запущенно

job show

На что стоит обратить внимание

• Snapshots

  • ждём пока завершатся

• Snapmirror

  • ждём пока завершится и ставим на паузу

• Пост дедуп и компрессия

  • Завершаем принудительно, ждать будем долго

• Volume move

  • Ждём

• NDMP

  • Завершаем

job delete -id job_id

Обновление

Наконец-то мы подошли к самой сути - апгрейду! 🥳

Но, прежде чем нажать заветную кнопочку order beer upgrade, давайте разберемся какие вообще бывают ..

Методы апгрейда прошивки

1.Automatic upgrade

Приоритетный способ. Выполняется как из web GUI так из под CLI. Выполняет последовательный автоматический апгрейд каждой ноды. Его мы и будем рассматривать

2. Rolling upgrade

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

Ставим в известность autosupport

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

autosupport invoke -node * -type all -message "MAINT=<time>h Starting_NDU"

Заливаем образ на СХД

Ранее, мы скачали прошивку, сейчас она лежит у нас в папке загрузок и выгляд примерно так 95P12_q_image.tgz

Распаковывать архив НЕ нужно!

Архив нужно залить на СХД, для этого есть два метода

До ONTAP 9.4

• HTTP сервер

• FTP сервер

Это окно апгрейда в ONTAP 9.3

Начиная с ONTAP 9.4

• Добавили прямую загрузку c локального диска (ура)

• Но варианты с использованием HTTP/FTP сервера все еще остаются

Антон, я никогда не пользовался FTP/HTTP сервером и у меня в инфраструктуре таких нет, что делать?

Do not panic!

Вам понадобится рабочая станция с доступом в менеджмент сеть СХД И любой веб сервер. Я обычно использую Fenix Web Server (гуглите), запускаем его, указываем рутовой папку в которой лежит прошивка а затем в вебухе заливаем этот образ на СХД

По умолчанию используется 80 порт. Но вы можете указать любой

Сам процесс апгрейда

Прошивку залили, кофе налили. Все готов к апгрейду!

Поехали!

Выбираем прошивку, до которой хотим обновиться и нажимаем Next

В следующем окне нажимаем Validate

Если валидация прошла успешно, то появится такое окно

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

Нажимаем Next

И попадаем в последнее окно

Тут мы можем выбрать обновлять нам все ноды в кластере либо каждую HA пару отдельно. Актуально если у нас несколько СХД разных поколений объеденены в один кластер

Так же мы можем изменить время стабилизации ноды после прошивки, это по сути задержка между обновлениеями

Все проверили и нажимаем Update

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

После чего, наконец-то, начнется процесс обновления. Или не начнется, но это мы рассмотрим в траблшутинге

Тут можно наблюдать за ходом обновления, остановить его или даже отменить

Обновление занимает 40 минут по 20 минут на каждую ноду, вне зависимости от версии прошивки. Это фиксированое значение

Дожидаемся успешного завершения и переходим к пост проверке, либо к траблшутингу, зависит от вашей удачи 😂

Пост-проверка

На самом деле тут все очень просто - повторяем пункт Подготовка

Все что выключали - включаем Все что останавливали - запускам

Если не прозвучало взрыва или СХД не загорелась то все в поряде 👌

Траблшутинг

Уфф, не повезло вам тут оказаться. Впрочем, отставить отчаиваться!

Обновление ПО - предельно простой процесс и в основном есть только одна ,самая распространенная проблема:

Вы не можете залить прошивку на СХД

Как бы банально это не звучало

В 90% случаев проблема в прокладке между клавиатурой и стулом где-то в сети, между вашим веб сервером и СХД, но не всегда

Прошивка заливается по node и cluster менеджмент интерфейсам

Что бы получить максимальную информативность заходим по ssh и пробуем выполнить загрузку прошивки еще раз, смотрим на ошибку

в примере выше СХД видит сервер, пытается на него подключиться чтобы забрать прошивку, но получает отворотповорот

Возможные причины:

• 80 порт заблочен фаерволом/занят кем-то другим (используйте другой порт)

• Для подключения требуется логин пароль

• Фаервол блочит все входящие подключения

Второй пример, показывает, что СХД вообще не видит веб/фтп сервер, так как срабатывает таймаут подключения

Возможные причины:

• Веб/фтп сервер выключен

• Не доступен для менеджмент сети СХД

• Карательный фаерво

Причины, не относящиейся к сети

• Не хватает места для хранения прошивки

  • Актуально только для старых систем либо если у вас хранится штук 20 образов

• Вы пытаетесь загрузить некорректный образ

• Образ неполный (недокачан)

Вы не можете обновиться

А вот это уже поинтереснее будет, и сложнее

Сразу обозначу основные пункты, на которые стоит обратить внимание

• Сверяйте md5, некорректно скачанный архив не пройдет валидацию

• Убедитесь что у вас нет критических неисправностей в кластере (неисправный диск, БП, кластер и тд)

• Проверьте, может вы пытаетесь обновиться не на ту версию прошивки

Так же рассмотрим парочку частных случаев

Первый случай

Казалось бы, все понятно, у нас есть проблема с кластером и нужно ее решить.

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

Как узнать что же нам мешает? Заходим по ssh в advanced режиме

set adv -c off

и смотрим процесс обновления

cluster image show-update-progress

Если ошибка есть, то тут будет указана причина

Проблема с датой, дата прошивки новее чем время на кластере

Смотрим какое время на кластере

cluster date show

Меняем на нужное

cluster date modify -date

И возобновляем процесс обновления

Второй случай

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

Не важно как причина, главное что у нас одна нода на новой версии прошивки, а другая на старой и обновление завершилось с ошибкой. Такое случается крайне редко.

Тем не менее, это не так страшно как кажется - ноды могут вполне сносно некоторое время работать на разных версиях прошивки

Допустим, мы изменили дату и теперь нужно продолжить процесс прошивки

Но как это сделать для одного контроллера? Только через CLI

system image update -node nodename -package http://ip/imagename

Нода обновилась, смотрим версию прошивки, должна совпадать

Огонь, мы все починили!

Об Авторе