Миграция серверов: легко и безболезненно
Иногда приходится перетряхивать инфраструктуру, делая это самым радикальным образом. Такой шаг устраняет недостатки старых версий вашей системы, позволяет обновить технологии и снизить расходы. Рассмотрим основные причины, которые могут подтолкнуть к миграции серверов:
Миграция с помощью контейнеров
Если использовать преимущества контейнеризации и систем оркестрации, переезд пройдёт намного легче и безболезненнее. В случае с тем же Kubernetes все нужные ОС со всеми настройками будут упакованы и готовы к перемещению. Останется развернуть новые копии на новых серверах. Да, не обойтись без правок в настройках подключений к тем же БД, но эти правки будут минимальны.
Кроме того, все нужные настройки сервисов вы сможете сделать заранее и зафиксировать с помощью файлов Deployment, если речь идёт, опять же, о Kubernetes.
Что делать, если контейнеров нет?
Если контейнеры не используются, есть альтернативные варианты переезда: 1. Перенос образов серверов. Делаются полные слепки состояния каждой ВМ вместе с файлами, конфигами и программами. Потом создаётся новый сервер, для чего используется образ старого. На выходе — готовая к работе машина с нужными настройками (итоговые донастройки минимальны). 2. Применение средств автоматизации развёртывания (Ansible, SaltStack, Chef, Terraform). Все эти средства функционируют по схожей концепции — вы описываете нюансы настройки вашей системы посредством специальных файлов. В файлах указываются аспекты развёртывания сервера. Такие системы управления развёртыванием способны сами «ходить» на серверы в сети, применяя нужные команды и делая это автоматически. Решение более надёжно, чем применение образов, плюс упрощает настройки и является более универсальным. 3. Упрощение миграции посредством DevOps-практик. Речь идёт о методологии GitOps. При её использовании нужные конфигурационные файлы хранятся в Git-репозиториях, то есть развёртывание инфраструктуры производится скриптами строго из репозитория. Методика дополняется системами автоматизации типа Ansible и Chef, о которых уже упоминали. Стоит добавить, что хранить конфигурационные файлы и настройки в Git — занятие трудоёмкое, но усилия окупаются. 4. Помощь облачного провайдера. Когда речь идёт о переносе сложной инфраструктуры в облако, лучше всего обратиться к выбранному провайдеру. Он подробно проконсультирует относительно миграции виртуальных машин. При необходимости — предложит автоматизированные сервисы для переноса инфраструктуры в режиме real time, не останавливая работу приложения.
Делаем выводы
Главное, что следует сказать — безболезненная миграция серверов потребует от вас системного подхода. При этом: 1. Чаще всего миграция требует определённых вложений в инструменты поддержания и управления вашей инфраструктурой. 2. Если в проекте не применяются системы управления инфраструктурой, внедрите их перед миграцией. Это однозначно окупится, т. к. проблем во время переезда будет меньше («лучше день потерять и потом за 5 минут долететь»). 3. Если речь идёт о миграции в облако сложной инфраструктуры, воспользуйтесь помощью выбранного провайдера либо автоматизированными облачными платформами для переноса приложений, данных и серверов.
Статья написана по материалам блога Mcs.Mail.ru.