Міграція є проєктом, а не тикетом.
Високонавантажену платформу видавця переархітектовано для масштабу, навантажувально протестовано і перенесено на наш bare metal. Видимий для клієнта вплив: вікно близько п’яти хвилин усередині двогодинної операції.
У цій статті 4 розділів
- Групі високонавантажених ресурсів великого видавця треба було переїхати між датацентрами на наш bare metal, і дорогою їх переархітектували для масштабу. Трафік термінових новин є їхнім бізнесом, і кожен читач побачив би невдалий cutover.
- Спочатку ми спроєктували платформу: дворівневий edge-кеш на all-flash SAN, балансувальник, налаштований на дуже велику кількість з’єднань, рівень бази даних з розділенням читання і запису та рівень object cache.
- Потім ми довели її під повномасштабним навантажувальним тестом, перш ніж перемістити бодай одного справжнього читача.
- Cutover був двогодинною операцією з видимим для клієнта вікном DNS близько п’яти хвилин, кожна фаза зі шляхом відкату.
Це новинні та lifestyle-сайти, де сплеск трафіку і є бізнесом. Міграція, яка їх кладе або піднімає повільнішими, видима кожному читачеві посеред термінової новини. Це ніколи не мало бути тикетом. Це був проєкт з ніччю cutover.
Чому одна команда на всю роботу
Робота потребувала двох речей одночасно, від однієї команди: інженерії, щоб переархітектувати рівні кешування та бази даних, і власної інфраструктури (all-flash enterprise SAN, справжній мережевий fabric), на яку це посадити. Ми звели інженерів і залізо разом, і ніч cutover була нашою.
Платформа, як її спроєктовано
Задум проєкту був потрійним: переархітектувати для масштабу кешу та бази даних, провести cutover з мінімальним обмеженим вікном і пронести кожен елемент нового дизайну через cutover неушкодженим. Ось чим це стало.
Дворівневий edge-кеш Varnish
HAProxy попереду
ProxySQL на кожному вебвузлі
Кластер Percona XtraDB
Valkey + Sentinel
Детерміноване перемагає елегантне
База даних переїхала через свіжий гарячий backup, а не через наздоганяння живої реплікації. Це було проєктне рішення з названим обґрунтуванням: backup детермінований, тож те, що є в backup, і є тим, що має новий кластер, без стану реплікації, який треба розплутувати в найгірший можливий момент. Елегантніший шлях існує, і ми свідомо від нього відмовилися. У ніч cutover ви хочете переїзд, результат якого вже знаєте.
Швидке переміщення даних означало передати їх у два стрибки: через публічний інтернет на проміжний relay, а потім через внутрішню LAN на швидкості лінії, перетворивши копіювання, обмежене криптографією, на кілька хвилин. На місці призначення кластер відбудували з backup і ресинхронізували вузол за вузлом.
А синхронізація файлової системи несла хірургічно точний список винятків, щоб міграція не могла затерти конфігурацію нового дому: конфігурація з вказівником на базу даних, drop-in object cache і налаштування дворівневого кешу були явно збережені. Єдиний елемент стану, який відновлення бази даних тихо стирає, активація плагіна очищення кешу, був заздалегідь нанесений на карту, з готовою до запуску повторною активацією. Ось що означає спроєктувати cutover двічі: один раз уперед і один раз для всього, що може вкусити дорогою.
Дані, у два стрибки
Публічний інтернет до проміжного relay, потім внутрішня LAN на швидкості лінії. Хвилини, а не години.
Кластер відновлено з гарячого backup
Ресинхронізовано вузол за вузлом.
Переміщення файлової системи, під охороною
Список винятків захищає нову архітектуру від затирання.
DNS перемикається
Видиме вікно: близько п’яти хвилин.
Єдине тихо стерте налаштування повторно активовано
За графіком, бо його нанесли на карту заздалегідь.
“Ми не перемістили ваші сервери. Ми відбудували вашу платформу і посадили її на нашу, у вікні близько п’яти хвилин, спланованому заздалегідь.”
Чим стали ці відносини
Міграція була точкою входу, а не кінцем. Споріднені ресурси пішли за тим самим шаблоном, а операційна дисципліна прийшла як частина побудови, а не як пізніший upsell: часті гарячі backup бази даних і збережені snapshot файлової системи, налаштовані edge-кеші, підключений рівень моніторингу продуктивності на весь парк і валідація навантажувальними тестами перед запуском. Відносини усталилися як «ми експлуатуємо і розвиваємо платформу», а не «ми її хостимо».
Прямі відповіді
Чи можете ви мігрувати високонавантажений сайт, не кладучи його?+
Ми плануємо обмежене вікно і називаємо його заздалегідь. У цьому проєкті: близько п’яти хвилин видимого для клієнта поширення DNS усередині двогодинної операції.
Backup і відновлення чи реплікація для міграції бази даних?+
Обидва варіанти правомірні. Тут ми обрали свіжий гарячий backup, бо він детермінований: те, що є в backup, і є тим, що має новий кластер, без стану реплікації, який треба розплутувати посеред cutover. Елегантний шлях не завжди є безпечним.
Що має містити план відкату міграції?+
Шлях відкату на кожній фазі і задокументований шлях назад до джерела, доки нова платформа не заслужить довіру.
Ви переархітектовуєте під час міграції чи просто переносите?+
Якщо переїзд вартий проєкту, він зазвичай вартий і переархітектури. Ця платформа отримала дорогою дворівневий edge-кеш, рівень бази даних з розділенням читання і запису та рівень object cache. Lift-and-shift іноді є правильним, але це рішення, а не замовчування.
Плануєте переїзд? Принесіть нам платформу, а не тикет.
Проєктування, навантажувальний тест, playbook для cutover, страхувальні канати відкату. Ми назвемо вам чесне вікно ще до тієї ночі і триматимемо страховку.
Поговоріть з інженером (shell cta.talkToEngineer)Ви дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером