Nejprve připravte a otestujte nový server, zkopírujte data metodou konzistence podporovanou aplikací, definujte okno přepnutí a zachovejte staré prostředí. Rollback musí zohlednit zápisy přijaté na novém serveru, nejen změnu DNS.
Před přesunem stroje proveďte inventuru služby
Migrace zahrnuje více než soubory aplikace. Vypište databáze, nahrané soubory, plánované úlohy, pracovníky front, certifikáty, domény, tajné údaje a odchozí integrace. Zaznamenejte verze softwaru a důležité provozní předpoklady, jako jsou oprávnění k souborům a cesty úložiště. Nový dedikovaný server může odhalit zapomenutou závislost, která byla tiše nainstalována před lety ve starém prostředí.
Přiřaďte vlastníka rozhodnutí o přepnutí a definujte, jak vypadá úspěch. Zahrňte kontroly viditelné pro uživatele, konzistenci dat a schopnost obnovit přístup. Před oznámením data migrace potvrďte, že nová konfigurace je dodána a použitelná. Potvrzení objednávky nebo uvedená specifikace hardwaru není totéž jako funkční cíl připravený přijímat produkční data.
Cílové prostředí postavte jako samostatné
Nainstalujte požadovaný stack, zřiďte správu a nakonfigurujte zamýšlený firewall. Uchovávejte tajné údaje v soukromí a oprávnění služeb nastavte záměrně. Před přesunem veřejného provozu ověřte očekávané chování hostname a certifikátu aplikace. Dokumentace Apache k virtuálním hostitelům ukazuje, proč je směrování podle hostname samostatné konfigurační rozhodnutí od adresy serveru. Funkční výchozí stránka neprokazuje, že je nakonfigurován správný hostitel aplikace.
Pro nácvik použijte reprezentativní obnovenou datovou sadu s vypnutým nebo na bezpečné testovací systémy přesměrovaným odchozím e-mailem, platbami a plánovanými úlohami. Zabráníte tak tomu, aby testovací prostředí jednalo vůči skutečným uživatelům. Procvičte přihlášení, nahrávání, práci na pozadí a obnovu. Zaznamenejte postup a jeho trvání, aby skutečné okno vycházelo z pozorovaného procesu, nikoli z optimismu.
Zvolte konzistentní datovou hranici
Použijte metodu zálohování nebo replikace podporovanou databází a aplikací. PostgreSQL rozlišuje SQL dumpy, zálohy souborového systému a průběžné archivování, z nichž každé má vlastní předpoklady. Jeho pokyny k dumpům uvádějí, že databázové dumpy mohou být vnitřně konzistentní, zatímco role v rámci clusteru a další podrobnosti vyžadují samostatné řešení. Přečtěte si požadavky pro přesný systém, který provozujete, místo abyste bez rozmyslu kopírovali otevřené datové soubory.
Naplánujte, jak databáze souvisí s nahranými soubory a stavem front. Pokud záznam odkazuje na soubor zkopírovaný v jinou dobu, obnovená aplikace může být neúplná, i když obě kopie jednotlivě uspěly. Rozhodněte, zda krátce pozastavit zápisy, použít otestované uspořádání replikace nebo provést export specifický pro aplikaci. Toto rozhodnutí o konzistenci výslovně uveďte v runbooku.
| Fáze | Požadovaný důkaz | Rozhodnutí |
|---|---|---|
| Nácvik | Aplikace a obnovená data projdou kontrolami | Cíl lze zvážit pro přepnutí |
| Závěrečná synchronizace | Definovaný konzistentní bod obnovy | Pokračujte pouze s pochopenými zbývajícími změnami |
| Přepnutí provozu | Správné směrování a chování certifikátu | Sledujte oba cíle |
| Rollback | Umístění všech nově přijatých zápisů | Před vrácením provozu sladte data |
Připravte směrování provozu bez slibů okamžitých změn
DNS time-to-live určuje, jak dlouho mohou být záznamy uloženy v mezipaměti, jak vysvětluje dokumentace Cloudflare k DNS. Pokud je součástí migrace DNS, zkontrolujte TTL včas a nechte stávající záznamy v mezipaměti vypršet podle jejich předchozího nastavení. Změna hodnoty v okamžiku přepnutí nemůže zpětně zkrátit všechny odpovědi v mezipaměti. Během přechodu mohou různí klienti dosáhnout různých cílů.
Ponechte staré prostředí dostupné, dokud se změny směrování neusadí, s promyšlenou politikou, zda může stále přijímat zápisy. Vyhněte se souběžnému spouštění duplicitních spotřebitelů front nebo plánovaných úloh, pokud pro to aplikace není navržena. Sledujte požadavky na obou stranách a z nezávislých klientů potvrďte zamýšlený hostname, certifikát TLS a verzi aplikace.
Definujte rollback po zahájení zápisů
Než nový systém začne přijímat změny, může být vrácení provozu poměrně jednoduché. Poté může samotné vrácení DNS způsobit ztrátu práce nebo vytvořit dvě konfliktní historie. Definujte, jak budou nově vytvořené záznamy a nahrané soubory zachovány nebo sladěny. Pokud je aplikace nedokáže bezpečně sloučit, může být řízené období údržby vhodnější než improvizovaný návrat ke staré kopii.
Stanovte podmínky, které vyžadují pozastavení migrace, a udržujte vlastníka rozhodnutí dosažitelného. Uchovávejte protokoly a užitečné důkazy podle pravidel uchovávání projektu. Nemažte starý stroj ani jeho nezávislou záložní kopii jen proto, že se jednou načetla domovská stránka. Doba uchovávání by měla pokrýt dohodnuté potřeby ověření a rollbacku.
Migraci uzavřete provozními kontrolami
Po přepnutí ověřte zálohy, upozornění, obnovu certifikátů, plánované úlohy a obnovu přístupu. Potvrďte, že sledovaný hostitel je nový cíl a že v produkci nezůstaly žádné testovací integrace. Zkontrolujte chyby aplikace a časy viditelné pro uživatele při běžném provozu. Aktualizujte inventuru a runbook, aby další správce nemusel odhadovat, co se změnilo.
Dedikované řady SwissOctet nabízejí různé fyzické konfigurace, ale migrační práce a spravovaná asistence musí být potvrzeny pro zvolenou službu. Pomocí katalogu vyberte vhodné prostředky a poté postavte otestovaný přesun kolem dat vaší aplikace. Migrace je dokončena, když služba a její proces obnovy fungují na cíli, ne jednoduše když byly přeneseny soubory.
Váš praktický kontrolní seznam.
- Zinventarizujte data, úlohy, tajné údaje a integrace.
- Před plánováním ověřte dodaný cíl.
- Nacvičte to s bezpečnými externími integracemi.
- Definujte konzistenci databáze a nahraných souborů.
- Naplánujte přechod směrování a prevenci duplicitních úloh.
- Určete rollback pro nové zápisy.
- Po přepnutí ověřte zálohy a monitorování.
Podrobnosti, na kterých záleží.
Mohu migrovat zkopírováním adresáře aplikace?+
Pouze pokud to zachytí vše, co služba potřebuje, a zachová konzistenci. Databáze, nahrané soubory, úlohy, tajné údaje a konfigurace obvykle vyžadují samostatnou pozornost.
Způsobí snížení TTL DNS okamžité přepnutí?+
Ne. Dříve uložené odpovědi mohou zůstat do konce své dřívější životnosti a klienti se mohou aktualizovat v různých časech.
Je rollback jen nasměrování DNS na starý server?+
Ne poté, co nový server přijme zápisy. Před vrácením provozu musíte zohlednit tyto záznamy a soubory.
Jděte ke zdroji.
Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací.
- PostgreSQL: Zálohování a obnova www.postgresql.org
- PostgreSQL: Konzistence a obnova SQL dumpu www.postgresql.org
- Apache: Dokumentace k virtuálním hostitelům httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně.