Как правильно обновлять серверы

23.12.2021

1

“Работает – не трогай” – сисадминская поговорка, защищающая сервис от “чешущихся” рук и многократно снижая аварийность. А еще – лишающая доступа к новым возможностям, улучшениям, оптимизациям и исправлениям. В том числе, касающихся безопасности. Поэтому, вот другая поговорка: “Если сервис не обновляется – то и не развивается”.

Софт должен поддерживаться. А значит – обновляться. Только так мы можем быть уверены, что текущая версия Flussonic – это лучшая версия, выпущенная когда-либо. И наши клиенты с нами согласны: каждый новый релиз Flussonic уже через неделю становится самым популярным. А три последних релиза работают на половине всех Flussonic в мире. И это при том, что обновления мы выпускаем раз в месяц!

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

Давайте проговорим действия, которые помогут:

  • снизить аварийность сервиса,
  • ускорить время восстановления,
  • или, даже, вовсе убрать страх перед обновлениями.

TL;DR

  • Читайте Changelog, он полезный и пишется для клиентов.
  • Делайте регулярные резервные копии.
  • Не обновляйтесь ночью в пятницу – вам никто не поможет.
  • В любой непонятной ситуации не паникуйте, пишите в поддержку. Лучше – до обновления.

1

Ознакомьтесь с Changelog

Changelog содержит краткий перечень изменений, а также описание ключевых изменений.

Пройдитесь глазами по списку. Особое внимание уделите тем возможностям, которые вы используете, перейдите по связанным ссылкам.

Например, в Flussonic 21.12 9 раз упоминается WebRTC. Выделите 10 минут, чтобы проверить на Staging работу WebRTC. Изучите, какие новые настройки помогут улучшить сервис. https://flussonic.com/changelog/

Сперва обновляем Staging

Staging отсутствует у большинства клиентов, и причина тому – экономия. Маленьким проектам хватает одного-двух серверов. И кратковременный простой одного из них может ничего не стоить для бизнеса. В таком случае, боевые сервера страдают от экспериментов с настройками, простаивают при обновлении основного ПО, при обновлении ОС, обслуживании железа, аппаратных сбоях.

А вот резервный сервер – это отличный Staging. Он находится в “холодном резерве”, либо подключается только в часы максимальной нагрузки. При штатной работе сервиса, можно отключить резервный сервер и на нем ознакомиться с новым релизом.

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

Далее переходим к инструментальному мониторингу.

Мониторинг

Мониторинг является обязательной частью сервиса. Без него выводы можно делать только из серии “ну вроде работает, я покликал”. Когда же есть мониторинг, разговор идет уже на другом уровне: “Ни одна из N метрик не отклонилась, все Z каналов захватываются, битрейт на входе и не изменился”.

У Flussonic есть встроенный Prometheus exporter и Grafana Dashboard. Это – современные инструменты для мониторинга. https://flussonic.com/doc/api/monitoring-flussonic-with-prometheus/

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

Худшее время для обновления

Если сервер только один, и нет возможности перевести нагрузку на другой узел, то остается только один вариант – обновляться в часы наименьшей нагрузки. Их можно определить, посмотрев на график трафика. Скорее всего, минимум нагрузки будет приходитьтся на глубокую ночь или ранее утро. Возможно, это будут выходные дни.

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

Обязательно заведите дополнительный сервер, чтобы появилась возможность:
1. выполнять обновления в рабочие часы
2. предварительно отрепетировать обновление на Staging.

Лучшее время для обновления

Обновление сервиса лучше планировать на начало рабочего дня, предварительно подготовившись. Проверьте, что:

  • Changelog изучен
  • Версия проверена на Staging
  • Мониторинг настроен
  • Бэкапы сделаны
  • Есть четкое понимание, как вернуть систему в исходное состояние
  • Нагрузка распределена между остальными узлами
  • Абоненты и другие отделы оповещены о работах.

Flussonic работает под Linux, поэтому обновление должен проводить системный администратор с уверенными навыками управления пакетами, чтения логов и редактирования текстовых файлов. Важно уметь работать с systemd, а также читать другие системные логи, кроме логов самого Flussonic. Если вы не уверены в своих навыках Linux, обратитесь в службу поддержки и получите подтверждение, что инженеры будут онлайн во время ваших работ по обновлению сервиса.

Итого: лучшее время для обновления – это любое время, когда вы подготовлены.

На практике, регулярное обновление занимает не более 5-15 минут, включая изучение Changelog.

3

Бэкапы не забыли?

Частая ошибка – не делать резервную копию Flussonic. Почему об этом забывают? Flussonic Media Server не хранит персональные данные, не хранит результаты работы людей (например, код или тексты), и это не файлообменник. Flussonic можно настроить один раз и забыть, он послушно перекладывает байты со входа на выход и не напоминает о себе. До тех пор, пока не случится “авария”:

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

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

Поэтому бекапы делаем, каждый день:

  • Flussonic: flussonic.conf выгружаем с помощью crontab. Дополнительно, будет хорошо забирать конфигурацию по API.
  • Watcher: делаем резервную копию базы данных PostgreSQL, выгружаем на надежное хранилище или на другой сервер. Попробуйте восстановить сервис с нуля из бэкапов на другом, “чистом” сервере. Так вы будете уверены, что бэкап содержит все необходимые данные.

Откатываем сервис

Что-то пошло не так? Пакет не установился? На мониторинге обнаружили просадку трафика? Перестали работать некоторые источники? В поддержку начали звонить абоненты? Не паникуем, хладнокровно заходим в веб-интерфейс Flussonic и на странице Upload debug своими словами описываем ситуацию. Полученный ID отправляем на support@flussonic.com или создаем тикет через ЛС.

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

Ситуация критическая? Устанавливаем предыдущую версию Flussonic, именно предыдущую, а не годовалой давности.

Будьте готовы, что потребуется откатить зависимости, а flussonic.conf или база данных Watcher будут несовместимы, т.к. их структура обновилась под новый релиз. В таких случаях мы делали бэкапы и тренировались на резервных и Staging-серверах.

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

Не обновляйте все сразу

- Алло, поддержка, помогите откатиться, я обновился и у меня сервис упал!
- Да, хорошо, сейчас посмотрим… Ваш конфигурационный файл содержал более неиспользуемые опции. Я откатил ваш сервер, прошу ознакомиться со списком изменений и подготовиться к обновлению.
- А что делать с остальными 11 серверами?

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

Никогда не обновляйте все сервера одновременно, это прямой путь положить сразу весь сервис. Обновите один сервер, подождите некоторое время – и повторите со следующим. Если у вас много серверов, то обновления стоит делать с помощью Ansible (мы научим или возьмем на расширенную поддержку).

Автор:
Максим Клюшков
Ключевые слова:
backup upgrade