Umgebungen von IoT Core migrieren

Last reviewed 2023-02-01 UTC

Google hat die Einstellung von IoT Core angekündigt. Dieses Dokument soll Ihnen beim Entwerfen und Implementieren eines Migrationsplans von einer IoT Core-basierten Umgebung in eine neue Umgebung helfen, die für Folgendes nicht von IoT Core abhängt:

  • Authentifizierung mit Edge-Geräten
  • Edge-Geräteverwaltung
  • Kommunikation zwischen Ihren Edge-Geräten und Google Cloud

Das Dokument bietet auch eine Anleitung, wenn Sie die Möglichkeit zur Migration nach der Einstellung von IoT Core bewerten und erfahren möchten, wie eine Migration aussehen könnte.

Dieses Dokument ist Teil einer Reihe von Dokumenten, die Informationen zu IoT-Architekturen in Google Cloud und zur Migration von IoT Core enthalten. Die anderen Dokumente in dieser Reihe umfassen die folgenden Punkte:

Die zu migrierende Arbeitslast

In diesem Dokument wird davon ausgegangen, dass die Arbeitslasten, die Sie von IoT Core migrieren möchten, die folgenden Teile haben:

  • Ein Teil, das auf Edge-Geräten ausgeführt wird (bereitgestellt an den Edges Ihrer Umgebung und neben den Daten, die Sie verarbeiten möchten)
  • Ein Backend, das in Google Cloud ausgeführt wird

Das folgende Diagramm zeigt die Architektur einer typischen Arbeitslast, die IoT Core verwendet. In dieser Architektur bindet Cloud IoT Edge-Geräte mit einem Backend ein, das in Google Cloud ausgeführt wird.

Ereignisfluss von Edge-Geräten zu Cloud IoT (im folgenden Text zusammengefasst).

Das obige Diagramm kann so zusammengefasst werden:

Für eine effektive Planung der Migration empfehlen wir Ihnen, eine Bewertung durchzuführen, um ein vollständiges Verständnis Ihrer Architektur der Quellumgebung zu erhalten. In diesem Fall bezieht sich Quellumgebung auf Ihre aktuelle IoT Core-basierte Umgebung.

In diesem Dokument wird davon ausgegangen, dass Sie die Konfiguration und die Softwarekomponenten, die auf Ihren Edge-Geräten ausgeführt werden, für Ihre Migration aktualisieren können. In einigen Fällen ist dieser Ansatz möglicherweise nicht durchführbar. Zum Beispiel könnten Ihre Edge-Geräte oder Ihre Bereitstellungsprozesse diesen Anwendungsfall möglicherweise nicht unterstützen. In diesem Fall empfehlen wir, die Edge-Geräte zu deaktivieren, die keine Updates unterstützen. Weitere Informationen zum Entwerfen und Implementieren automatisierter Bereitstellungs- und Konfigurationsprozesse für Edge-Geräte finden Sie unter Best Practices für die automatische Bereitstellung und Konfiguration von Edge- und Bare-Metal-Systemen und -Servern.

Migration entwerfen

Zum Migrieren Ihrer IoT Core-basierten Umgebung empfehlen wir die Ausführung des unter Migration zu Google Cloud beschriebenen Migrations-Frameworks.

Die folgende Grafik beschreibt den Migrationsprozess:

Migrationspfad mit vier Phasen

Wie im vorherigen Diagramm dargestellt, besteht dieser Prozess aus vier Phasen:

  1. Bewerten: In dieser Phase bewerten Sie die Quellumgebung sowie die Arbeitslasten und Edge-Geräte, die Sie von Cloud IoT Core migrieren möchten.
  2. Planen: In dieser Phase erstellen Sie die grundlegende Infrastruktur in Google Cloud, z. B. durch das Bereitstellen der Ressourcenhierarchie und das Einrichten des Netzwerkzugriffs.
  3. Bereitstellen: In dieser Phase stellen Sie die neue Lösung bereit, die anstelle von IoT Core verwendet werden soll, und migrieren Ihre Edge-Geräte zur neuen Lösung.
  4. Optimieren: In dieser Phase optimieren Sie Ihre Zielumgebung. In diesem Fall bezieht sich Zielumgebung auf die Umgebung, zu der Sie migrieren, die nicht auf IoT Core basiert.

Quellumgebung und Arbeitslasten bewerten

In der Bewertungsphase erfassen Sie Informationen über Ihre Quellumgebung, die Edge-Geräte und die Verwendung von IoT Core in Ihrer Organisation. Diese Informationen helfen Ihnen, einen Migrationsplan zu entwerfen und sicherzustellen, dass Sie die Ressourcen haben, die Sie für die Migration und für Ihre Zielumgebung benötigen.

In der Bewertungsphase gehen Sie so vor:

  1. Erstellen Sie ein Inventar der Edge-Geräte, die Sie in Cloud IoT Core registriert haben.
  2. Erstellen Sie ein Inventar der Backend-Arbeitslasten, die in Cloud IoT Core eingebunden sind.
  3. Edge-Geräte und Backend-Arbeitslasten kategorisieren
  4. Experimentieren und Proofs of Concept erstellen
  5. Gesamtbetriebskosten berechnen
  6. Entwerfen Sie die Architektur der Zielumgebung
  7. Wählen Sie aus, welche Edge-Geräte und Backend-Arbeitslasten zuerst migriert werden sollen

Am Ende der Bewertungsphase haben Sie zwei Inventare: ein Inventar für die Edge-Geräte und ein Inventar für die Backend-Arbeitslasten.

Damit Inkonsistenzen vermieden werden, empfehlen wir Ihnen, die Bereitstellung neuer Edge-Geräte und Backend-Arbeitslasten zu pausieren, bevor Sie dieses Inventar erstellen. Wir empfehlen außerdem, keine neuen Edge-Geräte und Hintergrundarbeitslasten bereitzustellen, nachdem Sie das Inventar erstellt haben.

Inventar Ihrer Edge-Geräte erstellen

Um Ihre Migration zu skalieren und den Migrationsplan zu entwerfen, müssen Sie wissen, wie viele Edge-Geräte in Ihrer Quellumgebung vorhanden sind. Sie müssen außerdem wissen, wie die Geräte mit IoT Core interagieren und ob sie nach allgemeinen Merkmalen, Verhalten, Zweck oder Abhängigkeiten kategorisiert werden können.

Jedes Edge-Gerät, das Sie bei IoT Core registrieren, gehört zu einer IoT Core-Registry. Der erste Schritt zum Erstellen des Inventars Ihrer Edge-Geräte besteht darin, die von Ihnen erstellten IoT Core-Registries aufzulisten. Anschließend erfassen Sie Informationen zu den in jeder Registry registrierten Edge-Geräten.

Wenn Sie das Inventar Ihrer Edge-Geräte erstellen, sollten Sie die folgenden Informationen für jedes Edge-Gerät und die Einbindung des Geräts in IoT Core berücksichtigen:

  • Kennungen: Erfassen Sie die folgenden Informationen zu den IoT Core-Kennungen des Edge-Geräts:

    • Die benutzerdefinierte Kennung
    • Die vom Server definierte, nicht bearbeitbare ID, die von IoT Core automatisch generiert wird, wenn Sie ein Edge-Gerät bei IoT Core registrieren.
    • Der Ressourcenname, der das Edge-Gerät mithilfe der ID der IoT Core-Registry, in der Sie das Edge-Gerät registriert haben, eindeutig identifiziert

  • Bereitstellungsstatus: Bewerten Sie den aktuellen Bereitstellungsstatus des Edge-Geräts. Das Edge-Gerät kann beispielsweise einen der folgenden Status haben:

    • Noch nicht hergestellt oder wird derzeit hergestellt
    • Bereit für die Bereitstellung, aber noch nicht für IoT Core registriert
    • Bereits an seinem Zielort bereitgestellt und in IoT Core registriert

  • IoT Core-Gerätetyp: Prüfen Sie den IoT Core-Gerätetyp. Jedes Edge-Gerät, das Sie bei IoT Core registrieren, kann auf zwei Arten fungieren. Es kann ein Client sein, der sich direkt mit IoT Core verbindet. Es kann auch ein Gateway für die Clients sein, die Sie nicht direkt mit IoT Core verbinden können oder möchten.

  • Kommunikationsprotokoll: IoT Core unterstützt zwei Protokolle für die Kommunikation mit Edge-Geräten: HTTP und MQTT. Prüfen Sie, welches Protokoll Ihre Edge-Geräte für die Kommunikation mit IoT Core verwenden. Für das MQTT-Protokoll müssen Sie auch die Dienstqualität ermitteln, auf die sich Ihre Edge-Geräte und Backend-Arbeitslasten verlassen.

  • Anmeldedaten: IoT Core authentifiziert Edge-Geräte mithilfe eines Schlüsselpaars und kurzlebiger Tokens, die mit diesem Schlüsselpaar generiert wurden. Optional kann es die Signatur des öffentlichen Teils des Schlüsselpaars mit einer zertifikatbasierten Verifizierungsmethode verifizieren. Prüfen Sie, wie die Authentifizierung des Edge-Geräts konfiguriert ist. Prüfen Sie, ob Sie den zertifikatbasierten Bestätigungsmechanismus für die IoT Core-Registry verwenden, zu der das Gerät gehört.

  • Gerätemetadaten: In IoT Core können Sie für jedes Edge-Gerät Metadaten in Form von Schlüssel/Wert-Paaren definieren. Sie können beispielsweise einen Hardwarefingerabdruck, eine Seriennummer, Herstellerinformationen oder ein anderes für einen Edge-Gerät relevantes Attribut definieren. Sie können Metadaten definieren, wenn Sie ein Edge-Gerät einer IoT Core-Registry hinzufügen oder ein Edge-Gerät bearbeiten, das sich bereits in einer Registry befindet. Metadaten werden niemals über IoT Core an oder von einem Edge-Gerät gesendet. Sammeln Sie Informationen zu den Metadaten, die Sie für das Edge-Gerät definiert haben.

  • Gerätestatus: In IoT Core kann jedes Edge-Gerät Informationen zum Status als beliebige strukturierte oder unstrukturierte Daten melden. Ein Edge-Gerät kann beispielsweise die Version der Firmware melden, die es ausführt. Oder es kann Informationen zu seinem Zustand nach bestimmten Messwerten melden. IoT Core veröffentlicht die empfangenen Informationen zum Gerätestatus als Nachrichten in einem von Ihnen konfigurierten Pub/Sub-Thema. Prüfen Sie, wie Ihr Edge-Gerät Informationen zu seinem Status meldet und an welche Pub/Sub-Themen IoT Core diese Nachrichten veröffentlicht. Bestimmen Sie, welche Komponenten Ihrer Architektur auf Informationen zum Edge-Gerätestatus basieren.

  • Telemetrieereignisse: Jedes Edge-Gerät, das Sie einer IoT Core-Registry hinzufügen, kann Telemetrieereignisse als beliebige strukturierte oder unstrukturierte Daten an IoT Core senden. IoT Core veröffentlicht die empfangenen Telemetrieereignisse als Nachrichten in einem von Ihnen konfigurierten Pub/Sub-Thema. Prüfen Sie, wie Ihr Edge-Gerät Telemetrieereignisse meldet und in welchen Pub/Sub-Themen IoT Core diese Nachrichten veröffentlicht. Bestimmen Sie, welche Komponenten Ihrer Architektur auf Telemetrieereignissen basieren, die vom Edge-Gerät gemeldet werden.

  • Gerätekonfiguration: In IoT Core können Sie die Konfiguration eines Edge-Geräts als beliebige strukturierte oder unstrukturierte Daten definieren. Mit IoT Core können Sie auch Aktualisierungen der Konfiguration eines Geräts als neue Versionen einer solchen Konfiguration definieren, die dann an das Edge-Gerät übertragen werden. Prüfen Sie, ob das Edge-Gerät die Konfiguration von Cloud IoT Core empfängt, und erfassen Sie Informationen zu allen von Ihnen definierten Konfigurationsversionen.

  • Befehle: In IoT Core können Edge-Geräte Befehle von IoT Core empfangen und dann auf diese Befehle reagieren. Prüfen Sie, ob Ihre Edge-Geräte die Reaktion auf Befehle von IoT Core unterstützen.

  • Software- und Konfigurationsupdates: Während der Migration müssen Sie möglicherweise die Softwarekomponenten, die auf dem Edge-Gerät ausgeführt werden, oder die Konfiguration dieser Komponenten, aktualisieren. Prüfen Sie die Aktualisierungsmechanismen, die Ihr Edge-Gerät unterstützt. Prüfen Sie, ob das Gerät auch einen Rollback-Mechanismus unterstützt, um ihn in einen bekannten Arbeitszustand zurückzusetzen, wenn bei solchen Aktualisierungen Fehler und Probleme auftreten.

  • Ausfallzeit: Während der Migration sind Backend-Arbeitslasten oder andere Teile der Quellumgebung möglicherweise nicht verfügbar. Prüfen Sie, ob Ihr Edge-Gerät Ausfallzeiten unterstützt, welche Fallback-Mechanismen es gibt und wie es nach der Ausfallzeit wiederhergestellt wird.

Inventar Ihrer Backend-Arbeitslasten erstellen, die in IoT Core integriert werden können

Nachdem Sie das Inventar Ihrer Edge-Geräte erstellt haben, erfassen Sie Informationen zu den Backend-Arbeitslasten in Ihrer Quellumgebung, die in Cloud IoT Core eingebunden sind. Eine Backend-Arbeitslast kann so in IoT Core eingebunden werden:

  • Durch Senden von Befehlen an Edge-Geräte und Aktualisieren der Konfiguration Ihrer Edge-Geräte mit IoT Core
  • Durch Abonnieren von Pub/Sub-Themen, an die IoT Core Nachrichten zu Edge-Gerätetelemetrieereignissen und Gerätestatus veröffentlicht
  • Durch Einbindung in IoT Core APIs direkt oder mithilfe eines Infrastrukturbereitstellungstools Beispielsweise können Sie mit Terraform IoT Core-Registries und -Geräte bereitstellen.

Wenn Sie das Inventar der Backend-Arbeitslasten erstellen, die in Cloud IoT Core eingebunden sind, berücksichtigen Sie für jede Backend-Arbeitslast Folgendes:

  • Befehle und Gerätekonfiguration: Prüfen Sie, ob die Backend-Arbeitslast Befehle an Edge-Geräte sendet und ob die Gerätekonfiguration aktualisiert wird. Beide Aktionen erfordern eine Integration in IoT Core APIs.
  • Telemetrieereignisse und Gerätestatus: Prüfen Sie, ob die Backend-Arbeitslast die Pub/Sub-Themen abonniert, in denen IoT Core Nachrichten zu Telemetrieereignissen und Gerätestatus veröffentlicht.

  • Einbindung in andere IoT Core APIs: Prüfen Sie, ob die Backend-Arbeitslast mit anderen IoT Core APIs interagiert, außer denen zum Senden von Befehlen und Aktualisieren von Gerätekonfigurationen. Beispielsweise kann Ihre Backend-Arbeitslast auf IoT Core APIs zurückgreifen, um Folgendes zu tun:

    • IoT Core-Registries erstellen und ihre Konfiguration aktualisieren.
    • IoT Core-Geräte erstellen und ihre Konfiguration aktualisieren.
    • Informationen zu IoT Core-Registries und -Geräten erfassen.
    • IoT Core-Logging-Messwerte und Logs zu Geräteaktivitäten verwenden.

Edge-Geräte und Backend-Arbeitslasten kategorisieren

Nachdem Sie das Inventar Ihrer Edge-Geräte und Ihrer Backend-Arbeitslast erstellt haben, kategorisieren Sie die Elemente in jedem Inventar anhand ihrer Eigenschaften. Mithilfe dieser Kategorisierung können Sie Ihren Migrationsplan entwerfen und auswählen, welche Edge-Geräte und Backend-Arbeitslasten zuerst migriert werden sollen.

Um Ihre Edge-Geräte zu kategorisieren, empfehlen wir eine Kategorisierung nach den Arten von Interaktionen, die zwischen Edge-Geräten und Backend-Arbeitslasten auftreten können. Berücksichtigen Sie folgende Arten von Interaktionen:

  • Wenn ein Edge-Gerät Daten mit Telemetrieereignissen oder Informationen zum Gerätestatus an Backend-Arbeitslasten sendet.
  • Wenn Backend-Arbeitslasten Anweisungen mit Befehlen oder Gerätekonfigurationsupdates an Edge-Geräte senden.

Für jede der vorherigen Arten der Interaktion unterscheiden sich die Nachrichtentypen, die während der Interaktionen dieser Art ausgetauscht werden. Die Nachrichten haben jedoch ähnliche Zwecke. Einige Geräte senden Daten von einem Edge-Gerät an Backend-Arbeitslasten, z. B. Telemetrieereignisse und Informationen zum Gerätestatus. Einige Geräte senden Anweisungen von Backend-Arbeitslasten an Edge-Geräte wie Befehle und Aktualisierungen der Gerätekonfiguration.

Basierend auf den vorgeschlagenen Arten von Interaktionen empfehlen wir die folgenden Kategorien für Ihre Edge-Geräte:

  • Nur Übertragung: Edge-Geräte, die Telemetrieereignisse oder Informationen zum Gerätestatus senden, aber keine Befehle oder Updates der Gerätekonfiguration von Backend-Arbeitslasten erhalten.
  • Nur Empfang: Edge-Geräte, die keine Telemetrieereignisse oder Informationen zum Gerätestatus senden, aber Befehle oder Gerätekonfigurationsupdates von Backend-Arbeitslasten empfangen.
  • Empfangen und übertragen: Edge-Geräte, die Telemetrieereignisse und Informationen zum Gerätestatus senden und Befehle oder Aktualisierungen der Gerätekonfiguration von Backend-Arbeitslasten empfangen.

