Миграционный контроль: о чём нужно помнить при переезде на новую инфраструктуру

Причины для смены инфраструктуры могут быть самые разные. Например:

• интернет-магазин становится всё популярнее, и текущего серверного оборудования не хватает, чтобы качественно обслуживать всех пользователей;

• впереди «высокий сезон» («чёрная пятница» для e-commerce, новогодние праздники для кулинарных порталов и т.д.), и чтобы выдержать увеличение нагрузки, нужно временно переехать на большие мощности;

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

• архитектура проекта становится сложнее, и решено использовать вместо standalone-решений managed-сервисы от облачных провайдеров (базы данных, системы очередей, файловое хранилище, системы доставки контента) или полностью перенести проект с on-premise инфраструктуры в облако.

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

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

В этой статье собрали best practices и опыт ITSumma по миграции веб-проектов, которые, надеемся, помогут избежать проблем и обойтись без бессонных ночей и новых седых волос для вашей IT-команды.

В большинстве случаев миграция инфраструктуры веб-проекта состоит из четырёх основных этапов:

• подготовка новой инфраструктуры, разворачивание в ней копии проекта, проверка работоспособности;

• подготовительные работы перед переключением;

• пошаговое переключение (с указанием конкретной последовательности шагов);

• проверка работоспособности проекта в новом окружении после переключения.

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

Для конкретики возьмём пример типового интернет-магазина на Битриксе, работающего на популярном стеке: Linux — PHP — MySQL — Nginx (LEMP-стек), развернутого на on-premise железе. Переезжать будем на более мощные серверы в другой дата-центр.

Готовим новое окружение

В новой инфраструктуре понадобится настроить всё, чем вы уже пользуетесь. Желательно в новых версиях, но не нарушая совместимость. Пройдёмся по пунктам.

Операционная система — очевидно, что новая инфраструктура должна быть построена на той же операционной системе, что и текущая. Но если возможно — обновленной версии, чтобы устранить уязвимости. Это поможет избежать проблем с обслуживанием серверов, работой привычных пакетных менеджеров и т д

Админ-панель из новой инфраструктуры лучше исключить. Использование панелей для администрирования, таких как, например, cpanel, vesta, ispmanager, накладывают ограничения на стек используемых технологий и конфигураций.

Базовое ПО при настройке нового окружения нужно будет воспроизвести в новой инфраструктруе. Версии необходимого базового ПО, веб-сервера, application-сервера, БД, должны быть не ниже, чем в текущем окружении. Но при этом убедитесь, что в случае обновления версии какого-либо компонента, не нарушится работа проекта (например, более новая версия MySQL может оказаться несовместимой с текущими настройками). Также убедитесь, что установлены все необходимые модули и расширения для PHP, nginx, Apache и т д.

Дополнительное ПО: например, системы кеширования (Memcached, Redis), ПО для поиска (Elasticsearch, Sphinx) нужно не только перенести, но и обязательно проверить настройки. Например, если Memcache не выделить необходимый объем оперативной памяти, то вполне вероятно возникновение eviction’ов и, как следствие, фактически отсутствие кеширования.

Кастомные сервисы Systemd и прочее. Нужно убедиться, что все необходимые асинхронные сервисы, как например, e-mail-рассылки через систему очередей, node.js-сервисы для веб-сокетов, перенесены на новую площадку.

Файлы конфигураций, например, PHP и nginx понадобится синхронизировать на новое окружение. В частности, проверьте, не прописаны ли в файлах конфигурации конкретные IP-адреса (которые при переезде на новую площадку изменятся). Убедитесь, что файлы конфигурации корректны (например, с помощью nginx -t / apachectl configtest и т.д.).

Таймзоны в конфигурациях MySQL, PHP такие же, как и на старом окружении. Расхождение в таймзонах может привести к ошибкам как на уровне работы серверного ПО, так и на уровне бизнес-логики. Например, при активной репликации баз данных (запись в мастер, чтение со слейва) разные таймзоны на узлах могут привести к «разваливанию» реплики. С точки зрения бизнес-логики ошибка в конфигурировании таймзоны может привести к полному бардаку в транзакциях — например, купленным в будущем товарам, рассинхроне внутренних и банковских данных и т.д.

Директории для временных файлов, сессий. Если на новом сервере не будет директорий для временных файлов и сессий, или же корректно установленных прав для работы с ними, то пользователи сервиса не смогут авторизоваться или элементарно загрузить на портал аватарку или фото товара.

SSH/FTP-пользователи, /etc/sudoers — при миграции инфраструктуры из одной площадки в другую необходимо удостовериться, что все пользователи и их ключи перенесены со старых серверов на новые. Также необходимо убедиться, что конфигурация sudo на новых площадка идентична старым. Параллельно с этим переносом своим клиентам мы обычно предлагаем актуализировать список пользователей, которые имеют доступы к серверам. К сожалению, при увольнении или смене роли сотрудника старые доступы нередко забывают «подчищать».

IPTables. Если в старой инфраструктуре использовались кастомные правила iptables (например, для ограничения подключения к БД с конкретного набора адресов), не забудьте аналогично сконфигурировать их на новой площадке. Если же вы не используете такого рода правила — всё равно, убедитесь что у вас не открыт публичный доступ к критичным портам.

 

Разворачиваемся на новом месте

