Delen via

Betrouwbaarheid in Azure IoT Hub

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure IoT Hub beschreven. Het omvat tolerantie binnen de regio via beschikbaarheidszones en implementaties in meerdere regio's.

Betrouwbaarheid is een gedeelde verantwoordelijkheid tussen u en Microsoft. U kunt deze handleiding gebruiken om te bepalen welke betrouwbaarheidsopties voldoen aan uw specifieke bedrijfsdoelstellingen en uptimedoelstellingen.

Wanneer u betrouwbaarheidsopties evalueert, moet u ook de afwegingen tussen de volgende items evalueren:

  • Tolerantieniveau dat u nodig hebt
  • Implementatie- en onderhoudscomplexiteit
  • Kosten voor het implementeren van verschillende opties

Zie Reliability trade-offs voor meer informatie.

Tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

IoT Hub biedt een redelijk hoge uptime-garantie, maar tijdelijke fouten kunnen optreden in elk gedistribueerd computingplatform. Als u tijdelijke fouten wilt afhandelen, bouwt u de juiste patronen voor opnieuw proberen in onderdelen die communiceren met cloudtoepassingen.

Ondersteuning voor beschikbaarheidszones

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

IoT Hub ondersteunt twee verschillende typen ondersteuning voor beschikbaarheidszones:

  • Zoneredundantie voor gegevens, die automatisch gegevens repliceert tussen meerdere beschikbaarheidszones voor de onderliggende opslagonderdelen waarin het register voor apparaat-id's en apparaat-naar-cloud-berichten worden opgeslagen.

  • Zoneredundantie voor berekening, die tolerantie biedt in de onderdelen die verantwoordelijk zijn voor het beheren van de apparaten en routeringsberichten.

Ondersteuning voor regio

Het type ondersteuning voor beschikbaarheidszones voor uw IoT-hub is afhankelijk van de regio waarin deze is geïmplementeerd.

Regio Zoneredundantie voor gegevens Zoneredundantie voor berekening
Oost-Australië Ja Ja
Brazilië Zuid Ja Ja
Centraal Canada Ja Ja
Centraal-India Nee Ja
Centrale Verenigde Staten Ja Ja
Oostelijke VS Nee Ja
Centraal Frankrijk Ja Ja
West-Centraal Duitsland Ja Ja
Oost-Japan Ja Ja
Centraal-Korea Nee Ja
Europa - noord Ja Ja
Noorwegen - oost Nee Ja
Qatar Centrale Nee Ja
Zuid-Centraal Verenigde Staten Nee Ja
Zuidoost-Azië Ja Ja
Verenigd Koninkrijk Zuid Ja Ja
West-Europa Nee Ja
Westelijke Verenigde Staten 2 Ja Ja
Westelijke VS 3 Nee Ja

IoT-hubs die u maakt in regio's die niet in deze lijst staan, zijn niet bestand tegen zonestoringen.

Kosten

Er zijn geen extra kosten verbonden aan zoneredundantie met IoT Hub.

Ondersteuning voor beschikbaarheidszones configureren

IoT Hub-resources ondersteunen automatisch zoneredundantie wanneer ze worden geïmplementeerd in ondersteunde regio's. Er is geen verdere configuratie vereist.

Normale bewerkingen

In deze sectie wordt beschreven wat u kunt verwachten wanneer IoT Hub-resources zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

  • Gegevensreplicatie tussen zones: Wanneer uw IoT-hub wordt geïmplementeerd in een regio die zoneredundantie voor gegevens ondersteunt, worden wijzigingen in gegevens automatisch tussen beschikbaarheidszones gerepliceerd. Replicatie vindt synchroon plaats.

  • Verkeersroutering tussen zones: Wanneer uw IoT-hub wordt geïmplementeerd in een regio die zoneredundantie voor rekenonderdelen ondersteunt, worden aanvragen doorgestuurd naar een primair exemplaar van de service in een van de beschikbaarheidszones. Azure selecteert automatisch het actieve exemplaar en de actieve zone.

Ontspanervaring

