Informazioni sui limiti e le restrizioni Azure IoT Edge

Si applica a: IoT Edge 1.6

Questo articolo illustra i limiti e le restrizioni quando si usa IoT Edge.

Limiti

Numero di client connessi nella gerarchia del gateway

Ogni dispositivo padre IoT Edge in una gerarchia di gateway può avere fino a 100 client connessi per impostazione predefinita.

Ogni dispositivo IoT Edge in una topologia annidata apre una connessione logica separata all'EdgeHub padre (o a hub IoT) per ogni modulo e per ogni client downstream instradato attraverso di esso, oltre a una connessione per l'edgeHub figlio stesso. La connessione dell'edgeHub figlio compare nel gemello del modulo connected-clients del padre come <childDeviceId>/$edgeHub. Le connessioni a ogni livello non vengono aggregate, ma aggiunte.

Ad esempio, se un dispositivo figlio di livello L4 IoT Edge ha 100 client downstream connessi (dispositivi e moduli), apre 100 connessioni al relativo edgeHub padre più 1 connessione per l'edgeHub figlio stesso, per 101 totale. Se esistono due dispositivi figlio di questo tipo in L4, l'elemento padre L5 vede 202 connessioni in ingresso totali da L4.

È possibile modificare questo limite impostando la variabile di ambiente MaxConnectedClients nel modulo edgeHub del dispositivo padre.

Per altre informazioni, vedere Creare una gerarchia di gateway.

Dimensioni delle proprietà del modulo gemello

hub IoT applica queste restrizioni:

• Limite di dimensioni di 8 KB per il valore dei tag.
• Limite di dimensioni di 32 KB per il valore di properties/desired e properties/reported.

Per altre informazioni, vedere Dimensioni del modulo gemello.

Numero di livelli di gerarchia annidati

Un dispositivo IoT Edge supporta fino a cinque livelli di dispositivi IoT Edge collegati come figli al di sotto di esso.

Per altre informazioni, vedere Relazioni padre e figlio.

Numero di moduli in una distribuzione

hub IoT ha le seguenti restrizioni per le distribuzioni automatiche di IoT Edge:

• 50 moduli per distribuzione
  • Questo limite viene sostituito dal limite di dimensioni del modulo gemello di hub IoT 32 KB. Per altre informazioni, vedere Tenere presente i limiti delle dimensioni dei dispositivi gemelli quando si usano moduli personalizzati.
• 100 distribuzioni (incluse le distribuzioni a più livelli per hub SKU a pagamento)
• 10 distribuzioni per hub SKU gratuito

Restrizioni

Certificati

IoT Edge certificati presentano le restrizioni seguenti:

• Il nome comune (CN) non può essere uguale a quello di hostname usato nel file di configurazione nel dispositivo IoT Edge.
• Il nome usato dai client per connettersi a IoT Edge non può essere uguale al nome comune usato nel certificato della CA Edge.

Per altre informazioni, vedere Certificati per la sicurezza dei dispositivi.

Attestazione TPM

Quando si usa l'attestazione TPM con il servizio device provisioning, è necessario usare TPM 2.0.

Per altre informazioni, vedere Requisiti dei dispositivi di attestazione TPM.

Sintassi di routing

"La sintassi di routing di IoT Edge e hub IoT è quasi identica." Sintassi di query supportata:

• Query di routing dei messaggi basata sulle proprietà del messaggio
• Query di routing dei messaggi basata sul corpo del messaggio

Sintassi di query non supportata:

• Query di routing dei messaggi basata su dispositivo gemello

Criteri di riavvio

Il valore dei criteri di riavvio on-unhealthy viene accettato dallo schema, ma il runtime attualmente non deriva lo stato di non integrità dai controlli di salute di Docker, quindi non ha effetti pratici. Il on-failure criterio di riavvio riavvia i moduli che escono con un codice di uscita diverso da zero. Solo i criteri di riavvio never, on-failure e always producono un comportamento osservabile.

Per riavviare automaticamente i moduli che diventano non integri, usare la soluzione alternativa indicata in questo problema di GitHub. Configurare la Healthcheck proprietà nel modulo createOptions per gestire un controllo di integrità non riuscito.

Log di risoluzione dei problemi

L'accesso ai log dei moduli dal portale di Azure può essere ritardato durante l'aggiornamento dei moduli.

Se si visualizza la scheda Troubleshoot dal dispositivo in IoT Edge nel portale di Azure, è possibile che venga visualizzato il messaggio "Impossibile recuperare i log. La richiesta non è riuscita con codice di stato 504". La richiesta genera un timeout e lo stato del runtime mostra "Errore" per tutti i moduli.

È possibile visualizzare di nuovo i log dopo un po' di tempo. L'accesso è ritardato perché edgeAgent può essere occupato a partire dai moduli, quindi non può recuperare i log contemporaneamente. I log vengono estratti da Moby o Docker, quindi questo processo richiede tempo e la richiesta può andare in timeout se edgeAgent è occupato.

Caricamento di file

hub IoT supporta solo le API di caricamento dei file per le identità dei dispositivi, non le identità del modulo. Poiché IoT Edge usa esclusivamente moduli, il caricamento di file non è supportato in modo nativo in IoT Edge.

Per altre informazioni sul caricamento di file con hub IoT, vedere Upload files with hub IoT.

Variabili di ambiente dell'agente Edge

Le modifiche apportate alle config.tomledgeAgent variabili di ambiente, ad esempio , hostname non vengono applicate a edgeAgent se il contenitore esiste già. Per applicare queste modifiche, rimuovere il edgeAgent contenitore eseguendo sudo docker rm -f edgeAgent. Il daemon IoT Edge ricrea il contenitore e avvia edgeAgent in circa un minuto.

Autenticazione NTLM

L'autenticazione NTLM non è supportata. I proxy configurati con l'autenticazione NTLM non funzionano.

IoT Edge ha un supporto limitato per l'autenticazione proxy. Sono supportati solo i proxy configurati per l'autenticazione con nome utente e password.

Passaggi successivi

Per altre informazioni, vedere hub IoT altri limiti.