Az alkalmazás rendelkezésre állása az Azure Arc által engedélyezett AKS-ben

A következőkre vonatkozik: AKS az Azure Stack HCI 22H2-n, AKS Windows Serveren

az Azure Arc által engedélyezett Azure Kubernetes Service (AKS) egy teljes mértékben támogatott tárolóplatformot kínál, amely natív felhőbeli alkalmazásokat futtathat a Kubernetes tárolóvezénylési platformon. Az architektúra támogatja a virtualizált Windows- és Linux-számítási feladatok futtatását.

Az AKS-architektúra feladatátvételi fürtszolgáltatással és élő migrálással készült, amely automatikusan engedélyezve van a célfürtök (számítási feladatok) számára. A különböző fennakadási események során az ügyfél számítási feladatait üzemeltető virtuális gépek szabadon mozognak az alkalmazások leállása nélkül. Ez az architektúra azt jelenti, hogy egy hagyományos vállalati ügyfél, aki az Azure Stack HCI-n vagy a Windows Serveren futó AKS-hez egyetlen megoldásként kezel egy örökölt alkalmazást, hasonló (vagy jobb) üzemidőt kap, mint ami egy örökölt virtuálisgép-alkalmazásban jelenleg tapasztalható.

Ez a cikk néhány alapvető fogalmat ismertet azon felhasználók számára, akik tárolóalapú alkalmazásokat szeretnének futtatni az AKS Arcon az élő migrálás engedélyezésével annak érdekében, hogy az alkalmazások elérhetők legyenek a fennakadások során. A Kubernetes-terminológiát, például az önkéntes fennakadásokat és az akaratlan fennakadásokat, a podon futó alkalmazások állásidejeként használják.

Mi az az élő migrálás?

Az élő áttelepítés egy Hyper-V szolgáltatás, amely lehetővé teszi a futó virtuális gépek transzparens áthelyezését egy Hyper-V-gazdagépről egy másikra anélkül, hogy a rendszer állásidőt észlel. Az élő áttelepítés elsődleges előnye a rugalmasság; a futó virtuális gépek nincsenek egyetlen gazdagéphez kötve. Ez lehetővé teszi, hogy a felhasználók olyan műveleteket hajtsanak végre, mint például egy adott gazdagép kiürítése a gazdagép leszerelése vagy frissítése előtt. A Windows feladatátvételi fürtszolgáltatással párosítva az élő áttelepítés magas rendelkezésre állású és hibatűrő rendszerek létrehozását teszi lehetővé.

Az Azure Stack HCI-n és a Windows Serveren futó AKS jelenlegi architektúrája feltételezi, hogy engedélyezte az élő migrálást az Azure Stack HCI-fürtözött környezetben. Ezért minden Kubernetes-munkavégző csomópont virtuális gépe élő migrálással van konfigurálva. Ezek a csomópontok a fizikai gazdagépek köré helyezhetők át fennakadások esetén, hogy a platform magas rendelkezésre állású legyen.

Ha egy örökölt alkalmazást egyetlenton futtat a Kubernetesen, ez az architektúra megfelel a magas rendelkezésre állási igényeknek. A Kubernetes kezeli a podok ütemezését az elérhető munkavégző csomópontokon, míg az élő áttelepítés kezeli a munkavégző csomópont virtuális gépeinek ütemezését az elérhető fizikai gazdagépeken.

Alkalmazáskimaradási forgatókönyvek

Az Azure Stack HCI-n és a Windows Serveren futó AKS virtuális gépeken futó alkalmazások helyreállítási idejének összehasonlító tanulmánya egyértelműen azt mutatja, hogy minimális hatással van az alkalmazásra a gyakori fennakadási események bekövetkezésekor. Három példa fennakadási forgatókönyvre:

• Olyan frissítés alkalmazása, amely a fizikai gép újraindítását eredményezi.
• Olyan frissítés alkalmazása, amely magában foglalja a munkavégző csomópont újraindítását.
• Fizikai gép nem tervezett hardverhibája.

Megjegyzés

Ezek a forgatókönyvek feltételezik, hogy az alkalmazás tulajdonosa továbbra is Kubernetes-affinitást és affinitás-ellenes beállításokat használ a podok megfelelő ütemezésének biztosításához a munkavégző csomópontok között.

Megszakítási esemény	Alkalmazások futtatása virtuális gépeken az Azure Stack HCI-n	Alkalmazások futtatása virtuális gépeken az AKS-en az Azure Stack HCI-n vagy a Windows Serveren
A fizikai gép újraindítását eredményező frissítés alkalmazása	Nincs hatás	Nincs hatás
Olyan frissítés alkalmazása, amely magában foglalja a munkavégző csomópont újraindulását (vagy a virtuális gép újraindítását)	Nincs hatás	Változó
Fizikai gép nem tervezett hardverhibája	6-8 perc	6-8 perc

A fizikai gép újraindítását eredményező frissítés alkalmazása

Fizikai gazdagép-karbantartási esemény, például egy gazdagép újraindítását eredményező frissítés alkalmazása során a fürtben futó alkalmazásokra nem várható hatás. A fürt rendszergazdája kiüríti a gazdagépet, és biztosítja, hogy a frissítés alkalmazása előtt az összes virtuális gép élő migrálva legyen.

Olyan frissítés alkalmazása, amely magában foglalja a munkavégző csomópont újraindítását

Ez a forgatókönyv egy munkavégző csomópont virtuális gépének leállítását jelenti a rutinszerű karbantartás elvégzéséhez. A frissítésre való felkészüléshez a fürt rendszergazdája kiüríti és elkülöníti a csomópontot, hogy a frissítések alkalmazása előtt az összes pod ki legyen ürítve egy elérhető munkavégző csomópontra. A frissítés befejezése után a munkavégző csomópont újracsatlakozik, és elérhetővé válik az ütemezéshez.

Megjegyzés

Az alkalmazások elérhetősége változó, mivel magában foglalja az alaptároló lemezképének letöltéséhez szükséges időt, különösen a nyilvános felhőben tárolt nagyobb rendszerképek esetében. Ezért javasoljuk, hogy kis alapszintű tárolórendszerképeket használjon, windowsos tárolók esetében pedig ajánlott az nano server alaprendszerképet használni.

Fizikai gép nem tervezett hardverhibája

Ebben a forgatókönyvben akaratlan fennakadás történik egy olyan fizikai gépen, amely egy örökölt alkalmazástárolót/podot üzemeltet az egyik munkavégző csomópont virtuális gépén. A feladatátvételi fürtszolgáltatás elkülönített állapotba helyezi a gazdagépet, majd 6–8 perc elteltével elindítja a virtuális gépek élő migrálásának folyamatát a túlélő gazdagépekre. Ebben az esetben az alkalmazás állásideje megegyezik a gazdagép- és munkavégző csomópont virtuális gépeinek újraindításához szükséges idővel.

Összegzés

Az AKS-feladatátvételi fürtözési technológiák célja annak biztosítása, hogy az Azure Stack HCI-ben és a Windows Serveren egyaránt magas rendelkezésre állású és hibatűrő számítási környezetek legyenek elérhetők. Az alkalmazás tulajdonosának azonban továbbra is konfigurálnia kell az üzemelő példányokat a Kubernetes olyan funkcióinak használatára, mint Deploymentsa , Affinity Mapping, RelicaSets, annak érdekében, hogy a podok rugalmasak legyenek a fennakadási forgatókönyvekben.

Következő lépések

AKS a Windows Serveren és az Azure Stack HCI-n – áttekintés