Georedundancia használata magas rendelkezésre állású alkalmazások tervezéséhez

2025-04-09

Az Azure Storage-hoz hasonló felhőalapú infrastruktúrák magas rendelkezésre állású és tartós platformot biztosítanak az adatok és alkalmazások üzemeltetéséhez. A felhőalapú alkalmazások fejlesztőinek alaposan meg kell fontolniuk, hogyan használhatják ezt a platformot, hogy maximalizálják a felhasználóik számára elérhető előnyöket. Az Azure Storage georedundáns lehetőségeket kínál a magas rendelkezésre állás biztosításához még regionális kimaradás esetén is. A georedundáns replikációhoz konfigurált tárfiókok szinkron módon replikálódnak az elsődleges régióban, és aszinkron módon replikálódnak egy több száz kilométerre lévő másodlagos régióba.

Az Azure Storage két lehetőséget kínál a georedundáns replikációhoz: a georedundáns tárolást (GRS) és a georedundáns tárolást (GZRS). Az Azure Storage georedundanciás lehetőségeinek kihasználásához győződjön meg arról, hogy a tárfiók csak olvasható georedundáns tárolásra (RA-GRS) vagy csak olvasható geozóna-redundáns tárolásra (RA-GZRS) van konfigurálva. Ha nem, többet is megtudhat a tárfiók replikációs típusának módosításáról.

Ez a cikk bemutatja, hogyan tervezhet olyan alkalmazást, amely továbbra is működni fog, bár korlátozott kapacitással, még akkor is, ha jelentős kimaradás van az elsődleges régióban. Ha az elsődleges régió elérhetetlenné válik, az alkalmazás zökkenőmentesen válthat, hogy olvasási műveleteket hajtson végre a másodlagos régión, amíg az elsődleges régió újra nem válaszol.

Alkalmazástervezési szempontok

Az alkalmazást úgy tervezheti meg, hogy kezelje az átmeneti hibákat vagy a jelentős kimaradásokat a másodlagos régióból való olvasással, ha olyan probléma merül fel, amely zavarja az elsődleges régióból történő olvasást. Ha az elsődleges régió ismét elérhető, az alkalmazás visszatérhet az elsődleges régióból történő olvasáshoz.

Tartsa szem előtt ezeket a legfontosabb szempontokat az alkalmazás rendelkezésre állása és rugalmassága RA-GRS vagy RA-GZRS használatával történő tervezésekor:

Az elsődleges régióban tárolt adatok írásvédett másolatát a rendszer aszinkron módon replikálja egy másodlagos régióban. Ez az aszinkron replikáció azt jelenti, hogy a másodlagos régió írásvédett példánya végül megegyezik az elsődleges régió adataival. A tárolási szolgáltatás határozza meg a másodlagos régió helyét.
Az Azure Storage-ügyfélkódtárak használatával olvasási és frissítési kéréseket hajthat végre az elsődleges régió végpontja felé. Ha az elsődleges régió nem érhető el, automatikusan átirányíthatja az olvasási kérelmeket a másodlagos régióba. Beállíthatja azt is, hogy az alkalmazás olvasási kéréseket küldjön közvetlenül a másodlagos régióba, ha szükséges, még akkor is, ha az elsődleges régió elérhető.
Ha az elsődleges régió elérhetetlenné válik, kezdeményezheti a fiók átvételét. A másodlagos régióba történő feladatátvételkor az elsődleges régióra mutató DNS-bejegyzések a másodlagos régióra lesznek módosítva. A feladatátvétel befejezése után a rendszer visszaállítja az írási hozzáférést a GRS- és RA-GRS-fiókokhoz. További információkért lásd: Vészhelyreállítás és tárfiók feladatátvétele.

Végül konzisztens adatok használata

A javasolt megoldás feltételezi, hogy elfogadható, ha potenciálisan elavult adatokat ad vissza a hívó alkalmazásnak. Mivel a másodlagos régió adatai végül konzisztensek, lehetséges, hogy az elsődleges régió elérhetetlenné válik, mielőtt a másodlagos régió frissítése befejeződött volna a replikálásban.

Tegyük fel például, hogy az ügyfél sikeresen elküldi a frissítést, de az elsődleges régió meghiúsul, mielőtt a frissítés propagálása a másodlagos régióba történik. Amikor az ügyfél kéri az adatok visszaolvasását, a frissített adatok helyett a másodlagos régióból kapja meg az elavult adatokat. Az alkalmazás tervezésekor el kell döntenie, hogy ez a viselkedés elfogadható-e. Ha igen, akkor azt is meg kell fontolnia, hogyan értesítheti a felhasználót.

A cikk későbbi részében többet is megtudhat a végleges konzisztens adatok kezeléséről , valamint arról, hogyan ellenőrizheti az Utolsó szinkronizálási idő tulajdonságot az elsődleges és a másodlagos régiók adatai közötti eltérések kiértékeléséhez.

Szolgáltatások kezelése külön-külön vagy együttesen

Bár nem valószínű, hogy egy szolgáltatás (blobok, üzenetsorok, táblák vagy fájlok) elérhetetlenné válik, míg a többi szolgáltatás továbbra is teljesen működőképes. Az egyes szolgáltatások újrapróbálkozásai külön-külön kezelhetők, vagy az újrapróbálkozásokat általánosan is kezelheti az összes tárolási szolgáltatás esetében együtt.

Ha például üzenetsorokat és blobokat használ az alkalmazásban, dönthet úgy, hogy külön kódot ad az egyes szolgáltatások újrapróbálkozó hibáinak kezeléséhez. Így a blobszolgáltatás hibája csak az alkalmazás blobokkal foglalkozó részét érinti, így az üzenetsorok továbbra is a szokásos módon futnak. Ha azonban úgy dönt, hogy az összes tárolási szolgáltatás újrapróbálkozásait együtt kezeli, akkor a blob- és üzenetsor-szolgáltatásokhoz érkező kérések is hatással lesznek, ha bármelyik szolgáltatás újrapróbálkozható hibát ad vissza.

Végső soron ez a döntés az alkalmazás összetettségétől függ. Előfordulhat, hogy az újrapróbálkozások hatásának korlátozása érdekében inkább szolgáltatásonként szeretné kezelni a hibákat. Vagy úgy is dönthet, hogy az összes tárolási szolgáltatás olvasási kéréseit átirányítja a másodlagos régióba, amikor problémát észlel az elsődleges régióban található bármely tárolási szolgáltatással kapcsolatban.

Az alkalmazás futtatása írásvédett módban

Ahhoz, hogy az elsődleges régióban hatékonyan felkészülhessen a leállásokra, az alkalmazásnak képesnek kell lennie a sikertelen olvasási és a sikertelen frissítési kérelmek kezelésére. Ha az elsődleges régió meghiúsul, az olvasási kérelmek átirányíthatók a másodlagos régióba. A frissítési kérelmek azonban nem irányíthatók át, mert a másodlagos régióban a replikált adatok csak olvashatók. Ezért úgy kell megterveznie az alkalmazást, hogy képes legyen írásvédett módban futni.

Beállíthat például egy jelölőt, amelyet a rendszer ellenőriz, mielőtt a frissítési kérelmeket elküldené az Azure Storage-ba. Amikor egy frissítési kérelem érkezik, kihagyhatja a kérést, és megfelelő választ adhat vissza a felhasználónak. Akár úgy is dönthet, hogy teljesen letilt bizonyos funkciókat a probléma megoldásáig, és értesíti a felhasználókat arról, hogy a funkciók átmenetileg nem érhetők el.

Ha úgy dönt, hogy az egyes szolgáltatások hibáit külön kezeli, akkor azt is biztosítania kell, hogy az alkalmazás írásvédett módban tudjon futni az egyes szolgáltatások szerint. Beállíthatja például a csak olvasható jelzőket az egyes szolgáltatásokhoz. Ezután szükség szerint engedélyezheti vagy letilthatja a kódban lévő jelzőket.

