Guida alla migrazione: Transizione da v1 a v3

Questa guida fornisce istruzioni passo passo per la migrazione del servizio IBM Cloud Logs Routing dalla versione 1 ( v1 ) alla versione 3 ( v3 ). Mentre v1 fornisce un concetto regionale, v3 offre un approccio globale con percorsi e filtri per adattare l'instradamento dei registri della piattaforma alle vostre esigenze. Il processo di migrazione prevede la configurazione del nuovo ambiente v3 e il passaggio da v1 a v3.

Si noti che durante la fase finale della migrazione si verificherà una breve interruzione del servizio (circa qualche minuto) in cui non verranno ricevuti i log della piattaforma.

ATTENZIONE: questa migrazione è irreversibile. Una volta migrati a v3, non è possibile tornare a v1.

Scenari di migrazione comuni

Prima di iniziare la migrazione, è importante capire quale scenario si adatta meglio all'attuale architettura di registrazione. I tre scenari seguenti rappresentano le configurazioni di registrazione più comuni e vi aiuteranno a determinare la configurazione appropriata per il vostro ambiente v3.

Scenario 1: Registrazione centralizzata

In una configurazione di registrazione centralizzata, tutti i log della piattaforma per l'intero account vengono consolidati in un'unica istanza IBM Cloud Logs.

Questo approccio semplifica la gestione dei registri, fornendo una visione unificata di tutte le attività della piattaforma sul vostro account.

Per implementare questo scenario in v3, è necessario creare un target che punti all'istanza centralizzata di IBM Cloud Logs e configurare una rotta con una regola jolly per catturare tutti i log della piattaforma, indipendentemente dalla regione di origine.

Scenario 2: Registrazione geografica

Lo scenario di logging geografico è pensato per le organizzazioni che mantengono più istanze di logging distribuite in diverse località geografiche.

In questa configurazione, i registri della piattaforma provenienti da varie regioni vengono indirizzati all'istanza regionale IBM Cloud Logs più vicina o designata in base alla vicinanza geografica o ai requisiti di residenza dei dati. Questo approccio bilancia la visibilità centralizzata con la distribuzione geografica, consentendo di instradare i log da più regioni a un numero minore di istanze IBM Cloud Logs strategicamente posizionate.

Per implementare questo scenario, è necessario creare più target (uno per ogni istanza geografica di IBM Cloud Logs ) e configurare percorsi con filtri appropriati basati sulla regione per indirizzare i log alla destinazione geografica corretta.

Scenario 3: disboscamento regionale

Il logging regionale rappresenta l'approccio più distribuito, in cui ogni regione di IBM Cloud ha la propria istanza IBM Cloud Logs dedicata.

Questa configurazione garantisce il completo isolamento regionale dei dati di log e viene spesso utilizzata per soddisfare requisiti rigorosi di residenza dei dati o di conformità. In questo scenario, i log della piattaforma generati in una regione specifica vengono indirizzati esclusivamente all'istanza IBM Cloud Logs distribuita nella stessa regione.

Per implementare questo scenario in v3, è necessario creare una destinazione e una rotta separate per ogni regione in cui si opera, assicurandosi che ogni rotta regionale includa filtri che limitino l'instradamento dei registri solo all'istanza IBM Cloud Logs di quella regione.

Approcci alla migrazione

Esistono due approcci per migrare da v1 a v3. Scegliete l'approccio più adatto alle vostre esigenze.

  1. Migrazione automatica (consigliata):

    L'approccio alla migrazione automatica è consigliato alla maggior parte degli utenti, in quanto semplifica il processo di migrazione e riduce il rischio di errori di configurazione.

    Utilizzate le API di migrazione per generare automaticamente i target e le rotte di v3 in base ai tenant di v1 esistenti.

    Per ulteriori informazioni, vedere Migrazione automatica.

  2. Configurazione manuale:

    Configurare manualmente l'ambiente v3 da zero prima di completare la migrazione.

    Scegli una delle seguenti opzioni:

Comprendere gli stati di migrazione

Il processo di migrazione passa attraverso diversi stati:

  • PRIMA: Lo stato iniziale prima dell'inizio della migrazione. Se un precedente tentativo di migrazione non è andato a buon fine, verrà incluso il messaggio di errore.
  • IN_PROGRESS: Il processo di migrazione è in corso. Questa operazione può richiedere alcuni minuti, a seconda della configurazione.
  • PENDING_COMPLETION: Le rotte e le destinazioni di v3 sono state create con successo. È necessario verificare la configurazione prima di completare la migrazione.
  • COMPLETO: La migrazione è stata completata con successo e l'account utilizza ora la configurazione v3.

Autorizzazioni IAM per la migrazione

Il processo di migrazione richiede autorizzazioni IAM specifiche. Per gestire la migrazione sono disponibili le seguenti azioni globali:

  • logs-router.migration.post: Configura e avvia la migrazione. Si tratta di un processo in due fasi per impostare i metadati dell'account e poi avviare l'aggiornamento effettivo di tutte le regioni. Richiede il ruolo di amministratore.
  • logs-router.migration.get: Recupera lo stato della migrazione. Disponibile per i ruoli di Amministratore, Editor, Operatore e Visualizzatore.
  • logs-router.migration.delete: Elimina il piano di migrazione generato, compresi tutti i target e le rotte v3 creati automaticamente. Richiede il ruolo di amministratore.

Per migrare da V1 a V3 è necessario avere il ruolo di amministratore della piattaforma.

Per ulteriori informazioni sui ruoli e le autorizzazioni IAM, vedere Ruoli IAM.