Migrace úloh Flexibilního serveru Azure Kubernetes Service (AKS) a MySQL do podpory zóny dostupnosti
Tato příručka popisuje, jak migrovat úlohu flexibilního serveru Azure Kubernetes Service a MySQL za účelem dokončení podpory zóny dostupnosti napříč všemi závislými službami. Úplný seznam všechzávislostch
Podpora zóny dostupnosti pro tuto úlohu musí být povolena při vytváření clusteru AKS nebo flexibilního serveru MySQL. Pokud chcete podporu zón dostupnosti pro existující cluster AKS a flexibilní server MySQL, budete muset tyto prostředky znovu nasadit.
Tyto pokyny k migraci se zaměřují hlavně na aspekty infrastruktury a dostupnosti spuštění následující architektury v Azure:
Závislosti služby úloh
Aby byla zajištěna úplná podpora úloh pro zóny dostupnosti, musí každá závislost služby v úloze podporovat zóny dostupnosti.
Existují dva typy podporovaných služeb zóny dostupnosti: zónově redundantní nebo zónově redundantní. Většina služeb podporuje jednu nebo druhou. V některých případech ale existují možnosti pro výběr zónového nebo zónově redundantního prostředku pro danou službu. V následujících doporučeních uvádíme, které služby podporují zónově redundantní prostředky. Označujeme také, které služby jsou globální a regionální.
Architektura úloh AKS a MySQL se skládá z následujících závislostí komponent:
Azure Kubernetes Service (AKS)
Zónové : Fond systémových uzlů a fondy uzlů uživatelů jsou zónové, když předem vyberete zóny, ve kterých se fondy uzlů nasadí během vytváření. Pro lepší odolnost doporučujeme předem vybrat všechny tři zóny. Do existujícího clusteru AKS je možné přidat více fondů uzlů uživatelů podporujících zóny dostupnosti a zadat hodnotu parametru
zones.Zónově redundantní: Komponenty řídicí roviny Kubernetes, jako jsou etcd, server API, scheduler a Správce kontroleru, se automaticky replikují nebo distribuují napříč zónami.
Poznámka:
Pokud chcete povolit zónovou redundanci součástí řídicí roviny clusteru AKS, musíte při vytváření clusteru AKS definovat výchozí fond systémových uzlů se zónami. Přidání dalších zónových fondů uzlů do existujícího neonálního clusteru AKS nezpůsobí zónově redundantní cluster AKS, protože tato akce nedistribuuje komponenty řídicí roviny napříč zónami po faktu.
Flexibilní server Azure Database for MySQL
Zónový režim: Režim zónové dostupnosti znamená, že pohotovostní server je vždy dostupný ve stejné zóně jako primární server. I když tato možnost zkracuje dobu převzetí služeb při selhání a latenci sítě, je méně odolná kvůli výpadku jedné zóny, která má vliv na primární i pohotovostní servery.
Zónově redundantní: Režim zónově redundantní dostupnosti znamená, že pohotovostní server je vždy dostupný v jiné zóně ve stejné oblasti jako primární server. Pro primární a pohotovostní servery budou povoleny dvě zóny pro redundanci zón. Tuto konfiguraci doporučujeme pro lepší odolnost.
Azure Standard Load Balancer nebo Aplikace Azure lication Gateway
Load Balancer úrovně Standard
Informace o aspektech souvisejících s prostředky Load Balanceru úrovně Standard najdete v tématu Load Balancer a Zóny dostupnosti.
Zónově redundantní: Volba redundance zón je doporučeným způsobem konfigurace front-endové IP adresy s existujícím Load Balancerem. Zónově redundantní front-end odpovídá back-endovém fondu clusteru AKS, který se distribuuje napříč několika zónami.
Zónové: Pokud připnete fondy uzlů na konkrétní zóny, jako je zóna 1 a 2, můžete předem vybrat zónu 1 a 2 pro front-endovou IP adresu v existujícím Load Balanceru. Důvodem, proč můžete chtít připnout fondy uzlů na konkrétní zóny, může být dostupnost řady specializovaných skladových položek virtuálních počítačů, jako je M-series.
Azure Application Gateway
Použití doplňku Kontroleru příchozího přenosu dat služby Application Gateway s clusterem AKS se podporuje jenom u skladových položek služby Application Gateway v2 (Standard a WAF). Další aspekty související se službou Aplikace Azure lication Gateway najdete v tématu Škálování služby Application Gateway v2 a WAF v2.
Zónové: Pokud chcete využít výhody zón dostupnosti, doporučujeme vytvořit prostředek služby Application Gateway ve více zónách, jako je zóna 1, 2 a 3. Vyberte všechny tři zóny pro nejlepší strategii odolnosti uvnitř oblastí. Pokud ale chcete odpovídat fondům back-endových uzlů, můžete fondy uzlů připnout na konkrétní zóny tak, že během vytváření prostředku služby App Gateway předem vyberete zónu 1 a 2. Důvodem, proč můžete chtít připnout fondy uzlů na konkrétní zóny, může být dostupnost řady specializovaných skladových položek virtuálních počítačů, jako M-seriesje například .
Zónově redundantní úložiště (ZRS)
Doporučujeme nakonfigurovat cluster AKS se spravovanými disky ZRS, protože se jedná o zónově redundantní prostředky. Svazky je možné naplánovat ve všech zónách.
Kubernetes o zónách dostupnosti Azure ví od verze 1.12. Objekt odkazující na spravovaný disk Azure můžete nasadit
PersistentVolumeClaimv clusteru AKS s více zónami. Kubernetes se postará o naplánování jakéhokoli podu, který tento PVC deklaruje ve správné zóně dostupnosti.Pro Azure Database for SQL doporučujeme hostovat data a soubory protokolů v zónově redundantním úložišti (ZRS). Tyto soubory se replikují na pohotovostní server prostřednictvím replikace na úrovni úložiště, která je k dispozici v ZRS.
Azure Firewall
Zónové: Pokud chcete využívat výhody zón dostupnosti, doporučujeme vytvořit prostředek služby Azure Firewall ve více zónách, jako je zóna 1, 2 a 3. Doporučujeme vybrat všechny tři zóny pro nejlepší strategii odolnosti uvnitř oblastí.
Azure Bastion
Oblast: Služba Azure Bastion se nasadí v rámci virtuálních sítí nebo partnerských virtuálních sítí a je přidružená k oblasti Azure. Další informace najdete v tématu Spolehlivost ve službě Azure Bastion.
Azure Container Registry (ACR)
Zónově redundantní: Doporučujeme vytvořit zónově redundantní registr na úrovni služby Premium. Můžete také vytvořit zónově redundantní repliku registru nastavením zoneRedundancy vlastnosti repliky. Informace o povolení redundance zón pro službu ACR najdete v tématu Povolení redundance zón ve službě Azure Container Registry pro zajištění odolnosti a vysoké dostupnosti.
Azure Cache for Redis
Zónově redundantní: Azure Cache for Redis podporuje zónově redundantní konfigurace na úrovních Premium a Enterprise. Zónově redundantní mezipaměť umístí své uzly do různých zón dostupnosti ve stejné oblasti.
Microsoft Entra ID
Globální: Microsoft Entra ID je globální služba s několika úrovněmi interní redundance a automatické obnovitelnosti. Microsoft Entra ID je nasazen ve více než 30 datacentrech po celém světě, které poskytují zóny dostupnosti, kde se nacházejí. Toto číslo rychle roste, protože se nasazuje více oblastí.
Azure Key Vault
Oblast: Služba Azure Key Vault je nasazená v oblasti. Aby se zachovala vysoká stálost vašich klíčů a tajných kódů, obsah trezoru klíčů se replikuje v rámci oblasti a do sekundární oblasti ve stejné geografické oblasti.
Zónově redundantní: Pro oblasti Azure s zónami dostupnosti a bez páru oblastí key Vault třikrát replikuje obsah trezoru klíčů v rámci jednoho umístění nebo oblasti zónově redundantní úložiště (ZRS).
Důležité informace o úlohách
Azure Kubernetes Service (AKS)
Pody můžou komunikovat s jinými pody bez ohledu na to, ve kterém uzlu nebo zóně dostupnosti se pody přistály na uzlu. Pokud se pody nacházejí v různých zónách dostupnosti, může vaše aplikace zaznamenat vyšší dobu odezvy. I když se očekává, že latence odezvy mezi pody spadá do přijatelného rozsahu pro většinu aplikací, existují scénáře aplikací, které vyžadují nízkou latenci, zejména pro chatty komunikace mezi pody.
Doporučujeme otestovat aplikaci, abyste měli jistotu, že funguje dobře napříč zónami dostupnosti.
Z důvodů nízké latence výkonu můžou být pody umístěné ve stejném datovém centru ve stejné zóně dostupnosti. Pokud chcete společně najít pody ve stejném datovém centru ve stejné zóně dostupnosti, můžete vytvořit fondy uzlů uživatelů s jedinečnou zóny a skupinou umístění bezkontaktní komunikace. Skupinu umístění bezkontaktní komunikace (PPG) můžete přidat do existujícího clusteru AKS vytvořením nového fondu uzlů agenta a zadáním PPG. Pomocí omezení šíření topologie podů můžete řídit rozložení podů v clusteru AKS napříč zónami dostupnosti, uzly a oblastmi.
Jakmile se pody, které vyžadují komunikaci s nízkou latencí, nacházejí ve stejné zóně dostupnosti, komunikace mezi pody není přímá. Místo toho se komunikace podů kanáluje prostřednictvím služby, která definuje logickou sadu podů v clusteru AKS. Pody je možné nakonfigurovat tak, aby komunikovaly s AKS a komunikace se službou se automaticky vyrovnávalo zatížení pro všechny pody, které jsou členy služby.
Pokud chcete využít výhod zón dostupnosti, fondy uzlů obsahují základní virtuální počítače, které jsou zónovými prostředky. Pokud chcete podporovat aplikace, které mají různé požadavky na výpočetní prostředky nebo úložiště, můžete při vytváření fondu uzlů uživatele vytvářet fondy uzlů uživatelů s konkrétními velikostmi virtuálních počítačů.
Můžete se například rozhodnout použít
Standard_M32mspod uzlyM-seriesuživatele, protože mikroslužby ve vaší aplikaci vyžadují vysokou propustnost, nízkou latenci a velikosti paměti optimalizované pro virtuální počítače, které poskytují vysoké počty vCPU a velké množství paměti. V závislosti na oblasti nasazení se při výběru velikosti virtuálního počítače na webu Azure Portal může zobrazit, že tato velikost virtuálního počítače je podporovaná jenom v zóně 1 a 2. Tuto konfiguraci odolnosti můžete přijmout jako kompromis pro vysoký výkon.Po vytvoření nemůžete změnit velikost virtuálního počítače fondu uzlů. Další informace o omezeních fondu uzlů najdete v tématu Omezení.
Flexibilní server Azure Database for MySQL
Implikací nasazení fondů uzlů v konkrétních zónách, jako je zóna 1 a 2, je, že všechny závislosti služeb vašeho clusteru AKS musí podporovat také zónu 1 a 2. V této architektuře úloh má cluster AKS závislost služby na flexibilních serverech Azure Database for MySQL s odolností zón. Jako primární server a zónu 2 byste vybrali zónu 1, aby byl pohotovostní server společně umístěný s fondy uzlů uživatelů AKS.
Azure Cache for Redis
Azure Cache for Redis distribuuje uzly v zónově redundantní mezipaměti způsobem kruhového dotazování přes vybrané zóny dostupnosti.
Existující mezipaměť Premium nemůžete aktualizovat tak, aby používala redundanci zón. Pokud chcete použít redundanci zón, musíte znovu vytvořit Azure Cache for Redis.
Pokud chcete dosáhnout optimální odolnosti, doporučujeme vytvořit službu Azure Cache for Redis se třemi nebo více replikami, abyste mohli repliky distribuovat napříč třemi zónami dostupnosti.
Aspekty zotavení po havárii
Zóny dostupnosti se používají k lepší odolnosti, aby se zajistila vysoká dostupnost vaší úlohy v primární oblasti nasazení.
Zotavení po havárii se skládá z operací zotavení a postupů definovaných v plánu provozní kontinuity. Plán provozní kontinuity řeší, jak se vaše úloha obnoví během rušivé události a jak se po události plně obnoví. Zvažte rozšíření nasazení do alternativní oblasti.
Pro vaši aplikační vrstvu si projděte aspekty provozní kontinuity a zotavení po havárii pro AKS v tomto článku.
Zvažte spuštění několika clusterů AKS v alternativních oblastech. Alternativní oblast může použít sekundární spárovanou oblast. Nebo pokud není párování oblastí pro vaši primární oblast, můžete vybrat alternativní oblast na základě vašeho zvážení dostupných služeb, kapacity, geografické blízkosti a suverenity dat. Projděte si průvodce rozhodováním o oblastech Azure. Zkontrolujte také vzor razítka nasazení.
Pro clustery AKS máte možnost konfigurovat aktivní-aktivní,aktivní-pohotovostní, aktivní-pasivní.
Funkce zotavení po havárii pro vaši databázovou vrstvu zahrnují geograficky redundantní zálohy s možností inicializovat geografické obnovení a nasazovat repliky pro čtení v jiné oblasti.
Během výpadku se budete muset rozhodnout, jestli se má zahájit obnovení. Operace obnovení budete muset zahájit pouze v případě, že výpadek bude pravděpodobně trvat déle, než je cíl doby obnovení vaší úlohy (RTO). Jinak počkáte na obnovení služby tím, že zkontrolujete stav služby na řídicím panelu služby Azure Service Health. V okně Service Health na webu Azure Portal můžete zobrazit všechna oznámení přidružená k vašemu předplatnému.
Když zahájíte obnovení pomocí funkce geografického obnovení ve službě Azure Database for MySQL, vytvoří se nový databázový server pomocí zálohovaných dat replikovaných z jiné oblasti.
Další kroky
Přečtěte si další informace: