Verwalten von Geräteverbindungen zum Erstellen resilienter Anwendungen

Artikel
04/15/2024

Dieser Artikel enthält eine allgemeine Anleitung, die Ihnen dabei hilft, robuste Anwendungen zu entwickeln, indem Sie eine Strategie zur Wiederverbindung von Geräten hinzufügen. Es wird erläutert, warum Geräte die Verbindung trennen und erneut verbinden müssen. Außerdem werden spezifische Strategien beschrieben, mit denen Entwickler Geräte erneut verbinden können, die getrennt wurden.

Ursachen für Verbindungsabbrüche

Im Folgenden sind die häufigsten Gründe aufgeführt, aus denen Geräte von IoT Hub getrennt werden:

Abgelaufenes SAS-Token oder X.509-Zertifikat. Das SAS-Token des Geräts oder das X.509-Authentifizierungszertifikat ist abgelaufen.
Netzwerkunterbrechung. Die Verbindung des Geräts mit dem Netzwerk wird unterbrochen.
Dienstunterbrechung. Fehler beim Azure IoT Hub-Dienst oder sind vorübergehend nicht verfügbar.
Dienstneukonfiguration. Nachdem Sie die IoT Hub-Diensteinstellungen neu konfiguriert haben, kann dies dazu führen, dass Geräte eine erneute Bereitstellung oder erneute Verbindung erfordern.

Warum Sie eine Strategie für die erneute Verbindung benötigen

Es ist wichtig, eine Strategie zum erneuten Verbinden von Geräten zu haben, wie in den folgenden Abschnitten beschrieben. Ohne eine Wiederverbindungsstrategie könnten Sie negative Auswirkungen auf die Leistung, Verfügbarkeit und Kosten Ihrer Lösung feststellen.

Massenverknüpfungsversuche können zu einem DDoS führen

Eine hohe Anzahl von Verbindungsversuchen pro Sekunde kann einen Zustand verursachen, der einem verteilten Denial-of-Service-Angriff (DDoS) ähnelt. Dieses Szenario ist für große Geräteflotten von Millionen relevant. Das Problem kann über den Mandanten hinausgehen, der die Flotte besitzt, und sich auf die gesamte Skalierungseinheit auswirken. Ein DDoS könnte die Kosten für Ihre Azure IoT Hub-Ressourcen stark erhöhen, da Sie diese skalieren müssen. Ein DDoS könnte auch die Leistung Ihrer Lösung aufgrund von Ressourcenhunger beeinträchtigen. Im schlimmeren Fall kann ein DDoS Dienstunterbrechungen verursachen.

Hubfehler oder Neukonfigurationen können viele Geräte trennen

Nachdem ein IoT-Hub einen Fehler verursacht hat oder nachdem Sie die Diensteinstellungen auf einem IoT-Hub neu konfiguriert haben, werden Geräte möglicherweise getrennt. Für ein ordnungsgemäßes Failover müssen getrennte Geräte neu bereitgestellt werden. Weitere Informationen zu Failoveroptionen finden Sie unter IoT Hub-Hochverfügbarkeit und Notfallwiederherstellung.

Die erneute Bereitstellung vieler Geräte könnte die Kosten erhöhen

Nachdem Geräte von IoT Hub getrennt wurden, besteht die optimale Lösung darin, das Gerät erneut zu verbinden, anstatt es erneut bereitzustellen. Wenn Sie IoT Hub mit DPS verwenden, fallen bei DPS Kosten pro Bereitstellung an. Wenn Sie viele Geräte auf DPS neu bereitstellen, erhöht dies die Kosten Ihrer IoT-Lösung. Weitere Informationen zu DPS-Bereitstellungskosten finden Sie unter IoT Hub DPS-Preise.

Entwurf mit Blick auf Resilienz

IoT-Geräte sind oft auf nicht kontinuierliche oder instabile Netzwerkverbindungen angewiesen (z. B. GSM oder Satellit). Bei der Interaktion der Geräte mit cloudbasierten Diensten können aufgrund unregelmäßiger Dienstverfügbarkeit und Störungen auf Infrastrukturebene oder kurzzeitiger Störungen Fehler auftreten. Eine auf einem Gerät ausgeführte Anwendung muss die Verbindungs- und Wiederverbindungsmechanismen sowie die Wiederholungslogik für das Senden und Empfangen von Nachrichten handhaben. Darüber hinaus hängen die Anforderungen für die Wiederholungsstrategie besonders vom IoT-Szenario, dem Kontext und den Funktionen des Geräts ab.

Die Azure IoT Hub-Geräte-SDKs zielen darauf ab, die Verbindung und Kommunikation von Cloud-zu-Gerät und Gerät-zu-Cloud zu vereinfachen. Diese SDKs stellen eine zuverlässige Möglichkeit für die Verbindung mit Azure IoT Hub dar und umfassen umfangreiche Optionen zum Senden und Empfangen von Nachrichten. Entwickler können zudem vorhandene Implementierungen ändern, um die optimale Wiederholungsstrategie für ein bestimmtes Szenario anzupassen.

Die relevanten SDK-Funktionen, die Konnektivität und zuverlässiges Messaging unterstützen, sind in den folgenden IoT Hub-Geräte-SDKs verfügbar. Weitere Informationen finden Sie in der API-Dokumentation sowie im jeweiligen SDK:

In den folgenden Abschnitten werden SDK-Funktionen beschrieben, welche die Konnektivität unterstützen.

Verbindung und Wiederholung

Dieser Abschnitt bietet eine Übersicht über die verfügbaren Wiederverbindungs- und Wiederholungsmuster bei der Verwaltung von Verbindungen. Es werden Implementierungsschritte für unterschiedliche Wiederholungsrichtlinien in Ihrer Geräteanwendung und relevante APIs der Geräte-SDKs erläutert.

Fehlermuster

Verbindungsfehler können auf vielen Ebenen auftreten:

Netzwerkfehler: getrennter Socket und Namensauflösungsfehler
Fehler auf Protokollebene beim HTTP-, AMQP- und MQTT-Datentransport: getrennte Verbindungen oder abgelaufene Sitzungen
Fehler auf Anwendungsebene, die auf lokale Fehler zurückzuführen sind: ungültige Anmeldeinformationen oder Dienstverhalten (z.B. Kontingentüberschreitung oder Drosselung)

Die Geräte-SDKs erkennen Fehler auf allen drei Ebenen. Geräte-SDKs erkennen und behandeln jedoch keine betriebssystembezogenen Fehler und Hardwarefehler. Der SDK-Entwurf basiert auf der Anleitung Behandeln vorübergehender Fehler im Azure Architecture Center.

Wiederholungsmuster

Die folgenden Schritte beschreiben den Wiederholungsvorgang bei Erkennen von Verbindungsfehlern:

Das SDK erkennt den Fehler und den damit verbundenen Fehler im Netzwerk, Protokoll oder in der Anwendung.
Das SDK verwendet den Fehlerfilter, um den Fehlertyp zu ermitteln und zu ermitteln, ob eine Wiederholung erforderlich ist.
Wenn das SDK einen nicht behebbaren Fehler erkennt, werden Vorgänge wie Verbinden, Senden und Empfangen abgebrochen. Das SDK benachrichtigt den Benutzer. Beispiele für nicht behebbare Fehler sind Authentifizierungsfehler oder Fehler aufgrund eines falschen Endpunkts.
Wenn das SDK einen behebbaren Fehler erkennt, wird die Wiederholung entsprechend der angegebenen Wiederholungsrichtlinie durchgeführt, bis das definierte Zeitlimit abläuft. Das SDK verwendet standardmäßig Exponentielles Backoff mit Jitter-Wiederholungsrichtlinie.
Wenn das definierte Zeitlimit abläuft, versucht das SDK nicht mehr, eine Verbindung herzustellen oder eine Nachricht zu senden, und benachrichtigt den Benutzer.
Das SDK ermöglicht dem Benutzer, einen Rückruf anzufügen, um Änderungen am Verbindungsstatus zu empfangen.

Die SDKs stellen in der Regel drei Wiederholungsrichtlinien bereit:

Exponentielles Backoff mit Jitter: Diese standardmäßige Wiederholungsrichtlinie ist am Anfang eher aggressiv, verlangsamt sich und erreicht dann eine maximale Verzögerung. Der Entwurf basiert auf der Wiederholungsanleitung im Azure Architecture Center.
Benutzerdefinierte Wiederholung: Für einige SDK-Sprachen können Sie eine benutzerdefinierte Wiederholungsrichtlinie entwerfen, die für Ihr Szenario besser geeignet ist, und diese dann in die Wiederholungsrichtlinie (RetryPolicy) einfügen. Die benutzerdefinierte Wiederholung ist im C-SDK nicht verfügbar und wird derzeit im Python-SDK nicht unterstützt. Das Python-SDK stellt die Verbindung nach Bedarf wieder her.
Keine Wiederholung: Sie können die Wiederholungsrichtlinie auf „no retry“ festlegen, wodurch die Wiederholungslogik deaktiviert wird. Das SDK versucht, einmal eine Verbindung herzustellen und einmal eine Nachricht zu senden, vorausgesetzt, die Verbindung ist hergestellt. Diese Richtlinie wird typischerweise in Szenarien verwendet, in denen Bandbreiten- oder Kostenaspekte eine Rolle spielen. Bei dieser Option gehen Nachrichten, die nicht gesendet werden können, verloren und können nicht wiederhergestellt werden.

APIs für Wiederholungsrichtlinien

SDK	SetRetryPolicy-Methode	Richtlinienimplementierungen	Implementierungsleitfaden
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Weitere Informationen unter: IOTHUB_CLIENT_RETRY_POLICY	C-Implementierung
Java	SetRetryPolicy	Standard:ExponentialBackoffWithJitter-Klasse Benutzerdefiniert: RetryPolicy-Schnittstelle implementieren Keine Wiederholung:NoRetry-Klasse	Java-Implementierung
.NET	DeviceClient.SetRetryPolicy	Standard:ExponentialBackoff-Klasse Benutzerdefiniert:IRetryPolicy-Schnittstelle implementieren Keine Wiederholung:NoRetry-Klasse	C#-Implementierung
Node	setRetryPolicy	Standard:ExponentialBackoffWithJitter-Klasse Benutzerdefiniert:RetryPolicy-Schnittstelle implementieren Keine Wiederholung:NoRetry-Klasse	Node-Implementierung
Python	Derzeit nicht unterstützt	Derzeit nicht unterstützt	Integrierte Verbindungsversuche: Abgebrochene Verbindungen werden standardmäßig mit einem festen Intervall von 10 Sekunden erneut versucht. Diese Funktionalität kann bei Bedarf deaktivier und das Intervall kann konfiguriert werden.

Hub-Wiederverbindungsflow

Wenn Sie IoT Hub nur ohne DPS verwenden, verwenden Sie die folgende Strategie für die erneute Verbindung.

Wenn ein Gerät keine Verbindung mit IoT Hub herstellt oder vom IoT Hub getrennt wird:

Verwenden Sie einen exponentiellen Back-Off mit Jitter-Verzögerungsfunktion.
Stellen Sie eine erneute Verbindung mit IoT Hub her.

Die folgende Abbildung fasst den Flow der Wiederherstellung der Verbindung zusammen:

Abbildung des Flow für die erneute Verbindung des Geräts für IoT Hub.

Hub mit DPS-Wiederverbindungsflow

Wenn Sie IoT Hub mit DPS verwenden, verwenden Sie die folgende Strategie für die erneute Verbindung.

Wenn ein Gerät keine Verbindung mit IoT Hub herstellt oder von IoT Hub getrennt wird, stellen Sie die Verbindung basierend auf den folgenden Fällen erneut her:

Szenario für die erneute Verbindung	Strategie für die erneute Verbindung
Für Fehler, die Verbindungsversuche zulassen (HTTP-Antwortcode 500)	Verwenden Sie einen exponentiellen Back-Off mit Jitter-Verzögerungsfunktion. Stellen Sie eine erneute Verbindung mit IoT Hub her.
Bei Fehlern, die darauf hindeuten, dass ein Wiederholungsvorgang möglich ist, die erneute Verbindung ist jedoch 10 aufeinanderfolgende Male fehlgeschlagen.	Stellen Sie das Gerät an DPS erneut bereit.
Bei Fehlern, die keine Verbindungsversuche zulassen (HTTP-Antworten 401, Nicht autorisiert oder 403, Verboten oder 404, Nicht gefunden)	Stellen Sie das Gerät an DPS erneut bereit.