sergei_sporyshev 7 июн 2022 в 10:52

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

5 мин

2.3K

Блог компании ITSummaТестирование IT-систем*Системное администрирование*IT-инфраструктура*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/*).

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

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

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

Включаем проксирование на 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;
    }
}

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

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

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

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

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

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

Теги:

Хабы: