Міграція серверів і хостингу без простою

Ми переносимо робочі сайти, магазини, бази даних, фонові сервіси й пошту на новий сервер або до іншого хостинг-провайдера. Новий сервер працює паралельно, доки кожен сайт не пройде перевірку, а саме перемикання — це зміна DNS, яку можна відкотити.

Коли міграція лягає на ваш стіл

Сервери не переносять заради розваги. Зазвичай дату визначає хтось інший, а на сервері працює більше, ніж будь-хто пам’ятає.

Хостинг закриває ваш тариф, а на сервері пошта, п'ять сайтів і cron-завдання, яке ніхто не описав
Рахунок за хостинг знову зріс, і переїзд здається ризикованішим, ніж платити далі
Операційна система чи панель керування більше не оновлюється, а людина, яка все налаштовувала, пішла
Ви хочете об'єднати кілька старих серверів в один або перейти на дешевші ARM-сервери
Пошта ваших доменів живе на тій самій машині, і ніхто не знає, від яких DNS-записів вона залежить
Попередня спроба переїзду закінчилася зламаними зображеннями, втраченими замовленнями чи листами, що повертаються

Що ми переносимо

Спершу інвентаризація

Перш ніж щось копіювати, ми складаємо перелік того, що насправді працює: сайти, бази даних, cron-завдання, фонові процеси, поштові скриньки й переадресації, FTP-акаунти, сертифікати й DNS-записи. Зазвичай у переліку знаходиться кілька речей, про які власник не знав.

Вебстек і бази даних

nginx і Apache, кілька версій PHP поруч, MySQL і PostgreSQL, а також панелі керування на кшталт aaPanel і FastPanel. Сайти переїжджають разом із налаштуваннями, користувачами й правами на файли, а не лише з файлами.

Node, Docker і сервіси

Застосунки Node.js під PM2 або systemd, контейнери Docker і процеси, що працюють у фоні. Залежності збираємо заново на новій машині, і це важливо, коли змінюється архітектура процесора.

Пошта

Поштові скриньки з паролями й історією, аліаси й переадресації, фільтрація спаму та DKIM, SPF і DMARC. Якщо провайдер блокує вихідний порт 25, вихідна пошта йде через релей, тож жоден лист не повертається.

DNS і Cloudflare

Зони відтворюємо за записами в панелі реєстратора чи Cloudflare, а не вгадуємо за запитами. TTL знижуємо заздалегідь, а сервери імен у реєстратора змінюємо лише тоді, коли нова зона повна.

Резервні копії й моніторинг

Новий сервер отримує резервні копії в окреме сховище з політикою зберігання й тестовим відновленням, а також моніторинг доступності, сертифікатів і місця на диску. Сервер без них перенесено лише наполовину.

Переїзд, спланований так, щоб перемикання було нудною частиною

Кожен сайт спочатку працює на новому сервері за тимчасовою адресою. Ми відкриваємо його сторінки, надсилаємо форми, робимо тестове замовлення там, де є оформлення, надсилаємо й отримуємо пошту та чекаємо, поки відпрацюють cron-завдання. Безпосередньо перед перемиканням дані синхронізуємо ще раз, щоб не втратити замовлення й коментарі, зроблені після першої копії. Потім DNS переходить зона за зоною. Старий сервер лишається недоторканим, доки новий не пропрацює якийсь час, тож відкат — це зміна одного запису.

Письмовий перелік усього, що працює на старому сервері
Кожен сайт перевірено на новому сервері до будь-якої зміни DNS
Фінальна синхронізація даних безпосередньо перед перемиканням
Старий сервер лишається запасним, доки ви не підтвердите

Проблеми, з якими ми вже стикалися

Ми перенесли між серверами десять проєктів і двадцять три сайти, зокрема повний переїзд з x86 на машини ARM64, і записали кожну проблему дорогою. На ARM залежності Node треба перевстановлювати, а не копіювати, а PHP може падати за певних налаштувань JIT. MySQL може почати розрізняти регістр у назвах таблиць і зламати запити, які працювали роками. Новіший чи старіший nginx не приймає частину старої конфігурації, а бази даних переїжджають із неправильним кодуванням порівняння (collation). Зона Cloudflare може зависнути на активації, спам-фільтр може не підписувати пошту, доки його не перезапустити в правильному порядку, а правило фаєрвола може заблокувати цілий офіс, що виходить в інтернет з однієї IP-адреси. Інструменти міграції в панелях можуть звітувати про успіх неповної копії, а сертифікати можуть тихо перестати продовжуватися. Тепер кожну з цих речей ми перевіряємо за хвилини, а не з’ясовуємо годинами.

Чекліст, складений на реальних міграціях, а не за документацією
Зміну архітектури, як-от x86 на ARM64, виконуємо свідомо
Різницю у версіях PHP, MySQL і nginx перевіряємо до перемикання
Пошту, сертифікати й правила фаєрвола тестуємо, а не припускаємо

Після переїзду: підтримка замість теки з документами

Міграція — це момент, коли одна команда нарешті знає весь сервер: що на ньому працює, навіщо і що від чого залежить. Шкода втратити ці знання наступного дня після перемикання. Більшість наших клієнтів після міграції лишаються на щомісячній підтримці серверів, де ті самі люди встановлюють оновлення, стежать за резервними копіями й моніторингом, продовжують сертифікати й беруться за наступні зміни. Якщо ви хочете обслуговувати сервер самі, ви отримуєте документацію нової конфігурації й доступ до всього.

