Úvahy pro konfiguraci

24 min

Obchodní systém spuštěný místně může mít architekturu, která je spojená s jinými službami provozovanými ve stejném prostředí. Je důležité pochopit vztahy mezi systémem, který chcete migrovat, a ostatními aplikacemi a službami, které vaše organizace aktuálně používá.

Ve vaší společnosti začínající technologie se databáze dodavatelů používá k zajištění, že komponenty jsou vždy na skladě a přicházejí včas pro jejich použití ve výrobním procesu. Kontroloři zásob používají mobilní zařízení k aktualizaci této databáze při doručení zásilek a kupujících používají web k monitorování úrovní zásob a identifikaci nejlepšího času na objednávku. Manažeři používají sadu sestav důležitých pro firmy k monitorování procesu a zlepšení efektivity. Chcete zajistit, aby migrace do Azure nezáporně ovlivnila žádné z těchto uživatelů.

Tady se dozvíte, jak naplánovat a spustit bezproblémovou migraci databází do cloudu.

Zkoumání závislostí

V komplexním systému komponenta zřídka funguje zcela nezávisle. Místo toho volá jiné procesy a komponenty. Databáze můžou například záviset na adresářových službách, které hostují uživatelské účty. Když přesunete databázi do cloudu, můžete k této adresářové službě přistupovat? Pokud ne, jak se budou uživatelé přihlašovat? Když takovou závislost přehlédnete, může dojít k celkovému selhání databáze.

Pokud chcete zmírnit rizika, zkontrolujte, jestli vaše databáze závisí na službách, jako jsou následující:

Adresářové služby, například Active Directory.
Další úložiště objektů zabezpečení
Jiné databáze.
Webová rozhraní API nebo jiné síťové služby.

Mějte také na paměti, že na vaší databázi můžou záviset další komponenty. Pokud přesunete databázi bez překonfigurování závislých komponent, jaké jsou důsledky? Pokud například přesunete databázi katalogu produktů a veřejný web na něm závisí, aby určil, jaké produkty mají být prezentovány uživatelům, způsobí přesun přerušení služby?

Zkontrolujte, jestli některý z těchto typů komponent závisí na vaší databázi:

Weby a webová rozhraní API.
Klientské aplikace, jako jsou mobilní aplikace a desktopový software.
Jiné databáze.
Zprávy.
Datové sklady.

Pokud chcete tyto kontroly provést, promluvte si se zúčastněnými stranami, správci a vývojáři zapojenými do jednotlivých databázových a systémových komponent. Pokud si nejste jistí, že rozumíte chování systémů, podívejte se do dokumentace, zvažte spuštění testů, jako jsou zachytávání sítě, abyste mohli sledovat chování.

Příprava na návrat

V jakémkoli projektu migrace byste měli být vždy připraveni na selhání. V projektu migrace databáze do cloudu je nejhorším případem, že nová databáze přestane být dostupná a uživatelé nemůžou dělat své úlohy. Toto riziko je běžné zmírnit, což může mít velký dopad na ziskovost vaší společnosti tím, že se plánuje vrátit k původní, neupravené databázi místně.

U náhradního plánu zvažte následující:

Jak zajistit, abyste se mohli vrátit k databázi, která není ovlivněná neúspěšnou migrací? Důrazně se například doporučuje provést úplné zálohování databáze těsně před zahájením migrace.
Jak dlouho je přijatelné, aby byla databáze offline, pokud se potřebujete vrátit?
Kolik rozpočtu máte na náhradní plán? Můžete si například dovolit replikovat databázi na vyhrazený záložní server? Pokud ano, můžete tento server před migrací vypnout. Chcete-li se vrátit, spustíte tento server. Okamžitě byste měli databázi, na kterou migrace nemá vliv, aniž byste ji museli obnovit ze zálohy.

Offline versus online migrace

Pokud chcete migrovat databázi, máte aspoň dvě možnosti:

Poznámka:

Online možnost není aktuálně dostupná pro databáze MySQL ve službě Data Migration Service.

Zastavte systém, přeneste databázi a potom znovu nakonfigurujte a restartujte systém, aby používal novou databázi. Jedná se o offline migraci.
Během přesunu databáze do nového umístění zachovejte systém spuštěný, přepočítejte transakce prováděné proti původní databázi do nové databáze, zatímco migrace pokračuje, a pak přepněte aplikace tak, aby se připojily k nové databázi. Jedná se o online migraci.

Je jednodušší provést offline migraci, kdy uživatelé nemůžou měnit data během migrace. Pokud je ale vaše databáze zaneprázdněná nebo kritická pro úspěch vaší organizace, nemusí to být možné.

