Чому клієнт терпить хостинг, який його не влаштовує

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

На такому сервері стоїть система, яку ставили ще за минулого адміна. Півсотні пакетів, десяток сервісів, 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/uk/. Якщо розмітка нестандартна, ОС стара або перевірка не пройшла, напишіть у підтримку XServer. Ми розберемо переїзд разом: старий сервер при цьому лишається недоторканим, тож втрачати нічого.