In deze sectie wordt beschreven wat u kunt verwachten wanneer IoT Hub-resources zijn geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: De IoT Hub-service is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten.

  • Actieve aanvragen: Tijdens een zonefout kunnen actieve aanvragen worden verwijderd. Uw clients en apparaten moeten voldoende logica voor opnieuw proberen hebben geïmplementeerd om tijdelijke fouten af te handelen.

  • Verwachte gegevensverlies: Wanneer uw IoT-hub wordt geïmplementeerd in een regio die zoneredundantie voor gegevens ondersteunt, mag een zonefout geen gegevensverlies veroorzaken.

  • Verwachte downtime: Wanneer uw IoT-hub wordt geïmplementeerd in een regio die zoneredundantie ondersteunt voor zowel reken- als gegevensonderdelen, mag een zonefout geen downtime veroorzaken voor uw IoT Hub-resources.

  • Verkeer omleiden: Wanneer uw IoT-hub wordt geïmplementeerd in een regio die zoneredundantie voor rekenonderdelen ondersteunt, detecteert IoT Hub het verlies van de zone. Vervolgens worden nieuwe aanvragen automatisch omgeleid naar een nieuw primair exemplaar van de service in een van de gezonde beschikbaarheidszones.

terugval

Wanneer de beschikbaarheidszone wordt hersteld, herstelt IoT Hub automatisch exemplaren in de beschikbaarheidszone en routeert het verkeer tussen uw exemplaren als normaal.

Testen voor zonefouten

Omdat IoT Hub verkeersroutering, failover en failback volledig beheert voor zonefouten, hoeft u geen processen voor fouten in de beschikbaarheidszone te valideren of verdere invoer op te geven.

Ondersteuning voor meerdere regio's

IoT Hub is een service met één regio. Als de regio niet meer beschikbaar is, zijn uw IoT Hub-resources ook niet beschikbaar.

Als uw resources zich echter in een gekoppelde regio bevinden, worden de gegevens van uw IoT-hub gerepliceerd naar de gekoppelde regio.

Uw IoT-hub kan in de volgende scenario's een failover naar de gekoppelde regio uitvoeren:

  • Door de klant geïnitieerde failover: U kunt handmatige failover naar de gekoppelde regio zelf activeren, ongeacht of de regio downtime ondervindt of niet. U kunt deze methode gebruiken om geplande failovers en drills uit te voeren.

  • Door Microsoft geïnitieerde failover: Als een regio verloren gaat, kan Microsoft een failover van IoT-hubs initiëren naar de gekoppelde regio. Microsoft zal echter waarschijnlijk geen failover initiëren, behalve na een aanzienlijke vertraging en op basis van best effort. Failover van IoT Hub-resources kan zich op een ander moment voordoen dan failover van andere Azure-services. Dit proces is een standaardoptie en vereist geen tussenkomst van u.

Als resources zich in een niet-verspreide regio bevinden, repliceert Microsoft geen configuratie en gegevens tussen regio's en is er geen ingebouwde failover tussen regio's. U kunt echter afzonderlijke resources implementeren in meerdere regio's. In dit scenario is het uw verantwoordelijkheid om replicatie, verkeersdistributie en failover te beheren.

Als uw IoT-hub zich in een niet-gereairede regio bevindt of als het standaardreplicatie- en failovergedrag niet aan uw behoeften voldoet, kunt u alternatieve benaderingen voor meerdere regio's gebruiken om failovers te plannen en te initiëren.

Ondersteuning voor regio

Standaardreplicatie en failover worden alleen ondersteund in regio's die zijn gekoppeld.

Behoeften

Gekoppelde regioreplicatie en failoveropties zijn beschikbaar voor alle IoT Hub-lagen.

Overwegingen

Gebruik door de klant geïnitieerde failover niet om uw hub permanent te migreren tussen de gekoppelde Azure-regio's. Over het algemeen bevinden apparaten zich dicht bij de primaire regio van de hub. Als u uw hub naar de secundaire regio verplaatst, neemt de latentie toe voor bewerkingen tussen de apparaten en de IoT-hub op de secundaire locatie.

Kosten

Voor hubs in regio's die zijn gekoppeld, zijn er geen extra kosten voor gegevensreplicatie of failover tussen de regio's.

Als uw IoT-hub zich in een niet-geairede regio bevindt, raadpleegt u alternatieve benaderingen voor meerdere regio's voor mogelijke kosteninformatie.

Replicatie configureren en voorbereiden op failover

Standaard wordt replicatie van gegevens in meerdere regio's automatisch geconfigureerd wanneer u een IoT-hub in een gekoppelde regio maakt. Dit proces is een standaardoptie en vereist geen tussenkomst van u. In regio's, met uitzondering van Brazilië - zuid en Zuidoost-Azië (Singapore), worden uw klantgegevens niet opgeslagen of verwerkt buiten de geografie waar u het service-exemplaar implementeert.

Als uw IoT-hub zich in de regio's Brazilië - zuid of Zuidoost -Azië (Singapore) bevindt, kunt u gegevensreplicatie uitschakelen en afmelden voor failover. Zie Herstel na noodgevallen uitschakelen (DR) voor meer informatie.

Als uw IoT-hub zich in een niet-geairede regio bevindt, moet u uw eigen replicatie- en failover-benadering voor meerdere regio's plannen. Zie Alternatieve benaderingen voor meerdere regio's voor meer informatie.

Normale bewerkingen

In deze sectie wordt beschreven wat u kunt verwachten wanneer een IoT-hub is geconfigureerd voor replicatie en failover tussen regio's en de primaire regio operationeel is.

  • Gegevensreplicatie tussen regio's: Gegevens worden automatisch gerepliceerd naar de gekoppelde regio. Replicatie vindt asynchroon plaats, wat betekent dat er gegevensverlies wordt verwacht als er een failover plaatsvindt. Er is geen gegevensreplicatie tussen regio's voor IoT-hubs in niet-gepairede regio's.

  • Verkeersroutering tussen regio's: Bij normale bewerkingen stroomt verkeer alleen naar de primaire regio.

Regio-down-ervaring

In deze sectie wordt beschreven wat u kunt verwachten wanneer een IoT-hub is geconfigureerd voor replicatie en failover tussen regio's en er een storing is in de primaire regio.

  • Detectie en reactie: De verantwoordelijkheid voor het detecteren en reageren op een storing in de primaire regio kan variëren.

    • Door de klant geïnitieerde failover: U bent verantwoordelijk voor het detecteren van een regioverlies en het bepalen wanneer u een failover wilt uitvoeren. Zie Handmatige failover uitvoeren voor een IoT-hub voor meer informatie over het uitvoeren van door de klant geïnitieerde failover tussen gekoppelde regio's.

      Er gelden limieten voor hoe vaak u door de klant geïnitieerde failover of failback kunt uitvoeren:

      • Gebruikers mogen twee geslaagde failoverbewerkingen en twee geslaagde failbackbewerkingen per dag uitvoeren.

      • Aaneengesloten failover- of failbackbewerkingen zijn niet toegestaan. U moet één uur wachten tussen deze bewerkingen.

    • Door Microsoft geïnitieerde failover: Microsoft kan besluiten om een failover uit te voeren als de primaire regio verloren gaat. Dit proces kan enkele uren duren na het verlies van de primaire regio, of zelfs langer in sommige scenario's. Failover van IoT Hub-resources vindt mogelijk niet tegelijkertijd plaats als andere Azure-services.

  • Actieve aanvragen: Aanvragen die door de primaire regio worden verwerkt tijdens een failover, gaan waarschijnlijk verloren. Clients moeten aanvragen opnieuw proberen nadat de failover is voltooid.

  • Verwachte gegevensverlies: Voor regio's die zijn gekoppeld, worden gegevens asynchroon gerepliceerd naar de gekoppelde regio. Als gevolg hiervan wordt na een failover een aantal gegevensverlies verwacht. Dit proces is van toepassing op zowel door Microsoft beheerde als door de klant beheerde failovers. De volgende tabel bevat een overzicht van het beoogde herstelpunt (RPO) of verwacht gegevensverlies van elk type gegevens dat door IoT-hubs wordt opgeslagen.

    Gegevenstype RPO
    Identiteitsregister Gegevensverlies van 0-5 minuten
    Apparaatdubbelgegevens Gegevensverlies van 0-5 minuten
    Cloud-naar-apparaat-berichten 1 Gegevensverlies van 0-5 minuten
    Bovenliggende 1 en apparaattaken Gegevensverlies van 0-5 minuten
    Apparaat naar cloud berichten Alle ongelezen berichten gaan verloren
    Feedbackberichten van cloud-naar-apparaat Alle ongelezen berichten gaan verloren

    1 Cloud-naar-apparaat-berichten en bovenliggende taken worden niet hersteld als onderdeel van een failover die door de klant wordt geïnitieerd.

  • Verwachte downtime: De verwachte downtime tijdens de failover van de regio is afhankelijk van het failovertype.

    • Door de klant geïnitieerde failover: Verwacht ongeveer 10 minuten tot 2 uur downtime vanaf het moment dat de regio verloren gaat tot wanneer de resource operationeel is in de gekoppelde regio. Het aantal apparaten dat is geregistreerd voor het IoT Hub-exemplaar waarvoor een failover wordt uitgevoerd, is van invloed op de hersteltijd. U kunt de hersteltijd verwachten voor een hub die ongeveer 100.000 apparaten host, ongeveer 15 minuten.

    • Door Microsoft geïnitieerde failover: Verwacht ongeveer 2 tot 26 uur uitvaltijd vanaf het moment dat de regio verloren gaat tot wanneer de resource beschikbaar is in de gekoppelde regio.

      De hoge hersteltijd is omdat Microsoft de failover-bewerking moet uitvoeren namens alle betrokken klanten in die regio. Voor kritieke systemen moet u door de klant geïnitieerde failover gebruiken om minder downtime te bereiken. Als u echter een minder kritieke IoT-oplossing uitvoert die een downtime van ongeveer één dag kan ondersteunen, is het mogelijk om afhankelijk te zijn van de door Microsoft geïnitieerde optie om te voldoen aan de algemene DR-doelstellingen voor uw IoT-oplossing.

    • Voor beide failovertypen blijft de volledig gekwalificeerde domeinnaam van het IoT Hub-exemplaar hetzelfde na een failover, wat betekent dat de verbindingsreeks ook hetzelfde blijft. Omdat het onderliggende IP-adres echter verandert, moeten clients wachten tot DNS-records (Domain Name System) worden bijgewerkt voordat ze na een failover toegang hebben tot de IoT-hub.

      Belangrijk

      De IoT Hub SDK's plaatsen het IP-adres van de IoT-hub niet in de cache. Gebruikerscode-interfacing met de SDK's mag het IP-adres van de IoT-hub niet in de cache opslaan.

      Vanwege deze factoren kan de tijd voor de runtimebewerkingen die worden uitgevoerd op uw IoT Hub-exemplaar volledig operationeel worden nadat het failoverproces is uitgevoerd, worden uitgedrukt met behulp van de volgende functie:

      Tijd om te herstellen = RTO [10 minuten tot 2 uur voor door de klant geïnitieerde failover of 2 tot 26 uur voor door Microsoft geïnitieerde failover] + VERTRAGING van DNS-doorgifte + Tijd die de clienttoepassing nodig heeft om een ip-adres van de IoT-hub in de cache te vernieuwen

  • Verkeer omleiden: Tijdens het failoverproces werkt IoT Hub DNS-records bij zodat deze verwijst naar de gekoppelde regio. Alle volgende aanvragen worden verzonden naar de gekoppelde regio.

    Nadat de failoverbewerking voor de IoT-hub is voltooid, zullen alle bewerkingen van het apparaat en de back-endtoepassingen naar verwachting blijven werken zonder handmatige tussenkomst. Deze continuïteit zorgt ervoor dat uw apparaat-naar-cloud-berichten blijven werken en dat het hele apparaatregister intact is. Als u gebeurtenissen verzendt via Azure Event Grid, kunnen ze worden gebruikt via dezelfde abonnementen die u eerder hebt geconfigureerd zolang deze Event Grid-abonnementen beschikbaar blijven. Er is geen verdere verwerking vereist voor aangepaste eindpunten.

Configuratie na overstap vereist

Afhankelijk van waar u de berichten van uw IoT-hub routeert, moet u mogelijk extra stappen uitvoeren nadat de failover is voltooid.

  • Azure Event Hubs: De event hubs-compatibele naam en het eindpunt van het ingebouwde eindpunt voor gebeurtenissen van uw IoT-hub veranderen na een failover. Deze wijziging treedt op omdat de Event Hubs-client geen inzicht heeft in IoT Hub-gebeurtenissen.

    Wanneer u telemetrieberichten van het ingebouwde eindpunt ontvangt met behulp van de Event Hubs-client of gebeurtenisprocessorhost, gebruikt u de verbindingsreeks van de IoT-hub om de verbinding tot stand te brengen. Deze aanpak zorgt ervoor dat uw back-endtoepassingen blijven werken zonder handmatige tussenkomst na een failover.

    Als u de event Hubs-compatibele naam en het eindpunt in uw toepassing rechtstreeks gebruikt, moet u het nieuwe Event Hubs-compatibele eindpunt ophalen na een failover om door te gaan met bewerkingen. Als u het eindpunt en de naam wilt ophalen, kunt u Azure Portal of de .NET SDK gebruiken:

    • Azure Portal: Zie Verbinding maken met het ingebouwde eindpunt voor meer informatie over het gebruik van de portal om het event hubs-compatibele eindpunt en de event hubs-compatibele naam op te halen.

    • De .NET SDK: Gebruik de voorbeeldcode om de verbindingsreeks van de IoT Hub te gebruiken om het event Hubs-compatibele eindpunt opnieuw op te nemen. In dit codevoorbeeld wordt de verbindingsreeks gebruikt om het nieuwe Event Hubs-eindpunt op te halen en de verbinding opnieuw tot stand te brengen. Visual Studio moet zijn geïnstalleerd.

  • Azure Functions en Azure Stream Analytics: Als u Azure Functions of Stream Analytics gebruikt om verbinding te maken met het eindpunt voor ingebouwde gebeurtenissen, moet u het Event Hubs-eindpunt bijwerken waarmee de functie of taak verbinding maakt, volgens hetzelfde proces dat wordt beschreven in het voorgaande opsommingsteken. Voer vervolgens een actie Opnieuw opstarten uit omdat eventuele gebeurtenisstroomverschuivingen na een failover ongeldig worden.

  • Azure Storage: Wanneer u naar Azure Storage doorstuurt, vermeldt u eerst de blobs of bestanden. Herhaal ze vervolgens om ervoor te zorgen dat alle blobs of bestanden worden gelezen zonder dat partitionering wordt aangenomen. Het partitiebereik kan mogelijk veranderen tijdens een door Microsoft geïnitieerde failover of door de klant geïnitieerde failover. U kunt de List Blobs-API gebruiken om de lijst met blobs of de List Azure Data Lake Storage-API op te sommen voor de lijst met bestanden. Zie Azure Storage als routeringseindpunt voor meer informatie.

terugval

Als u een failback wilt uitvoeren naar de primaire regio, kunt u de failoveractie handmatig een tweede keer activeren. Het is belangrijk om de beperkingen te onthouden voor hoe vaak u een failover kunt uitvoeren.

Als de oorspronkelijke failoverbewerking is uitgevoerd om te herstellen na een uitgebreide storing in de oorspronkelijke primaire regio, voert u failback uit naar de primaire regio nadat de primaire regio is hersteld na de storing.

Testen op regiofouten

Als u een fout wilt simuleren tijdens een regiostoring, kunt u een handmatige failover van uw IoT-hub activeren. Omdat regionale failover echter zowel downtime als gegevensverlies veroorzaakt, moet u alleen testfailovers uitvoeren in niet-productieomgevingen. Voor meer informatie, zie Region-down ervaring. Denk eraan om een testexemplaar van de IoT Hub in te stellen om de failoveroptie periodiek volgens plan te starten. Met periodieke tests kunt u vertrouwen opbouwen in uw vermogen om uw end-to-end oplossingen effectief te herstellen en te gebruiken wanneer er zich een echte ramp voordoet.

Alternatieve benaderingen voor meerdere regio's

