Földrajzilag elosztott adatarchitektúra tervezése
Az alkalmazás architektúrájának megtervezésében az utolsó rész az adattárolási réteg mérlegelése. Biztosak szeretnénk lenni abban, hogy az adatok teljes funkcionalitással olvashatók és írhatók lesznek egy egész régióra kiterjedő hiba után.
A szállítmánykövetési portálon úgy döntöttünk, hogy az Azure Front Door használatával küldjük el az összes kérést az Usa keleti régiójában található App Servicesnek. Ha az USA keleti régiója meghibásodik, a Front Door észleli a hibát, és kéréseket küld az USA nyugati régiójában található duplikált App Services-összetevőkre. Az eredeti, egyrégiós architektúrában a relációs adatokat az Azure SQL Database-ben, a részben strukturált adatokat pedig a Cosmos DB-ben tároltuk. Most szeretnénk megérteni, hogyan biztosíthatjuk, hogy mindkét adatbázis elérhető maradjon, ha az USA keleti régiója meghibásodik.
Itt megtudhatja, hogyan replikálhatja az adatokat a régiók között, és hogyan biztosíthatja, hogy szükség esetén a feladatátvétel gyorsan megtörténjen.
Azure SQL Database
A relációs adatokat tároló Azure SQL Database többrégiós implementációjának létrehozásához a következők egyikét használhatjuk:
- Active geo-replication
- Automatikus feladatátvételi csoportok
Active geo-replication
Az Azure SQL Database képes egy adatbázist és annak minden módosítását automatikusan egy másik adatbázisba replikálni az aktív georeplikáció szolgáltatással. Az adatbázis írható példányát egyedül az elsődleges logikai kiszolgáló üzemelteti. Létrehozható legfeljebb négy másik logikai kiszolgáló, amelyek az adatbázis írásvédett példányait üzemeltetik.
A szállítmánykövetési portálhoz hozzon létre egy másodlagos adatbázist az USA nyugati régiójában, és konfigurálja az USA keleti régiójából származó georeplikálást. Regionális hiba esetén a Front Door átirányítja a felhasználói kéréseket az Usa nyugati régiójában található App Servicesbe. Az App Services és az Azure Functions hozzáférhet a relációs adatokhoz, mert egy másolat már replikálva lett az USA nyugati régiójába.
Ez a változtatás automatikus, de mint tudjuk, az USA nyugati régiójában lévő másodlagos adatbázis írásvédett. Ha egy felhasználó adatokat próbál módosítani, például új szállítást kezdeményez, hibák léphetnek fel. Amint észleljük a problémát az Azure Portalon, manuálisan kezdeményezhetjük a feladatátvételt az USA nyugati régiójába. Ha automatizálni szeretnénk ezt a folyamatot, a fejlesztők írhatnak olyan kódot amely meghívja failover metódust az Azure SQL Database REST API-ban.
Megjegyzés:
Az Azure SQL Database felügyelt példányai nem támogatják az aktív georeplikációt. A felügyelt példányok rendeltetése az, hogy egyszerűbbé tegyék a biztonság fenntartása melletti adatmigrálást egy helyszíni SQL Server-ről. Ha felügyelt példányt használ, fontolja meg inkább a feladatátvételi csoportok használatát.
Automatikus feladatátvételi csoportok
Egy automatikus feladatátvételi csoport adatbázisok olyan csoportja, amelyben az adatok automatikusan replikálva vannak egy elsődleges kiszolgálóról egy vagy több másodlagosra. Ez a kialakítás az aktív georeplikációéhoz hasonló, és ugyanazt az adatreplikálási módszert használja. A hibára adott reakció azonban szabályzat meghatározásával automatizálható.
A szállítási portálhoz létrehozunk egy másodlagos adatbázist az USA nyugati régiójában. Ezután hozzáadunk egy szabályzatot, amely az adatbázis elsődleges replikája felett meghiúsul az USA nyugati régiójában, ha katasztrofális hiba történik az USA keleti régiójában. Ilyen esetben automatikusan az USA nyugati régiójában lévő replika válik az írható elsődleges adatbázissá, és megmarad a teljes funkcionalitás.
Automatikus feladatátvételi csoport használatát akkor érdemes mérlegelni, ha úgy szeretné automatizálni az írható adatbázis feladatátvételét, hogy nem ír egyéni kódot ennek kiváltására. Emellett automatikus feladatátvételi csoportokat is használhat, ha az adatbázis az Azure SQL Database felügyelt példányában fut.
Fontos
Az aktív georeplikációs és automatikus feladatátvételi csoportok alapjául tartozó replikáció aszinkron. Amikor egy módosítás alkalmazva van az elsődleges replikán, a rendszer nyugtát küld az ügyfélnek. Ezzel a tranzakció befejezettnek minősül, és megkezdődik a replikálás. Ha hiba keletkezik, akkor az elsődleges adatbázisban végrehajtott utolsó módosítások nem feltétlenül lesznek a másodlagosba replikálva. Figyelembe kell venni, hogy katasztrófa után a legutóbbi adatbázis-módosítások elveszhetnek.
Azure Cosmos DB
A konfigurációnk kevésbé összetett az Azure Cosmos DB-vel, mivel többrégiós felhőadatbázis-rendszerként van kialakítva. A Cosmos DB többmodelles adatbázis, amely relációs, részben strukturált és más formátumú adatok tárolására is alkalmas. A Cosmos DB adatai a legmagasabb rendelkezésre állás érdekében akkor is különböző hibatűrési tartományokban lévő példányokra vannak replikálva, ha egyetlen régióban futtatjuk.
Többrégiós Cosmos DB-fiók létrehozásakor az alábbi használati módok közül választhatunk:
Többrégiós fiókok több írható régióval.
Ebben a módban az adatbázis minden példánya mindig írható. Egy régió kiesése esetén nincs szükség feladatátvételre.
Többrégiós fiókok egyetlen írható régióval.
Ebben a módban csak az elsődleges régió tartalmaz írható adatbázisokat. A másodlagos régiókba replikált adatok írásvédettek. Az elsődleges régió kiesése esetén a módosítások alapértelmezés szerint le vannak tiltva. Választhatjuk azonban az automatikus feladatátvétel engedélyezése beállítást, hogy a Cosmos DB automatikusan átadja az adatbázis elsődleges, írható példányának feladatait egy másik régiónak.
Fontos
A Cosmos DB-ben az adatreplikáció szinkronizált. Módosítások alkalmazásakor a tranzakció nem minősül befejezettnek, amíg nincs a minimálisan elégséges számban replikálva. Az ügyfél csak ez után kap róla nyugtát. Hiba esetén az utolsó módosítások sem vesznek el, mert a replikáció már lezajlott.