Zum Kategorisieren Ihrer Backend-Arbeitslasten können Sie ähnlich vorgehen wie bei der Kategorisierung von Edge-Geräten. Basierend auf den vorgeschlagenen Arten von Interaktionen empfehlen wir die folgenden Kategorien für Ihre Backend-Arbeitslasten:

  • Nur Empfang: Backend-Arbeitslasten, die Telemetrieereignisse oder Informationen zum Gerätestatus von Edge-Geräten empfangen, aber keine Befehle oder Gerätekonfigurationsupdates senden.
  • Nur Senden: Backend-Arbeitslasten, die keine Telemetrieereignisse oder Informationen zum Gerätestatus empfangen, aber Befehle oder Aktualisierungen der Gerätekonfiguration senden.
  • Senden und empfangen: Backend-Arbeitslasten, die Telemetrieereignisse oder Informationen zum Gerätestatus von Edge-Geräten empfangen und Befehle oder Gerätekonfigurations-Updates senden.

Bewertung abschließen

Nachdem Sie das Inventar erstellt haben, müssen Sie die folgenden Teile der Bewertungsphase abschließen:

Nachdem Sie diese Aktivitäten abgeschlossen haben, lesen Sie dieses Dokument weiter.

Architektur der Zielumgebung entwerfen

Nachdem Sie die vorherigen Bewertungsaktivitäten abgeschlossen haben, entwerfen Sie die Architektur für die Zielumgebung.

In diesem Dokument geht es um die Migration der Quellumgebung zur Zielumgebung. Die Migration Ihrer Umgebung von IoT Core bietet jedoch auch die Möglichkeit, neue Features und Updates zu planen. Berücksichtigen Sie beim Entwerfen der Architektur der Zielumgebung alle Einschränkungen, die in der Quellumgebung auftreten können. Überlegen Sie sich, wie Sie die Zielumgebung konfigurieren möchten, um diese Einschränkungen zu vermeiden. Sie können auch potenzielle neue Features berücksichtigen, die Sie in der Zielumgebung benötigen.

Je nachdem, wie Sie Ihre Edge-Geräte und Backend-Arbeitslasten kategorisiert haben, werden möglicherweise folgende ergänzende IoT Core-Anwendungsfälle angezeigt, die aus der Bewertung der Quellumgebung stammen:

  • Aufnahme von Daten von Edge-Geräten in ein Backend, das in Google Cloud ausgeführt wird.
  • Backend-Arbeitslasten der Edge-Geräteverwaltung in Google Cloud ausführen.

Damit die Migration weniger komplex ist, sollten Sie sich auf die Anwendungsfälle konzentrieren, die sich aus der Bewertung der Quellumgebung ergeben haben. Wenn Sie beispielsweise Daten von Edge-Geräten aufnehmen, aber keine IoT Core-Geräteverwaltungsfunktionen verwenden, empfehlen wir Ihnen, sich auf das Entwerfen der Zielumgebung zu konzentrieren. Mit diesem Ansatz können Sie nur den Anwendungsfall der Datenaufnahme unterstützen, ohne den Anwendungsfall der Geräteverwaltung berücksichtigen zu müssen.

Das Design der Zielumgebung kann variieren, je nachdem, welche dieser Cloud IoT Core-Anwendungsfälle Sie in der Quellumgebung implementiert haben und wie Sie sie in der Zielumgebung implementieren möchten. Sie müssen die folgenden Faktoren berücksichtigen:

  • Wenn Sie beide Anwendungsfälle in der Quellumgebung implementiert haben, können Sie die Zielumgebung so entwerfen, dass beide Anwendungsfälle mit einer einzigen Lösung implementiert werden. Sie können die beiden Anwendungsfälle auch separat mit unterschiedlichen Lösungen implementieren.
  • Wenn Sie nur einen der beiden Anwendungsfälle in der Quellumgebung implementieren, können Sie die Zielumgebung so entwerfen, dass dieser Anwendungsfall mit einer einzigen Lösung implementiert wird.

Das folgende Diagramm zeigt eine Reihe von Beispielfragen, die Sie bei der Entscheidung beachten sollten, wie Sie die Architektur der Zielumgebung entwerfen.

Beispielfragen, die im folgenden Text angegeben werden.

Das obige Diagramm kann so zusammengefasst werden:

  • Müssen Sie sowohl Daten von Edge-Geräten aufnehmen als auch Edge-Geräte verwalten?

    • Falls ja, fahren Sie mit der nächsten Frage fort.
    • Falls nein, fahren Sie mit den Fragen zum Anwendungsfall der Edge-Geräteverwaltung fort.

  • Benötigen Sie eine einzige Lösung, um Anwendungsfälle für die Datenaufnahme und Edge-Geräteverwaltung zu implementieren?

    • Falls ja, stellen Sie eine Lösung sowohl für die Datenaufnahme als auch für die Edge-Geräteverwaltung in Google Cloud bereit.
    • Falls nicht, stellen Sie eine Edge-Geräteverwaltungslösung in Google Cloud bereit und fahren Sie dann mit den Fragen zur Bewertung der Datenaufnahme fort.

  • Müssen Sie Edge-Geräte verwalten?

    • Falls ja, stellen Sie eine Edge-Geräteverwaltungslösung in Google Cloud bereit und fahren Sie dann mit den Fragen zur Bewertung der Datenaufnahme fort.
    • Falls nicht, fahren Sie mit den Fragen zur Bewertung der Datenaufnahme fort.

  • Müssen Daten von Edge-Geräten aufgenommen werden?

    • Falls ja, fahren Sie mit der nächsten Frage fort.
    • Falls nein, haben Sie entweder die Migration abgeschlossen oder Sie müssen Ihre Quellumgebung nicht migrieren. In beiden Fällen können Sie die Quellumgebung außer Betrieb nehmen.

  • Was ist das bevorzugte Kommunikationsprotokoll?

    • Stellen Sie in MQTT einen MQTT-Broker in Google Cloud bereit.
    • Bei HTTP oder gRPC werden Daten, die von Edge-Geräten stammen, mit Pub/Sub aufgenommen.
    • Andernfalls bewerten Sie Datenaufnahmelösungen, die mit Ihren bevorzugten Kommunikationsprotokollen kompatibel sind.

Berücksichtigen Sie beim Entwerfen der Architektur der Zielumgebung Folgendes:

  • Die Verwaltung einer beliebigen Komponente der Architektur erfordert Wissen und Mühe. Wir empfehlen Ihnen, zu bewerten, wie viele zusätzliche Ressourcen Sie für die Zielumgebung benötigen.
  • Die Bereitstellung vieler Edge-Geräte erfordert besondere Aufmerksamkeit in puncto Sicherheit, Skalierbarkeit und Funktion. Weitere Informationen zum Bereitstellen von Edge-Geräten finden Sie unter Best Practices für die automatische Bereitstellung und Konfiguration von Edge- und Bare-Metal-Systemen und -Servern.
  • Wenn Sie Pub/Sub zur Aufnahme von Daten von Ihren Edge-Geräten verwenden, müssen Sie keine verteilte Messaging-Plattform verwalten und skalieren. Wenn Sie Pub/Sub verwenden, um Daten von Ihren Edge-Geräten aufzunehmen, berücksichtigen Sie sowohl Pub/Sub-Kontingente und -Limits, insbesondere wenn Sie Daten von vielen Geräten aufnehmen müssen.

  • Zur Authentifizierung Ihrer Edge-Geräte in der Zielumgebung und zur Verwaltung ihrer Identitäten sollten Sie prüfen, welche Authentifizierungsmethoden und Anmeldedaten die Zielumgebung unterstützen. Vergleichen Sie sie mit denen, die Sie mit IoT Core in der Quellumgebung verwenden.

    Nachdem Sie diese Informationen erfasst haben, folgen Sie der Anleitung im IoT-Backend-Sicherheitsleitfaden, um einen Authentifizierungs- und Identitätsverwaltungsmechanismus für Ihre Edge-Geräte zu entwickeln und zu implementieren.

Auswählen, welche Edge-Geräte und Backend-Arbeitslasten zuerst migriert werden sollen

Nachdem Sie die Architektur der Zielumgebung entworfen haben, definieren Sie Folgendes:

  1. Die Kategorien der Edge-Geräte und Backend-Arbeitslasten, die zuerst migriert werden sollen.
  2. Die Migration umfasst die Gruppen der Elemente, die von der Quellumgebung zur Zielumgebung migriert werden sollen.