De failovermogelijkheden tussen regio's van IoT Hub zijn niet geschikt voor de volgende scenario's:

  • Uw IoT-hub bevindt zich in een niet-gepareerde regio.

  • Uw bedrijfs-uptime-doelen worden niet vervuld door de hersteltijd of het gegevensverlies die de ingebouwde failover-opties bieden.

  • U moet een failover uitvoeren naar een regio die niet gekoppeld is aan uw primaire regio.

U kunt een failoveroplossing voor meerdere regio's ontwerpen die is afgestemd op elk afzonderlijk apparaat. Een volledige behandeling van implementatietopologieën in IoT-oplossingen valt buiten het bereik van dit artikel, maar u kunt een implementatiemodel voor meerdere regio's overwegen. In dit model wordt de back-end van uw primaire IoT-hub en oplossing voornamelijk uitgevoerd in één Azure-regio. Een secundaire IoT-hub en back-end worden geïmplementeerd in een andere Azure-regio. Als de IoT-hub in de primaire regio te maken krijgt met een storing of als de netwerkverbinding van het apparaat naar de primaire regio wordt onderbroken, gebruiken apparaten een secundair service-eindpunt.

  • Verwachte downtime: Deze benadering heeft minder dan één minuut downtime, maar kan complex zijn om te implementeren.

  • Verwachte gegevensverlies: De hoeveelheid gegevensverlies is afhankelijk van de specifieke gegevensarchieven die u gebruikt en de manier waarop u geo-replicatie tussen deze gegevens configureert.

  • Kosten: Voor deze aanpak moet u ten minste één extra IoT-hub inrichten, waardoor uw totale kosten worden verhoogd.

Als u een regionaal failovermodel met IoT Hub wilt implementeren, moet u de volgende stappen ondernemen:

  • Een secundaire IoT-hub- en apparaatrouteringslogica: Als de service in uw primaire regio wordt onderbroken, moeten apparaten verbinding maken met uw secundaire regio. Vanwege de statusbewuste aard van de meeste betrokken services activeren oplossingsbeheerders meestal het failoverproces tussen regio's handmatig. 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 wordt gehouden met behulp van DNS-omleidingstechnieken, zoals Azure Traffic Manager.

    Opmerking

    Traffic Manager heeft geen ingebouwde ondersteuning voor IoT Hub. U kunt aangepaste Traffic Manager-eindpunten configureren voor elke IoT-hub. Configureer de statustest van het Traffic Manager-eindpunt om het eindpunt van de IoT-hub te gebruiken.

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

  • Samenvoeglogica: Wanneer de primaire regio weer beschikbaar is, moeten alle status en gegevens die in de secundaire regio zijn gemaakt, worden gemigreerd naar de primaire regio. Deze status en gegevens hebben meestal betrekking op apparaatidentiteiten 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 bijwerkingen van de uiteindelijk consistente verdeling van evenementen en van duplicaten of levering van evenementen buiten volgorde. De toepassingslogica moet ook worden ontworpen om mogelijke inconsistenties of iets verouderdse status te tolereren. Dit scenario kan voorkomen vanwege de extra tijd die het systeem nodig heeft om te herstellen op basis van herstelpuntdoelstellingen (RPO's).

Reservekopieën

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Redundantie, replicatie en back-up voor meer informatie.

De IoT Hub-service maakt bulkexportbewerkingen mogelijk, waarmee u het volledige identiteitsregister van een IoT-hub kunt exporteren. Deze gegevens worden overgebracht naar een Azure Storage-blobcontainer met behulp van een Shared Access Signature. Met deze methode kunt u betrouwbare back-ups van uw apparaatgegevens maken in een blobcontainer die u beheert. Zie IoT Hub-apparaatidentiteiten bulksgewijs importeren en exporteren voor meer informatie.

U kunt ook de Azure Resource Manager-sjabloon (ARM-sjabloon) van een bestaande IoT-hub exporteren om een back-up te maken van de configuratie van de IoT-hub. Zie Een IoT-hub handmatig migreren met behulp van een ARM-sjabloon voor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor IoT Hub beschrijft de verwachte beschikbaarheid van de service en de voorwaarden waaraan moet worden voldaan om die beschikbaarheidsverwachting te bereiken. Als u deze voorwaarden wilt begrijpen, is het belangrijk dat u de SLA's voor onlineservices bekijkt.

Verwante inhoud