Aktív-passzív vészhelyreállítási 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 egyrégiós alkalmazásról van szó. 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ó az AKS aktív-passzív vészhelyreállítási megoldását ismerteti. Ebben a megoldásban két független, azonos AKS-fürtöt telepítünk két párosított Azure-régióba, amelyek közül egyszerre csak az egyik szolgálja ki aktívan a forgalmat.

Megjegyzés

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

Aktív-passzív megoldás áttekintése

Ebben a katasztrófa utáni helyreállítási megközelítésben két egymástól független AKS-fürtöt telepítünk két Azure-régióba. Azonban egyszerre csak az egyik fürt szolgálja ki aktívan a forgalmat. A másodlagos fürt (amely nem aktívan szolgálja ki a forgalmat) ugyanazokat a konfigurációs és alkalmazásadatokat tartalmazza, mint az elsődleges fürt, de csak akkor fogadja el a forgalmat, ha Azure Front Door traffic manager irányítja.

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

Ez a megoldás akkor valósítható meg a legjobban, ha olyan erőforrásokra támaszkodó alkalmazásokat üzemeltet, mint például az adatbázisok, amelyek aktívan kiszolgálják a forgalmat egy régióban. Olyan esetekben, amikor mindkét régióban üzembe helyezett állapot nélküli alkalmazásokat kell üzemeltetnie, például horizontális skálázást, javasoljuk, hogy mérlegeljen egy aktív-aktív megoldást, mivel az aktív-passzív megoldás további késéssel jár.

Összetevők

Az aktív-passzív 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ó. A normál műveletek során a hálózati forgalom az Azure Front Door konfigurációjában beállított elsődleges AKS-fürthöz lesz irányítva.

Konfigurált fürtpriorizálás: Minden fürthöz 1–5 közötti rangsorolási szintet kell beállítania (1 a legmagasabb prioritás, az 5 pedig a legalacsonyabb prioritás). Több fürtöt is beállíthat ugyanarra a prioritási szintre, és megadhatja az egyes fürtök súlyát. Ha az elsődleges fürt elérhetetlenné válik, a forgalom automatikusan az Azure Front Doorban kiválasztott soron következő régióba lesz irányítva. A rendszer működéséhez minden forgalomnak át kell haladnia az Azure Front Dooron.

Azure Front Door: Azure Front Door elosztja a terhelést, és az elsődleges régióban lévő Azure Application Gateway-példányra irányítja a forgalmat (a fürtöt 1-es prioritással kell megjelölni). Régióhiba esetén a szolgáltatás átirányítja a forgalmat a prioritási listában szereplő következő fürtre.

További információ: Prioritásalapú forgalomirányítás.

Központ–küllő pár: Minden regionális AKS-példányhoz egy központ–küllő pár van telepítve. Az Azure Firewall Manager-szabályzatok az egyes régiókban kezelik a tűzfalszabályokat.

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.

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.

Átállási folyamat

Ha egy szolgáltatás vagy szolgáltatásösszetevő elérhetetlenné válik egy régióban, a forgalmat egy olyan régióba kell irányítani, ahol a szolgáltatás elérhető. A többrégiós architektúra számos különböző hibapontot tartalmaz. Ebben a szakaszban a lehetséges hibapontokat mutatjuk be.

Alkalmazáscsoportok (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 megpróbálja biztosítani, 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 eltávolítja a podot, így a ReplicaSet új példány létrehozására kényszerül.

További információ: Kubernetes ReplicaSet.

Alkalmazáscsoportok (globális)

Amikor egy teljes régió elérhetetlenné válik, a fürt podjai többé nem állnak rendelkezésre a kérések kiszolgálására. 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ó fürtre irányuló megnövekedett forgalom és kérések kezelése érdekében vegye figyelembe az alábbi iránymutatást:

  • 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 podreplikák számának növeléséhez használja a Vízszintes pod automatikus skálázót a megnövekedett regionális kereslet kompenzálásához.
  • Az AKS Cluster Autoscaler segítségével növelheti a Kubernetes-példányok csomópontjainak számát a megnövekedett regionális kereslet ellensúlyozása érdekében.

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 ebben az aktív-passzív megoldásban az egyetlen pontból álló regionális meghibásodástól, használja a Azure Availability Zones. 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ásik rendelkezésre állási zónában 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. Továbbra is ügyeljen arra, hogy számoljon a megmaradó fürtre irányuló megnövekedett forgalommal és kérésekkel.

Hibaátvételi tesztstraté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: