Alkalmazás rendelkezésre állása az AKS-Azure Stack HCI

Az AKS on Azure Stack HCI egy teljes körűen támogatott tárolóplatform, amelyen natív felhőalkalmazások futtathatók a Kubernetes tárolóvezénylési platformján alapuló Kubernetesen. Az architektúra támogatja a virtualizált Windows és Linux számítási feladatok futtatását a Azure Stack HCI és Windows Server 2019 Datacenteren.

Az AKS aktuális architektúrája Azure Stack HCI feladatátvételi fürtszolgáltatással és a célfürtök (számítási feladatok) számára automatikusan engedélyezett élő áttelepítéssel készült. A különféle megszakítási események során az ügyfél számítási feladatait kiszolgáló virtuális gépek szabadon áthelyeződnek anélkül, hogy az alkalmazásnak megszakadt volna az állásideje. Ez azt jelenti, hogy egy hagyományos nagyvállalati ügyfél, aki egy örökölt alkalmazást egyszeres alkalmazásként az AKS-be vált a Azure Stack HCI-ban, hasonló (vagy jobb) üzemidőt fog tapasztalni, mint ami egy örökölt alkalmazás virtuális gépeken való futtatásakor jelenleg tapasztalható.

Ez a témakör néhány alapvető fogalmat ismertet az olyan felhasználók számára, akik engedélyezett élő áttelepítéssel szeretnék futtatni a tárolóba telepített alkalmazásokat az AKS-Azure Stack HCI, így biztosítva, hogy az alkalmazások rendelkezésre állnak a megszakítások során. A Kubernetes-terminológiát, például az önkéntes megszakítást és a akaratlan üzemkimaradást a podban futó alkalmazások állásidejérül 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 az egyik Hyper-V-gazdagépről a másikra állásidő nélkül. 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 az olyan műveleteket, mint a virtuális gépek adott gazdagépének kiürítését a gazdagép leszerelése vagy frissítése előtt. A feladatátvételi fürtszolgáltatással Windows élő áttelepítés lehetővé teszi magas rendelkezésre állású és hibatűrő rendszerek létrehozását.

Az AKS jelenlegi architektúrája a Azure Stack HCI feltételezi, hogy az ügyfeleken engedélyezve van az élő áttelepítés Azure Stack HCI fürtözött környezetben. Ebben az esetben az összes Kubernetes feldolgozó csomópont virtuális gépe élő migrálással lesz létrehozva. Ezek a csomópontok a fizikai gazdagépek között kimaradás esetén áthelyezhetőek a platform magas rendelkezésre állása érdekében.

A feladatátvételi fürtszolgáltatást Azure Stack HCI AKS-t bemutató ábra

Az olyan ügyfelek számára, akik a Kubernetesen egyedülálló alkalmazásként futtatják az örökölt alkalmazásokat, ez az architektúra megfelel a magas rendelkezésre állási igényeiknek. A Kubernetes kezeli a podok ütemezését az elérhető munkavégző csomópontokon, az élő áttelepítés pedig a rendelkezésre álló fizikai gazdagépek munkavégző csomópont virtuális gépei ütemezését.

Egyedülállóként futó örökölt alkalmazást bemutató példadiagram

Alkalmazáskimaradási forgatókönyvek

Az AKS-en futó virtuális gépeken futó alkalmazások helyreállítási időit összehasonlító Azure Stack HCI egyértelműen kimutatja, hogy a gyakori megszakítási események előfordulásakor minimális hatással van az alkalmazásra. Három példa a megszakítási forgatókönyvekre:

  • Olyan frissítés alkalmazása, amely a fizikai gép újraindítását jelenti.
  • Olyan frissítés alkalmazása, amely magában foglalja a feldolgozó csomópont újralétrehozását.
  • Egy fizikai gép nem tervezett hardverhibája.

Megjegyzés

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

Megszakítási esemény Alkalmazások futtatása virtuális gépeken Azure Stack HCI Alkalmazások futtatása virtuális gépeken az AKS-Azure Stack HCI
Olyan frissítés alkalmazása, amely a fizikai gép újraindítását jelenti Nincs hatás Nincs hatás
Olyan frissítés alkalmazása, amely magában foglalja a feldolgozó csomópont újralétrehozása (vagy a virtuális gép újraindítása) Nincs hatás Változó
Fizikai gép nem tervezett hardverhibája 6–8 perc 6–8 perc

Olyan frissítés alkalmazása, amely a fizikai gép újraindítását jelenti

A fizikai gazdagépek karbantartási eseménye, például egy gazdagép újraindítását igénylő frissítés alkalmazása nem jár hatással a fürtben futó alkalmazásokra. A fürt rendszergazdája kiüríti a gazdagépet, és a frissítés alkalmazása előtt minden virtuális gép élő áttelepítését biztosítja.

Olyan frissítés alkalmazása, amely magában foglalja a feldolgozó csomópont újralétrehozását

Ebben a forgatókönyvben le kell mondania egy munkavégző csomópont virtuális gépét a rutinszerű karbantartás végrehajtásához. A frissítés előkészítéséhez a fürt rendszergazdája kiüríti és elkülöníti a csomópontot, így a frissítések alkalmazása előtt a rendszer minden podot kiürít egy rendelkezésre álló 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 rendelkezésre állása eltérő lehet, mivel ez magában foglalja az alap tároló rendszerké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én. Ezért ajánlott kis méretű alaptároló-rendszerképeket használni, Windows tárolókhoz az alapként szolgáló nano server rendszerkép használata javasolt.

Fizikai gép nem tervezett hardverhibája

Ebben a forgatókönyvben egy akaratlan megszakítási esemény történik egy olyan fizikai gépen, amely egy örökölt alkalmazástárolót/podot tartalmaz a munkavégző csomópont egyik virtuális gépén. A feladatátvételi fürtszolgáltatás izolált állapotba fogja a gazdagépet, majd 6–8 perc múlva elindítja a virtuális gépek élő áttelepítését a megmaradt gazdagépekbe. Ebben az esetben az alkalmazás állásideje a gazdagép és a munkavégző csomópont virtuális gépének újraindításához szükséges időnek felel meg.

Összegzés

Az AKS a Azure Stack HCI és feladatátvételi fürtözési technológiával egyaránt úgy lett kialakítva, hogy biztosítsa a számítási környezetek magas rendelkezésre állát és hibatűrő megoldását. Az alkalmazás tulajdonosának azonban továbbra is konfigurálnia kell az üzemelő példányokat a Kubernetes funkcióinak (például , , ) használatára, hogy biztosítsa a podok rugalmasságát a megszakítási DeploymentsAffinity MappingRelicaSets forgatókönyvekben.