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

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

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

Дисклеймер: в предыдущей статье, для конкретики, мы рассматривали процедуру подготовки новой площадки на примере типичного интернет-магазина, работающего на 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-записи (чтобы после отключения проксирования на старой площадке трафик не «вернулся» на старую инфраструктуру).

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

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

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

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

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