0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Иногда приходится перетряхивать инфраструктуру, делая это самым радикальным образом. Такой шаг устраняет недостатки старых версий вашей системы, позволяет обновить технологии и снизить расходы. Рассмотрим основные причины, которые могут подтолкнуть к миграции серверов: 1.<strong>Так требует договор</strong>. Случается, что в течение конкретного промежутка времени нужно перевести вашу инфраструктуру в дата-центр какой-нибудь другой страны. Или же бизнес был куплен другой компанией, следовательно, возникла необходимость перевести обслуживание в дата-центр нового собственника. 2.<strong>Возникли проблемы с обслуживанием</strong>арендованных серверов. Проблемы бывают разные: неадекватное повышение цен, ухудшение работы оборудования, критические ошибки системных администраторов - всего не перечесть. Результат - справедливое недовольство с вашей стороны. 3. Перестройка инфраструктуры даёт<strong>важное конкурентное преимущество</strong>. Миграция открывает пути к повышению скорости, улучшению качества обслуживания, предоставляет доступ к новым сервисам и облачным технологиям, позволяет существенно снизить расходы и т. п. 4.<strong>Требуется глубокая перестройка инфраструктуры</strong>. Запланирована смена технического стека, операционных систем и систем управления БД, перестройка архитектуры, бизнеса и т. д. 5.<strong>Необходимо улучшить масштабируемость либо оптимизировать стоимость эксплуатации</strong>сервиса посредством использования облачных технологий и контейнеров, путём замены физических серверов виртуальными и пр.</p>
1
<p>Иногда приходится перетряхивать инфраструктуру, делая это самым радикальным образом. Такой шаг устраняет недостатки старых версий вашей системы, позволяет обновить технологии и снизить расходы. Рассмотрим основные причины, которые могут подтолкнуть к миграции серверов: 1.<strong>Так требует договор</strong>. Случается, что в течение конкретного промежутка времени нужно перевести вашу инфраструктуру в дата-центр какой-нибудь другой страны. Или же бизнес был куплен другой компанией, следовательно, возникла необходимость перевести обслуживание в дата-центр нового собственника. 2.<strong>Возникли проблемы с обслуживанием</strong>арендованных серверов. Проблемы бывают разные: неадекватное повышение цен, ухудшение работы оборудования, критические ошибки системных администраторов - всего не перечесть. Результат - справедливое недовольство с вашей стороны. 3. Перестройка инфраструктуры даёт<strong>важное конкурентное преимущество</strong>. Миграция открывает пути к повышению скорости, улучшению качества обслуживания, предоставляет доступ к новым сервисам и облачным технологиям, позволяет существенно снизить расходы и т. п. 4.<strong>Требуется глубокая перестройка инфраструктуры</strong>. Запланирована смена технического стека, операционных систем и систем управления БД, перестройка архитектуры, бизнеса и т. д. 5.<strong>Необходимо улучшить масштабируемость либо оптимизировать стоимость эксплуатации</strong>сервиса посредством использования облачных технологий и контейнеров, путём замены физических серверов виртуальными и пр.</p>
2
<h2>Миграция с помощью контейнеров</h2>
2
<h2>Миграция с помощью контейнеров</h2>
3
<p>Если использовать преимущества контейнеризации и систем оркестрации, переезд пройдёт намного легче и безболезненнее. В случае с тем же Kubernetes все нужные ОС со всеми настройками будут упакованы и готовы к перемещению. Останется развернуть новые копии на новых серверах. Да, не обойтись без правок в настройках подключений к тем же БД, но эти правки будут минимальны.</p>
3
<p>Если использовать преимущества контейнеризации и систем оркестрации, переезд пройдёт намного легче и безболезненнее. В случае с тем же Kubernetes все нужные ОС со всеми настройками будут упакованы и готовы к перемещению. Останется развернуть новые копии на новых серверах. Да, не обойтись без правок в настройках подключений к тем же БД, но эти правки будут минимальны.</p>
4
<p>Кроме того, все нужные настройки сервисов вы сможете сделать заранее и зафиксировать с помощью файлов Deployment, если речь идёт, опять же, о Kubernetes.</p>
4
<p>Кроме того, все нужные настройки сервисов вы сможете сделать заранее и зафиксировать с помощью файлов Deployment, если речь идёт, опять же, о Kubernetes.</p>
5
<h2>Что делать, если контейнеров нет?</h2>
5
<h2>Что делать, если контейнеров нет?</h2>
6
<p>Если контейнеры не используются, есть альтернативные варианты переезда: 1.<strong>Перенос образов серверов</strong>. Делаются полные слепки состояния каждой ВМ вместе с файлами, конфигами и программами. Потом создаётся новый сервер, для чего используется образ старого. На выходе - готовая к работе машина с нужными настройками (итоговые донастройки минимальны). 2.<strong>Применение средств автоматизации развёртывания</strong>(Ansible, SaltStack, Chef, Terraform). Все эти средства функционируют по схожей концепции - вы описываете нюансы настройки вашей системы посредством специальных файлов. В файлах указываются аспекты развёртывания сервера. Такие системы управления развёртыванием способны сами "ходить" на серверы в сети, применяя нужные команды и делая это автоматически. Решение более надёжно, чем применение образов, плюс упрощает настройки и является более универсальным. 3.<strong>Упрощение миграции посредством DevOps-практик</strong>. Речь идёт о методологии<strong>GitOps</strong>. При её использовании нужные конфигурационные файлы хранятся в Git-репозиториях, то есть развёртывание инфраструктуры производится скриптами строго из репозитория. Методика дополняется системами автоматизации типа Ansible и Chef, о которых уже упоминали. Стоит добавить, что хранить конфигурационные файлы и настройки в Git - занятие трудоёмкое, но усилия окупаются. 4.<strong>Помощь облачного провайдера</strong>. Когда речь идёт о переносе сложной инфраструктуры в облако, лучше всего обратиться к выбранному провайдеру. Он подробно проконсультирует относительно миграции виртуальных машин. При необходимости - предложит автоматизированные сервисы для переноса инфраструктуры в режиме real time, не останавливая работу приложения.</p>
6
<p>Если контейнеры не используются, есть альтернативные варианты переезда: 1.<strong>Перенос образов серверов</strong>. Делаются полные слепки состояния каждой ВМ вместе с файлами, конфигами и программами. Потом создаётся новый сервер, для чего используется образ старого. На выходе - готовая к работе машина с нужными настройками (итоговые донастройки минимальны). 2.<strong>Применение средств автоматизации развёртывания</strong>(Ansible, SaltStack, Chef, Terraform). Все эти средства функционируют по схожей концепции - вы описываете нюансы настройки вашей системы посредством специальных файлов. В файлах указываются аспекты развёртывания сервера. Такие системы управления развёртыванием способны сами "ходить" на серверы в сети, применяя нужные команды и делая это автоматически. Решение более надёжно, чем применение образов, плюс упрощает настройки и является более универсальным. 3.<strong>Упрощение миграции посредством DevOps-практик</strong>. Речь идёт о методологии<strong>GitOps</strong>. При её использовании нужные конфигурационные файлы хранятся в Git-репозиториях, то есть развёртывание инфраструктуры производится скриптами строго из репозитория. Методика дополняется системами автоматизации типа Ansible и Chef, о которых уже упоминали. Стоит добавить, что хранить конфигурационные файлы и настройки в Git - занятие трудоёмкое, но усилия окупаются. 4.<strong>Помощь облачного провайдера</strong>. Когда речь идёт о переносе сложной инфраструктуры в облако, лучше всего обратиться к выбранному провайдеру. Он подробно проконсультирует относительно миграции виртуальных машин. При необходимости - предложит автоматизированные сервисы для переноса инфраструктуры в режиме real time, не останавливая работу приложения.</p>
7
<h2>Делаем выводы</h2>
7
<h2>Делаем выводы</h2>
8
<p>Главное, что следует сказать -<strong>безболезненная миграция серверов потребует от вас системного подхода</strong>. При этом: 1. Чаще всего миграция требует определённых вложений в инструменты поддержания и управления вашей инфраструктурой. 2. Если в проекте не применяются системы управления инфраструктурой, внедрите их перед миграцией. Это однозначно окупится, т. к. проблем во время переезда будет меньше ("лучше день потерять и потом за 5 минут долететь"). 3. Если речь идёт о миграции в облако сложной инфраструктуры, воспользуйтесь помощью выбранного провайдера либо автоматизированными облачными платформами для переноса приложений, данных и серверов.</p>
8
<p>Главное, что следует сказать -<strong>безболезненная миграция серверов потребует от вас системного подхода</strong>. При этом: 1. Чаще всего миграция требует определённых вложений в инструменты поддержания и управления вашей инфраструктурой. 2. Если в проекте не применяются системы управления инфраструктурой, внедрите их перед миграцией. Это однозначно окупится, т. к. проблем во время переезда будет меньше ("лучше день потерять и потом за 5 минут долететь"). 3. Если речь идёт о миграции в облако сложной инфраструктуры, воспользуйтесь помощью выбранного провайдера либо автоматизированными облачными платформами для переноса приложений, данных и серверов.</p>
9
<p><em>Статья написана по материалам блога<a>Mcs.Mail.ru</a>.</em></p>
9
<p><em>Статья написана по материалам блога<a>Mcs.Mail.ru</a>.</em></p>
10
10