Offline migrace

Předpokládejme, že vaše databáze podporuje tým analytiků, kteří během normální pracovní doby pracují v jednom časovém pásmu. Tým obvykle nepracuje o víkendech. Od 19:00 do 19:00 v neděli se databáze často nepoužívá.

V takovém případě můžete provést offline migraci o víkendu pomocí následujícího postupu:

Po dokončení všech transakcí v pátek večer přepněte databázi do offline režimu.
Proveďte úplnou zálohu nebo export databáze.
Vypněte místní server a zachovejte ho v případě, že se potřebujete vrátit zpět.
Obnovte databázi v cílovém cloudovém systému.
Přeneste cílový systém do režimu online.
Překonfigurujte klienty pro připojení ke cloudové databázi.

V tomto případě je možné offline migraci, protože existuje dlouhá doba, kdy přerušení služby má na uživatele malý vliv. Během této doby můžete provést úplnou zálohu a obnovení databáze, protože víte, že nezmeškáte žádné změny.

Online migrace

Teď zvažte jinou databázi, která podporuje prodejní aplikaci. Zaměstnanci prodeje jsou rozmístěni po celém světě a také pracují o víkendech. Neexistuje období nízké aktivity, databáze je vždy zaneprázdněná a pokud databázi přeberete offline po určitou dobu, ovlivní to uživatele. Obchodní aktivita je důležitá pro firmy, takže přerušení služby bude mít přímý vliv na spodní řádek organizace.

V takových případech zvažte provedení online migrace. Při online migraci je výpadek omezený na dobu potřebnou k přechodu na novou databázi. K provedení online migrace použijte nástroj, jako je Azure Data Migration Service. Online migrace mají následující rozdíly mezi offline migracemi:

Původní databázi před provedením zálohování nebo exportu nepřesunete do offline režimu.
Během migrace se změny vztahují na starou databázi.
Nástroj pro migraci zajistí, aby se tyto změny před přepnutím zkopírovaly do nové databáze. Toho se často dosahuje tak, že překonfiguruje starou databázi tak, aby replikuje změny do nové databáze.

Migrace aplikací

Jak (a kdy) byste měli po migraci databáze přejít na nový systém a aktualizovat aplikace tak, aby používaly novou databázi? Můžete:

Přesuňte aplikace 1 po druhém do nové databáze.
Přesun podmnožina uživatelů
Osvojte si kombinaci obou přístupů.

Záměrem je provést migraci aplikací v malých fázích, které se dají snadno vrátit zpět, pokud se něco pokazí. Bez ohledu na to, jestli jste postupovali podle offline nebo online přístupu k migraci databáze, měli byste mít stále funkční konfiguraci umístěnou v původním zdroji. Teoreticky budete moct rychle přepnout zpět na původní zdroj. Pokud se ale data neustále mění, musíte zvážit, kde byly tyto změny provedeny.

Při offline migraci jsou zdroje a cíle nezávislé na sobě. Uživatelé a aplikace už nemusí vidět konzistentní zobrazení dat. V transakčním systému je tato situace pravděpodobně nepřijatelná. V takovém případě byste museli zachovat určitou formu obousměrné replikace mezi databázemi, zatímco oba systémy zůstanou aktivní. Případně pokud je účelem aplikace generovat měsíční nebo týdenní sestavy, generovat projekce prodeje nebo provádět jiné statistické operace, nemusí být tato nedostatečná konzistence tak znepokojena. Takové aplikace mají "dlouhý pohled" na data, nikoli na aktuálních datech. V tomto druhém případě transakční aplikace používají novou databázi, zatímco aplikace pro vytváření sestav se posouvají pomaleji.
Při online migraci se nová databáze synchronizuje se starou databází, obvykle určitou formou replikace. Proces replikace může být asynchronní, takže může dojít k prodlevě. Změny dat v nové databázi se ale nebudou šířit zpět do původní databáze, což vede k možným konfliktům. Aplikace spuštěná ve staré databázi může provést konfliktní změnu dat upravených v nové databázi. Replikace nevidomě přepíše změnu v nové databázi, což vede ke ztrátě aktualizace.

Přístupy k testování

Pokud databáze hraje důležitou roli ve vaší firmě, můžou být důsledky selhání rozsáhlé. Pokud chcete zvýšit důvěru, že k tomu nedojde, zvažte spuštění testů výkonu u migrované databáze, aby se zajistilo, že se s tím uživatelé zatížení můžou dostat a rychle reagovat. Mějte na paměti, že pokud je poptávka mnohem vyšší než normální, může existovat období špičky aktivity. Musíte mít jistotu, že migrovaný systém zpracovává očekávané úlohy.

Před povolením přístupu uživatelů vždy proveďte určitý typ regresního testování proti nové databázi. Tyto testy ověří správnost chování a funkčnosti systému.

Dále byste měli zvážit spuštění "namočeného testu". Namočený test je zátěžový test navržený tak, aby viděl, jak systém jako celek pracuje pod tlakem. Test namočení zdůrazňuje novou databázi a určuje, jestli je stabilní pod vysokou poptávkou. Test namočení se spouští během významného časového období a zjistí, co se stane, když vysoká poptávka přetrvává.

Jakmile zjistíte, že je nový systém stabilní, můžete začít migrovat uživatele. Možná ale budete potřebovat další záruku, že uživatelé najdou nový systém přijatelný. V tuto chvíli můžete zvážit "kanárské testování". Canary test transparentně směruje malou podmnožinu uživatelů do nového systému, ale neví, že k němu přistupuje. Je to forma slepého testu, která vám umožní najít všechny problémy nebo problémy s novým systémem. Sledujte odpovědi od těchto uživatelů a proveďte potřebné úpravy.

Údržba paralelních systémů

Existuje několik důvodů, proč se můžete rozhodnout spustit starou místní databázi paralelně s novou cloudovou databází:

Testovací období. Jak jste viděli v předchozím tématu, je vhodné spustit kanárské testy vůči migrované databázi, aby bylo možné posoudit její funkčnost, stabilitu a kapacitu, než ji použijete k podpoře lidí. Udržování místního systému paralelně poskytuje rychlý způsob, jak vrátit uživatele ke starému systému, pokud dojde k problémům s novým systémem.
Fázované migrace. Jedním ze způsobů, jak zmírnit dopad neočekávaných selhání v produkčním prostředí, je nejprve přesunout malý počet uživatelů do nového systému a monitorovat výsledky. Pokud všechny běží hladce, můžete přesunout další skupiny uživatelů, jakmile budete mít jistotu v nové databázi. Uživatele můžete přesouvat abecedně, podle oddělení, podle umístění nebo podle role, dokud nebudou všichni v nové databázi.
Kusmeální migrace. Dalším přístupem je segmentovat migraci nejen uživatelem, ale podle úloh. Můžete například migrovat databázové tabulky, které podporují lidské zdroje, před tabulkami, které podporují prodej.

Ve všech těchto případech existuje období, kdy stará místní databáze běží paralelně s novou cloudovou databází. Je nutné zajistit, aby se na novou databázi použily také změny provedené ve staré databázi a aby tokly opačným směrem. Tuto synchronizaci můžete skriptovat nebo použít nástroj, jako je Azure Data Migration Service.

Pokud se rozhodnete udržovat paralelní databáze a synchronizovat změny, položte si tyto otázky:

Řešení konfliktů. Je pravděpodobné, že se změna místního řádku provede v podobné době jako jiná změna stejného řádku v cloudu? Tím dojde ke konfliktu, kdy není jasné, která změna by se měla zachovat. Jak byste takové konflikty vyřešili?
Síťový provoz. Kolik síťového provozu se vygeneruje, když se mezi databázemi synchronizují změny? Máte pro tento provoz dostatečnou kapacitu sítě?
Latence. Pokud dojde ke změně v jedné z databází, jaká prodleva (pokud existuje) je přijatelná před tím, než tato změna dosáhne druhé databáze? Například v katalogu produktů můžete čekat až den, než budou nové produkty viditelné pro všechny uživatele. Pokud však databáze obsahuje důležité transakční informace, jako jsou směnné kurzy měn, měla by se tato data synchronizovat mnohem častěji, pokud ne okamžitě.

Kusmeální migrace

Kusmeální migrace je místo, kde rozdělíte kompletní systém na úlohy a migrujete jednu úlohu najednou.

Více databází

Složitý systém může obsahovat více databází, které podporují několik úloh. Například lidské zdroje můžou používat databázi StaffDB, zatímco prodejní tým může mít mobilní aplikace, které dotazuje databázi ProductCatalogDB i databázi OrdersDB.

Samozřejmě můžete zvolit migraci celého databázového systému do cloudu najednou. To může být jednodušší, protože nemusíte spouštět databáze místně i v cloudu. Během migrace nemusíte uvažovat o tom, jak tyto databáze komunikují. Rizika selhání jsou však vyšší. Jeden problém může mít vliv na tým lidských zdrojů i prodejní tým.

