Обновление ПО на каком-либо коммутаторе — это не просто залил софт, прописал в него загрузку на старте и сказал ребут. Это целый процесс, который многим просто не виден. Об этом процессе и хотелось бы рассказать.

Одна из услуг, предоставляемых компанией Selectel — аренда выделенного сервера. Это отдельный независимый сервер, размещенный в стойке в дата-центре, к серверу подведены электропитание, IPMI-сеть, сеть с доступом в интернет, и сеть для соединения нескольких серверов в дата-центре в единый выделенный сегмент, так называемая «локальная сеть».

Каждая сеть: интернет, локальная и IPMI, заведена в отдельный коммутатор.
Схематически это выглядит примерно так:


Коммутатор доступа в интернет («интернет коммутатор» на схеме, мы для упрощения называем их именно так), обозначим его как SW10, может быть как одиночный, так и частью стека или M-LAG пары, и подключен дальше к коммутаторам агрегации. Коммутаторы агрегации («интернет агрегации», если упрощенно говорить как у нас обычно принято, обозначим как AGG1) уже подключены к маршрутизаторам доступа (обозначим один маршрутизатор как R)

Надо обновлять!

По ряду причин на SW10 потребовалось обновить версию программного обеспечения. Причины для такого поступка могут быть разные:

• В текущей версии ПО есть «баг», который исправлен в следующей версии.
• В текущей версии ПО нет необходимого функционала, который стал необходим, и реализация которого есть в следующей версии.
• «Дыра» в безопасности на текущей версии ПО (например, пароль суперпользователя по умолчанию, неправильная обработка атрибутов авторизации, buffer overrun в реализации SSH, да что угодно).
• Необходимость поддерживать версию ПО на коммутаторе в актуальном состоянии по требованию вендора («Мы рассмотрели ваш вопрос, используемое на коммутаторе ПО находится в статусе End-Of-Support, для дальнейшей работы по кейсу просим поставить актуальную версию ПО и повторить действия»).
• В пару поставили устройство на более новой версии ПО, и для корректной работы пары устройств надо обновить ПО именно на этом устройстве.
• Другие объективные причины.

К коммутатору доступа подключено до 48 серверов клиентов. Это может быть и один клиент, арендующий все 48 серверов в стойке (да, есть и такое), и 48 клиентов (по одному на сервер). В любом случае, обновление программного обеспечения на коммутаторе это почти 100% перерыв связи на несколько минут (а то и 20-30 минут, если объем программного обеспечения большой, перезагрузка коммутатора происходит долго).

Особо стоит отметить обновление программного обеспечения на стеках (да и M-LAG парах) у некоторых производителей — пока все коммутаторы в стеке или паре не будут иметь одну версию программного обеспечения, будет перерыв связи на всех этих коммутаторах. Главный принцип, которого мы всегда придерживаемся в компании — это клиентоориентированность.

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

Надеюсь, вышеописанного было достаточно, чтобы показать, что обновление ПО на коммутаторе, пусть и обслуживающем всего одну стойку, это не просто процесс «залить новый софт > прописать в конфиге загрузку в него > перезагрузить коммутатор > заниматься своими делами», а намного более сложная процедура, требующая ответственного подхода.

В дальнейшем все примеры будут показывать обновление ПО на коммутаторе Huawei CE5855.

Подготовка к работам

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

Проверка возможности обновления

У каждого производителя сетевого оборудования в release notes к новой версии программного обеспечения есть таблица совместимости версий и так называемый upgrade path, то есть, требования по совместимости конфигураций, надо ли производить сброс оборудования к заводским настройкам перед обновлением, надо ли в процессе перехода от версии F к версии K, например, устанавливать промежуточную версию H, форматировать внутреннюю флешку или совершать какие-либо дополнительные ритуальные действия. Перед началом процесса подготовки к обновлению необходимо проверить возможность и процедуру такого обновления по этой таблице.

Могут быть курьезные случаи, например, ПО версии 6.0.2h и выше может быть установлено на любые коммутаторы определенной модели, а ПО предыдущих версий — только на коммутаторы этой модели определенной аппаратной ревизии (А1), которая была снята с производства в 2018 году. А мы устанавливаем коммутатор ревизии В2, но все предыдущие коммутаторы работают на ПО версии 6.0.1, то есть, мы не можем на новый коммутатор поставить 6.0.1.

Подключение консолей

Чтобы получить доступ к оборудованию во время обновления программного обеспечения, увидеть, что же оборудование выводит на консоль, какие диагностические сообщения, или как происходит сам процесс обновления и перезагрузки, требуется подключить к оборудованию так называемую «консоль» — кабель RS-232 к определенному разъему.

Такие разъемы есть практически на всём сетевом оборудовании в Selectel. Для выполнения удаленного подключения с использованием RS-232 консоли во всех дата-центрах Selectel установлены так называемые «консольные серверы». По сути, это маршрутизаторы, у которых аплинк-порты Ethernet, даунлинк-порты — RS-232, а программное обеспечение предоставляет доступ к RS-232 портам посредством telnet или SSH IP-протоколов. Мы используем консольные серверы производства компании Aten.

Проверка локального доступа

Все сетевое оборудование в дата-центрах Selectel использует централизованные механизмы ААА для проверки пар логин-пароль, выдачи прав различным пользователям на различные действия (например, сотрудники технической поддержки имеют только read-only права доступа на оборудование, это помогает им в диагностике, сотрудники облачной платформы имеют доступ только на оборудование, обеспечивающее работу этой облачной платформы) и логирование действий. Каждый сотрудник, имеющий доступ на сетевое оборудование, пользуется индивидуальной учётной записью.

В некоторых случаях оборудование может некорректно обрабатывать ААА-события от центральной системы, или же центральная ААА-система может быть недоступна в ходе каких-то работ. На этот случай на каждой единице сетевого оборудования есть локальная учетная запись супер-администратора. Пароль к этой учетной записи генерируется случайным образом при первой настройке этой единицы оборудования, и записывается в менеджер паролей.

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

Аппаратные проверки

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

display device
display interface transceiver
display device fan 
display device power

Вывод этих команд надо не просто посмотреть визуально и убедиться, что «всё хорошо», а сохранить вывод в файл для последующего сравнения с аналогичным файлом после работ.

L1: Проверка интерфейсов

Дальше мы проверяем количество интерфейсов коммутатора, находящихся в статусе up, и сохраняем в файл вывод краткого статуса всех интерфейсов:

display interface brief | i up | count 
display interface brief

L1: Проверка оптических интерфейсов

Как правило, в каждом 1G коммутаторе в дата-центрах Selectel есть 1-2 оптических трансивера. Оптические линки используются, например, для подключения аплинков коммутаторов доступа к коммутаторам агрегации.

Возможен такой вариант, что после выполнения цикла «выключить-включить» трансивер не выдает положенный сигнал в оптическую линию, или же происходит деградация фотодиода приемника. Такие случаи тоже надо предусматривать. Поэтому для каждого оптического интерфейса мы проверяем и сохраняем в файл информацию об уровнях сигналов:

display interface transceiver verbose

При выполнении этой команды мы проверяем, что среди установленных оптических трансиверов нет таких, для которых Transceiver Type – UNKNOWN и пустое значение поля Vendor Part Number. Есть большая вероятность, что такие трансиверы не заработают после обновления. В случае наличия таких трансиверов, их нужно заменить.

На коммутаторе AGG1 тоже надо проверить и сохранить статус оптических трансиверов и уровни сигналов в сторону коммутатора SW10.

L2: Проверка наличия МАС-адресов

Для того, чтобы быть более уверенным в том, что работоспособность коммутатора после обновления ПО осталась на прежнем уровне, необходимо проверить сколько сейчас МАС-адресов есть в таблице коммутации, ну и на всякий случай необходимо сохранить полный вывод содержимого таблицы коммутации.

display mac-address total-number 
display mac-address

Аналогичную проверку на количество МАС-адресов надо провести на интерфейсе коммутатора AGG1, на интерфейсе в сторону коммутатора SW10. После обновления коммутатора SW10 отсутствие МАС-адресов на коммутаторе AGG1 покажет на наличие проблем.

L3: проверка «живых» IP-адресов

Коммутатор — это L2 устройство, оперирующее только МАС-адресами. Но для выполнения работ нам мало проверок на наличие только МАС-адресов, мы хотим убедиться, что у клиентов после выполнения работ будет работать и L3, то-есть, серверы клиентов, доступные по IP до работ, должны быть доступны по IP и после проведения работ. Для этого нам придется выполнить два действия на двух разных устройствах.

Сначала мы получаем список МАС-адресов в таблице коммутации на SW10 (исключая интерфейс аплинка и служебный VLAN управления):

display mac-address | exclude 123 | exclude Eth-Trunk0

И затем сравниваем его с таблицей ARP записей на маршрутизаторе R:

show arp no-resolve | match "<список MAC-адресов через |>"

С внешнего устройства в интернете проверяем доступность по ICMP адресов из полученного списка, отбираем несколько адресов (по возможности — из разных VLAN’ов для разных клиентов) для контрольного теста после работ.

Заливка ПО на коммутатор и перезагрузка

Перед копированием ПО на коммутатор для обновления необходимо выполнить ряд шагов. Во-первых, мы сразу проверяем имеющееся место на диске (встроенной флешке) коммутатора. Если коммутатор в стеке — наличие места надо проверять на каждом члене стека.

dir flash:
dir 2#flash:

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

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

Save

После этого резервная копия конфигурации перекачивается в домашнюю директорию инженера, или проверяется наличие такой-же конфигурации в git.

scp sw_hostname:/vrpcfg.zip /directory

Теперь мы готовы к копированию нового ПО на коммутатор. Обычно мы производим копирование с Linux-сервера с использованием scp. Есть способы скопировать ПО и с использованием TFTP, и по Xmodem, но данный способ поддерживает большинство наших коммутаторов (не только Huawei):

scp CE5855EI-V200R005***.cc sw10.domain.selectel:/

Если коммутатор, на котором обновляется ПО, находится в стеке, то надо скопировать ПО с мастера на все члены стека:

copy flash:/CE5855EI-V200R005***.cc 2#flash:/

Наконец, надо указать файлы с ПО и, при необходимости, патчем как загрузочные для всех членов коммутатора:

startup system-software flash:/CE5855EI-V200R005***.cc all
startup patch flash:/CE5855EI-V200R005***.PAT all

И после этого проверить, что значения этих параметров для следующего запуска установились корректно:

display startup

Мы, как минимум, изменили конфигурацию запуска коммутатора. Поэтому мы сохраняем ее еще раз:

Save

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

Reboot

В ходе перезагрузки коммутатор анализирует конфигурационный файл, там написано, что загрузку надо производить в другой образ ПО, поэтому происходит запуск новой версии ПО. Новая версия ПО при первом запуске может произвести изменения в конфигурационном файле. Какие-то команды, изменения синтаксиса, может, перенос каких-то строк конфигурации в другое место конфига.

Обновили? Проверяем!

Проверка после перезагрузки

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

display startup

А вот теперь мы начинаем те же самые проверки, что и перед перезагрузкой, но сравниваем данные.

Аппаратные проверки

Мы смотрим на состав шасси, состояние модулей, БП, вентиляторов. Все должно работать так же, как и до обновления ПО.

display device
display interface transceiver
display device fan 
display device power

У нас есть предыдущий вывод этих команд, мы сравниваем текущий вывод с историческими данными.

L1. Проверка интерфейсов

display interface brief | i up | count 
display interface brief

Если мы видим отличия в количестве интерфейсов в статусе up, то это уже повод для дополнительных проверок. Как правило, все интерфейсы, которые работали перед обновлением ПО, должны работать и после. Редко кто на серверах настраивает только ручное включение интерфейсов после их падения. В случае, если к коммутатору подключено размещенное на colocation оборудование, то вероятность такого поведения выше.

L1: Проверка оптических интерфейсов

Для каждого оптического интерфейса мы проверяем и сравниваем с сохраненной информацию об уровнях сигналов:

display interface transceiver verbose

При выполнении этой команды мы проверяем, что все оптические трансиверы правильно определились новой версией ПО.

На коммутаторе AGG1 тоже надо проверить и сравнить с сохраненной информацией статус оптических трансиверов и уровни сигналов в сторону коммутатора SW10.

L2: Проверка наличия МАС-адресов

Проверить количество МАС-адресов в таблице коммутации и сравнить с тем, что было, надо как на самом коммутаторе SW10:

display mac-address total-number 
display mac-address

Так и на коммутаторе агрегации AGG1.

Резкое отличие (на 50% и больше) в количестве МАС-адресов на коммутаторе SW10 подскажет нам о наличии проблем с изучением МАС-адресов. Этот случай может привести к большим проблемам в виде большого количества unknown unicast трафика.
Если на коммутаторе SW10 все МАС-адреса есть, а на коммутаторе агрегации информации о них со стороны SW10 нет, то это говорит о наличии проблем с форвардингом трафика на коммутаторе SW10.

L3: проверка «живых» IP-адресов

В ходе проверки перед обновлением ПО мы сохранили несколько «живых» IP-адресов. Теперь мы выполняем аналогичную проверку, чтобы убедиться, что «живые» серверы с адресами «остались в живых» и после обновления ПО. С внешнего устройства в интернете проверяем доступность по ICMP адресов из ранее созданного списка.

И наконец

Анализ изменений конфигурации

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

display configuration changes running file vrpcfg.zip

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

Ура!

И вот теперь, после того, как все проверили, можно сохранять новую конфигурацию на коммутаторе.

Save

Эта конфигурация уже автоматически будет скопирована в git. И надо не забыть написать инженерам дата-центра, что консоли к коммутаторам можно демонтировать.