Hög tillgänglighet och haveriberedskap för IoT Hub

Som ett första steg mot att implementera en motståndskraftig IoT-lösning måste arkitekter, utvecklare och företagsägare definiera målen för drifttid för de lösningar som de skapar. Dessa mål kan definieras främst baserat på specifika affärsmål för varje scenario. I den här kontexten beskriver artikeln Teknisk vägledning för affärskontinuhet i Azure ett allmänt ramverk som hjälper dig att tänka på affärskontinuhet och haveriberedskap. Dokumentet Haveriberedskap och hög tillgänglighet för Azure-program ger arkitekturvägledning för strategier för Azure-program för att uppnå hög tillgänglighet (HA) och haveriberedskap (DR).

I den här artikeln beskrivs funktionerna för ha och dr som erbjuds specifikt av IoT Hub tjänsten. De breda områden som beskrivs i den här artikeln är:

• Hög hög be del av regionen
• Dr i flera regioner
• Uppnå hög hög regions-HA

Beroende på de drifttidsmål som du definierar för dina IoT-lösningar bör du bestämma vilka av alternativen som beskrivs nedan som bäst passar dina affärsmål. Att införliva något av dessa HA/DR-alternativ i din IoT-lösning kräver en noggrann utvärdering av avvägningarna mellan följande:

• Återhämtningsnivå som du behöver
• Implementerings- och underhållskomplexitet
• COGS-påverkan

Hög hög be del av regionen

Tjänsten IoT Hub ha inom regionen genom att implementera redundans i nästan alla lager av tjänsten. Serviceavtalet som publiceras av IoT Hub tjänsten uppnås genom att dessa redundans används. Inget ytterligare arbete krävs av utvecklarna av en IoT-lösning för att dra nytta av dessa FUNKTIONER för ha. Även IoT Hub erbjuder en relativt hög drifttidsgaranti kan tillfälliga fel fortfarande förväntas som med alla distribuerade databehandlingsplattformar. Om du precis har börjat migrera dina lösningar till molnet från en lokal lösning måste ditt fokus övergå från att optimera "mean time between failures" (medeltid mellan fel) till "mean time to recover" (medeltid för återställning). Med andra ord ska tillfälliga fel betraktas som normala när du arbetar med molnet i mixen. Lämpliga återförsöksprinciper måste vara inbyggda i de komponenter som interagerar med ett molnprogram för att hantera tillfälliga fel.

Tillgänglighetszoner

Det finns en 99,9 % Serviceavtal för IoT Hub och du kan läsa serviceavtalet. I det fullständigaAzure-serviceavtalet förklaras den garanterade tillgängligheten för Azure som helhet.

IoT Hub stöder Tillgänglighetszoner. En tillgänglighetszon är ett erbjudande med hög tillgänglighet som skyddar dina program och data mot datacenterfel. En region med stöd för tillgänglighetszoner består av tre zoner som stöder den regionen. Varje zon tillhandahåller ett eller flera datacenter på en unik fysisk plats med oberoende ström, kylning och nätverk. Detta ger replikering och redundans inom regionen. Stöd för tillgänglighetszoner för IoT Hub aktiveras automatiskt för nya IoT Hub resurser som skapas i följande Azure-regioner:

• Australien, östra
• Brasilien, södra
• Kanada, centrala
• Central US
• Frankrike, centrala
• USA, västra 2
• Japan, östra
• Norra Europa
• Sydostasien
• Storbritannien, södra

Dr i flera regioner

Det kan finnas några sällsynta situationer när ett datacenter upplever längre avbrott på grund av strömavbrott eller andra fel som rör fysiska tillgångar. Sådana händelser är ovanliga när ha-funktionen inom regionen som beskrivs ovan kanske inte alltid hjälper. IoT Hub flera lösningar för att återställa från sådana utökade avbrott.

Återställningsalternativen som är tillgängliga för kunder i en sådan situation är Microsoft-initierad redundans och manuell redundans. Den grundläggande skillnaden mellan de två är att Microsoft initierar det första och att användaren initierar det senare. Manuell redundans ger dessutom ett lägre mål för återställningstid (RTO) jämfört med microsoftinitierad redundans. De specifika mål för program för program som erbjuds med varje alternativ beskrivs i avsnitten nedan. När något av dessa alternativ för att utföra redundans för en IoT-hubb från dess primära region används, blir hubben helt funktionell i motsvarande geoparade Azure-region.

Båda dessa redundansalternativ erbjuder följande mål för återställningspunkt (ÅTERSTÄLLNINGSPUNKT):

¹ Meddelanden från moln till enhet och överordnade jobb återställs inte som en del av manuell redundans.