Документація нового сервера: сервіси, шляхи, розклади, доступи
Резервні копії й моніторинг працюють з першого дня
Можливість продовжити зі щомісячною підтримкою серверів
Усі акаунти й ключі оформлені на вас

Як проходить міграція

Інвентаризація

Ми отримуємо доступ на читання до старого сервера, доменів і DNS. Ви отримуєте перелік того, що там працює, і того, що передбачає переїзд.

План і новий сервер

Узгоджуємо цільовий хостинг і розмір сервера, потім налаштовуємо нову машину з тими самими або новішими версіями програм. Ви отримуєте план перемикання для кожного сайту й домену.

Копіювання й перевірка

Сайти, бази даних, сервіси й пошту копіюємо й перевіряємо за тимчасовими адресами. Проблеми виправляємо, поки старий сервер і далі обслуговує всіх.

Перемикання

Після фінальної синхронізації даних DNS переходить зона за зоною в обраний вами час. У процесі ми стежимо за трафіком, логами й поштою.

Спостереження й рішення

Новий сервер працює під наглядом, а старий чекає як запасний. Потім старий сервер вимикаємо, а ви обираєте між щомісячною підтримкою й передачею з документацією.

Звідки й куди переносимо

Панелі й вебсервери

Бази даних і застосунки

Пошта й DNS

Інфраструктура

Як можна з нами працювати

Проєкт міграції

Фіксований обсяг, узгоджений після інвентаризації: які сайти, сервіси й домени переїжджають і куди.

Міграція й щомісячна підтримка

Ми переносимо сервер, а потім і далі доглядаємо за ним: оновлення, резервні копії, моніторинг і наступні зміни.

Погодинна допомога

Інвентаризація й план міграції для вашої команди або допомога з однією складною частиною, як-от пошта чи DNS.

Відгуки

До кожного клієнта та його проєкту ставимося уважно.

Команда Revol і далі розширює можливості розробки клієнта завдяки якісній роботі та надійній підтримці. Вони ефективно комунікують і добре розуміють потреби та бізнес клієнта.

Tomas

CEO (Юкон, Канада)

Робота Revol повністю виправдала очікування, і клієнт залишився задоволений. Свіжий підхід і постійна готовність допомогти стали для нас справжньою цінністю. Якщо вам потрібна комунікабельна, клієнтоорієнтована команда для досягнення ваших цілей — сміливо звертайтеся до них.

Andrey

CEO, Stellium (США)

Часті запитання

Чи перестануть працювати наші сайти під час переїзду?

Не мали б. Новий сервер працює паралельно й приймає трафік лише після того, як на ньому перевірено кожен сайт. Поки оновлюється DNS, частина відвідувачів ще недовго потрапляє на старий сервер, тому він лишається увімкненим, доки зміна не пошириться.

Що буде із замовленнями й заявками, зробленими під час перемикання?

Безпосередньо перед перемиканням ми ще раз синхронізуємо дані, тож лишається лише коротке вікно. Для завантажених магазинів домовляємося, як його закрити: перемкнутися в тиху годину, призупинити оформлення замовлень на кілька хвилин або вручну перенести останні замовлення зі старої бази.

Чи можете ви перенести й нашу пошту?

Так. Поштові скриньки переїжджають разом із листами й паролями, якщо стара система це дозволяє, а також аліаси й переадресації. Ми відтворюємо DKIM, SPF і DMARC для нового сервера й перевіряємо, що вихідні листи доставляються, а не лише відправляються.

У нас сервери x86. Чи можна перейти на ARM64?

Зазвичай так, і ARM-сервери часто дешевші за того самого навантаження. Більшість задач на PHP, WordPress, Node і базах даних працюють на ARM після перезбирання залежностей. Інвентаризація рано показує, якщо щось існує лише для x86, наприклад старий образ Docker чи закритий бінарний файл, і тоді цю частину ми лишаємо на x86.

Чи потрібен вам доступ до нашого реєстратора доменів?

Для планування достатньо доступу на читання до DNS. Для перемикання треба змінити записи або сервери імен: це можете зробити ви за нашими інструкціями або дати нам доступ на цей день.

Що, як після перемикання щось зламається?

Старий сервер нікуди не дівся, тож найшвидше рішення — повернути DNS назад, поки ми шукаємо причину. У перші дні після кожного перемикання ми стежимо за логами, поштовими чергами й моніторингом: саме тоді зазвичай з'являються проблеми, яких не було видно під час тестування.

Чи можна відмовитися від нашої панелі керування?

Так. Ми можемо перенести сайти з однієї панелі на іншу або на звичайний сервер без панелі, яким керують через конфігураційні файли й скрипти. Радимо те, що підходить людям, які доглядатимуть за сервером надалі.

Чи доглядаєте ви за сервером після міграції?

Якщо хочете. Більшість клієнтів після міграції продовжують зі щомісячною підтримкою серверів, де та сама команда займається оновленнями, резервними копіями, моніторингом і подальшими змінами. Інакше ви отримуєте документацію й повний доступ, і сервер ви обслуговуєте самі.