Vysoká dostupnost služby IoT Hub a zotavení po havárii

Jako první krok k implementaci odolného řešení IoT musí architekti, vývojáři a vlastníci firmy definovat cíle na dobu provozu pro řešení, která buduje. Tyto cíle je možné definovat primárně na základě konkrétních obchodních cílů pro každý scénář. V tomto kontextu popisuje článek Technické pokyny k kontinuitě podnikových prostředí Azure obecný rámec, který vám pomůže přemýšlet o kontinuitě podnikových prostředí a zotavení po havárii. Dokument Zotavení po havárii a vysoká dostupnost pro aplikace Azure poskytuje pokyny k architektuře pro strategie pro aplikace Azure k dosažení vysoké dostupnosti (HA) a zotavení po havárii (DR).

Tento článek popisuje funkce pro hašování a dr. nabízí speciálně IoT Hub služby. V tomto článku jsou probírané tyto oblasti:

• Haštení v rámci oblasti
• DR napříč oblastmi
• Dosažení vysoké vysoké úrovně napříč oblastmi

V závislosti na cílech provozuschopnosti, které definujete pro řešení IoT, byste měli určit, které z níže uvedených možností nejlépe vyhovují vašim obchodním cílům. Zahrnutí kterékoli z těchto alternativ ha/dr do řešení IoT vyžaduje pečlivé vyhodnocení promyšleného řešení:

• Úroveň odolnosti, kterou požadujete
• Složitost implementace a údržby
• Dopad COGS

Haštení v rámci oblasti

Služba IoT Hub ha ha v rámci oblasti díky implementaci redundance téměř ve všech vrstvách služby. Smlouvy SLA publikované službou IoT Hub se dosahuje použitím těchto redundancí. Vývojáři řešení IoT nic dalšího nepracují, aby tyto funkce pro hašování využili. Přestože IoT Hub nabízí přiměřenou záruku vysoké provozuschopnosti, přechodná selhání je možné očekávat stejně jako u jakékoli distribuované výpočetní platformy. Pokud právě začínáte s migrací řešení do cloudu z místního řešení, musíte se zaměřit na optimalizaci "střední doby mezi selháními" na "střední dobu obnovení". Jinými slovy, přechodná selhání se při provozu s cloudem v kombinaci považují za normální. V komponentách, které komunikují s cloudovou aplikací, musí být integrované vhodné zásady opakování, aby bylo možné řešit přechodná selhání.

Zóny dostupnosti

K dispozici je 99,9% smlouva SLA pro IoT Hub a můžete si přečíst sla. Úplná smlouva Azure SLA vysvětluje garantovanou dostupnost Azure jako celku.

IoT Hub podporuje Zóny dostupnosti. Zóna dostupnosti je nabídka vysoké dostupnosti, která chrání vaše aplikace a data před selháním datacentra. Oblast s podporou zóny dostupnosti se skládá ze tří zón podporujících tuto oblast. Každá zóna poskytuje jedno nebo více datových center v jedinečném fyzickém umístění s nezávislým napájením, chlazením a sítí. To zajišťuje replikaci a redundanci v rámci oblasti. Podpora zóny dostupnosti pro IoT Hub je automaticky povolená pro nové IoT Hub prostředků vytvořených v následujících oblastech Azure:

• Austrálie – východ
• Brazílie – jih
• Střední Kanada
• USA – střed
• Francie – střed
• USA – západ 2
• Japonsko – východ
• Severní Evropa
• Southeast Asia
• Spojené království – jih

DR napříč oblastmi

Může se zobrazit několik výjimečných situací, kdy v datacentru dojde k delším výpadkům způsobeným výpadky napájení nebo jinými selháními, která se týkají fyzických prostředků. Takové události jsou vzácné, během kterých výše popsaná funkce ha v rámci oblasti nemusí vždy pomoci. IoT Hub poskytuje několik řešení pro zotavení z takto rozšířených výpadků.

Dostupné možnosti obnovení pro zákazníky v takové situaci jsou převzetí služeb při selhání iniciované Microsoftem a ruční převzetí služeb při selhání. Základní rozdíl mezi těmito dvěma variantami spočívá v tom, že první z nich iniciuje Microsoft a uživatel iniciuje druhou. Ruční převzetí služeb při selhání navíc poskytuje nižší cíl doby obnovení (RTO) v porovnání s možností převzetí služeb při selhání iniciované Microsoftem. Konkrétní RPO nabízené u jednotlivých možností jsou popsány v následujících částech. Když se provede která z těchto možností převzetí služeb při selhání centra IoT z jeho primární oblasti, stane se centrum plně funkční v odpovídající geograficky spárované oblasti Azure.

Obě tyto možnosti převzetí služeb při selhání nabízejí následující cíle bodů obnovení (RPO):

^1. Zprávy z cloudu do zařízení a nadřazené úlohy se v rámci ručního převzetí služeb při selhání nezískaly.

Po dokončení operace převzetí služeb při selhání pro centrum IoT se očekává, že všechny operace ze zařízení a back-endových aplikací budou fungovat i nadále bez nutnosti ručního zásahu. To znamená, že zprávy ze zařízení do cloudu by měly dál fungovat a celý registr zařízení je nedotčený. Události generované prostřednictvím Event Grid se dávají využívat prostřednictvím stejných předplatných nakonfigurovaných dříve, pokud jsou Event Grid předplatná nadále dostupná. Pro vlastní koncové body se nevyžaduje žádné další zpracování.

Převzetí služeb při selhání iniciované Microsoftem

Převzetí služeb při selhání iniciované Microsoftem ve výjimečných situacích používá Microsoft k převzetí služeb při selhání všech center IoT z ovlivněné oblasti do odpovídající geograficky spárované oblasti. Tento proces je výchozí možností (žádný způsob, jak se uživatelé odhlásit) a nevyžaduje od uživatele žádný zásah. Společnost Microsoft si vyhrazuje právo stanovit, kdy bude tato možnost provedena. Tento mechanismus nezahrnuje souhlas uživatele před tím, než se služby centra uživatele přehodí při selhání. Převzetí služeb při selhání iniciované Microsoftem má cíl doby obnovení (RTO) 2–26 hodin.

Velký RTO je proto, že Microsoft musí provést operaci převzetí služeb při selhání jménem všech ovlivněných zákazníků v této oblasti. Pokud používáte méně důležité řešení IoT, které dokáže utrhnout přibližně jeden den v výpadku, můžete využít závislost na této možnosti a splnit celkové cíle zotavení po havárii pro vaše řešení IoT. Celková doba, po které se běhové operace po aktivaci tohoto procesu plně zprovozní, je popsaná v části "Čas k obnovení".

Ruční převzetí služeb při selhání

Pokud RTO, které převzetí služeb při selhání iniciuje Microsoft, nesplní vaše firemní cíle z provozuschopnosti, zvažte použití ručního převzetí služeb při selhání, abyste proces převzetí služeb při selhání sami spouštěli. RTO při použití této možnosti může být mezi 10 minutami a několika hodinami. RTO je aktuálně funkcí počtu zařízení zaregistrovaných pro instanci IoT Hubu, u které probíhá přehodování služeb při selhání. Můžete očekávat, že RTO pro centrum hostující přibližně 100 000 zařízení bude v 15minutových plánech. Celková doba, po kterou se běhové operace stanou plně funkční, když se tento proces aktivuje, je popsaný v části "doba pro obnovení".

Možnost ručního převzetí služeb při selhání je vždy dostupná pro použití bez ohledu na to, jestli má primární region výpadky nebo ne. Proto tuto možnost můžete použít k provádění plánovaných převzetí služeb při selhání. Jedním z příkladů použití plánovaného převzetí služeb při selhání je provedení pravidelného přechodu k převzetí služeb při selhání. V takovém případě se jedná o slovo s upozorněním, ale výsledkem plánované operace převzetí služeb při selhání je výpadek centra po dobu určenou RTO pro tuto možnost a také způsobí ztrátu dat, jak je definováno v tabulce RPO výše. Je možné zvážit nastavení instance testovacího centra IoT, aby bylo možné naplánovat možnost plánovaného převzetí služeb při selhání, a získat tak jistotu, že vaše možnosti budou fungovat i v případě, že dojde k reálné havárii.

Ruční převzetí služeb při selhání je dostupné bez dalších poplatků pro centra IoT vytvořená po 18. května 2017

Podrobné pokyny najdete v tématu kurz: provedení ručního převzetí služeb při selhání pro Centrum IoT.

Ruční převzetí služeb při selhání a centrum událostí

Jak bylo popsáno dříve v části Upozornění , název a koncový bod pro IoT Hub vestavěné události v centru událostí po ručním převzetí služeb při selhání se mění. Důvodem je skutečnost, že klient centra událostí nemá přehled o IoT Hubch událostech. Totéž platí pro ostatní cloudové klienty, jako jsou funkce a Azure Stream Analytics. Chcete-li načíst koncový bod a název, můžete použít Azure Portal nebo využít zahrnutý vzorek.

Použití portálu

Další informace o použití portálu k načtení koncového bodu kompatibilního s centrem událostí a názvu kompatibilního s centrem událostí najdete v tématu čtení z integrovaného koncového bodu.

Použití zahrnutého vzorku

Chcete-li použít připojovací řetězec IoT Hub pro opětovné zachycení koncového bodu kompatibilního s centrem událostí, využijte ukázku na adrese https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs , která ukazuje, jak použít připojovací řetězec IoT Hub k opětovnému zachycení kompatibilního koncového bodu centra EventHub. Příklad kódu používá připojovací řetězec k získání nového koncového bodu centra událostí a k novému navázání připojení. musíte mít nainstalovanou Visual Studio.

Spuštění testovacích cvičení

V centrech IoT, které se používají v produkčním prostředí, by se neměly provádět testovací cvičení.

Nepoužívejte ruční převzetí služeb při selhání k migraci centra IoT do jiné oblasti.

Ruční převzetí služeb při selhání by se nemělo používat jako mechanismus k trvalé migraci vašeho centra mezi geograficky spárované oblasti Azure. Tím se zvyšuje latence operací prováděných proti službě IoT Hub ze zařízení s domovským umístěním ve staré primární oblasti.

Navrácení služeb po obnovení

Navrácení služeb po obnovení do staré primární oblasti se dá dosáhnout tak, že akci převzetí služeb při selhání vykonáte jiným časem. Pokud se původní operace převzetí služeb při selhání provedla při obnovení z rozšířeného výpadku v původní primární oblasti, doporučujeme, aby se centrum po obnovení do původního umístění obnovilo z situace výpadku.

Doba obnovení

I když plně kvalifikovaný název domény (a tudíž připojovací řetězec) instance centra IoT zůstane stejný po převzetí služeb při selhání, pak se změní podkladová IP adresa. Vzhledem k tomu, že po aktivaci procesu převzetí služeb při selhání může být celková doba pro běhové operace prováděná vůči instanci služby IoT Hub plně funkční, můžete ji vyjádřit pomocí následující funkce.

Doba obnovení = RTO [10 min-2 hodiny pro ruční převzetí služeb při selhání (2-26 hodin) pro převzetí služeb při selhání spouštěné Microsoftem] + prodleva šíření DNS + doba, kterou klientská aplikace aktualizuje v mezipaměti IoT Hub IP adresa.

Dosažení mezi oblastí HA

