Approcci architetturali per soluzioni multi-tenant basate sull'hub IoT

Le soluzioni basate su hub IoT multi-tenant sono disponibili in diverse versioni e dimensioni. Potrebbero essere presenti molti requisiti e vincoli, tra cui la proprietà dell'infrastruttura, l'isolamento dei dati dei clienti e la conformità. Può essere difficile definire un modello che soddisfi tutti questi vincoli di progettazione e spesso è necessario prendere in considerazione più dimensioni. Questo articolo descrive diversi approcci comunemente usati per risolvere le considerazioni sulla multitenancy per le soluzioni basate sull'hub IoT.

Considerazioni e requisiti principali

Queste considerazioni e requisiti vengono presentati nell'ordine in cui vengono in genere classificati in ordine di priorità per la progettazione di una soluzione.

Governance e conformità

Le considerazioni sulla governance e sulla conformità potrebbero richiedere l'uso di un modello o di un set specifico di risorse IoT. Non tutti i servizi IoT hanno le stesse certificazioni o funzionalità. Se è necessario soddisfare specifici standard di conformità, potrebbe essere necessario selezionare servizi specifici. Per ulteriori informazioni, vedere gli approcci architettonici per la governance e la conformità nelle soluzioni multitenant.

La governance in IoT può anche assumere altre forme, ad esempio la proprietà e la gestione dei dispositivi. Il cliente è proprietario del dispositivo o del provider di soluzioni? Chi possiede la gestione di tali dispositivi? Queste considerazioni e implicazioni sono univoche per ogni provider di soluzioni e possono portare a scelte diverse nel modello di tecnologia, modello di distribuzione e multi-tenancy usato.

Ridimensiona

È importante pianificare la scalabilità della soluzione. La scala viene spesso considerata in queste tre dimensioni:

• Quantità di dispositivi: tutti i servizi di gestione dei dispositivi di Azure - Azure IoT Central, hub IoT di Azure servizio Device Provisioning (DPS) e hub IoT di Azure - presentano limitazioni sul numero di dispositivi supportati in una singola istanza.

  Suggerimento

  Fare riferimento alla documentazione su larga scala se si prevede di distribuire un numero molto elevato di dispositivi.

• Velocità effettiva dei dispositivi: dispositivi diversi, anche nella stessa soluzione, potrebbero avere requisiti di velocità effettiva diversi. "Velocità effettiva" in questo contesto si riferisce sia al numero di messaggi in un periodo di tempo che alle dimensioni dei messaggi. Ad esempio, in un:

  • Soluzione smart-building, termostati in genere segnalano i dati a una frequenza inferiore rispetto agli ascensori.
  • In una soluzione del veicolo connesso, i messaggi di dati di registrazione della fotocamera del veicolo sono in genere più grandi dei messaggi di telemetria di navigazione.

  Se i messaggi vengono limitati in termini di frequenza, valutare la possibilità di aumentare le istanze di un servizio. Se i tuoi messaggi sono limitati in relazione alle dimensioni, considera di passare a istanze di dimensioni maggiori di un servizio.

• Inquilini: La portata di un singolo inquilino può essere ridotta, ma moltiplicata per il numero di inquilini, può crescere rapidamente.

Prestazioni e affidabilità

Isolamento dei tenant

Le soluzioni completamente condivise possono avere vicini rumorosi. Nei casi dell'hub IoT e di IoT Central, i vicini rumorosi possono generare codici di risposta HTTP 429 ("Troppe richieste"), che sono errori rigidi che possono causare un effetto a catena. Per altre informazioni, vedere Quote e limitazione.

Nelle soluzioni completamente multi-tenant, questi effetti possono essere propagati. Quando i clienti condividono applicazioni dell'hub IoT o IoT Central, tutti i clienti dell'infrastruttura condivisa ricevono errori. Poiché hub IoT e IoT Central sono in genere i punti di ingresso per i dati nel cloud, è probabile che anche altri sistemi downstream che dipendono da questi dati non riescano. Spesso, il motivo più comune per questi errori è quando viene superato un limite di quota dei messaggi. In questo caso, la soluzione più rapida e più semplice per le soluzioni hub IoT consiste nell'aggiornare lo SKU hub IoT, aumentare il numero di unità di hub IoT o entrambe. Per le soluzioni IoT Central, la soluzione viene ridimensionata automaticamente in base alle esigenze, fino al numero documentato di messaggi supportati.

È possibile isolare e distribuire i tenant sui piani di controllo, gestione e comunicazione di IoT utilizzando i criteri di allocazione personalizzati di DPS . Inoltre, quando si seguono le indicazioni per soluzioni IoT a scalabilità elevata, è possibile gestire altre distribuzioni di allocazione a livello di bilanciamento del carico DPS.

Archiviazione dei dati, query, utilizzo e conservazione

Le soluzioni IoT tendono a essere intensive di dati, sia in streaming che a riposo. Per altre informazioni sulla gestione dei dati nelle soluzioni multi-tenant, vedere Approcci architetturali per l'archiviazione e i dati nelle soluzioni multi-tenant.

Sicurezza

Le soluzioni IoT spesso hanno considerazioni sulla sicurezza a più livelli, soprattutto nelle soluzioni distribuite in un'architettura di riferimento aziendale purdue modificata dal cloud o in soluzioni industry 4.0. L'approccio di progettazione selezionato influisce sui livelli di rete e sui limiti esistenti; dopo aver selezionato la progettazione fisica, è possibile selezionare l'implementazione della sicurezza. È possibile usare gli strumenti seguenti in qualsiasi approccio:

• Microsoft Defender per IoT, una soluzione di monitoraggio IoT completa da considerare che offre una licenza EIoT per dispositivo e licenze del sito OT per ogni dispositivo e/o sito. A seconda dell'approccio selezionato più avanti in questo articolo, lo scenario di licenza utente denominato Microsoft 365 potrebbe non essere possibile. In tal caso, sono disponibili le opzioni di licenza per dispositivo e sito, che sono opzioni di licenza indipendenti dalle licenze tenant di Microsoft 365.

• Firewall di Azure o un dispositivo firewall non Microsoft, che dovresti considerare per isolare i livelli di rete e monitorare il traffico di rete. La scelta esatta dell'approccio determina dove i carichi di lavoro hanno isolamento di rete rispetto a una rete condivisa, come illustrato più avanti in questo articolo.

• Azure IoT Edge.

La maggior parte di questi argomenti di sicurezza si applica in una soluzione multi-tenant simile a quella in una soluzione a tenant singolo, con le varianti associate all'approccio selezionato. Un componente che probabilmente sarà sostanzialmente diverso in una soluzione IoT complessiva è l'identità dell'utente e dell'applicazione. Gli approcci architetturali per l'identità nelle soluzioni multi-tenant illustrano questo aspetto di una soluzione multi-tenant complessiva.

Approcci da considerare

Le considerazioni e le scelte per i componenti principali, ad esempio gestione, inserimento, elaborazione, archiviazione e sicurezza, sono le stesse per soluzioni IoT singole e multi-tenant. La differenza principale è il modo in cui si organizzano e si usano i componenti per supportare la multi-tenancy. Ad esempio, punti decisionali comuni per:

• Si potrebbe scegliere di utilizzare SQL Server o Azure Data Explorer per l'archiviazione.
• Il livello di inserimento e gestione consiste nel scegliere tra l'hub IoT e IoT Central.

La maggior parte delle soluzioni IoT rientra in un modello di architettura radice, che è una combinazione del modello di distribuzione, del modello di tenancy e del modello di distribuzione. I requisiti e le considerazioni principali descritti in precedenza determinano questi fattori.

Uno dei punti decisionali più importanti da prendere, all'interno dello spazio IoT, consiste nel selezionare tra approcci PaaS (Application-Platform-as-a-Service) e PaaS (Platform-as-a-Service). Per ulteriori informazioni, consultare Confrontare gli approcci delle soluzioni Internet delle Cose (IoT) (PaaS vs. aPaaS).

Questa scelta è il comune dilemma "sviluppare o acquistare" che molte organizzazioni si trovano ad affrontare in molti progetti. È importante valutare i vantaggi e gli svantaggi di entrambe le opzioni.

Concetti e considerazioni per le soluzioni aPaaS

Una tipica soluzione aPaaS che usa Azure IoT Central, come core della soluzione, potrebbe usare i servizi PaaS e aPaaS di Azure seguenti:

• Hub eventi di Azure come motore di messaggistica e flusso di dati multipiattaforma di livello aziendale.
• App per la logica di Azure come offerta di piattaforma distribuita come servizio o iPaaS di integrazione.
• Azure Esplora dati come piattaforma di analisi dei dati.
• Power BI come piattaforma di visualizzazione e creazione di report.

Nel diagramma precedente i tenant condividono un ambiente IoT Central, Azure Esplora dati, Power BI e App per la logica di Azure.

Questo approccio è in genere il modo più rapido per ottenere una soluzione sul mercato. Si tratta di un servizio su larga scala che supporta la multi-tenancy usando le organizzazioni.

È importante comprendere che poiché IoT Central è un'offerta aPaaS, esistono determinate decisioni che non rientrano nel controllo dell'implementatore. Queste decisioni includono:

• IoT Central usa Microsoft Entra ID come provider di identità.
• Le distribuzioni di IoT Central vengono eseguite usando operazioni sia di controllo che di piano dati, che combinano documenti dichiarativi con codice imperativo.
• Limite massimo di nodi e profondità massima dell'albero in un modello multi-tenant basato su IoT Central, potrebbe forzare un provider di servizi ad avere più istanze di IoT Central. In tal caso, è consigliabile seguire il modello Deployment Stamp.
• IoT Central impone limiti alle chiamate API, che potrebbero influire sulle implementazioni di grandi dimensioni.

Concetti e considerazioni per le soluzioni PaaS

Un approccio basato su PaaS può usare i servizi di Azure seguenti:

• hub IoT di Azure come piattaforma di configurazione e comunicazione del dispositivo principale.
• Servizio Device Provisioning IoT di Azure come distribuzione del dispositivo e piattaforma di configurazione iniziale.
• Azure Esplora dati per l'archiviazione e l'analisi dei dati delle serie temporali dei percorsi ad accesso frequente e sporadico dai dispositivi IoT.
• Analisi di flusso di Azure per l'analisi dei dati dei percorsi ad accesso frequente dai dispositivi IoT.
• Azure IoT Edge per eseguire intelligenza artificiale (AI), servizi non Microsoft o logica aziendale, nei dispositivi IoT Edge.

Nel diagramma precedente ogni tenant si connette a un'app Web condivisa, che riceve dati da hub IoT e un'app per le funzioni. I dispositivi si connettono al servizio Device Provisioning e a hub IoT.

Questo approccio richiede maggiore impegno per gli sviluppatori per creare, distribuire e gestire la soluzione (rispetto a un approccio aPaaS). Per comodità dell'implementatore, sono predefinite meno funzionalità. Pertanto, questo approccio offre anche un maggiore controllo, perché meno presupposti sono incorporati nella piattaforma sottostante.

Modelli di architettura radice

La tabella seguente elenca i modelli comuni per le soluzioni IoT multi-tenant. Ogni modello include le informazioni seguenti:

• Nome del modello, basato sulla combinazione del tipo di destinazione, del modello e della distribuzione.
• Destinazione di distribuzione, che rappresenta la sottoscrizione di Azure in cui distribuire le risorse.
• Il modello Tenancy a cui viene fatto riferimento dal modello, come descritto in Modelli multi-tenancy
• Modello di distribuzione, che fa riferimento a una distribuzione semplice con considerazioni minime sulla distribuzione, un modello Geode o un modello deployment stamp.

Modello	Destinazione di distribuzione	Modello tenancy	Modello di distribuzione
SaaS semplice	Sottoscrizione del provider di servizi	Completamente multi-tenant	Semplice
SaaS orizzontale	Sottoscrizione del provider di servizi	Partizionato orizzontalmente	Stamp di distribuzione
Automatizzato a tenant singolo	Sottoscrizione del provider di servizi o del cliente	Tenant singolo per cliente	Semplice

SaaS semplice

Destinazione distribuzione	Modello tenancy	Modello di distribuzione
Sottoscrizione del provider di servizi	Completamente multi-tenant	Semplice

L'approccio SaaS semplice è l'implementazione più semplice per una soluzione IoT SaaS. Come illustrato nel diagramma precedente, tutta l'infrastruttura è condivisa e l'infrastruttura non ha un timbro geografico o scala applicato. Spesso l'infrastruttura si trova all'interno di una singola sottoscrizione di Azure.

Azure IoT Central supporta il concetto di organizzazioni. Le organizzazioni consentono a un provider di soluzioni di separare facilmente i tenant in modo sicuro e gerarchico, condividendo al tempo stesso la progettazione di base delle applicazioni in tutti i tenant.

Le comunicazioni ai sistemi all'esterno di IoT Central, ad esempio per l'analisi dei dati a lungo termine, lungo un percorso sporadico o una connettività con le operazioni aziendali, vengono eseguite tramite altre offerte Microsoft PaaS e aPaaS. Queste altre offerte possono includere i servizi seguenti:

• Hub eventi di Azure come motore di messaggistica e flusso di dati multipiattaforma di livello aziendale.
• App per la logica di Azure come piattaforma di integrazione distribuita come servizio o iPaaS.
• Azure Esplora dati come piattaforma di analisi dei dati.
• Power BI come piattaforma di visualizzazione e creazione di report.

Se si confronta l'approccio SaaS semplice con il modello aPaaS automatizzato a tenant singolo, molte caratteristiche sono simili. La differenza principale tra i due modelli è che:

• Nel modello tenant singolo automatizzato si distribuisce un'istanza di IoT Central distinta per ogni tenant,
• Nel modello SaaS semplice con aPaaS devi distribuire un'istanza condivisa per più clienti e crei un'organizzazione IoT Central per ogni locatario.

Poiché si condivide un livello dati multi-tenant in questo modello, è necessario implementare la sicurezza a livello di riga per isolare i dati dei clienti. Per ulteriori informazioni, vedere gli approcci architetturali per archiviazione e dati nelle soluzioni multitenant.

Vantaggi:

• Più facile da gestire e operare rispetto agli altri approcci presentati qui.

Rischi:

• Questo approccio potrebbe non essere facilmente scalabilità fino a un numero elevato di dispositivi, messaggi o tenant.

• I servizi e i componenti sono condivisi, quindi un malfunzionamento in un qualsiasi componente potrebbe influire su tutti i tuoi tenant. Questo rischio è un rischio per l'affidabilità e la disponibilità elevata della soluzione.

• È importante considerare come gestire la conformità, le operazioni, il ciclo di vita del tenant e la sicurezza dei subfleet di dispositivi. Queste considerazioni diventano importanti a causa della natura condivisa di questo tipo di soluzione nei piani di controllo, gestione e comunicazione.

SaaS orizzontale

Destinazione di distribuzione	Modello tenancy	Modello di distribuzione
Sottoscrizione del provider di servizi	Partizionato orizzontalmente	Stamp di distribuzione

Un approccio di scalabilità comune consiste nel partizionare orizzontalmente la soluzione. Ciò significa che sono presenti alcuni componenti condivisi e alcuni componenti per cliente.

All'interno di una soluzione IoT sono disponibili molti componenti che possono essere partizionati orizzontalmente. I sottosistemi partizionati orizzontalmente vengono in genere disposti usando un modello di stamp di distribuzione che si integra con la soluzione più grande.

Esempio di SaaS orizzontale

L'esempio di architettura seguente partiziona IoT Central per ogni cliente finale, che funge da portale di gestione dei dispositivi, comunicazioni dei dispositivi e amministrazione. Questo partizionamento viene spesso eseguito in modo che il cliente finale che utilizza la soluzione abbia il controllo completo sull'aggiunta, la rimozione e l'aggiornamento dei propri dispositivi, senza intervento del fornitore del software. Il resto della soluzione segue un modello di infrastruttura condivisa standard, che risolve l'analisi dei percorsi ad accesso frequente, le integrazioni aziendali, la gestione SaaS e le esigenze di analisi dei dispositivi.

Ogni tenant ha una propria organizzazione IoT Central, che invia dati di telemetria a un'app per le funzioni condivise e la rende disponibile agli utenti aziendali dei tenant tramite un'app Web.

Vantaggi:

• Facile da gestire e utilizzare, anche se potrebbe essere necessaria una gestione aggiuntiva per i componenti a tenant singolo.
• Opzioni di ridimensionamento flessibili, perché i livelli vengono ridimensionati in base alle esigenze.
• L'effetto dei guasti dei componenti è ridotto. Anche se un errore di un componente condiviso interessa tutti i clienti, i componenti ridimensionati orizzontalmente influiscono solo sui clienti associati a istanze di scalabilità specifiche.
• Miglioramento delle informazioni dettagliate sul consumo per tenant per i componenti partizionati.
• I componenti partizionati offrono personalizzazioni più semplici per tenant.

Rischi:

• La scalabilità della soluzione, in particolare per eventuali componenti condivisi.
• L'affidabilità e la disponibilità elevata sono potenzialmente influenzate. Un singolo errore nei componenti condivisi potrebbe influire su tutti i tenant contemporaneamente.
• La personalizzazione del componente partizionato per tenant richiede considerazioni su DevOps e gestione a lungo termine.

Di seguito sono riportati i componenti più comuni che sono in genere adatti per il partizionamento orizzontale.

Database

È possibile scegliere di partizionare i database. Spesso si tratta dei dati di telemetria e degli archivi dati del dispositivo partizionati. Spesso vengono usati più archivi dati per scopi specifici diversi, ad esempio archiviazione ad accesso frequente o archiviazione o per informazioni sullo stato della sottoscrizione tenancy.

Separare i database per ogni tenant, per i vantaggi seguenti:

• Supportare gli standard di conformità. I dati di ogni tenant sono isolati tra istanze dell'archivio dati.
• Correggere i problemi del vicino rumoroso.

Gestione, comunicazioni e amministrazione dei dispositivi

hub IoT di Azure servizio Device Provisioning, hub IoT e le applicazioni IoT Central possono spesso essere distribuite come componenti partizionati orizzontalmente. In questo approccio, è necessario un altro servizio per reindirizzare i dispositivi all'istanza del servizio Device Provisioning appropriata per il piano di gestione, controllo e telemetria del tenant specifico. Per ulteriori informazioni, vedere il documento informativo sulla scalabilità di una soluzione Azure IoT per supportare milioni di dispositivi.

Questo approccio viene spesso adottato per consentire ai clienti finali di gestire e controllare i propri dispositivi che sono più direttamente e completamente isolati.

Se il piano di comunicazione del dispositivo è partizionato orizzontalmente, i dati di telemetria devono essere arricchiti con dati che identificano il tenant di origine. Questo arricchimento consente al processore di flusso di conoscere le regole del tenant da applicare al flusso di dati. Ad esempio, se un messaggio di telemetria genera una notifica nel processore di flusso, il processore di flusso deve determinare il percorso di notifica appropriato per il tenant associato.

Elaborazione dei flussi

Partizionando l'elaborazione del flusso, si abilitano le personalizzazioni per tenant dell'analisi all'interno dei processori di flusso.

Automatizzato a tenant singolo

Un approccio automatizzato a tenant singolo si basa su un processo decisionale e una progettazione simili a una soluzione aziendale.

Ogni tenant ha un ambiente identico e isolato, con un'organizzazione IoT Central e altri componenti dedicati.

Destinazione distribuzione	Modello tenancy	Modello di distribuzione
Sottoscrizione del provider di servizi o del cliente	Tenant singolo per cliente	Semplice

Un punto decisionale critico in questo approccio consiste nella scelta della sottoscrizione di Azure in cui devono essere distribuiti i componenti. Se i componenti vengono distribuiti nella sottoscrizione, si ha un maggiore controllo e una migliore visibilità sul costo della soluzione, ma è necessario avere maggiori problemi di sicurezza e governance della soluzione. Viceversa, se la soluzione viene distribuita nella sottoscrizione del cliente, il cliente è responsabile della sicurezza e della governance della distribuzione.

Questo modello supporta un livello elevato di scalabilità perché i requisiti di tenant e sottoscrizione sono in genere i fattori di limitazione nella maggior parte delle soluzioni. Pertanto, isolare ogni tenant per offrire un ambito di grandi dimensioni per il ridimensionamento del carico di lavoro di ogni tenant, senza sforzi sostanziali da parte dello sviluppatore della soluzione.

Questo modello ha anche una bassa latenza rispetto ad altri modelli, perché è possibile distribuire i componenti della soluzione in base all'area geografica dei clienti. L'affinità geografica consente percorsi di rete più brevi tra un dispositivo IoT e la distribuzione di Azure.

Se necessario, è possibile estendere la distribuzione automatizzata per supportare una migliore latenza o scalabilità, abilitando la distribuzione rapida di istanze aggiuntive della soluzione in aree geografiche nuove o esistenti.

L'approccio automatizzato a tenant singolo è simile al semplice modello saaS aPaaS. La differenza principale tra i due modelli è che nell'approccio automatizzato a tenant singolo si distribuisce un'istanza di IoT Central distinta per ogni tenant, mentre nel modello SaaS semplice con un modello aPaaS si distribuisce un'istanza condivisa di IoT Central con più organizzazioni IoT Central.

Vantaggi:

• Facile da gestire e operare.
• L'isolamento dell'inquilino è garantito.

Rischi:

• L'automazione iniziale può essere complicata per il nuovo personale di sviluppo.
• La sicurezza delle credenziali tra clienti per la gestione della distribuzione di livello superiore deve essere applicata oppure le compromissioni possono estendersi tra i clienti.
• Si prevede che i costi siano più elevati, perché i vantaggi di scalabilità di un'infrastruttura condivisa tra i clienti non sono disponibili.
• Molte istanze da gestire se il provider di soluzioni è proprietario della manutenzione di ogni istanza.

Aumentare la scalabilità di SaaS

Quando si espande la scalabilità di una soluzione a distribuzioni di grandi dimensioni, esistono problemi specifici che si verificano in base ai limiti del servizio, alle problematiche geografiche e ad altri fattori. Per altre informazioni sulle architetture di distribuzione IoT su larga scala, vedere Scalabilità orizzontale di una soluzione Azure IoT per supportare milioni di dispositivi.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Michael C. Bazarewsky | Senior Customer Engineer, FastTrack per Azure
• David Crook | Principal Customer Engineer, FastTrack per Azure

Altri contributori:

• John Downs | Principal Software Engineer
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

Passaggi successivi

• Esaminare le linee guida per la multi-tenancy e Azure Cosmos DB.
• Informazioni sui percorsi di dati ad accesso frequente, ad accesso frequente e ad accesso sporadico con IoT in Azure.