Leitfaden zur Migration: Der Übergang von v1 zu v3

Dieser Leitfaden enthält eine schrittweise Anleitung für die Migration Ihres IBM Cloud Logs Routing-Dienstes von Version 1 ( v1 ) auf Version 3 ( v3 ). Während v1 ein regionales Konzept bietet, bietet v3 einen globalen Ansatz mit Routen und Filtern, um die Weiterleitung von Plattformprotokollen an Ihre Bedürfnisse anzupassen. Der Migrationsprozess umfasst die Konfiguration Ihrer neuen Umgebung v3 und den Wechsel von v1 zu v3.

Beachten Sie, dass es während des letzten Migrationsschritts zu einer kurzen Dienstunterbrechung (ca. einige Minuten) kommt, bei der keine Plattformprotokolle empfangen werden.

WARNUNG: Diese Migration ist unumkehrbar. Sobald Sie zu v3 migriert sind, können Sie nicht mehr zu v1 zurückkehren.

Häufige Migrationsszenarien

Bevor Sie mit der Migration beginnen, sollten Sie sich darüber im Klaren sein, welches Szenario am besten zu Ihrer derzeitigen Protokollierungsarchitektur passt. Die folgenden drei Szenarien stellen die gängigsten Protokollierungskonfigurationen dar und helfen Ihnen dabei, die geeignete Konfiguration für Ihre v3 Umgebung zu finden.

Szenario 1: Zentralisierte Protokollierung

Bei einer zentralisierten Protokollierungskonfiguration werden alle Plattformprotokolle für Ihr gesamtes Konto in einer einzigen IBM Cloud Logs-Instanz konsolidiert.

Dieser Ansatz vereinfacht die Protokollverwaltung, indem er einen einheitlichen Überblick über alle Plattformaktivitäten in Ihrem Konto bietet.

Um dieses Szenario in v3 zu implementieren, müssen Sie ein Ziel erstellen, das auf Ihre zentralisierte Instanz IBM Cloud Logs verweist, und eine Route mit einer Wildcard-Regel konfigurieren, um alle Plattformprotokolle unabhängig von ihrer Quellregion zu erfassen.

Szenario 2: Geografische Aufzeichnung

Das geografische Protokollierungsszenario ist für Unternehmen gedacht, die mehrere Protokollierungsinstanzen an verschiedenen geografischen Standorten unterhalten.

In dieser Konfiguration werden Plattformprotokolle aus verschiedenen Regionen an die nächstgelegene oder eine bestimmte regionale IBM Cloud Logs-Instanz weitergeleitet, je nach geografischer Nähe oder Anforderungen an die Datenresidenz. Dieser Ansatz schafft ein Gleichgewicht zwischen zentraler Sichtbarkeit und geografischer Verteilung und ermöglicht es Ihnen, Protokolle aus mehreren Regionen an eine kleinere Anzahl strategisch günstig gelegener IBM Cloud Logs Instanzen weiterzuleiten.

Um dieses Szenario zu implementieren, müssen Sie mehrere Ziele erstellen (eines für jede geografische IBM Cloud Logs Instanz) und Routen mit entsprechenden regionsbasierten Filtern konfigurieren, um Protokolle an das richtige geografische Ziel zu leiten.

Szenario 3: Regionaler Holzeinschlag

Die regionale Protokollierung stellt den am weitesten verteilten Ansatz dar, bei dem jede Region IBM Cloud über eine eigene Instanz IBM Cloud Logs verfügt.

Diese Konfiguration gewährleistet eine vollständige regionale Isolierung der Protokolldaten und wird häufig verwendet, um strenge Anforderungen an die Datenaufbewahrung oder die Einhaltung von Vorschriften zu erfüllen. In diesem Szenario werden Plattformprotokolle, die in einer bestimmten Region generiert werden, ausschließlich an die IBM Cloud Logs Instanz weitergeleitet, die in derselben Region eingesetzt wird.

Um dieses Szenario in v3 zu implementieren, müssen Sie für jede Region, in der Sie tätig sind, ein eigenes Ziel und eine eigene Route erstellen und sicherstellen, dass jede regionale Route Filter enthält, die die Weiterleitung von Protokollen auf die IBM Cloud Logs Instanz dieser Region beschränken.

Migrationsansätze

Es gibt zwei Möglichkeiten, von v1 auf v3 zu migrieren. Wählen Sie den Ansatz, der Ihren Bedürfnissen am besten entspricht.

  1. Automatisierte Migration (empfohlen):

    Die automatisierte Migration wird für die meisten Benutzer empfohlen, da sie den Migrationsprozess vereinfacht und das Risiko von Konfigurationsfehlern verringert.

    Verwenden Sie die Migrations-APIs, um automatisch v3 Ziele und Routen auf der Grundlage Ihrer bestehenden v1 Tenants zu erstellen.

    Weitere Informationen finden Sie unter Automatisierte Migration.

  2. Manuelle Konfiguration:

    Konfigurieren Sie Ihre v3 Umgebung manuell von Grund auf, bevor Sie die Migration abschließen.

    Wählen Sie eine der folgenden Optionen aus:

Verständnis der Migrationsstaaten

Der Migrationsprozess durchläuft mehrere Stadien:

  • BEFORE: Der Ausgangszustand vor Beginn der Migration. Wenn ein früherer Migrationsversuch fehlgeschlagen ist, wird die Fehlermeldung mit angegeben.
  • IN_PROGRESS: Der Migrationsprozess läuft aktiv. Dies kann je nach Ihrer Konfiguration einige Minuten dauern.
  • PENDING_COMPLETION: Ihre v3 Routen und Ziele wurden erfolgreich erstellt. Sie sollten die Konfiguration überprüfen, bevor Sie die Migration abschließen.
  • ABGESCHLOSSEN: Die Migration wurde erfolgreich abgeschlossen, und Ihr Konto verwendet nun die Konfiguration v3.

IAM-Berechtigungen für die Migration

Der Migrationsprozess erfordert bestimmte IAM-Berechtigungen. Die folgenden globalen Aktionen sind für die Verwaltung der Migration verfügbar:

  • logs-router.migration.post: Konfiguriert und startet die Migration. Dies ist ein zweistufiger Prozess, bei dem zunächst die Kontometadaten eingerichtet und dann die eigentliche Aktualisierung aller Regionen gestartet wird. Erfordert die Rolle eines Administrators.
  • logs-router.migration.get: Ruft den Status der Migration ab. Verfügbar für die Rollen Administrator, Editor, Operator und Viewer.
  • logs-router.migration.delete: Löscht den generierten Migrationsplan, einschließlich aller automatisch erstellten v3 Ziele und Routen. Erfordert die Rolle eines Administrators.

Für die Migration von V1 auf V3 müssen Sie die Plattformrolle Administrator haben.

Weitere Informationen zu IAM-Rollen und Berechtigungen finden Sie unter IAM-Rollen.