Zvažte zmírnění těchto rizik u středně velkých a velkých databázových systémů provedením kusmeální migrace, kdy přesouváte jednotlivé úlohy najednou. V tomto příkladu byste mohli nejprve zvážit migraci databáze StaffDB , protože problémy spojené se selháním by byly omezené na tým lidských zdrojů a nezabránily vám v přijímání objednávek. Když vyřešíte všechny problémy, ke kterým dojde při migraci StaffDB , naučíte se lekce, které platí pro jiné migrace úloh.

V dalším kroku byste mohli uvažovat o migraci úlohy katalogu produktů do cloudu. Pokud to uděláte, zvažte například tyto otázky:

Jak zajistíte, aby byly produkty nově přidané do katalogu k dispozici k objednávce?
Potřebujete synchronizovat nějaká data s databází OrdersDB , která zůstávají v místním prostředí?
Jaká latence je pro nové produkty přijatelná pro přístup k databázi OrdersDB z katalogu produktů?

Jednoúčelové migrace databáze

I když máte jenom jednu databázi, která podporuje všechny úlohy, můžete přesto zvážit kusmeální migraci. Databázi můžete například rozdělit na části takto:

Tabulky, které podporují operace personálního oddělení.
Tabulky, které podporují prodej
Tabulky, které podporují analýzu a vytváření sestav.

Pokud nejprve migrujete provozní tabulky personálního oddělení, všechny problémy, které nastanou, ovlivní pouze pracovníky personálního oddělení. Prodej a datoví analytici nadále pracují na staré databázi bez přerušení.

Než provedete kusmeální migraci, musíte plně porozumět databázím a tomu, jak je aplikace používají. Některé tabulky v databázi můžou například podporovat prodej i vytváření sestav. To znamená, že nemůžete vyčistit dělení úloh. Tyto tabulky musíte synchronizovat mezi místními a cloudovými databázemi, dokud nebudou migrovány všechny úlohy.

Záležitosti zabezpečení

Vaše databáze můžou obsahovat citlivá data, jako jsou podrobnosti o produktu, osobní údaje o zaměstnancích a platební údaje, takže zabezpečení je vždy vysokou prioritou. Musíte se rozhodnout, jak tato data chránit během migrace a v nové databázi.

Ochrana brány firewall

V aplikaci připojené k internetu jsou databázové servery obvykle chráněné alespoň dvěma branami firewall. První brána firewall odděluje internet od front-endových serverů – pokud například tyto servery hostují weby nebo webová rozhraní API. Na vnější bráně firewall by měl být otevřený jenom port TCP 80, ale tento port musí být otevřený pro všechny zdrojové IP adresy s výjimkou blokovaných adres.

Druhá brána firewall odděluje front-endové servery od databázových serverů. Doporučuje se publikovat databázovou službu na privátním čísle portu, které není známo vnějšímu světu. Na druhé bráně firewall otevřete toto číslo portu pouze pro IP adresy front-end serverů. Toto uspořádání brání jakékoli přímé komunikaci před škodlivým internetovým uživatelem s databázovými servery.

Pokud plánujete migrovat databázové servery na virtuální počítače Azure, replikujte pravidla brány firewall pomocí virtuální sítě se skupinami zabezpečení sítě (NSG). Pokud používáte Azure Database for MySQL, Azure Database for MariaDB nebo Azure Database for PostgreSQL, můžete vytvořit pravidla brány firewall pro ochranu databáze pomocí stránky zabezpečení Připojení ion pro server na webu Azure Portal.

Ověřování a autorizace

Ve většině databází je potřeba pečlivě řídit, kdo přistupuje k datům a upravuje je. Tento ovládací prvek vyžaduje, aby se uživatelé při připojování k databázi kladně identifikovali. Tento proces se nazývá ověřování a obvykle se provádí pomocí uživatelského jména a hesla. Databázové systémy, jako jsou MySQL, MariaDB a PostgreSQL, poskytují vlastní mechanismy ověřování. Při migraci systémů do cloudu je nutné zajistit, abyste uživatele bezpečně ověřovali.

Poznámka:

Služby Azure Database for MySQL, Azure Database for MariaDB a Azure Database for PostgreSQL emulují tradiční ověřování MySQL, MariaDB a PostgreSQL.

Když víte, kdo je uživatel, musíte mu přiřadit oprávnění k dokončení úkolů, které jsou součástí jejich úlohy. Tento proces se nazývá autorizace.

V případě projektu migrace databáze musíte zajistit, aby uživatelé byli v cloudové databázi správně autorizovaní:

