Ajánlott eljárások az alkalmazások elszigeteléséhez a Service Bus leállásaival és katasztrófáival szemben
A kritikus fontosságú alkalmazásoknak folyamatosan kell működniük, még nem tervezett kimaradások vagy katasztrófák esetén is. Az adatfeldolgozási erőforrások katasztrofális kimaradásokkal szembeni rugalmassága számos vállalat számára követelmény, és bizonyos esetekben még az iparági szabályozások is megkövetelik. Ez a cikk a Service Bus-alkalmazások lehetséges szolgáltatáskimaradások vagy -katasztrófák elleni védelmére használható technikákat ismerteti.
Az Azure Service Bus már magában hordozza az egyes gépek vagy akár teljes állványok katasztrofális hibáinak kockázatát az adatközponton belüli több hibatartományt felölelő fürtök között, és transzparens hibaészlelési és feladatátvételi mechanizmusokat implementál, hogy a szolgáltatás továbbra is a biztosított szolgáltatási szinteken belül működjön, és általában észrevehető megszakítások nélkül, amikor ilyen hibák történnek.
Emellett a kimaradás kockázata tovább terjed három fizikailag elkülönített létesítményre (rendelkezésre állási zónákra), és a szolgáltatás elegendő kapacitással rendelkezik ahhoz, hogy azonnal megbirkózzon az adatközpontok teljes, katasztrofális veszteségével. A hibatartományon belüli, mindenre aktív Azure Service Bus-fürtmodell és a rendelkezésre állási zóna támogatása minden helyszíni üzenetközvetítő terméknél jobb a súlyos hardverhibákkal szembeni rugalmasság, sőt akár a teljes adatközpont-létesítmények katasztrofális elvesztése esetén is. Mégis lehetnek olyan súlyos helyzetek, amikor a fizikai pusztítás széles körben elterjedt, és még ezek a mértékek sem képesek megfelelően védekezni ellen.
A Service Bus georedundáns helyreállítási és georeplikációs funkciói úgy lettek kialakítva, hogy egyszerűbbé tegyék az ilyen mértékű katasztrófák utáni helyreállítást, és hogy az alkalmazáskonfigurációk módosítása nélkül is elhagyják a meghibásodott Azure-régiót.
Üzemkimaradások és katasztrófák
Fontos megjegyezni a "kimaradások" és a "katasztrófák" közötti különbséget.
A kimaradás az Azure Service Bus ideiglenes elérhetetlensége, amely hatással lehet a szolgáltatás bizonyos összetevőire, például egy üzenetkezelő tárolóra vagy akár a teljes adatközpontra. A probléma kijavítása után azonban a Service Bus ismét elérhetővé válik. A kimaradás általában nem okozza az üzenetek vagy más adatok elvesztését. Az összetevők meghibásodására példa egy adott üzenettároló elérhetetlensége. Az adatközpont egészére kiterjedő leállásokra példa az adatközpont áramkimaradása vagy egy hibás adatközponti hálózati kapcsoló. A leállások néhány perctől néhány napig tarthatnak. Egyes kimaradások csak rövid kapcsolatvesztések átmeneti vagy hálózati problémák miatt.
A katasztrófa a Service Bus-fürt, az Azure-régió vagy az adatközpont állandó vagy hosszabb távú vesztesége. Előfordulhat, hogy a régió vagy az adatközpont ismét elérhetővé válik, vagy órákig vagy napokig nem érhető el. Ilyen katasztrófák például a tűz, az áradás vagy a földrengés. Az állandóvá váló katasztrófa egyes üzenetek, események vagy egyéb adatok elvesztését okozhatja. A legtöbb esetben azonban nem lehet adatvesztés, és az adatközpont biztonsági mentése után az üzenetek helyreállíthatók.
Kimaradások és katasztrófák elleni védelem
A Prémium szintű Azure Service Busban két funkció biztosítja a Geo-Disaster Recovery szolgáltatást. Először is létezik geo-vészhelyreállítás (Metadata DR), amely metaadatok (entitások, konfigurációk, tulajdonságok) replikálását biztosítja. Másodszor, van georeplikáció, amely jelenleg nyilvános előzetes verzióban érhető el, amely magában a metaadatok és az adatok replikálását (üzenetadatok és üzenettulajdonságok / állapotváltozások) biztosítja. A Geo-Vészhelyreállítás funkció nem tévesztendő össze a rendelkezésre állási zónákkal. Függetlenül attól, hogy metaadat-dr. vagy georeplikációról van-e szó, mindkét geografikus helyreállítási funkció rugalmasságot biztosít az Olyan Azure-régiók között, mint az USA keleti régiója és az USA nyugati régiója.
A rendelkezésre állási zónák minden Service Bus-szinten elérhetők, és a támogatás rugalmasságot biztosít egy adott földrajzi régión belül, például az USA keleti régiójában. A Microsoft Azure vészhelyreállításának részletes ismertetését ez a cikk ismerteti.
A magas rendelkezésre állási és vészhelyreállítási fogalmak közvetlenül az Azure Service Bus prémium szintű csomagjába vannak beépítve, mind ugyanabban a régióban (rendelkezésre állási zónákon keresztül), mind különböző régiókban (georedundáns helyreállítás és georeplikálás révén).
Geo-Vészhelyreállítási lehetőségek
Geo-vészhelyreállítás
A Service Bus prémium szintű csomagja a névtér szintjén támogatja a Geo-Vészhelyreállítást. További információ: Azure Service Bus Geo-Disaster Recovery. A csak prémium szintű szinten elérhető Geo-Vészhelyreállítás funkció metaadatok vészhelyreállítását valósítja meg, és elsődleges és másodlagos névterekre támaszkodik. A Geo-Vészhelyreállítás funkcióval csak az entitások metaadatai replikálódnak az elsődleges és a másodlagos névterek között.
Georeplikáció
A Service Bus prémium szintű csomagja a névtér szintjén támogatja a georeplikálást is. További információt az Azure Service Bus georeplikációs (nyilvános előzetes verzió) című témakörben talál. A kizárólag prémium szintű és jelenleg nyilvános előzetes verzióban elérhető georeplikációs funkció metaadatokat és adatkatasztrófa-helyreállítást valósít meg, és elsődleges és másodlagos régiókra támaszkodik. A georeplikációval az entitások metaadatai és adatai is replikálódnak az elsődleges és a másodlagos régiók között.
Magas szintű funkcióbeli különbségek
A Geo-Vészhelyreállítás (Metadata DR) szolgáltatás egy névtér metaadatait replikálja egy elsődleges névtérből egy másodlagos névtérbe. Egyszeri feladatátvételt támogat a másodlagos régióba. Az ügyfél által kezdeményezett feladatátvétel során a névtér aliasnevét a rendszer a másodlagos névtérre irányítja át, majd a párosítás megszakad. A metaadatokon kívül egyetlen adat sem replikálódik, és az RBAC-hozzárendelések sem replikálódnak.
A georeplikációs funkció replikálja a metaadatokat és az összes adatot egy elsődleges régióból egy vagy több másodlagos régióba. Amikor az ügyfél feladatátvételt végez, a kiválasztott másodlagos lesz az elsődleges, az előző elsődleges pedig másodlagos lesz. A felhasználók igény szerint visszaállíthatják a feladatátvételt az eredeti elsődleges helyre.
Rendelkezésreállási zónák
Minden Service Bus-szint támogatja a rendelkezésre állási zónákat, és hibaelszigetelt helyeket biztosít ugyanazon az Azure-régión belül. A Service Bus az üzenetkezelési tároló három példányát kezeli (1 elsődleges és 2 másodlagos). A Service Bus mind a három példányt szinkronizálja az adatok és a felügyeleti műveletek esetében. Ha az elsődleges másolat sikertelen, a másodlagos másolatok egyikét előlépteti az elsődlegesre, és nem észleli az állásidőt. Ha az alkalmazások átmeneti leválasztást látnak a Service Busról, az SDK újrapróbálkozási logikája automatikusan újracsatlakozik a Service Bushoz.
Rendelkezésre állási zónák használata esetén a rendszer a metaadatokat és az adatokat (üzeneteket) is replikálja a rendelkezésre állási zónában lévő adatközpontok között.
Feljegyzés
A rendelkezésre állási zónák támogatása csak olyan Azure-régiókban érhető el, ahol rendelkezésre állási zónák találhatók.
Névtér létrehozásakor a rendelkezésre állási zónák támogatása (ha a kiválasztott régióban elérhető) automatikusan engedélyezve lesz a névtérhez. A funkció használata nem jár többletköltséggel, és a névtér létrehozása után nem tilthatja le vagy engedélyezheti ezt a funkciót.
Feljegyzés
Korábban a rendelkezésre állási zónák engedélyezéséhez true kellett beállítani a tulajdonságotzoneRedundant, de ez a viselkedés alapértelmezés szerint megváltozott a rendelkezésre állási zónák engedélyezéséhez. A meglévő névterek szükség esetén át lesznek migrálva a rendelkezésre állási zónákba, és a tulajdonság zoneRedundant elavult. A tulajdonság zoneRedundant továbbra is megjelenhet false, még akkor is, ha a rendelkezésre állási zónák engedélyezve vannak.
Áttelepített meglévő névterek:
- Jelenleg nincs engedélyezve a rendelkezésre állási zónák használata.
- A régió támogatja a rendelkezésre állási zónákat.
- A régió elegendő rendelkezésre állási zónával rendelkezik.
Katasztrófák elleni védelem – standard szint
Ha a Service Bus Standard szinttel szeretne rugalmasságot elérni a katasztrófákkal szemben, használhat aktív vagy passzív replikációt. Minden megközelítés esetében, ha egy adott üzenetsornak vagy témakörnek elérhetőnek kell maradnia egy adatközpont kimaradása esetén, mindkét névtérben létrehozhatja. Mindkét entitásnak ugyanaz a neve lehet. Az elsődleges üzenetsor például a contosoPrimary.servicebus.windows.net/myQueue alatt érhető el, a másodlagos megfelelője pedig a contosoSecondary.servicebus.windows.net/myQueue alatt érhető el.
Feljegyzés
Az aktív replikáció és a passzív replikáció beállítása általános célú megoldások, és nem a Service Bus egyes funkciói. A replikációs logika (2 különböző névtérbe való küldés) a küldő alkalmazásokban található, és a fogadónak egyéni logikával kell rendelkeznie az ismétlődő észleléshez.
Ha az alkalmazás nem igényel állandó feladó–fogadó kommunikációt, az alkalmazás tartós ügyféloldali üzenetsort implementálhat az üzenetvesztés megakadályozása és a küldőnek az átmeneti Service Bus-hibák elleni védelem érdekében.
Aktív replikáció
Az aktív replikáció mindkét névtérben entitásokat használ minden művelethez. Minden olyan ügyfél, amely üzenetet küld, két másolatot küld ugyanabból az üzenetből. Az első példányt a rendszer elküldi az elsődleges entitásnak (például contosoPrimary.servicebus.windows.net/sales), az üzenet második példányát pedig a másodlagos entitásnak (például contosoSecondary.servicebus.windows.net/sales).
Az ügyfél mindkét üzenetsorból fogad üzeneteket. A fogadó feldolgozza az üzenet első példányát, a második példány pedig el lesz tiltva. Az ismétlődő üzenetek letiltásához a feladónak egyedi azonosítóval kell megjelölnie az egyes üzeneteket. Az üzenet mindkét példányát ugyanazzal az azonosítóval kell megjelölni. Az üzenet címkézéséhez használhatja a ServiceBusMessage.MessageId vagy a ServiceBusMessage.Subject tulajdonságokat, vagy egy egyéni tulajdonságot. A fogadónak meg kell őriznie a már fogadott üzenetek listáját.
Feljegyzés
Az aktív replikációs megközelítés megduplázza a műveletek számát, ezért ez a megközelítés magasabb költségekhez vezethet.
Passzív replikáció
Hibamentes esetben a passzív replikáció a két üzenettovábbítási entitás közül csak egyet használ. Az ügyfél elküldi az üzenetet az aktív entitásnak. Ha az aktív entitáson végzett művelet meghiúsul egy hibakóddal, amely azt jelzi, hogy az aktív entitást üzemeltető adatközpont nem érhető el, az ügyfél elküldi az üzenet másolatát a biztonsági mentési entitásnak. Ekkor az aktív és a biztonsági mentési entitások szerepköröket váltanak. A küldő ügyfél a régi aktív entitást az új biztonsági mentési entitásnak tekinti, a régi biztonsági mentési entitás pedig az új aktív entitás. Ha mindkét küldési művelet sikertelen, a két entitás szerepkörei változatlanok maradnak, és a rendszer hibát ad vissza.
Az ügyfél mindkét üzenetsorból fogad üzeneteket. Mivel előfordulhat, hogy a fogadó két másolatot kap ugyanabból az üzenetből, a fogadónak el kell tiltania az ismétlődő üzeneteket. Az ismétlődő elemeket ugyanúgy tilthatja le, mint az aktív replikáció esetében.
A passzív replikáció általában gazdaságosabb, mint az aktív replikáció, mivel a legtöbb esetben csak egy műveletet hajt végre. A késés, az átviteli sebesség és a pénzügyi költség megegyezik a nem replikált forgatókönyvével.
Passzív replikáció használata esetén az alábbi esetekben az üzenetek elveszhetnek vagy kétszer fogadhatók:
- Üzenet késése vagy elvesztése: Tegyük fel, hogy a feladó sikeresen küldött egy m1 üzenetet az elsődleges üzenetsorba, majd az üzenetsor elérhetetlenné válik, mielőtt a fogadó megkapja az m1-et. A feladó egy következő m2 üzenetet küld a másodlagos üzenetsorba. Ha az elsődleges üzenetsor átmenetileg nem érhető el, a fogadó m1-et kap, miután az üzenetsor ismét elérhetővé válik. Katasztrófa esetén előfordulhat, hogy a fogadó soha nem kapja meg az m1-et.
- Ismétlődő fogadás: Tegyük fel, hogy a feladó m üzenetet küld az elsődleges üzenetsorba. A Service Bus sikeresen feldolgozza az m-t, de nem tud választ küldeni. Miután a küldési művelet túllépte az időkorlátot, a feladó azonos m-példányt küld a másodlagos üzenetsorba. Ha a fogadó képes fogadni az m első példányát, mielőtt az elsődleges üzenetsor elérhetetlenné válik, a fogadó körülbelül ugyanabban az időpontban kapja meg az m mindkét példányát. Ha a fogadó nem tudja megkapni az m első példányát, mielőtt az elsődleges üzenetsor elérhetetlenné válik, a fogadó kezdetben csak az m második példányát kapja meg, majd megkapja az m második példányát, amikor az elsődleges üzenetsor elérhetővé válik.
Az Azure Messaging Replication Tasks with .NET Core minta bemutatja az üzenetek névterek közötti replikálását.
Következő lépések
A vészhelyreállítással kapcsolatos további információkért tekintse meg az alábbi cikkeket: