Міграція Linux без простою: де ламається перенесення
Перенесення на інший майданчик або зміну конфігурації зазвичай планують за документацією: служби перелічено, порти описано, вікно простою закладено. На практиці основний час іде не на перенесення даних, а на розбіжності, які випливають уже під прод-навантаженням. Вікно простою, пораховане за паперовим планом, майже завжди виявляється коротшим за реальне.
Перша точка відмови під час перенесення — розбіжність версій служб. Вузол-джерело міг роками жити на старій гілці, де параметр називався інакше або мав інше значення за замовчуванням; на новому вузлі той самий рядок конфігурації вже не працює або працює не так. Перевірка «служба піднялася» цього не ловить — вона підтверджує лише факт запуску процесу.
Друга — приховані залежності служб. Зворотний проксі ходить на внутрішню адресу, яка на новому майданчику належить іншому вузлу; застосунок чекає змонтований каталог зі спільними файлами; завдання планувальника звертається до сусіднього хоста й тихо падає. У конфігурації самого сервісу цих зв'язків немає, і інвентаризація пакетів їх не показує.
Третя — ручні правки конфігурації. Правку внесли прямо на живому сервері, щоб закрити інцидент, і не зафіксували в репозиторії; під час розгортання з шаблону поведінка виходить іншою, а причину розбіжності шукають годинами. Ми починаємо міграцію Linux із фіксації фактичного стану — і розбираємо, як це закривається далі.
Що змінюється після перенесення: строки, відмови, навантаження
Метрика, за якою перенесення вважають успішним, — вікно недоступності. Під час перенесення «в лоб» сервіс гасять на десятки хвилин: зняти дамп, розгорнути, перемкнути DNS і дочекатися, поки спливуть кеші резолверів.
Керована міграція це прибирає — база доганяється реплікацією, трафік переводиться перемиканням віртуальної адреси, і вікно стискається до одиниць секунд.
Час перемикання перестає залежати від обсягу даних. Раніше він зростав лінійно: чим більша база, тим довший простій. Тепер дані синхронізуються заздалегідь, а в момент переведення залишається дочекатися нульового відставання репліки й погасити залишкові записи. Різниця — між нічним узгодженим вікном і перемиканням усередині робочого дня.
Частка невдалих розгортань падає не через акуратність інженерів, а через зникнення розбіжності середовищ. Конфігурація описується декларативно й застосовується однаково на всіх майданчиках, образи збираються один раз і просуваються середовищами без перезбирання.
Якщо до перенесення частину розгортань відкочували з формулюванням «на тестовому працювало», то після такі відкати просто не відтворюються: середовище перестає бути джерелом випадковості.
Час відновлення стає передбачуваним. Замість «підняти вузол, що впав, і згадати, що на ньому правили руками» відкат іде на попередній образ або снапшот — хвилини замість годин, із відтворюваним станом.
Тут працює й те, що ролі та сценарії автоматизації в Ansible лежать у репозиторії, а не в головах чергових.
За навантаженням перенесення додає запас: горизонтальне масштабування перестає впиратися в один вузол, а розподіл трафіку між майданчиками дозволяє пережити відмову без деградації.
Підсумок — не «ми переїхали», а інші базові числа експлуатації: коротші вікна, менше відмов, передбачуване відновлення.
Способи перенесення: повна копія, поетапний переїзд, гібрид
Спосіб перенесення обирають не за зручністю, а за двома питаннями: скільки часу служба може бути недоступною і наскільки її стан відтворюваний із конфігурації.
Якщо середовище описано кодом, а дані лежать у зовнішньому сховищі, сервер збирається заново — шлях найпередбачуваніший, але він потребує повної інвентаризації залежностей.
Коли стан накопичився вручну — локальні каталоги, правки в конфігураціях «на місці», — швидше зняти повну копію сервера й потім вичистити зайве.
Між цими крайнощами працюють поетапне перенесення з проміжною синхронізацією та гібридний режим, коли частина служб уже живе на новому майданчику, а частина ще на старому.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Перезбирання середовища | Усе описано кодом, дані в зовнішньому сховищі | Потрібна повна інвентаризація залежностей |
| Повна копія сервера | Багато ручних правок, строки стиснуті | Переносить накопичене сміття та старі уразливості |
| Поетапне перенесення з проміжною синхронізацією | Служб багато, простій неприпустимий | Потребує узгодженого порядку виведення й контролю розбіжностей |
| Гібридний режим | Частина служб переїжджає раніше за решту | Складніша маршрутизація трафіку й спостережуваність |
На практиці підхід часто комбінують: перезбирають те, що описано кодом, копіюють те, що не описано, а синхронізацією закривають розрив. Вибір фіксуємо до початку робіт — від нього залежать план перемикання й точка відкату.
Порядок робіт: від інвентаризації до передачі супроводу
Міграція Linux-парку ламається рідко на самому перенесенні — відмова приходить від зв'язку, який не врахували в плані: забутий таймер у розкладі, адреса старого вузла, прописана в конфігу, сертифікат, прив'язаний до попереднього хоста.
Тому порядок робіт будуємо так, щоб кожна наступна дія спиралася на перевірювану карту, а не на пам'ять інженера.
- Інвентаризація серверів. Збираємо ролі, дистрибутиви та їхні гілки, ядра, зайняті порти, точки монтування, розклади завдань і власників кожного вузла. На виході — реєстр, за яким видно, що переноситься як є, а що потребує заміни.
- Карта залежностей. Фіксуємо, хто з ким спілкується: балансувальники, черги, бази, зовнішні сервіси за білими списками, спільні сховища. Окремо позначаємо неявні зв'язки — ті, що не описані в документації, але випливають у логах.
- Проєктування цільової схеми. Розводимо ролі по вузлах, закриваємо зайві мережеві доступи, переносимо секрети й сертифікати, готуємо конфігурацію під автоматичне встановлення. Схема узгоджується до початку робіт, а не по ходу.
- Підготовка середовища й перевірка на копії трафіку. Цільові вузли піднімаються заздалегідь, на них ганяється копія реального потоку з обезліченими даними. Це ловить розбіжності у версіях бібліотек і правах доступу, поки робочий контур не зачеплено.
- План перемикання й точка повернення. Розписуємо послідовність за кроками з вікнами, відповідальними та критеріями готовності. Для кожного кроку визначено точку повернення: зріз даних, збережений конфіг, зворотне перемикання балансувальника.
- Перемикання. Трафік переводиться порціями, з паузами на контроль метрик затримки, частки помилок і черг. Розбіжність поза межами норми — повернення за заздалегідь прописаною процедурою, без імпровізації.
- Перевірка після перенесення. Звіряємо журнали, розклади, права, відгук суміжних систем, цілісність даних. Тільки після цього виводимо старі вузли зі схеми, залишаючи їх доступними на строк відкату.
- Передача супроводу. Віддаємо регламенти, схему мережі, карту залежностей, інструкції щодо типових збоїв і доступи. Команда замовника чергує за документом, а не за пам'яттю інженера, який пішов.
Що залишається у вас: конфігурації, схеми, регламенти
Документація збирається по ходу робіт, а не відновлюється в кінці. Тому на здачі ви отримуєте не презентацію, а робочий комплект, за яким інфраструктуру можна обслуговувати без нас — своєю командою або іншим підрядником.
- Опис конфігурацій — файли налаштувань веб-серверів, баз даних, черг і планувальників із поясненням, чому параметр виставлено саме так і що зламається за його зміни.
- Схема інфраструктури — вузли та їхні ролі, межі мережевих сегментів, точки балансування, зовнішні залежності й резервні копії.
- Схеми взаємодії служб — який сервіс з яким спілкується, за якими портами і що відбувається за недоступності сусіда: де деградація, а де відмова.
- Політики доступу та ролі — хто і що може читати й змінювати, як видаються й відкликаються ключі, строки життя доступів і порядок їх перегляду.
- Регламент обслуговування — що і з якою періодичністю перевіряти, які значення метрик вважаються нормою, як оновлюються пакети й застосовуються виправлення безпеки.
- Порядок відкату — покроковий сценарій повернення до попереднього стану, включно з узгодженістю даних і моментом, після якого відкат уже неможливий.
- Інвентар — перелік серверів із призначенням і відповідальними, місця зберігання секретів і правила їх ротації.
Кожен артефакт перевіряємо разом із вашими інженерами: розгортаємо за ним тестовий контур і переконуємося, що описи збігаються з реальністю.
Кейс: переїзд кластера без зупинки сервісу
Кластер стояв на двох майданчиках: робочий контур і резерв, між ними — реплікація даних і балансувальник із перенесенням навантаження за вагами. Перемикання робили руками в нічне вікно: сервіс гасився на 4–6 годин, інженер за чек-лістом переносив трафік і звіряв логи.
За квартал набиралося два-три незаплановані відмови, а час реакції на збій сягав до 40 хвилин — поки знаходили, де розійшлися дані.
Що змінили
Другий майданчик тримали в постійній реплікації, конфігурацію перевели в код: ролі Ansible описують стан вузлів, балансувальника й мережевих фільтрів, тому середовище відтворюється з нуля, а не доналаштовується за пам'яттю.
Вікно обслуговування прибрали — трафік переводили порціями: 1%, 5%, 25%, 50%, 100%, з паузою на кожному ступені, поки частка помилок і затримки в нормі.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Простій під час перемикання | 4–6 годин уночі | немає, перемикання на живому трафіку |
| Відкат | повторне нічне перенесення | повернення ваги за хвилину |
| Відмови за квартал | 2–3 | нуль за весь період міграції |
| Реакція на збій | до 40 хвилин | до 5 хвилин |
| Старий майданчик | тримали «на всякий випадок» | виведений з експлуатації через 3 тижні |
Виведення старого майданчика йшло останнім: з нього зняли навантаження, три тижні він працював лише на читання й приймав резервні копії, потім вимкнули реплікацію й зняли машини.
Переїзд кластера перестав бути подією з нічним чергуванням — кожен ступінь перевірено на частині трафіку.
Чим міграція Linux відрізняється від перезбирання середовища
Перенесення стану — це коли разом із даними переїжджає й саме середовище: юніти служб, конфігурації, права, сертифікати, завдання за розкладом, облікові записи. Чисте розгортання — коли інфраструктура піднімається заново з декларативного опису, а переносяться лише дані. Різниця не в акуратності, а в тому, звідки приходять ризики й як розкладається час простою.
Головний ризик перенесення стану — накопичений дрейф. Службу роками правили руками, частина параметрів ніде не зафіксована, окреме налаштування або правило фільтрації трафіку живе лише на диску старої машини.
Інструмент на кшталт Ansible допомагає описати конфігурацію, але такі залежності все одно витягують за журналами й за поведінкою служби при вимкненому доступі.
Чисте розгортання збирає ті самі служби з опису: ролі, шаблони конфігурацій, міграції схем. Старт довший, зате далі складність підтримки падає — стан відтворюваний, а не відновлюється за пам'яттю.
Основний ризик тут — сумісність версій служб: новий набір пакетів і форматів конфігурацій може не прийняти старі дані без проміжного кроку міграції.
На практиці вибір гібридний. Периферію — балансувальник, середовище виконання застосунків, оркестрацію — розгортаємо чисто, а бази, черги й файлові сховища переносимо з перевіркою сумісності та контрольною звіркою.
Простій рахуємо за найдовшим компонентом, а не за середнім, і тримаємо зворотний відкат на старий майданчик, поки зміну не підтверджено на реальному навантаженні.
Що уточнюють перед стартом: сумніви й відповіді
До старту перенесення склад служб, точки монтування й зовнішні залежності вже описані — залишаються питання, від відповідей на які залежить, як саме піде робота.
Нижче — те, що найчастіше уточнюють до початку: простої, доля середовищ, зібраних вручну, і спосіб переконатися, що після переїзду працює не «приблизно те саме», а те саме.
Окремо проговорюємо оборотність: у кожного етапу є відкат, старий контур залишається робочим до підтвердження результату, а зміни на час вікна заморожуються за узгодженим списком.
Чи доведеться зупиняти обслуговування?
Повна зупинка потрібна лише на коротке вікно перемикання — від одиниць хвилин. Дані переносяться на працюючій системі, а перед самим перемиканням виконується наздоганяльна синхронізація, тому основна частина перенесення йде без простою.
У нас частину служб розгортали руками — вони переживуть перенесення?
Так, але спочатку їх інвентаризують: ручні правки виймаються із системи й описуються в конфігурації. Так вже розгорнуте середовище відтворюється на новому контурі один в один, а не «як вийде», і перестає залежати від того, хто і коли щось поправив на сервері.
Як перевіряють, що результат коректний?
Звіркою даних, відгуком кожної служби й перевіркою прикладних сценаріїв за чек-лістом. Збіг контрольних сум і однакові відповіді на старому та новому контурі — критерій приймання, а не загальне враження «ніби працює».
Чи є резервні копії та зворотне перенесення?
Резервні копії знімаються перед кожним етапом і перевіряються на відновлення, а не просто створюються. Зворотне перенесення на старий контур залишається доступним увесь час приймання, тому помилку можна відкотити, не збираючи систему заново.
Як це позначиться на роботі розробників?
Вплив обмежується вікном перемикання: гілки, стенди й доступи зберігаються, змінюються лише адреси підключення. Заморожування змін узгоджується заздалегідь, щоб команда планувала релізи навколо вікна, а не дізнавалася про нього по факту.
Обговоримо завдання й повернемося з оцінкою та планом
Щоб оцінка була предметною, а не «залежить від складності», на вході потрібен короткий зріз вашого середовища: дистрибутив і гілка ядра на парку машин, схема розділів і файлових систем, спосіб завантаження, що крутиться поверх — веб-сервери, бази, черги, планувальники завдань.
Плюс обмеження: допустиме вікно недоступності, вимоги до розміщення даних, прив'язка до заліза або ліцензій, наявність резервного контуру.
Далі ми збираємо це в план перенесення й повертаємося з конкретикою:
- склад робіт: що переносимо як є, що перепаковуємо в конфігурацію, що виводимо з експлуатації;
- план перенесення за хвилями — з порядком, точками перевірки й критеріями готовності кожної хвилі;
- оцінка строків у робочих днях: підготовка, репетиції на копії контуру, продуктивні вікна;
- схема відкату: які знімки й копії залишаються доступними і за який час повертаємося до вихідного стану;
- перелік ризиків під ваші обмеження — сумісність драйверів, стан репозиторіїв, залежності між сервісами;
- технічне обговорення з вашими інженерами: розбір плану, правки з вашого боку, узгодження вікна;
- передача під супровід: документація, доступи, регламент реагування, якщо підтримку далі ведемо ми.
Опишіть поточне середовище й обмеження у вільній формі — повернемося з варіантами перенесення, строками та переліком робіт. Нав'язаних етапів не буде: частину пунктів ви відсічете відразу, решта ляже в основу робіт.
