Cloud миграция: нула прекъсване

„Нула прекъсване“ при cloud миграция не означава, че всеки байт се мести без нито една секунда freeze. Означава: потребителите не виждат outage — или само кратък, контролиран cutover — докато production кацне на нова инфраструктура. Това ръководство покрива blue-green, фазова пренос и DNS cutover към EuroVDC облачни сървъри / KVM.

Целта е София (ЕС)? Прочетете и ръководството за KVM VPS в България. За размер на плана — ръководството за наем на KVM. Тук фокусът е управлението на риска от прекъсване.

Какво означава реално „нула downtime“

• Сайтове с много четене: Старо и ново паралелно; DNS или load balancer прехвърля; записите се синхронизират с кратък freeze.
• Приложения с много писане: Кратък maintenance (минути) или freeze срещу replication lag е нормално; „буквално нула секунди“ често е маркетинг.
• Метрика: HTTP 5xx, неуспешни плащания и „сайтът го няма“ — вашият SLA дефинира успеха.

Инвентар преди преместване

1. App stack (PHP, Node, Docker…), web сървър, reverse proxy.
2. Размер на базата, двигател (MySQL/PostgreSQL), налична репликация.
3. Файлово хранилище (uploads, media); може ли object storage?
4. Cron, опашки, websocket, изходящ имейл.
5. SSL, DNS TTL, зависими поддомейни.
6. Тайни и API ключове — готови на целта, не само в git.

Липсващият инвентар създава изненади в деня на cutover. Първо вдигнете същия образ на staging.

Стратегия A: Blue-green (паралелни среди)

Старата среда е „blue“, EuroVDC cloud е „green“. Green работи с app плюс DB snapshot/replica; smoke тестовете минават; трафикът отива към green. При проблем DNS/LB се връща към blue.

1. Провизирайте целевия VM (София), укрепете OS и firewall.
2. Deploy на кода; вържете production тайни.
3. Приближете DB чрез replica или dump + binlog/WAL.
4. Health check на green (login, кошница, критични API).
5. Намалете TTL рано; при cutover сменете A/AAAA или LB backends.
6. Дръжте blue ~48 часа (rollback).

Стратегия B: Фазова миграция

Първо статично/CDN, после read replicas, после write master. Разделя риска при магазини и големи бази. Всяка фаза има писмен rollback.

• Фаза 1: Media/object storage или CDN origin.
• Фаза 2: Част от read трафика към новите app сървъри.
• Фаза 3: DB promote / final sync + кратък write freeze.
• Фаза 4: Наблюдение на стария хост, после изключване.

DNS, SSL и прозорец за cutover

Свалете TTL на 300 (или по-ниско) 24–48 часа преди cutover. Валидирайте SSL на новия IP предварително. Планирайте cutover в слаб трафик; добавете payment webhook allowlist за новия IP.

Ако домейнът е в EuroVDC, обновете A записите в панела чрез запитване за домейн / DNS; същата логика важи и при външен регистратор.

Синхрон на базата: практически варианти

• Малка DB (<5–10 GB): Dump/restore в maintenance прозорец с app freeze.
• Средна/голяма: Репликация, promote при lag ≈ 0; кратък freeze.
• Много файлове: rsync dry-run, после финален delta при cutover.

След cutover проверете интегритет: брой редове, последни order ID, критични cron-ове само веднъж.

Чести грешки при миграция

• Cutover без намален TTL — часове split-brain.
• Обръщане на production DNS без staging репетиция.
• Cron на двата хоста (двойни таксувания / двойни имейли).
• Преместване на файлове без .env и queue worker.
• Изтриване на blue веднага без план за rollback.
• Отказ от write freeze в името на „нула downtime“ и риск от загуба на данни.

Примерен график (среден SaaS)

1. T-7 дни: Инвентар, целеви VM, staging репетиция.
2. T-2 дни: Намален TTL, SSL, старт на репликация.
3. T-0 (60–90 мин): Freeze на записи → final sync → DNS/LB → smoke → unfreeze.
4. T+2 дни: При стабилни метрики — решение за спиране на blue.

Практически бележки за EuroVDC

На Sofia KVM с root инсталирате собствен reverse proxy (Nginx/Caddy); IP от панела влиза в DNS. Domain + SSL в същия акаунт скъсява cutover checklist. В деня на преноса запишете staging smoke (screenshot + curl) преди ticket — ускорява диагнозата.

Добавете payment и email allowlist към новия IP на T-1. Следете 5xx и дължина на опашката 24 часа след cutover; тихите грешки обикновено са в cron и webhook, не на началната страница.

Често задавани въпроси

Възможен ли е истински нулев downtime?

При системи с много четене видимото прекъсване често може да се избегне. При тежки записи и единичен master DB краткият планиран freeze е по-безопасен; твърденията за „буквално нула секунди“ обикновено са преувеличени.

Каква е типичната цел при EuroVDC?

KVM облачен сървър в София с root, NVMe и локация в ЕС. Оразмерете плана според натоварването и репетирайте със същия образ на staging.

Blue-green или фазова миграция?

Blue-green е бърз за малки/средни приложения. Фазовата миграция разделя риска при големи DB или много компоненти. Комбинацията е често срещана.

Кога да намалим DNS TTL?

Най-малко 24–48 часа преди cutover. Иначе resolver-ите кешират стария IP и трафикът се разделя.

Как работи rollback?

Дръжте старата (blue) среда поне 48 часа. Върнете DNS/LB; имайте писмен план за синхрон на записи след cutover обратно към blue при нужда.

Имейл и cron по време на миграция?

Заключете cron да работи само от едната страна. Добавете SMTP/webhook allowlist на новия хост, за да избегнете тихи грешки при доставка.

Планирайте преноса

Сравнете планове в София: Облачен сървър. За тежък single-tenant: dedicated сървър; за локация: ръководството за Sofia VPS.