Почему клиент терпит хостинг, который его не устраивает

Сервер, которому пять лет, страшнее бросить, чем терпеть. Диски медленные, тариф давно не в рынке, поддержка отвечает сутки, а клиент всё равно остаётся. Переезд для него выглядит как операция без наркоза.

На таком сервере стоит система, которую ставили ещё при прошлом админе. Полсотни пакетов, десяток сервисов, cron-задачи, сертификаты, правила firewall, базы, сайты, пара самописных скриптов в /opt и настройки, о которых уже никто не помнит. Полного списка нет ни у кого.

Классический переезд выглядит так:

1. Заказать новый сервер и поставить на него чистую ОС.
2. По памяти и по старым заметкам восстановить всё, что стояло на старом.
3. Перенести данные, переписать конфиги под новые пути, диски и имена интерфейсов.
4. Переключить DNS и поймать всё, что не завелось.
5. Ещё неделю получать звонки: «а вот это раньше работало».

На это уходят вечера и выходные, а каждая забытая мелочь всплывает уже на боевом сервере. Простой непредсказуем: планировали час, вышло полдня. Откатиться назад тоже не получится, данные за это время успели разойтись.

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

Мы видели это годами с обеих сторон: и когда клиенты уходили от нас, и когда приходили к нам. Разница была только в том, кто в этот раз не спал ночью.

Как мы подошли к этому сами

У нас эта боль была своя. Клиенты XServer переезжают между нашими дата-центрами, с виртуалок на выделенные серверы и обратно, со старого железа на новое. Каждый такой переезд инженер делал по внутренней статье «Клонирование физических серверов»: загрузить обе машины в наш Live OS, снять таблицу разделов, прогнать partclone по сети, собрать chroot, пересобрать initramfs, переставить grub, поправить сеть. От 30 до 60 команд на двух машинах, и порядок важен.

Главное, что мы вынесли из этих переездов: переустанавливать систему не нужно. Linux состоит из файловых систем, загрузчика и нескольких конфигов, в которых прописаны имена дисков и сетевых карт. Если перенести файловые системы целиком и поправить только то, что привязано к старому железу, система поедет дальше, как будто ничего не случилось. Пакеты, настройки и забытые скрипты в /opt едут вместе с ней, и список для этого никому составлять не надо.

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

Так статья превратилась в одну команду на новом сервере. Инженеру больше не нужно держать порядок шагов в голове, а лог переезда можно показать клиенту.

Почему мы отдали её клиентам

Сначала утилита была чисто внутренней: обе машины стоят у нас, обе грузятся в Live OS по сети из панели, инженер запускает команду. Но самый нужный переезд выглядит иначе. Старый сервер стоит у другого провайдера, и его владелец как раз тот клиент, который хотел бы переехать, но боится.

Утилите при этом всё равно, где стоит старый сервер: ей нужны две машины в Live OS и сеть между ними. Новый сервер у XServer получает Live из панели одним пунктом меню. Оставалось научиться загружать в Live чужой сервер, к которому у нас нет ни панели, ни PXE. Получилось два пути. Из работающей системы одна команда скачивает Live и через kexec перезагружает сервер прямо в него, минуя BIOS и порядок загрузки. Там, где kexec не работает, есть ISO-образ для консоли провайдера или панели VPS.

Дальше решение напрашивалось само. Если людей удерживает от переезда страх, то инструмент, который его снимает, должен быть в руках у самого клиента. Мы зарегистрировали домен reloca.to, положили туда установщик, написали инструкцию на трёх языках и отдаём утилиту бесплатно всем, кто переезжает к нам.

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

Что такое reloca.to и как он работает

reloca.to переносит установленный Linux-сервер с одной машины на другую по сети. Обе машины на время переезда загружены в XServer Live OS: лёгкую систему, которая живёт в оперативной памяти и не трогает диски. Вы заходите по ssh на новый сервер и запускаете одну команду с адресом старого:

curl -fsSL reloca.to | bash
reloca.to 10.0.0.12

Старый сервер утилита называет source.reloca.to, а новый destination.reloca.to, так что в приглашении оболочки и в каждой строке лога видно, где вы находитесь. Дальше она проходит семь фаз, и каждую можно запустить отдельно.

1. Инвентарь. На обеих машинах снимаются диски, разделы, md RAID, LVM, файловые системы вместе с их фичами, fstab, ядра, загрузчик и сеть.
2. План. Из двух инвентарей рождается текстовый файл: как разметить новый диск, что копировать блочно, а что файлами, какие UUID сохранить, что поправить в fstab и сети. План можно прочитать и отредактировать до первой записи, а сухой прогон reloca.to -n покажет его и каждую команду, ничего не трогая.
3. Разметка. Перед тем как стереть диск, утилита печатает его модель, серийник, размер и что на нём сейчас и просит ввести с экрана имя и размер, например sda 894. Рефлекторное «y» не выберет не тот диск. Только потом создаются разделы, swap и файловые системы с теми же UUID, label и набором фич, что у источника.
4. Передача. Тома летят по сети через partclone или tar со сжатием по защищённому каналу, с прогрессом и оценкой времени. Утилита живёт в tmux: обрыв ssh ничего не стоит, а упавший том повторяется отдельно.
5. Доработка. В chroot на новом сервере правятся fstab, mdadm.conf, initramfs с драйверами нового контроллера, grub под BIOS или UEFI. Основной сетевой интерфейс переименовывается в eth0, старый MAC заменяется на новый. Каждая правка попадает в лог как diff, оригиналы сохраняются.
6. Проверка. До перезагрузки утилита убеждается, что загрузочная запись указывает на существующие ядро и initrd, в initramfs есть нужные модули, fstab резолвится, фичи файловых систем совпадают, сеть настроена. Если что-то не так, она выходит с кодом 3 и прямо говорит: диск записан, не ребутать, чинить.
7. Cutover. Старый сервер снимается с сети или выключается, а новый перезагружается в перенесённую систему. Это происходит только после зелёной проверки.

Простой равен времени переноса: от получаса до нескольких часов в зависимости от объёма данных. Всё это время старый сервер стоит в Live с нетронутыми дисками. Если что-то пошло не так, его просто перезагружают в прежнюю систему, и всё продолжает работать как раньше.

Чего утилита никогда не делает:

• Не пишет на старый сервер: ни fsck, ни resize. Он остаётся точкой отката.
• Не стирает диск, пока вы не прочитаете, что на нём сейчас, и не введёте его имя и размер.
• Не форматирует «по умолчанию»: каждая файловая система создаётся с фичами источника и сверяется сразу после mkfs.
• Не перезагружает новый сервер без зелёной проверки.
• Не трогает другие диски нового сервера: на время работы они переводятся в read-only.

Для каких переездов он подходит

• От другого хостера к XServer. Самый частый случай: старый сервер у чужого провайдера загружается в Live одной командой или с ISO через консоль, новый получает Live из панели. Дальше одна команда, и тот же сервер стоит у нас.
• С виртуалки на выделенный сервер, когда VPS вырос и нужно железо. Разметку под один диск или том аппаратного RAID строит план. Если в новом сервере два одинаковых диска без контроллера, опция -o raid=1 соберёт из них программное зеркало, поставит загрузчик на оба и добавит mdadm в систему, если его там не было.
• С физического сервера на виртуалку, когда старому железу пора на покой, а нагрузка давно помещается в VPS. Программный RAID превращается в одиночный диск, UEFI становится BIOS или наоборот, загрузчик переставляется сам.
• С программного RAID на аппаратный. Массивы md читаются уже собранными, на новой стороне из них получаются обычные разделы на томе контроллера, fstab и mdadm.conf правятся.
• Со старого железа на новое, где диски другого размера. Новый диск больше: корень растягивается. Меньше: если данные влезают, корень переливается файлами в свежую файловую систему с теми же UUID и фичами, и загрузчик ничего не замечает. Например, у старого сервера диск 2 TB, занято 150 GB, а у нового 1 TB.
• Между нашими дата-центрами. То, для чего утилита и появилась: обе машины в панели, обе грузятся в Live по сети, никаких ISO и kexec.

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

Что поддерживается

Не поддерживаются btrfs, ZFS, LUKS и NTFS, CentOS 6 и другие системы на grub-legacy, SUSE. Для Windows у нас отдельный инструмент. Если вашего случая нет в таблице, напишите нам до переезда: часть таких случаев решается руками вместе с утилитой, а часть становится её следующей фичей.

С чего начать

1. Закажите сервер у XServer и загрузите его в Live OS: панель клиента → сервер → меню загрузки → Live OS. Панель задаст пароль root, адрес останется.
2. Загрузите в Live старый сервер. Из работающей системы от root достаточно одной команды: скрипт возьмёт адрес, шлюз и DNS с основного интерфейса, скачает и сверит Live и через kexec перезагрузится прямо в него. Через минуту сервер вернётся на том же адресе как source.reloca.to, пароль root будет напечатан перед перезагрузкой.

   curl -fsSL reloca.to/live | bash

   Если kexec недоступен (Hyper-V, Azure, отдельные сетевые карты), подключите образ reloca.to/live.iso через virtual media или панель VPS и выберите в меню пункт full.
3. Зайдите на новый сервер по ssh с пробросом агента, поставьте утилиту и сначала посмотрите план в сухом прогоне. Недостающие пакеты она доставит сама.

   ssh -A root@НОВЫЙ-СЕРВЕР
   curl -fsSL reloca.to | bash
   reloca.to -n СТАРЫЙ-IP      # сухой прогон: план и каждая команда, ничего не пишется
   reloca.to СТАРЫЙ-IP         # полный переезд

4. Держите открытой консоль нового сервера на время cutover: первую загрузку видно только там.

Полная инструкция по фазам, опции и коды выхода собраны на reloca.to/ru/. Если разметка нестандартная, ОС старая или проверка не прошла, напишите в поддержку XServer. Мы разберём переезд вместе: старый сервер при этом остаётся нетронутым, так что терять нечего.