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. 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.
A kimaradás az Azure Service Bus ideiglenes elérhetetlensége. A kimaradás hatással lehet a Service Bus egyes összetevőire, például egy üzenettárolóra vagy akár a teljes adatközpontra. A probléma kijavítása után a Service Bus ismét elérhetővé válik. A kimaradások általában nem okoznak ü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.
A katasztrófa egy Service Bus-skálázási egység vagy adatközpont végleges elvesztését jelenti. Előfordulhat, hogy az adatközpont ismét elérhetővé válik vagy nem lesz elérhető. A katasztrófák általában egyes üzenetek vagy egyéb adatok elvesztését okozzák. Ilyenek például a tűz, az áradás vagy a földrengés.
Kimaradások és katasztrófák elleni védelem – prémium szintű
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ással).
Geo-vészhelyreállítás
A Service Bus prémium szintje a névtér szintjén támogatja a georeduktúra-helyreállítást. További információ: Azure Service Bus geo-vészhelyreállítás. A csak prémium termékváltozathoz elérhető vészhelyreállítási funkció metaadatok vészhelyreállítását valósítja meg, és elsődleges és másodlagos névterekre támaszkodik. Geo-vészhelyreállítás esetén a rendszer csak az entitások metaadatait replikálja az elsődleges és a másodlagos névterek között.
Rendelkezésreállási zónák
A Service Bus prémium szintű csomagja 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 prémium szintű 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.
Amikor prémium szintű névteret hoz létre a portálon keresztül, a rendelkezésre állási zónák támogatása (ha elérhető a kiválasztott régióban) automatikusan engedélyezve lesz a névtérhez. Ha prémium szintű névteret hoz létre más mechanizmusokkal, például Azure Resource Manager/ Bicep-sablonok, parancssori felület vagy PowerShell használatával, a tulajdonságot zoneRedundant explicit módon be kell állítani a rendelkezésre állási zónák engedélyezéséhez true (ha a kiválasztott régióban elérhető). 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.
Kimaradások és katasztrófák elleni védelem – standard szint
Az adatközpontok kimaradásaival szembeni rugalmasság érdekében a standard üzenetkezelési tarifacsomaggal aktív vagy passzív replikációt használhat. 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.
A [georeplikálás a Service Bus standard szinttel][Georeplikálás a Service Bus Standard szinttel] minta az üzenetkezelési entitások aktív replikációját mutatja be.
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: