Freigeben über

Zuverlässigkeit im Azure IoT Hub

In diesem Artikel wird die Zuverlässigkeitsunterstützung in Azure IoT Hub beschrieben. Sie deckt die intraregionale Resilienz über Verfügbarkeitszonen und Bereitstellungen mit mehreren Regionen ab.

Zuverlässigkeit ist eine gemeinsame Verantwortung zwischen Ihnen und Microsoft. Mit diesem Leitfaden können Sie ermitteln, welche Zuverlässigkeitsoptionen Ihre spezifischen Geschäftsziele und Uptime-Ziele erfüllen.

Wenn Sie Zuverlässigkeitsoptionen auswerten, müssen Sie auch die Kompromisse zwischen den folgenden Elementen auswerten:

  • Grad der Resilienz, die Sie benötigen
  • Implementierungs- und Wartungsaufwand
  • Kosten für die Implementierung verschiedener Optionen

Weitere Informationen finden Sie unter Zuverlässigkeitsabschläge.

Vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

IoT Hub bietet eine relativ hohe Verfügbarkeitsgarantie, aber vorübergehende Fehler können in jeder verteilten Computing-Plattform auftreten. Um vorübergehende Fehler zu behandeln, erstellen Sie die entsprechenden Wiederholungsmuster in Komponenten, die mit Cloudanwendungen interagieren.

Unterstützung für Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

IoT Hub unterstützt zwei verschiedene Arten von Verfügbarkeitszonenunterstützung:

  • Zonenredundanz für Daten, die Automatisch Daten zwischen mehreren Verfügbarkeitszonen für die zugrunde liegenden Speicherkomponenten repliziert, die die Geräteidentitätsregistrierung und Geräte-zu-Cloud-Nachrichten speichern.

  • Zonenredundanz für die Berechnung, die Resilienz in den Komponenten bereitstellt, die für die Verwaltung der Geräte und routingnachrichten verantwortlich sind.

Regionsunterstützung

Die Art der Verfügbarkeitszonenunterstützung für Ihren IoT-Hub hängt von der Region ab, in der sie bereitgestellt wird.

Region Zonenredundanz für Daten Zonenredundanz für Compute
Australien (Osten) Ja Ja
Brasilien Süd Ja Ja
Kanada, Mitte Ja Ja
Zentralindien Nein Ja
Zentrale USA Ja Ja
Ost-USA Nein Ja
Frankreich, Mitte Ja Ja
Deutschland West Central Ja Ja
Japan, Osten Ja Ja
Zentral-Korea Nein Ja
Nordeuropa Ja Ja
Norwegen, Osten Nein Ja
Katar Zentral Nein Ja
Süd-Mittel-USA Nein Ja
Südostasien Ja Ja
Vereinigtes Königreich Süd Ja Ja
Westeuropa Nein Ja
Westliches USA 2 Ja Ja
Westliches USA 3 Nein Ja

IoT-Hubs, die Sie in Regionen erstellen, die nicht in dieser Liste enthalten sind, sind nicht widerstandsfähig für Zonenausfälle.

Kosten

Es gibt keine zusätzlichen Kosten für Zonenredundanz mit IoT Hub.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

IoT Hub-Ressourcen unterstützen zonenredundanz automatisch, wenn sie in unterstützten Regionen bereitgestellt werden. Es ist keine weitere Konfiguration erforderlich.

Normalbetrieb

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn IoT Hub-Ressourcen für Zonenredundanz konfiguriert sind und alle Verfügbarkeitszonen betriebsbereit sind.

  • Datenreplikation zwischen Zonen: Wenn Ihr IoT-Hub in einer Region bereitgestellt wird, die Zonenredundanz für Daten unterstützt, werden Änderungen der Daten automatisch zwischen Verfügbarkeitszonen repliziert. Replikation erfolgt synchron.

  • Datenverkehrsrouting zwischen Zonen: Wenn Ihr IoT-Hub in einer Region bereitgestellt wird, die Zonenredundanz für Computekomponenten unterstützt, werden Anforderungen an eine primäre Instanz des Diensts in einer der Verfügbarkeitszonen weitergeleitet. Azure wählt die aktive Instanz und Zone automatisch aus.

Zonenausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn IoT Hub-Ressourcen für Zonenredundanz konfiguriert sind und es einen Ausfall der Verfügbarkeitszone gibt.

  • Erkennung und Reaktion: Der IoT Hub-Dienst ist für die Erkennung eines Fehlers in einer Verfügbarkeitszone verantwortlich. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.

  • Aktive Anforderungen: Während eines Zonenfehlers werden möglicherweise aktive Anforderungen gelöscht. Ihre Clients und Geräte sollten über ausreichende Wiederholungslogik verfügen, um vorübergehende Fehler zu behandeln.

  • Erwarteter Datenverlust: Wenn Ihr IoT-Hub in einer Region bereitgestellt wird, die Zonenredundanz für Daten unterstützt, sollte ein Zonenfehler keinen Datenverlust verursachen.

  • Erwartete Ausfallzeiten: Wenn Ihr IoT-Hub in einer Region bereitgestellt wird, die Zonenredundanz für Compute- und Datenkomponenten unterstützt, sollte ein Zonenfehler keine Ausfallzeiten für Ihre IoT Hub-Ressourcen verursachen.

  • Datenverkehrsumleitung: Wenn Ihr IoT-Hub in einer Region bereitgestellt wird, die Zonenredundanz für Computekomponenten unterstützt, erkennt IoT Hub den Verlust der Zone. Anschließend werden alle neuen Anforderungen automatisch an eine neue primäre Instanz des Diensts in einer der fehlerfreien Verfügbarkeitszonen umgeleitet.

Zonenwiederherstellung

Wenn die Verfügbarkeitszone wiederhergestellt ist, stellt IoT Hub automatisch die Instanzen in der Verfügbarkeitszone wieder her und leitet den Datenverkehr wie gewohnt zwischen Ihren Instanzen um.

Testen auf Zonenfehler

Da IoT Hub Datenverkehrsrouting, Failover und Failback für Zonenfehler vollständig verwaltet, müssen Sie keine Prozesse für Verfügbarkeitszonenfehler überprüfen oder weitere Eingaben bereitstellen.

Unterstützung für mehrere Regionen

IoT Hub ist ein Einzelregionendienst. Wenn die Region nicht verfügbar ist, sind Ihre IoT Hub-Ressourcen ebenfalls nicht verfügbar.

Wenn sich Ihre Ressourcen jedoch in einer Region befinden, die gekoppelt ist, werden die Daten Ihres IoT-Hubs in den gekoppelten Bereich repliziert.

Ihr IoT-Hub führt in den folgenden Szenarien möglicherweise ein Failover in die gekoppelte Region durch:

  • Vom Kunden initiiertes Failover: Sie können manuellen Failover für die gekoppelte Region selbst auslösen, unabhängig davon, ob die Region Ausfallzeiten hat oder nicht. Sie können diesen Ansatz verwenden, um geplante Failovers und Übungen durchzuführen.

  • Von Microsoft initiiertes Failover: Wenn eine Region verloren geht, kann Microsoft ein Failover von IoT-Hubs in die gekoppelte Region initiieren. Microsoft wird jedoch wahrscheinlich kein Failover initiieren, es sei denn nach einer erheblichen Verzögerung und nach bestem Bemühen. Failover von IoT Hub-Ressourcen kann zu einem anderen Zeitpunkt auftreten als Failover anderer Azure-Dienste. Dieser Vorgang ist eine Standardoption und erfordert keinen Eingriff von Ihnen.

Wenn sich Ressourcen in einer nicht verzweifleten Region befinden, repliziert Microsoft keine Konfiguration und Daten in allen Regionen, und es gibt kein integriertes regionsübergreifendes Failover. Sie können jedoch separate Ressourcen in mehreren Regionen bereitstellen. In diesem Szenario liegt es in Ihrer Verantwortung, Replikation, Datenverkehrsverteilung, Failover zu verwalten.

Wenn sich Ihr IoT-Hub in einer nicht gepaarten Region befindet, oder das Standardreplikations- und Failoververhalten nicht Ihren Anforderungen entspricht, können Sie alternative Multi-Region-Ansätze verwenden, um Failover-Vorgänge zu planen und zu initiieren.

Regionsunterstützung

Die Standardreplikation und das Failover werden nur in Regionen unterstützt, die gekoppelt sind.

Anforderungen

Die Replikation gepaarter Regionen und Failover-Optionen sind für alle IoT-Hub-Stufen verfügbar.

Überlegungen

Verwenden Sie kein vom Kunden initiiertes Failover, um Ihren Hub dauerhaft zwischen den gekoppelten Azure-Regionen zu migrieren. Im Allgemeinen befinden sich Geräte in der Nähe der primären Region des Hubs. Wenn Sie Ihren Hub in die sekundäre Region verschieben, erhöht sich die Latenz für Vorgänge zwischen den Geräten und dem IoT-Hub am sekundären Standort.

Kosten

Für Hubs in Regionen, die gekoppelt sind, gibt es keine zusätzlichen Kosten für die regionsübergreifende Datenreplikation oder das Failover.

Wenn sich Ihr IoT-Hub in einer nicht gepaarten Region befindet, finden Sie alternative Multi-Region-Ansätze für mögliche Kosteninformationen.

Konfigurieren der Replikation und Vorbereiten des Failovers

Standardmäßig wird die regionsübergreifende Datenreplikation automatisch konfiguriert, wenn Sie einen IoT-Hub in einer gekoppelten Region erstellen. Dieser Vorgang ist eine Standardoption und erfordert keinen Eingriff von Ihnen. In Regionen mit Ausnahme von Brasilien Süd- und Südostasien (Singapur) werden Ihre Kundendaten nicht außerhalb der Geografie gespeichert oder verarbeitet, in der Sie die Dienstinstanz bereitstellen.

Wenn Sich Ihr IoT-Hub in den Regionen Brasilien Süd- oder Südostasien (Singapur) befindet, können Sie die Datenreplikation deaktivieren und das Failover deaktivieren. Weitere Informationen finden Sie unter Deaktivieren der Notfallwiederherstellung (DR).

Wenn Sich Ihr IoT-Hub in einer nicht gekoppelten Region befindet, müssen Sie Ihre eigene regionsübergreifende Replikation und einen Failoveransatz planen. Weitere Informationen finden Sie unter Alternative Multi-Region-Ansätze.

Normalbetrieb

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein IoT-Hub für die regionsübergreifende Replikation und das Failover konfiguriert ist und die primäre Region betriebsbereit ist.

  • Datenreplikation zwischen Regionen: Daten werden automatisch in den gekoppelten Bereich repliziert. Die Replikation erfolgt asynchron, was bedeutet, dass bei einem Failover ein Datenverlust erwartet wird. Es gibt keine Datenreplikation zwischen Regionen für IoT-Hubs in nicht zusammengeführten Regionen.

  • Datenverkehrsrouting zwischen Regionen: In normalen Vorgängen fließt der Datenverkehr nur in die primäre Region.

Regionsausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein IoT-Hub für die regionsübergreifende Replikation und das Failover konfiguriert ist, und es gibt einen Ausfall in der primären Region.

  • Erkennung und Reaktion: Die Verantwortung für das Erkennen und Reagieren auf einen Ausfall in der primären Region kann variieren.

    • Vom Kunden initiiertes Failover: Sie sind dafür verantwortlich, einen Regionsverlust zu erkennen und zu entscheiden, wann ein Failover durchgeführt werden soll. Weitere Informationen zum Ausführen eines vom Kunden initiierten Failovers zwischen gekoppelten Regionen finden Sie unter Ausführen eines manuellen Failovers für einen IoT-Hub.

      Es gibt Beschränkungen, wie häufig Sie ein vom Kunden initiiertes Failover oder Failback ausführen können:

      • Benutzer können zwei erfolgreiche Failovervorgänge und zwei erfolgreiche Failbackvorgänge pro Tag ausführen.

      • Direkt aufeinanderfolgende Failover- oder Failbackvorgänge sind nicht zulässig. Sie müssen eine Stunde zwischen diesen Vorgängen warten.

    • Von Microsoft initiiertes Failover: Microsoft kann sich entscheiden, ein Failover durchzuführen, wenn die primäre Region verloren geht. Dieser Vorgang kann mehrere Stunden nach dem Verlust der primären Region oder sogar länger in einigen Szenarien dauern. Failover von IoT Hub-Ressourcen tritt möglicherweise nicht gleichzeitig mit anderen Azure-Diensten auf.

  • Aktive Anforderungen: Alle Anforderungen, die der primäre Bereich während eines Failovers verarbeitet, gehen wahrscheinlich verloren. Clients sollten nach Abschluss des Failovers Anforderungen wiederholen.

  • Erwarteter Datenverlust: Bei Regionen, die gekoppelt sind, werden Daten asynchron in den gekoppelten Bereich repliziert. Daher wird nach dem Failover ein Datenverlust erwartet. Dieser Prozess gilt sowohl für von Microsoft verwaltete als auch für vom Kunden verwaltete Failovers. In der folgenden Tabelle wird das Ziel des Wiederherstellungspunkts (Recovery Point Objective, RPO) oder der erwartete Datenverlust jedes Datentyps beschrieben, den IoT-Hubs speichern.

    Datentyp RPO
    Identitätsregistrierung 0-5 Minuten Datenverlust
    Daten des Gerätezwillings 0-5 Minuten Datenverlust
    Cloud-to-Device-Nachrichten 1 0-5 Minuten Datenverlust
    Übergeordnete 1 - und Geräteaufträge 0-5 Minuten Datenverlust
    Gerät-zu-Cloud-Nachrichten Alle ungelesenen Nachrichten gehen verloren
    Cloud-zu-Gerät-Feedbacknachrichten Alle ungelesenen Nachrichten gehen verloren

    1 Cloud-zu-Gerät-Nachrichten und übergeordnete Aufträge werden nicht als Teil eines vom Kunden initiierten Failovers wiederhergestellt.

  • Erwartete Ausfallzeiten: Die erwartete Ausfallzeit während des Regionsfailovers hängt vom Failovertyp ab.

    • Vom Kunden initiiertes Failover: Erwarten Sie ca. 10 Minuten bis zu 2 Stunden Ausfallzeit, von dem Zeitpunkt, an dem die Region verloren geht, bis zu dem Zeitpunkt, an dem die Ressource in der gekoppelten Region wieder betriebsbereit ist. Die Anzahl der Geräte, die für die IoT-Hubinstanz registriert wurden, die fehlgeschlagen ist, wirkt sich auf die Wiederherstellungszeit aus. Sie können davon ausgehen, dass die Wiederherstellungszeit für einen Hub, der ungefähr 100.000 Geräte hostt, etwa 15 Minuten beträgt.

    • Von Microsoft initiiertes Failover: Erwarten Sie etwa 2 bis 26 Stunden Ausfallzeit vom Zeitpunkt des Verlusts der Region bis zur Verfügbarkeit der Ressource in der gekoppelten Region.

      Die hohe Wiederherstellungszeit liegt daran, dass Microsoft den Failovervorgang im Namen aller betroffenen Kunden in dieser Region ausführen muss. Bei kritischen Systemen sollten Sie ein vom Kunden initiiertes Failover verwenden, um weniger Ausfallzeiten zu erzielen. Wenn Sie jedoch eine weniger kritische IoT-Lösung ausführen, die eine Ausfallzeit von ungefähr einem Tag aufrecht erhalten kann, kann es möglich sein, eine Abhängigkeit von der von Microsoft initiierten Option zu nehmen, um die allgemeinen DR-Ziele für Ihre IoT-Lösung zu erfüllen.

    • Bei beiden Failovertypen bleibt der vollqualifizierte Domänenname der IoT-Hubinstanz nach dem Failover gleich, was bedeutet, dass die Verbindungszeichenfolge auch gleich bleibt. Da sich jedoch die zugrunde liegenden IP-Adressänderungen ändern, müssen Clients auf die Aktualisierung von DNS-Einträgen (Domain Name System) warten, bevor sie nach dem Failover auf den IoT-Hub zugreifen.

      Von Bedeutung

      Die IoT Hub-SDKs speichern die IP-Adresse des IoT-Hubs nicht zwischen. Benutzercode, der mit den SDKs verbunden ist, sollte die IP-Adresse des IoT-Hubs ebenfalls nicht zwischenspeichern.

      Aufgrund dieser Faktoren kann die Zeit, die nötig ist, damit die für Ihre IoT-Hubinstanz ausgeführten Laufzeitvorgänge nach Abschluss des Failover-Prozesses vollständig betriebsbereit sind, mit der folgenden Funktion ausgedrückt werden:

      Zeit für die Wiederherstellung = RTO [10 Minuten bis 2 Stunden für vom Kunden initiiertes Failover oder 2 bis 26 Stunden für das von Microsoft initiierte Failover] + DNS-Verteilungsverzögerung + Zeit, die die Clientanwendung benötigt, um alle zwischengespeicherten IoT Hub-IP-Adressen zu aktualisieren

  • Datenverkehrsumleitung: Während des Failovervorgangs aktualisiert IoT Hub DNS-Einträge, um auf die gekoppelte Region zu verweisen. Alle nachfolgenden Anfragen werden an die gekoppelte Region gesendet.

    Nachdem der Failovervorgang für den IoT-Hub abgeschlossen ist, sollten alle Vorgänge des Geräts und der Back-End-Anwendungen ohne manuellen Eingriff fortgesetzt werden. Diese Kontinuität stellt sicher, dass Ihre Geräte-zu-Cloud-Nachrichten weiterhin funktionieren und die gesamte Geräteregistrierung intakt ist. Wenn Sie Ereignisse über Azure Event Grid ausgeben, können sie über dieselben Abonnements genutzt werden, die Sie zuvor konfiguriert haben, solange diese Event Grid-Abonnements weiterhin verfügbar sind. Für benutzerdefinierte Endpunkte ist keine weitere Behandlung erforderlich.

