Перенести сайт на другой хостинг можно практически незаметно для посетителей: заранее подготовить новый сервер, скопировать данные, переключить DNS и оставить старую машину работать до окончания миграции. С собственным физическим сервером всё сложнее. Его необходимо выключить, извлечь из стойки или забрать из офиса, упаковать, доставить в дата-центр, установить, подключить питание и сеть и только после этого снова запустить.
На это время машина физически не может обслуживать пользователей. Поэтому главный вопрос при переезде собственного сервера в colocation заключается не столько в том, как перевезти металлический корпус, сколько в том, что будет происходить с сайтом и данными, пока сервер находится в дороге.
Для небольшого корпоративного сайта несколько часов технических работ иногда допустимы. Для интернет-магазина, SaaS, API или другого коммерческого сервиса подобный простой уже может означать потерянные заказы и обращения клиентов. Поэтому схема переезда зависит от того, насколько долго проект способен оставаться недоступным.
Самый безопасный подход состоит в том, чтобы разделить физический переезд оборудования и доступность сервиса. Сервер может ехать через город, а сайт в это время продолжает работать на временной машине.
Как подготовить сервер к переезду в ЦОД
Подготовку стоит начинать с резервной копии. Даже если сервер перевозится целиком вместе со всеми дисками, рассчитывать только на то, что после дороги он включится точно в том же состоянии, не стоит.
Современное серверное оборудование нормально переносит транспортировку при правильной упаковке, но накопители, контроллеры и другие компоненты всё равно остаются физическими устройствами. Диск может отказаться запускаться после выключения, карта расширения способна немного сместиться, а ошибка при подключении на новой площадке иногда приводит к проблемам, которых до переезда не было.
Поэтому перед выключением должна существовать актуальная копия данных вне перевозимого сервера.
Для небольшого сайта это может быть полный архив файлов и дамп базы данных на другом хранилище. Для крупной базы лучше использовать штатную систему резервного копирования и обязательно проверить, что копия действительно восстанавливается.
Бэкап, который находится на другом диске внутри того же корпуса, в данном случае почти бесполезен. Если с сервером что-нибудь произойдёт целиком, вместе с ним пострадает и такая копия.
Сначала нужно решить будет ли сайт работать во время перевозки
Если несколько часов простоя допустимы, схема довольно простая. Назначается техническое окно, пользователи заранее предупреждаются при необходимости, сайт останавливается, создаётся финальная копия данных и сервер выключается.
После установки в дата-центре машина запускается, проверяется сеть и сервис возвращается в работу.
Для коммерческого проекта я бы старалась избегать такого сценария, если есть техническая возможность временно поднять сайт на другой машине.
Временный сервер не обязан быть точной копией основного железа. Его задача — обслуживать проект несколько часов или один день, пока физическая машина переезжает.
Можно арендовать VPS, облачную виртуальную машину или временный выделенный сервер. На него заранее переносится сайт, база данных и необходимые сервисы. После проверки трафик переключается на временную площадку, а собственный сервер спокойно выключается и отправляется в ЦОД.
Когда физическая машина установлена и полностью проверена, данные синхронизируются обратно, а пользователи постепенно возвращаются на основной сервер.
Такая схема требует больше подготовки, но превращает потенциально многочасовой простой практически в обычную техническую миграцию.
Самая сложная часть — данные, которые изменяются во время работы временного сервера.
Статический сайт перенести легко: файлы практически не меняются, поэтому после возвращения основной машины достаточно синхронизировать небольшое количество изменений или вообще ничего не делать.
Интернет-магазин постоянно получает новые заказы, создаёт пользователей и изменяет остатки. Просто скопировать старую базу обратно после переезда нельзя, иначе изменения, появившиеся на временном сервере, будут потеряны.
Здесь нужна либо репликация базы данных, либо запланированная финальная синхронизация с коротким режимом обслуживания.
Например, за несколько минут до обратного переключения магазин временно закрывает оформление заказов. Последние изменения базы переносятся на основной сервер, после чего трафик направляется обратно. В результате реальный простой измеряется минутами, хотя физический сервер мог находиться в дороге несколько часов.
Для очень критичных систем используются более сложные схемы репликации и высокой доступности, но для большинства сайтов подобный уровень инфраструктуры не нужен.
DNS нужно готовить заранее
После переезда сервер может получить новый публичный IP. Это особенно вероятно, если раньше он находился в офисе или другом дата-центре.
Если просто изменить A-запись домена после установки машины, часть пользователей некоторое время продолжит обращаться к старому адресу из-за DNS-кэша.
Поэтому за несколько дней до переезда полезно уменьшить TTL соответствующих DNS-записей. Тогда после изменения IP информация обновится у резолверов быстрее.
Слишком маленький TTL держать постоянно обычно нет необходимости. После успешной миграции его можно вернуть к обычному значению.
Если используется CDN или внешний reverse proxy, задача иногда становится проще. Пользователи обращаются к узлам CDN, а IP исходного сервера скрыт за ними. Тогда при переезде достаточно изменить origin внутри панели сервиса, и посетители вообще не взаимодействуют с IP физической машины напрямую.
Но полагаться на CDN как на способ скрыть неподготовленный переезд не стоит. База данных, фоновые задачи и административная часть приложения всё равно должны быть корректно перенесены.
Перед выключением нужно также получить от нового ЦОД все сетевые параметры. Желательно заранее знать IP, шлюз, префикс, VLAN и параметры IPv6, если он будет использоваться.
Если возможно, конфигурацию можно подготовить до доставки сервера. Но здесь нужно быть осторожным: если изменить сетевые параметры слишком рано, машина потеряет доступ в старой локации.
Часто удобнее подготовить второй конфигурационный файл или выполнить финальное изменение уже через IPMI после установки в новом ЦОД.
Как безопасно перевезти физический сервер
Перед перевозкой машину нужно корректно выключить. Не следует просто отключать питание работающего сервера, если только система полностью не зависла. База данных должна завершить операции, файловые системы — корректно размонтироваться, а RAID — закончить критичные процессы.
Если в этот момент выполняется rebuild массива, большой backup или другая тяжёлая дисковая операция, лучше дождаться её завершения.
После выключения полезно зафиксировать текущую конфигурацию. Можно сфотографировать заднюю панель, положение сетевых кабелей, блоков питания и других подключений.
Если сервер имеет много дисков, стоит проверить их нумерацию. Hot-swap корзины лучше не переставлять местами без необходимости. Современные RAID обычно способны определить диски независимо от физического слота, но создавать себе дополнительный риск во время переезда бессмысленно.
Особенно внимательно следует обращаться с серверами, где используются большие GPU или другие тяжёлые PCI Express карты.
В стационарной стойке такая карта надёжно закреплена, но при транспортировке удары и вибрации создают нагрузку на разъём и крепления. В зависимости от конструкции сервера тяжёлый ускоритель иногда лучше снять и перевезти отдельно.
Для обычных rackmount GPU с заводской системой фиксации это может быть не нужно. Здесь стоит следовать рекомендациям производителя конкретного шасси.
Сервер желательно перевозить в оригинальной упаковке. Заводские коробки имеют плотные формованные вставки, рассчитанные именно под массу и размеры оборудования.
Если оригинальной упаковки нет, нужна профессиональная транспортная тара, которая исключает свободное перемещение машины внутри коробки.
Тяжёлый сервер нельзя воспринимать как обычный системный блок. Машина 2U с дисками и двумя блоками питания способна весить десятки килограммов. При падении она опасна не только для самого оборудования.
Направляющие обычно перевозятся отдельно. Их нужно подписать и убедиться, что вместе с ними находятся все необходимые крепления.
Это выглядит мелочью, но один потерянный комплект rails способен задержать установку уже доставленного сервера.
До поездки желательно согласовать с дата-центром время доставки и процедуру приёмки. Особенно если оборудование привозит курьер, а не сам администратор.
На некоторых площадках требуется заранее сообщить модель и серийный номер оборудования, данные курьера или оформить пропуск.
Если сервер привезли ночью без предварительного согласования, наличие круглосуточной поддержки ещё не гарантирует, что охрана просто примет дорогое оборудование у неизвестного человека.
После установки нельзя сразу переключать пользователей
Первый запуск на новой площадке должен быть тестовым.
Сначала проверяется питание. Если сервер имеет два блока, оба должны определяться системой и нормально работать.
Затем проверяется IPMI, iDRAC или iLO. Аппаратный удалённый доступ нужен именно сейчас, пока ещё есть возможность спокойно исправить проблемы до возвращения сайта в продакшен.
После этого запускается операционная система и проверяется сеть.
Полезно убедиться не только в том, что SSH открывается с компьютера администратора. Нужно проверить шлюз, DNS, внешний IP, IPv6, если он используется, и маршруты до основных сетей.
Следом проверяются диски и RAID. Все накопители должны определяться, массив должен находиться в нормальном состоянии, а аппаратные журналы не должны содержать новых ошибок после транспортировки.
Затем запускается приложение. Проверяются веб-сервер, база данных, фоновые процессы, cron, очереди, почта и всё остальное, что требуется проекту.
Если сайт использует внешние сервисы, необходимо проверить, не были ли они ограничены по старому IP.
Например, партнёрская API-система может разрешать подключения только с заранее указанного адреса. После переезда запросы перестанут работать, пока новый IP не будет добавлен в whitelist.
Похожая проблема возникает с платежными шлюзами, корпоративными VPN, удалёнными базами и другими системами, где используется фильтрация по источнику.
Обратный DNS тоже стоит проверить, если сервер отправляет почту самостоятельно. PTR-запись для нового IP задаётся через провайдера и не переносится вместе с машиной.
Только после полной проверки имеет смысл возвращать пользовательский трафик.
Если сайт временно работал на другом сервере, перед переключением выполняется финальная синхронизация данных.
После изменения DNS или настройки CDN нужно ещё некоторое время наблюдать оба сервера. Из-за кэширования часть запросов может продолжать приходить на временную машину.
Отключать её сразу после первого успешного открытия сайта с нового IP не стоит.
Удобно оставить временный сервер работающим хотя бы до тех пор, пока не станет очевидно, что практически весь пользовательский трафик уже перешёл на основной узел.
Мониторинг после переезда особенно важен в первые часы. Нужно смотреть загрузку CPU, RAM, температуру, сеть, задержки дисков и ошибки приложения.
Новая площадка может иметь другую сетевую задержку до внешних сервисов, другое поведение маршрутов и другие ограничения.
Если физическая машина осталась той же, это ещё не означает, что среда вокруг неё никак не изменилась.
Полезно сравнить время ответа сайта до и после переезда. Если оно неожиданно выросло, причина может находиться не в самом сервере, а в сети до базы, внешнего API или пользователей.
После нескольких дней стабильной работы можно вернуть обычный TTL DNS, удалить временную инфраструктуру и обновить документацию.
В ней стоит сохранить новый IP, данные ЦОД, номер стойки или сервера, management-адрес, схему подключений и контакты поддержки.
Если в дата-центре хранится ЗИП, нужно записать, какие компоненты там находятся.
Переезд особенно удобно использовать как повод привести инфраструктуру в порядок. Старые учётные записи можно удалить, IPMI обновить, пароли изменить, firmware проверить, а сетевые правила пересмотреть.
Но все крупные изменения лучше не совмещать в один момент.
Если одновременно физически перевозить сервер, менять операционную систему, перестраивать RAID, обновлять базу и переделывать сеть, при возникновении ошибки будет сложно понять, какая именно часть переезда её вызвала.
Безопаснее сначала перенести машину в максимально знакомом рабочем состоянии, убедиться в стабильности, а затем выполнять модернизацию отдельными этапами.
Особенно это актуально для старого сервера. Переезд иногда становится первым полным выключением машины за несколько лет. После холодного старта внезапно обнаруживается слабый блок питания, проблемный диск или батарея RAID-контроллера.
Поэтому перед отправкой в ЦОД полезно несколько раз выполнить полный цикл выключения и включения ещё на старой площадке.
Если сервер не способен стабильно пройти cold boot на столе администратора, перевозить его в дата-центр преждевременно.
Для критичного коммерческого проекта я бы рассматривала физический переезд только при наличии независимой резервной копии и временного места, где сервис сможет работать во время дороги.
Так colocation перестаёт быть рискованным мероприятием, связанным с многочасовой недоступностью сайта.
Сама машина действительно должна быть выключена и физически перемещена. Но пользователям совершенно необязательно наблюдать этот процесс.
Если данные заранее синхронизированы, DNS подготовлен, временный сервер проверен, а новый ЦОД уже выдал сетевые параметры, основная часть переезда происходит за кулисами. Для посетителя сайт просто продолжает открываться, пока его физический сервер едет к новому месту работы.