Pokud se RTO vaše cíle provozu vaší firmy, které nabízí Microsoft iniciované převzetí služeb při selhání nebo ruční převzetí služeb při selhání, měli byste zvážit implementaci mechanismu převzetí služeb při selhání automatických oblastí v jednotlivých zařízeních. Kompletní zpracování topologií nasazení v řešeních IoT je mimo rámec tohoto článku. Tento článek popisuje model nasazení pro místní převzetí služeb při selhání pro účely vysoké dostupnosti a zotavení po havárii.

V rámci modelu regionálního převzetí služeb při selhání se back-end řešení spouští hlavně v jednom umístění datového centra. Sekundární centrum IoT a back-end se nasazují v jiném umístění datového centra. Pokud služba IoT Hub v primární oblasti zpomaluje výpadek nebo dojde k přerušení připojení k síti ze zařízení do primární oblasti, zařízení použijí sekundární koncový bod služby. Dostupnost řešení můžete vylepšit implementací modelu převzetí služeb při selhání mezi oblastmi a nemusíte přitom zamezit v jedné oblasti.

Aby bylo možné implementovat model regionálního převzetí služeb při selhání pomocí IoT Hub, je nutné provést následující kroky:

• Sekundární logika služby IoT Hub a směrování zařízení: Pokud dojde k přerušení služby ve vaší primární oblasti, zařízení musí začít připojovat se k vaší sekundární oblasti. Vzhledem k tomu, že se jedná o charakter většiny služeb, které jsou součástí, je běžné, že správci řešení můžou aktivovat proces převzetí služeb při selhání mezi oblastmi. Nejlepším způsobem, jak komunikovat s novým koncovým bodem do zařízení a přitom zachovat kontrolu nad procesem, je nechat pravidelně kontrolovat službu concierge pro aktuální aktivní koncový bod. služba concierge může být webová aplikace, která je replikována a udržována dosažitelná pomocí technik přesměrování DNS (například pomocí Azure Traffic Manager).

  Poznámka

  Služba IoT Hub není podporovaným typem koncového bodu v Azure Traffic Manager. Doporučením je integrovat navrhovanou službu concierge do Azure Traffic Manageru tím, že implementuje rozhraní API sondy stavu koncového bodu.

• Replikace registru identit: aby bylo možné použít, sekundární centrum IoT musí obsahovat všechny identity zařízení, které se mohou připojit k řešení. Řešení by mělo uchovávat geograficky replikované zálohy identit zařízení a odeslat je do sekundárního služby IoT Hub předtím, než přepnete aktivní koncový bod pro daná zařízení. V tomto kontextu je užitečná funkce exportu identity zařízení IoT Hub. Další informace najdete v tématu IoT Hub příručka pro vývojáře – registr identit.

• Sloučení logiky: když bude primární region opět k dispozici, všechny stavy a data, které byly vytvořeny v sekundární lokalitě, musí být migrovány zpět do primární oblasti. Tato data a data se většinou vztahují k identitám zařízení a metadatům aplikací, které je potřeba sloučit s primárním centrem IoT a dalšími obchody pro konkrétní aplikace v primární oblasti.

Pro zjednodušení tohoto kroku byste měli použít operace idempotentní. Operace idempotentní minimalizují vedlejší účinky z konečné souvislé distribuce událostí a z duplicitních nebo neseřazených doručení událostí. Kromě toho by měla být logika aplikace navržena tak, aby tolerována potenciální nekonzistence nebo mírně neaktuálního stavu. K této situaci může dojít v důsledku dodatečné doby potřebné k tomu, aby systém mohl na základě cílů bodu obnovení (RPO) provést zacelení.

Výběr pravé možnosti HA/DR

Tady je souhrn možností HA/DR prezentovaných v tomto článku, které se dají použít jako rámec Reference k výběru správné možnosti, která funguje pro vaše řešení.

Další kroky

• Co je Azure IoT Hub?
• Začínáme se službou IoT Hub (rychlý Start)
• Kurz: provedení ručního převzetí služeb při selhání pro Centrum IoT