Az IaaS magas rendelkezésre állású és vészhelyreállítási megoldásának felfedezése
Az Azure for IaaS-ben számos különböző funkciókombináció telepíthető. Ez a szakasz öt gyakori példát mutat be az SQL Server magas rendelkezésre állású és vészhelyreállítási (HADR) architektúráira az Azure-ban.
Egyrégiós magas rendelkezésre állási példa 1. példa – Always On rendelkezésre állási csoportok
Ha csak magas rendelkezésre állásra van szüksége, és nem vészhelyreállításra, a (rendelkezésre állási csoport) AG konfigurálása az egyik legáthatóbb módszer, függetlenül attól, hogy hol használja az SQL Servert. Az alábbi képen egy példa látható arra, hogy egy adott régióban milyen lehet egy lehetséges AG.
Miért érdemes megfontolni ezt az architektúrát?
Ez az architektúra úgy védi az adatokat, hogy több példányt is tartalmaz a különböző virtuális gépeken.
Ez az architektúra lehetővé teszi a helyreállítási időkorlát (RTO) és a helyreállítási pont célkitűzésének (RPO) megfelelő implementálás esetén minimális adatvesztéssel való elérését.
Ez az architektúra egyszerű, szabványosított módszert biztosít az alkalmazások számára az elsődleges és a másodlagos replikák eléréséhez (ha például írásvédett replikákat használnak).
Ez az architektúra jobb rendelkezésre állást biztosít a javítási forgatókönyvek során.
Ez az architektúra nem igényel megosztott tárterületet, ezért kisebb a bonyodalom, mint egy feladatátvevő fürtpéldány (FCI) használatakor.
2. példa egyrégiós magas rendelkezésre állásra – Always On Feladatátvevő fürtpéldány
Az AG-k bevezetéséig az FCI-k voltak a legnépszerűbbek az SQL Server magas rendelkezésre állásának megvalósítására. Az FCI-ket azonban akkor tervezték, amikor a fizikai környezetek voltak dominánsak. A virtualizált világban az FCI-k nem nyújtanak sok ugyanolyan védelmet, mint a fizikai hardveren, mivel ritkán fordul elő, hogy egy virtuális gép problémába merüljön. Az FCI-k úgy lettek kialakítva, hogy védelmet nyújtsanak olyan dolgokkal szemben, mint a hálózati kártya meghibásodása vagy a lemezhiba, amelyek valószínűleg nem fordulnak elő az Azure-ban.
Ennek ellenére az FCI-knek van helyük az Azure-ban. Működnek, és mindaddig, amíg a megfelelő elvárásai vannak azzal kapcsolatban, hogy mi az, és mi nem biztosított, az FCI egy tökéletesen elfogadható megoldás. Az alábbi képen a Microsoft dokumentációjából látható, hogy az FCI-környezet hogyan néz ki a Tárolóhelyek Direct használatakor.
Miért érdemes megfontolni ezt az architektúrát?
Az FCI-k továbbra is népszerű rendelkezésre állási megoldások.
A megosztott tárterület fejlesztése olyan funkciókkal történik, mint az Azure Shared Disk.
Ez az architektúra megfelel a HA legtöbb RTO-jának és RPO-jának (bár a DR nem kezelhető).
Ez az architektúra egy egyszerű, szabványosított módszert biztosít az alkalmazások számára az SQL Server fürtözött példányának eléréséhez.
Ez az architektúra jobb rendelkezésre állást biztosít a javítási forgatókönyvek során.
1. vészhelyreállítási példa – Többrégiós vagy hibrid Always On rendelkezésre állási csoport
Ha AG-ket használ, az egyik lehetőség az AG konfigurálása több Azure-régióban vagy potenciálisan hibrid architektúraként. Ez azt jelenti, hogy a replikákat tartalmazó összes csomópont ugyanabban a WSFC-ben vesz részt. Ez jó hálózati kapcsolatot feltételez, különösen akkor, ha hibrid konfigurációról van szó. Az egyik legnagyobb szempont a WSFC tanúsító erőforrása lenne. Ez az architektúra megköveteli, hogy az AD DS és a DNS elérhető legyen minden régióban és potenciálisan a helyszínen is, ha hibrid megoldásról van szó. Az alábbi képen látható, hogyan néz ki egy két helyen konfigurált egyetlen AG a Windows Server használatával.
Miért érdemes megfontolni ezt az architektúrát?
Ez az architektúra bevált megoldás; ez nem más, mint két adatközpont ma egy AG-topológiában.
Ez az architektúra az SQL Server Standard és Enterprise kiadásaival működik.
Az AG-k természetesen további adatmásolatokkal biztosítják a redundanciát.
Ez az architektúra egyetlen olyan funkciót használ, amely ha- és D/R-t is biztosít
2. vészhelyreállítási példa – Elosztott rendelkezésre állási csoport
Az elosztott AG egy Enterprise kiadás csak az SQL Server 2016-ban bevezetett szolgáltatás. Ez eltér a hagyományos AG-hez képest. Ahelyett, hogy rendelkezik egy mögöttes WSFC-vel, amelyben az összes csomópont egy AG-ben részt vevő replikákat tartalmaz az előző példában leírtak szerint, az elosztott AG-k több AG-ből áll. Az olvasási írási adatbázist tartalmazó elsődleges replikát globális elsődlegesnek nevezzük. A második AG elsődlegese továbbítóként ismert, és szinkronban tartja az adott AG másodlagos replikáit. Lényegében ez az AG-k AG-je.
Ez az architektúra megkönnyíti az olyan dolgok kezelését, mint a kvórum, mivel minden fürt saját kvórumot tart fenn, ami azt jelenti, hogy saját tanúval is rendelkezik. Az elosztott AG működni fog, akár az Azure-t használja az összes erőforráshoz, akár hibrid architektúrát használ.
Az alábbi képen egy példa elosztott AG-konfiguráció látható. Két WSFC van. Tegyük fel, hogy mindegyik egy másik Azure-régióban található, vagy az egyik a helyszínen, a másik pedig az Azure-ban található. Minden WSFC rendelkezik két replikával rendelkező AG-vel. Az AG 1 globális elsődlegese az AG 1 másodlagos replikáját szinkronizálva tartja, valamint a továbbítót, amely szintén a 2. AG elsődlegese. Ez a replika szinkronizálja az AG 2 másodlagos replikáját.
Miért érdemes megfontolni ezt az architektúrát?
Ez az architektúra egyetlen meghibásodási pontként választja el a WSFC-t, ha minden csomópont elveszíti a kommunikációt
Ebben az architektúrában egyetlen elsődleges nem szinkronizálja az összes másodlagos replikát.
Ez az architektúra biztosíthatja a feladat-visszalépést egyik helyről a másikra.
3. vészhelyreállítási példa – Naplószállítás
A naplószállítás az SQL Server vészhelyreállításának konfigurálására szolgáló legrégebbi HADR-metódusok egyike. A fent leírtaknak megfelelően a mértékegység a tranzakciónapló biztonsági mentése. Hacsak nem tervezik a meleg készenléti üzemmódra való váltást, hogy ne történjen adatvesztés, az adatvesztés valószínűleg bekövetkezik. Vészhelyreállítás esetén mindig érdemes némi adatvesztést feltételezni, még akkor is, ha minimális. Az alábbi kép a Microsoft dokumentációjából egy példanapló szállítási topológiáját mutatja be.
Miért érdemes megfontolni ezt az architektúrát?
A naplószállítás egy kipróbált és igaz funkció, amely már több mint 20 éve létezik
A naplószállítás egyszerűen üzembe helyezhető és felügyelhető, mivel biztonsági mentésen és visszaállításon alapul.
A naplószállítás toleráns az olyan hálózatokhoz, amelyek nem robusztusak.
A naplószállítás megfelel a DR legtöbb RTO- és RPO-céljának.
A naplószállítás jó módszer az FCI-k védelmére.
4. vészhelyreállítási példa – Azure Site Recovery
Azok számára, akik nem szeretnének SQL Server-alapú vészmegoldást implementálni, az Azure Site Recovery egy lehetséges lehetőség. Az adatszakértők többsége azonban inkább az adatbázis-központú megközelítést részesíti előnyben, mivel általában alacsonyabb RPO-t használ.
Az alábbi kép a Microsoft dokumentációjából származik. Megjeleníti, hogy az Azure Portalon hol konfigurálná az Azure Site Recovery replikációját.
Miért érdemes megfontolni ezt az architektúrát?
Az Azure Site Recovery nem csak az SQL Serverrel fog működni.
Az Azure Site Recovery megfelelhet az RTO-nak és esetleg az RPO-nak.
Az Azure Site Recovery az Azure platform részeként érhető el.