Földrajzilag elosztott adatarchitektúra tervezése

Befejeződött

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.

Úgy döntöttünk, hogy a szállítmánykövető portálon minden kérést az USA keleti régiójában lévő App Service-szolgáltatásnak küldünk az Azure Front Door használatával. Ha az USA keleti régiója Front Door, a rendszer észleli a hibát, és kéréseket küld az APP SERVICES nyugati régiója összetevőinek duplikált összetevőinek. 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 azt szeretnénk megtudni, hogyan biztosítható, hogy mindkét adatbázis elérhető maradjon az USA keleti régiójában történő hiba esetén.

Itt megtudhatja, hogyan replikálhat adatokat a régiók között, és hogyan gondoskodhat arról, hogy a feladatátvétel szükség esetén gyorsan bekövetkezhet.

Többrépontos architektúra-adatbázisokat bemutató diagram.

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:

  • Aktív georeplikáció
  • Automatikus feladatátvételi csoportok

Aktív georeplikáció

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ő portálhoz egy másodlagos adatbázist hozunk létre az USA nyugati régiójában, és konfiguráljuk a georeplikációt az USA keleti régiójában. Regionális hiba esetén a Front Door az USA nyugati régiójában lévő App Service-szolgáltatásokhoz irányítja a felhasználói kéréseket. Az App Service-szolgáltatások és az Azure-függvények azért férnek hozzá a relációs adatokhoz, mert azok egy példánya már replikálva van az USA nyugati régiójában.

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. Az USA nyugati régiójában manuálisan kezdeményezhetjük a feladatátvételt, amint észleljük a problémát az Azure Portalon. 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. Felügyelt példányok használata esetén érdemes megfontolni 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 az USA nyugati régiójában hozunk létre másodlagos adatbázist. Ez után felveszünk hozzá egy szabályzatot, amely az elsődleges replika feladatát az USA nyugati régiójába helyezi át az USA keleti régiójában bekövetkező katasztrofális hiba esetén. 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. Akkor is feladatátvételi csoportokat kell használnunk, ha az adatbázis az Azure SQL Database egy felügyelt példányában fut.

Fontos

Az aktív georeplikációt és az automatikus feladatátvételi csoportokat is kiszolgáló 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

Az Azure Cosmos DB konfigurációja kevésbé összetett. 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. Ez azért van így, mert a Cosmos DB-t többrégiós felhőbeli adatbázis-rendszernek tervezték. 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 mindig írható az adatbázis összes példánya. 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.

Tesztelje tudását

1.

Azt szeretné, hogy regionális kimaradás esetén a szállítmánykövető alkalmazásban automatikusan megtörténjen a feladatátvétel az SQL-adatbázishoz való írási hozzáféréssel. Nem szeretne egyéni kódot írni. Mi a teendő?

2.

Gondoskodni szeretne arról, hogy regionális kimaradás esetén nem vesznek el befejezett tranzakciók. Mi a teendő?