Guide de migration : Passer de v1 à v3

Ce guide fournit des instructions étape par étape pour la migration de votre service IBM Cloud Logs Routing de la version 1 ( v1 ) à la version 3 ( v3 ). Alors que v1 propose un concept régional, v3 offre une approche globale avec des itinéraires et des filtres permettant d'adapter l'acheminement des journaux de la plate-forme à vos besoins. Le processus de migration consiste à configurer votre nouvel environnement v3, puis à passer de v1 à v3.

Notez qu'il y aura une brève interruption de service (environ quelques minutes) au cours de la dernière étape de la migration, lorsque les journaux de la plate-forme ne seront pas reçus.

ATTENTION: Cette migration est irréversible. Une fois que vous avez migré vers v3, vous ne pouvez plus revenir à v1.

Scénarios de migration courants

Avant de commencer votre migration, il est important de comprendre quel scénario correspond le mieux à votre architecture de journalisation actuelle. Les trois scénarios suivants représentent les configurations de journalisation les plus courantes et vous aideront à déterminer la configuration appropriée pour votre environnement v3.

Scénario 1 : enregistrement centralisé

Dans une configuration de journalisation centralisée, tous les journaux de la plate-forme pour l'ensemble de votre compte sont consolidés dans une seule instance IBM Cloud Logs.

Cette approche simplifie la gestion des journaux en fournissant une vue unifiée de toutes les activités de la plateforme sur votre compte.

Pour mettre en œuvre ce scénario dans v3, vous devrez créer une cible pointant vers votre instance centralisée IBM Cloud Logs et configurer une route avec une règle de caractère générique pour capturer tous les journaux de la plate-forme, quelle que soit leur région d'origine.

Scénario 2 : enregistrement géographique

Le scénario de journalisation géographique est conçu pour les organisations qui gèrent plusieurs instances de journalisation réparties sur différents sites géographiques.

Dans cette configuration, les journaux de la plate-forme provenant de différentes régions sont acheminés vers l'instance régionale IBM Cloud Logs la plus proche ou désignée en fonction de la proximité géographique ou des exigences en matière de résidence des données. Cette approche permet d'équilibrer la visibilité centralisée et la distribution géographique, ce qui vous permet d'acheminer les journaux provenant de plusieurs régions vers un plus petit nombre d'instances IBM Cloud Logs situées à des endroits stratégiques.

Pour mettre en œuvre ce scénario, vous devrez créer plusieurs cibles (une pour chaque instance géographique de IBM Cloud Logs ) et configurer des itinéraires avec des filtres régionaux appropriés pour diriger les journaux vers la destination géographique correcte.

Scénario 3 : Exploitation forestière régionale

La journalisation régionale représente l'approche la plus distribuée, où chaque région IBM Cloud dispose de sa propre instance IBM Cloud Logs.

Cette configuration garantit une isolation régionale complète des données de journalisation et est souvent utilisée pour répondre à des exigences strictes en matière de résidence des données ou de conformité. Dans ce scénario, les journaux de la plate-forme générés dans une région spécifique sont acheminés exclusivement vers l'instance IBM Cloud Logs déployée dans cette même région.

Pour mettre en œuvre ce scénario dans v3, vous devrez créer une cible et une route distinctes pour chaque région où vous opérez, en veillant à ce que chaque route régionale comprenne des filtres qui limitent l'acheminement des journaux à la seule instance IBM Cloud Logs de cette région.

Approches en matière de migration

Il existe deux approches pour migrer de v1 à v3. Choisissez l'approche qui correspond le mieux à vos besoins.

  1. Migration automatisée (recommandée):

    L'approche de la migration automatisée est recommandée pour la plupart des utilisateurs car elle simplifie le processus de migration et réduit le risque d'erreurs de configuration.

    Utilisez les API de migration pour générer automatiquement des cibles et des itinéraires v3 en fonction de vos locataires v1 existants.

    Pour plus d'informations, voir Migration automatisée.

  2. Configuration manuelle:

    Configurez manuellement votre environnement v3 à partir de zéro avant de procéder à la migration.

    Sélectionnez l'une des options suivantes :

Comprendre les États de migration

Le processus de migration passe par plusieurs états :

  • AVANT: L'état initial avant le début de la migration. Si une tentative de migration précédente a échoué, le message d'erreur sera inclus.
  • IN_PROGRESS: Le processus de migration est en cours d'exécution. Cette opération peut prendre plusieurs minutes en fonction de votre configuration.
  • PENDING_COMPLETION: Vos routes et cibles v3 ont été créées avec succès. Vous devez vérifier la configuration avant de terminer la migration.
  • COMPLET: La migration a été effectuée avec succès et votre compte utilise désormais la configuration v3.

Permissions IAM pour la migration

Le processus de migration nécessite des autorisations IAM spécifiques. Les actions globales suivantes sont disponibles pour gérer la migration :

  • logs-router.migration.post: Configure et démarre la migration. Il s'agit d'un processus en deux étapes qui consiste à configurer les métadonnées du compte, puis à lancer la mise à jour effective de toutes les régions. Nécessite un rôle d'administrateur.
  • logs-router.migration.get: Permet de connaître l'état de la migration. Disponible pour les rôles d'administrateur, d'éditeur, d'opérateur et de spectateur.
  • logs-router.migration.delete: Supprime le plan de migration généré, y compris toutes les cibles et routes v3 créées automatiquement. Nécessite un rôle d'administrateur.

Vous devez avoir le rôle d' administrateur de la plate-forme pour migrer de V1 à V3.

Pour plus d'informations sur les rôles et les autorisations IAM, voir Rôles IAM.