Az automatikus feladatátvételi csoportok áttekintésének ajánlott & eljárásai (Azure SQL Database)

  • Cikk
  • 18 perc alatt elolvasható

A KÖVETKEZŐKRE VONATKOZIK: Azure SQL Database

Az automatikus feladatátvételi csoportok funkció lehetővé teszi a logikai kiszolgálón lévő adatbázisok egy részének vagy mindegyikének replikálását és feladatátvételét egy másik régióba. Ez a cikk az automatikus feladatátvételi csoport funkció Azure SQL Database és néhány ajánlott eljárás használatával foglalkozik.

Elsőként tekintse át az automatikus feladatátvételi csoport konfigurálását ismertető cikket. A feladatátvételi csoport automatikus feladatátvételi útmutatója a végpontok közötti élményt ismerteti.

Megjegyzés

  • Ez a cikk a Azure SQL Database automatikus feladatátvételi csoportjait ismerteti. A Azure SQL Managed Instance az automatikus feladatátvételi csoportokat Azure SQL Managed Instance.
  • Az automatikus feladatátvételi csoportok támogatják a csoport összes adatbázisának georeplikátását egy másik régióban lévő egyetlen másodlagos kiszolgálóra. Ha több Azure SQL Database földrajzilag másodlagos replikát kell létrehoznia (ugyanabban vagy különböző régiókban) ugyanahhoz az elsődleges replikához, használjon aktív georeplikát.

Áttekintés

Az automatikus feladatátvételi csoportok funkcióval kezelheti egy kiszolgálón lévő adatbáziscsoport vagy egy felügyelt példány összes felhasználói adatbázisának replikálását és feladatátvételét egy másik Azure-régióba. Ez egy deklaratív absztrakció az aktív georeplikációs funkción felül, amely a georeplikált adatbázisok nagy léptékű üzembe helyezésének és felügyeletének egyszerűsítésére lett tervezve.

Automatikus feladatátvétel

Kezdeményezhet geo-feladatátvételt manuálisan, vagy delegálhatja az Azure-szolgáltatásba egy felhasználó által megadott szabályzat alapján. Az utóbbi lehetőség lehetővé teszi több kapcsolódó adatbázis automatikus helyreállítását egy másodlagos régióban egy katasztrofális hiba vagy más nem tervezett esemény után, amely az elsődleges régióban a SQL Database vagy SQL Managed Instance rendelkezésre állásának teljes vagy részleges elvesztését eredményezi. Ezek általában olyan kimaradások, amelyeket a beépített magas rendelkezésre állású infrastruktúra nem képes automatikusan elhárítani. A geo-feladatátvételi eseményindítók közé tartoznak például a természeti katasztrófák, vagy az olyan incidensek, amelyeket egy bérlő vagy egy vezérlőkör leállása okozott a számítási csomópontokon az operációs rendszer kernelmemória-szivárgása miatt. További információ: Azure SQL magas rendelkezésre állás.

Csak olvasható számítási feladatok kiszervezése

Az elsődleges adatbázisok felé érkező forgalom csökkentése érdekében a feladatátvételi csoport másodlagos adatbázisait is használhatja az írásvédett számítási feladatok kiszervezésére. Az írásvédett figyelővel irányíthatja az írásvédett forgalmat egy olvasható másodlagos adatbázisra.

Végpont átirányítása

Az automatikus feladatátvételi csoportok által biztosított írható és olvasható, illetve írásvédett végpontok a földrajzi feladatátvétel során változatlanok maradnak. Ez azt jelenti, hogy a geo-feladatátvétel után nem kell módosítania az alkalmazás kapcsolati sztring, mert a kapcsolatok automatikusan az aktuális elsődlegesre lesznek irányítva. Akár manuális, akár automatikus feladatátvételi aktiválást használ, a geo-feladatátvétel a csoport összes másodlagos adatbázisát elsődleges szerepkörre váltja. A geo-feladatátvétel befejezése után a RENDSZER automatikusan frissíti a DNS-rekordot, hogy átirányítsa a végpontokat az új régióba. A geo-feladatátvételi RPO-t és az RTO-t az üzletmenet-folytonosság áttekintésében találja.

Alkalmazás helyreállítása

A teljes üzletmenet-folytonosság érdekében a regionális adatbázis-redundancia hozzáadása csak a megoldás része. Egy alkalmazás (szolgáltatás) teljes körű helyreállításához egy katasztrofális hiba után a szolgáltatást alkotó összes összetevő és a függő szolgáltatások helyreállítására van szükség. Ilyen összetevők például az ügyfélszoftver (például egy egyéni JavaScriptet tartalmazó böngésző), a webes előtérrendszerek, a tárterület és a DNS. Kritikus fontosságú, hogy minden összetevő ellenálló legyen ugyanazokkal a hibákkel szemben, és az alkalmazás helyreállítási időkorlátja (RTO) keretében elérhetővé váljon. Ezért azonosítania kell az összes függő szolgáltatást, és ismernie kell az általuk nyújtott garanciákat és képességeket. Ezután meg kell tennie a megfelelő lépéseket annak biztosítására, hogy a szolgáltatás működjön azon szolgáltatások feladatátvétele során, amelyektől függ.

Terminológia és képességek

  • Feladatátvételi csoport (FOG)

    A feladatátvételi csoport az önálló kiszolgáló által felügyelt adatbázisok nevesített csoportja, amely egységként feladatátvételt végezhet egy másik Azure-régióba arra az esetre, ha az elsődleges régió kimaradása miatt az összes vagy néhány elsődleges adatbázis elérhetetlenné válik.

    Fontos

    A feladatátvételi csoport nevének globálisan egyedinek kell lennie a .database.windows.net tartományban.

  • Kiszolgálók

    A logikai kiszolgálón lévő felhasználói adatbázisok egy része vagy mindegyike elhelyezhető feladatátvételi csoportban. A kiszolgálók emellett több feladatátvételi csoportot is támogatnak egyetlen kiszolgálón.

  • Elsődleges

    A feladatátvételi csoport elsődleges adatbázisait üzemeltető kiszolgáló.

  • Másodlagos

    A feladatátvételi csoportban a másodlagos adatbázisokat üzemeltető kiszolgáló. A másodlagos nem lehet ugyanabban az Azure-régióban, mint az elsődleges.

  • Önálló adatbázisok hozzáadása feladatátvételi csoporthoz

    Több önálló adatbázist is elhelyezhet ugyanazon a kiszolgálón ugyanabba a feladatátvételi csoportba. Ha egyetlen adatbázist ad hozzá a feladatátvételi csoporthoz, az automatikusan létrehoz egy másodlagos adatbázist ugyanazzal a kiadással és számítási méretekkel a másodlagos kiszolgálón. Ezt a kiszolgálót a feladatátvételi csoport létrehozásakor adta meg. Ha olyan adatbázist ad hozzá, amely már rendelkezik másodlagos adatbázissal a másodlagos kiszolgálón, a georeplikációs kapcsolatot a csoport örökli. Ha olyan adatbázist ad hozzá, amely már rendelkezik másodlagos adatbázissal egy olyan kiszolgálón, amely nem része a feladatátvételi csoportnak, a rendszer létrehoz egy új másodlagosat a másodlagos kiszolgálón.

    Fontos

    Győződjön meg arról, hogy a másodlagos kiszolgáló nem rendelkezik azonos nevű adatbázissal, hacsak nem egy meglévő másodlagos adatbázisról van szó.

  • Adatbázisok hozzáadása a rugalmas készletben a feladatátvételi csoporthoz

    Egy rugalmas készleten belül az összes vagy több adatbázist ugyanabba a feladatátvételi csoportba helyezheti. Ha az elsődleges adatbázis rugalmas készletben található, a másodlagos adatbázis automatikusan létrejön a rugalmas készletben ugyanazzal a névvel (másodlagos készlet). Győződjön meg arról, hogy a másodlagos kiszolgáló azonos nevű rugalmas készletet tartalmaz, és elegendő szabad kapacitással rendelkezik a feladatátvételi csoport által létrehozott másodlagos adatbázisok üzemeltetéséhez. Ha olyan adatbázist ad hozzá a készlethez, amely már rendelkezik másodlagos adatbázissal a másodlagos készletben, a georeplikációs csatolást a csoport örökli. Ha olyan adatbázist ad hozzá, amely már rendelkezik másodlagos adatbázissal egy olyan kiszolgálón, amely nem része a feladatátvételi csoportnak, a rendszer létrehoz egy új másodlagosat a másodlagos készletben.

  • Feladatátvételi csoport olvasási-írási figyelője

    Egy DNS CNAME rekord, amely az aktuális elsődlegesre mutat. Automatikusan létrejön a feladatátvételi csoport létrehozásakor, és lehetővé teszi, hogy az írási-olvasási számítási feladat transzparensen újra csatlakozzon az elsődlegeshez, amikor az elsődleges változás a feladatátvételt követően megváltozik. Amikor a feladatátvételi csoport létrejön egy kiszolgálón, a figyelő URL-címéhez tartozó DNS CNAME rekord a következőképpen <fog-name>.database.windows.netalakul.

  • Feladatátvételi csoport írásvédett figyelője

    Egy DNS CNAME rekord, amely az aktuális másodlagosra mutat. A feladatátvételi csoport létrehozásakor automatikusan létrejön, és lehetővé teszi, hogy az írásvédett SQL számítási feladat transzparens módon csatlakozzon a másodlagoshoz, amikor a másodlagos változás a feladatátvételt követően megváltozik. Amikor a feladatátvételi csoport létrejön egy kiszolgálón, a figyelő URL-címéhez tartozó DNS CNAME rekord a következőképpen <fog-name>.secondary.database.windows.netalakul.

  • Több feladatátvételi csoport

    Több feladatátvételi csoportot is konfigurálhat ugyanahhoz a kiszolgálópárhoz a geo-feladatátvétel hatókörének szabályozásához. Minden csoport egymástól függetlenül feladatátvételt ad át. Ha a bérlőnkénti adatbázis-alkalmazás több régióban van üzembe helyezve, és rugalmas készleteket használ, ezzel a képességgel kombinálhatja az egyes készletek elsődleges és másodlagos adatbázisait. Így csökkentheti a szolgáltatáskimaradás hatását csak néhány bérlői adatbázisra.

  • Automatikus feladatátvételi szabályzat

    Alapértelmezés szerint a feladatátvételi csoport automatikus feladatátvételi szabályzattal van konfigurálva. A rendszer geo-feladatátvételt indít el a hiba észlelése és a türelmi időszak lejárta után. A rendszernek ellenőriznie kell, hogy a kimaradás nem enyhíthető-e a beépített magas rendelkezésre állású infrastruktúrával, például a hatás mértéke miatt. Ha az alkalmazásból vagy manuálisan szeretné vezérelni a geo-feladatátvételi munkafolyamatot, kikapcsolhatja az automatikus feladatátvételi szabályzatot.

    Megjegyzés

    Mivel a szolgáltatáskimaradás mértékének ellenőrzése és annak mérséklése emberi beavatkozást igényel, a türelmi időszak nem állítható be egy óra alatt. Ez a korlátozás a feladatátvételi csoportban lévő összes adatbázisra vonatkozik, függetlenül azok adatszinkronizálási állapotától.

  • Írásvédett feladatátvételi szabályzat

    Alapértelmezés szerint az írásvédett figyelő feladatátvétele le van tiltva. Biztosítja, hogy az elsődleges kiszolgáló teljesítménye ne legyen hatással a másodlagos kapcsolat nélküli állapotra. Ugyanakkor azt is jelenti, hogy az írásvédett munkamenetek nem fognak tudni csatlakozni, amíg a másodlagos munkamenet helyre nem áll. Ha az írásvédett munkamenetek állásideje nem tolerálható, és az elsődlegest írásvédett és írásvédett forgalomhoz is használhatja az elsődlegesen az elsődleges teljesítménycsökkenés rovására, a tulajdonság konfigurálásával engedélyezheti a feladatátvételt az AllowReadOnlyFailoverToPrimary írásvédett figyelő számára. Ebben az esetben a rendszer automatikusan átirányítja a csak olvasható forgalmat az elsődlegesre, ha a másodlagos nem érhető el.

    Megjegyzés

    A AllowReadOnlyFailoverToPrimary tulajdonság csak akkor lép érvénybe, ha az automatikus feladatátvételi szabályzat engedélyezve van, és automatikus geo-feladatátvétel lett aktiválva. Ebben az esetben, ha a tulajdonság értéke Igaz, az új elsődleges kiszolgáló írási-olvasási és írásvédett munkameneteket is kiszolgál.

  • Tervezett feladatátvétel

    A tervezett feladatátvétel teljes adatszinkronizálást hajt végre az elsődleges és a másodlagos adatbázisok között, mielőtt a másodlagos áttér az elsődleges szerepkörre. Ez nem garantálja az adatvesztést. A tervezett feladatátvételt a következő helyzetekben használjuk:

    • Vészhelyreállítási (DR) próbák végrehajtása éles környezetben, ha az adatvesztés nem elfogadható
    • Az adatbázisok áthelyezése egy másik régióba
    • Adja vissza az adatbázisokat az elsődleges régióba a szolgáltatáskimaradás csökkentése után (feladat-visszavétel)

  • Nem tervezett feladatátvétel

    A nem tervezett vagy kényszerített feladatátvétel azonnal átváltja a másodlagos szerepkört az elsődleges szerepkörre anélkül, hogy megvárná a legutóbbi módosítások propagálását az elsődlegesről. Ez a művelet adatvesztést okozhat. A nem tervezett feladatátvétel helyreállítási módszerként használatos a kimaradások során, ha az elsődleges nem érhető el. A szolgáltatáskimaradás mérséklésekor a régi elsődleges rendszer automatikusan újracsatlakozik, és új másodlagossá válik. Egy tervezett feladatátvétel végrehajtható a feladat-visszavételhez, amely visszaadja a replikákat az eredeti elsődleges és másodlagos szerepköreiknek.

  • Manuális feladatátvétel

    A geo-feladatátvételt az automatikus feladatátvételi konfigurációtól függetlenül bármikor kezdeményezheti manuálisan. Ha az elsődleges feladatátvételi szabályzat nincs konfigurálva, az elsődlegesre hatással lévő kimaradás esetén manuális feladatátvételre van szükség a másodlagos szerepkör elsődleges szerepkörbe való előléptetéséhez. Kezdeményezhet kényszerített (nem tervezett) vagy barátságos (tervezett) feladatátvételt. A felhasználóbarát feladatátvétel csak akkor lehetséges, ha a régi elsődleges példány elérhető, és adatvesztés nélkül áthelyezhető a másodlagos régióba. A feladatátvétel befejezésekor a RENDSZER automatikusan frissíti a DNS-rekordokat, hogy biztosítsa az új elsődleges kiszolgálóhoz való kapcsolódást.

  • Türelmi időszak adatvesztéssel

    Mivel az adatok aszinkron replikációval replikálódnak a másodlagos adatbázisba, az automatikus geo-feladatátvétel adatvesztést okozhat. Az automatikus feladatátvételi szabályzatot testre szabhatja úgy, hogy tükrözze az alkalmazás adatvesztéssel szembeni tűréshatárát. Konfigurálásával GracePeriodWithDataLossHoursszabályozhatja, hogy a rendszer mennyi ideig várjon a kényszerített feladatátvétel kezdeményezése előtt, ami adatvesztést okozhat.

Feladatátvételi csoport architektúrája

A Azure SQL Database feladatátvételi csoportja tartalmazhat egy vagy több adatbázist, amelyeket általában ugyanaz az alkalmazás használ. Ha automatikus feladatátvételi szabályzattal rendelkező automatikus feladatátvételi csoportokat használ, a csoport egy vagy több adatbázisát érintő leállások automatikus geo-feladatátvételt eredményeznek.

Az automatikus feladatátvételi csoportot az elsődleges kiszolgálón kell konfigurálni, és egy másik Azure-régióban lévő másodlagos kiszolgálóhoz kell csatlakoztatni. A csoportok az összes vagy néhány adatbázist tartalmazhatják ezekben a kiszolgálókban. Az alábbi ábra egy több adatbázissal és automatikus feladatátvételi csoporttal rendelkező georedundáns felhőalkalmazás tipikus konfigurációját mutatja be.

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

A szolgáltatás üzletmenet-folytonosságot szem előtt tartva történő tervezésekor kövesse az ebben a cikkben ismertetett általános irányelveket és ajánlott eljárásokat. Feladatátvételi csoport konfigurálásakor győződjön meg arról, hogy a hitelesítés és a hálózati hozzáférés a másodlagos helyen megfelelően működik a geo-feladatátvétel után, amikor a geo-másodlagos lesz az új elsődleges. Részletekért tekintse meg SQL Database vészhelyreállítás utáni biztonságot. További információ a vészhelyreállítási megoldások tervezéséről: Felhőmegoldások tervezése vészhelyreállításhoz aktív georeplikálás használatával.

Az időponthoz kötött visszaállítás feladatátvételi csoportokkal való használatával kapcsolatos információkért lásd: Időponthoz kötött helyreállítás (PITR).

Kezdeti vetés

Amikor adatbázisokat vagy rugalmas készleteket ad hozzá egy feladatátvételi csoporthoz, az adatreplikálás megkezdése előtt van egy kezdeti bevezetési fázis. A kezdeti vetés fázisa a leghosszabb és legdrágább művelet. A kezdeti bevetés befejezése után a rendszer szinkronizálja az adatokat, majd csak az ezt követő adatmódosításokat replikálja. A kezdeti előkészítés befejezéséhez szükséges idő az adatok méretétől, a replikált adatbázisok számától, az elsődleges adatbázisok terhelésétől, valamint az elsődleges és a másodlagos adatbázis közötti kapcsolat sebességétől függ. Normál körülmények között a vetés lehetséges sebessége óránként 500 GB SQL Database. A bevetés az összes adatbázis esetében párhuzamosan történik.

Több adatbázis feladatátvétele több feladatátvételi csoport használatával

Egy vagy több feladatátvételi csoport két kiszolgáló között hozható létre különböző régiókban (elsődleges és másodlagos kiszolgálók). Minden csoport tartalmazhat egy vagy több, egységként helyreállított adatbázist arra az esetre, ha az elsődleges régióban kimaradás miatt az összes vagy néhány elsődleges adatbázis elérhetetlenné válik. Feladatátvételi csoport létrehozása olyan geo-másodlagos adatbázisokat hoz létre, amelynek szolgáltatási célja megegyezik az elsődlegessel. Ha meglévő georeplikációs kapcsolatot ad hozzá egy feladatátvételi csoporthoz, győződjön meg arról, hogy a geo-másodlagos kiszolgáló ugyanazzal a szolgáltatási szinttel és számítási mérettel van konfigurálva, mint az elsődleges.

Az olvasási-írási figyelő használata (elsődleges)

Írható és olvasható számítási feladatok esetén a kapcsolati sztringben használja a következő kiszolgálónevet: <fog-name>.database.windows.net. A rendszer automatikusan átirányítja a kapcsolatokat az elsődleges kiszolgálóra. Ez a név nem változik a feladatátvétel után. Vegye figyelembe, hogy a feladatátvétel magában foglalja a DNS-rekord frissítését, így az ügyfélkapcsolatok csak az ügyfél DNS-gyorsítótárának frissítése után lesznek átirányítva az új elsődleges helyre. Az elsődleges és másodlagos figyelő DNS-rekordjának élettartama (TTL) 30 másodperc.

Írásvédett figyelő használata (másodlagos)

Ha logikailag elkülönített írásvédett számítási feladatokkal rendelkezik, amelyek tolerálják az adatkéséseket, futtathatja őket a földrajzilag másodlagos helyen. Írásvédett számítási feladatok esetén a kapcsolati sztringben használja a következő kiszolgálónevet: <fog-name>.secondary.database.windows.net. A kapcsolatok automatikusan a földrajzilag másodlagos helyre lesznek irányítva. Azt is javasoljuk, hogy az olvasási szándékot a kapcsolati sztring használjaApplicationIntent=ReadOnly.

A Prémium, a üzletileg kritikus és a rugalmas skálázású szolgáltatási szinteken a SQL Database támogatja a csak olvasható replikák használatát az írásvédett lekérdezési számítási feladatok kiszervezéséhez a ApplicationIntent=ReadOnly kapcsolati sztring paraméter használatával. Ha földrajzilag másodlagos replikát konfigurált, ezzel a képességgel csatlakozhat egy írásvédett replikához az elsődleges helyen vagy a georeplikált helyen:

  • A másodlagos helyen található írásvédett replikához való csatlakozáshoz használja ApplicationIntent=ReadOnly a és <fog-name>.secondary.database.windows.neta .

Lehetséges teljesítménycsökkenés a feladatátvétel után