Синхронизация файлов. Когда готова «базовая» конфигурационная площадка в новой инфраструктуре, можно начинать переносить кодовую базу. Для начала рекомендуем убедиться, что значение настройки /proc/sys/fs/inotify/max_user_watches выставлено корректно — а именно, как минимум, 8192 вотчеров на 1GB оперативной памяти на сервере. Например, если в в вашем сервере объем допустимый объем оперативной памяти 128GB, количество вотчеров выставлено на значение 1048576 (максимально допустимое). Иначе, если вотчеров будет недостаточно, а директорий для синхронизации — много (а обычно их много), lsync попросту не запустится. Однако, начиная с версии ядра 5.11, данный параметр умеет автоматически "подстраиваться" под количество оперативной памяти на сервере. 

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

GIT. Если используете системы контроля версий (а нам кажется, что они есть в 100% случаев), стоит убедиться, что на новой площадке на уровне веб-сервера закрыт публичный доступ до служебных директорий вида .git/… Потому что вы точно не хотите фигурировать в историях из интернета, где злоумышленники получили доступ к исходному коду сайта.

Базы данных. После того как вы перенесли исходный код и настроили его репликацию на новый сервер, аналогичные действия необходимо произвести и с базами данных. В первую очередь, на старом и новом сервере необходимо включить бинлоги и убедиться, что их формат не приводит к ошибкам в работе вашего веб-сайта. После этого необходимо удостовериться, что настройки БД (в частности, для MySQL: innodb_buffer_pool_size, innodb_file_per_table) на новом сервере совпадают с значениями на старом сервере. И по возможности применить рекомендации mysqltuner.pl. Также, перед запуском необходимо убедиться, что на новом сервере sql_mode совпадает с соответствующим значением на старом сервере (иначе sql-запросы могут вести себя по-разному и результат их выполнения может быть неожиданным). И последним шагом необходимо поднять реплику master-slave с последнего доступного бэкапа базы данных и убедиться, что приложение работает с нужной базой данных (чтобы не получилось, что сайт на новой инфраструктуре обращается к старой базе данных на старой площадке).

Cron-задания. После того, как вы по аналогии со всеми предыдущими пунктами перенесете настройки cron-заданий и вызываемые ими скрипты, нужно убедиться, что вызовы всех заданий ЗАКОММЕНТИРОВАНЫ. Иначе может произойти то самое дублирование уведомлений, двойное списание денег и всё то, что может расстроить и разозлить пользователей.

Почтовый сервер. Если для e-mail-рассылок используется локальный сервер или сервер текущего хостера, нужно перенести соответствующий компонент и воспроизвести отправку писем с новой площадки. Это поможет убедиться, что сообщения содержат все необходимые заголовки и после переключения они не станут улетать в спам.

DNS и его конфигурирование — один из последних этапов при подготовке к миграции инфраструктуры на новую площадку. Сначала необходимо убедиться, что на старых серверах не поднят NS-сервер, а если поднят, то его также нужно перенести — иначе после переезда и отключения старого сервера полностью отключится резолвинг доменных имен и работа проекта остановится. Также рекомендуем сконфигурировать TTL для доменных имен до допустимого минимума в 60 секунд. Тогда при переключении трафика на новую площадку DNS-кэши почистятся максимально быстро. Если планируется полноценный «бесшовный» перенос, то на старых серверах надо настроить (но пока не включать) проксирование трафика на новые серверы, чтобы вне зависимости от настроек TTL можно было максимально быстро переключить пользовательский трафик на новую площадку.

Финальные проверки 

Когда мы полностью сконфигурировали новую рабочую площадку и развернули на ней копию проекта, нужно всё перепроверить. Минимальный набор необходимых действий выглядит так: 

• произвести рестарт серверов — чтобы проверить, что после рестарта запускаются все необходимые сервисы и компоненты и не запускаются ненужные (например, lsync);

• проверить базовую работу сайта — страницы открываются, нет 404-ых ошибок на страницах конкретных новостей, товаров и т.д.;

• проверить аутентификацию/авторизацию на новой версии сайта — пользователей «не выкидывает» из админки сайта, на личные страницы подгружаются все данные профиля и можно полноценно пользоваться продуктом;

• провести тестовый запуск каких-нибудь задач по расписанию с тестовыми данными — чтобы уведомления о списании денег не ушли реальным живым пользователям.

Вместо выводов: а почему не IaC?

Конечно, в идеальном IT-мире вся инфраструктура подчиняется подходу Infrastructure as a Code, который снимает все перечисленные в статье проблемы и позволяет не настраивать новое окружение вручную.

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

Во-вторых, в некоторых проектах ощутимо «дешевле» произвести сетап «руками», чем поддерживать в актуальном состоянии IaaC. Но если в таком случае все же понадобилась миграция, мы настоятельно советуем параллельно с подготовкой новой инфраструктуры запустить процесс описания инфраструктуры через Terraform или Ansible. Системы управления конфигурациями позволят гораздо быстрее и, что важно, более контролируемо при необходимости подключить дополнительные мощности или перебалансировать нагрузку. 

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

Именно в таких неидеальных ситуациях и нужен чек-лист — чтобы независимо от legacy проекта поднять рабочую и корректную инфраструктуру в новом окружении. Для этой статьи мы обобщили опыт многих наших инфраструктурных проектов: и по переезду, и по разворачиванию новых, и по обновлению. Надеемся, он окажется полезным и позволит обойти хотя бы некоторые подводные камни. 

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