Esegui la migrazione degli ambienti da IoT Core

Last reviewed 2023-02-01 UTC

Google ha annunciato il ritiro di IoT Core. Questo documento ha lo scopo di aiutarti a progettare e implementare un piano di migrazione da un ambiente basato su IoT Core a un nuovo ambiente che non dipende da IoT Core per uno dei seguenti casi:

  • Autenticazione dispositivo perimetrale
  • Gestione dei dispositivi periferici
  • Comunicazione tra i tuoi dispositivi periferici e Google Cloud

Il documento fornisce anche indicazioni su come valutare l'opportunità di eseguire la migrazione in seguito al ritiro di IoT Core e capire come potrebbe essere una migrazione.

Questo documento fa parte di una serie di documenti che forniscono informazioni sulle architetture IoT su Google Cloud e sulla migrazione da IoT Core. Gli altri documenti di questa serie includono:

Il carico di lavoro per la migrazione

Questo documento presuppone che i carichi di lavoro di cui vuoi eseguire la migrazione da IoT Core abbiano le seguenti parti:

  • Una parte che viene eseguita sui dispositivi periferici (il cui deployment è stato eseguito ai bordi del tuo ambiente, accanto ai dati che vuoi elaborare)
  • Un backend eseguito su Google Cloud

Il seguente diagramma mostra l'architettura di un carico di lavoro tipico che utilizza IoT Core. In questa architettura, Cloud IoT integra i dispositivi periferici che hanno un backend che viene eseguito su Google Cloud.

Flusso di eventi dai dispositivi periferici a Cloud IoT (riepilogo nel testo seguente).

Il diagramma precedente può essere sintetizzato in questo modo:

Per pianificare efficacemente la migrazione, ti consigliamo di eseguire una valutazione per comprendere appieno l'architettura dell'ambiente di origine. In questo caso, l'ambiente di origine si riferisce al tuo ambiente attuale basato su IoT Core.

Questo documento presuppone che sia possibile aggiornare la configurazione e i componenti software in esecuzione sui dispositivi periferici per la migrazione. In alcuni casi, questo approccio potrebbe non essere fattibile. Ad esempio, i dispositivi periferici o i processi di deployment potrebbero non supportare questo caso d'uso. In questo caso, ti consigliamo di ritirare i dispositivi periferici che non supportano gli aggiornamenti. Per ulteriori informazioni sulla progettazione e l'implementazione dei processi di provisioning e configurazione automatici per i dispositivi periferici, consulta Best practice per il provisioning e la configurazione automatici di sistemi e server perimetrali e bare metal.

Progetta la migrazione

Per eseguire la migrazione dell'ambiente basato su IoT Core, vi consigliamo di seguire il framework di migrazione descritto in Migrazione a Google Cloud.

Il seguente diagramma descrive il percorso del percorso di migrazione:

Percorso di migrazione con quattro fasi.

Come mostrato nel diagramma precedente, questo percorso prevede quattro fasi:

  1. Valuta: in questa fase, valuti l'ambiente di origine, i carichi di lavoro e i dispositivi periferici di cui vuoi eseguire la migrazione da Cloud IoT Core.
  2. Pianifica: in questa fase, crei l'infrastruttura di base su Google Cloud, ad esempio esegui il provisioning della gerarchia delle risorse e configuri l'accesso alla rete.
  3. Esegui il deployment: in questa fase, esegui il deployment della nuova soluzione da utilizzare al posto di IoT Core ed esegui la migrazione dei dispositivi periferici alla nuova soluzione.
  4. Ottimizzazione: in questa fase ottimizzi l'ambiente di destinazione. In questo caso, ambiente di destinazione si riferisce all'ambiente verso cui stai eseguendo la migrazione, che non si basa su IoT Core.

Valuta l'ambiente di origine e i carichi di lavoro

Nella fase di valutazione, raccogli informazioni sul tuo ambiente di origine, sui dispositivi periferici e sull'uso di IoT Core nella tua organizzazione. Queste informazioni ti aiutano a progettare un piano di migrazione e ad assicurarti di avere le risorse necessarie per la migrazione e per il tuo ambiente di destinazione.

Nella fase di valutazione:

  1. Crea un inventario dei dispositivi periferici registrati su Cloud IoT Core.
  2. Crea un inventario dei carichi di lavoro di backend che si integrano con Cloud IoT Core.
  3. Classifica i tuoi dispositivi periferici e i carichi di lavoro di backend.
  4. Dimostrazioni di progettazione e esperimenti.
  5. Calcola il costo totale di proprietà.
  6. Progettare l'architettura dell'ambiente di destinazione.
  7. Scegli prima i dispositivi periferici e i carichi di lavoro di backend di cui eseguire la migrazione.

Al termine della fase di valutazione, avrai due inventari: un inventario per i dispositivi periferici e un inventario per i carichi di lavoro di backend.

Per evitare incongruenze, ti consigliamo di mettere in pausa il deployment di nuovi dispositivi periferici e di carichi di lavoro di backend prima di creare questi inventari. Ti consigliamo inoltre di non eseguire il deployment di nuovi dispositivi periferici e di carichi di lavoro in background dopo aver creato gli inventari.

Creare un inventario dei tuoi dispositivi periferici

Per ridurre l'ambito della migrazione e progettare il piano di migrazione, è necessario sapere quanti dispositivi periferici esistono nell'ambiente di origine. Devi anche capire come i dispositivi interagiscono con IoT Core e se puoi classificarli in base a caratteristiche comuni, comportamenti, finalità o dipendenze.

Ogni dispositivo periferico che registri su IoT Core appartiene a un registro di IoT Core. Il primo passo per la creazione dell'inventario dei tuoi dispositivi periferici è l'elenco dei registri IoT Core che hai creato. Quindi, raccoglierai informazioni sui dispositivi periferici registrati in ogni registry.

Per creare l'inventario dei tuoi dispositivi periferici, considera le seguenti informazioni per ogni dispositivo periferico e in che modo il dispositivo si integra con IoT Core:

  • Identificatori: raccogli le seguenti informazioni sugli identificatori IoT Core del dispositivo periferico:

    • Identificatore definito dall'utente
    • L'ID definito dal server non modificabile che IoT Core genera automaticamente quando registri un dispositivo periferico a IoT Core
    • Il nome della risorsa che identifica in modo univoco il dispositivo periferico utilizzando l'identificatore del registry IoT Core in cui hai registrato il dispositivo periferico

  • Stato del deployment: valuta lo stato di deployment attuale del dispositivo periferico. Ad esempio, il dispositivo periferico potrebbe essere in uno dei seguenti stati:

    • Non ancora o ancora in fase di produzione
    • Pronto per il deployment, ma non ancora registrato in IoT Core
    • Già implementato nel suo sito di destinazione e registrato su IoT Core

  • Tipo di dispositivo IoT Core:valuta il tipo di dispositivo IoT Core. Ogni dispositivo periferico che registri su IoT Core può agire in due modi. Può essere un client che si connette direttamente a IoT Core. Oppure, può essere un gateway per i client che non puoi o non vuoi connettere direttamente a IoT Core.

  • Protocollo di comunicazione: IoT Core supporta due protocolli per comunicare con i dispositivi periferici: HTTP e MQTT. Valuta quale protocollo utilizzano i tuoi dispositivi periferici per comunicare con IoT Core. Per il protocollo MQTT, devi anche determinare la qualità del servizio su cui fanno affidamento i tuoi dispositivi periferici e i carichi di lavoro di backend.

  • Credenziali: IoT Core autentica i dispositivi periferici utilizzando una coppia di chiavi e token di breve durata generati utilizzando tale coppia di chiavi. Può facoltativamente verificare la firma della parte pubblica della coppia di chiavi utilizzando un metodo di verifica basato su certificato. Valutare la configurazione dell'autenticazione del dispositivo periferico. Controlla se stai utilizzando il meccanismo di verifica basato su certificato per il registro IoT Core a cui appartiene il dispositivo.

  • Metadati del dispositivo:in IoT Core, puoi definire metadati per ogni dispositivo perimetrale sotto forma di coppie chiave/valore. Ad esempio, puoi definire un'identificazione personale dell'hardware, un numero di serie, le informazioni del produttore o qualsiasi altro attributo pertinente per un dispositivo periferico. Puoi definire i metadati quando aggiungi un dispositivo periferico a un registro IoT Core o modifichi un dispositivo periferico già presente in un registro. I metadati non vengono mai inviati a o da un dispositivo periferico tramite IoT Core. Raccogli le informazioni sui metadati definiti per il dispositivo periferico.

  • Stato del dispositivo: in IoT Core, ogni dispositivo perimetrale può segnalare informazioni sul suo stato come dati strutturati o non strutturati arbitrari. Ad esempio, un dispositivo periferico potrebbe segnalare la versione del firmware in esecuzione. Oppure potrebbe segnalare le informazioni sulla sua salute, in base a metriche specifiche. IoT Core pubblica le informazioni ricevute sullo stato del dispositivo come messaggi in un argomento Pub/Sub configurato. Valuta come il tuo dispositivo periferico segnala informazioni sul suo stato e su quali argomenti Pub/Sub IoT Core pubblica questi messaggi. Determina quali componenti dell'architettura si basano sulle informazioni relative allo stato del dispositivo periferico.

  • Eventi di telemetria: ogni dispositivo perimetrale che aggiungi a un registro IoT Core può inviare eventi di telemetria come dati strutturati o non strutturati arbitrari a IoT Core. IoT Core pubblica gli eventi di telemetria ricevuti come messaggi in un argomento Pub/Sub configurato. Valuta come il tuo dispositivo periferico segnala gli eventi di telemetria e su quali argomenti Pub/Sub IoT Core pubblica questi messaggi. Determina quali componenti dell'architettura si basano sugli eventi di telemetria segnalati dal dispositivo periferico.

  • Configurazione del dispositivo:in IoT Core, puoi definire la configurazione di un dispositivo periferico come dati strutturati o non strutturati arbitrari. IoT Core consente inoltre di definire gli aggiornamenti alla configurazione di un dispositivo come nuove versioni di tale configurazione, che verranno quindi trasferite al dispositivo periferico. Valuta se il dispositivo periferico riceve la configurazione da Cloud IoT Core e raccogli informazioni su tutte le versioni di configurazione che hai definito.

  • Comandi: in IoT Core, i dispositivi periferici possono ricevere comandi da IoT Core e quindi reagire di conseguenza. Valuta se i tuoi dispositivi periferici supportano la reazione ai comandi provenienti dall'IoT Core.

  • Aggiornamenti software e di configurazione: durante la migrazione, potresti dover aggiornare i componenti software in esecuzione sul dispositivo periferico o la configurazione di questi componenti. Valutare i meccanismi di aggiornamento supportati dal dispositivo periferico. Stabilisci se il dispositivo supporta anche un meccanismo di rollback per riportarlo a uno stato di funzionamento noto se si verificano problemi durante questo tipo di aggiornamenti.

  • Tempo di inattività: durante la migrazione, i carichi di lavoro di backend o altre parti dell'ambiente di origine potrebbero non essere disponibili. Valuta se il tuo dispositivo periferico supporta i tempi di inattività, i suoi meccanismi di fallback e come si ripristina dopo il tempo di inattività.

Crea un inventario dei carichi di lavoro di backend che si integrino con IoT Core

Dopo aver creato l'inventario dei tuoi dispositivi periferici, raccogli informazioni sui carichi di lavoro di backend nel tuo ambiente di origine che si integrano con Cloud IoT Core. Un carico di lavoro di backend può integrarsi con IoT Core nei seguenti modi:

  • Inviando comandi ai dispositivi periferici e aggiornando la configurazione dei dispositivi periferici utilizzando IoT Core.
  • Abbonandoti ad argomenti Pub/Sub in cui IoT Core pubblica messaggi su eventi di telemetria e sui dispositivi perimetrali.
  • Integrandosi con le API IoT Core direttamente o utilizzando uno strumento di provisioning dell'infrastruttura. Ad esempio, potresti utilizzare Terraform per eseguire il provisioning di registry e dispositivi IoT Core.

Per creare l'inventario dei carichi di lavoro di backend che si integrano con Cloud IoT Core, considera quanto segue per ogni carico di lavoro di backend:

  • Comandi e configurazione dei dispositivi: valuta se il carico di lavoro di backend invia comandi ai dispositivi periferici e se aggiorna la configurazione dei dispositivi. Entrambe le azioni richiedono un'integrazione con le API IoT Core.
  • Eventi di telemetria e stato del dispositivo: valuta se il carico di lavoro di backend si abbona agli argomenti Pub/Sub in cui IoT Core pubblica messaggi sugli eventi di telemetria e sullo stato del dispositivo.

  • Integrazione con altre API IoT Core: valuta se il carico di lavoro di backend interagisce con qualsiasi altra API IoT Core, oltre a quelle per inviare comandi e aggiornare le configurazioni del dispositivo. Ad esempio, il carico di lavoro di backend potrebbe basarsi sulle API IoT Core per:

    • Crea registri IoT Core e aggiorna la loro configurazione.
    • Creare dispositivi IoT Core e aggiornarne la configurazione.
    • Raccogliere informazioni sui registry e sui dispositivi IoT Core.
    • Utilizza le metriche di logging di IoT Core e i log delle attività dei dispositivi.

Classifica i tuoi dispositivi periferici e i carichi di lavoro di backend

Dopo aver creato gli inventari dei tuoi dispositivi periferici e il tuo carico di lavoro di backend, classifica gli articoli in ogni inventario in base alle loro caratteristiche. Questa categorizzazione ti aiuta a redigere un piano di migrazione e a scegliere i dispositivi periferici e i carichi di lavoro di backend di cui eseguire la migrazione per primi.

Per classificare i tuoi dispositivi periferici, ti consigliamo di categorizzare in base ai tipi di interazioni che possono verificarsi tra i dispositivi periferici e i carichi di lavoro di backend. Considera i seguenti tipi di interazione:

  • Quando un dispositivo periferico invia dati ai carichi di lavoro di backend utilizzando eventi di telemetria o informazioni sullo stato del dispositivo.
  • Quando i carichi di lavoro di backend inviano istruzioni ai dispositivi periferici utilizzando i comandi o gli aggiornamenti della configurazione del dispositivo.

Per ognuno dei tipi di interazione precedenti, i tipi di messaggi scambiati durante le interazioni di quel tipo sono diversi. Tuttavia, i messaggi hanno scopi simili. Alcuni dispositivi inviano i dati da un dispositivo periferico ai carichi di lavoro di backend, ad esempio eventi di telemetria e informazioni sullo stato dei dispositivi. Alcuni dispositivi inviano le istruzioni dai carichi di lavoro di backend ai dispositivi periferici, ad esempio comandi e aggiornamenti della configurazione del dispositivo.

In base ai tipi di interazioni proposti, ti consigliamo le seguenti categorie per i tuoi dispositivi periferici:

  • Solo trasmissione: i dispositivi periferici che inviano eventi di telemetria o informazioni sullo stato del dispositivo, ma non ricevono comandi o aggiornamenti della configurazione del dispositivo dai carichi di lavoro di backend.
  • Solo ricezione: dispositivi periferici che non inviano eventi di telemetria o informazioni sullo stato del dispositivo, ma ricevono comandi o aggiornamenti della configurazione del dispositivo dai carichi di lavoro di backend.
  • Ricezione e trasmissione: dispositivi periferici che inviano eventi di telemetria e informazioni sullo stato del dispositivo e ricevono comandi o aggiornamenti della configurazione del dispositivo dai carichi di lavoro di backend.

Per classificare i carichi di lavoro di backend, puoi seguire un approccio simile a quello che hai seguito per classificare i dispositivi periferici. In base ai tipi di interazione proposti, consigliamo le seguenti categorie per i carichi di lavoro di backend:

  • Solo ricezione: carichi di lavoro di backend che ricevono eventi di telemetria o informazioni sullo stato dei dispositivi dai dispositivi periferici, ma non inviano comandi o aggiornamenti della configurazione dei dispositivi.
  • Solo invio: carichi di lavoro di backend che non ricevono eventi di telemetria o informazioni sullo stato del dispositivo, ma inviano comandi o aggiornamenti della configurazione del dispositivo.
  • Invia e ricevi: carichi di lavoro di backend che ricevono eventi di telemetria o informazioni sullo stato dei dispositivi dai dispositivi periferici e inviano comandi o aggiornamenti della configurazione del dispositivo.

Completa il test

Dopo aver creato gli inventari, devi completare le seguenti parti della fase di valutazione:

Dopo aver completato queste attività, continua a leggere questo documento.

Progettare l'architettura dell'ambiente di destinazione

Dopo aver completato le attività di valutazione precedenti, progetti l'architettura per l'ambiente di destinazione.

Questo documento è incentrato sulla migrazione dell'ambiente di origine all'ambiente di destinazione. Tuttavia, la migrazione dell'ambiente da IoT Core è anche un'opportunità per pianificare nuove funzionalità e aggiornamenti. Quando progetti l'architettura dell'ambiente di destinazione, pensa a eventuali limitazioni che potresti aver riscontrato nell'ambiente di origine. Valuta come configurare l'ambiente di destinazione per evitare queste limitazioni. Puoi anche prendere in considerazione eventuali nuove funzionalità che potrebbero essere necessarie nell'ambiente di destinazione.

In base a come hai classificato i tuoi dispositivi periferici e i carichi di lavoro di backend, potresti vedere i seguenti casi d'uso complementari di IoT Core derivanti dalla valutazione dell'ambiente di origine:

  • Importazione di dati provenienti da dispositivi periferici in un backend in esecuzione su Google Cloud.
  • Carichi di lavoro di backend per la gestione dei dispositivi periferici su Google Cloud.

Per ridurre la complessità della migrazione, ti consigliamo di concentrarti sui casi d'uso emersi dalla valutazione del tuo ambiente di origine. Ad esempio, se importi dati da dispositivi periferici ma non utilizzi le funzionalità di gestione dei dispositivi IoT Core, ti consigliamo di concentrarti sulla progettazione dell'ambiente di destinazione. Questo approccio ti consente di supportare solo il caso d'uso dell'importazione dati, senza considerare il caso d'uso della gestione dei dispositivi.

La progettazione dell'ambiente di destinazione può variare a seconda dei casi d'uso Cloud IoT Core implementati nell'ambiente di origine e delle modalità con cui vuoi implementarli nell'ambiente di destinazione. È necessario considerare i seguenti fattori:

  • Se hai implementato entrambi i casi d'uso nell'ambiente di origine, puoi progettare l'ambiente di destinazione per implementare entrambi i casi d'uso con una singola soluzione. Puoi anche implementare i due casi d'uso separatamente utilizzando soluzioni distinte.
  • Se implementi solo uno dei due casi d'uso nell'ambiente di origine, puoi progettare l'ambiente di destinazione per implementare quel caso d'uso con un'unica soluzione.

Il seguente diagramma mostra una serie di domande di esempio da considerare quando decidi come progettare l'architettura dell'ambiente di destinazione.

Domande di esempio, indicate nel testo seguente.

Il diagramma precedente può essere sintetizzato in questo modo:

  • Hai bisogno di importare i dati dai dispositivi periferici e gestire i dispositivi periferici?

    • Se sì, passa alla domanda successiva.
    • Se la risposta è no, passa alle domande per casi d'uso di gestione dei dispositivi perimetrali.

  • Hai bisogno di un'unica soluzione per implementare i casi d'uso di importazione dati e gestione dei dispositivi perimetrali?

    • Se sì, esegui il deployment di una soluzione sia per l'importazione dati che per la gestione dei dispositivi periferici su Google Cloud.
    • In caso contrario, esegui il deployment di una soluzione di gestione dei dispositivi periferici su Google Cloud e passa alle domande per la valutazione del caso d'uso dell'importazione dati.

  • Hai bisogno di gestire i dispositivi periferici?

    • Se sì, esegui il deployment di una soluzione di gestione dei dispositivi periferici su Google Cloud e passa alle domande per la valutazione del caso d'uso dell'importazione dati.
    • In caso negativo, continua con le domande per la valutazione del caso d'uso dell'importazione dati.

  • Hai bisogno di importare dati provenienti da dispositivi periferici?

    • Se sì, vai alla domanda successiva.
    • In caso contrario, hai completato la migrazione o non è necessario eseguire la migrazione dell'ambiente di origine. In entrambi i casi, puoi rimuovere l'ambiente di origine.

  • Qual è il protocollo di comunicazione preferito?

    • Se MQTT, esegui il deployment di un intermediario MQTT su Google Cloud.
    • Se HTTP o gRPC, importa i dati provenienti da dispositivi periferici utilizzando Pub/Sub.
    • Altrimenti, valuta le soluzioni di importazione dati compatibili con i tuoi protocolli di comunicazione preferiti.

Quando progetti l'architettura dell'ambiente di destinazione, considera quanto segue:

  • La gestione di qualsiasi componente dell'architettura richiede conoscenza e impegno. Consigliamo di valutare quante risorse aggiuntive devi tenere conto per l'ambiente di destinazione.
  • Il provisioning di molti dispositivi periferici pone sfide di sicurezza, scalabilità e operative. Per saperne di più sul provisioning dei dispositivi periferici, consulta la pagina Best practice per il provisioning e la configurazione automatici di sistemi e server perimetrali e bare metal.
  • L'uso di Pub/Sub per importare i dati dai tuoi dispositivi periferici ti consente di non dover gestire e scalare una piattaforma di messaggistica distribuita. Se utilizzi Pub/Sub per importare dati provenienti dai tuoi dispositivi periferici, prendi in considerazione sia le quote e i limiti di Pub/Sub, soprattutto se devi importare dati da molti dispositivi.

  • Per autenticare i tuoi dispositivi periferici nell'ambiente di destinazione e gestire le loro identità, ti consigliamo di valutare i metodi di autenticazione e le credenziali di archiviazione supportati dall'ambiente di destinazione. Confrontale con quelle che utilizzi con IoT Core nell'ambiente di origine.

    Dopo aver raccolto queste informazioni, ti consigliamo di seguire le istruzioni della Guida alla sicurezza dei backend IoT per progettare e implementare un meccanismo di autenticazione e gestione delle identità per i tuoi dispositivi periferici.

Scegli prima i dispositivi periferici e i carichi di lavoro di backend di cui eseguire la migrazione

Dopo aver progettato l'architettura dell'ambiente di destinazione, definisci quanto segue:

  1. Categorie di dispositivi periferici e carichi di lavoro di backend di cui eseguire la migrazione prima.
  2. I gruppi di migrazione (i gruppi di elementi di cui eseguire la migrazione dall'ambiente di origine all'ambiente di destinazione).

Definisci prima le categorie di dispositivi periferici di cui eseguire la migrazione

Le categorie di dispositivi periferici e i carichi di lavoro di backend potrebbero offrire sfide diverse e difficoltà di migrazione. Un esempio potrebbe essere la migrazione dei dispositivi periferici solo per la trasmissione, che potrebbero essere più semplici rispetto alla migrazione dei dispositivi periferici di ricezione e di trasmissione.

Per capire meglio come scegliere le categorie di dispositivi periferici e i carichi di lavoro di backend di cui eseguire la migrazione prima di eseguire la migrazione, vedi Scegliere prima le app di cui eseguire la migrazione.

Questa sezione riepiloga le considerazioni da fare per ogni categoria di dispositivi periferici al momento di decidere quale sarà la prima migrazione.

Dispositivi periferici solo per la trasmissione

Questi dispositivi periferici inviano eventi e informazioni di telemetria sullo stato del dispositivo utilizzando MQTT o HTTP.

Se i dispositivi utilizzano MQTT, potrebbe essere necessario aggiornare la loro configurazione solo per connettersi all'intermediario MQTT e autenticarsi nell'ambiente di destinazione. Puoi continuare a pubblicare eventi di telemetria e informazioni sullo stato del dispositivo tramite il mediatore MQTT nell'ambiente di destinazione. In alcuni casi, potresti non avere un broker MQTT nel tuo ambiente di destinazione e dover eseguire la migrazione a un tipo di ambiente di destinazione diverso, ad esempio una soluzione di terze parti. In questo caso, devi valutare le funzionalità e le interfacce di integrazione fornite dalla soluzione. Puoi quindi progettare e implementare un piano di migrazione appropriato.

Se i dispositivi utilizzano HTTP, potrebbe essere necessario aggiornare la loro configurazione per connettersi e autenticarsi in base all'ambiente di destinazione. Potrebbe anche essere necessario ridefinire la semantica di come i dispositivi comunicano per tenere conto delle differenze nell'ambiente di destinazione rispetto all'utilizzo delle API IoT Core. Ad esempio, se utilizzi Pub/Sub nell'ambiente di destinazione, potresti eseguire la migrazione dall'uso delle API IoT Core per pubblicare messaggi in argomenti Pub/Sub e utilizzare API Pub/Sub per lo stesso scopo. In alcuni casi, potresti non utilizzare Pub/Sub nel tuo ambiente di destinazione e, di conseguenza, devi eseguire la migrazione a un tipo di ambiente di destinazione diverso, ad esempio una soluzione di terze parti. In questo caso, devi valutare le funzionalità e le interfacce di integrazione fornite dalla soluzione di terze parti per progettare e implementare un piano di migrazione appropriato.

Dispositivi periferici con sola ricezione

Questi dispositivi periferici ricevono i comandi tramite MQTT e gli aggiornamenti della configurazione utilizzando MQTT o HTTP. IoT Core non supporta l'utilizzo di HTTP per inviare comandi.

Se i dispositivi ricevono comandi e aggiornamenti della configurazione utilizzando MQTT, vengono prese in considerazione considerazioni simili a quelle della categoria di dispositivi perimetrali precedente. Per eseguire la migrazione di questa categoria di dispositivi periferici, aggiorna la configurazione dei dispositivi periferici a cui connetterti e autenticarli nel database MQTT nel tuo ambiente di destinazione. Puoi continuare a iscriverti ad argomenti MQTT in cui IoT Core pubblica comandi e aggiornamenti della configurazione del dispositivo. In alcuni casi, potresti non avere un intermediario MQTT nel tuo ambiente di destinazione e dover eseguire la migrazione a un tipo di ambiente di destinazione diverso, ad esempio una soluzione di terze parti. In questo caso, devi valutare le funzionalità e le interfacce di integrazione fornite dalla soluzione per progettare e implementare un piano di migrazione appropriato.

Se i dispositivi ricevono aggiornamenti della configurazione tramite HTTP, vengono prese in considerazione considerazioni simili a quelle della categoria di dispositivi periferici precedente. Per eseguire la migrazione di questa categoria di dispositivi periferici, potrebbe essere necessario aggiornare la configurazione per connettersi e autenticarsi nell'ambiente di destinazione. Per ricevere gli aggiornamenti della configurazione, potrebbe anche essere necessario ridefinire la semantica della comunicazione per tenere conto delle differenze nell'ambiente di destinazione rispetto all'uso delle API IoT Core. Ad esempio, se stai eseguendo la migrazione a un tipo di ambiente di destinazione diverso, ad esempio una soluzione di terze parti, devi valutare le funzionalità e le interfacce di integrazione fornite dalla soluzione per progettare e implementare un piano di migrazione appropriato.

Ricevi e trasmetti dispositivi periferici

Questi dispositivi periferici potrebbero essere più difficili da migrare perché sono sia consumatori di dati provenienti da carichi di lavoro di backend sia produttori di dati ricevuti dai dispositivi periferici. In questo caso, le considerazioni per eseguire la migrazione delle categorie di dispositivi periferici di cui sopra si applicano entrambe, pertanto è necessario prestare particolare attenzione per la migrazione di questa categoria di carico di lavoro di backend.

Dopo aver scelto le categorie di dispositivi periferici di cui eseguire la migrazione, scegli prima le categorie di carichi di lavoro di cui eseguire la migrazione.

Carichi di lavoro di backend di sola ricezione

Questi carichi di lavoro di backend sono disaccoppiati da dispositivi periferici che producono eventi di telemetria o informazioni sullo stato dei dispositivi, quindi per i seguenti motivi può essere relativamente semplice eseguire la migrazione:

  • I carichi di lavoro di backend si iscrivono agli argomenti Pub/Sub. Per questo motivo, i dispositivi non devono conoscere i produttori di tali informazioni per consumarle. Potrebbe non essere necessario aggiornare la configurazione del software in esecuzione sui tuoi dispositivi periferici.
  • I carichi di lavoro di backend non inviano comandi o aggiornamenti della configurazione dei dispositivi ai dispositivi periferici. Pertanto, non è necessario tenere conto di questo caso d'uso durante la migrazione di questi carichi di lavoro di backend.
  • Puoi conservare gli argomenti Pub/Sub esistenti per pubblicare o utilizzare messaggi. In tal caso, i carichi di lavoro di backend possono rimanere associati agli argomenti Pub/Sub esistenti se l'ambiente di destinazione continua a inoltrare eventi di telemetria e informazioni sullo stato del dispositivo a tali argomenti.

Carichi di lavoro di backend di sola invio

Questi carichi di lavoro di backend richiedono una valutazione completa per comprendere come interagiscono con i dispositivi periferici quando inviano comandi e aggiornamenti della configurazione dei dispositivi e come eseguirne la migrazione nell'ambiente di destinazione. Ad esempio, se esegui la migrazione a un ambiente di destinazione con un intermediario MQTT, i carichi di lavoro di backend potrebbero migrare dall'utilizzo delle API IoT Core per inviare comandi o aggiornamenti della configurazione del dispositivo per pubblicare messaggi tramite MQTT. In alcuni casi, potrebbe non essere necessario eseguire un aggiornamento software o di configurazione sui dispositivi periferici. Ad esempio, se i carichi di lavoro di backend pubblicano comandi e aggiornamenti della configurazione nello stesso formato e negli stessi argomenti MQTT in cui IoT Core pubblica messaggi sui comandi e sugli aggiornamenti della configurazione del dispositivo nell'ambiente di origine. Se stai eseguendo la migrazione a un tipo di ambiente di destinazione diverso, ad esempio una soluzione di terze parti, devi valutare le funzionalità e le interfacce di integrazione fornite dalla soluzione per progettare e implementare un piano di migrazione appropriato.

Invia e ricevi carichi di lavoro di backend

Questi carichi di lavoro di backend potrebbero essere più difficili da migrare perché sono sia i consumatori di dati provenienti da dispositivi periferici sia i produttori di dati ricevuti dai dispositivi periferici. Le considerazioni per la migrazione delle categorie dei carichi di lavoro di backend discusse sopra si applicano entrambe in questo caso, quindi è necessario un particolare impegno nella gestione della migrazione di questa categoria di carico di lavoro di backend.

Definisci gruppi di migrazione

Per ridurre i rischi e la complessità della migrazione di un numero elevato di elementi in un singolo batch, gli elementi vengono suddivisi in ogni categoria in gruppi di migrazione. Per pianificare gruppi di migrazione, segui questi passaggi:

  1. Progettazione di gruppi di migrazione mediante raggruppamento di elementi omogenei: per raggruppare gli elementi di cui eseguire la migrazione in batch, è consigliabile scegliere un insieme di criteri in modo che gli elementi di un gruppo di migrazione condividano caratteristiche comuni. Ad esempio, puoi raggruppare i dispositivi periferici in batch secondo quanto segue:

    • La regione di deployment
    • Il registry IoT Core a cui sono registrati i dispositivi
    • Se è presente un insieme significativo di metadati del dispositivo IoT Core
    • Lo stato di deployment dei dispositivi

  2. Decidi le dimensioni di ogni gruppo di migrazione. Per ogni categoria di elementi di cui eseguire la migrazione, consigliamo di pianificare i primi gruppi di migrazione in quella categoria in modo relativamente piccolo. Puoi aumentare le dimensioni dei batch man mano che acquisisci esperienza e slancio durante la migrazione.

  3. Valuta se i tuoi gruppi di migrazione hanno bisogno di strategie ad hoc: a seconda del modo in cui hai raggruppato gli elementi di cui eseguire la migrazione in batch, la strategia di migrazione da applicare a un determinato batch di migrazione può dipendere dalle caratteristiche degli elementi di quel gruppo. Ad esempio, per eseguire la migrazione dei dispositivi periferici raggruppati per stato di deployment, devi fare le seguenti considerazioni:

    • Se i dispositivi non sono ancora stati realizzati o sono in fase di produzione, puoi chiedere al produttore di aggiornare la configurazione e il software per eseguirne la migrazione nell'ambiente di destinazione.
    • Se i dispositivi sono pronti per il deployment, ma non sono ancora registrati in IoT Core, puoi indicare al deployer di richiamare questi dispositivi periferici. Puoi quindi aggiornare la configurazione e il software per eseguirne la migrazione nell'ambiente di destinazione.
    • Se è già stato eseguito il deployment dei dispositivi nel sito di destinazione e la registrazione in IoT Core è possibile aggiornarne la configurazione e il software per eseguirne la migrazione nell'ambiente di destinazione, da remoto o in loco.

Pianifica e getta le basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura e dei servizi cloud che supportano i tuoi carichi di lavoro su Google Cloud come segue:

  1. Creare una gerarchia di risorse.
  2. Configurare Identity and Access Management.
  3. Configura la fatturazione.
  4. Configura la connettività di rete.
  5. Aumenta la sicurezza.
  6. Configurare il monitoraggio e gli avvisi.

Per istruzioni su come creare l'infrastruttura cloud e i servizi che supportano i carichi di lavoro e le loro dipendenze, consulta Migrazione a Google Cloud: creazione delle basi. Segui queste linee guida per creare una base per i tuoi ambienti. Puoi quindi continuare con le attività descritte nelle sezioni successive di questo documento.

Eseguire la migrazione dei dispositivi periferici e dei carichi di lavoro di backend

Dopo aver creato gli elementi di base per l'ambiente di destinazione, devi eseguire le operazioni seguenti per eseguire la migrazione dei dispositivi periferici e dei carichi di lavoro di backend nell'ambiente di destinazione.

  1. Esegui il provisioning e configura le risorse per implementare l'architettura dell'ambiente di destinazione: come primo passo del processo di migrazione, crea e configura l'infrastruttura della nuova piattaforma.
  2. Esegui la migrazione dei dispositivi periferici e dei carichi di lavoro di backend nell'ambiente di destinazione: dopo aver verificato che l'ambiente di destinazione sia pronto, esegui la migrazione dei carichi di lavoro e dei dispositivi periferici all'ambiente di destinazione. A seconda dell'architettura dell'ambiente di destinazione e dei casi d'uso, potrebbero essere disponibili approcci diversi per la migrazione. Questo documento illustra una strategia di migrazione in due passaggi che consente la coesistenza del tuo ambiente di origine e di destinazione per un determinato periodo di tempo. Questo approccio significa che se si verificano errori durante la migrazione, puoi eseguire il rollback all'ambiente di origine.
  3. Ritira l'ambiente di origine: dopo aver verificato che l'ambiente di destinazione sia completamente operativo, disattiva l'ambiente di origine.

Esegui il provisioning e la configurazione delle risorse per l'architettura dell'ambiente di destinazione

In questa fase, esegui il provisioning e la configurazione dell'ambiente di destinazione. Come descritto in Progettare l'architettura dell'ambiente di destinazione, l'architettura dell'ambiente di destinazione può essere sintetizzata in questo modo:

  • Un intermediario MQTT in esecuzione su Google Cloud: esegui un intermediario MQTT su Google Cloud e inoltri eventi di telemetria e informazioni sullo stato del dispositivo dal intermediario MQTT ai carichi di lavoro di backend. I carichi di lavoro di backend pubblicano comandi e controlli nell'argomento MQTT.
  • Pub/Sub: i tuoi dispositivi periferici pubblicano eventi di telemetria e informazioni sullo stato del dispositivo in Pub/Sub e ricevono comandi da Pub/Sub.
  • Una piattaforma di terze parti per l'importazione e la gestione dei dati: configuri una soluzione di terze parti per gli eventi di telemetria e le informazioni sull'importazione dello stato dei dispositivi e sulla gestione dei dispositivi.

Per ulteriori informazioni su ciascuna architettura, consulta le architetture di dispositivi connessi su Google Cloud.

Esegui la migrazione dei dispositivi periferici e dei carichi di lavoro di backend nell'ambiente di destinazione

Dopo aver eseguito il provisioning e la configurazione delle risorse nell'ambiente di destinazione, esegui la migrazione dei dispositivi periferici e dei carichi di lavoro di backend nell'ambiente di destinazione. In questa sezione, esegui la migrazione di dispositivi periferici e carichi di lavoro di backend dall'ambiente di origine all'ambiente di destinazione. L'ambiente di origine e di destinazione coesistono fino alla disabilitazione dell'ambiente di origine.

Per ridurre i tempi di inattività, il processo di migrazione prevede le seguenti fasi:

  1. Monitoraggio degli ambienti di origine e di destinazione.
  2. Migrazione delle informazioni sui metadati del dispositivo perimetrali dall'ambiente di origine all'ambiente di destinazione. Sono incluse le credenziali e la configurazione e lo stato del dispositivo.
  3. Aggiornamento dei dispositivi periferici in modo che si connettano all'ambiente di origine e di destinazione.
  4. Migrazione dei carichi di lavoro di backend dall'ambiente di origine all'ambiente di destinazione.
  5. Aggiornamento dei dispositivi periferici in modo che si connettano solo all'ambiente di origine.

Ti consigliamo di monitorare sia l'ambiente di origine sia l'ambiente di destinazione durante ogni fase della migrazione e di verificare i risultati di ogni fase prima di passare alla fase successiva.

Oltre a monitorare l'ambiente, potrebbe essere opportuno introdurre i test della blackbox per verificare se l'ambiente funziona come previsto. Un esempio di questo test potrebbe essere un caso d'uso in cui il carico di lavoro di backend invia una notifica via email agli operatori quando rileva un evento specifico, ad esempio una temperatura superiore a 50 gradi Celsius. Puoi creare uno scenario di test con dati di telemetria per una temperatura superiore a 50 gradi centigradi e verificare se il carico di lavoro di backend invia un'email agli operatori.

Monitora gli ambienti di origine e di destinazione

Per monitorare gli ambienti di origine e di destinazione, ti consigliamo di valutare le seguenti metriche:

  • Conteggio dispositivi attivi: il numero di dispositivi che di recente hanno inviato dati a IoT Core.
  • Numero di errori di comunicazione dei dispositivi:il numero di errori riscontrati dai carichi di lavoro di backend durante la comunicazione con i dispositivi periferici, raggruppati per tipo di errore, in un determinato periodo. Questa metrica è utile per capire se i carichi di lavoro di backend hanno problemi di comunicazione con i dispositivi periferici.
  • Numero di operazioni del dispositivo: il numero di operazioni eseguite dai dispositivi periferici, ad esempio richieste di connessione o disconnessione, pubblicazione dei messaggi, raggruppate per tipo di operazione, in un determinato periodo. Questa metrica ti aiuta a capire se i dispositivi periferici sono in esecuzione come previsto. Ad esempio, se sia il valore di Numero di errori del dispositivo sia il numero di operazioni del dispositivo stanno aumentando, l'ambiente potrebbe riscontrare problemi nell'invio di messaggi ai dispositivi periferici.
  • Numero di byte ricevuti: il numero di byte ricevuti dai dispositivi periferici in un determinato periodo. Questa metrica consente di valutare le statistiche sul traffico in entrata della rete.
  • Numero di byte inviati: conteggio delta del numero di byte inviati ai dispositivi periferici. Questa metrica ti consente di valutare le statistiche relative al traffico in uscita dalla rete.
  • Velocità effettiva del messaggio: il numero di messaggi che i carichi di lavoro di backend hanno elaborato in un determinato periodo. Questa metrica consente di capire se l'ambiente scala in base al volume di traffico tra i dispositivi periferici e i carichi di lavoro di backend. Ad esempio, se sia il numero dei dispositivi attivi sia il numero delle operazioni sui dispositivi aumentano, ma la velocità effettiva del messaggio non cambia troppo, ti consigliamo di verificare se i carichi di lavoro di backend hanno risorse sufficienti per gestire l'aumento dei messaggi.
  • Latenza di consegna dei messaggi:il tempo trascorso dopo che un dispositivo periferico ha pubblicato un messaggio e prima che un carico di lavoro di backend lo riceva per l'elaborazione. Ad esempio, se il valore di latenza aumenta, potresti verificare se ci sono problemi che rallentano la consegna del messaggio.
  • Messaggi non recapitabili: il numero di messaggi che non possono essere recapitati a dispositivi periferici e ai carichi di lavoro di backend. Il mancato recapito dei messaggi ai consumatori potrebbe indicare che i dispositivi periferici o i carichi di lavoro di backend potrebbero non rispondere.
  • Utilizzo della quota di risorse per il cloud: monitora l'utilizzo della quota di risorse da cloud per garantire che l'ambiente disponga di risorse sufficienti per la scalabilità.
Monitora l'ambiente di origine

Cloud Monitoring raccoglie automaticamente le metriche da IoT Core e Pub/Sub. Ad esempio, IoT Core espone le metriche device/active_devices, device/error_count e device/operation_count. Questi dati ti aiutano a capire quanti dispositivi periferici sono connessi all'ambiente di origine e quanti di questi dispositivi stanno riscontrando errori durante la comunicazione con IoT Core. Le metriche device/received_bytes_count e device/sent_bytes_count ti consentono di monitorare il consumo della larghezza di banda della rete.

Per monitorare lo stato e l'integrità del recapito dei messaggi, utilizza il monitoraggio del linguaggio di query per misurare il punteggio di integrità della latenza di recapito per una sottoscrizione, velocità effettiva del messaggio e messaggi non recapitabili.

Monitorare l'ambiente di destinazione

Monitori l'ambiente di destinazione per capire se la migrazione è riuscita. A seconda dell'architettura dell'ambiente di destinazione, l'intermediario MQTT o la piattaforma IoT di terze parti potrebbero fornire le seguenti metriche:

Esegui la migrazione delle informazioni sui metadati del dispositivo periferico dall'ambiente di origine all'ambiente di destinazione

Per eseguire la migrazione alla nuova piattaforma IoT, devi eseguire la migrazione delle informazioni sui metadati dei dispositivi periferici all'ambiente di destinazione. Per eseguire la migrazione dei metadati dei dispositivi periferici, valuta le seguenti categorie di metadati:

  • Credenziali del dispositivo: IoT Core autentica i dispositivi periferici utilizzando una coppia di chiavi e token di breve durata. Segui i passaggi richiesti dall'ambiente di destinazione per registrare i dispositivi nell'ambiente di destinazione e creare credenziali dei dispositivi nell'ambiente di destinazione in base al suo meccanismo di autenticazione.

  • Configurazione del dispositivo:l'ambiente di destinazione potrebbe essere una piattaforma IoT di terze parti che fornisce il servizio di configurazione del dispositivo e il tuo caso d'uso richiede la configurazione dei dispositivi periferici con lo stato più recente desiderato. In questo caso, devi eseguire la migrazione della configurazione del dispositivo all'ambiente di destinazione. Durante la migrazione, assicurati che la configurazione del dispositivo sia sincronizzata tra l'ambiente di origine e quello di destinazione. Se il tuo ambiente di destinazione si basa su un intermediario MQTT o Pub/Sub e non fornisce un modo per gestire la configurazione dei dispositivi, potresti voler archiviare le configurazioni dei dispositivi nei bucket Cloud Storage come un archivio a lungo termine.

  • Informazioni sullo stato del dispositivo: assicurati che i dispositivi periferici aggiornino il loro stato quando si connettono all'ambiente di destinazione per la prima volta, in modo che l'ambiente di destinazione disponga delle informazioni più aggiornate sullo stato del dispositivo.

Dopo aver completato questo passaggio, verifica che le informazioni e le credenziali del dispositivo richieste siano configurate correttamente e che i dispositivi periferici possano connettersi e autenticarsi nell'ambiente di destinazione.

Aggiorna i dispositivi periferici per connetterti all'ambiente di origine e di destinazione

Quando raggiungi questa fase, il tuo ambiente di destinazione è pronto ad accettare connessioni da dispositivi periferici. Puoi aggiornare i dispositivi periferici per connetterli sia all'ambiente di origine sia all'ambiente di destinazione al fine di inviare eventi di telemetria e informazioni sullo stato del dispositivo. Quando aggiorni i dispositivi periferici, l'approccio da seguire dipende dalla categoria del dispositivo periferico.

Per i dispositivi periferici che inviano eventi di telemetria o informazioni sullo stato del dispositivo, ma non ricevono comandi o aggiornamenti della configurazione del dispositivo dai carichi di lavoro di backend, procedi come segue:

  1. Aggiornare i dispositivi periferici per fare in modo che inviino eventi di telemetria e informazioni sullo stato dei dispositivi sia all'ambiente di origine che all'ambiente di destinazione.
  2. Verifica che l'ambiente di destinazione riceva correttamente gli eventi di telemetria e le informazioni sullo stato del dispositivo.

Al contrario, per i dispositivi periferici che non inviano eventi di telemetria o informazioni sullo stato del dispositivo, ma ricevono comandi o aggiornamenti della configurazione da carichi di lavoro di backend, procedi come segue:

  1. Aggiorna i dispositivi periferici per ricevere comandi e aggiornamenti della configurazione dall'ambiente di destinazione.
  2. Assicurati che i dispositivi periferici segnalino il risultato dell'esecuzione dei comandi o degli aggiornamenti della configurazione all'ambiente di destinazione.
  3. Inviare un comando e un aggiornamento della configurazione dall'ambiente di destinazione ai dispositivi periferici.
  4. Verifica che l'esecuzione del comando e l'aggiornamento della configurazione siano riusciti.

Per i dispositivi periferici che inviano eventi di telemetria e informazioni sullo stato del dispositivo e ricevono anche comandi o aggiornamenti della configurazione dai carichi di lavoro di backend:

  1. Aggiornare i dispositivi periferici per fare in modo che inviino eventi di telemetria e informazioni sullo stato del dispositivo sia all'ambiente di origine che a quello di destinazione.
  2. Verifica che l'ambiente di destinazione riceva correttamente gli eventi di telemetria e le informazioni sullo stato del dispositivo.
  3. Aggiornare i codici dei dispositivi periferici per ricevere comandi e aggiornamenti della configurazione dall'ambiente di destinazione.
  4. Assicurati che i dispositivi periferici segnalino il risultato dell'esecuzione dei comandi o degli aggiornamenti della configurazione all'ambiente di destinazione.
  5. Inviare un comando e un aggiornamento della configurazione dall'ambiente di destinazione ai dispositivi periferici.
  6. Verifica che l'esecuzione del comando e l'aggiornamento della configurazione siano riusciti.

Dopo aver eseguito questi passaggi per il tuo caso d'uso, tutte le categorie di dispositivi perimetrali procedono come segue:

  • Connettiti sia all'ambiente di origine sia all'ambiente di destinazione.
  • Invia eventi di telemetria e informazioni sullo stato del dispositivo sia all'ambiente di origine che a quello di destinazione.
  • Ricevi comandi e aggiornamenti della configurazione dall'ambiente di origine solo perché non hai ancora eseguito la migrazione dei carichi di lavoro di backend.

È meglio evitare uno scenario in cui i carichi di lavoro di backend elaborino lo stesso messaggio che i dispositivi periferici inviano sia all'ambiente di origine sia all'ambiente di destinazione. Ti consigliamo di configurare il periodo di conservazione dei messaggi nell'ambiente di destinazione con il valore minimo possibile. Questo approccio ti consente di verificare che l'ambiente di destinazione funzioni come previsto. Ti consente anche di verificare che i messaggi nell'ambiente di destinazione scadano prima di eseguire la migrazione dei carichi di lavoro di backend. Puoi regolare la configurazione di conservazione dei messaggi nell'ambiente di destinazione dopo il passaggio successivo della migrazione.

Se i dispositivi periferici non possono connettersi contemporaneamente all'ambiente di origine e di destinazione per motivi tecnici o normativi, devi prima configurare il dispositivo per l'ambiente di origine dall'ambiente di origine. Puoi quindi connetterti solo all'ambiente di destinazione. In questo caso, i carichi di lavoro di backend ancora connessi all'ambiente di origine smettono di ricevere eventi di telemetria e informazioni sullo stato dei dispositivi dai dispositivi periferici. I dispositivi non possono più inviare comandi e aggiornamenti della configurazione ai dispositivi periferici.

Ti consigliamo inoltre di eseguire il provisioning e di configurare un meccanismo di archiviazione del buffer. Questo approccio ti consente di evitare di perdere dati quando il dispositivo invia eventi di telemetria e informazioni sullo stato del dispositivo all'ambiente di destinazione quando i carichi di lavoro di backend sono ancora connessi all'ambiente di origine. I carichi di lavoro di backend possono quindi utilizzare queste informazioni quando si connettono all'ambiente di destinazione. Ad esempio, puoi configurare la conservazione dei messaggi dell'ambiente di destinazione, sulla base di un intermediario MQTT, Pub/Sub o una piattaforma IoT. Questo approccio consente di conservare i messaggi non confermati disponibili per il tempo necessario al completamento della fase successiva della migrazione, come descritto nella sezione seguente.

Migrazione dei carichi di lavoro di backend dall'ambiente di origine all'ambiente di destinazione

Esegui la migrazione dei carichi di lavoro di backend all'ambiente di destinazione. A seconda dell'architettura dell'ambiente di destinazione, devi adottare approcci diversi per eseguire la migrazione del carico di lavoro.

Mediatore MQTT su Google Cloud: se il tuo ambiente di destinazione è basato su un broker MQTT, il tuo approccio alla migrazione è condotto dai seguenti fattori:

  • Per i carichi di lavoro di backend che ricevono eventi di telemetria o informazioni sullo stato dei dispositivi dai dispositivi periferici, ma non inviano comandi o aggiornamenti della configurazione del dispositivo. Configura i carichi di lavoro di backend in modo da sottoscrivere gli argomenti MQTT per ricevere eventi di telemetria e informazioni sullo stato dei dispositivi provenienti dai dispositivi periferici.
  • Al contrario, per i carichi di lavoro di backend che non ricevono eventi di telemetria o informazioni sullo stato del dispositivo, ma inviano gli aggiornamenti dei comandi o della configurazione del dispositivo: configura i carichi di lavoro di backend in modo che pubblichi messaggi per inviare comandi e aggiornamenti della configurazione agli argomenti MQTT per gli aggiornamenti dei comandi e della configurazione nell'ambiente di destinazione.
  • Per i carichi di lavoro di backend che ricevono eventi di telemetria o informazioni sullo stato del dispositivo dai dispositivi periferici e inviano comandi o aggiornamenti della configurazione del dispositivo: configura i carichi di lavoro di backend in modo che sottoscrivano gli argomenti MQTT per ricevere la telemetria, quindi configuri i carichi di lavoro di backend per pubblicare i messaggi e inviare comandi e aggiornamenti della configurazione agli argomenti MQTT.

Pub/Sub: se il tuo ambiente di destinazione è basato su Pub/Sub, i seguenti fattori guidano il tuo approccio alla migrazione:

  • Per i carichi di lavoro di backend che ricevano eventi di telemetria o informazioni sullo stato del dispositivo dai dispositivi periferici, ma non inviano comandi o aggiornamenti della configurazione del dispositivo: crea nuove sottoscrizioni Pub/Sub nell'ambiente di destinazione e aggiorna i carichi di lavoro di backend per utilizzare le nuove iscrizioni create.
  • Al contrario, per i carichi di lavoro di backend che non ricevono eventi di telemetria o informazioni sullo stato del dispositivo, ma inviano comandi o aggiornamenti della configurazione del dispositivo: crea argomenti Pub/Sub e configura i carichi di lavoro di backend per pubblicare messaggi in modo da inviare comandi e aggiornamenti della configurazione agli argomenti Pub/Sub.
  • Per carichi di lavoro di backend che ricevono eventi di telemetria o informazioni sullo stato del dispositivo dai dispositivi periferici e inviano comandi o aggiornamenti della configurazione del dispositivo: configura i carichi di lavoro di backend in modo da sottoscrivere gli argomenti Pub/Sub per ricevere eventi di telemetria e informazioni sullo stato del dispositivo. Quindi, configura i carichi di lavoro di backend per pubblicare messaggi in modo da inviare comandi e configurare aggiornamenti agli argomenti Pub/Sub.

Piattaforma IoT di terze parti: se il tuo ambiente di destinazione è basato su una piattaforma IoT di terze parti, devi seguire le istruzioni della piattaforma IoT di terze parti per configurare le integrazioni tra i carichi di lavoro di backend e la piattaforma IoT. Quindi, verifichi che i carichi di lavoro di backend siano in grado di ricevere eventi di telemetria e informazioni sullo stato dei dispositivi provenienti da dispositivi periferici. Inoltre, controlli che i carichi di lavoro di backend possano pubblicare messaggi per inviare comandi o aggiornamenti della configurazione del dispositivo al dispositivo periferico.

Per verificare che i dispositivi periferici e i carichi di lavoro di backend funzionino come previsto, ti consigliamo di:

  • Verifica che i carichi di lavoro di backend ricevano eventi di telemetria e informazioni sullo stato del dispositivo e reagiscano correttamente. Ad esempio, se i carichi di lavoro di backend generano una dashboard quasi in tempo reale per monitorare dati specifici di telemetria, verifica che la dashboard sia aggiornata con il periodo di dati più recente.
  • Verifica che i carichi di lavoro di backend inviino comandi e aggiornamenti della configurazione ai dispositivi periferici come previsto. Verifica anche che i dispositivi periferici reagiscano come previsto.
  • Verifica se il dispositivo periferico segnala eventi di telemetria e informazioni sullo stato del dispositivo all'ambiente di destinazione.

A questo punto, i carichi di lavoro di backend si comportano come segue:

  • Connettiti all'ambiente di destinazione.
  • Ricevi eventi di telemetria e informazioni sullo stato dei dispositivi perimetrali dall'ambiente di destinazione.
  • Invia comandi e aggiornamenti della configurazione ai dispositivi periferici dall'ambiente di destinazione.

Ora puoi aggiornare la configurazione della conservazione dei messaggi dell'ambiente di destinazione impostata su un valore minimo quando connetti i dispositivi periferici all'ambiente di origine e di destinazione e impostarli in base ai tuoi requisiti.

Quando aggiorni la configurazione dei carichi di lavoro di backend per ricevere eventi di telemetria e informazioni sullo stato del dispositivo dall'ambiente di destinazione, i carichi di lavoro di backend potrebbero richiedere tempo per applicare questa configurazione aggiornata. Durante la fase di transitoria, i carichi di lavoro di backend non possono consumare eventi di telemetria e informazioni sullo stato dei dispositivi inviati dai dispositivi periferici. Se i tuoi casi d'uso richiedono l'integrità completa dei dati, potresti dover configurare il periodo di conservazione dei messaggi dell'ambiente di destinazione prima di aggiornare la configurazione dei carichi di lavoro di backend. Questo approccio garantisce che i messaggi non scadano prima che i carichi di lavoro di backend possano applicare la nuova configurazione e consumare i messaggi.

Aggiorna i dispositivi periferici per connettersi solo all'ambiente di destinazione

A questo punto, hai eseguito correttamente la migrazione dei tuoi dispositivi periferici all'ambiente di destinazione; tuttavia, questi utilizzano ancora l'ambiente di origine. Per completare il passaggio di migrazione, aggiorna i dispositivi periferici in modo che si connettano all'ambiente di destinazione solo rimuovendo le connessioni e l'integrazione con IoT Core. Una volta completato l'aggiornamento, i dispositivi periferici si connettono solo all'ambiente di destinazione.

Scollega l'ambiente di origine

Dopo aver eseguito la migrazione dei dispositivi periferici e dei carichi di lavoro di backend nell'ambiente di destinazione e aver convalidato l'ambiente di destinazione, rimuovi l'ambiente di origine.

Per disattivare l'ambiente di origine, segui questi passaggi:

  1. Elimina le sottoscrizioni Pub/Sub che si iscrivono agli argomenti IoT Core.
  2. Elimina gli argomenti Pub/Sub inutilizzati. Se riutilizzi gli argomenti Pub/Sub, assicurati di non eliminare gli argomenti creati da IoT Core. Puoi trovare gli argomenti Pub/Sub utilizzati da IoT Core utilizzando la console IoT Core.
  3. Elimina i dispositivi e i registri IoT Core.

Ottimizza il tuo ambiente dopo la migrazione

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, rendi il tuo ambiente più efficiente di prima. In questa fase, esegui più iterazioni di un loop ripetibile finché il tuo ambiente non soddisfa i requisiti di ottimizzazione. La procedura di questo loop ripetibile è la seguente:

  1. Valutare il tuo ambiente attuale, i tuoi team e il ciclo di ottimizzazione.
  2. Definizione dei requisiti e degli obiettivi di ottimizzazione.
  3. Ottimizzazione dell'ambiente e dei tuoi team.
  4. Ottimizzare il ciclo di ottimizzazione.

Le seguenti sezioni si basano su Migrazione a Google Cloud: ottimizzazione dell'ambiente.

Valuta il tuo ambiente di destinazione, i tuoi team e il ciclo di ottimizzazione

Mentre la prima valutazione che effettui si concentra sull'ambiente di origine, questa fase di valutazione riguarda la fase di ottimizzazione. Per ulteriori informazioni su come valutare l'ambiente di destinazione, i team e il ciclo di ottimizzazione, consulta Misurare l'ambiente, i team e il ciclo di ottimizzazione.

Stabilisci i tuoi requisiti di ottimizzazione

Esamina i seguenti requisiti di ottimizzazione che potresti dover effettuare per il tuo ambiente di destinazione:

  • Configura la scalabilità automatica: utilizza i servizi Google Cloud come gruppo di istanze gestite o Google Kubernetes Engine per scalare automaticamente in orizzontale o in verticale la tua soluzione IoT e i carichi di lavoro di backend quando i carichi aumentano. Questo approccio contribuisce a garantire che la registrazione dei dispositivi e l'archiviazione dei dati di telemetria possano gestire un volume di dati maggiore quando esegui il deployment di un parco risorse di dispositivi di grandi dimensioni. Dato che Cloud Spanner è un database transazionale distribuito, ad alta disponibilità e scalabile, è un buon candidato per archiviare i dati di telemetria e le informazioni di registrazione dei dispositivi.
  • Migliora il meccanismo di logging e monitoraggio: ottimizza e integra il tuo meccanismo di logging e monitoraggio per formare una soluzione centralizzata. Potresti anche voler migliorare determinate metriche di monitoraggio per capire in che modo i dispositivi perimetrali interagiscono con la soluzione IoT. Dovresti anche registrare e collegare attività come eventi di connessione, eventi di disconnessione ed eventi di telemetria. Consigliamo inoltre di monitorare gli errori di sistema e delle applicazioni. Se possibile, configura un avviso quando si verificano determinati errori critici a livello di sistema.
  • Proteggi i tuoi carichi di lavoro utilizzando i servizi per la sicurezza di Google Cloud: Security Command Center è un servizio centralizzato per la segnalazione di vulnerabilità e minacce che puoi utilizzare per rafforzare la tua strategia di sicurezza valutando la tua superficie di attacco per dati e sicurezza. Fornisce inventario e rilevamento degli asset e può aiutarti a identificare configurazioni errate, vulnerabilità e minacce. Security Command Center ti aiuta anche a mitigare e correggere i rischi. Per informazioni su come proteggere i carichi di lavoro in esecuzione su Google Kubernetes Engine (GKE), consulta la panoramica della sicurezza di Google Kubernetes Engine per informazioni su come proteggere i carichi di lavoro di GKE.

Completa l'ottimizzazione

Dopo aver completato l'elenco dei requisiti di ottimizzazione, devi completare la fase di ottimizzazione. Per scoprire come fare, consulta Migrazione a Google Cloud: ottimizzazione dell'ambiente.

Passaggi successivi