Zuverlässigkeit in Azure IoT Hub

Azure IoT Hub ist ein in der Cloud gehosteter verwalteter Dienst, der als zentraler Nachrichtenhub für die Kommunikation zwischen einer IoT-Anwendung und den angeschlossenen Geräten fungiert.

Wenn Sie Azure verwenden, ist zustellbarkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie IoT Hub widerstandsfähig für eine Vielzahl potenzieller Ausfälle und Probleme machen, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone und Regionsausfälle. Außerdem wird beschrieben, wie Sie Sicherungen verwenden können, um aus anderen Arten von Problemen wiederherzustellen, und hebt einige wichtige Informationen zum IoT Hub Service Level Agreement (SLA) hervor.

Empfehlungen für die Produktionsimplementierung für Zuverlässigkeit

Für Produktionsworkloads wird empfohlen, die folgenden Empfehlungen zu befolgen:

Übersicht über die Zuverlässigkeitsarchitektur

Wenn Sie einen IoT-Hub erstellen, stellen Sie eine IoT-Hubressource bereit, die alle Funktionen enthält, die zum Verwalten und Kommunizieren mit Ihren Geräten erforderlich sind. Zu den Hauptkomponenten eines IoT-Hubs gehören:

• Geräteidentitätsregistrierung: Eine Datenbank, in der Informationen zu den Geräten und Modulen gespeichert werden, die eine Verbindung mit Ihrem IoT-Hub herstellen können. Jedes Gerät muss über einen Eintrag in der Identitätsregistrierung verfügen, bevor eine Verbindung hergestellt werden kann. Weitere Informationen finden Sie unter Grundlegendes zur Identitätsregistrierung in Ihrer IoT Hub-Instanz.

• Messaging components: IoT Hub behandelt bidirektionales Messaging zwischen Geräten und Ihren Back-End-Anwendungen, einschließlich Geräte-zu-Cloud-Telemetrie, Cloud-zu-Gerät-Befehle und direkte Methodenaufrufe.

• Geräte-Zwillinge: JSON-Dokumente, die Gerätestatusinformationen speichern, einschließlich Metadaten, Konfigurationen und Bedingungen. Geräte und Back-End-Anwendungen können Geräte-Zwillinge lesen und aktualisieren.

Aus Zuverlässigkeitsgründen werden IoT Hub Komponenten in zwei Gruppen kategorisiert:

• Computekomponenten: Verwalten von Geräteverbindungen, Authentifizieren von Anforderungen, Weiterleiten von Nachrichten und Verarbeiten von direkten Methodenaufrufen. Diese Komponenten bestimmen die Fähigkeit IoT Hub, Anforderungen zu akzeptieren und zu verarbeiten.

• Datenkomponenten: Speichern Sie die Geräteidentitätsregistrierung, Geräte twins und Geräte-zu-Cloud-Nachrichten. Diese Komponenten bestimmen die Verfügbarkeit und Haltbarkeit von Daten.

Diese Unterscheidung ist wichtig, da unterschiedliche Regionen unterschiedliche Arten von Redundanz für diese Komponenten unterstützen.

Integration in andere Dienste

Sie können den IoT Hub mit dem Azure Geräteregister integrieren. Wenn Sie diesen Ansatz verwenden, überprüfen Sie Reliability in Azure Device Registry um zuverlässigkeit in beiden Diensten zu verstehen.

Wenn Sie IoT Hub Device Provisioning Service (DPS) für die Gerätebereitstellung verwenden, hängt die Zuverlässigkeit Ihrer Lösung auch von DPS ab. Weitere Informationen finden Sie unter IoT Hub-Gerätebereitstellungsdienst Hochverfügbarkeit und Notfallwiederherstellung.

Resilienz für 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 den Azure richtlinien für die vorübergehende Fehlerbehandlung befolgen, wenn sie mit allen in der Cloud gehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

IoT Hub bietet eine relativ hohe Betriebszeitgarantie, 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.

Bei Bereitstellungen in großem Maßstab empfiehlt es sich, randomisierten Wiederholungsjitter zu verwenden. Jitter hilft beim Verteilen der Last über die Hubpartitionen und reduziert die Wahrscheinlichkeit einer Drosselung während groß angelegter Wiederverbindungsereignisse.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

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

IoT Hub unterstützt zwei verschiedene Typen 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.

Wenn eine Region beide Arten von Zonenredundanz unterstützt, werden kritische Dienstdaten , einschließlich der Geräteidentitätsregistrierung, synchron über Verfügbarkeitszonen innerhalb der Region repliziert. Daher wird im Falle eines Ausfalls einer Zone kein Datenverlust erwartet, und der Dienst führt automatisch eine Umleitung der Gerätekonnektivität und des Nachrichtendatenverkehrs zu einer fehlerfreien Zone durch. Während In-Flight-Anforderungen während des Failoverereignisses vorübergehend beeinträchtigt werden können, wird die Dienstkontinuität beibehalten, und die Gerätewiederherstellungslogik stellt in der Regel die Wiederherstellung sicher.

Anforderungen

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
Australia East
Brasilien Süd
Canada Central
Zentralindien
Central US
East US
Frankreich, Mitte
Deutschland West Central
Japan, Osten
Korea Central
Nordeuropa
Norway East
Qatar Central
Süd-Mittel-USA
Südostasien
UK South
West Europe
Westliches USA 2
Westliches USA 3

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.

Verhalten, wenn alle Zonen fehlerfrei sind

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.

Verhalten bei einem Zoneausfall

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 dafür verantwortlich, einen Fehler in einer Verfügbarkeitszone zu erkennen. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.

• Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Resource Health Alerts einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.

• 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 Ausfallzeit: Wenn Ihr IoT Hub in einer Region bereitgestellt wird, die Zonenredundanz sowohl für Compute- als auch für Datenkomponenten unterstützt, sollte ein Zonenfehler keine Ausfallzeit für Ihre IoT Hub-Ressourcen verursachen.

• Traffic rerouting: 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 wird, stellt IoT Hub die Instanzen in der Verfügbarkeitszone automatisch wieder her und leitet den Datenverkehr wie gewohnt zwischen Ihren Instanzen um.

Test auf Zonenfehler

Da IoT Hub das Datenverkehrsrouting, Failover und Failback bei Ausfall von Verfügbarkeitszonen vollständig verwaltet, müssen Sie keine Prozesse für Ausfälle von Verfügbarkeitszonen überprüfen oder weitere Eingaben bereitstellen.

Widerstandsfähigkeit bei regionalen Ausfällen

IoT Hub ist ein Einzelregionendienst. Wenn die Region nicht verfügbar ist, sind ihre IoT Hub Ressourcen ebenfalls nicht verfügbar. Obwohl IoT Hub die asynchrone Datenreplikation zu einer gekoppelten Azure Region für Notfallwiederherstellungszwecke unterstützt, gibt es kein integriertes regionsübergreifendes Failover für die Gerätekonnektivität.

Wenn sich Ressourcen in einer nonpaired-Region befinden, repliziert Microsoft keine Konfiguration und Daten über Regionen hinweg, 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 verzweifleten Region befindet oder das Standardreplikations- und Failoververhalten nicht Ihren Anforderungen entspricht, entwerfen und implementieren Sie eine benutzerdefinierte Failoverstrategie mit mehreren Regionen, einschließlich der folgenden Schritte:

• Bereitstellen einer sekundären IoT Hub in einer anderen Azure Region.
• Implementieren eines Endpunktumleitungsmechanismus, um Geräte bei Bedarf in die alternative Region zu leiten. Sie können z. B. jedes Gerät vorab in beiden Hubs bereitstellen und beide Verbindungszeichenfolgen auf den Geräten so konfigurieren, dass sie bei Bedarf zwischen Hubs wechseln können.

Microsoft-verwaltetes Failover zu einer gekoppelten Region

Wenn sich Ihre Ressourcen in einer Region befinden, die gekoppelt ist, werden die Daten Ihres IoT-Hubs in die gekoppelte Region repliziert. Dieser Ansatz soll die Notfallwiederherstellung unterstützen. Wenn es einen Regionsfehler in der primären Region Ihres IoT-Hubs gibt, müssen Sie keine Maßnahmen ergreifen, um die Gerätekonnektivität zu aktivieren, um in der gekoppelten Region fortzufahren.

Failovertypen

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.

• 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, außer nach einer erheblichen Verzögerung und auf Best-Effort-Basis. Failover von IoT-Hub-Ressourcen kann zu einem anderen Zeitpunkt auftreten als Failover von anderen Azure-Diensten. Dieser Vorgang ist eine Standardoption und erfordert keinen Eingriff von Ihnen.

Anforderungen

• Regionsunterstützung: Die Standardreplikation und das Failover werden nur in Regionen unterstützt, die gepaart sind.
• Tier: Replikation mit gekoppelten Regionen und Failoveroptionen stehen für alle IoT Hub Ebenen zur Verfügung.

Überlegungen

Verwenden Sie kein vom Kunden initiiertes Failover, um Ihren Hub dauerhaft zwischen den Azure gekoppelten 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 unter Benutzerdefinierte Multi-Region-Lösungen zur Erhöhung der Ausfallsicherheit 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 benutzerdefinierte Lösungen mit mehreren Regionen zur Resilienz.

Verhalten, wenn alle Regionen funktionsfähig sind

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, einschließlich der Geräteidentitätsregistrierung, 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.

Verhalten während eines Regionenausfalls

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.

  • Microsoft-initiiertes Failover: Microsoft kann sich entscheiden, ein Failover auszuführen, wenn der primäre Bereich 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 Vorgang gilt sowohl für 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

  ¹ 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.

  • Microsoft-initiiertes Failover: Erwarten Sie etwa 2 bis 26 Stunden Ausfallzeit ab dem Zeitpunkt, an dem die Region verloren geht, bis die Ressource in der gekoppelten Region verfügbar ist.

    Die hohe Wiederherstellungszeit liegt darin, 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 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 hub 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 Microsoft initiiertes Failover] + DNS-Verteilungsverzögerung + Zeit, die die Clientanwendung benötigt, um alle zwischengespeicherten IoT-Hub-IP-Adressen zu aktualisieren

• Traffic rerouting: Während des Failovervorgangs aktualisiert IoT Hub DNS-Einträge so, dass sie auf den gekoppelten Bereich 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 Event Hubs-kompatible Name und der Endpunkt des eingebetteten Ereignisendpunkts Ihres IoT-Hubs ändern sich nach einem Failover. Diese Änderung tritt auf, da der Event Hubs-Client keinen Einblick in IoT Hub Ereignisse hat.

  Wenn Sie Telemetrienachrichten vom integrierten Endpunkt mithilfe des Event Hubs-Clients oder des Ereignisprozessorhosts empfangen, 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:

  • Die 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 Verbinden mit dem integrierten Endpunkt.

  • Das .NET SDK: Um die IoT-Hub-Verbindungszeichenfolge zu verwenden, um den mit Event Hubs kompatiblen Endpunkt erneut abzurufen, verwenden Sie den Beispielcode. In diesem Codebeispiel wird die Verbindungszeichenfolge verwendet, um den neuen Event Hubs-Endpunkt abzurufen und die Verbindung erneut herzustellen. Sie müssen Visual Studio installiert haben.

• Azure Functions 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, indem Sie denselben Prozess ausführen, 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 listen Sie zuerst die Blobs oder Dateien auf. 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 Microsoft initiierten Failovers oder vom Kunden initiierten Failovers ändern. Sie können die List Blobs API verwenden, um die Liste der Blobs oder die List Azure Data Lake Storage API für die Liste der Dateien auflisten. Weitere Informationen finden Sie unter Azure Storage als Routingendpunkt.

Region-Wiederherstellung

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.

Test 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 Verhalten während eines Regionenausfalls. Erwägen Sie, eine Test-IoT-Hub-Instanz einzurichten, um die geplante Failover-Option regelmäßig durchzuführen. 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.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

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 der primäre IoT-Hub und das Lösungs-Back-End 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.

Um ein regionales Failovermodell mit IoT Hub zu implementieren, müssen Sie die folgenden Schritte durchführen:

• 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 Empfangsdienst kann eine Webanwendung sein, die repliziert und erreichbar gehalten wird, indem DNS-Umleitungstechniken verwendet werden, z. B. Azure Traffic Manager.

  Hinweis

  Traffic Manager verfügt nicht über eingebaute 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 Geräteidentitätsexportfunktion von IoT Hub ist in diesem Kontext hilfreich. 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.

Sichern und Wiederherstellen

Der IoT Hub-Dienst ermöglicht Massenexportvorgänge, mit denen Sie die gesamte Identitätsregistrierung eines IoT hub 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 großen Mengen.

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

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 Was sind Redundanz, Replikation und Sicherung?.

Resilienz gegenüber Wartungsarbeiten an Diensten

Microsoft wendet regelmäßig Dienstupdates an und führt andere Wartungen durch. Die Azure Plattform übernimmt diese Aktivitäten automatisch, um sicherzustellen, dass die Wartung nahtlos und transparent für Sie ist. Bei Wartungsereignissen wird keine Ausfallzeit erwartet, es sei denn, Sie wurden über die geplante Wartung in Azure Service Health informiert.

Service-Level-Vereinbarung

Der ServiceLevel-Vertrag (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit der einzelnen Dienste und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Online-Dienste.

Verwandte Inhalte

• Skalierbarkeit, Hohe Verfügbarkeit und DR für IoT-Lösungen
• Reliability in Azure Device Registry
• Reliability in Azure