Ez a referenciaarchitektúra néhány bevált eljárást mutat be egy N szintű alkalmazás több Azure-régióban való futtatásához a magas rendelkezésre állás eléréséhez és egy robusztus vészhelyreállítási infrastruktúra kiépítéséhez.
Felépítés
Töltse le az architektúra Visio-fájlját.
Munkafolyamat
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, valamint a Traffic Managerhez. Ezzel a módszerrel rugalmasan kezelheti az egyes régiókat egyetlen erőforrásgyűjteményként. 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. Győződjön meg arról, hogy a címterek nem fedik egymást.
SQL Server Always On rendelkezésre állási csoport. Ha SQL Servert használ, a magas rendelkezésre állás érdekében az SQL Always On rendelkezésre állási csoportokat javasoljuk. Hozzon létre egyetlen rendelkezésre állási csoportot, amely mindkét régióban tartalmazza az SQL Server-példányokat.
Megjegyzés:
Másik lehetőségként fontolja meg az Azure SQL Database használatát, amely relációs adatbázist biztosít felhőszolgáltatás formájában. Az SQL Database használatával nem kell rendelkezésre állási csoportot konfigurálnia, vagy kezelnie a feladatátvételt.
Virtuális hálózatok közötti társviszony-létesítés. Társviszonyt létesíthet a két virtuális hálózattal az elsődleges régióból a másodlagos régióba történő adatreplikálás engedélyezéséhez. További információ: Virtuális hálózatok közötti társviszony-létesítés.
Összetevők
- A rendelkezésre állási csoportok biztosítják, hogy az Azure-ban üzembe helyezhető virtuális gépek több elkülönített hardvercsomópont között legyenek elosztva egy fürtben. Ha hardver- vagy szoftverhiba történik az Azure-ban, a rendszer csak a virtuális gépek egy részét érinti, és a teljes megoldás elérhető és működőképes marad.
- A rendelkezésre állási zónák védik az alkalmazásokat és az adatokat az adatközpont hibáitól. A rendelkezésre állási zónák különálló fizikai helyek egy Azure-régión belül. Minden zóna egy vagy több, független energiaellátással, hűtéssel és hálózatkezeléssel felszerelt adatközpontból áll.
- Az Azure Traffic Manager egy DNS-alapú forgalom terheléselosztó, amely optimálisan osztja el a forgalmat. Szolgáltatásokat nyújt a globális Azure-régiókban, magas rendelkezésre állással és válaszkészséggel.
- Az Azure Load Balancer a meghatározott szabályok és állapotminták szerint osztja el a bejövő forgalmat. A terheléselosztó alacsony késést és nagy átviteli sebességet biztosít, és akár több millió folyamatot is felskálázhat az összes TCP- és UDP-alkalmazáshoz. Ebben a forgatókönyvben egy nyilvános terheléselosztót használunk a bejövő ügyfélforgalom webes szintre való elosztásához. Ebben a forgatókönyvben egy belső terheléselosztót használunk a forgalom üzleti szintről a háttérbeli SQL Server-fürtre való elosztásához.
- Az Azure Bastion biztonságos RDP- és SSH-kapcsolatot biztosít az összes virtuális géphez abban a virtuális hálózatban, amelyben ki van építve. Az Azure Bastion használatával megvédheti a virtuális gépeket az RDP/SSH-portok külső világba való felfedésétől, miközben továbbra is biztonságos hozzáférést biztosít az RDP/SSH használatával.
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 kiszolgálóval. A forgalom az egyik régióra irányul, míg a másik készenléti kiszolgálón várakozik. A készenléti állapot azt jelenti, hogy a másodlagos régióban lévő virtuális gépek ki vannak foglalva, és mindig futnak.
- Aktív/passzív hidegtartalékkal. A forgalom az egyik régióra irányul, míg a másik hidegtartalékként áll készenlétben. A hideg készenléti állapot azt jelenti, hogy a másodlagos régióban lévő virtuális gépek csak a feladatátvételhez lesznek lefoglalva. 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, az el lesz veszve a forgatásbó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. Üzembe helyezhet néhány virtuális gépet a gyakori elérésű készenléti állapotban, majd igény szerint felskálázhatja a skálázást.
Régiónkénti párosítás
Minden egyes Azure-régió párban áll egy másikkal egy azonos földrajzi területen belül. Régiókat általában azonos regionális párokból érdemes választani (például: USA 2. keleti régiója és USA középső régiója). Ennek előnyei például a következők:
- Ha széles körű kimaradás áll fenn, a rendszer minden párból legalább egy régió helyreállítását rangsorolja.
- A tervezett Azure-rendszerfrissítések egyszerre csak a régiópár egyik tagján jelennek meg, ami csökkenti az állásidőt.
- A párok azonos földrajzi helyen belül találhatók, hogy megfeleljenek az adatok tárolási helyére vonatkozó előírásoknak.
Azonban győződjön meg arról, hogy mindkét régió támogatja az összes Azure-szolgáltatást, amely szükséges az alkalmazásához (lásd: Szolgáltatások régiónként). További információ a regionális párokról: Üzletmenet-folytonosság és vészhelyreállítás (BCDR): Az Azure párosított régiói.
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.
- Állapotminta. 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 meghibásodik, van egy időszak, amikor az ügyfelek nem érik el az alkalmazást. 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.
A Traffic Manager alapértelmezés szerint automatikusan visszabukik. A probléma elkerülése érdekében manuálisan csökkentse az elsődleges régió prioritását egy feladatátvételi esemény 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 visszavá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 azureEndpoints --priority 3
Egy másik módszer a végpont ideiglenes letiltása, 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 azureEndpoints --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.
Társviszonyt létesíthet a két virtuális hálózat között a 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ájá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 ezeket a replikákat szinkron véglegesítés automatikus feladatátvétellel való használatára.
Helyezzen egy vagy több másodlagos replikát a másodlagos régióba. Konfigurálja ezeket a replikákat aszinkron véglegesítés használatára teljesítménybeli okokból. (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.
Considerations
Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.
Elérhetőség
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 nem tudnak hozzáférni az alkalmazáshoz az állásidő alatt. 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 a hiba például regionális kimaradás eseté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én fennáll az adatvesztés kockázata. 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:
- Ideiglenesen állítson át egy SQL Server-adatbázisreplikát a másodlagos régióban szinkron véglegesítésre. Ez a lépés biztosítja, hogy a feladatátvétel során ne legyen adatvesztés.
- Végezze el a feladatátvételt erre a replikára.
- Miután megtörtént a feladat-visszavétel az elsődleges régióra, állítsa vissza az aszinkron véglegesítést.
Kezelhetőség
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öltségoptimalizálás
A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.
Az Azure díjszabási kalkulátorával megbecsüli a költségeket. Íme néhány egyéb szempont.
Virtual Machine Scale Sets
A virtuálisgép-méretezési csoportok minden Windows rendszerű virtuálisgép-méretben elérhetők. Csak a telepített Azure-beli virtuális gépekért és a felhasznált, hozzáadott mögöttes infrastruktúra-erőforrásokért, például a tárolásért és a hálózatkezelésért kell fizetnie. A Virtuálisgép-méretezési csoportok szolgáltatásnak nincsenek növekményes költségei.
Az önálló virtuális gépek díjszabási lehetőségeiért tekintse meg a Windows rendszerű virtuális gépek díjszabását.
SQL server
Ha az Azure SQL DBaas-t választja, költségmegtakarítást érhet el, mert nem kell always on rendelkezésre állási csoportot és tartományvezérlőt konfigurálnia. Az önálló adatbázistól kezdve a felügyelt példányon át a rugalmas készletekig számos üzembe helyezési lehetőség érhető el. További információkért tekintse meg az Azure SQL díjszabását.
Az SQL Server virtuális gépek díjszabási beállításaiért tekintse meg az SQL virtuális gépek díjszabását.
Terheléselosztók
Csak a konfigurált terheléselosztási és kimenő szabályok számáért kell fizetnie. A bejövő NAT-szabályok ingyenesek. A Standard Load Balancer nem számít fel óránkénti díjat, ha nincsenek szabályok konfigurálva.
A Traffic Manager díjszabása
A Traffic Manager díjszabása a beérkező DNS-lekérdezések számán alapul. A havi 1 milliárdnál több lekérdezést fogadó szolgáltatások esetében kedvezményt biztosítunk. Az egyes figyelt végpontokért is díjat számítunk fel.
További információért lásd a Microsoft Azure Well-Architected Framework költségekkel kapcsolatos részét.
Virtuális hálózatok közötti társviszony-létesítés díjszabása
A több Azure-régiót használó magas rendelkezésre állású üzembe helyezés a VNET-társviszony-létesítést fogja használni. A virtuális hálózatok közötti társviszony-létesítésnek különböző díjai vannak ugyanabban a régióban és a globális virtuális hálózatok közötti társviszony-létesítés esetén.
További információ: Virtuális hálózat díjszabása.
DevOps
Egyetlen Azure Resource Manager-sablont használhat az Azure-erőforrások és függőségei kiépítéséhez. Ugyanezzel a sablonnal telepítheti az erőforrásokat az elsődleges és a másodlagos régiókban is. Adja meg az összes erőforrást ugyanabban a virtuális hálózatban, hogy azonos alapszintű számítási feladatban legyenek elkülönítve. Az összes erőforrás beleszámításával egyszerűbben társíthatja a számítási feladat adott erőforrásait egy DevOps-csapathoz, így a csapat önállóan kezelheti az erőforrások minden aspektusát. Ez az elkülönítés lehetővé teszi a DevOps Team and Services számára a folyamatos integrációt és a folyamatos teljesítést (CI/CD).
Emellett különböző Azure Resource Manager-sablonokat is használhat, és integrálhatja őket az Azure DevOps Services szolgáltatással különböző környezetek percek alatt történő kiépítéséhez, például az éles környezetek, például forgatókönyvek replikálásához vagy tesztelési környezetek betöltéséhez, ha szükséges, költségmegtakarítással.
Érdemes az Azure Monitor használatával elemezni és optimalizálni az infrastruktúra teljesítményét, valamint monitorozni és diagnosztizálni a hálózati problémákat a virtuális gépekre való bejelentkezés nélkül. Az alkalmazás Elemzések valójában az Azure Monitor egyik összetevője, amely gazdag metrikákat és naplókat biztosít a teljes Azure-környezet állapotának ellenőrzéséhez. Az Azure Monitor segít követni az infrastruktúra állapotát.
Győződjön meg arról, hogy nem csak az alkalmazáskódot támogató számítási elemeket, hanem az adatplatformot is figyeli, különösen az adatbázisait, mivel az alkalmazás adatszintjének alacsony teljesítménye súlyos következményekkel járhat.
Annak az Azure-környezetnek a teszteléséhez, ahol az alkalmazások futnak, verzióalapúnak kell lennie, és az alkalmazáskóddal azonos mechanizmusokkal kell üzembe helyezni, majd a DevOps tesztelési paradigmáival is tesztelhető és érvényesíthető.
További információt a Microsoft Azure Well-Architected Framework Operatív kiválóság című szakaszában talál.
Közreműködők
Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.
Fő szerző:
- Donnie Trumpower | Vezető felhőmegoldás-tervező
A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.
További lépések
Kapcsolódó erőforrások
A következő architektúra ugyanazokat a technológiákat használja: