N szintű alkalmazás futtatása több Azure Stack Hub-régióban a magas rendelkezésre állás érdekében

Ez a referenciaarchitektúra bevált eljárásokat mutat be az N szintű alkalmazások több Azure Stack Hub-régióban való futtatásához a rendelkezésre állás és a robusztus vészhelyreállítási infrastruktúra elérése érdekében. Ebben a dokumentumban a Traffic Managert használják a magas rendelkezésre állás eléréséhez, azonban ha a Traffic Manager nem előnyben részesített választás a környezetben, akkor egy magas rendelkezésre állású terheléselosztó is helyettesíthető.

Megjegyzés

Vegye figyelembe, hogy az alábbi architektúrában használt Traffic Managert az Azure-ban kell konfigurálni, és a Traffic Manager-profil konfigurálásához használt végpontoknak nyilvánosan elérhető IP-címeknek kell lenniük.

Architektúra

Ez az architektúra az N szintű alkalmazás SQL Server láthatóra épül.

• Elsődleges és másodlagos régiók. Használjon két régiót a magas rendelkezésre állás eléréséhez. Az egyik ebben az esetben az elsődleges régió. A másik a feladatátvétel során használt régió.

• Azure Traffic Manager. A Traffic Manager az egyik régió felé irányítja a beérkező kérelmeket. A normál működés során a rendszer az elsődleges régió felé irányítja a kérelmeket. Ha az adott régió nem érhető el, a Traffic Manager átadj a feladatokat a másodlagos régiónak. További információt a következő szakaszban talál: A Traffic Manager konfigurációja.

• Erőforráscsoportok. Hozzon létre külön erőforráscsoportokat az elsődleges régióhoz, a másodlagos régióhoz. Ennek köszönhetően rugalmasan, egyetlen erőforráskészletként kezelheti az egyes régiókat, például ismételten üzembe helyezhet egy régiót a másik eltávolítása nélkül. Kapcsolja össze az erőforráscsoportokat, hogy egy lekérdezés futtatásával listázhassa az alkalmazás összes erőforrását.

• Virtuális hálózatok. Hozzon létre egy külön virtuális hálózatot minden régióhoz. Ügyeljen arra, hogy a címterek ne legyenek átfedésben.

• SQL Server Always On rendelkezésre állási csoport. Az SQL Server használata esetén az SQL Server Always On rendelkezésre állási csoportok használata javasolt a magas rendelkezésre állás érdekében. Hozzon létre egyetlen rendelkezésre állási csoportot, amely mindkét régióban tartalmazza az SQL Server-példányokat.

• Virtuális hálózat és virtuális hálózat közötti VPN-kapcsolat. Mivel a virtuális hálózatok közötti társviszony-létesítés még nem érhető el az Azure Stack Hubon, használja a VNET-et a virtuális hálózatok közötti VPN-kapcsolathoz a két virtuális hálózat csatlakoztatásához. További információt a VNET-ről virtuális hálózatra az Azure Stack Hubban talál.

Javaslatok

A többrégiós architektúrák magasabb rendelkezésre állást biztosíthatnak, mint az egyetlen régióban történő üzembe helyezés. Ha egy régió üzemkimaradása hatással van az elsődleges régióra, a Traffic Manager szolgáltatással feladatátvételt hajthat végre a másodlagos régióba. Ez az architektúra az alkalmazás egy adott alrendszerének meghibásodása esetén is segíthet.

A régiók közötti magas rendelkezésre állás elérésének több általános megközelítése van:

• Aktív/passzív, készenléti állapotban. A forgalom az egyik régióra irányul, míg a másik készenléti kiszolgálón várakozik. Készenléti kiszolgáló esetében a másodlagos régió virtuális gépei folyamatosan le vannak foglalva és futnak.

• Aktív/passzív hideg készenléti állapotban. A forgalom az egyik régióra irányul, míg a másik hidegtartalékként áll készenlétben. Hidegtartalék esetében a másodlagos régió virtuális gépei nincsenek lefoglalva, amíg nem szükségessé nem válnak feladatátvétel céljából. Ezen megközelítés futtatása kevesebb költséggel jár, de a meghibásodáskor általában hosszabb időt vesz igénybe az üzembe állás.

• Aktív/aktív. Mindkét régió aktív, és a kérelmek terheléselosztással oszlanak meg közöttük. Ha egy régió elérhetetlenné válik, kikerül a rotációból.

Ez a referenciaarchitektúra a készenléti kiszolgálóval konfigurált aktív/passzív üzemmódra összpontosít, a Traffic Managert használva a feladatátvételhez. Kis számú virtuális gépet üzembe helyezhet a készenléti állapotban, majd igény szerint felskálázhatja a skálázást.

A Traffic Manager konfigurációja

A Traffic Manager konfigurálásakor vegye figyelembe a következő szempontokat:

• Útválasztás. A Traffic Manager többféle útválasztási algoritmust támogat. A cikkben leírt forgatókönyvhöz a prioritásos útválasztást (régebbi nevén feladatátvétel esetén használt útválasztás) használja. Ezzel a beállítással a Traffic Manager az összes kérelmet az elsődleges régió felé irányítja, kivétel akkor, ha az nem elérhető. Ebben az esetben automatikusan átadja a feladatokat a másodlagos régiónak. Lásd: A feladatátvétel esetén használt útválasztás konfigurálása.

• Állapotadat-mintavétel. A Traffic Manager HTTP- (vagy HTTPS-) mintavételt használ az egyes régiók rendelkezésre állásának monitorozására. A mintavétel 200-as HTTP-választ vár egy megadott URL-címhez. Ajánlott eljárásként hozzon létre egy olyan végpontot, amely az alkalmazás általános állapotáról ad jelentést, és ezt a végpontot használja az állapotmintához. Ellenkező esetben előfordulhat, hogy a mintavétel megfelelően működő végpontot jelent, miközben az alkalmazás kritikus fontosságú részei valójában hibásak. További információ: Állapotvégpont monitorozási mintája.

Amikor a Traffic Manager átadja a feladatokat, az alkalmazás egy ideig nem lesz elérhető a felhasználók számára. Ez az időtartam a következő tényezőktől függ:

• Az állapotmintának észlelnie kell, ha az elsődleges régió elérhetetlenné válik.

• A DNS-kiszolgálóknak frissíteniük kell az IP-címhez tartozó gyorsítótárazott DNS-rekordokat. Ez a DNS élettartamától (TTL) függ. Az alapértelmezett TTL 300 másodperc (5 perc), de ezt az értéket a Traffic Manager-profil létrehozásakor konfigurálhatja.

Részletek: A Traffic Manager monitorozásának ismertetése.

Ha a Traffic Manager feladatátvételt hajt végre, automatikus feladat-visszavétel megvalósítása helyett a manuális feladat-visszavételt ajánlunk. Ellenkező esetben előfordulhat, hogy egyes esetekben az alkalmazás oda-vissza váltogat a régiók között. A feladat-visszavétel előtt ellenőrizze, hogy az alkalmazás minden alrendszere működik-e.

Vegye figyelembe, hogy a Traffic Manager alapértelmezés szerint automatikusan végrehajtja a feladat-visszavételt. Ennek megelőzéséhez manuálisan csökkentse az elsődleges régió prioritását a feladatátvétel után. Tegyük fel például, hogy az elsődleges régió 1-es prioritású, a második pedig 2-es. A feladatátvétel után az automatikus visszavétel megelőzéséhez állítsa az elsődleges régió prioritását 3-asra. Ha készen áll a váltásra, frissítse a prioritást 1-re.

A következő Azure CLI-parancsot frissíti a prioritást:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --priority 3

Másik megoldásként ideiglenesen letilthatja a végpontot, amíg készen nem áll a feladat-visszavételre:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --endpoint-status Disabled

A feladatátvétel okától függően előfordulhat, hogy újra üzembe kell helyeznie az erőforrásokat a régión belül. A feladat-visszavétel előtt tesztelje a működési készenlétet. A teszt többek között a következőket ellenőrzi:

• A virtuális gépek megfelelően vannak-e konfigurálva. (Az összes szükséges szoftver telepítve van, az IIS fut stb.)

• Az alkalmazás alrendszerei működőképesek-e.

• Funkciótesztelés. (Pl. az adatbázisszint elérhető a webes szintről.)

Az SQL Server Always On rendelkezésre állási csoportok konfigurálása

A Windows Server 2016-nál régebbi kiadásokban az SQL Server Always On rendelkezésre állási csoportok tartományvezérlőt igényelnek, és a rendelkezésre állási csoport összes csomópontjának azonos Active Directory (AD) tartományban kell lennie.

Az rendelkezésre állási csoport konfigurálása:

• Legalább két tartományvezérlőt helyezzen mindegyik régióba.

• Minden tartományvezérlőhöz rendeljen egy statikus IP-címet.

• Hozzon létre VPN-t két virtuális hálózat közötti kommunikáció engedélyezéséhez.

• Minden virtuális hálózathoz adja hozzá a tartományvezérlők IP-címét (mindkét régióból) a DNS-kiszolgálólistához. Ezt az alábbi CLI-paranccsal teheti meg. További információ: DNS-kiszolgálók módosítása.

  az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
  

• Hozzon létre egy Windows Server feladatátvételi fürtszolgáltatást (WSFC) fürtöt, amely mindkét régióban tartalmazza SQL Server-példányokat.

• Hozzon létre egy SQL Server Always On rendelkezésre állási csoportot, amely tartalmazza az elsődleges és a másodlagos régió SQL Server-példányait. Ennek lépéseit az Always On rendelkezésre állási csoport kiterjesztése távoli Azure adatközpontra (PowerShell) című cikkben találja.

  • Az elsődleges régiót helyezze az elsődleges régióba.

  • Helyezzen egy vagy több másodlagos replikát az elsődleges régióba. Konfigurálja azokat a szinkron véglegesítés használatára, automatikus feladatátvétellel.

  • Helyezzen egy vagy több másodlagos replikát a másodlagos régióba. Ezeket a teljesítmény érdekében aszinkron véglegesítés használatára konfigurálja. (Ellenkező esetben az összes T-SQL-tranzakciónak várnia kell, míg az adatok körbeérnek a hálózaton a másodlagos régióig.)

Megjegyzés

Az aszinkron véglegesítési replikák nem támogatják az automatikus feladatátvételt.

Rendelkezésre állási szempontok

Komplex N szintű alkalmazás esetén előfordulhat, hogy nem kell replikálnia a teljes alkalmazást a másodlagos régióba. Ehelyett elég lehet replikálni egy kritikus fontosságú alrendszert, amely az üzletmenet folytonosságának fenntartásához szükséges.

A Traffic Manager a rendszer egyik lehetséges meghibásodási pontja. Ha a Traffic Manager szolgáltatás meghibásodik, az ügyfelek a leállás ideje alatt nem érhetik el az alkalmazást. Tekintse át a Traffic Manager szolgáltatói szerződését, és döntse el, hogy a Traffic Manager egyedüli használata elegendő-e vállalata magas rendelkezésre állásra vonatkozó követelményeihez. Ha nem, akkor a biztonság érdekében érdemes lehet hozzáadni egy másik forgalomkezelési szolgáltatást a feladat-visszavételhez. Ha az Azure Traffic Manager szolgáltatás meghibásodik, módosítsa a CNAME rekordját a DNS-ben úgy, hogy a többi forgalomkezelő szolgáltatásra mutasson. (Ezt a lépést manuálisan kell elvégezni. Amíg a DNS-módosítások érvénybe nem lépnek, az alkalmazás nem lesz elérhető.)

Az SQL Server-fürt esetében két feladatátvételi forgatókönyvet kell figyelembe venni:

• Az összes SQL Server-adatbázisreplika meghibásodik az elsődleges régióban. Ez például regionális kimaradás során fordulhat elő. Ebben az esetben manuálisan kell elvégeznie a rendelkezésre állási csoport feladatátvételét, annak ellenére, hogy a Traffic Manager az előtérben automatikusan elvégzi a feladatátvételt. Kövesse a Kényszerített manuális feladatátvétel elvégzése SQL Server rendelkezésre állási csoporton című cikk lépéseit. A cikk leírja, hogyan végezhető kényszerített feladatátvétel az SQL Server Management Studio, a Transact-SQL vagy a PowerShell használatával az SQL Server 2016-ban.

  Figyelmeztetés

  A kényszerített feladatátvétel esetében adatvesztés fordulhat elő. Amint az elsődleges régió újra elérhetővé válik, készítsen pillanatfelvételt az adatbázisról, és használja a tablediff parancsot a különbségek megkereséséhez.

• A Traffic Manager átadja a feladatokat a másodlagos régiónak, de az elsődleges SQL Server-adatbázisreplika továbbra is elérhető marad. Például előfordulhat, hogy az előtérréteg meghibásodik, de ez nincs hatással az SQL Servert futtató virtuális gépekre. Ebben az esetben a rendszer átirányítja az internetes forgalmat a másodlagos régióba, és ez a régió továbbra is csatlakozhat az elsődleges replikához. Ekkor azonban nagyobb lesz a késés, mivel az SQL Server-kapcsolatoknak több régión kell áthaladniuk. Ebben a helyzetben manuálisan kell végrehajtania a feladatátvételt az alábbiak szerint:

  1. Ideiglenesen állítson át egy SQL Server-adatbázisreplikát a másodlagos régióban szinkron véglegesítésre. Ez biztosítja, hogy ne legyen adatvesztés a feladatátvétel során.

  2. Végezze el a feladatátvételt erre a replikára.

  3. Miután megtörtént a feladat-visszavétel az elsődleges régióra, állítsa vissza az aszinkron véglegesítést.

Felügyeleti szempontok

Amikor frissíti az üzemelő példányt, egyszerre egy régiót frissítsen. Ezzel csökkenthető a nem megfelelő konfiguráció vagy az alkalmazásban felmerülő hiba okozta globális meghibásodás esélye.

Tesztelje a rendszer meghibásodásokkal szembeni rugalmasságát. Alább található néhány gyakori meghibásodási helyzet:

• Állítson le virtuálisgép-példányokat.

• Terhelje az erőforrásokat, például a processzort és a memóriát.

• Bontsa/késleltesse a hálózati kapcsolatot.

• Váltsa ki egyes folyamatok összeomlását.

• Alkalmazzon lejárt tanúsítványokat.

• Szimuláljon hardverhibákat.

• Állítsa le a DNS-szolgáltatást a tartományvezérlőkön.

Mérje meg a helyreállítási időtartamokat, és győződjön meg róla, hogy azok megfelelnek az üzleti követelményeinek. Több hibaállapot kombinációját is tesztelje.

Következő lépések

• Az Azure Cloud Patterns szolgáltatással kapcsolatos további információkért lásd: Felhőtervezési minták.