Files
knowledge-base/DC-MIGRATION.md
Stanislav Hubacek b53714113c new files
2026-06-16 15:47:45 +02:00

9.9 KiB
Raw Permalink Blame History

🏗️ Migrace datových center

Strategie migrace

Strategie RTO RPO Riziko Náklady Doba trvání Popis
Cold / Big Bang hodinydny dny Vysoké Nízké dny Vše najednou vypnout, přesunout, zapnout
Phased / Wave minuty (per wave) minuty Střední Střední týdnyměsíce Workloady po vlnách
Rolling 0 (live) 0 Nízké Vysoké měsíce Live migration per VM/služba
Parallel Run 0 0 Nízké Velmi vysoké měsíce Oba DC v provozu, postupný přechod
Pilot Light hodiny minuty Střední Nízké týdny Kritické služby v novém DC, ostatní se přesouvají
Lift & Shift hodiny minuty Střední Nízké týdny VM/servery přesunuty bez změny konfigurace
Re-platform hodiny minuty Nízké Střední měsíce Optimalizace během migrace (OS upgrade, resize)
Re-architect 0 0 Nízké Vysoké měsíceroky Aplikace přepracována pro novou platformu

Rozhodovací strom

flowchart TD
    Start(["Migrace DC"]) --> APP{"Aplikace\nstateful?"}
    APP -->|"Ano"| DOWNTIME{"Toleruje\nvýpadek?"}
    APP -->|"Ne"| ROLLING["Rolling / Parallel Run"]

    DOWNTIME -->|"Ano, hodiny+"| COLD["Cold / Big Bang\nNejjednodušší, nejlevnější\nRiziko: vše najednou"]
    DOWNTIME -->|"Ano, minuty"| PHASED["Phased / Wave\nPo aplikacích / byznys jednotkách"]
    DOWNTIME -->|"Ne (zero downtime)"| SYNC{"Sync replikace\nmožná?"}

    SYNC -->|"Ano, < 100 km"| ROLLING
    SYNC -->|"Ne"| PARALLEL["Parallel Run\nOba DC aktivní, postupný cutover"]

    ROLLING --> ROLL_HA{"VMware,\nHyper-V?"}
    ROLL_HA -->|"Ano"| VMOTION["vMotion / Storage vMotion\nLive migration, 0 downtime"]
    ROLL_HA -->|"Ne"| ROLL_REPL["Storage + DB replikace\nPostupný přesun workloadů"]

Fáze migrace

1. Discovery a assessment

Úkol Nástroje Výstup
Inventarizace HW a SW RVTools, NetBox, CMDB Seznam všech serverů, VM, služeb
Dependency mapping ServiceNow, AppDynamics, manual Aplikační dependency graf
Traffic analysis NetFlow, sFlow, vRNI BANDWIDTH, latency, peak usage
Výkonnostní baseline Prometheus, Zabbix, vRealize CPU/RAM/disk/network per workload
Licenční audit Flexera, SAM Licence, support, compliance

Výstupem je: seznam workloadů s RTO/RPO, závislostmi a kritičností. Bez toho nelze naplánovat migraci.

2. Plánování

  • Wave plán — rozdělení workloadů do migračních vln (1050 VM na vlnu)
  • Závislostní řazení — DNS, NTP, LDAP, PKI musí být první
  • Cutover okno — časové okno pro přepnutí (typicky víkend)
  • Rollback plán — podmínky a postup pro vrácení
  • Testovací plán — co a jak testovat po migraci
  • Komunikační plán — kdo, kdy, jak je informován

3. Příprava nového DC

  • Infrastruktura — DNS, NTP, DHCP, LDAP/AD, PKI, monitoring (viz DATACENTERS.md — deployment order)
  • Network — BGP peering, VXLAN/VLAN, firewall pravidla, load balancery
  • Storage — SAN zoning, NAS exports, Ceph cluster
  • Virtualizace — vCenter, Hyper-V cluster, Proxmox

4. Replikace a synchronizace

Vrstva Metoda Nástroje
Storage (block) SAN sync/async mirror, LUN replication NetApp SnapMirror, Dell EMC RecoverPoint, Pure ActiveCluster
Storage (file) DFS-R, rsync, robocopy Windows DFS, Rsync
Storage (object) Cross-region replication MinIO replication, S3 CRR
Databáze Log shipping, CDC, streaming replication PostgreSQL Patroni, Oracle Data Guard, MSSQL AlwaysOn, MySQL Group Replication
VM Storage vMotion, replication VMware vSphere Replication, Hyper-V Replica, Zerto
Kubernetes Velero + Restic, Rook Ceph mirror Velero, Rook

5. Migrace workloadů

Wave migrace (doporučeno pro střední/větší DC)

gantt
    title Wave migrace
    dateFormat  YYYY-MM-DD
    section Wave 1 - Core
    DNS, NTP, LDAP    :done, w1a, 2026-07-01, 3d
    Monitoring + logging :done, w1b, after w1a, 2d
    section Wave 2 - Network
    Load balancers     :active, w2a, 2026-07-06, 2d
    Firewalls          :active, w2b, 2026-07-08, 2d
    section Wave 3 - Storage
    NAS migrace        :w3a, 2026-07-10, 5d
    SAN replication    :w3b, 2026-07-10, 3d
    section Wave 4 - Dev/Test
    Dev VMs            :w4a, 2026-07-15, 5d
    section Wave 5 - Prod tier 3
    Internal apps      :w5a, 2026-07-22, 5d
    section Wave 6 - Prod tier 2
    Business apps      :w6a, 2026-07-29, 5d
    section Wave 7 - Prod tier 1
    Critical apps      :w7a, 2026-08-05, 5d

Typický postup jedné vlny:

  1. Den -7: Sync replikace dat (initial seed)
  2. Den -1: Incremental sync, final test
  3. Den 0 (cutover):
    • Zastavení aplikace ve zdrojovém DC
    • Final sync (poslední delta)
    • Start aplikace v cílovém DC
    • DNS/Traffic switch
    • Smoke test
  4. Den +1: Monitorování (výkon, chyby, lag)
  5. Den +7: Rollback window end (potvrzení úspěchu)

6. Síťové strategie

IP re-addressing

Přístup Popis Výhody Nevýhody
Keep IP Stejné IP, BGP anycast nebo stretch VLAN Není třeba měnit konfiguraci aplikací Stretched VLAN/L2 omezení
Change IP Nový IP rozsah, DNS/BGP routing změna Čistá architektura Změny konfigurací, DNS TTL
NAT překlad NAT mezi starým a novým IP spacem Bez změny aplikací Latence, komplexita troubleshooting

Keep IP je možný jen:

  • L2 stretch mezi DC (VXLAN, OTV) — omezeno vzdáleností
  • BGP anycast pro VIP (load balancery)
  • Aplikace tolerující ARP cache změny

DNS cutover

1. Snížit TTL na 60300 s (týden předem)
2. Při cutoveru změnit A/AAAA záznamy na nové IP
3. Počkat na propagaci (dle TTL)
4. Monitorovat traffic

Traffic steering

Technika Use case
BGP Změna AS path / local pref pro přesměrování trafficu
DNS Snížení TTL, change A records
Load balancer Změna pool members, health check
GSLB Global Server Load Balancing (F5 GTM, NSX ALB)
Cloud DNS AWS Route53, Azure Traffic Manager, Google Cloud DNS

7. Databázová migrace

Viz detail v jednotlivých DB souborech. Tabulka shrnutí:

DB Metoda RPO RTO Poznámka
PostgreSQL Streaming replication + Patroni switchover 0 (sync) / ~MB (async) min Patroni auto-failover
MySQL Group Replication / async replication 0 (sync) / sekundy min InnoDB Cluster
Oracle Data Guard switchover 0 (sync) min Far sync pro vzdálené DC
MSSQL AlwaysOn AG failover 0 (sync) min Cloud witness
MongoDB Replica set election sekundy < 1 min Priority-based failover
Cassandra Multi-DC replication eventual 0 Nativní multi-master

8. Testování

Fáze Co testovat Metoda
Pre-migrace Aplikace v novém DC (izolovaně) Dry run na replikovaných datech
Cutover Funkčnost, dostupnost, latence Smoke test, synthetic transactions
Post-migrace Výkon, integrace, monitoring A/B comparison s baseline, canary traffic
Rollback Návrat ke starému DC Testovaný rollback plán

9. Rollback plán

Každá vlna musí mít definovaný rollback:

Podmínka Akce
Aplikace nestartuje v novém DC Přepnutí DNS zpět, zastavení replikace
Výkon horší než baseline (o > 20 %) Rollback, analýza příčiny
Integrační selhání (API timeout, DB connection) Rollback, dependency check
Bezpečnostní incident Rollback, forenzní analýza

Rollback by měl být otestován před reálným cutoverem.


Speciální případy

Mainframe migrace

  • IBM z/OS — GDPS (Geographically Dispersed Parallel Sysplex)
  • HyperSwap pro storage mirroring
  • Cross-system coupling facility (XCF)
  • Často poslední migrovaná komponenta

COTS aplikace (Oracle EBS, SAP)

  • Vyžadují specifické migrační postupy výrobce
  • Oracle EBS: Autoconfig, cloning (ADXLC)
  • SAP: System Copy (Homogeneous / Heterogeneous), SWPM, SUM
  • Licenční re-licensing při změně HW

Cloud migrace (On-prem → Cloud)

Viz CLOUD.md — migrační strategie (6 Rs):

Strategie Popis
Re-host (Lift & Shift) VM → Cloud VM (AWS MGN, Azure Migrate)
Re-platform OS upgrade, managed DB (RDS, Cloud SQL)
Re-architect Aplikace přepsána na cloud-native
Retire Zastavení nepotřebných aplikací
Retain Aplikace zůstává on-prem (revize později)
Repurchase SaaS náhrada

Doporučený postup per velikost DC

Velikost DC Počet VM Doporučená strategie Doba trvání Tým
Small < 50 Big Bang (víkend) 24 dny 35 lidí
Medium 50500 Phased (510 wave) 28 týdnů 510 lidí
Large 5005000 Phased + Rolling 312 měsíců 1030 lidí
Enterprise 5000+ Parallel Run / Rolling 1236 měsíců 30+ lidí

Související

Zdroje

Odkazy, knihy a standardy: sources/infrastructure/sources.md

Poslední revize: 2026-06-12