Hoge beschikbaarheid en herstel na noodgevallen van IoT Hub

Als eerste stap bij het implementeren van een flexibele IoT-oplossing moeten architecten, ontwikkelaars en bedrijfseigenaren de bedrijfsdoelen definiëren voor de oplossingen die ze bouwen. Deze doelstellingen kunnen voornamelijk worden gedefinieerd op basis van specifieke bedrijfsdoelstellingen voor elk scenario. In deze context wordt in het artikel Technische richtlijnen voor Azure Business Continuity een algemeen framework beschreven om u te helpen nadenken over bedrijfscontinuïteit en herstel na noodherstel. Het document Herstel na nood en hoge beschikbaarheid voor Azure-toepassingen bevat architectuur richtlijnen voor strategieën voor Azure-toepassingen voor hoge beschikbaarheid (HA) en herstel na noodherstel (DR).

In dit artikel worden de ha- en DR-functies besproken die specifiek worden aangeboden door de IoT Hub service. De algemene gebieden die in dit artikel worden besproken, zijn:

• Ha binnen regio's
• Regio-overschrijdende DR
• Ha in regio-overschrijdende regio bereiken

Afhankelijk van de uptimedoelen die u definieert voor uw IoT-oplossingen, moet u bepalen welke van de onderstaande opties het beste bij uw bedrijfsdoelstellingen passen. Het opnemen van een van deze alternatieven voor ha/dr in uw IoT-oplossing vereist een zorgvuldige evaluatie van de afwegingen tussen de:

• Flexibiliteitsniveau dat u nodig hebt
• Complexiteit van implementatie en onderhoud
• Gevolgen voor COGS

Ha binnen regio's

De IoT Hub service biedt intraregio-HA door redundantie in bijna alle lagen van de service te implementeren. De SLA die is gepubliceerd door IoT Hub service wordt bereikt door gebruik te maken van deze redundantie. De ontwikkelaars van een IoT-oplossing hebben geen extra werk nodig om te profiteren van deze ha-functies. Hoewel IoT Hub redelijk hoge uptimegarantie biedt, kunnen er nog steeds tijdelijke fouten worden verwacht, zoals bij elk gedistribueerd computingplatform. Als u net begint met het migreren van uw oplossingen naar de cloud vanuit een on-premises oplossing, moet u zich richten op het optimaliseren van 'gemiddelde tijd tussen fouten' naar 'gemiddelde tijd om te herstellen'. Met andere woorden, tijdelijke fouten moeten als normaal worden beschouwd tijdens het werken met de cloud in de combinatie. Het juiste beleid voor opnieuw proberen moet worden ingebouwd in de onderdelen die communiceren met een cloudtoepassing om tijdelijke fouten op te kunnen.

Beschikbaarheidszones

Er is een 99,9% Service Level Agreement voor IoT Hub en u kunt de SLA lezen. In de volledige Azure SLA wordt de gegarandeerde beschikbaarheid van Azure als geheel uitgelegd.

IoT Hub ondersteunt Beschikbaarheidszones. Een beschikbaarheidszone is een aanbieding voor hoge beschikbaarheid die uw toepassingen en gegevens beschermt tegen datacenterfouten. Een regio met ondersteuning voor beschikbaarheidszones bestaat uit drie zones die die regio ondersteunen. Elke zone biedt een of meer datacenters elk op een unieke fysieke locatie met onafhankelijke voeding, koeling en netwerken. Dit biedt replicatie en redundantie binnen de regio. Ondersteuning van beschikbaarheidszone voor IoT Hub wordt automatisch ingeschakeld voor nieuwe IoT Hub resources die zijn gemaakt in de volgende Azure-regio's:

• Australië - oost
• Brazilië - zuid
• Canada - midden
• VS - centraal
• Frankrijk - centraal
• VS - west 2
• Japan - oost
• Europa - noord
• Azië - zuidoost
• Verenigd Koninkrijk Zuid

Regio-overschrijdende DR

Er kunnen enkele zeldzame situaties zijn waarin een datacenter uitgebreide storingen ervaart als gevolg van stroomstoringen of andere storingen met betrekking tot fysieke activa. Dergelijke gebeurtenissen zijn zeldzaam, waarbij de hierboven beschreven mogelijkheid voor een intra-regio-HA niet altijd kan helpen. IoT Hub biedt meerdere oplossingen voor het herstellen van dergelijke uitgebreide uitval.

De herstelopties die beschikbaar zijn voor klanten in een dergelijke situatie zijn door Microsoft geïnitieerde failover en handmatige failover. Het fundamentele verschil tussen de twee is dat Microsoft eerstgenoemde initieert en dat de gebruiker het tweede initieert. Handmatige failover biedt ook een lagere RTO (Recovery Time Objective) in vergelijking met de door Microsoft geïnitieerde failoveroptie. De specifieke RTO's die bij elke optie worden aangeboden, worden in de onderstaande secties besproken. Wanneer een van deze opties wordt gebruikt om een failover van een IoT-hub uit te voeren vanuit de primaire regio, wordt de hub volledig functioneel in de bijbehorende geografisch gekoppelde Azure-regio.

Beide failoveropties bieden de volgende herstelpuntdoelstellingen (RPO's):

¹ Cloud-naar-apparaat-berichten en bovenliggende taken worden niet hersteld als onderdeel van handmatige failover.

Zodra de failoverbewerking voor de IoT-hub is voltooid, wordt verwacht dat alle bewerkingen van het apparaat en de back-endtoepassingen zonder handmatige tussenkomst blijven werken. Dit betekent dat uw apparaat-naar-cloud-berichten moeten blijven werken en dat het hele apparaatregister intact blijft. Gebeurtenissen die via Event Grid worden ingediend, kunnen worden gebruikt via dezelfde abonnement(en) die eerder zijn geconfigureerd, zolang deze Event Grid beschikbaar blijven. Er is geen extra verwerking vereist voor aangepaste eindpunten.

Door Microsoft geïnitieerde failover

Door Microsoft geïnitieerde failover wordt in zeldzame situaties door Microsoft gebruikt om een failover uit te brengen van alle IoT-hubs van een getroffen regio naar de bijbehorende geografisch gekoppelde regio. Dit proces is een standaardoptie (geen manier voor gebruikers om af te zien) en vereist geen tussenkomst van de gebruiker. Microsoft behoudt zich het recht voor om te bepalen wanneer deze optie wordt gebruikt. Dit mechanisme heeft geen toestemming van de gebruiker nodig voordat er een failed over de hub van de gebruiker wordt gedaan. Door Microsoft geïnitieerde failover heeft een RTO (Recovery Time Objective) van 2-26 uur.

De grote RTO is omdat Microsoft de failoverbewerking moet uitvoeren namens alle betrokken klanten in die regio. Als u een minder kritieke IoT-oplossing gebruikt die een downtime van ongeveer een dag kan hebben, is het geen probleem om afhankelijk te zijn van deze optie om te voldoen aan de algemene doelstellingen voor herstel na noodherstel voor uw IoT-oplossing. De totale tijd die nodig is om runtimebewerkingen volledig operationeel te maken zodra dit proces is geactiveerd, wordt beschreven in de sectie Tijd om te herstellen.

Handmatige failover

Als niet aan uw bedrijfsbedrijfsdoelen wordt voldaan door de RTO die door Microsoft geïnitieerde failover biedt, kunt u overwegen handmatige failover te gebruiken om het failoverproces zelf te activeren. De RTO die deze optie gebruikt, kan tussen de 10 minuten en een paar uur zijn. De RTO is momenteel een functie van het aantal apparaten dat is geregistreerd voor het IoT Hub-exemplaar dat wordt overgenomen. U kunt verwachten dat de RTO voor een hub die als host voor ongeveer 100.000 apparaten wordt gebruikt, binnen 15 minuten is. De totale tijd die nodig is om runtimebewerkingen volledig operationeel te maken zodra dit proces is geactiveerd, wordt beschreven in de sectie Tijd om te herstellen.

De optie voor handmatige failover is altijd beschikbaar voor gebruik, ongeacht of de primaire regio te maken heeft met downtime of niet. Daarom kan deze optie mogelijk worden gebruikt om geplande failovers uit te voeren. Een voorbeeld van het gebruik van geplande failovers is het uitvoeren van periodieke failover-oefeningen. Een waarschuwing is echter dat een geplande failoverbewerking resulteert in downtime voor de hub voor de periode die is gedefinieerd door de RTO voor deze optie, en ook resulteert in een gegevensverlies zoals gedefinieerd in de bovenstaande RPO-tabel. U kunt overwegen om een IoT Hub-test-exemplaar in te stellen om periodiek de optie voor geplande failover uit te oefenen, om vertrouwen te krijgen in de mogelijkheid om uw end-to-end-oplossingen actief te maken wanneer zich een echt noodlot voor doet.

Handmatige failover is beschikbaar zonder extra kosten voor IoT-hubs die zijn gemaakt na 18 mei 2017

Zie Zelfstudie: Handmatige failover uitvoeren voor een IoT-hub voor stapsgewijse instructies

Handmatige failover en Event Hub

Zoals eerder vermeld in de sectie Waarschuwing, wijzigen de event hub-compatibele naam en het eindpunt van de IoT Hub ingebouwde gebeurtenissen-eindpunt na handmatige failover. Dit komt doordat de Event Hub-client geen inzicht heeft in IoT Hub gebeurtenissen. Hetzelfde geldt voor andere cloud-clients, zoals Functions en Azure Stream Analytics. Als u het eindpunt en de naam wilt ophalen, kunt u de Azure Portal of een opgenomen voorbeeld gebruiken.

Gebruik de portal

Zie Lezen van het ingebouwde eindpunt voor meer informatie over het gebruik van de portal om het Event Hub-compatibele eindpunt en de event hub-compatibele naam op te halen.

Het opgenomen voorbeeld gebruiken

Als u de IoT Hub connection string wilt gebruiken om het event hub-compatibele eindpunt te heroveren, gebruikt u een voorbeeld in dat laat zien hoe u de IoT Hub connection string kunt gebruiken om het EventHub-compatibele eindpunt opnieuw samen te https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs krijgen. In het codevoorbeeld wordt de connection string om het nieuwe Event Hub-eindpunt op te halen en de verbinding opnieuw tot stand te brengen. U moet Visual Studio geïnstalleerd.

Testoefeningen uitvoeren

Testoefeningen mogen niet worden uitgevoerd op IoT-hubs die worden gebruikt in uw productieomgevingen.

Gebruik geen handmatige failover om IoT Hub te migreren naar een andere regio

Handmatige failover mag niet worden gebruikt als een mechanisme om uw hub permanent te migreren tussen de geografisch gekoppelde Azure-regio's. Dit verhoogt de latentie voor de bewerkingen die worden uitgevoerd op de IoT-hub vanaf apparaten in de oude primaire regio.

Failback

Een failback naar de oude primaire regio kan worden bereikt door de failoveractie een andere keer te activeren. Als de oorspronkelijke failoverbewerking is uitgevoerd om te herstellen na een uitgebreide storing in de oorspronkelijke primaire regio, wordt u aangeraden een failback van de hub naar de oorspronkelijke locatie uit te voeren zodra die locatie is hersteld na de storing.

Tijd om te herstellen

Hoewel de FQDN (en dus de connection string) van het IoT Hub-exemplaar dezelfde blijft na een failover, verandert het onderliggende IP-adres. Daarom kan de totale tijd voor de runtime-bewerkingen die worden uitgevoerd op uw IoT Hub-exemplaar volledig operationeel worden nadat het failoverproces is geactiveerd, worden uitgedrukt met behulp van de volgende functie.

Tijd om te herstellen = RTO [10 min- 2 uur voor handmatige failover | 2- 26 uur voor door Microsoft geïnitieerde failover] + vertraging bij DNS-doorzetting + Tijd die de clienttoepassing nodig heeft om elk IoT Hub IP-adres in de cache te vernieuwen.

Regio-overschrijdende ha

Als de RTO niet voldoet aan uw bedrijfsbedrijfsdoelen die ofwel door Microsoft geïnitieerde failover- of handmatige failover-opties bieden, kunt u overwegen een mechanisme voor automatische failover per apparaat tussen regio's te implementeren. Een volledige behandeling van implementatietopologies in IoT-oplossingen valt buiten het bereik van dit artikel. In dit artikel wordt het implementatiemodel voor regionale failovers beschreven voor hoge beschikbaarheid en herstel na noodherstel.

In een regionaal failovermodel wordt de back-end van de oplossing voornamelijk uitgevoerd op één datacenterlocatie. Een secundaire IoT-hub en back-end worden geïmplementeerd op een andere datacenterlocatie. Als de IoT-hub in de primaire regio te maken heeft met een storing of als de netwerkconnectiviteit van het apparaat naar de primaire regio wordt onderbroken, gebruiken apparaten een secundair service-eindpunt. U kunt de beschikbaarheid van oplossingen verbeteren door een failovermodel tussen regio's te implementeren in plaats van binnen één regio te blijven.

Als u op hoog niveau een regionaal failovermodel wilt implementeren met IoT Hub, moet u de volgende stappen uitvoeren:

• Een secundaire IoT-hub en routeringslogica voor apparaten: als de service in uw primaire regio wordt onderbroken, moeten apparaten verbinding gaan maken met uw secundaire regio. Gezien de statusbewuste aard van de meeste betrokken services, is het gebruikelijk dat oplossingsbeheerders het failoverproces tussen regio's activeren. De beste manier om het nieuwe eindpunt te communiceren met apparaten, terwijl u de controle over het proces behoudt, is door ze regelmatig een Concierge-service te laten controleren op het huidige actieve eindpunt. De Concierge-service kan een webtoepassing zijn die wordt gerepliceerd en bereikbaar blijft met behulp van DNS-omleidingstechnieken (bijvoorbeeld met behulp van Azure Traffic Manager).

  Notitie

  IoT Hub-service is geen ondersteund eindpunttype in Azure Traffic Manager. Het wordt aanbevolen om de voorgestelde Concierge-service te integreren met Azure Traffic Manager door de eindpunttest-API te implementeren.

• Replicatie van identiteitsregister: om te kunnen worden gebruikt, moet de secundaire IoT-hub alle apparaat-id's bevatten die verbinding kunnen maken met de oplossing. De oplossing moet geo-gerepliceerde back-ups van apparaat-id's behouden en deze uploaden naar de secundaire IoT-hub voordat u overschakelt naar het actieve eindpunt voor de apparaten. De exportfunctionaliteit van apparaat-IoT Hub is nuttig in deze context. Zie de ontwikkelaarshandleiding IoT Hub identiteitsregister voor meer informatie.

• Samenvoegingslogica: wanneer de primaire regio weer beschikbaar is, moeten alle statussen en gegevens die in de secundaire site zijn gemaakt, terug worden gemigreerd naar de primaire regio. Deze status en gegevens hebben voornamelijk betrekking op apparaat-id's en toepassingsmetagegevens, die moeten worden samengevoegd met de primaire IoT-hub en andere toepassingsspecifieke winkels in de primaire regio.

Gebruik idempotente bewerkingen om deze stap te vereenvoudigen. Idempotente bewerkingen minimaliseren de neveneffecten van de uiteindelijke consistente distributie van gebeurtenissen en van duplicaten of out-of-order levering van gebeurtenissen. Bovendien moet de toepassingslogica worden ontworpen om mogelijke inconsistenties of een enigszins verouderd status te tolereren. Deze situatie kan optreden vanwege de extra tijd die het duurt om het systeem te herstellen op basis van herstelpuntdoelstellingen (RPO).

De juiste optie voor ha/dr kiezen

Hier volgt een samenvatting van de opties voor ha/dr in dit artikel die kunnen worden gebruikt als referentiekader om de juiste optie te kiezen die voor uw oplossing werkt.

Volgende stappen

• Wat is Azure IoT Hub?
• Aan de slag met IoT Hubs (quickstart)
• Zelfstudie: Handmatige failover uitvoeren voor een IoT-hub