Kategorien der Edge-Geräte definieren, die zuerst migriert werden sollen

Die Kategorien der Edge-Geräte und Backend-Arbeitslasten können unterschiedliche Herausforderungen und Schwierigkeiten bei der Migration bieten. Ein Beispiel wäre die Migration von reinen Edge-Geräten, die einfacher sein kann als die Migration von Edge-Geräten für den Empfang und die Übertragung.

Weitere Informationen zur Auswahl der Kategorien von Edge-Geräten und Backend-Arbeitslasten, die zuerst migriert werden sollen, finden Sie unter Anwendungen auswählen, die zuerst migriert werden sollen.

In diesem Abschnitt werden die Überlegungen zusammengefasst, die Sie für jede Edge-Gerätekategorie treffen müssen, wenn Sie entscheiden, welche Migration zuerst migriert werden soll.

Edge-Geräte nur für die Übertragung

Diese Edge-Geräte senden Telemetrieereignisse und Informationen zum Gerätestatus entweder mit MQTT oder HTTP.

Wenn die Geräte MQTT verwenden, müssen Sie möglicherweise ihre Konfiguration nur aktualisieren, um eine Verbindung zum MQTT-Broker in Ihrer Zielumgebung herzustellen und sich bei diesem zu authentifizieren. Sie können Telemetrieereignisse und Informationen zum Gerätestatus über den MQTT-Broker in der Zielumgebung veröffentlichen. In einigen Fällen haben Sie möglicherweise keinen MQTT-Broker in Ihrer Zielumgebung und müssen zu einer anderen Art von Zielumgebung migrieren, z. B. zu einer Drittanbieterlösung. In diesem Fall müssen Sie die Funktionen und die von der Lösung bereitgestellten Integrationsschnittstellen bewerten. Sie können dann einen geeigneten Migrationsplan erstellen und implementieren.

Wenn die Geräte HTTP verwenden, müssen Sie möglicherweise ihre Konfiguration aktualisieren, um eine Verbindung zur Zielumgebung herzustellen und sich bei dieser zu authentifizieren. Möglicherweise müssen Sie auch die Semantik der Geräte refaktorieren, um den Unterschieden in der Zielumgebung zu entsprechen, im Vergleich zur Verwendung von IoT Core APIs. Wenn Sie beispielsweise Pub/Sub in der Zielumgebung verwenden, können Sie von der Verwendung von IoT Core APIs zum Veröffentlichen von Nachrichten in Pub/Sub-Themen zu Pub/Sub APIs für denselben Zweck migrieren. In einigen Fällen verwenden Sie Pub/Sub möglicherweise nicht in Ihrer Zielumgebung und müssen daher in eine andere Art von Zielumgebung migrieren, z. B. in eine Lösung eines Drittanbieters. In diesem Fall müssen Sie die Funktionen und Integrationsschnittstellen bewerten, die die Drittanbieterlösung bietet, um einen geeigneten Migrationsplan zu entwerfen und zu implementieren.

Edge-Geräte nur für den Empfang

Diese Edge-Geräte erhalten Befehle über MQTT und Konfigurationsupdates entweder mit MQTT oder HTTP. IoT Core unterstützt die Verwendung von HTTP zum Senden von Befehlen nicht.

Wenn die Geräte Befehle und Konfigurationsupdates mit MQTT erhalten, gelten ähnliche Überlegungen wie die vorherige Edge-Gerätekategorie. Wenn Sie diese Kategorie von Edge-Geräten migrieren möchten, aktualisieren Sie die Konfiguration der Edge-Geräte, um eine Verbindung zum MQTT-Broker in Ihrer Zielumgebung herzustellen und sich bei diesem zu authentifizieren. Sie abonnieren weiterhin MQTT-Themen, auf denen IoT Core Befehle und Aktualisierungen der Gerätekonfiguration veröffentlicht. In einigen Fällen haben Sie möglicherweise keinen MQTT-Broker in Ihrer Zielumgebung und müssen zu einer anderen Art von Zielumgebung migrieren, z. B. zu einer Drittanbieterlösung. In diesem Fall müssen Sie die Funktionen und die Integrationsschnittstellen bewerten, die die Lösung bietet, um einen geeigneten Migrationsplan zu entwerfen und zu implementieren.

Wenn die Geräte Konfigurationsupdates über HTTP erhalten, gelten ähnliche Überlegungen wie bei der vorherigen Edge-Gerätekategorie. Wenn Sie diese Kategorie von Edge-Geräten migrieren möchten, müssen Sie möglicherweise deren Konfiguration aktualisieren, um eine Verbindung zur Zielumgebung herzustellen und sich bei dieser zu authentifizieren. Damit Sie Konfigurationsupdates erhalten, müssen Sie möglicherweise die Semantik der Kommunikation refaktorieren, um die Unterschiede in Ihrer Zielumgebung zu berücksichtigen, im Vergleich zur Verwendung von IoT Core APIs. Wenn Sie beispielsweise zu einer anderen Zielumgebung migrieren, z. B. zu einer Drittanbieterlösung, müssen Sie die Funktionen und die Integrationsschnittstellen bewerten, die die Lösung für das Design und die einen geeigneten Migrationsplan implementieren.

Edge-Geräte für den Empfang und die Übertragung

Diese Edge-Geräte sind möglicherweise am schwierigsten zu migrieren, da sie sowohl Nutzer von Daten, die von Backend-Arbeitslasten stammen, als auch Ersteller von Daten, die Edge-Geräte erhalten, sind. Die oben erläuterten Kategorien der Migration der Kategorien von Edge-Geräten gelten in diesem Fall besonders. Sie müssen also besonders auf die Migration dieser Backend-Arbeitslastkategorie achten.

Nachdem Sie sich entschieden haben, welche Kategorien von Edge-Geräten zuerst migriert werden sollen, müssen Sie festlegen, welche Kategorien von Backend-Arbeitslasten zuerst migriert werden.

Backend-Arbeitslasten nur für den Empfang

Diese Backend-Arbeitslasten sind von Edge-Geräten entkoppelt, die Telemetrieereignisse oder Informationen zum Gerätestatus erzeugen. Daher können sie aus den folgenden Gründen relativ einfach migriert werden:

  • Backend-Arbeitslasten abonnieren Pub/Sub-Themen. Aus diesem Grund benötigen die Geräte nicht die Ersteller dieser Informationen, um sie zu nutzen. Möglicherweise müssen Sie die Konfiguration oder die Software, die auf Ihren Edge-Geräten ausgeführt wird, nicht aktualisieren.
  • Backend-Arbeitslasten senden keine Befehle oder Gerätekonfigurationsupdates an Edge-Geräte. Daher müssen Sie diesen Anwendungsfall während der Migration dieser Backend-Arbeitslasten nicht berücksichtigen.
  • Sie können die vorhandenen Pub/Sub-Themen beibehalten, um Nachrichten zu veröffentlichen oder zu verarbeiten. In einem solchen Fall können Ihre Backend-Arbeitslasten die vorhandenen Pub/Sub-Themen abonnieren, wenn Ihre Zielumgebung weiterhin Telemetrieereignisse und Informationen zum Gerätestatus an diese Pub/Sub-Themen weiterleitet.

Backend-Arbeitslasten nur für das Senden

Diese Backend-Arbeitslasten erfordern eine umfassende Bewertung, um zu verstehen, wie sie beim Senden von Befehlen und Gerätekonfigurationsupdates mit Edge-Geräten interagieren und wie sie in die Zielumgebung migriert werden. Wenn Sie beispielsweise in eine Zielumgebung mit einem MQTT-Broker migrieren, können diese Backend-Arbeitslasten von IoT Core APIs migriert werden, um Befehle oder Aktualisierungen der Gerätekonfiguration zu senden, damit Nachrichten über MQTT veröffentlicht werden. Möglicherweise müssen Sie in einigen Fällen keine Software- oder Konfigurationsupdates auf Ihren Edge-Geräten ausführen. Beispiel: Wenn Backend-Arbeitslasten Befehle und Konfigurationsupdates im selben Format und in denselben MQTT-Themen veröffentlichen, in denen IoT Core Nachrichten zu Befehlen und Gerätekonfigurationsupdates in Ihrer Quellumgebung veröffentlicht. Wenn Sie zu einer anderen Zielumgebung migrieren, z. B. zu einer Drittanbieterlösung, müssen Sie die Funktionen und die Integrationsschnittstellen bewerten, die die Lösung bietet, um einen geeigneten Migrationsplan zu entwerfen und zu implementieren.

Backend-Arbeitslasten für das Senden und den Empfang

Diese Backend-Arbeitslasten sind möglicherweise am schwierigsten zu migrieren, da sie sowohl Nutzer von Daten aus Edge-Geräten als auch Datenersteller sind, die von Edge-Geräten empfangen werden. Die oben erläuterten Kategorien für die Migration der Kategorien von Backend-Arbeitslasten gelten in diesem Fall. Deshalb müssen Sie bei der Migration dieser Backend-Arbeitslastkategorie besonders sorgfältig vorgehen.

Migrationsbatches definieren

Um die Risiken und die Komplexität der Migration einer großen Anzahl von Elementen in einem einzelnen Batch zu reduzieren, teilen Sie die zu migrierenden Elemente in jede Kategorie in Migrationsbatches auf. So planen Sie Migrationsbatches:

  1. Migrationsbatches erstellen, indem Sie homogene Elemente gruppieren: Um die zu migrierenden Elemente in Batches zu gruppieren, empfehlen wir, dass Sie eine Reihe von Kriterien auswählen, damit die Elemente in einem Migrationsbatch gemeinsame Merkmale aufweisen. Sie können beispielsweise Edge-Geräte so in Batches gruppieren:

    • Die Bereitstellungsregion
    • Die IoT Core-Registry, in der die Geräte registriert sind
    • Wenn ein aussagekräftiger IoT Core-Gerätemetadatensatz vorhanden ist
    • Der Bereitstellungsstatus der Geräte

  2. Legen Sie die Größe jedes Migrationsbatches fest: Für jede Kategorie von zu migrierenden Elementen empfehlen wir, die ersten Migrationsbatches in dieser Kategorie relativ klein zu planen. Sie erhöhen die Batches, wenn Sie während der Migration an Erfahrung und Momentum gewinnen.

  3. Prüfen, ob Ihre Migrations-Batches Ad-hoc-Strategien erfordern: Je nachdem, wie Sie die zu migrierenden Elemente in Migrationsbatches gruppieren, hängt die Migrationsstrategie für einen bestimmten Migrationsbatch möglicherweise an den Eigenschaften der Elemente in diesem Batch. Wenn Sie beispielsweise Edge-Geräte nach Bereitstellungsstatus migrieren möchten, müssen Sie die folgenden Überlegungen beachten:

    • Wenn Ihre Geräte noch nicht hergestellt wurden oder derzeit hergestellt werden, können Sie den Hersteller anweisen, seine Konfiguration und die Software zu aktualisieren, damit sie in die Zielumgebung migriert werden.
    • Wenn Ihre Geräte für die Bereitstellung bereit sind, aber noch nicht für IoT Core registriert sind, können Sie den Bereitsteller anweisen, diese Edge-Geräte zurückzurufen. Anschließend können Sie deren Konfiguration und die Software aktualisieren, um sie in die Zielumgebung zu migrieren.
    • Wenn Ihre Geräte bereits an ihrem Zielstandort bereitgestellt und in IoT Core registriert sind, können Sie ihre Konfiguration und die Software aktualisieren, um sie entweder im Remotezugriff oder lokal zu migrieren.

Grundlage planen und aufbauen

In der Planungs- und Aufbauphase stellen Sie die Infrastruktur und die Dienste bereit, die Ihre Arbeitslasten in Google Cloud wie folgt unterstützen:

  1. Erstellen Sie eine Ressourcenhierarchie.
  2. Konfigurieren Sie Identity and Access Management.
  3. Richten Sie die Abrechnung ein.
  4. Richten Sie die Netzwerkverbindung ein.
  5. Erhöhen Sie die Sicherheit.
  6. Richten Sie Monitoring und Benachrichtigungen ein.

Informationen zum Erstellen der Cloud-Infrastruktur und der Dienste, die Ihre Arbeitslasten und deren Abhängigkeiten unterstützen, finden Sie unter Migration zu Google Cloud: Grundlage aufbauen. Befolgen Sie diese Richtlinien, um eine Grundlage für Ihre Umgebungen zu schaffen. Anschließend fahren Sie mit den Aktivitäten fort, die in den nächsten Abschnitten dieses Dokuments beschrieben werden.

Edge-Geräte und Backend-Arbeitslasten migrieren

Nachdem Sie die Grundlage für Ihre Zielumgebung geschaffen haben, müssen Sie Ihre Edge-Geräte und Backend-Arbeitslasten in die Zielumgebung migrieren.

  1. Stellen Sie Ressourcen bereit und konfigurieren Sie sie, um die Architektur der Zielumgebung zu implementieren: Im ersten Schritt des Migrationsprozesses erstellen und richten Sie die Infrastruktur der neuen Plattform ein.
  2. Edge-Geräte und Backend-Arbeitslasten in die Zielumgebung migrieren: Nachdem Sie überprüft haben, ob die Zielumgebung bereit ist, migrieren Sie die Backend-Arbeitslasten und Edge-Geräte in die Zielumgebung. Je nach Architektur Ihrer Zielumgebung und Ihren Anwendungsfällen kann es verschiedene Migrationsansätze geben. In diesem Dokument wird eine zweistufige Migrationsstrategie erläutert, mit der Ihre Quell- und Zielumgebung für einen bestimmten Zeitraum nebeneinander bestehen können. Bei diesem Ansatz können Sie bei Fehlern während der Migration ein Rollback zur Quellumgebung durchführen.
  3. Außerbetriebnahme der Quellumgebung: Nachdem Sie festgestellt haben, dass die Zielumgebung vollständig betriebsbereit ist, nehmen Sie die Quellumgebung außer Betrieb.

Ressourcen für die Architektur der Zielumgebung bereitstellen und konfigurieren

In dieser Phase wird die Zielumgebung bereitgestellt und konfiguriert. Wie unter Architektur der Zielumgebung entwerfen beschrieben, kann die Architektur der Zielumgebung so zusammengefasst werden:

  • Ein MQTT-Broker, der in Google Cloud ausgeführt wird: Sie führen einen MQTT-Broker in Google Cloud aus und leiten Telemetrieereignisse und Informationen zum Gerätestatus vom MQTT-Broker an Backend-Arbeitslasten weiter. Ihre Backend-Arbeitslasten veröffentlichen Befehle und Steuerelemente im MQTT-Thema.
  • Pub/Sub: Ihre Edge-Geräte veröffentlichen Telemetrieereignisse und Informationen zum Gerätestatus in Pub/Sub und empfangen Befehle von Pub/Sub.
  • Datenaufnahme- und Geräteverwaltungsplattform eines Drittanbieters: Sie richten eine Drittanbieterlösung für Telemetrieereignisse und Informationen zur Gerätestatusaufnahme und Geräteverwaltung ein.

Weitere Informationen zu den einzelnen Architekturen finden Sie unter Verbundene Gerätearchitekturen in Google Cloud.

Edge-Geräte und Backend-Arbeitslasten in die Zielumgebung migrieren

Nachdem Sie die Ressourcen in der Zielumgebung bereitgestellt und konfiguriert haben, migrieren Sie Edge-Geräte und Backend-Arbeitslasten zur Zielumgebung. In diesem Abschnitt migrieren Sie Edge-Geräte und Backend-Arbeitslasten von der Quellumgebung zur Zielumgebung. Die Quell- und Zielumgebung sind gleichzeitig vorhanden, bis Sie die Quellumgebung außer Betrieb nehmen.

Zur Minimierung von Ausfallzeiten besteht der Migrationsprozess aus folgenden Phasen:

  1. Quell- und Zielumgebungen überwachen.
  2. Informationen zu Edge-Gerätemetadaten aus der Quellumgebung in die Zielumgebung migrieren. Dazu gehören Geräteanmeldedaten, Gerätekonfiguration und Gerätestatus.
  3. Edge-Geräte aktualisieren, um eine Verbindung sowohl zur Quell- als auch zur Zielumgebung herzustellen.
  4. Backend-Arbeitslasten von der Quellumgebung in die Zielumgebung migrieren.
  5. Edge-Geräte aktualisieren, sodass nur eine Verbindung zur Quellumgebung hergestellt wird.

Wir empfehlen, in jeder Migrationsphase die Quell- und die Zielumgebung zu überwachen und die Ergebnisse jeder Phase zu prüfen, bevor Sie zur nächsten Phase übergehen.

Zusätzlich zum Monitoring der Umgebung können Sie Blackbox-Tests einführen, um zu prüfen, ob die Umgebung wie erwartet funktioniert. Ein Beispiel für einen solchen Test wäre ein Anwendungsfall, bei dem Ihre Backend-Arbeitslast eine E-Mail-Benachrichtigung an Operatoren sendet, wenn ein bestimmtes Ereignis erkannt wird, z. B. eine Temperatur von mehr als 50 °C. Sie können einen Testfall mit Telemetriedaten für eine Temperatur von mehr als 50 °C erstellen und testen, ob die Backend-Arbeitslast eine E-Mail an Operatoren sendet.

Quell- und Zielumgebungen überwachen

Für das Monitoring der Quell- und Zielumgebungen empfehlen wir die folgenden Messwerte:

  • Aktive Geräteanzahl: Die Anzahl der Geräte, die kürzlich Daten an IoT Core gesendet haben.
  • Anzahl der Gerätekommunikationsfehler: Die Anzahl der Fehler, die Backend-Arbeitslasten bei der Kommunikation mit Edge-Geräten in einem bestimmten Zeitraum aufgetreten sind, gruppiert nach Fehlertyp. Dieser Messwert ist hilfreich, um zu verstehen, ob Backend-Arbeitslasten Probleme mit der Kommunikation mit Edge-Geräten haben.
  • Anzahl der Gerätevorgänge: Anzahl der Vorgänge von Edge-Geräten, z. B. Anfragen zum Herstellen oder Trennen einer Verbindung, Nachrichtenveröffentlichung, gruppiert nach Vorgangstyp in einem bestimmten Zeitraum. Dieser Messwert hilft Ihnen zu verstehen, ob Edge-Geräte wie erwartet ausgeführt werden. Wenn beispielsweise die Anzahl der Gerätefehler und die Anzahl der Gerätevorgänge zunimmt, kann es sein, dass die Umgebung Probleme beim Senden von Nachrichten an die Edge-Geräte hat.
  • Anzahl der empfangenen Byte: Die Anzahl der Byte, die in einem bestimmten Zeitraum von Edge-Geräten empfangen wurden. Dieser Messwert hilft Ihnen, die Statistiken des eingehenden Netzwerktraffics zu verstehen.
  • Anzahl gesendeter Byte: Deltamenge der Anzahl von Byte, die an Edge-Geräte gesendet werden. Dieser Messwert hilft Ihnen, die Statistiken zum ausgehenden Netzwerktraffic zu analysieren.
  • Nachrichtendurchsatz: Die Anzahl der Nachrichten, die Backend-Arbeitslasten in einem bestimmten Zeitraum verarbeitet haben. Dieser Messwert hilft Ihnen zu verstehen, ob die Umgebung entsprechend dem Traffic zwischen Edge-Geräten und Backend-Arbeitslasten skaliert wird. Wenn beispielsweise die Anzahl der aktiven Geräte und die Anzahl der Gerätevorgänge steigt, sich der Nachrichtendurchsatz jedoch nicht zu stark ändert, sollten Sie prüfen, ob die Backend-Arbeitslasten genügend Ressourcen haben, um den Anstieg der Nachrichten zu bewältigen.
  • Latenz der Nachrichtenzustellung: Die Zeitspanne, die nach der Veröffentlichung einer Nachricht durch ein Edge-Gerät und vor der Verarbeitung einer Backend-Arbeitslast für die Verarbeitung verstrichen ist. Wenn beispielsweise der Latenzwert zunimmt, sollten Sie prüfen, ob es Probleme gibt, die die Nachrichtenzustellung verlangsamen.
  • Unzustellbare Nachrichten: Die Anzahl der Nachrichten, die nicht an Edge-Geräte und Backend-Arbeitslasten zugestellt werden können. Wenn Nachrichten nicht an Nutzer gesendet werden, reagieren die Edge-Geräte oder Backend-Arbeitslasten möglicherweise nicht.
  • Kontingentnutzung für Cloud-Ressourcen: Überwachen Sie die Nutzung von Cloud-Ressourcenkontingenten, damit die Umgebung über ausreichende Ressourcen für die Skalierung verfügt.
Die Quellumgebung überwachen

Cloud Monitoring erfasst automatisch Messwerte aus IoT Core und Pub/Sub. IoT Core stellt beispielsweise die Messwerte device/active_devices, device/error_count und device/operation_count bereit. Anhand dieser Daten können Sie nachvollziehen, wie viele Edge-Geräte mit der Quellumgebung verbunden sind und wie viele Edge-Geräte Fehler bei der Kommunikation mit IoT Core haben. Mit den Messwerten device/received_bytes_count und device/sent_bytes_count können Sie den Verbrauch der Netzwerkbandbreite überwachen.

Mithilfe von Monitoring Query Language können Sie den Status der Zustellungslatenz für ein Abo, den Nachrichtendurchsatz und nicht zustellbare Nachrichten messen.

Zielumgebung überwachen

Überwachen Sie die Zielumgebung, um festzustellen, ob die Migration erfolgreich war. Je nach Architektur der Zielumgebung kann der MQTT-Broker oder die IoT-Plattform eines Drittanbieters die folgenden Messwerte bereitstellen:

  • MQTT-Broker: Wenn die Zielumgebung auf einem MQTT-Broker basiert, stellt der Broker möglicherweise Messwerte zu Edge-Geräten und zur Nachrichtenzustellung bereit. Informationen zum Überwachen von gesendeten und empfangenen Byte finden Sie unter Von Cloud Load Balancing bereitgestellte Messwerte. Wenn der MQTT-Broker in einem GKE-Cluster ausgeführt wird, können Sie Cloud Monitoring konfigurieren, um festzulegen, welche Messwerte an Monitoring gesendet werden. Wenn der MQTT-Broker auf einer Compute Engine-Instanz ausgeführt wird, können Sie das Standard-Dashboard verwenden oder Ops Agent installieren, um detaillierte Telemetriedaten aus der Cloud Monitoring-Instanz zu erfassen.

  • Pub/Sub: Wenn die Zielumgebung auf Pub/Sub basiert, verwenden Sie Pub/Sub-Themen und -Abos. Sie können beispielsweise mit der Monitoring Query Language eine Abfrage ausführen, um die Integritätsbewertung für Zustellungen für ein Abo, den Nachrichtendurchsatz und nicht zustellbare Nachrichten abzurufen.

  • IoT-Plattform: Wenn die Zielumgebung auf einer IoT-Plattform basiert, kann die Plattform Informationen über Edge-Geräte und die Nachrichtenzustellung bereitstellen. Wenn die IoT-Plattform eines Drittanbieters in einem GKE-Cluster ausgeführt wird, können Sie Logging und Monitoring konfigurieren, um festzulegen, welche Messwerte an Cloud Monitoring gesendet werden. Wenn die IoT-Plattform eines Drittanbieters auf einer Cloud Monitoring-Instanz ausgeführt wird, können Sie das Standard-Dashboard verwenden oder Ops-Agent installieren, um detaillierte Telemetrie von der Cloud Monitoring-Instanz zu erfassen.

Metadateninformationen des Edge-Geräts aus der Quellumgebung in die Zielumgebung migrieren

Bei der Migration zur neuen IoT-Plattform migrieren Sie Edge-Gerätemetadateninformationen in die Zielumgebung. Ziehen Sie die folgenden Metadatenkategorien in Betracht, um die Edge-Gerätemetadaten zu migrieren:

  • Geräteanmeldedaten: IoT Core authentifiziert Edge-Geräte mit einem Schlüsselpaar und kurzlebigen Tokens. Führen Sie die erforderlichen Schritte in der Zielumgebung aus, um Geräte in der Zielumgebung zu registrieren und Geräteanmeldedaten in der Zielumgebung gemäß ihrem Authentifizierungsmechanismus zu erstellen.

  • Gerätekonfiguration: Möglicherweise ist Ihre Zielumgebung eine IoT-Plattform eines Drittanbieters, die einen Gerätekonfigurationsdienst bereitstellt. In Ihrem Anwendungsfall müssen Edge-Geräte mit dem neuesten gewünschten Status konfiguriert sein. In diesem Fall müssen Sie die Gerätekonfiguration in die Zielumgebung migrieren. Achten Sie darauf, dass die Gerätekonfiguration während der Migration zwischen der Quellumgebung und der Zielumgebung synchron ist. Wenn Ihre Zielumgebung auf einem MQTT-Broker oder Pub/Sub basiert und keine Möglichkeit zum Verwalten der Gerätekonfiguration bietet, sollten Sie die Gerätekonfigurationen als Langzeitarchiv in Cloud Storage-Buckets speichern.

  • Informationen zum Gerätestatus: Edge-Geräte müssen ihren Zustand aktualisieren, wenn sie zum ersten Mal eine Verbindung zur Zielumgebung herstellen. Dadurch hat die Zielumgebung immer die neuesten Informationen zum Gerätestatus.

Prüfen Sie nach Abschluss dieses Schritts, ob die erforderlichen Geräteinformationen und Anmeldedaten korrekt konfiguriert sind und ob sich Edge-Geräte mit der Zielumgebung verbinden und sich bei dieser authentifizieren können.

Edge-Geräte aktualisieren, um eine Verbindung sowohl zur Quell- als auch zur Zielumgebung herzustellen

Wenn Sie diese Phase erreichen, kann Ihre Zielumgebung Verbindungen von Edge-Geräten akzeptieren. Sie können Edge-Geräte aktualisieren, um sie sowohl mit der Quell- als auch mit der Zielumgebung zu verbinden, um Telemetrieereignisse und Informationen zum Gerätestatus zu senden. Wie Sie Edge-Geräte aktualisieren, hängt die erforderliche Vorgehensweise von der Kategorie des Edge-Geräts ab.

Bei Edge-Geräten, die Telemetrieereignisse oder Informationen zum Gerätestatus senden, aber keine Befehle oder Aktualisierungen der Gerätekonfiguration von Backend-Arbeitslasten empfangen, tun Sie Folgendes:

  1. Aktualisieren Sie die Edge-Geräte, damit sie Telemetrieereignisse und Informationen zum Gerätestatus an die Quell- und Zielumgebung senden.
  2. Prüfen Sie, ob die Zielumgebung Telemetrieereignisse und Informationen zum Gerätestatus korrekt empfängt.

Umgekehrt tun Sie für Edge-Geräte, die keine Telemetrieereignisse oder Informationen zum Gerätestatus senden, aber Befehle oder Konfigurationspdates von Backend-Arbeitslasten erhalten, Folgendes:

  1. Aktualisieren Sie Edge-Geräte, um Befehle und Konfigurationsupdates von der Zielumgebung zu erhalten.
  2. Achten Sie darauf, dass Ihre Edge-Geräte das Ergebnis der Befehlsausführung oder der Konfigurationsupdates an die Zielumgebung melden.
  3. Senden Sie einen Befehl und ein Konfigurationsupdate von der Zielumgebung an die Edge-Geräte.
  4. Überprüfen Sie, ob der Befehl und das Konfigurationsupdate erfolgreich ausgeführt wurden.

Bei Edge-Geräten, die sowohl Telemetrieereignisse als auch Informationen zum Gerätestatus senden und auch Befehle oder Konfigurationupdates von Backend-Arbeitslasten empfangen, gehen Sie so vor:

  1. Aktualisieren Sie die Edge-Geräte, damit sie Telemetrieereignisse und Informationen zum Gerätestatus an die Quell- und Zielumgebung senden.
  2. Prüfen Sie, ob die Zielumgebung Telemetrieereignisse und Informationen zum Gerätestatus korrekt empfängt.
  3. Aktualisieren Sie die Edge-Gerätecodes, um Befehle und Konfigurationsupdates von der Zielumgebung zu erhalten.
  4. Achten Sie darauf, dass Ihre Edge-Geräte das Ergebnis der Befehlsausführung oder der Konfigurationsupdates an die Zielumgebung melden.
  5. Senden Sie einen Befehl und ein Konfigurationsupdate von der Zielumgebung an die Edge-Geräte.
  6. Überprüfen Sie, ob der Befehl und das Konfigurationsupdate erfolgreich ausgeführt wurden.

Nachdem Sie diese Schritte für Ihren Anwendungsfall ausgeführt haben, führen alle Kategorien des Edge-Geräts Folgendes aus:

  • Stellen Sie eine Verbindung sowohl zur Quell- als auch zur Zielumgebung her.
  • Senden Sie Telemetrieereignisse und Informationen zum Gerätestatus an die Quell- und Zielumgebung.
  • Empfangen Sie Befehle und Konfigurationsupdates nur aus der Quellumgebung, da Sie noch keine Backend-Arbeitslasten migriert haben.

Sie sollten ein Szenario vermeiden, in dem Backend-Arbeitslasten dieselbe Nachricht verarbeiten, die Edge-Geräte sowohl an die Quell- als auch an die Zielumgebung senden. Wir empfehlen, die Aufbewahrungsdauer für Nachrichten in der Zielumgebung so gering wie möglich zu konfigurieren. Mit diesem Ansatz können Sie prüfen, ob die Zielumgebung wie erwartet funktioniert. Außerdem können Sie prüfen, ob Nachrichten in der Zielumgebung ablaufen, bevor Sie Backend-Arbeitslasten migrieren. Sie können die Konfiguration der Nachrichtenaufbewahrung in der Zielumgebung nach dem nächsten Migrationsschritt optimieren.

Wenn Ihre Edge-Geräte aus technischen oder regulatorischen Gründen nicht gleichzeitig eine Verbindung zur Quell- und der Zielumgebung herstellen können, konfigurieren Sie das Edge-Gerät so, dass die Verbindung zur Quellumgebung getrennt wird. Sie können dann nur eine Verbindung zur Zielumgebung herstellen. In diesem Fall empfangen die Backend-Arbeitslasten, die noch mit der Quellumgebung verbunden sind, keine Telemetrieereignisse und Informationen zum Gerätestatus von Edge-Geräten. Die Geräte können keine Befehle und Konfigurationsupdates mehr an Edge-Geräte senden.

Außerdem empfehlen wir, einen Pufferspeichermechanismus bereitzustellen und zu konfigurieren. Mit diesem Ansatz können Sie Datenverluste vermeiden, wenn Ihr Gerät Telemetrieereignisse und Informationen zum Gerätestatus an die Zielumgebung sendet, wenn Ihre Backend-Arbeitslasten noch mit der Quellumgebung verbunden sind. Die Backend-Arbeitslasten können diese Informationen dann nutzen, wenn sie eine Verbindung zur Zielumgebung herstellen. Sie können beispielsweise die Nachrichtenaufbewahrung der Zielumgebung basierend auf einem MQTT-Broker, Pub/Sub oder einer IoT-Plattform konfigurieren. Bei diesem Ansatz können unbestätigte Nachrichten für die Zeit verfügbar bleiben, die für die nächste Phase der Migration erforderlich ist, wie im folgenden Abschnitt beschrieben.

Backend-Arbeitslasten von der Quellumgebung in die Zielumgebung migrieren

Sie migrieren Ihre Backend-Arbeitslasten in die Zielumgebung. Je nach Architektur Ihrer Zielumgebung müssen Sie für die Migration der Arbeitslast unterschiedliche Ansätze verwenden.

MQTT-Broker in Google Cloud: Wenn Ihre Zielumgebung auf einem MQTT-Broker basiert, wird der Migrationsansatz durch die folgenden Faktoren bestimmt:

  • Bei Backend-Arbeitslasten, die Telemetrieereignisse oder Informationen zum Gerätestatus von Edge-Gerätenempfangen, aber keine Befehle oder Gerätekonfigurationsupdates senden: Konfigurieren Sie Ihre Backend-Arbeitslasten so, dass sie MQTT-Themen abonnieren, um Telemetrieereignisse und Informationen zum Gerätestatus von Edge-Geräten zu erhalten.
  • Umgekehrt gilt Folgendes für Backend-Arbeitslasten, die keine Telemetrieereignisse oder Informationen zum Gerätestatus empfangen, aber Befehle oder Aktualisierungen der Gerätekonfiguration senden: Konfigurieren Sie Ihr Backend. Arbeitslasten zum Veröffentlichen von Nachrichten, um Befehle und Konfigurationsupdates an MQTT-Themen für Befehls- und Konfigurationsupdates in der Zielumgebung zu senden.
  • Für Backend-Arbeitslasten, die sowohl Telemetrieereignisse als auch Informationen zum Gerätestatus von Edge-Geräten empfangen und Befehle oder Aktualisierungen der Gerätekonfiguration senden: Konfigurieren Sie Ihre Backend-Arbeitslasten so, dass MQTT-Themen abonniert werden. Telemetrie empfangen, konfigurieren Sie Ihre Backend-Arbeitslasten so, dass Nachrichten veröffentlicht werden, um Befehle und Konfigurationsupdates an die MQTT-Themen zu senden.

Pub/Sub: Wenn Ihre Zielumgebung auf Pub/Sub basiert, wird Ihr Migrationsansatz durch folgende Faktoren bestimmt:

  • Bei Backend-Arbeitslasten, die Telemetrieereignisse oder Informationen zum Gerätestatus von Edge-Gerätenempfangen, aber keine Befehle oder Gerätekonfigurationsupdates senden: Erstellen Sie neue Pub/Sub-Abos in der Zielumgebung und aktualisieren Sie Ihre Backend-Arbeitslasten so, dass sie die neu erstellten Abos nutzen.
  • Umgekehrt gilt Folgendes für Backend-Arbeitslasten, die keine Telemetrieereignisse oder Informationen zum Gerätestatus empfangen, aber Befehle oder Aktualisierungen der Gerätekonfiguration senden: Erstellen Sie Pub/Sub-Themen und konfigurieren Sie Ihre Backend-Arbeitslasten für die Veröffentlichung von Nachrichten, um Befehle und Konfigurationsupdates an Pub/Sub-Themen zu senden.
  • Für Backend-Arbeitslasten, die sowohl Telemetrieereignisse als auch Informationen zum Gerätestatus von Edge-Geräten empfangen und Befehle oder Aktualisierungen der Gerätekonfiguration senden: Konfigurieren Sie Ihre Backend-Arbeitslasten so, dass sie Pub/Sub-Themen abonnieren, um Telemetrieereignisse und Informationen zum Gerätestatus zu erhalten. Konfigurieren Sie dann Ihre Backend-Arbeitslasten so, dass Nachrichten veröffentlicht werden, um Befehle und Konfigurationsupdates an Pub/Sub-Themen zu senden.

IoT-Plattform von Drittanbietern: Wenn Ihre Zielumgebung auf der IoT-Plattform eines Drittanbieters basiert, folgen Sie der Anleitung der Drittanbieter-IoT-Plattform, um Integrationen zwischen Backend-Arbeitslasten und der IoT-Plattform einzurichten. Anschließend prüfen Sie, ob Backend-Arbeitslasten Telemetrieereignisse und Informationen zum Gerätestatus von Edge-Geräten empfangen können. Sie prüfen auch, ob Backend-Arbeitslasten Nachrichten veröffentlichen können, um Befehle oder Aktualisierungen der Gerätekonfiguration an das Edge-Gerät zu senden.

Gehen Sie so vor, um zu prüfen, ob Edge-Geräte und Backend-Arbeitslasten wie erwartet funktionieren:

  • Prüfen Sie, ob Backend-Arbeitslasten Telemetrieereignisse und Informationen zum Gerätestatus erhalten und korrekt reagieren. Wenn Ihre Backend-Arbeitslasten beispielsweise ein Dashboard nahezu in Echtzeit generieren, um bestimmte Telemetriedaten zu überwachen, prüfen Sie, ob das Dashboard mit dem neuesten Datenzeitraum aktualisiert wurde.
  • Prüfen Sie, ob Backend-Arbeitslasten Befehle und Konfigurationsupdates wie erwartet an Edge-Geräte senden. Prüfen Sie, ob Edge-Geräte auch wie erwartet reagieren.
  • Prüfen Sie, ob das Edge-Gerät Telemetrieereignisse und Informationen zum Gerätestatus an die Zielumgebung meldet.

An dieser Stelle führen Backend-Arbeitslasten folgende Schritte aus:

  • Stellen Sie eine Verbindung zur Zielumgebung her.
  • Sie erhalten Telemetrieereignisse und Informationen zum Gerätestatus von Edge-Geräten aus der Zielumgebung.
  • Befehle und Konfigurationsupdates an Edge-Geräte aus der Zielumgebung senden.

Sie können jetzt die Konfiguration der Nachrichtenaufbewahrung der Zielumgebung aktualisieren, wenn Sie einen Mindestwert festlegen, wenn Sie Edge-Geräte sowohl mit der Quell- als auch mit der Zielumgebung verbinden und es entsprechend Ihren Anforderungen festlegen.

Wenn Sie die Konfiguration von Backend-Arbeitslasten aktualisieren, um Telemetrieereignisse und Informationen zum Gerätestatus aus der Zielumgebung zu empfangen, benötigen Backend-Arbeitslasten möglicherweise Zeit, um diese aktualisierte Konfiguration anzuwenden. Während der Übergangsphase können Backend-Arbeitslasten keine Telemetrieereignisse und Informationen zum Gerätestatus verarbeiten, die von Edge-Geräten gesendet werden. Wenn Ihre Anwendungsfälle eine vollständige Datenintegrität erfordern, müssen Sie möglicherweise die Aufbewahrungsdauer der Nachricht der Zielumgebung konfigurieren, bevor Sie die Konfiguration von Backend-Arbeitslasten aktualisieren. Dieser Ansatz sorgt dafür, dass Nachrichten nicht ablaufen, bevor Backend-Arbeitslasten die neue Konfiguration anwenden und die Nachrichten nutzen können.

Edge-Geräte so aktualisieren, dass sie nur eine Verbindung zur Zielumgebung herstellen

Sie haben jetzt Ihre Edge-Geräte erfolgreich in die Zielumgebung migriert. Sie verwenden jedoch noch die Quellumgebung. Aktualisieren Sie Ihre Edge-Geräte so, dass sie nur dann eine Verbindung zur Zielumgebung herstellen, wenn Sie den Migrationsschritt abschließen und Verbindungen zur IoT-Kernverbindung entfernen. Nach Abschluss dieser Aktualisierung sind Ihre Edge-Geräte nur noch mit der Zielumgebung verbunden.

Quellumgebung außer Betrieb nehmen

Nachdem Sie Edge-Geräte und Backend-Arbeitslasten zur Zielumgebung migriert und die Zielumgebung validiert haben, nehmen Sie die Quellumgebung außer Betrieb.

So nehmen Sie die Quellumgebung außer Betrieb:

  1. Löschen Sie die Pub/Sub-Abos, die die IoT Core-Themen abonnieren.
  2. Löschen Sie nicht verwendete Pub/Sub-Themen. Wenn Sie Pub/Sub-Themen wiederverwenden, dürfen Sie die von IoT Core erstellten Themen nicht löschen. Die von IoT Core verwendeten Pub/Sub-Themen finden Sie über die IoT Core-Konsole.
  3. Löschen Sie die IoT Core-Geräte und -Registries.

Umgebung nach der Migration optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase machen Sie Ihre Umgebung effizienter als zuvor. Sie führen mehrere Iterationen einer wiederholbaren Schleife aus, bis Ihre Umgebung Ihre Optimierungsanforderungen erfüllt. Die Schritte dieser wiederholbaren Schleife sind folgende:

  1. Aktuelle Umgebung, Teams und Optimierungsschleife bewerten
  2. Optimierungsanforderungen und -ziele festlegen
  3. Umgebung und Teams optimieren
  4. Optimierungsschleife verbessern

Die folgenden Abschnitte basieren auf dem Dokument Migration zu Google Cloud: Umgebung optimieren.

Zielumgebung, Teams und Optimierungsschleife bewerten

Die erste Bewertung, die Sie vornehmen, konzentriert sich auf die Quellumgebung. Diese Bewertungsphase bezieht sich jedoch auf die Optimierungsphase. Weitere Informationen zum Bewerten der Zielumgebung, der Teams und der Optimierungsschleife finden Sie unter Umgebung, Teams und Optimierungsschleife messen.

Optimierungsanforderungen festlegen

Sehen Sie sich die folgenden Optimierungsanforderungen an, die Sie für Ihre Zielumgebung möglicherweise benötigen:

  • Richten Sie Autoscaling ein: Verwenden Sie Google Cloud-Dienste wie Verwaltete Instanzgruppe oder Google Kubernetes Engine, um Ihre IoT-Lösung und Backend-Arbeitslasten automatisch horizontal oder vertikal zu skalieren, wenn die Lasten steigen. Dieser Ansatz trägt dazu bei, dass Ihre Geräteregistrierung und Ihr Telemetrie-Datenspeicher bei der Bereitstellung einer großen Geräteflotte ein größeres Datenvolumen bewältigen kann. Da es sich bei Cloud Spanner um eine verteilte, hochverfügbare und skalierbare Transaktionsdatenbank handelt, ist es sinnvoll, Ihre Telemetriedaten und Geräteregistrierungsinformationen zu speichern.
  • Logging- und Monitoring-Mechanismus verbessern: Optimieren Sie Ihren Logging- und Monitoring-Mechanismus, um eine zentrale Lösung zu erstellen. Vielleicht möchten Sie auch bestimmte Monitoring-Messwerte verbessern, damit Sie besser verstehen, wie Edge-Geräte mit Ihrer IoT-Lösung interagieren. Sie sollten auch Aktivitäten wie Verbindungsereignisse, Verbindungstrennungen und Telemetrieereignisse protokollieren und korrelieren. Außerdem empfehlen wir Ihnen, System- und Anwendungsfehler zu überwachen. Richten Sie nach Möglichkeit eine Benachrichtigung ein, wenn bestimmte kritische Fehler auf Systemebene auftreten.
  • Arbeitslasten mit Google Cloud-Sicherheitsdiensten schützen: Security Command Center ist ein zentraler Dienst zur Meldung von Sicherheitslücken und Bedrohungen, mit dem Sie Ihre Sicherheitslage verbessern können, indem Sie Ihre Sicherheits- und Datenangriffsfläche bewerten. Er bietet Asset-Inventar und -Erkennung und kann Ihnen dabei helfen, Fehlkonfigurationen, Sicherheitslücken und Bedrohungen zu erkennen. Mit Security Command Center können Sie auch Risiken mindern und beheben. Informationen zum Schutz Ihrer Arbeitslasten, die in Google Kubernetes Engine (GKE) ausgeführt werden, finden Sie unter Google Kubernetes Engine-Sicherheit – Übersicht. Hier erfahren Sie, wie Sie Ihre GKE-Arbeitslasten schützen.

Optimierung abschließen

Nachdem Sie die Liste Ihrer Optimierungsanforderungen erstellt haben, schließen Sie die Optimierungsphase ab. Weitere Informationen finden Sie unter Migration zu Google Cloud: Umgebung optimieren.

Nächste Schritte