Passzív-hideg megoldás áttekintése az Azure Kubernetes Service -hez (AKS)

Amikor létrehoz egy alkalmazást az Azure Kubernetes Service-ben (AKS), és az erőforrás létrehozásakor kiválaszt egy Azure-régiót, akkor az alkalmazás egyrégiós lesz. Ha a régió katasztrófa esetén elérhetetlenné válik, az alkalmazás is elérhetetlenné válik. Ha azonos üzembe helyezést hoz létre egy másodlagos Azure-régióban, az alkalmazás kevésbé lesz érzékeny az egyrégiós katasztrófákra, ami garantálja az üzletmenet folytonosságát, és a régiók közötti adatreplikáció lehetővé teszi az utolsó alkalmazásállapot helyreállítását.

Ez az útmutató egy passzív-hideg megoldást vázol fel az AKS-hez. Ebben a megoldásban két független és azonos AKS-fürtöt helyezünk üzembe két párosított Azure-régióban, és csak egy fürt aktívan szolgálja ki a forgalmat, amikor az alkalmazásra szükség van.

Megjegyzés

Az alábbi gyakorlatot belsőleg áttekintettük, és a Microsoft-partnereinkkel együtt ellenőriztük.

Passzív-hideg megoldás áttekintése

Ebben a megközelítésben két független AKS-fürtöt helyezünk üzembe két Azure-régióban. Amikor az alkalmazásra szükség van, aktiváljuk a passzív fürtöt a forgalom fogadásához. Ha a passzív klaszter leáll, manuálisan aktiválnunk kell a hideg klasztert, hogy átvegye a forgalmat. Ezt a feltételt minden alkalommal beállíthatjuk manuális bemenettel, vagy megadhatunk egy bizonyos eseményt.

Forgatókönyvek és konfigurációk

Ez a megoldás leginkább "szükség szerinti használat" számítási feladatként van implementálva, ami olyan forgatókönyvek esetén hasznos, amelyekhez a számítási feladatoknak adott napszakokban kell futniuk, vagy igény szerint kell futniuk. A passzív-hideg megközelítés például a következő használati eseteket foglalja magában:

  • Egy gyártó vállalat, amely egy összetett és erőforrás-igényes szimulációt kell futtatnia egy nagy adathalmazon. Ebben az esetben a passzív fürt egy felhőalapú régióban található, amely nagy teljesítményű számítási és tárolási szolgáltatásokat kínál. A passzív klasztert csak akkor használják, ha a szimulációt a felhasználó vagy ütemezés alapján indítja el a rendszer. Ha a fürt nem működik az aktiváláskor, a hideg fürt biztonsági mentésként használható, és a számítási feladat futtatható rajta.
  • A kormányzati ügynökségnek biztonsági másolatot kell készítenie kritikus rendszereiről és adatairól kibertámadás vagy természeti katasztrófa esetén. Ebben az esetben a passzív fürt egy biztonságos és elkülönített, a nyilvánosság számára nem hozzáférhető helyen található.

Összetevők

A passzív hideg vészhelyreállítási megoldás számos Azure-szolgáltatást használ. Ez a példaarchitektúra a következő összetevőket foglalja magában:

Több fürt és régió: Több AKS-fürtöt helyez üzembe, amelyek mindegyike külön Azure-régióban található. Amikor szükség van az alkalmazásra, a rendszer aktiválja a passzív fürtöt a hálózati forgalom fogadásához.

Key Vault: Minden régióban kiépítenie kell egy Azure Key Vaultot a titkos kulcsok és kulcsok tárolásához.

Log Analytics: A regionális Log Analytics-példányok regionális hálózati metrikákat és diagnosztikai naplókat tárolnak. A megosztott példányok az összes AKS-példány metrikáit és diagnosztikai naplóit tárolják.

Hub–spoke pár: Minden regionális AKS-példányhoz egy hub–spoke pár van telepítve. Az Azure Firewall Manager-szabályzatok az egyes régiókban kezelik a tűzfalszabályokat.

Tárolóregisztrációs adatbázis: A számítási feladat tárolólemezképei egy felügyelt tárolóregisztrációs adatbázisban vannak tárolva. Ezzel a megoldással egyetlen Azure Container Registry-példányt használunk a fürt összes Kubernetes-példányához. Az Azure Container Registry georeplikálásával a rendszerképeket a kiválasztott Azure-régiókba replikálhatja, és folyamatos hozzáférést biztosít a képekhez még akkor is, ha egy régió leállást tapasztal.

Feladatátvételi folyamat

Ha a passzív fürt a hozzá tartozó Azure-régióban fellépő probléma miatt nem működik megfelelően, aktiválhatja a hideg fürtöt, és az összes forgalmat átirányíthatja a hideg fürt régiójába. Ezt a folyamatot akkor használhatja, ha a passzív fürt inaktiválva van, amíg újra nem kezd működni. A hideg klaszter online állapotba kerülése eltarthat néhány percig, mivel ki lett kapcsolva, és végig kell futnia a beállítási folyamaton. Ez a megközelítés nem ideális időérzékeny alkalmazásokhoz. Ebben az esetben érdemes fontolóra venni az aktív-aktív feladatátvételt.

Alkalmazási podok (regionális)

A Kubernetes üzembehelyezési objektuma egy pod (ReplicaSet) több replikáját hozza létre. Ha az egyik nem érhető el, a forgalom a többi replika között lesz irányítva. A Kubernetes ReplicaSet gondoskodik arról, hogy a megadott számú replika folyamatosan fusson és működőképes legyen. Ha egy példány leáll, újra létre kell hozni egy új példányt. Az élőség-mintavételek ellenőrizhetik a podon futó alkalmazás vagy folyamat állapotát. Ha a pod nem válaszol, az életképességi próba megszünteti a podot, ami arra kényszeríti a ReplicaSet-et, hogy hozzon létre egy új példányt.

További információ: Kubernetes ReplicaSet.

Alkalmazásmodulok (globális)

Amikor egy teljes régió elérhetetlenné válik, a fürt podjai többé nem tudják kiszolgálni a kéréseket. Ebben az esetben az Azure Front Door-példány az összes forgalmat a fennmaradó egészséges régiókba irányítja. Ezekben a régiókban a Kubernetes-fürtök és podok továbbra is kiszolgálják a kéréseket. A fennmaradó klaszterre irányuló megnövekedett forgalom és kérelmek kezelésére vegye figyelembe az alábbi iránymutatásokat:

  • Győződjön meg arról, hogy a hálózati és számítási erőforrások megfelelő méretűek ahhoz, hogy elnyeljék a régió feladatátvétele miatti hirtelen forgalomnövekedést. Az Azure Container Network Interface (CNI) használatakor például győződjön meg arról, hogy rendelkezik olyan alhálózattal, amely támogatja a kiugró forgalommal rendelkező pod IP-címeket.
  • A megnövekedett regionális igény ellensúlyozására használja a Vízszintes podautomatikus skálázót a podreplikák számának növeléséhez.
  • Az AKS Cluster Autoscaler használatával növelheti a Kubernetes-példány csomópontjainak számát a megnövekedett regionális igény ellensúlyozására.

Kubernetes-csomópontkészletek (regionális)

Időnként előfordulhat, hogy honosított hiba történik a számítási erőforrásoknál, például az energia elérhetetlenné válik egyetlen Azure-kiszolgálói állványon. Ha meg szeretné védeni az AKS-csomópontokat attól, hogy egy pont regionális hiba legyen, használja az Azure Rendelkezésre állási zónákat. A rendelkezésre állási zónák biztosítják, hogy az egyes rendelkezésre állási zónák AKS-csomópontjai fizikailag elkülönüljenek a más rendelkezésre állási zónákban meghatározottaktól.

Kubernetes-csomópontkészletek (globális)

Teljes regionális hiba esetén az Azure Front Door a fennmaradó kifogástalan állapotú régiókba irányítja a forgalmat. Ismét ügyeljen arra, hogy ellensúlyozza a fennmaradó fürtre jutó megnövekedett forgalmat és kérésszámot.

Feladatátvételi tesztelési stratégia

Bár az AKS-ben jelenleg nem létezik olyan mechanizmus, amely tesztelési célokra leépítheti az üzembe helyezés teljes régióját, a Azure Chaos Studio-munkaterületek használatával szimulálhatja a fürt csomópontkészleteinek rendelkezésre állási zónájának leállását.

Következő lépések

Ha más megoldást fontolgat, tekintse meg az alábbi cikkeket:

  • Utolsó frissítés időpontja: