Mik azok a redundancia, replikáció és biztonsági mentés?

Gyakran úgy gondolunk a felhőre, mint globálisan elosztott, mindenütt jelen lévő rendszerre. A valóságban azonban a felhő adatközpontokban futó hardverből áll. A rugalmasság megköveteli, hogy figyelembe kell vennie a felhőben üzemeltetett összetevők futtatásának fizikai helyeivel kapcsolatos kockázatokat.

Ez a cikk általános bevezetést nyújt a redundancia, a replikáció és a biztonsági mentés használatába, amelyek olyan számítási feladatok létrehozására szolgálnak, amelyek rugalmasak a szolgáltatáskimaradást, kimaradásokat vagy adatvesztést okozó fizikai kockázatokkal szemben.

A redundancia a szolgáltatásösszetevő több azonos példányának fenntartására és a másolatok oly módon való használatára alkalmas, hogy megakadályozza, hogy egy összetevő egyetlen meghibásodási ponttá váljon.

A replikáció vagy az adatredundancia több adatmásolat, más néven replika fenntartásának képessége.

A biztonsági mentés lehetővé teszi az adatok időbélyegzett másolatának megőrzését, amely az elveszett adatok visszaállítására használható.

Megbízhatósági szempontból a számos kockázat mérséklésének egyik fontos módja, ha valamilyen redundanciát, replikációt vagy biztonsági mentést is belefoglal az üzletmenet-folytonossági tervezésbe.

Megjegyzés:

Ez a cikk nem nyújt tervezési útmutatást vagy részletes információkat az egyes Azure szolgáltatásokról. Az egyes Azure-szolgáltatások megbízhatósági szempontból való működéséről a szolgáltatások megbízhatósági útmutatóját tekintheti meg.

Redundancy

A redundancia egy összetevő több példányának üzembe helyezéséből áll. Bár a redundancia érthető, bizonyos helyzetekben bonyolulttá válhat a megvalósítás.

A redundancia megismerése során a legegyszerűbb megfontolni a redundanciát az állapot nélküli összetevőkkel kapcsolatban, amelyek olyan összetevők, amelyek nem tárolnak adatokat. Bár a legtöbb valós megoldáshoz szükség van állapotkezelésre, ebben a szakaszban egy példa állapot nélküli alkalmazásprogramozási felület (API) tekintetében tárgyaljuk a redundanciát. A példa API fogadja a bemenetet, működik ezen a bemeneten, majd visszaad egy kimenetet anélkül, hogy adatokat tárolná. A következő, Replikáció: Adatredundancia című szakaszban figyelembe vesszük az állapotalapú redundancia szempontjait.

Forgatókönyv: Állapot nélküli redundancia

Ebben a példában egy állapot nélküli API-összetevő van üzembe helyezve egy virtuális gépen. Az API-összetevő állásidejének elkerülése érdekében, ha hardverhiba történik a fizikai gazdagépen, a példa egy redundáns megoldást implementál, amely:

  • Az API-példány több példányát helyezi üzembe.
  • Egy terheléselosztót implementál a kérések API-példányok közötti elosztásához.

Egy összetevő három példányát ábrázoló diagram egy terheléselosztóval, amely elosztja közöttük a forgalmat.

A terheléselosztó figyeli az egyes példányok állapotát, hogy csak kifogástalan állapotú példányoknak küldjön kéréseket.

Egy összetevő három példányát ábrázoló diagram, amelyek közül az egyik sikertelen volt, míg a fennmaradó kettő továbbra is működik.

Redundanciával kapcsolatos meggondolások

Redundáns megoldások megvalósításakor, például a fenti forgatókönyvben, fontos figyelembe venni a következőket:

  • Erőforrásköltségek. A redundancia definíció szerint magában foglalja, hogy több példánya van valaminek, ami növeli a megoldás üzemeltetésének teljes költségét.

  • Teljesítmény. Minél szélesebb a földrajzi terület, ahol elosztja a dolgok másolatait, annál több kockázattal jár a probléma mérséklése. Az ügyfelektől érkező kérések azonban hosszabb ideig is tarthatnak, mivel több hálózati infrastruktúrát kell átjárniuk, és ez növeli a hálózati késést.

    A legtöbb valós helyzetben a hálózati késés elhanyagolható rövid távolságok esetén, mint például egy adatközponton belül, vagy akár városon belüli adatközpontok között is. Ha azonban nagy távolságra osztja el a másolatokat, akkor a hálózati késés jelentősebbé válhat.

  • A példányok konzisztenciája. Fontos, hogy a példányok egymással konzisztensek maradjanak, és ne konfigurálja egyenként a példányokat, mert véletlenül eltéréseket tapasztalhat a példányok között. Ha vannak különbségek a példányok között, akkor a kérelmek feldolgozása eltérő lehet attól függően, hogy melyik példány szolgálja ki őket. Ez megnehezítheti a hibák és viselkedések diagnosztizálását.

  • A munka eloszlása. Ha egy összetevő több példányával rendelkezik, el kell osztania közöttük a munkát. Előfordulhat, hogy az összes példányon egyformán elosztja a munkát, vagy egyetlen elsődleges példánynak küldhet kéréseket, és csak másodlagos példányt használhat, ha az elsődleges példány nem érhető el.

    A bejövő kéréseket fogadó összetevők esetében a terheléselosztókat gyakran használják a kérések példányoknak való elküldésére. Előfordulhat azonban, hogy az összetevők egymástól függetlenül működnek, és nem kapnak kéréseket az ügyfelektől, így ezekben az esetekben előfordulhat, hogy a példányoknak össze kell hangolniuk a munkájukat egymással.

  • Állapotfigyelés. Az egyes példányok állapota határozza meg, hogy az adott példány képes-e a munkájára, és az állapotfigyelés fontos a gyors helyreállítás engedélyezéséhez, ha probléma merül fel.

    A terheléselosztók általában állapotfigyelést végeznek. A terheléselosztót nem tartalmazó összetevők esetében előfordulhat, hogy rendelkezik egy külső összetevővel, amely az összes példány állapotát figyeli, vagy az egyes példányok figyelhetik a többi példány állapotát.

Fizikai helyek a felhőben

A redundancia szükségessége egyértelmű, ha tisztában van azzal, hogy egy példány vagy adat egy adott fizikai helyen van tárolva még felhőkörnyezetben is.

Például:

  • A virtuális gépek egyszerre egyetlen fizikai helyen futnak.
  • Az adatok tárolása meghatározott fizikai helyen történik, például egy SSD-meghajtón vagy a kiszolgálókhoz csatlakoztatott merevlemezen.

Még akkor is, ha egy összetevő egy adatrészének vagy példányainak több példánya is van, minden másolat a fizikai hardverhez van kötve, amelyen tárolva van.

A felhőkörnyezet teljes fizikai helye fizikai hatókörökbe rendezhető. Minden fizikai hatókörben fennállnak olyan potenciális kockázatok, amelyek veszélyeztethetik az adott hatókörben lévő összetevőket vagy adatokat. Íme egy nem teljes listakockázat, amely a fizikai hatókör szempontjából határozható meg:

Fizikai hatókör Lehetséges kockázat
Egy adott hardver, például lemez vagy kiszolgáló Hardverhiba
Állvány egy adatközpontban A rackfelső hálózati kapcsoló üzemkimaradása
Adatközpont Az épület hűtőrendszerével kapcsolatos probléma
Azure-ben az adatközpontok egy csoportját elérhetőségi zónának nevezik. Városszintű elektromos vihar
Az adatközpont tágabb földrajzi területe, például egy város, amely egy Azure régió Széles körben elterjedt természeti katasztrófa

Megbízhatósági szempontból a fizikai hatókörökkel járó kockázatok csökkentésének fontos módja az összetevők példányainak különböző fizikai hatókörök közötti elterjesztése. Azure beépített redundanciával rendelkező szolgáltatások az alábbi három módszer közül egyet vagy többet kínálhatnak a redundáns példányok üzembe helyezésére:

  • A helyi redundancia olyan példányokat helyez el egyetlen Azure adatközpont több részén, amelyek védelmet nyújtanak az egy példányt érintő hardverhibákkal szemben. A helyi redundancia általában a legalacsonyabb költséget és késést biztosítja. Az adatközpont meghibásodása azonban azt jelentheti, hogy az összes példány nem érhető el.

  • A zónaredundancia egy Azure régióban elosztja a példányokat több rendelkezésre állási zónában. A zónaredundancia a hardverhibák mellett az adatközpontok hibáival szemben is védelmet nyújt.

  • Geo-redundancia több Azure régióban helyezi el a példányokat, és védelmet nyújt a nagy méretű regionális kimaradások ellen. A georedundancia magasabb költséggel jár, és figyelembe kell vennie a szélesebb körű megoldás kialakítását, valamint azt, hogy hogyan válthat az egyes régiókban található összetevők példányai között. Figyelembe kell vennie a szinkron és aszinkron replikációban leírt késést is.

A redundancia működése a Azure: Számítási szolgáltatások

A redundanciát a Azure szinte minden részén alkalmazzák. Példaként, hogy Azure hogyan valósítja meg a redundanciát, vegye figyelembe a számítási számítási feladatokat futtató szolgáltatásokat.

Azure egy önálló virtuális gép (VM) egyetlen fizikai kiszolgálón fut egy Azure adatközpontban. Útmutatást adhat az Azure számára annak érdekében, hogy a virtuális gép a várt helyen fusson, mint például a régióban vagy a rendelkezésre állási zónában, és bizonyos helyzetekben érdemes lehet elhelyezni egy Önnek dedikált gazdagépen.

Gyakori, hogy egy virtuális gép több példányát is futtatja. Ebben a forgatókönyvben dönthet úgy, hogy egyenként kezeli őket, vagy használhat egy virtuális gép skálakészletet. Méretezési csoport használata esetén továbbra is láthatja az azt alátámasztó egyes virtuális gépeket, de a méretezési csoport számos képességet biztosít a redundáns virtuális gépek kezeléséhez. Ezek a képességek magukban foglalják a virtuális gépek automatikus elhelyezését a megadott szabályok alapján, például a régión vagy a rendelkezésre állási zónán belüli tartalék tartományok közötti szétosztással.

Számos más Azure számítási szolgáltatás támaszkodik a virtuális gépekre a számítási feladatok elvégzéséhez. A számítási szolgáltatások általában különböző redundanciabeállításokat kínálnak, amelyek meghatározzák a virtuális gépek elosztásának módját. Előfordulhat például, hogy egy szolgáltatás zónaredundancia-beállítást biztosít, amellyel automatikusan eloszthatja a virtuális gépeket a rendelkezésre állási zónák között, és konfigurálhatja a terheléselosztást.

Replikáció: Adatredundancia

Az állapotra (adatokra) alkalmazott redundanciát replikációnak nevezzük. A replikációval több valós idejű vagy közel valós idejű másolatot is tarthat fenn élő adatokról, más néven replikákról. A kockázatokkal szembeni rugalmasság javítása érdekében a replikákat különböző helyeken terjesztheti. Ha egy replika elérhetetlenné válik, a rendszer feladatátvételt is végrehajthat, hogy egy másik replika átvehesse a funkcióját.

A replikációnak különböző típusai vannak, és mindegyik különböző prioritásokat helyez el az adatkonzisztencián, a teljesítményen és a költségeken. Az egyes replikációs típusok az üzletmenet-folytonosság megvitatása során használt két fő metrikát érintik: a helyreállítási időkorlátot (RTO), amely a vészforgatókönyvekben elviselhető állásidő maximális mennyisége, és a helyreállítási pont célkitűzése (RPO), amely a vészforgatókönyvekben elviselhető adatvesztés maximális mennyisége. Ha többet szeretne megtudni ezekről a metrikákról és azok üzletmenet-folytonossághoz való viszonyáról, tekintse meg az üzletmenet-folytonosságot, a magas rendelkezésre állást és a vészhelyreállítást ismertető témakört.

Mivel a replikáció fontos a funkcionális és teljesítménykövetelményeknek való megfelelésben, a legtöbb adatbázisrendszer és egyéb adattárolási termék és szolgáltatás tartalmaz valamilyen replikációt szorosan integrált funkcióként. Az általuk kínált replikációtípusok általában az architektúrájukon és a használatuk módján alapulnak. Az Azure szolgáltatások által támogatott replikációtípusokról a Azure szolgáltatás megbízhatósági útmutatóiban olvashat.

Fontos

A replikáció nem ugyanaz, mint a biztonsági mentés. A replikáció szinkronizálja az összes módosítást több replika között, és nem tartja karban a régi adatmásolatokat.

Tegyük fel, hogy véletlenül töröl néhány adatot. A törlési művelet minden replikára replikálódik, és az adatok mindenhol törlődnek. Ebben az esetben valószínűleg vissza kell állítania a törölt adatokat egy biztonsági másolatból. A biztonsági mentést a cikk későbbi részében ismertetjük.

Szinkron és aszinkron replikáció

Az adatok replikálásakor az adatok módosításait szinkronban kell tartani a replikák között. Az adatváltozások konzisztenciájának fenntartása során számos elsődleges kihívás áll fenn:

  • Késleltetés. A replikák frissítése időt vesz igénybe, és minél távolabb vannak a replikák, annál tovább tart az adatok továbbítása a replikák közötti távolságon keresztül, és nyugtázást kap.

  • Változáskezelés. Az adatok változhatnak a replikák szinkronizálása közben, így az adatok konzisztenciájának kezelése összetetté válhat.

Ezeknek a kihívásoknak a megoldásához kétféleképpen replikálhatja az adatváltozásokat, és kezelheti az adatkonzisztenciát:

  • A szinkron replikáció megköveteli, hogy a frissítések több replikán is végbemenők, mielőtt a frissítés befejeződöttnek minősül. Az alábbi ábra a szinkron replikáció működését mutatja be:

    Két replika közötti szinkron replikációt bemutató ábra.

    Ebben a példában a következő lépések sorozata következik be:

    1. Az ügyfél módosítja az adatokat, és a kérést elküldi az 1. replikának, amely feldolgozza a kérést, és tárolja a módosított adatokat.
    2. Az 1. replika elküldi a módosításokat a 2. replikának, amely feldolgozza a kérést, és tárolja a módosított adatokat.
    3. A 2. replika tudomásul veszi az 1. replikára való visszalépést.
    4. Az 1. replika visszaigazolja a módosítást az ügyfélnek.

    A szinkron replikáció garantálja a konzisztenciát, ami azt jelenti, hogy támogatja a nulla RPO-t. Ez azonban a teljesítmény költségével jár. Minél távolabb vannak egymástól a replikák földrajzilag, és minél több hálózati ugrást kell áthaladni, annál nagyobb késést fog eredményezni a replikációs folyamat.

  • Az aszinkron replikáció a háttérben történik. Az alábbi ábra az aszinkron replikáció működését mutatja be:

    Két replika közötti aszinkron replikációt bemutató ábra.

    Ebben a példában a következő lépések sorozata következik be:

    1. Az ügyfél módosítja az adatokat, és a rendszer elküldi a kérelmet az 1. replikának.
    2. Az 1. replika feldolgozza a kérést, tárolja a módosított adatokat, és azonnal nyugtázza a módosítást az ügyfélnek.
    3. Egy későbbi időpontban az 1. replika szinkronizálja a módosítást a 2. replikára.

    Mivel az aszinkron replikáció a tranzakciós folyamatokon kívül történik, az alkalmazás teljesítményének korlátozásaként eltávolítja a replikációt. Ha azonban egy másik replikára kell feladatátvételt végeznie, előfordulhat, hogy nem rendelkezik a legújabb adatokkal, ezért az RPO-nak nullánál nagyobbnak kell lennie. Az aszinkron replikáció által támogatott RPO pontosan a replikáció gyakoriságától függ.

Replikaszerepkörök

Számos replikációs rendszerben a replikák különböző szerepköröket vehetnek fel, ami segít koordinálni az adatok módosításait, és csökkenti az ütközések esélyét. Két fő szerepkörtípus létezik, az aktív és a passzív. A replikák elosztásának két gyakori módja van az alábbi szerepkörökkel:

  • Az aktív-passzív replikáció azt jelenti, hogy egy aktív replika van, amely az igazság forrásaként szolgál. Az adatok módosításait az adott replikára kell alkalmazni. Minden más replika passzív szerepkörben működik, ami azt jelenti, hogy az aktív replikától kapják az adatok frissítését, de nem dolgozzák fel közvetlenül az ügyfelek módosításait. A passzív replikák csak akkor használhatók élő forgalomhoz, ha feladatátvétel történik, és a replikák szerepkörei megváltoznak. Az alábbi ábrán egy aktív-passzív rendszer látható egy passzív replikával:

    Két replika közötti aktív-passzív replikációt bemutató ábra.

    Aktív-passzív rendszerben a feladatátvétel időtartama határozza meg az RTO-t. Az aktív-passzív rendszer RTO-jának mérése általában percekben történik.

    Egyes replikációs megoldások támogatják az írásvédett replikákat is, amelyek lehetővé teszik az adatok olvasását (de írását nem) a passzív replikákból. Ez a megközelítés hasznos lehet a replikák kihasználtságának további kihasználásához, például ha elemzést vagy jelentéskészítést kell végeznie az adatokon anélkül, hogy az alkalmazás tranzakciós munkájához használt elsődleges replikát érintené. Számos Azure szolgáltatás támogatja a csak olvasható replikákat, köztük az Azure Storage read access GRS (RA-GRS) replikációs típussal és az Azure SQL Database aktív georeplikációval.

  • Az aktív-aktív replikáció lehetővé teszi több aktív replika egyidejű használatát az élő forgalomhoz, és bármelyik replika feldolgozhatja a kéréseket:

    Két replika közötti aktív-aktív replikációt bemutató ábra.

    Az aktív-aktív replikáció magas teljesítményt tesz lehetővé, mivel a rendszer az összes replikán használhatja az erőforrásokat. Az aktív-aktív replikáció bizonyos helyzetekben támogatja a nulla RTO-t. Ezek az előnyök azonban az adatkonzisztenciát bonyolítják, mivel előfordulhat, hogy több replika egyidejű versengő módosításait aszinkron módon kell egyeztetni.

Az összetett adatszolgáltatások az aktív-aktív és az aktív-passzív replikációt is kombinálhatják. Előfordulhat például, hogy egy replikakészletet helyeznek üzembe egy Azure régióban, és egy másikat egy másik régióban. Minden régióban egyetlen aktív replika szolgál ki kéréseket, míg egy vagy több passzív replika áll készen a feladatátvételre. Eközben mindkét régió aktív-aktív modellben működik, lehetővé téve a forgalom elosztását közöttük.

A replikáció működése Azure adatszolgáltatásokban

Minden Azure szolgáltatást, amely adatokat tárol, valamilyen replikációs lehetőséget kínál. Azonban minden szolgáltatás más megközelítést használhat, amely a szolgáltatás architektúrájára és rendeltetésére jellemző.

Például a Azure Storage képes szinkron és aszinkron replikációt is biztosítani a képességek halmazán keresztül:

  • Az adatok több példánya szinkron módon replikálódik az elsődleges régión belül. Kiválaszthatja, hogy a replikákat különböző fizikai hardvereken helyezi-e el egy adatközpontban helyileg redundáns tárolásban (LRS), vagy elosztja őket több rendelkezésre állási zónában a zónaredundáns tároláshoz (ZRS).
  • Ha az elsődleges régió párosítva van, és engedélyezi a georedundáns tárolást (GRS), az adatok a párosított régióba is replikálódnak. Mivel a párosított régiók földrajzilag távoliak, ez a replikáció aszinkron módon történik az alkalmazás átviteli sebességére gyakorolt hatás csökkentése érdekében.
  • A zónaredundáns tárolás és a georedundáns tárolás egyidejű használatát a geo-zónaredundáns tárolási szint (GZRS) használatával választhatja ki. A rendszer szinkron módon replikálja a régión belüli adatokat, a régiók közötti adatokat pedig aszinkron módon replikálja.

További információ: Azure Storage redundancia.

Egy másik példa a Azure Cosmos DB, amely replikációt is biztosít. Minden Azure Cosmos DB adatbázis több replikával rendelkezik. Ha globálisan osztja el a replikákat, az lehetővé teszi a több régiós írásokat, amely révén az ügyfelek bármely használt régióban replikára írhassanak. Ezek az írási műveletek szinkron módon replikálódnak a régión belül, majd aszinkron módon replikálódnak más régiókra. Azure Cosmos DB ütközésfeloldási mechanizmust biztosít arra az esetre, ha írási ütközések fordulnak elő a különböző replikák között. További információkért lásd: Az Azure Cosmos DB globális adatelosztása - a háttérben.

Ha virtuális gépeket használ, a Azure Site Recovery használatával replikálhatja a virtuális gépeket és lemezeiket a rendelkezésre állási zónák vagy egy másik Azure régió között.

Ha Azure megoldást tervez, tekintse meg az egyes szolgáltatások reliability útmutatóit annak megértéséhez, hogy ez a szolgáltatás hogyan biztosít redundanciát és replikációt, beleértve a különböző helyeken is.

Backup

A biztonsági mentés egy adott időpontban készít másolatot az adatokról. Ha probléma merül fel, később visszaállíthatja a biztonsági másolatot. A biztonsági másolat készítése után történt adatok módosításai azonban nem lesznek a biztonsági másolatban, és elveszhetnek.

A biztonsági mentés használatával megoldásokat kínálhat az adatok biztonsági mentésére és helyreállítására a Microsoft Azure felhőben, akár belső szinten, akár a felhőbe mentve. A biztonsági mentés számos kockázattal szemben védelmet nyújt, többek között a következőket:

  • A hardver vagy más infrastruktúra katasztrofális veszteségei.
  • Adatok sérülése és törlése.
  • Kibertámadások, például zsarolóprogramok.

Fontos

Fontos, hogy a többi helyreállítási lépés mellett rendszeresen tesztelje és ellenőrizze a biztonsági mentési és visszaállítási folyamatokat. A tesztelés biztosítja, hogy a biztonsági másolatok átfogóak és hibamentesek legyenek, és hogy a folyamatok megfelelően visszaállítsák őket. A tesztek azért is fontosak, hogy a csapat megértse a követendő folyamatokat. További információ: Tesztelés és gyakorlatok.

A biztonsági mentés hatása a követelményekre

Vészhelyreállítási stratégia részeként történő használat esetén a biztonsági másolatok általában támogatják az órákban mért RTO-t és RPO-t:

  • Az RTO-t befolyásolja a helyreállítási folyamatok elindításához és befejezéséhez szükséges idő, beleértve a biztonsági mentés visszaállítását és a helyreállítás sikeres befejezésének ellenőrzését. A biztonsági mentés méretétől és attól függően, hogy hány biztonsági mentési fájlt kell beolvasni, gyakori, hogy több órát vagy még tovább tart a biztonsági mentés teljes visszaállítása.

  • Az RPO-t a biztonsági mentési folyamat gyakorisága befolyásolja. Ha gyakrabban készít biztonsági másolatot, az azt jelenti, hogy kevesebb adatot veszít el, ha biztonsági másolatból kell visszaállítania. A biztonsági mentések azonban tárolást igényelnek, és bizonyos esetekben hatással lehetnek a szolgáltatás teljesítményére a biztonsági mentések készítése során. Ezért figyelembe kell vennie a biztonsági mentés gyakoriságát, és meg kell találnia a szervezet követelményeinek megfelelő egyensúlyt. A biztonsági mentés gyakoriságának figyelembe kell vennie az üzletmenet-folytonosság tervezését.

Egyes biztonsági mentési rendszerek összetettebb biztonsági mentési követelményeket támogatnak, beleértve a különböző megőrzési időszakokkal rendelkező több biztonsági mentési szintet, valamint a gyorsabb mentést és kevesebb tárterület használatát lehetővé tevő különbözeti vagy növekményes biztonsági mentéseket.

Biztonsági mentés Azure szolgáltatásokban

Számos Azure szolgáltatás biztosít biztonsági mentési képességeket az adatokhoz.

Azure Backup egy dedikált biztonsági mentési megoldás több kulcsfontosságú Azure szolgáltatáshoz, beleértve a virtuális gépeket, Azure Storage és Azure Kubernetes Service-t (AKS).

Emellett számos felügyelt adatbázis saját biztonsági mentési képességeket is biztosít a szolgáltatás részeként, például:

Biztonsági mentés és replikáció

A biztonsági mentés és a replikáció mindegyike különböző kockázatokkal szemben nyújt védelmet, és a két megközelítés egymást kiegészíti.

A replikáció támogatja a napi rugalmasságot, és gyakran használják magas rendelkezésre állási stratégiában. Egyes replikációs megközelítések kevés állásidőt vagy adatvesztést igényelnek, és alacsony RTO-t és RPO-t támogatnak. A replikáció azonban nem véd meg az adatvesztést vagy sérülést okozó kockázatoktól.

Ezzel szemben a biztonsági mentés gyakran az utolsó védelmi vonal a katasztrofális kockázatok ellen. A biztonsági mentések gyakran viszonylag magas RTO-t és RPO-t igényelnek, bár a biztonsági mentések konfigurálásának módja pontosan befolyásolja, hogy milyen magasak lesznek. A biztonsági másolatból történő teljes visszaállítás gyakran egy vészhelyreállítási terv része.

Összetevők előkészítése redundáns működéshez

Amikor olyan rendszert tervez, amely az architektúra részeként redundanciát használ, fontos megfontolni a következőket is:

  • Ismétlődő erőforráskonfiguráció a konzisztencia érdekében.
  • A példányhibák során fellépő kapacitás kezelése túlkiépítéssel.

Ismétlődő erőforrás-konfiguráció

Felhőkörnyezetekben az egyes erőforrások konfigurálása kritikus fontosságú. Hálózati terheléselosztó létrehozásakor például számos olyan beállítást konfigurálhat, amelyek befolyásolják a működést; és amikor egy függvényt Azure Functions használ, a biztonsági, teljesítmény- és alkalmazáskonfigurációs beállításokhoz kapcsolódó beállításokat konfigurálja. A Azure minden erőforrása rendelkezik valamilyen konfigurációval, amely a viselkedését vezérli.

Amikor különböző helyeken kezeli az erőforrások redundáns másolatait, fontos, hogy ön szabályozza a konfigurációjukat. Számos beállítást ugyanúgy kell beállítani az egyes példányokon, hogy az erőforrások ugyanúgy viselkedjenek. Egyes beállítások azonban eltérőek lehetnek az egyes példányok között, például egy adott régió virtuális hálózatára mutató hivatkozások.

Az erőforrások konzisztenciájának megőrzésének gyakori módszere az infrastruktúra kódként (IaC) való használata, például Bicep vagy Terraform. Ezek az eszközök lehetővé teszik az erőforrást meghatározó fájlok létrehozását, és ezeket a definíciókat az erőforrás minden példányához újra felhasználhatja. Az IaC használatával csökkentheti az erőforrások több példányának létrehozásának és kezelésének terheit rugalmassági célokra, és számos más előnye is van. További információ: Mi az infrastruktúra kódként (IaC)? és javaslatok az infrastruktúra kódként való használatára.

Kapacitás kezelése túlkiépítéssel

Ha egy példány meghibásodik, előfordulhat, hogy a teljes rendszerkapacitás eltér az kifogástalan működés során szükséges kapacitástól. Tegyük fel például, hogy általában egy webkiszolgáló hat példányával dolgozzák fel a bejövő webes forgalmat, és ezek a példányok egyenlően oszlanak el a régió három Azure rendelkezésre állási zónája között:

Három rendelkezésre állási zónát ábrázoló ábra, amelyek mindegyike a webkiszolgáló két példányával rendelkezik, összesen hat kapacitáspéldányhoz.

Ha egy rendelkezésre állási zóna leállást tapasztal, ideiglenesen elveszíthet két példányt, és csak négy webkiszolgáló-példány marad. Ha az alkalmazás általában nagy terhelés alatt áll, és mind a hat példánynak lépést kell tartania a normál forgalommal, akkor a kapacitáscsökkentés melletti futás befolyásolhatja a megoldás teljesítményét.

A hibákra való felkészüléshez túlterjeszkítheti a szolgáltatás kapacitását. A túlkiépítés lehetővé teszi, hogy a megoldás bizonyos mértékű kapacitásvesztést elviseljen, és továbbra is működjön a teljesítmény romlása nélkül.

Ha a webkiszolgáló példányainak túlkiosztásával szeretne felkészülni egy rendelkezésre állási zóna meghibásodásának esetére, kövesse az alábbi lépéseket:

  1. Határozza meg a csúcsterheléshez szükséges példányok számát.
  2. A túlallokált példányok számának lekérése a számítási feladatok csúcspéldányainak számával megszorozva történik, az alábbi tényezővel: [(zónák/(zónák-1)].
  3. Kerekítsd fel az eredményt a legközelebbi egész számra.

Megjegyzés:

Az alábbi táblázat feltételezi, hogy három rendelkezésre állási zónát használ, és az egyik zóna kapacitásvesztését szeretné figyelembe venni. Ha a követelmények eltérnek, módosítsa a képletet ennek megfelelően.

Számítási feladatok maximális száma A [(zones/(zones-1)] tényező. Formula Telepítendő példányok (kerekítve)
3 3/2 vagy 1,5 (3 x 1,5 = 4,5) 5 példány
4 3/2 vagy 1,5 (4 x 1,5 = 6) 6 példány
5 3/2 vagy 1,5 (5 x 1,5 = 7,5) 8 példány
6 3/2 vagy 1,5 (6 x 1,5 = 9) 9 példány
7 3/2 vagy 1,5 (7 x 1,5 = 10,5) 11 példány
8 3/2 vagy 1,5 (8 x 1,5 = 12) 12 példány
9 3/2 vagy 1,5 (9 x 1,5 = 13,5) 14 példány
10 3/2 vagy 1,5 (10 x 1,5 = 15) 15 példány

Az előző példában a csúcsterheléshez a webkiszolgáló hat példánya szükséges, így a túlkiépítés összesen kilenc példányt igényel:

A webkiszolgálók túlkiépítését ábrázoló diagram összesen kilenc kapacitáspéldányhoz.

Következő lépések

Ismerje meg a feladatátvételt és a feladatvisszavételt.

  • Last updated on