Nach dem Failover erforderliche Konfiguration

Je nachdem, wo Sie die Nachrichten Ihres IoT-Hubs weiterleiten, müssen Sie möglicherweise zusätzliche Schritte ausführen, nachdem das Failover abgeschlossen ist.

  • Azure Event Hubs: Der mit Event Hubs kompatible Name und Endpunkt des integrierten Ereignisendpunkts Ihres IoT-Hubs ändern sich nach dem Failover. Diese Änderung tritt auf, da der Event Hubs-Client keinen Einblick in IoT Hub-Ereignisse hat.

    Wenn Sie Telemetrienachrichten vom integrierten Endpunkt empfangen, indem Sie entweder den Event Hubs-Client oder den Ereignisprozessorhost verwenden, verwenden Sie die Verbindungszeichenfolge des IoT-Hubs , um die Verbindung herzustellen. Mit diesem Ansatz wird sichergestellt, dass Ihre Back-End-Anwendungen weiterhin funktionieren, ohne dass ein manueller Eingriff nach dem Failover erforderlich ist.

    Wenn Sie den ereignishubskompatiblen Namen und Endpunkt in Ihrer Anwendung direkt verwenden, müssen Sie den neuen Event Hubs-kompatiblen Endpunkt abrufen, nachdem ein Failover ausgeführt wurde, um den Betrieb fortzusetzen. Um den Endpunkt und den Namen abzurufen, können Sie das Azure-Portal oder das .NET SDK verwenden:

    • Das Azure-Portal: Weitere Informationen zur Verwendung des Portals zum Abrufen des mit Event Hubs kompatiblen Endpunkts und des mit Event Hubs kompatiblen Namens finden Sie unter Herstellen einer Verbindung mit dem integrierten Endpunkt.

    • .NET SDK: Verwenden Sie den Beispielcode, um die IoT-Hub-Verbindungszeichenfolge zum Erneuten Abrufen des mit Event Hubs kompatiblen Endpunkts zu verwenden. In diesem Codebeispiel wird die Verbindungszeichenfolge verwendet, um den neuen Event Hubs-Endpunkt abzurufen und die Verbindung erneut herzustellen. Visual Studio muss installiert sein.

  • Azure-Funktionen und Azure Stream Analytics: Wenn Sie Azure Functions oder Stream Analytics verwenden, um eine Verbindung mit dem integrierten Ereignisendpunkt herzustellen, müssen Sie den Event Hubs-Endpunkt aktualisieren, mit dem die Funktion oder der Auftrag eine Verbindung herstellt, und zwar nach demselben Prozess, der im vorherigen Aufzählungspunkt beschrieben ist. Führen Sie dann eine Neustartaktion aus, da alle Ereignisdatenstromversätze nach dem Failover ungültig werden.

  • Azure Storage: Beim Routing an Azure Storage sollten Sie zuerst die Blobs oder Dateien auflisten. Iterieren Sie dann über sie, um sicherzustellen, dass alle Blobs oder Dateien gelesen werden, ohne eine Partitionierung vorauszusetzen. Der Partitionsbereich kann sich während eines von Microsoft initiierten Failovers oder vom Kunden initiierten Failovers möglicherweise ändern. Sie können die Liste der Blobs oder die Liste der Azure Data Lake Storage-APIs mithilfe der Liste der Blobs-APIs aufzählen, um die gewünschte Liste von Dateien zu erhalten. Weitere Informationen finden Sie unter Azure Storage als Routingendpunkt.

Regionswiederherstellung

Sie können ein Failback zur primären Region ausführen, indem Sie die Failoveraktion ein zweites Mal auslösen. Es ist wichtig, sich an die Einschränkungen zu erinnern, wie häufig Sie ein Failover durchführen können.

Wenn der ursprüngliche Failovervorgang durchgeführt wurde, um sich von einem erweiterten Ausfall in der ursprünglichen primären Region zu erholen, führen Sie einen Failback in die primäre Region durch, nachdem sich die primäre Region von dem Ausfall erholt hat.

Testen auf Regionsfehler

Um einen Fehler während eines Regionsausfalls zu simulieren, können Sie ein manuelles Failover Ihres IoT-Hubs auslösen. Da das regionale Failover jedoch sowohl Ausfallzeiten als auch Datenverluste verursacht, sollten Sie nur Testfailover in Nichtproduktionsumgebungen ausführen. Weitere Informationen finden Sie unter Region-down-Erfahrung. Erwägen Sie das Einrichten einer IoT Hub-Testinstanz, um die geplante Failoveroption regelmäßig zu initiieren. Regelmäßige Tests können Ihnen helfen, Vertrauen in Ihre Fähigkeit zu schaffen, Ihre End-to-End-Lösungen effektiv wiederherzustellen und zu betreiben, wenn ein echtes Notfall auftritt.

Alternative Ansätze für mehrere Regionen

Die regionsübergreifenden Failoverfunktionen von IoT Hub eignen sich nicht für die folgenden Szenarien:

  • Ihr IoT-Hub befindet sich in einer nicht gekoppelten Region.

  • Ihre Ziele hinsichtlich der Uptime werden durch die Wiederherstellungszeit oder den Datenverlust, die eine der integrierten Failoveroptionen bietet, nicht erfüllt.

  • Sie müssen ein Failover zu einer Region ausführen, die nicht das Paar Ihrer primären Region ist.

Sie können eine regionsübergreifende Failoverlösung entwerfen, die auf jedes einzelne Gerät zugeschnitten ist. Eine vollständige Behandlung von Bereitstellungstopologien in IoT-Lösungen liegt außerhalb des Umfangs dieses Artikels, Sie können jedoch ein Bereitstellungsmodell mit mehreren Regionen in Betracht ziehen. In diesem Modell werden Ihr primärer IoT-Hub und ihr Back-End-Lösung hauptsächlich in einer Azure-Region ausgeführt. Ein sekundärer IoT-Hub und ein Back-End werden in einer anderen Azure-Region bereitgestellt. Wenn der IoT-Hub in der primären Region einen Ausfall hat oder die Netzwerkkonnektivität vom Gerät zur primären Region unterbrochen wird, verwenden Geräte einen sekundären Dienstendpunkt.

  • Erwartete Ausfallzeiten: Dieser Ansatz hat weniger als eine Minute Ausfallzeit, kann aber komplex sein, um sie zu implementieren.

  • Erwarteter Datenverlust: Die Menge des Datenverlusts hängt von den spezifischen Datenspeichern ab, die Sie verwenden, und der Art und Weise, wie Sie die Georeplikation zwischen ihnen konfigurieren.

  • Kosten: Dieser Ansatz erfordert, dass Sie mindestens einen zusätzlichen IoT-Hub bereitstellen, wodurch ihre Gesamtkosten erhöht werden.