När redundansåtgärden för IoT Hub har slutförts förväntas alla åtgärder från enhets- och backend-programmen fortsätta att fungera utan manuella åtgärder. Det innebär att meddelanden från enhet till moln bör fortsätta att fungera och att hela enhetsregistret är intakt. Händelser som genereras via Event Grid kan användas via samma prenumeration(er) som konfigurerats tidigare så länge de Event Grid prenumerationerna fortsätter att vara tillgängliga. Ingen ytterligare hantering krävs för anpassade slutpunkter.

Microsoft-initierad redundans

Microsofts microsoftinitierade redundans används i sällsynta fall för att redundanskoppla alla IoT-hubbar från en berörd region till motsvarande geoparade region. Den här processen är ett standardalternativ (inget sätt för användare att avanmäla sig) och kräver ingen åtgärd från användaren. Microsoft förbehåller sig rätten att fastställa när det här alternativet ska användas. Den här mekanismen omfattar inte ett användarmedgivande innan användarens hubb har fördr dess vid fel. Microsoft-initierad redundans har ett mål för återställningstid (RTO) på 2–26 timmar.

Det stora RTO:et beror på att Microsoft måste utföra redundansåtgärden åt alla berörda kunder i den regionen. Om du kör en mindre viktig IoT-lösning som kan klara ett driftstopp på ungefär en dag är det ok att du är beroende av det här alternativet för att uppfylla de övergripande målen för haveriberedskap för din IoT-lösning. Den totala tiden för körningsåtgärder att bli fullt fungerande när den här processen har utlösts beskrivs i avsnittet "Tid för återställning".

Manuell redundans

Om dina affärsupptidsmål inte uppfylls av det RTO som Microsoft initierade redundans för kan du använda manuell redundans för att utlösa redundansen själv. Det RTO som använder det här alternativet kan vara mellan 10 minuter och ett par timmar. RTO:t är för närvarande en funktion för antalet enheter som registrerats mot IoT Hub-instansen som är överförd. Du kan förvänta dig att RTO för en hubb som är värd för cirka 100 000 enheter ligger i en bollarspark på 15 minuter. Den totala tiden för körningsåtgärder att bli fullt fungerande när den här processen har utlösts beskrivs i avsnittet "Tid för återställning".

Alternativet för manuell redundans är alltid tillgängligt för användning oavsett om den primära regionen har driftstopp eller inte. Det här alternativet kan därför potentiellt användas för att utföra planerade redundanser. Ett exempel på hur planerade redundanser används är att utföra periodiska redundansgranskningar. En varning är dock att en planerad redundansåtgärd resulterar i ett driftstopp för hubben för perioden som definieras av RTO för det här alternativet, och även resulterar i en dataförlust enligt definitionen i RPO-tabellen ovan. Du kan överväga att konfigurera en IoT Hub-testinstans för att regelbundet använda alternativet för planerad redundans för att få förtroende för din förmåga att få igång dina lösningar från början till slut när en verklig katastrof inträffar.

Manuell redundans är tillgängligt utan extra kostnad för IoT-hubbar som skapats efter den 18 maj 2017

Stegvisa instruktioner finns i Självstudie: Utföra manuell redundans för en IoT-hubb

Manuell redundans och händelsehubb

Som tidigare nämnts i avsnittet Varning ändras det Event Hub-kompatibla namnet och slutpunkten för den inbyggda IoT Hub händelser efter manuell redundansväxling. Det beror på att Event Hub-klienten inte har insyn i IoT Hub händelser. Samma sak gäller för andra molnbaserade klienter, till exempel Functions och Azure Stream Analytics. Om du vill hämta slutpunkten och namnet kan du använda Azure Portal eller använda ett inkluderat exempel.

Använda portalen

Mer information om hur du använder portalen för att hämta den Event Hub-kompatibla slutpunkten och det Event Hub-kompatibla namnet finns i Läsa från den inbyggda slutpunkten.

Använd det inkluderade exemplet

Om du vill använda IoT Hub-anslutningssträngen för att återta den Event Hub-kompatibla slutpunkten använder du ett exempel som finns på som visar hur du använder IoT Hub-anslutningssträngen för att återta den https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs EventHub-kompatibla slutpunkten. Kodexe exempel använder anslutningssträngen för att hämta den nya event hub-slutpunkten och återupprätta anslutningen. Du måste ha Visual Studio installerat.

Köra testtest

Testtest ska inte utföras på IoT-hubbar som används i produktionsmiljöerna.

Använd inte manuell redundans för att migrera IoT Hub till en annan region

Manuell redundans bör inte användas som en mekanism för att permanent migrera din hubb mellan de geoparade Azure-regionerna. Detta ökar svarstiden för de åtgärder som utförs mot IoT-hubben från enheter som finns i den gamla primära regionen.

Återställning efter fel

Du kan växla tillbaka till den gamla primära regionen genom att utlösa redundansåtgärden en annan gång. Om den ursprungliga redundansåtgärden utfördes för att återställa från ett utökat avbrott i den ursprungliga primära regionen rekommenderar vi att hubben växlas tillbaka till den ursprungliga platsen när platsen har återställts från avbrottsläget.

Tid för återställning

Även om FQDN (och därmed anslutningssträngen) för IoT Hub-instansen förblir samma efter redundans, ändras den underliggande IP-adressen. Därför kan den totala tiden för körningsåtgärder som utförs mot din IoT Hub-instans att bli fullt fungerande efter att redundansen har utlösts uttryckas med hjälp av följande funktion.

Tid för återställning = RTO [10 min–2 timmar för manuell redundans | 2–26 timmar för Microsoft-initierad redundans] + DNS-spridningsfördröjning + tid det tar för klientprogrammet att uppdatera cachelagrade IoT Hub IP-adresser.

Uppnå ha för flera regioner

Om dina affärsupptidsmål inte uppfylls av det RTO som antingen Microsoft-initierad redundans eller manuell redundans erbjuder, bör du överväga att implementera en automatisk redundansmekanism per enhet mellan regioner. En fullständig behandling av distributions topologier i IoT-lösningar ligger utanför omfånget för den här artikeln. I artikeln beskrivs den regionala distributionsmodellen för redundans för hög tillgänglighet och haveriberedskap.

I en regional redundansmodell körs lösningens backend främst på en datacenterplats. En sekundär IoT-hubb och -backend distribueras på en annan datacenterplats. Om IoT-hubben i den primära regionen drabbas av ett avbrott eller nätverksanslutningen från enheten till den primära regionen avbryts, använder enheterna en sekundär tjänstslutpunkt. Du kan förbättra lösningens tillgänglighet genom att implementera en redundansmodell mellan regioner i stället för att hålla dig inom en enda region.

För att implementera en regional redundansmodell med IoT Hub måste du utföra följande steg på hög nivå:

• En sekundär IoT-hubb och enhetsroutningslogik: Om tjänsten i din primära region avbryts måste enheterna börja ansluta till den sekundära regionen. Eftersom de flesta tjänster är tillståndsmedvetna är det vanligt att lösningsadministratörer utlöser redundans mellan regioner. Det bästa sättet att kommunicera den nya slutpunkten till enheter, samtidigt som kontrollen över processen bibehålls, är att de regelbundet kontrollerar en concierge-tjänst för den aktuella aktiva slutpunkten. Concierge-tjänsten kan vara en webbapp som replikeras och hålls åtkomlig med dns-omdirigeringstekniker (till exempel med hjälp av Azure Traffic Manager).

  Anteckning

  IoT Hub-tjänsten är inte en slutpunktstyp som stöds i Azure Traffic Manager. Rekommendationen är att integrera den föreslagna concierge-tjänsten med Azure Traffic Manager genom att implementera API:et för slutpunktshälsoavsökning.

• Replikering av identitetsregistret: För att kunna användas måste den sekundära IoT-hubben innehålla alla enhetsidentiteter som kan ansluta till lösningen. Lösningen bör behålla geo-replikerade säkerhetskopior av enhetsidentiteter och ladda upp dem till den sekundära IoT-hubben innan du växlar den aktiva slutpunkten för enheterna. Exportfunktionen för enhetsidentiteter i IoT Hub användbar i den här kontexten. Mer information finns i IoT Hub utvecklarhandbok – identitetsregistret.

• Sammanslagningslogik: När den primära regionen blir tillgänglig igen måste alla tillstånd och data som har skapats på den sekundära platsen migreras tillbaka till den primära regionen. Det här tillståndet och data gäller främst enhetsidentiteter och programmetadata, som måste slås samman med den primära IoT-hubben och andra programspecifika butiker i den primära regionen.

För att förenkla det här steget bör du använda idempotenta åtgärder. Idempotenta åtgärder minimerar sidoeffekterna från den slutliga konsekventa fördelningen av händelser och från dubbletter eller leverans av händelser i ordningsföljd. Dessutom bör programlogiken utformas för att tolerera potentiella inkonsekvenser eller något inkonsekvent tillstånd. Den här situationen kan inträffa på grund av den ytterligare tid det tar för systemet att återställa baserat på mål för återställningspunkt (RPO).

Välj rätt alternativ för ha/dr

Här är en sammanfattning av alternativen för ha/dr som presenteras i den här artikeln och som kan användas som referensram för att välja rätt alternativ som fungerar för din lösning.

Nästa steg

• Vad är Azure IoT Hub?
• Kom igång med IoT Hubs (snabbstart)
• Självstudie: Utföra manuell redundans för en IoT-hubb