Решились на переезд? Тогда не забудьте убедиться, что сложили все вещи по списку :-) В первой части нашей дилогии про миграцию мы рассмотрели причины и предпосылки для любого переезда; обсудили подготовку нового окружения, разворачивание проекта в новой инфраструктуре, а также базовые этапы тестирования работы вашего проекта на новой площадке. А здесь, в заключительной статье, предлагаем ознакомиться с пошаговым планом переключения трафика вашего проекта на новую инфраструктуру.
Итак, делимся стандартным «протоколом»: в каком порядке производить определенные действия и почему, на какие критические моменты обращать внимание, какие операции и проверки нужно произвести уже ПОСЛЕ переключения. А на десерт — примеры конфигурационных файлов для инструментов, используемых в процессе переключения.
Дисклеймер: в предыдущей статье, для конкретики, мы рассматривали процедуру подготовки новой площадки на примере типичного интернет-магазина, работающего на 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 стек с минимальным уровнем абстракции), общие принципы для миграции более сложных инфраструктур будут максимально похожи с рассмотренным нами кейсом.
А ещё мы своим заказчикам рекомендуем после миграции проверить всё не только руками, но и иными инструментами — проведя нагрузочное тестирование. О том, как мы это делаем и с какими сюрпризами доводилось сталкиваться в последнее время, расскажем в ближайших публикациях.
Автор: Сережа