Ergreifen Sie die folgenden Maßnahmen, wenn Sie ein Modell für regionales Failover mit IoT Hub implementieren möchten:

  • Eine sekundäre IoT-Hub- und Geräteroutinglogik: Wenn der Dienst in Ihrer primären Region unterbrochen wird, müssen Geräte mit der Verbindung mit Ihrer sekundären Region beginnen. Aufgrund der zustandsbewussten Art der meisten beteiligten Dienste lösen Lösungsadministratoren den Failoverprozess zwischen Regionen häufig manuell aus. Die beste Möglichkeit, Geräte über den neuen Endpunkt zu informieren und gleichzeitig die Kontrolle über den Prozess zu behalten, besteht darin, für die Geräte eine regelmäßige Prüfung eines Concierge-Diensts auf den derzeit aktiven Endpunkt durchführen zu lassen. Der Concierge-Service kann eine Webanwendung sein, die durch die Verwendung von DNS-Umleitungstechniken wie Azure Traffic Manager repliziert und erreichbar bleibt.

    Hinweis

    Der Traffic Manager bietet keine integrierte Unterstützung für IoT Hub. Sie können benutzerdefinierte Traffic Manager-Endpunkte für jeden IoT-Hub konfigurieren. Konfigurieren Sie den Integritätstest des Traffic Manager-Endpunkts für die Verwendung des IoT-Hub-Endpunkts.

  • Identitätsregistrierungsreplikation: Um verwendbar zu sein, muss der sekundäre IoT-Hub alle Geräteidentitäten enthalten, die eine Verbindung mit der Lösung herstellen können. Für die Lösung sollten georeplizierte Backups von Geräteidentitäten vorgehalten und auf die sekundäre IoT Hub-Einheit hochgeladen werden, bevor der aktive Endpunkt für die Geräte gewechselt wird. Die Funktionen zum Exportieren der Geräteidentität von IoT Hub sind in diesem Zusammenhang praktisch. Weitere Informationen finden Sie unter Grundlegendes zur Identitätsregistrierung in Ihrer IoT Hub-Instanz.

  • Zusammenführungslogik: Wenn die primäre Region wieder verfügbar wird, müssen alle in der sekundären Region erstellten Status und Daten wieder in die primäre Region migriert werden. Dieser Status und die Daten beziehen sich hauptsächlich auf Geräteidentitäten und Anwendungsmetadaten, die mit der primären IoT Hub-Einheit und etwaigen anderen anwendungsspezifischen Datenspeichern in der primären Region zusammengeführt werden müssen.

    Um diesen Schritt zu vereinfachen, verwenden Sie idempotent-Vorgänge . Idempotente Vorgänge verringern die Nebeneffekte für die letztendliche konsistente Verteilung von Ereignissen sowie für Duplikate oder die außerordentliche Bereitstellung von Ereignissen. Außerdem sollte die Anwendungslogik so konzipiert werden, dass potenzielle Inkonsistenzen oder geringfügig veraltete Zustände toleriert werden. Dieses Szenario kann aufgrund der zusätzlichen Zeit auftreten, die das System benötigt, um basierend auf RPOs zu heilen.

Datensicherungen

Für die meisten Lösungen sollten Sie sich nicht ausschließlich auf Sicherungen verlassen. Verwenden Sie stattdessen die in diesem Handbuch beschriebenen anderen Funktionen, um Ihre Resilienzanforderungen zu unterstützen. Sicherungen schützen jedoch vor einigen Risiken, die andere Ansätze nicht vermeiden. Weitere Informationen finden Sie unter Redundanz, Replikation und Sicherung.

Der IoT Hub-Dienst ermöglicht Massenexportvorgänge, mit denen Sie die gesamte Identitätsregistrierung eines IoT-Hubs exportieren können. Diese Daten werden mithilfe einer freigegebenen Zugriffssignatur an einen Azure Storage-BLOB-Container übertragen. Mit dieser Methode können Sie zuverlässige Sicherungen Ihrer Geräte-Informationen in einem Blobcontainer erstellen, den Sie steuern. Weitere Informationen finden Sie unter "Importieren und Exportieren von IoT Hub-Geräteidentitäten in Massen".

Sie können auch die Azure Resource Manager-Vorlage (ARM-Vorlage) eines vorhandenen IoT-Hubs exportieren, um eine Sicherung der IoT Hub-Konfiguration zu erstellen. Weitere Informationen finden Sie unter Manuelles Migrieren eines IoT-Hubs mithilfe einer ARM-Vorlage.

Service-Level-Vereinbarung

Der Servicelevelvertrag (SLA) für IoT Hub beschreibt die erwartete Verfügbarkeit des Diensts und die Bedingungen, die erfüllt werden müssen, um diese Verfügbarkeitserwartungen zu erreichen. Um diese Bedingungen zu verstehen, ist es wichtig, dass Sie die SLAs für Onlinedienste überprüfen.

Verwandte Inhalte