Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Ez a cikk általános áttekintést nyújt arról, hogyan működik a feladatátvétel és a feladat-visszavétel egy felhőkörnyezetben. A feladatátvétel megértéséhez azonban először ismernie kell a redundanciát és a replikációt. Ezekről a fogalmakról a cikk folytatása előtt a redundancia, a replikáció és a biztonsági mentés című témakörben olvashat.
Az alkalmazások és az adatreplikák redundáns másolatainak fenntartásának gyakori oka a feladatátvétel végrehajtása. A feladatátvétellel átirányíthatja a forgalmat és a kéréseket a meghibásodott példányokról a rendben lévő példányokhoz. Ezután, ha az eredeti példányok ismét kifogástalan állapotba lépnek, feladat-visszavételt hajthat végre, hogy visszatérjen az eredeti konfigurációhoz.
Aktív és passzív példány szerepkörei
A feladatátvétel kontextusában egy példány lehet egyetlen összetevő, például egy adatbázis, vagy több összetevő gyűjteménye, amelyek egy szolgáltatás telepítését alkotják egy régióban. Egy teljes megoldáson keresztül a megoldás különböző részeit különböző módokon és különböző helyzetekben lehet feladatátvételre használni.
A feladatátvételhez és visszaállításhoz konfigurált összetevők vagy összetevők csoportja több példányt igényel. Mindegyik példány egy adott szerepkört feltételez:
- Az elsődleges vagy aktív példányok aktívan működnek, például az ügyfelek bejövő kéréseinek kiszolgálása. Általában egyszerre egy elsődleges példány van.
- A másodlagos vagy passzív példányok inaktívak, de szükség esetén készen állnak a váltásra, hogy elsődlegesek legyenek. Több másodlagos példány létezhet.
A passzív példányok konfigurálásának számos módja van. Minden módszer magában foglalja a helyreállítási idő és más tényezők, például a költségek és a működési összetettség közötti kompromisszumot:
- Forró készenléti rendszerek, amelyek úgy vannak kialakítva, hogy bármikor készen állnak az üzemi forgalom elfogadására.
- Meleg készenléti üzemmódok, amelyek úgy vannak kialakítva, hogy szinte készen állnak az éles forgalom elfogadására, de ehhez szükség lehet néhány konfigurációs módosításra vagy skálázási műveletre, mielőtt elfogadhatnák a forgalmat.
- A minimális konfigurációban részben üzembe helyezett próbafényes készenléti állapotok, és jelentős előkészítést igényelnek, mielőtt elfogadhatják az éles forgalmat.
- Hideg készenléti állapotok, amelyek egyáltalán nem helyezhetők üzembe, és az üzembe helyezendő összetevőkre támaszkodnak, mielőtt elfogadhatnák az éles forgalmat.
Jótanács
Egyes megoldások aktív-aktív megközelítésre épülnek, ami azt jelenti, hogy több példány is kiszolgálja a kéréseket. Az aktív-aktív rendszerek nem igényelnek feladatátvételt, mivel az összes példány folyamatosan aktívan kiszolgálja a kéréseket.
Átállási hatáskörök
A különböző helyzetek különböző feladatátvételi stratégiákat igényelnek. A lehetséges stratégiák szemléltetéséhez vegyünk egy példamegoldást, amely egy adatbázisból származó adatokhoz hozzáférő alkalmazásból áll. A feladatátvételi megoldást úgy konfigurálhatja, hogy redundáns másolatokat hoz létre az alkalmazáskiszolgálóról és az adatbázis több replikájáról. Ezután konfigurálja a következőt:
- Zónaredundancia a másolatok és replikák különböző rendelkezésre állási zónákban való elhelyezésével egy Azure régióban.
- Georedundancia globális terheléselosztóval a régiók közötti feladatátvételhez.
Íme egy egyszerűsített diagram, amely a normál műveletek általános architektúráját szemlélteti:
Ebben a megoldásban különböző helyzetek válthatnak ki különböző feladatátvételi eseményeket. Ezek mindegyike egy feladatátvételi hatókörnek felel meg, amely a feladatátvételt okozó összetevők részletességét jelöli:
Az adatbázis-replika átállása akkor fordulhat elő, ha az aktív adatbázis-replika elérhetetlenné válik. A passzív replikát aktív replikává léptetik elő. Az alkalmazások általában gyorsan átirányíthatják a kéréseiket az új aktív replikára:
A rendelkezésre állási zóna feladatátvétele akkor fordulhat elő, ha egy teljes rendelkezésre állási zóna leállást tapasztal. Az ilyen típusú kimaradás megköveteli, hogy az összes forgalmat a fennmaradó zónában lévő webkiszolgálóra irányítsa, és azt is biztosítja, hogy a túlélő zónában lévő adatbázis-replika aktív replikává váljon, ha még nem:
A régió átállása akkor fordulhat elő, ha az Azure elsődleges régió teljes katasztrofális veszteséget szenved el.
Bár ezek a hatókörök egyfajta feladatátvételt biztosítanak, eltérő feladatátvételi követelményekkel és folyamatokkal rendelkezhetnek. Emellett előfordulhat, hogy a Microsoft felelős bizonyos feladatátvételi hatókörökért, például zónaredundáns szolgáltatások használata esetén, míg Ön a felelős a szélesebb hatókörökre vonatkozó feladatátvételért, mint például az Azure régiók közötti feladatátvételért.
Átállás és üzletmenet-folytonosság tervezése
Az üzletmenet-folytonossági tervezés része a feladatátvételi stratégiák tervezése, beleértve a feladatátvétel különböző hatóköreit is.
Az üzletmenet-folytonossági terveknek általában tartalmazniuk kell az automatizált feladatátvételi eljárásokat a rendelkezésre állási zónákon belül vagy között. Ez a feladatátvételi típus a magas rendelkezésre állási stratégia részét képezi. Ha például egy adatbázis aktív replikája meghiúsul, egy automatizált folyamat előléptethet egy passzív replikát, hogy aktív replikává váljon. Ezután a webkiszolgálók kommunikálnak az új aktív replikával. Hasonlóképpen, ha egy rendelkezésre állási zóna meghibásodik, számos megoldás épül fel az automatikus helyreállításhoz a fennmaradó zónák használatával.
Különböző átállási eljárásokat alkalmaznak vészforgatókönyvekhez, például a teljes régió leállásának valószínűtlen esete. Régiókimaradás esetén előfordulhat, hogy a bejövő webes kéréseket a második régió használatára váltja, valamint elindítja az adatbázis feladatátvételét egy másodlagos régió replikájára.
Ne feledje, hogy a feladatátvételi eljárásoknak az üzletmenet-folytonossági tervezésbe való belevételével részletesebb tervezést és tesztelést kell végeznie. További információ: Mi az üzletmenet-folytonosság, a magas rendelkezésre állás és a vészhelyreállítás?
Tervezett és nem tervezett feladatátvételek
A nem tervezett feladatátvételek azok, amelyeket egy összetevő leállása során hajtanak végre, így a szolgáltatás egy másik példány használatával állítható vissza. A nem tervezett feladatátvételek néha állásidőt vagy adatvesztést eredményeznek a megoldás kialakításától függően. A nem tervezett feladatátvételekhez szükség van valamire a hiba észleléséhez és annak eldöntéséhez, hogy mikor indítsuk el a feladatátvételt.
Ezzel szemben a tervezett feladatátvételek azok, amelyeket proaktívan aktivál. Úgy teheti meg ezt, hogy előre felkészül valamire, például egy virtuális gép javítására és újraindítására. A tervezett feladatátvételek alacsonyabb tűréshatárt jelenthetnek az állásidő és az adatvesztés szempontjából, mivel ezek a rendszeres karbantartási eljárások részét képezik.
A feladatátvétel működési folyamata
A feladatátvétel általában a következő lépésekből áll, amelyeket manuálisan vagy automatizált rendszerekkel lehet végrehajtani. Az egyes lépések konkrét részletei az adott rendszertől függenek.
Hiba észlelése (nem tervezett feladatátvételek esetén). Az automatizált feladatátvétel megköveteli, hogy egy rendszer észlelje, ha egy példány nem érhető el, ami általában egy állapotellenőrzésen alapul. A különböző szolgáltatások különböző módokon határozzák meg az állapotukat. Egyes szolgáltatások például proaktív módon küldenek szívverési eseményeket a példányok között. Másoknak külön összetevőre van szükségük az egyes példányok rendszeres időközönkénti mintavételéhez. Az állapotfigyelőknek gyakran időbe telhet, hogy észleljék a példány hibáját, és gyakran fontos türelmi időt biztosítani arra az esetre, ha a példány egyszerűen foglalt volt, és nem tudott válaszolni.
Válassza az átváltást hiba esetén. Egy bizonyos ponton döntés születik a feladatátvétel elvégzéséről. A döntést egy automatizált eszköz vagy manuálisan hozhatja meg. A szervezet kockázattűrése befolyásolhatja, hogy milyen gyorsan születik meg ez a döntés. Ha alacsony a kockázattűrése, problémára utaló jel esetén gyorsan átkapcsolhat. Ha nagyobb a kockázattűrése, a feladatátvétel előtt megvárhatja, hogy meg lehessen-e oldani a problémát.
Válasszon ki egy új elsődleges példányt. A fennmaradó példányok egyike lesz az új elsődleges.
Bizonyos helyzetekben előfordulhat, hogy előre meghatározta, hogy melyik példány legyen az új elsődleges, vagy lehet, hogy csak egy példányra kell váltania.
Más helyzetekben van egy automatizált folyamat, amellyel a rendszer kiválaszt egy új elsődleges példányt. Számos konszenzusos algoritmust használnak az elosztott számítástechnikában, beleértve a vezető választásokat is. Ezek az algoritmusok a megfelelő szolgáltatásokban, például adatbázisokban implementálódnak. Egyes rendszerekben fontos, hogy az egyes példányok értesüljenek az új elsődleges replikáról, így a kijelölés eredményeit a rendszer automatikusan bejelenti az egyes replikáknak.
Átirányítási kérések. Konfigurálja a környezetet úgy, hogy a kérések az kifogástalan állapotú példányokra vagy az új elsődleges példányra legyenek irányítva.
Ennek eléréséhez előfordulhat, hogy frissítenie kell más rendszereket, hogy tudják, hol küldjenek kéréseket. Ez magában foglalhatja a terheléselosztási rendszer frissítését, hogy kizárja a nem megfelelő állapotú példányt. Más helyzetekben a tartománynévrendszert (DNS) gyakran használják a kérések egy rendszer aktív példányának való küldéséhez. A feladatátvételi folyamat részeként általában frissítenie kell a DNS-rekordokat, hogy a kérések az új elsődleges példányra legyenek irányítva. A DNS az élettartam (TTL) fogalmával rendelkezik, amely arra utasítja az ügyfeleket, hogy milyen gyakran kell ellenőrizniük a frissített DNS-rekordokat . Ha a TTL hosszú értékre van állítva, időbe telhet, amíg az ügyfelek információt kapnak a feladatátvételről, és továbbra is küldhetnek kéréseket a régi elsődlegesnek.
Mivel a feladatátvételi folyamatok késéseket is tartalmazhatnak, fontos, hogy a feladatátvételi eljárásokat úgy tervezze meg, hogy megfeleljen az állásidőre (a helyreállítási pont célkitűzésére vagy RTO-jára) és az adatvesztésre (a helyreállítási pont célkitűzésére vagy RPO-jára) vonatkozó követelményeknek. További információ: Mi az üzletmenet-folytonosság, a magas rendelkezésre állás és a vészhelyreállítás?
Failback
A visszaállás folyamata a forgalom visszaállítása és visszairányítása az eredeti elsődleges példányra.
Bizonyos helyzetekben egyáltalán nem szükséges a visszaállás, mert minden példány egyformán képes elsődlegesként működni. Vannak azonban olyan helyzetek, amikor fontos a visszaállás, például amikor egy adott Azure régióból kell futtatnia az alkalmazásokat, és egy regionális kimaradás során ideiglenesen egy másik régióba kellett átkapcsolnia.
A visszaállás néha ugyanúgy történik, mint a feladatátvétel. A feladat-visszavétel azonban több okból is összetettebb lehet, mint a feladatátvétel:
Adatszinkronizálási problémák. A normál feladatátvétel során és után is előfordulhat, hogy az előző elsődleges példány még mindig végzett némi munkát, vagy adatokat írt egy adattárba. A feladat-visszavételi folyamat része az adatok konzisztenciájának és integritásának biztosítása a megoldásban, beleértve az elsődleges és a másodlagos példányok közötti ütközések vagy duplikációk kezelését is.
Gyakori, hogy az adatszinkronizálási problémák manuális beavatkozást igényelnek. Ha nincs szüksége az ütköző adatokra, előfordulhat, hogy alaphelyzetbe állítja az adatbázist vagy más állapotot.
Helyreállítási lépések. Ha a feladatátvétel előtt megkísérelték a hibajavítási lépéseket az elsődleges rendszeren, előfordulhat, hogy az elsődleges példány ismeretlen állapotban maradhatott.
Ha fennáll annak a veszélye, hogy az elsődleges példány inkonzisztens állapotban van, akkor előfordulhat, hogy meg kell semmisítenie és újra kell telepítenie az elsődleges példányt, hogy az ismert jó állapotban legyen a visszaállítás előtt.
Extra állásidő. A visszaállási folyamat állásideje hosszabb lehet, mint az átállás során, az adatkonzisztencia helyreállításához szükséges újrakonfigurálások vagy műveletek miatt.
Ezt a problémát úgy háríthatja el, hogy feladat-visszavételi folyamatokat futtat egy karbantartási időszak alatt, vagy előre tanácsot ad a felhasználóknak a változásról. Emellett előfordulhat, hogy a rendszer online állapotában is végrehajthat néhány előkészítő műveletet, és minimalizálhatja a szükséges állásidőt.
Kockázattűrés. Ha a feladatátvétel kimaradás miatt történt, a szervezet állásidőre vagy más kockázatokra vonatkozó tűrőképessége a feladat-visszavétel során alacsonyabb lehet.
Az üzleti érdekelt feleket folyamatosan tájékoztatni kell a folyamat során a helyzetről, és teljes mértékben tisztában kell lenniük a feladat-visszavétel szükségességével és a feladat-visszavételi eljárások következményeivel. Lehetséges, hogy megfelelő időpontot tud egyeztetni a módosítások elvégzéséhez.
Feladatátvétel és feladatvisszavétel az Azure szolgáltatásokban
Fontos tisztában lenni azzal, hogy a feladatátvétel általában hogyan működik, ne feledje, hogy minden Azure szolgáltatás másképp közelítheti meg a feladatátvételt és a feladat-visszavételt. 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.
Számos Azure szolgáltatás automatikusan kezeli a feladatátvétel bizonyos típusait. Ha például zónaredundánsként konfigurált Azure szolgáltatásokat használ, a Microsoft automatikusan elvégzi a feladatátvételt a rendelkezésre állási zónák között. További információ: Mi a rendelkezésre állási zónák? és a Azure szolgáltatás megbízhatósági útmutatói.
Ha virtuális gépeket használ, Azure Site Recovery replikálja 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, és feladatátvételt hajthat végre Önnek.
Ha olyan megoldást tervez, amely több Azure szolgáltatást egyesít, a feladatátvételi követelmények összetettebbé válhatnak. Tegyük fel, hogy egy alkalmazásszinttel és adatbázissal rendelkező megoldást tervez, és többrégiós aktív/passzív architektúrát szeretne létrehozni. Az elsődleges régióban történő kimaradás során fontos, hogy az alkalmazás és az adatbázis együtt adja át a feladatokat a másodlagos régiónak. A használt szolgáltatásoktól függően előfordulhat, hogy saját átállási stratégiát kell megterveznie, hogy váltson az egyes régiókban található telepítések között. Azure globális forgalomirányítást és terheléselosztást biztosít Azure Front Door és Azure Traffic Manager keresztül, és kiválaszthatja a feladatátvételi követelményeknek megfelelő technológiát. Minden szolgáltatás támogatja az alkalmazás egyes regionális példányainak állapotának monitorozását, és konfigurálhatja úgy, hogy automatikusan átirányítsa a forgalmat az kifogástalan állapotú példányra.