Zjistěte, kde jsou uživatelské účty uložené v místním systému. V MySQL jsou uživatelské účty obvykle uložené v user tabulce mysql databáze, ale je možné je například integrovat s uživatelskými účty uloženými ve službě Active Directory.
Získejte seznam všech uživatelských účtů. V MySQL můžete například použít tento příkaz:
```
SELECT host, user FROM mysql.user;
```
Pro každý uživatelský účet zjistěte, jaký přístup k databázi má. V MySQL můžete například použít tento příkaz pro dbadmin@on-premises-host uživatelský účet:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Znovu vytvořte každý uživatelský účet v cloudové databázi. V MySQL můžete například pomocí tohoto příkazu vytvořit nový účet:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Autorizuje každý uživatelský účet na správnou úroveň přístupu v cloudové databázi. V MySQL můžete například pomocí tohoto příkazu povolit uživateli přístup k úplné databázi:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Šifrování

Když se data odesílají přes síť, může je zachycovat takzvaný útok "man-in-the-middle". Abyste tomu zabránili, podporuje azure Database for MySQL, Azure Database for MariaDB a Azure Database for PostgreSQL šifrování komunikace protokol SSL (Secure Sockets Layer). Protokol SSL se ve výchozím nastavení vynucuje a důrazně doporučujeme toto nastavení změnit.

Možná budete muset změnit nastavení připojení klientských aplikací, aby používaly šifrování SSL. Proberte toto téma se svými vývojáři a určete potřebné změny.

Monitorování a správa

Součástí plánování migrace databáze je zvážit, jak správci databáze budou po migraci dál provádět své úkoly.

Sledování

Správci místní databáze se používají k pravidelnému monitorování problémů, jako jsou kritické body hardwaru nebo kolize pro přístup k síti. Monitorují, aby se zajistilo, že můžou vyřešit všechny problémy, než dojde k ovlivnění produktivity. Můžete očekávat, že jakákoli databáze, která se pravidelně nemonitoruje, začne dříve nebo později způsobovat problémy.

Ke cloudovým databázím byste měli použít naprosto stejný přístup. Možná bude jednodušší vyřešit problémy v systému PaaS, jako je Azure, protože můžete přidávat prostředky bez nutnosti koupě, nastavení a konfigurace jakéhokoli hardwaru. Stále ale potřebujete odhalit problémy s vývojem, takže monitorování je mezi každodenními úkoly vysokou prioritou.

Než budete migrovat databáze do cloudu, zjistěte, jaké nástroje monitorování aktuálně používají vaši správci. Pokud jsou tyto nástroje kompatibilní s navrhovaným cloudovým řešením, možná je budete muset znovu připojit jenom k migrovaným databázím. Pokud ne, musíte prozkoumat alternativy.

Mějte na paměti, že Azure zahrnuje sadu nástrojů pro monitorování výkonu a shromažďuje širokou škálu čítačů výkonu a dat protokolů. Tato data zobrazíte pomocí řídicích panelů a grafů na webu Azure Portal konfigurací služby Azure Monitor. Můžete vytvářet vlastní grafy, tabulky a sestavy, které jsou speciálně navržené pro potřeby správců.

Správa

Správci databází používají upřednostňované nástroje ke změně schématu a obsahu místní databáze. Pokud po migraci používají stejné nástroje, můžete i nadále těžit z jejich odborných znalostí. Začněte posouzením toho, jestli je existující sada nástrojů kompatibilní s navrženou cloudovou databází hostovanou v cloudu. Mnoho nástrojů bude kompatibilních, protože jsou založené na široce přijímaných standardech, jako je SQL, ale je důležité ověřit kompatibilitu. Pokud aktuální nástroje pro správu po migraci nebudou fungovat, zkuste identifikovat alternativy s vašimi správci.

Azure obsahuje několik nástrojů, které můžete použít ke správě databází MySQL, MariaDB a PostgreSQL:

Azure Portal. Tento web má výkonné funkce, které používáte ke konfiguraci, monitorování a správě databází – a všech dalších prostředků, které můžete vytvořit v cloudu Azure.
Azure PowerShell: Toto je skriptovací spouštěcí prostředí a jazyk, který má širokou sadu příkazů. K automatizaci složitých úloh správy databází použijte PowerShell, který je k dispozici pro prostředí Windows a Linux.
Rozhraní příkazového řádku Azure. Toto je rozhraní příkazového řádku pro Azure. Slouží ke správě služeb a prostředků v Azure. Rozhraní příkazového řádku můžete použít z prostředí prostředí Windows a Linuxu a v rámci skriptů Bash.