Как правильно обновлять серверы
“Работает – не трогай” – сисадминская поговорка, защищающая сервис от “чешущихся” рук и многократно снижая аварийность. А еще – лишающая доступа к новым возможностям, улучшениям, оптимизациям и исправлениям. В том числе, касающихся безопасности. Поэтому, вот другая поговорка: “Если сервис не обновляется – то и не развивается”.
Софт должен поддерживаться. А значит – обновляться. Только так мы можем быть уверены, что текущая версия Flussonic – это лучшая версия, выпущенная когда-либо. И наши клиенты с нами согласны: каждый новый релиз Flussonic уже через неделю становится самым популярным. А три последних релиза работают на половине всех Flussonic в мире. И это при том, что обновления мы выпускаем раз в месяц!
Конечно, обновление ПО – это риск. И речь здесь не только про аварии. Изучить изменения, найти привычные элементы в интерфейсе, конфигурации, API – все это занимает время. Несмотря на то, что большинство клиентов и обновляется без нашей помощи, к команде поддержки регулярно обращаются с запросом экстренной помощи после обновления.
Давайте проговорим действия, которые помогут:
- снизить аварийность сервиса,
- ускорить время восстановления,
- или, даже, вовсе убрать страх перед обновлениями.
TL;DR
Ознакомьтесь с 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. Это – современные инструменты для мониторинга.
Итого, на этом шаге вы подключаете мониторинг всех серверов, настраиваете уведомления. Изучите часы максимальной нагрузки, cпланируйте обновление серверов, смотрите на метрики – не ждите звонка в поддержку.
Худшее время для обновления
Если сервер только один, и нет возможности перевести нагрузку на другой узел, то остается только один вариант – обновляться в часы наименьшей нагрузки. Их можно определить, посмотрев на график трафика. Скорее всего, минимум нагрузки будет приходитьтся на глубокую ночь или ранее утро. Возможно, это будут выходные дни.
Это и есть худшее время для обновления: придется работать сверхурочно, базовая поддержка будет недоступна. А в случае возникновения ошибки, начнется паника – ведь клиенты скоро начнут возвращаться, и время на устранение неполадок ограничено.
Обязательно заведите дополнительный сервер, чтобы появилась возможность:
1. выполнять обновления в рабочие часы
2. предварительно отрепетировать обновление на Staging.
Лучшее время для обновления
Обновление сервиса лучше планировать на начало рабочего дня, предварительно подготовившись. Проверьте, что:
- Changelog изучен
- Версия проверена на Staging
- Мониторинг настроен
- Бэкапы сделаны
- Есть четкое понимание, как вернуть систему в исходное состояние
- Нагрузка распределена между остальными узлами
- Абоненты и другие отделы оповещены о работах.
Flussonic работает под Linux, поэтому обновление должен проводить системный администратор с уверенными навыками управления пакетами, чтения логов и редактирования текстовых файлов. Важно уметь работать с systemd, а также читать другие системные логи, кроме логов самого Flussonic.
Если вы не уверены в своих навыках Linux, обратитесь в службу поддержки и получите подтверждение, что инженеры будут онлайн во время ваших работ по обновлению сервиса.
Итого: лучшее время для обновления – это любое время, когда вы подготовлены.
На практике, регулярное обновление занимает не более 5-15 минут, включая изучение Changelog.
Бэкапы не забыли?
Частая ошибка – не делать резервную копию 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 (мы научим или возьмем на расширенную поддержку).