Ha az alkalmazást írásvédett módban tudja futtatni, az is lehetővé teszi, hogy korlátozott funkcionalitást biztosítson egy nagyobb alkalmazásfrissítés során. Aktiválhatja az alkalmazást, hogy írásvédett módban fusson, és a másodlagos adatközpontra mutasson, biztosítva, hogy a frissítések végrehajtása közben senki ne férhessen hozzá az elsődleges régió adataihoz.

Frissítések kezelése, amikor az eszköz írásvédett módban fut.

Az update kéréseket többféleképpen lehet kezelni, amikor olvasási módban fut a program. Ez a szakasz néhány megfontolandó általános mintát mutat be.

Válaszolhat a felhasználónak, és értesítheti őket arról, hogy a frissítési kérelmek feldolgozása jelenleg nem történik meg. Egy kapcsolatkezelő rendszer például lehetővé teheti, hogy a felhasználók hozzáférjenek a kapcsolattartási adatokhoz, de ne végezzenek frissítéseket.
A frissítéseket egy másik régióban is leküldheti. Ebben az esetben a függőben lévő frissítési kérelmeket egy másik régióban lévő üzenetsorba írná, majd feldolgozná ezeket a kéréseket, miután az elsődleges adatközpont újra online állapotba kerül. Ebben a forgatókönyvben tudatnia kell a felhasználóval, hogy a frissítési kérelem várólistára kerül a későbbi feldolgozáshoz.
A frissítéseket egy másik régióban lévő tárfiókba is megírhatja. Amikor az elsődleges régió újra online állapotba kerül, az adatok szerkezetétől függően egyesítheti ezeket a frissítéseket az elsődleges adatokkal. Ha például külön fájlokat hoz létre egy dátum-/időbélyeggel a névben, ezeket a fájlokat visszamásolhatja az elsődleges régióba. Ez a megoldás olyan számítási feladatokra alkalmazható, mint a naplózás és az IoT-adatok.

Újrapróbálkozések kezelése

A felhőben futó szolgáltatásokkal kommunikáló alkalmazásoknak érzékenynek kell lenniük a nem tervezett eseményekre és hibákra, amelyek előfordulhatnak. Ezek a hibák átmenetiek vagy tartósak lehetnek, kezdve a természeti katasztrófa miatti jelentős kimaradás pillanatnyi megszakadásától. Fontos, hogy a rendelkezésre állás maximalizálása és az alkalmazások általános stabilitásának javítása érdekében megfelelő újrapróbálkozással tervezzen felhőalkalmazásokat.

Kérelmek megtekintése

Ha az elsődleges régió elérhetetlenné válik, az olvasási kérelmek átirányíthatók a másodlagos tárolóba. Ahogy korábban említettük, az alkalmazás számára elfogadhatónak kell lennie az elavult adatok olvasásához. Az Azure Storage-ügyfélkódtár lehetőséget kínál az újrapróbálkozások kezelésére és az olvasási kérelmek másodlagos régióba való átirányítására.

Ebben a példában a Blob Storage újrapróbálkozása az osztályban BlobClientOptions van konfigurálva, és a BlobServiceClient konfigurációs beállítások használatával létrehozott objektumra lesz alkalmazva. Ez a konfiguráció egy elsődleges, majd másodlagos megközelítés, ahol az olvasási kérések újrapróbálkoznak az elsődleges régióból a másodlagos régióba. Ez a módszer akkor a legjobb, ha az elsődleges régióban a hibák várhatóan ideiglenesek lesznek.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob storage
BlobClientOptions blobClientOptions = new BlobClientOptions()
{
    Retry = {
        // The delay between retry attempts for a fixed approach or the delay
        // on which to base calculations for a backoff-based approach
        Delay = TimeSpan.FromSeconds(2),

        // The maximum number of retry attempts before giving up
        MaxRetries = 5,

        // The approach to use for calculating retry delays
        Mode = RetryMode.Exponential,

        // The maximum permissible delay between retry attempts
        MaxDelay = TimeSpan.FromSeconds(10)
    },

    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for 
    // GET or HEAD requests during retries.
    // If the status of the response from the secondary Uri is a 404, then subsequent retries
    // for the request will not use the secondary Uri again, as this indicates that the resource 
    // may not have propagated there yet.
    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
    GeoRedundantSecondaryUri = secondaryAccountUri
};

