Analýza rozhodovacích kritérií pro výběr nástrojů a model migrace
Teď, když jsme prozkoumali možnosti metodologií migrace a možností nástrojů, můžeme prozkoumat rozhodovací kritéria, která je potřeba zvážit při provádění migrací na flexibilní server Azure Database for PostgreSQL. Tři hlavní kritéria, která nám pomáhají při rozhodování, jsou Výpadek, umístění zdrojové databáze a přizpůsobitelnost.
Odstávka
Výpadek je klíčovou vlastností aktivit migrace a doba trvání, která je přijatelná pro zúčastněné strany, nám pomáhá rozhodnout, jestli musíme provést offline nebo online aktivitu migrace.
Za normálních okolností se aktivity migrace plánují dobře předem, aby se zajistilo, že jsou pro danou aktivitu dokončeny příslušné kontroly změn a související zásady správného řízení. Toto plánování umožňuje dialog s klíčovými účastníky pochopit, jak dlouho může být systém offline. V této situaci je vhodné vědět, jak dlouho trvá různé možnosti, které můžete stanovit odhadované minimální a maximální doby výpadku.
Stanovení minimálního výpadku potřebného k provedení přímé migrace aplikace je klíčem. V konečném důsledku je tentokrát částka, kterou musíte převést systém do offline režimu i pro online (nebo minimální prostoje) aktivity migrace. Složitost aplikace bude diktovat tuto časová osa. U relativně jednoduché aplikace může být tento proces případ zastavení služby, aktualizace konfiguračního souboru a jeho následné zapnutí. V složitějších prostředích může tento proces trvat mnohem déle, pokud se hraje více serverů a aplikačních vrstev.
Pochopení doby trvání potřebné pro aktivity online nebo offline migrace je dalším důležitým prvkem souvisejícím s výpadky. Pokud se jedná o offline migraci, doba potřebná k extrakci, přenosu a načtení dat ze zdroje do cíle následovaná ověřením a ověřením je váš výpadek. Tento výpadek se pak zachytá mezi dobou potřebnou k vypnutí aplikace nebo úlohy a časem potřebným k tomu, aby se aplikace nebo úloha znovu zapnula.
Pokud se jedná o online (minimální prostoje), je doba trvání potřebná k synchronizaci konečných změn ze zdroje do cíle po vypnutí aplikace. Před změnou konfigurace a povolením aplikace nebo úlohy přidejte do této prostoje, ověření a ověřovací aktivity.
Jakmile budeme mít tyto informace, můžeme se podívat na technické prvky migrace, abychom mohli zjistit, jaké jsou naše realizovatelné možnosti.
Umístění zdrojové databáze
Zdrojové umístění databází, které se mají migrovat, hraje roli kvůli omezením, která budou pravděpodobně zavedena pro jakoukoli danou konfiguraci.
Místní zdroje nebo zdroje mimo Azure
V případě místní databáze nebo databáze, která není umístěná v Azure, je omezení klíče obvykle síťové připojení mezi zdrojem a cílem. Tři body, které je potřeba vzít v úvahu, jsou šířka pásma, latence a objem dat. Jakmile těmto bodům rozumíme, můžeme se informovaně rozhodnout, jaký typ migrace je realizovatelný.
Pokud máme velký objem dat pro migraci a proporcionálně malou šířku pásma, nebude pravděpodobně možné jednoduchý výpis a obnovení. Vzhledem k tomu, že pokud máme velký objem dat a velkou šířku pásma, je to méně důležité.
Podobně platí, že pokud se jedná o online migraci, ve které se provede synchronizace dat, je latence jedním z klíčových faktorů. Pokud je latence vysoká, může to mít nepříznivý dopad na výkon systému, protože dokončení procesu synchronizace trvá příliš dlouho.
Jedním z důležitých faktorů, které je potřeba vzít v úvahu při migraci od jiných poskytovatelů cloudu, je to, jestli se účtují poplatky za výchozí přenos dat. Pokud ano, může být potřeba vzít v úvahu možnost minimalizovat fyzickou stopu přenášených dat. V takových situacích může být technologie komprese důležitá pro výpisy paměti nebo datové proudy používané pro synchronizaci.
Další služby založené na Azure
Existují situace, kdy chcete migrovat z jiných služeb založených na Azure na flexibilní server Azure Database for PostgreSQL. Tyto zdrojové databáze můžou být na virtuálních počítačích, kontejnerech Azure nebo na jednoúčelovém serveru Azure Database for PostgreSQL. Pokud ano, existuje jiná sada aspektů, které je potřeba prozkoumat, ale současně, existuje několik příležitostí, jak využít optimalizace v rámci služeb Azure pro tyto scénáře.
Přizpůsobitelnost
Poslední oblastí, ve které je potřeba vzít v úvahu, je to, kolik přizpůsobení je potřeba nebo jak potřebujete. Tento faktor může mít podobu nutnosti upravit strukturu zdrojové databáze tak, aby podporovala replikaci dat, případně to může znamenat, jak snadné je automatizovat prostřednictvím skriptování.
Dobrým příkladem je automatizace offline migrace databáze prostřednictvím pg_dump a pg_restore, ale současně by zahrnovala kompresi a dekompresi souborů s výpisem paměti.
Rozhodování
Teď, když jsme prošli procesem shromažďování všech těchto informací, můžeme spolupracovat se zúčastněnými stranami a určit nejlepší možnost pro daný scénář. Při rozhodování o tom, která metodologie a technologie jsou nastavené tak, aby používaly, je důležité nejen pracovat s obchodními účastníky, ale také s technickými účastníky. Tato spolupráce pomáhá vyhnout se situaci, kdy firma řídí minimální prostojovou migraci, kterou technický tým nemá v pozici, aby ji zajistil kvůli personálním, zdrojům nebo technologickým omezením.
Klíčovou věcí je spravovat očekávání a mít otevřený a upřímný dialog. Je také důležité zajistit, aby firma vezměla vlastnictví ověřovacích úkolů, které se nacházejí mimo pravomoci technických týmů zajišťujících migraci databáze. Toto ověření může zahrnovat kontrolu konzistence dat a ověřování a testování uživatelského prostředí.