Как обновить ONTAP
Введение
Сам по себе процесс обновления достаточно прямолинеен и происходит on-line без необходимости отключать что-либо.
Но вот подготовка к обновлению это самый трудоемкий процесс
Впрочем, давайте по порядку. Разделим все на следующие пункты
Планирование
Подготовка
Обновление
Пост-проверка
Траблшутинг
Планирование
Первое, что нужно сделать, посмотреть с какой на какую версию прошивки мы можем обновиться и в какой последовательности
Пример:
Нам нужно обновиться с версии ONTAP 9.1 до ONTAP 9.7, а значит необходимо выполнить 3 цикла обновления
Обновляемся с 9.1 до 9.3
С 9.3 до 9.5
С 9.5 до 9.7
Желательно обновляться последовательно, а не скопом до последней прошивки. Так мы лучше контролируем процесс
Релизы с приставкой Р например 9.7Р4 - технические релизы, они фиксят баги внутри GA релизов и обновляться на них или нет вы решаете самостоятельно предварительно заглянув в соответствующий release notes
ONTAP 9.* - general avaliability (GA) релиз ONTAP 9.*P* - технический релиз ONTAP 9.*RC* - релиз кандидат
У каждого релиза есть свой срок поддержки
Второе, проверяем матрицу совместимости
Важнейший шаг для тех кто использует native FC!
Что нужно знать для успешного обновления в среде FC? Совместимость ONTAP и :
SAN Switch/Fabric firmware
Host HBA firmware
Host hypervisor version
Host OS version
Именно в таком порядке важности
Пример:
У нас есть - SAN свитч Cisco MDS 9148 - firmware 5.2 - ONTAP 9.1
Нам нужно обновиться до ONTAP 9.7, смотрим по матрице совместимости, и видим, что для обновления до ONTAP 9.7 нужна версия прошивки на свитче 6.2(17) и выше
Третье, качаем прошивку
Опционально, генерим план апгрейда в AIQ
Почему опционально?
Апгрейд план показывает процесс обновления только через CLI. Если вы уверенный админ ONTAP он вполне подходит, но для всех остальных лучше воспользоваться web GUI
Нужен разве что для revert upgrade, по нашему это откат на предыдущую прошивку, когда что-то пошло не так
Банально не все настроили AIQ. А зря. Shame on you!
Подготовка
Прошивку скачали, матрицу прочекали. Приступим к подготовке
На этом этапе нам нужно проверить:
Состояние кластера
Производительность
Протоколы
Запущенные задания
Состояние кластера
Контроллеры обновляются по очереди, соответственно срабатывает процесс takeover, аналогично если бы вышел из строя один из контроллеров, а значит нам необходимо убедится что кластер здоров и функционирует нормально до того как мы начнем апгрейд
Проверяем кластер
Проверяем нет ли неисправных дисков
DNS сервер
Проверяем failover группы для NAS протоколов
Производительность
Достаточно выжный пункт
Конечно, беспрактис и здравый смысл подсказывает, что обновляться (даже пусть и non-disruptive) нужно в наименее загруженные часы.
Как вам уже известно, контроллеры обновляются по очереди и "подхватывают" нагрузку друг-друга. Соответственно если оба контроллера загружены на 90%, то в момент апгрейда вся эта нагрузка приедет к одному контроллеру и будет беда.
По-этому, перед апгрейдом стоит всегда быстренько проверить текущую загрузку каждного контроллера. По своему опыту скажу что по 60% (120%) на каждую ноду это нормально для апгрейда, все что выше - ждите подлагов в сервисах
И смотрим на CPU и Disk Util параметры
Протоколы
В зависимоти от используемых протоколов, нам необходимо провести некоторую подготовку
Statless. Не сессионные протоколы
FCP - проверьте чтобы LUN был виден по всем путям, в зависимости от количества lif на СХД. Со стороны СХД и Хоста
iSCSI - аналогично FCP, SAN-lif не переезжают
Вбиваем комманды и сверяем
Statefull. Сессионные протоколы. Держат сессию клиент-сервер и в процессе giveback не позволяют польностью отдать сервисы на перезагрузившийся контроллер, что с одной стороны защищает обмен данными, а с другой мешает апгрейду
CIFS - Для Hyper-V на SMBv3 с Continuous Available shares проблем не будет, а вот для всех остальных реализаций или с отключенным CA нужно будет терменировать все сессии пользователей
NFSv4.x - тут дела обстоят получше, мешать апгрейду этот протокол не будет. Но вот пользователей повыкидывает и им нужно будет ждать таймаут подключения. В общем стоит держать это в уме и заранее отключить телефон
Запущенные задания
Все Jobs которые стоит отключить перед обновлением
Для начала проверьте что вообще сейчас запущенно
На что стоит обратить внимание
Snapshots
ждём пока завершатся
Snapmirror
ждём пока завершится и ставим на паузу
Пост дедуп и компрессия
Завершаем принудительно, ждать будем долго
Volume move
Ждём
NDMP
Завершаем
Обновление
Но, прежде чем нажать заветную кнопочку order beer upgrade, давайте разберемся какие вообще бывают ..
Методы апгрейда прошивки
1.Automatic upgrade
Приоритетный способ. Выполняется как из web GUI так из под CLI. Выполняет последовательный автоматический апгрейд каждой ноды. Его мы и будем рассматривать
2. Rolling upgrade
Выполняется исключительно через CLI и предназначен для ручного апгрейда каждой ноды отдельно. Такой метод используют в основном при даунгрейде либо возникновении ошибок
Ставим в известность autosupport
Правило хорошего тона, которое все обычно игрнорируют. Этот шаг нужен чтобы в будущем было более понятно когда был агрейд, а когда действительно случилась неисправность
Заливаем образ на СХД
Ранее, мы скачали прошивку, сейчас она лежит у нас в папке загрузок и выгляд примерно так 95P12_q_image.tgz
Распаковывать архив НЕ нужно!
Архив нужно залить на СХД, для этого есть два метода
До ONTAP 9.4
HTTP сервер
FTP сервер
Начиная с 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 режиме
и смотрим процесс обновления
Если ошибка есть, то тут будет указана причина
Проблема с датой, дата прошивки новее чем время на кластере
Смотрим какое время на кластере
Меняем на нужное
И возобновляем процесс обновления
Второй случай
Предположим, одна нода обновилась, а вторая нет. Причина, например та же, отсутствие сертификатат или неправильная его дата.
Не важно как причина, главное что у нас одна нода на новой версии прошивки, а другая на старой и обновление завершилось с ошибкой. Такое случается крайне редко.
Тем не менее, это не так страшно как кажется - ноды могут вполне сносно некоторое время работать на разных версиях прошивки
Допустим, мы изменили дату и теперь нужно продолжить процесс прошивки
Но как это сделать для одного контроллера? Только через CLI
Нода обновилась, смотрим версию прошивки, должна совпадать
Огонь, мы все починили!
Last updated