// Create a BlobServiceClient object using the configuration options above
BlobServiceClient blobServiceClient = new BlobServiceClient(primaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

Ha megállapítja, hogy az elsődleges régió valószínűleg hosszú ideig nem érhető el, konfigurálhatja az összes olvasási kérést úgy, hogy a másodlagos régióra mutasson. Ez a konfiguráció csak másodlagos megközelítés. Ahogy korábban már említettem, szüksége lesz egy stratégiára a frissítési kérelmek kezeléséhez ez idő alatt, és egy olyan módszerre, amellyel tájékoztathatja a felhasználókat arról, hogy csak olvasási kérések feldolgozása folyamatban van. Ebben a példában létrehozunk egy új példányt, amely a másodlagos régió végpontját BlobServiceClient használja.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Create a BlobServiceClient object pointed at the secondary Uri
// Use blobServiceClientSecondary only when issuing read requests, as secondary storage is read-only
BlobServiceClient blobServiceClientSecondary = new BlobServiceClient(secondaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

Annak ismerete, hogy mikor váltson írásvédett módra és csak másodlagos kérelmekre, egy architekturális tervezési mintának, az áramkör-megszakító mintának része, amely későbbi szakaszban lesz tárgyalva.

Kérelmek frissítése

A frissítési kérelmek nem irányíthatók át másodlagos tárolóba, amely írásvédett. A korábban leírtaknak megfelelően az alkalmazásnak képesnek kell lennie a frissítési kérelmek kezelésére , ha az elsődleges régió nem érhető el.

Az áramkör-megszakító minta a frissítési kérelmekre is alkalmazható. A frissítési kérelmek hibáinak kezeléséhez beállíthat egy küszöbértéket a kódban, például 10 egymást követő hibát, és nyomon követheti az elsődleges régióba irányuló kérések hibáinak számát. A küszöbérték elérése után az alkalmazás átkapcsolhat olvasási módba, hogy ne kerüljön sor frissítési kérelmekre az elsődleges régió számára.

Az áramkör-megszakító minta implementálása

Az olyan hibák kezelése, amelyekből a helyreállítás változó mennyiségű időt vehet igénybe, az úgynevezett Áramkör-megszakító minta nevű architektúrális tervezési minta része. Ennek a mintának a megfelelő megvalósítása megakadályozhatja, hogy egy alkalmazás ismétlődően megkíséreljen végrehajtani egy valószínűleg sikertelen műveletet, ezáltal javítva az alkalmazás stabilitását és rugalmasságát.

Az áramkör-megszakító minta egyik aspektusa az elsődleges végponttal kapcsolatos folyamatos probléma azonosítása. Ennek meghatározásához monitorozhatja, hogy az ügyfél milyen gyakran találkozik újrapróbálkozható hibával. Mivel mindegyik forgatókönyv eltérő, meg kell határoznia egy megfelelő küszöbértéket, amelyet a másodlagos végpontra való váltáshoz és az alkalmazás írásvédett módban való futtatásához kell használni.

Dönthet például úgy, hogy végrehajt egy váltást, ha 10 egymást követő meghibásodás történik az elsődleges régióban. Ezt nyomon követheti a kódban található hibák számának megadásával. Ha a küszöbérték elérése előtt sikeres a művelet, állítsa vissza a számot nullára. Ha a szám eléri a küszöbértéket, váltson az alkalmazásra, hogy a másodlagos régiót használja az olvasási kérelmekhez.

Alternatív megközelítésként dönthet úgy, hogy egyéni monitorozási összetevőt implementál az alkalmazásban. Ez az összetevő folyamatosan pingelheti az elsődleges tárolási végpontot triviális olvasási kérésekkel (például egy kis blob olvasásával) az állapotának meghatározásához. Ez a megközelítés némi erőforrást igényelne, de nem jelentős összeget. Ha olyan probléma adódik, amely eléri a küszöbértéket, akkor a másodlagos olvasáskérésekre és a csak olvasható módra vált. Ebben a forgatókönyvben, amikor az elsődleges tárvégpont pingelése ismét sikeres lesz, visszaállhat az elsődleges régióra, és folytathatja a frissítések engedélyezését.

A váltás időpontjának meghatározásához használt hibaküszöb szolgáltatásonként eltérő lehet az alkalmazásban, ezért érdemes megfontolni a konfigurálható paraméterek beállítását.

Egy másik szempont az alkalmazás több példányának kezelése, és mi a teendő, ha újrapróbálkozható hibákat észlel az egyes példányokban. Előfordulhat például, hogy 20 virtuális gép fut ugyanazzal az alkalmazással. Külön kezeli az egyes eseteket? Ha egy példány problémákba ütközik, csak arra az egy példányra szeretné korlátozni a választ? Vagy azt szeretné, hogy az összes példány ugyanúgy válaszoljon, ha egy példány problémája van? A példányok külön kezelése sokkal egyszerűbb, mint a válasz egymás közötti koordinálása, de a megközelítés az alkalmazás architektúrájától függ.

Végül konzisztens adatok kezelése

A georedundáns tárolás az elsődleges régióból a másodlagos régióba történő tranzakciók replikálásával működik. A replikációs folyamat biztosítja, hogy a másodlagos régió adatai végül konzisztensek legyenek. Ez azt jelenti, hogy az elsődleges régióban lévő összes tranzakció végül megjelenik a másodlagos régióban, de előfordulhat, hogy a megjelenésük előtt késés következik be. Azt sem garantálja, hogy a tranzakciók a másodlagos régióba érkeznek az eredetileg az elsődleges régióban alkalmazott sorrendben. Ha a tranzakciók sorrenden kívül érkeznek a másodlagos régióba, úgy tekintheti, hogy a másodlagos régióban lévő adatok inkonzisztens állapotban lesznek, amíg a szolgáltatás fel nem ér.

Az Azure Table Storage következő példája bemutatja, mi történhet, ha egy alkalmazott adatait frissítve rendszergazdai szerepkörrel szeretné őket taggá tenni. A példa kedvéért ehhez frissítenie kell a alkalmazotti entitást, és frissítenie kell egy rendszergazdai szerepkört entitást a rendszergazdák teljes számával. Figyelje meg, hogyan alkalmazzák a frissítéseket sorrenden kívül a másodlagos régióban.

idő	tranzakciós	Replikáció	legutóbbi szinkronizálási idő	Eredmény
T0	Tranzakció A: Alkalmazott beszúrása entitás az elsődlegesben			A tranzakció A az elsődlegesbe lett beszúrva. még nem replikálták.
T1		A tranzakció A replikálva másodlagos	T1	Az A tranzakció replikálva lett a másodlagosra. Legutóbbi szinkronizálási idő frissítve.
T2	Tranzakció B: Frissítés alkalmazotti entitás elsődlegesen		T1	"B" tranzakció elsődlegesnek írva, még nem replikálták.
T3	Tranzakció C: Frissít ügyintéző szerepkör-entitás a következőben: elsődleges		T1	A C tranzakció az elsődlegesre lett írva. még nem replikálták.
T4		Tranzakció C replikálva másodlagos	T1	A C tranzakció a másodlagos rendszerre lett másolva. A LastSyncTime nem frissült, mert A B tranzakciót még nem replikálták.
T5	Entitások olvasása másodlagosból		T1	Az alkalmazott régi értékét kapja meg. entitás, mert a B tranzakció még nem történt meg. még nem replikálták. Megkapja az új értéket a következőhöz: rendszergazdai szerepkör-entitás, mert C Lemásoltak. Az utolsó szinkronizálási időpont még mindig nem történt meg. B tranzakció miatt frissítve lett. nem ismétlődött meg Megmondhatja a a rendszergazdai szerepkör entitása inkonzisztens mert az entitás dátuma/ideje a következő: az utolsó szinkronizálási időpont.
T6		Tranzakció B replikálva másodlagos	T6	T6 – A C-n keresztüli összes tranzakció replikálva, utolsó szinkronizálás ideje frissítésre kerül.

Ebben a példában tegyük fel, hogy az ügyfél a T5 időpontban kezd olvasni a másodlagos régióból. Jelenleg sikeresen beolvassa a rendszergazdai szerepkör entitást, de az entitás olyan értéket tartalmaz a rendszergazdák számához, amelyek nem összhangban vannak a másodlagos régióban rendszergazdaként megjelölt alkalmazotti entitások számával. Az ügyfél megjelenítheti ezt az értéket, azzal a kockázattal, hogy az információk inkonzisztensek. Másik lehetőségként az ügyfél megpróbálhatja megállapítani, hogy a rendszergazdai szerepkör valószínűleg inkonzisztens állapotban van, mert a frissítések sorrenden kívül történtek, majd erről a tényről tájékoztatja a felhasználót.

Annak megállapításához, hogy egy tárfiók esetleg inkonzisztens adatokkal rendelkezik-e, az ügyfél ellenőrizheti az Utolsó szinkronizálási idő tulajdonság értékét. A legutóbbi szinkronizálási idő azt az időpontot jelzi, amikor a másodlagos régió adatai utoljára konzisztensek voltak, és azt, hogy a szolgáltatás mikor alkalmazta az adott időpont előtti összes tranzakciót. A fenti példában, miután a szolgáltatás beszúrta a alkalmazotti entitást a másodlagos régióba, az utolsó szinkronizálási idő T1lesz. A T1-nél marad, amíg a szolgáltatás nem frissíti az alkalmazotti entitást a másodlagos régióban, amikor az T6 értékre van állítva. Ha az ügyfél lekéri az utolsó szinkronizálási időt, amikor beolvassa az entitást T5, összehasonlíthatja az entitás időbélyegével. Ha az entitás időbélyege későbbi, mint az utolsó szinkronizálási idő, akkor az entitás potenciálisan inkonzisztens állapotban van, és megteheti a megfelelő lépést. A mező használatához tudnia kell, hogy mikor fejeződött be az elsődleges frissítés utolsó frissítése.

Az utolsó szinkronizálási idő ellenőrzéséről az Tárfiók utolsó szinkronizálási idejének ellenőrzésecímű témakörben olvashat.

Tesztelés

Fontos tesztelni, hogy az alkalmazás a várt módon viselkedik-e, amikor újrapróbálkozható hibákba ütközik. Például tesztelnie kell, hogy az alkalmazás a probléma észlelésekor a másodlagos régióra vált-e, majd az alkalmazás visszavált, amikor a primer régió ismét elérhetővé válik. A viselkedés megfelelő teszteléséhez módot kell adnia az újrapróbálkozható hibák szimulálására és azok gyakoriságának szabályozására.

Az egyik lehetőség a Fiddler használata a HTTP-válaszok elfogására és módosítására egy szkriptben. Ez a szkript azonosítja az elsődleges végponttól érkező válaszokat, és a HTTP-állapotkódot olyanra módosítja, amelyet a Storage-ügyfélkódtár újrapróbálkozó hibaként ismer fel. Ez a kódrészlet egy egyszerű Fiddler-szkriptet mutat be, amely elfogja a employeedata táblára érkező olvasási kérelmekre adott válaszokat az 502-s állapot visszaadásához:

static function OnBeforeResponse(oSession: Session) {
    ...
    if ((oSession.hostname == "\[YOURSTORAGEACCOUNTNAME\].table.core.windows.net")
      && (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
        oSession.responseCode = 502;
    }
}

Ezt a példát kiterjesztheti arra, hogy a kérések szélesebb körét elfogja, és csak néhányuknál módosítsa a responseCode kódot, hogy jobban szimuláljon egy valós forgatókönyvet. További információ a Fiddler-szkriptek testreszabásáról: Kérelem vagy válasz módosítása a Fiddler dokumentációjában.

Ha konfigurálható küszöbértékeket állított be az alkalmazás írásvédettre állításához, egyszerűbb lesz annak viselkedését tesztelni teszt tranzakciók mennyiségeivel.

Következő lépések

Az elsődleges és másodlagos végpontok közötti váltás részletes bemutatásához lásd: Azure-minták – A Circuit Breaker minta használata a RA-GRS tárolóval.