Dostupnost aplikace v AKS na Azure Stack HCL

AKS na Azure Stack HCI je plně podporovaná platforma kontejneru, kde můžete spouštět cloudové nativní aplikace v Kubernetes, které jsou založené na platformě pro orchestraci kontejnerů Kubernetes. architektura podporuje spouštění virtualizovaných Windows a úloh pro Linux nad Azure Stackmi rozhraními HCI a Windows Server 2019 Datacenter.

Aktuální architektura AKS na Azure Stack HCI je sestavená s podporou clusteringu s podporou převzetí služeb při selhání a migrace za provozu automaticky povolená pro cílové clustery (úlohy). Při různých událostech přerušení se virtuální počítače, které hostují úlohy zákazníků, volně pohybují bez pozorovaného výpadku aplikace. To znamená, že tradiční zákazník, který je po stažení a posunutí starší verze aplikace jako typ singleton na AKS na Azure Stack HCI, získá podobnou (nebo lepší) dobu provozu, než je v současné době spuštěná starší verze aplikace na virtuálních počítačích.

Toto téma popisuje některé základní koncepty pro uživatele, kteří chtějí spouštět aplikace s podporou kontejneru na AKS v Azure Stack HCL s povolenou migrací za provozu, aby bylo zajištěno, že aplikace budou během přerušení k dispozici. Terminologie Kubernetes, jako je například dobrovolné přerušení a nedobrovolné přerušení, se používá k odkazování na prostoje aplikace spuštěné v pod.

Co je migrace za provozu?

Migrace za provozu je funkce technologie Hyper-v, která umožňuje transparentně přesunout běžící virtuální počítače z jednoho hostitele Hyper-V do jiného bez pozorovaného výpadku. Hlavní výhodou migrace za provozu je flexibilita; běžící virtuální počítače nejsou vázané na jeden hostitelský počítač. To umožňuje akcím, jako je vyprazdňování určitého hostitele virtuálních počítačů, před vyřazením z provozu nebo upgradem hostitele. po párování s Windows clustering s podporou převzetí služeb při selhání umožňuje migrace za provozu vytvořit vysoce dostupné systémy a systémy odolné proti chybám.

Aktuální architektura AKS na Azure Stack HCI předpokládá, že zákazníci mají povolenou migraci za provozu ve svém Azure Stackm clusterovém prostředí HCI. V takovém případě se všechny virtuální počítače pracovních uzlů Kubernetes vytvoří s nakonfigurovanou migrací za provozu. Tyto uzly se můžou v případě výpadku přesunout mezi fyzické hostitele, aby byla platforma vysoce dostupná.

Diagram znázorňující AKS Azure Stack HCL s povoleným clusteringem s podporou převzetí služeb při selhání

Pro zákazníky, kteří používají starší verzi aplikace jako typ singleton nad Kubernetes, tato architektura bude vyhovovat vašim požadavkům na vysokou dostupnost. Kubernetes bude spravovat plánování lusků na dostupných pracovních uzlech, zatímco migrace za provozu bude spravovat plánování virtuálních počítačů pracovních uzlů na dostupných fyzických hostitelích.

Diagram znázorňující příklad starší verze aplikace, která běží jako typ singleton

Scénáře přerušení aplikace

Srovnávací studie časů obnovení pro aplikace běžící na virtuálních počítačích v AKS v Azure Stack HCI jasně ukazuje, že při výskytu běžných událostí přerušení dochází k minimálnímu dopadu na aplikaci. Tři příklady scénářů přerušení zahrnují:

  • Použití aktualizace, která vede k restartování fyzického počítače.
  • Použití aktualizace, která zahrnuje opětovné vytvoření pracovního uzlu.
  • Neplánované selhání hardwaru fyzického počítače.

Poznámka

V těchto scénářích se předpokládá, že vlastník aplikace stále používá spřažení Kubernetes a nastavení proti spřažení k zajištění správného plánování lusků napříč pracovními uzly.

Událost přerušení Spouštění aplikací na virtuálních počítačích v Azure Stack HCI Spouštění aplikací na virtuálních počítačích v AKS na Azure Stack HCI
Použití aktualizace, která má za následek restartování fyzického počítače Žádný dopad Žádný dopad
Použití aktualizace, která zahrnuje opětovné vytvoření pracovního uzlu (nebo restartování virtuálního počítače) Žádný dopad Různé
Neplánované selhání hardwaru fyzického počítače 6-8 minut 6 – 8 minut

Použití aktualizace, která má za následek restartování fyzického počítače

Během události údržby fyzického hostitele, jako je například použití aktualizace, která má za následek restartování hostitelského počítače, se u aplikací spuštěných v clusteru neočekává žádný dopad. Správce clusteru vyprázdní hostitele a zajistí, aby všechny virtuální počítače byly migrovány před instalací aktualizace.

Použití aktualizace, která zahrnuje opětovné vytvoření pracovního uzlu

Tento scénář zahrnuje zavedení virtuálního počítače pracovního uzlu, který provádí rutinní údržbu. Správce clusteru může při přípravě na aktualizaci tento uzel vyprázdnit a izolovat, takže všechny lusky budou před použitím aktualizací vyřazeny z dostupného pracovního uzlu. Po dokončení aktualizace se pracovní uzel znovu připojí a zpřístupní pro plánování.

Poznámka

Dostupnost aplikace se bude lišit, protože by obsahovala dobu potřebnou ke stažení základní image kontejneru, zejména pro větší obrázky uložené ve veřejném cloudu. proto doporučujeme použít malé základní image kontejneru a pro Windows kontejnery, které používají nano server základní image.

Neplánované selhání hardwaru fyzického počítače

V tomto scénáři dojde k nedobrovolným událostem přerušení fyzického počítače, který hostuje kontejner starší aplikace nebo v jednom z virtuálních počítačů pracovních uzlů. Clustering s podporou převzetí služeb při selhání umístí hostitele v izolovaném stavu a po uplynutí období od 6 do 8 minut zahájit proces migrace těchto virtuálních počítačů do chodu hostitelů. V tomto případě je doba výpadku aplikace ekvivalentem času potřebného k restartování hostitele a virtuálních počítačů pracovních uzlů.

Závěr

AKS na Azure Stack technologie HCI a clusteringu s podporou převzetí služeb při selhání jsou navržené tak, aby se zajistila vysoká dostupnost výpočetních prostředí a odolnost proti chybám. Vlastník aplikace však stále musí nakonfigurovat nasazení, aby používal funkce Kubernetes, jako je například,, Deployments a Affinity MappingRelicaSets zajistit tak, že lusky jsou odolné ve scénářích přerušení.