DevOps для Обновления и Оптимизации Инфраструктуры (железные сервера)

Предварительное техническое задание для DevOps

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

Background проекта

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

Проблемы в существующем решении:

- Текущий сервер требует замены SSD-дисков, которые уже определенное время бросают Warning (собственно, это и актуализировало поиск DevOps). Рассматриваем вариант либо с временным переключением на резервную копию, замену дисков и полную установку нового дистрибутива и всего приложения, либо покупку новых 2–3  серверов, разворачивании полной архитектуры на них и переключение трафика (преимущество второго пути в удобстве, контроле, возможности тестов и возможность взять более быстрые диски и процессор, недостаток – за покупку новых серверов придется доплачивать за установку). Как вариант – развернуть архитектуру на одном или двух новых серверах, переключить трафик на них, затем обновить диски на старом сервере и использовать его как резервный с репликацией MySQL.

- На сервере используется устаревшая CentOS 7. Возможно, стоит обновиться к Rocky/Alma или даже рассмотреть переход на Debian (этот вопрос входит в часть консультации).

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

- Docker используется только для MySQL, остальные приложения устанавливались через yum со всеми недостатками подобного решения (неожиданные обновления, невозможность создать управляемую среду, необходимость конфигурировать каждое приложение).

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

- Сейчас модель работы: один главный сервер и один вспомогательный в другом дата-центре. В случаи аварии переключение на резерв происходит вручную через написанную нами панель управления, которая меняет IP-адреса через API Cloudflare. Вспомогательный сервер работает в режиме репликации. Clickhouse не использует репликацию (на этапе создания архитектуры проекта для этого надо было доустанавливать Zookeeper, который очень капризный, поэтому более простым решением показался самостоятельный лог, который параллельно исполняется на резервном сервере). Надо будет принять решение, мы оставляем status quo или все же развернем три Clickhouse-экземпляра в кластер с использованием координатора Clickhouse keeper.

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

Задачи

• Консультация. Описание текущего проекта, его проблем и возможных путей решения.
• Создаем серверную архитектуру решения. Решить, какова будет модель работы MySQL (сейчас односторонняя репликация) и Clickhouse (разворачиваем кластер с двух серверов в дата-центре №1 и один в дата-центре №2 или оставляем текущую модель двух независимых серверов с параллельной записью).
• Создаем Docker-compose скрипты. Docker image для настройки PHP-FPM уже существует, вероятно, его часть можно будет переиспользовать. Надо принять решение, у нас будет один Nginx, который будет обслуживать три проекта (это будет потребовать отдельных папок конфигов, каждый со своими доменами для каждого из проектов) или же один Nginx, который будет проксировать запрос на внутренние контейнеры с Nginx (потенциально узнать, какие при этом возникают задержки). Образы, которые будут нужны: Nginx, MySQL, Clickhouse, PHP-FPM, Redis. Сейчас для запуска долгоиграющих процессов используется systemctl, вероятно, будет смысл сделать решение на supervisord или другом решении?
• Разработать решение, чтобы добавление новых доменов было более автоматизированным (в частности, генерировать для них LetsEncrypt-сертификат, после чего автоматически добавлять в конфиги Nginx).
• Консультация по MySQL. Каждый проект будет использовать свой экземпляр MySQL или использовать общий? У нас есть относительно небольшая бизнес-часть в MySQL и несколько больших таблиц логов. Проконсультироваться, стоит вынести таблицы логов в отдельную базу данных или даже в отдельный экземпляр MySQL со своими настройками (это может помочь делать более быстрое разворачивание новой реплики, поскольку сейчас для разворачивания реплики нужно сделать полный бэкап, который занимает десятки гигабайт и затем разворачивается несколько часов, что может быть критичным).
• Принимаем решение по количеству серверов, параметрах, их локации. Вероятно, стоит будет докупить 1, 2 или 3 сервера. Организационную часть покупки берем на себя, надо будет выбрать лучший баланс между ценой и мощностью серверов.
• Тюнинг сервера для максимальной скорости обслуживания ответов. Настройка сетевых параметров ядра под задачи приложения, настройка scheduler, режима работы процессора/памяти, возможно – настройка RAID, если это будет сделано неоптимально «с коробки».
• Подготовка решения по автоматическому failover на резервный сервер (частично это будет реализовано вместе командой разработчиков, но вероятно потребуется настройка репликации и консультация по оптимальному пути, как все это настроить).
• Настройка MySQL-конфига для более оптимальной работы на нужном железе.
• Сейчас используется скрипт Deployer, который по запросу выкачивает master-ветку и делает деплой с возможностью отката и перезапускает все нужные процессы. Обсудить решение и есть ли возможности более оптимального пути, который будет подходить для команды разработчиков.
• Обсудить возможность создания тестовой среды, на которой можно будет проверить новый функционал для менеджеров и тестировщиков.
• Установка системы мониторинга (обсудить существующие решения, желательно без излишней модели монетизации, в идеале self-hosted решения, а не SaaS, например, Grafana + Prometeus, Zabbix или другое). Система должна показывать общую ситуацию по всем серверам – нагрузка, количество трафика, среднее время запросов на определенных endpoint, а также присылать уведомления в случае создания критичных ситуаций.
• Backup-решение существует, но вероятно нужно будет его оптимизировать с учетом новой конфигурации и создать скрипты для более быстрого разворачивания данных с бэкапов.
• Все вышеуказанные шаги (в частности, особенности тюнинга сервера и процедура разворачивания нового экземпляра приложения) должны быть тщательно задокументированы, чтобы все шаги мог воспроизвести технический лидер в случае критической необходимости или кто-то другой достаточно компетентный в случае отсутствия того, кто настроил систему. То есть, система не должна быть закрытым ящиком: «кто-то несколько лет настроил систему и никто не знает, почему так, а не иначе и непонятно, как это модифицировать или перенести на другой сервер».