Чек-лист: что проверить перед переездом 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

 }

 

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

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

во-первых, сравнить размеры баз данных (du -sch /var/lib/mysql); 

во-вторых, выборочно сравнить количество записей в таблицах на старой и новой базе данных; 

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

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

Финально, перед началом самого переключения, необходимо еще раз убедиться, что на директории для временных файлов и сессий установлены корректные права (иначе ваши пользователи не смогут пройти процедуры аутентификации/авторизации или загрузить какой либо контент на сайт).
Кроме того, проверьте, что все необходимые крон-задания перенесены и закомментированы (смотрим в /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 стек с минимальным уровнем абстракции), общие принципы для миграции более сложных инфраструктур будут максимально похожи с рассмотренным нами кейсом.

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