Freigeben über

Grundlegendes zu Azure IoT Edge-Grenzwerten und -Einschränkungen

  • Artikel

Gilt für: Häkchen für IoT Edge 1.5 IoT Edge 1.5 IoT Edge 1.4 Häkchen IoT Edge 1.4

Wichtig

IoT Edge 1.5 LTS und IoT Edge 1.4 LTS sind unterstützte Releases. Das Ende der Lebensdauer von IoT Edge 1.4 LTS wird am 12. November 2024 erreicht. Wenn Sie ein früheres Release verwenden, finden Sie weitere Informationen unter Aktualisieren von IoT Edge.

In diesem Artikel werden die Grenzwerte und Einschränkungen bei der Verwendung von IoT Edge erläutert.

Grenzwerte

Anzahl untergeordneter Elemente in der Gatewayhierarchie

Bei jedem IoT Edge übergeordneten Gerät in Gatewayhierarchien kann es standardmäßig bis zu 100 verbundene untergeordnete Geräte geben.

Es ist jedoch wichtig zu wissen, dass jedes IoT Edge-Gerät in einer geschachtelten Topologie eine separate logische Verbindung mit dem übergeordneten EdgeHub (oder IoT Hub) für jeden verbundenen Client (Gerät oder Modul) und eine Verbindung für sich selbst öffnen muss. Die Verbindungen auf jeder Ebene werden also nicht aggregiert, sondern hinzugefügt.

Wenn beispielsweise 2 untergeordnete IoT Edge-Geräte auf einer L4-Ebene vorhanden sind, und jedes davon wiederum über 100 Clients verfügt, dann hätte das übergeordnete IoT Edge-Gerät auf der Ebene oberhalb von L5 insgesamt 202 eingehende Verbindungen von L4.

Sie können diesen Grenzwert ändern, indem Sie im edgeHub-Modul des übergeordneten Geräts die Umgebungsvariable MaxConnectedClients festlegen. Bei IoT Edge kann es allerdings zu Problemen beim Melden seines Zustands in den von Gerätezwillingen berichteten Eigenschaften kommen, wenn die Anzahl der Clients ein paar Hundert überschreitet, wegen des Grenzwerts für die IoT Hub-Zwillingsgröße. Gehen Sie generell vorsichtig vor, wenn Sie den Grenzwert erhöhen, indem Sie diese Umgebungsvariable ändern.

Weitere Informationen finden Sie unter Erstellen einer Gatewayhierarchie.

Größe für gewünschte Eigenschaften

IoT Hub erzwingt die folgenden Einschränkungen:

  • Ein Größenlimit von 8 KB für den Wert von Tags
  • Ein Größenlimit von 32 KB für den Wert von properties/desired und properties/reported

Weitere Informationen finden Sie unter Größe von Modulzwillingen.

Anzahl geschachtelter Hierarchieebenen

Ein IoT Edge-Gerät kann maximal fünf Ebenen von IoT Edge-Geräten aufweisen, die als untergeordnete Geräte darunter verknüpft sind.

Weitere Informationen finden Sie unter Beziehungen zwischen über- und untergeordneten Geräten.

Anzahl der Module in einer Bereitstellung

IoT Hub erzwingt die folgenden Einschränkungen für automatische IoT Edge-Bereitstellungen:

Beschränkungen

Zertifikate

Für IoT Edge-Zertifikate gelten die folgenden Einschränkungen:

  • Der allgemeine Name (Common Name, CN) darf nicht mit dem Hostnamen identisch sein, der in der Konfigurationsdatei auf dem IoT Edge-Gerät verwendet wird.
  • Der Name, der von Clients zum Herstellen einer Verbindung mit IoT Edge verwendet wird, darf nicht mit dem allgemeinen Namen übereinstimmen, der im Edgezertifizierungsstellenzertifikat verwendet wird.

Weitere Informationen finden Sie unter Zertifikate für die Gerätesicherheit.

TPM-Nachweis

Wenn Sie den TPM-Nachweis mit dem Device Provisioning Service verwenden, müssen Sie TPM 2.0 verwenden.

Weitere Informationen finden Sie unter Geräteanforderungen für den TPM-Nachweis.

Routingsyntax

Die Routingsyntax ist bei IoT Edge und IoT Hub nahezu identisch. Unterstützte Abfragesyntax:

Nicht unterstützte Abfragesyntax:

Neustartrichtlinien

Verwenden Sie on-unhealthy oder on-failure nicht als Werte in der restartPolicy von Modulen, weil sie nicht implementiert sind und keinen Neustart auslösen werden. Nur die Neustartrichtlinien never und always sind implementiert.

Die empfohlene Möglichkeit zum automatischen Neustart fehlerhafter IoT Edge-Module wird in dieser Problemumgehung beschrieben. Konfigurieren Sie die Eigenschaft Healthcheck im createOptions des Moduls, um eine fehlgeschlagene Integritätsprüfung zu behandeln.

Problembehandlungsprotokolle

Der Zugriff auf Modulprotokolle über das Azure-Portal kann verzögert sein, während Module aktualisiert werden.

Auf der Registerkarte Problembehandlung auf Ihrem Gerät in IoT Edge im Azure-Portal wird möglicherweise die Meldung „Protokolle können nicht abgerufen werden. Fehler bei der Anforderung mit Statuscode 504.“ angezeigt. Für die Anforderung ist ein Timeout aufgetreten, und unter Laufzeitstatus wird möglicherweise „Fehler“ für alle Module angezeigt.

Die Protokolle können nach einer gewissen Zeit wieder angezeigt werden. Der Grund für den verzögerten Zugriff besteht darin, dass edgeAgent möglicherweise mit dem Starten von Modulen beschäftigt ist, sodass nicht parallel Protokolle abgerufen werden können. Protokolle werden aus Moby/Docker abgerufen. Dieser Vorgang dauert also eine Weile, und bei der Anforderung kann ein Timeout auftreten, wenn edgeAgent ausgelastet ist.

Dateiupload

IoT Hub unterstützt nur Dateiupload-APIs für Geräteidentitäten, nicht für Modulidentitäten. Da IoT Edge ausschließlich Module verwendet, wird das Hochladen von Dateien in IoT Edge nicht nativ unterstützt.

Weitere Informationen zum Hochladen von Dateien mit IoT Hub finden Sie unter Hochladen Dateien mit IoT Hub.

Edge-Agent-Umgebungsvariablen

Änderungen in config.toml an edgeAgent-Umgebungsvariablen wie hostname werden auf edgeAgent nicht angewendet, wenn der Container bereits vorhanden ist. Zum Anwenden dieser Änderungen entfernen Sie den Container edgeAgent mithilfe des Befehls sudo docker rm -f edgeAgent. Der IoT Edge-Daemon erstellt den Container neu und startet edgeAgent in ungefähr einer Minute.

NTLM-Authentifizierung

NTLM-Authentifizierung wird nicht unterstützt. Proxys, die mit NTLM-Authentifizierung konfiguriert sind, funktionieren nicht.

IoT Edge hat eingeschränkte Unterstützung für die Proxyauthentifizierung. Proxys, die nur für die Authentifizierung mit Benutzername und Kennwort konfiguriert sind, werden unterstützt.

Nächste Schritte

Weitere Informationen finden Sie unter Andere IoT Hub-Grenzwerte.