Egy tipikus Azure-alkalmazás több Azure-szolgáltatást használ, és több összetevőből áll. A feladatátvételi csoport automatikus geo-feladatátvétele a Azure SQL összetevők állapota alapján aktiválódik. Előfordulhat, hogy az elsődleges régióban lévő többi Azure-szolgáltatást nem érinti a szolgáltatáskimaradás, és az összetevőik továbbra is elérhetők lehetnek az adott régióban. Miután az elsődleges adatbázisok a másodlagos (DR) régióra váltanak, a függő összetevők közötti késés növekedhet. A nagyobb késés alkalmazásteljesítményre gyakorolt hatásának elkerülése érdekében gondoskodjon az alkalmazás összes összetevőjének redundanciáról a vészhelyreállítási régióban, kövesse ezeket a hálózati biztonsági irányelveket, és vezényelje a releváns alkalmazás-összetevők geo-feladatátvételét az adatbázissal együtt.

Lehetséges adatvesztés feladatátvétel után

Ha az elsődleges régióban kimaradás lép fel, előfordulhat, hogy a legutóbbi tranzakciók nem replikálhatók a földrajzilag másodlagos régióba. Ha az automatikus feladatátvételi szabályzat konfigurálva van, a rendszer megvárja az automatikus geo-feladatátvétel kezdeményezése előtt megadott GracePeriodWithDataLossHours időtartamot. Az alapértelmezett érték 1 óra. Ez a folyamat az adatbázisok rendelkezésre állásának biztosítására törekszik az adatvesztés elkerülése helyett. Ha nagyobb számra,például 24 órára állítja GracePeriodWithDataLossHours , vagy letiltja az automatikus geo-feladatátvételt, az adatbázis rendelkezésre állása rovására csökkentheti az adatvesztés valószínűségét.

Fontos

A 800 vagy kevesebb DTU-val vagy 8 vagy kevesebb virtuális maggal rendelkező rugalmas készletek és a 250-nél több adatbázis problémákba ütközhet, beleértve a hosszabb tervezett geo-feladatátvételt és a csökkentett teljesítményt. Ezek a problémák nagyobb valószínűséggel fordulnak elő írásigényes számítási feladatok esetén, ha a georeplikákat földrajzilag széles körben választják el egymástól, vagy ha minden adatbázishoz több másodlagos georeplikát használnak. E problémák egyik tünete a georeplikációs késés növekedése az idő múlásával, ami kiterjedtebb adatvesztést okozhat egy szolgáltatáskimaradás során. Ez a késés a sys.dm_geo_replication_link_status használatával figyelhető. Ha ezek a problémák jelentkeznek, a kockázatcsökkentés magában foglalja a készlet vertikális felskálázását, hogy több DTU-val vagy virtuális magokkal rendelkezzen, vagy csökkentse a készletben lévő georeplikált adatbázisok számát.

Feladatátvételi csoportok és hálózati biztonság

Egyes alkalmazások esetében a biztonsági szabályok megkövetelik, hogy az adatréteghez való hálózati hozzáférés egy adott összetevőre vagy összetevőre, például virtuális gépre, webszolgáltatásra stb. korlátozódjon. Ez a követelmény kihívást jelent az üzletmenet-folytonossági tervezés és a feladatátvételi csoportok használata szempontjából. Az ilyen korlátozott hozzáférés megvalósításakor vegye figyelembe az alábbi lehetőségeket.

Feladatátvételi csoportok és virtuális hálózati szolgáltatásvégpontok használata

Ha Virtual Network szolgáltatásvégpontokat és szabályokat használ az adatbázishoz való hozzáférés korlátozására SQL Database, vegye figyelembe, hogy minden egyes virtuális hálózati szolgáltatásvégpont csak egy Azure-régióra vonatkozik. A végpont nem teszi lehetővé, hogy más régiók fogadják az alhálózatról érkező kommunikációt. Ezért csak az ugyanabban a régióban üzembe helyezett ügyfélalkalmazások csatlakozhatnak az elsődleges adatbázishoz. Mivel a geo-feladatátvétel eredményeként a SQL Database ügyfél-munkamenetek egy másik (másodlagos) régióban lévő kiszolgálóra lesznek átirányítva, ezek a munkamenetek meghiúsulnak, ha az adott régión kívüli ügyfélről származnak. Ezért az automatikus feladatátvételi szabályzat nem engedélyezhető, ha a részt vevő kiszolgálók vagy példányok szerepelnek a Virtual Network szabályokban. A manuális feladatátvétel támogatásához kövesse az alábbi lépéseket:

  1. Helyezze üzembe az alkalmazás előtér-összetevőinek redundáns másolatait (webszolgáltatás, virtuális gépek stb.) a másodlagos régióban.
  2. Konfigurálja egyenként a virtuális hálózati szabályokat az elsődleges és a másodlagos kiszolgálóhoz.
  3. Engedélyezze az előtérbeli feladatátvételt Traffic Manager-konfigurációval.
  4. A szolgáltatáskimaradás észlelésekor kezdeményezheti a manuális geo-feladatátvételt. Ez a beállítás olyan alkalmazásokhoz van optimalizálva, amelyek konzisztens késést igényelnek az előtér és az adatréteg között, és támogatják a helyreállítást, ha az előtérrendszert, az adatréteget vagy mindkettőt érinti a szolgáltatáskimaradás.

Megjegyzés

Ha írásvédett figyelőt használ egy írásvédett számítási feladat terheléselosztására, győződjön meg arról, hogy a számítási feladat egy virtuális gépen vagy más, a másodlagos régióban lévő erőforráson fut, hogy csatlakozni tudjon a másodlagos adatbázishoz.

Feladatátvételi csoportok és tűzfalszabályok használata

Ha az üzletmenet-folytonossági csomaghoz automatikus feladatátvételi csoportokat használó feladatátvételre van szükség, a nyilvános IP-tűzfalszabályok használatával korlátozhatja az adatbázishoz való hozzáférést SQL Database. Az automatikus feladatátvétel támogatásához kövesse az alábbi lépéseket:

  1. Hozzon létre egy nyilvános IP-címet.
  2. Hozzon létre egy nyilvános terheléselosztót , és rendelje hozzá a nyilvános IP-címet.
  3. Hozzon létre egy virtuális hálózatot és a virtuális gépeket az előtérbeli összetevőkhöz.
  4. Hozzon létre hálózati biztonsági csoportot , és konfigurálja a bejövő kapcsolatokat.
  5. Egy szolgáltatáscímke használatával Sql.<Region> győződjön meg arról, hogy a kimenő kapcsolatok nyitva vannak egy régióban Azure SQL Database számára.
  6. Hozzon létre egy SQL Database tűzfalszabályt, amely engedélyezi a bejövő forgalmat az 1. lépésben létrehozott nyilvános IP-címről.

A kimenő hozzáférés konfigurálásáról és a tűzfalszabályokban használandó IP-címről további információt a Terheléselosztó kimenő kapcsolataiban talál.

A fenti konfiguráció biztosítja, hogy az automatikus geo-feladatátvétel ne blokkolja az előtér-összetevők kapcsolatait, és feltételezi, hogy az alkalmazás képes elviselni az előtér és az adatréteg közötti hosszabb késést.

Fontos

Az üzletmenet folytonosságának biztosítása érdekében a regionális kimaradások során biztosítani kell a földrajzi redundanciát az előtér-összetevők és az adatbázisok számára is.

Elsődleges adatbázis skálázása

Az elsődleges adatbázist vertikálisan felskálázhatja vagy leskálázhatja egy másik számítási méretre (ugyanazon a szolgáltatási szinten belül), anélkül, hogy leválasztaná a georeplikációs kiszolgálókat. A vertikális felskálázás során azt javasoljuk, hogy először vertikálisan skálázza fel a földrajzilag másodlagosat, majd skálázza fel az elsődlegeset. Leskálázáskor fordítsa meg a sorrendet: először az elsődlegeset, majd a másodlagos skálázást. Amikor egy adatbázist egy másik szolgáltatási szintre skáláz, a rendszer kikényszeríti ezt a javaslatot.

Ezt a sorozatot kifejezetten azért javasoljuk, hogy elkerülje azt a problémát, amikor az alacsonyabb termékváltozatú geo-másodlagos rendszer túlterhelődik, és a frissítési vagy alacsonyabb szintű folyamat során újra kell vetíteni. A problémát úgy is elkerülheti, ha az elsődleges példányt írásvédetté teszi, de ez hatással lesz az összes írási és olvasási számítási feladatra az elsődleges példányon.

Megjegyzés

Ha a feladatátvételi csoport konfigurációjának részeként létrehozott egy geo-másodlagosat, nem ajánlott vertikálisan leskálázni a geo-másodlagos skálázást. Ez biztosítja, hogy az adatréteg elegendő kapacitással rendelkezzen a rendszeres számítási feladatok geo-feladatátvétel utáni feldolgozásához.

Kritikus adatok elvesztésének megakadályozása

A nagy kiterjedésű hálózatok nagy késése miatt a georeplikálás aszinkron replikációs mechanizmust használ. Az aszinkron replikáció az elsődleges meghibásodás esetén elkerülhetetlenné teszi az adatvesztés lehetőségét. A kritikus fontosságú tranzakciók adatvesztés elleni védelme érdekében az alkalmazásfejlesztők közvetlenül a tranzakció véglegesítése után meghívhatják a sp_wait_for_database_copy_sync tárolt eljárást. A hívás sp_wait_for_database_copy_sync addig blokkolja a hívó szálat, amíg az utolsó véglegesített tranzakciót át nem továbbítja és meg nem továbbítja a másodlagos adatbázis tranzakciónaplójában. Azonban nem várja meg, amíg a továbbított tranzakciók visszajátszanak (újra) a másodlagoson. sp_wait_for_database_copy_sync A hatóköre egy adott georeplikációs hivatkozásra vonatkozik. Ezt az eljárást bármely olyan felhasználó meghívhatja, aki rendelkezik az elsődleges adatbázishoz való kapcsolódási jogosultsággal.

Megjegyzés

sp_wait_for_database_copy_sync A megakadályozza az adatvesztést az adott tranzakciók geo-feladatátvétele után, de nem garantálja az olvasási hozzáférés teljes szinkronizálását. Az eljáráshívás által sp_wait_for_database_copy_sync okozott késés jelentős lehet, és a hívás időpontjában az elsődlegesen még nem továbbított tranzakciónapló méretétől függ.

Engedélyek

A feladatátvételi csoportok engedélyeit az Azure szerepköralapú hozzáférés-vezérlése (Azure RBAC) kezeli.

A feladatátvételi csoportok létrehozásához és kezeléséhez Azure RBAC írási hozzáférés szükséges. A SQL Server Közreműködő szerepkör rendelkezik a feladatátvételi csoportok kezeléséhez szükséges összes engedéllyel.

Adott engedélyhatókörökért tekintse át, hogyan konfigurálhatja az automatikus feladatátvételi csoportokat Azure SQL Database.

Korlátozások

Vegye figyelembe a következő korlátozásokat:

  • Feladatátvételi csoportok nem hozhatók létre két kiszolgáló között ugyanabban az Azure-régióban.
  • A feladatátvételi csoportok nem nevezhetők át. Törölnie kell a csoportot, és újra létre kell hoznia egy másik néven.
  • A feladatátvételi csoport adatbázisainak átnevezése nem támogatott. Az adatbázis átnevezéséhez vagy az adatbázis feladatátvételi csoportból való eltávolításához ideiglenesen törölnie kell a feladatátvételi csoportot.

Feladatátvételi csoportok programozott kezelése

Ahogy korábban említettem, az automatikus feladatátvételi csoportok programozott módon is kezelhetők az Azure PowerShell, az Azure CLI és a REST API használatával. Az alábbi táblázatok az elérhető parancsokat ismertetik. Az aktív georeplikálás azure Resource Manager API-kat tartalmaz a felügyelethez, beleértve a Azure SQL Database REST API-t és a Azure PowerShell parancsmagokat. Ezek az API-k erőforráscsoportok használatát igénylik, és támogatják az Azure szerepköralapú hozzáférés-vezérlését (Azure RBAC). További információ a hozzáférési szerepkörök implementálásáról: Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC).

Parancsmag Leírás
New-AzSqlDatabaseFailoverGroup Ez a parancs létrehoz egy feladatátvételi csoportot, és regisztrálja azt az elsődleges és másodlagos kiszolgálókon is
Remove-AzSqlDatabaseFailoverGroup Feladatátvételi csoport eltávolítása a kiszolgálóról
Get-AzSqlDatabaseFailoverGroup Lekéri egy feladatátvételi csoport konfigurációját
Set-AzSqlDatabaseFailoverGroup Módosítja egy feladatátvételi csoport konfigurációját
Switch-AzSqlDatabaseFailoverGroup Elindítja egy feladatátvételi csoport feladatátvételét a másodlagos kiszolgálóra
Add-AzSqlDatabaseToFailoverGroup Egy vagy több adatbázis hozzáadása feladatátvételi csoporthoz

Következő lépések