Чек-лист: что проверить перед переездом IT-инфраструктуры

Решились на переезд? Тогда не забудьте убедиться, что сложили все вещи по списку :-) В первой части ^[1] нашей дилогии про миграцию ^[2] мы рассмотрели причины и предпосылки для любого переезда; обсудили подготовку нового окружения, разворачивание проекта в новой инфраструктуре, а также базовые этапы тестирования работы вашего проекта на новой площадке. А здесь, в заключительной статье, предлагаем ознакомиться с пошаговым планом переключения трафика вашего проекта на новую инфраструктуру.

Итак, делимся стандартным «протоколом»: в каком порядке производить определенные действия и почему, на какие критические моменты обращать внимание, какие операции и проверки нужно произвести уже ПОСЛЕ переключения. А на десерт — примеры конфигурационных файлов для инструментов, используемых в процессе переключения.

Дисклеймер: в предыдущей статье ^[1], для конкретики, мы рассматривали процедуру подготовки новой площадки на примере типичного интернет-магазина, работающего на LEMP-стеке ((Linux, Nginx, MySQL, PHP). И сейчас продолжим рассматривать процедуру переключения, оставаясь на этом же стеке.

Пред-переключательные проверки

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

Проверка синхронизации файлов

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

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

#коечтополезное
пример конфигурации lsync:

settings {
       logfile    = "/var/log/lsyncd/lsyncd.log",
       statusFile = "/var/log/lsyncd/lsyncd.status",
        nodaemon   = false,   insist = true
}

sync {
     default.rsync,
     source="/path/to/source/",
     target="root@host:/path/to/target/",
     delete=false,
     rsync     = {
         archive  = true,
         sparse   = true,
         update   = true,
         protect_args    = true,
         temp_dir = '/var/www/lsyncd',
     },
     delay=5
 }

Проверка репликации БД

Аналогично предыдущему пункту для проверки того, что репликация работает корректно (естественно, при отсутствии алертов ошибок репликации), необходимо:

1. сравнить размеры баз данных (du -sch /var/lib/mysql);
2. выборочно сравнить количество записей в таблицах на старой и новой базе данных;
3. дополнительно можно добавить несколько тестовых записей в БД и убедиться, что они появились в новой БД.

Директории для сессий, временных файлов, крон-заданий

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

Кроме того, проверьте, что все необходимые крон-задания перенесены и закомментированы (смотрим в /etc/cron/*, /var/spool/cron/*).

Переключение

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

1. Отключаем все крон-задания на старой площадке (иначе, после включения их на новой площадке, есть вероятность дубликации задач, и тогда, как мы говорили в предыдущей статье, дублирование пользовательских нотификаций, двойные списания денег по подписке и прочие плохие вещи вам обеспечены).
2. Выключаем на новой БД read_only, проверяем, что его нет в my.conf (иначе, после переключения соединений на новую БД, будут недоступны все операции на запись/обновление/удаление) mysql> SET GLOBAL read_only = 0.
3. Включаем проксирование на web-сервере со старой площадки на новую для бесшовного переключения трафика (ну, и для возможности откатиться назад без изменения ДНС-записей).

   Пример конфигурации nginx для проксирования:

   server {
     listen 80 default_server;
     server_name _;
       location / {
         access_log off;
         proxy_pass http://new_ip;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       }
   }
   
   server {
     listen 443 ssl;
     server_name _;
       location / {
         access_log off;
         ssl_certificate     /path/to/cert/fullchain.crt;
       ssl_certificate_key /path/to/cert/cert.key;
         proxy_pass https://new_ip;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       }
   }

4. Включаем крон-задания (убедившись, что все настройки, расписание, пути для вывода корректные).
5. Проверяем работоспособность сайта на новой площадке:
   • базовая проверка: открываются страницы сайта, нет 404-ых ошибок на страницах конкретных новостей или товаров, нет 404-ых ошибок на статике (изображения, пользовательские файлы).
   • проверка аутентификации/авторизации: пользователей не «выкидывает» из личного кабинета, данные пользователей загружаются корректно.
   • проверка крон-заданий и работы сервисов очередей: различные уведомления, списания, генерация отчетов и т д выполняется корректно.

   Если в результате проверок вы убедились, что сайт работает корректно, все необходимые данные перенесены и вы не получаете негативный фидбек от пользователей вашего продукта, можно переходить к финальной стадии переезда…

6. Отключаем синхронизацию со старой инфраструктурой:
   • отключаем файловую синхронизацию (lsync) на старом сервере; убеждаемся, что его нет в автозагрузке
   • на новом сервере БД отключаем репликацию:
     mysql> STOP SLAVE
mysql> RESET SLAVE [ALL]
   • отключаем алерты об ошибках синхронизации (как на реплике БД, так и на lsync) в системе мониторинга.
7. Переключаем DNS-записи (чтобы после отключения проксирования на старой площадке трафик не «вернулся» на старую инфраструктуру).

Вместо выводов

Вот мы с вами, уважаемые читатели, и закончили миграцию ^[2] нашего проекта на новую инфраструктуру. Естественно, в процессе переключения не исключен так называемый «человеческий фактор». И уже после переключения, проверок работоспособности вашего сайта, мы настоятельно рекомендуем провести «финальную ревизию» перед отключением старой инфраструктуры. А именно:

• убедиться, что отключены все механизмы синхронизации данных и файлов;
• проверить конфигурацию системного ПО, баз данных, веб-сервера, application-сервера, почтовой подсистемы;
• провести «ревизию» dns-записей;
• актуализировать данные в системе мониторинга;
• проверить настройки резервного копирования (бекапов)

Хоть мы и рассмотрели процедуру миграции на одном из примитивных кейсов (LEMP стек с минимальным уровнем абстракции), общие принципы для миграции более сложных инфраструктур будут максимально похожи с рассмотренным нами кейсом.

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