Suivez ces étapes pour migrer un déploiement de Cloud Exchange conteneurisé, autonome ou HA, vers la dernière version. Pour les chemins de migration pris en charge et l’autre type de déploiement, reportez-vous à Migrer Cloud Exchange.
Important
Contactez votre SE/AM si vous avez des questions concernant l’installation, le déploiement, la configuration et la migration de Cloud Exchange.
Conditions préalables
- Avant de commencer la migration, assurez-vous que votre instance respecte les Configuration système requise pour Cloud Exchange.
- Allez dans le répertoire d’installation Cloud Exchange :
ta_cloud_exchange - Exécutez ces commandes pour télécharger le script de vérification de la mise à jour/migration et pour rendre le script exécutable :
curl -fsSL -O https://raw.githubusercontent.com/netskopeoss/ta_cloud_exchange/main/ce_healthcheck chmod +x ce_healthcheck
- Exécutez le script de vérification de mise à jour/migration. Pour plus de détails sur sa sortie, reportez-vous à Comprendre les résultats.
sudo python3 ./ce_healthcheck
- Pour les nœuds secondaires, exécutez la commande donnée ci-dessous. Ceci s’applique uniquement aux déploiements en HA.
sudo python3 ./ce_healthcheck --deployment HA
Note
Si l’une des vérifications échoue, veuillez les traiter avant de passer à l’étape suivante.
- Pour les nœuds secondaires, exécutez la commande donnée ci-dessous. Ceci s’applique uniquement aux déploiements en HA.
- Désactivez tous les plugins source dans tous les modules et attendez que les tâches en file d'attente se terminent :
- Attendez 20 à 30 minutes après avoir désactivé les plugins sources.
- Accédez à Settings > Logging, cliquez sur Filter Query, entrez ce filtre dans le champ Filtres, puis cliquez sur Load.
message Like "Ingested " || message Like "Stored " || message Like "task(s)" || message Like "Completed storing"
- Surveillez les journaux filtrés. Lorsque aucun New journal n'apparaît, poursuivez la migration.
- Une fois la migration terminée, activez les plugins sources que vous avez désactivés.
- Gardez le mot de passe de maintenance à portée de main. Vous en aurez besoin pour effectuer certaines étapes.
Important
Si vous perdez le mot de passe de maintenance, vos données existantes ne pourront pas être conservées.
La migration des données RabbitMQ n'est pas prise en charge, car le type de file d'attente est passé de Classique à Quorum.
Déploiement autonome
De la v5.1.1 à la v7.0.0, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Déploiement autonome
Le script migrate_ce migre votre déploiement vers le dernier déploiement autonome de Cloud Exchange. Exécutez le script sur la New machine (destination).
Avant d'exécuter le script, assurez-vous que :
- Vous disposez des informations d'identification SSH (mot de passe root ou fichier PEM) de l'ancienne machine où Cloud Exchange est installé.
- Le dernier dépôt Cloud Exchange est cloné sur la New machine. Pour le cloner, exécutez :
git clone https://github.com/netskopeoss/ta_cloud_exchange
- Sur la New machine, accédez au répertoire où vous avez cloné la dernière version de Cloud Exchange. Copiez l'exemple de fichier de configuration et ouvrez-le pour le modifier :
cp cloudexchange.config.example cloudexchange.config vi cloudexchange.config
- Dans
cloudexchange.config, définissez les valeurs de ces champs. Définissez également les champs facultatifs que vous utilisez ou personnalisez, tels que la configuration du proxy et le port de l’interface utilisateur.MAINTENANCE_PASSWORD=<old cloud exchange maintenance password> JWT_SECRET=<old cloud exchange JWT secret>
JWT_SECRETest optionnel. Si vous le laissez vide, le script d’installation génère un New secret JWT. - Sur la New machine, exécutez le script de migration :
sudo ./migrate_ce
- Lorsque vous y êtes invité, saisissez le nom d’utilisateur, l’adresse IP et la méthode d’authentification de l’ancienne machine. Saisissez ensuite le mot de passe de l’utilisateur pour l’authentification par mot de passe, ou le chemin d’accès au fichier PEM pour l’authentification par fichier PEM.
- Attendre la fin du script. Après s’être connecté à l’ancienne machine, le script :
- Exécutez le script d’arrêt sur l’ancienne machine.
- Compresse les données existantes sur l'ancienne machine et les transfère vers la New machine.
- Décompresse les données dans le dossier d'installation de la New machine.
- Exécute le script d'installation, qui demande les entrées nécessaires pour démarrer la dernière version de Cloud Exchange.
- Exécute le script de démarrage.
- Vérifiez l’état des conteneurs. Si vous utilisez Podman, exécutez plutôt
sudo podman ps.sudo docker ps
- Ouvrez l'interface utilisateur du Cloud Exchange migré dans votre navigateur. Connectez-vous avec vos identifiants Cloud Exchange existants et vérifiez que vos configurations et données sont présentes et fonctionnent.
Les plugins CLS qui utilisent l’authentification TLS doivent être mis à jour vers une version compatible CE 7.0.0 avant de pouvoir être configurés ou utilisés sur CE 7.0.0. Consultez la base de connaissances pour connaître les plugins concernés.
Déploiement HA
Vers la version 7.0.0 à partir de la version 5.1.1, v5.1.2, v6.0.0, v6.1.0 Déploiement autonome
Pour passer d'un déploiement autonome au dernier déploiement HA conteneurisé, copiez les données de l'ancienne machine autonome vers le nœud qui devient le New nœud primaire.
Pour plus de détails sur les paramètres de haute disponibilité et sur la façon de configurer le cluster, reportez-vous à Haute disponibilité de Cloud Exchange.
Sur l'ancienne machine autonome
- Accédez au répertoire
ta_cloud_exchange:cd ta_cloud_exchange
- Arrêtez les conteneurs :
sudo ./stop
- Accédez au répertoire de données :
cd data
- Créez un fichier zip des données :
sudo zip -r ce_backup.zip mongo-data/ repos/ plugins/
- Si vous utilisez des plug-ins personnalisés, ajoutez-les au fichier zip :
sudo zip -r ce_backup.zip custom_plugins
- Copiez le fichier zip vers le New nœud principal :
sudo scp ce_backup.zip <username>@<ip-of-vm>:<ta_cloud_directory>/data
Sur le New nœud principal
Exécutez ces étapes sur le nœud que vous souhaitez définir comme nœud principal.
- Accédez au répertoire de données de la version la plus récente de Cloud Exchange :
cd <ta_cloud_directory>/data
- Extraire les données :
sudo unzip ce_backup.zip "mongo-data/*" -d . sudo mkdir /opt/shared/data/ -p sudo unzip ce_backup.zip "plugins/*" "repos/*" "custom_plugins/*" -d /opt/shared/data/
- Revenir au répertoire de travail d’origine :
cd ..
- Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
cp cloudexchange.config.example cloudexchange.config vi cloudexchange.config
- Dans
cloudexchange.config, définissez les valeurs de ces champs. Définissez également les champs facultatifs que vous utilisez ou personnalisez, tels que la configuration du proxy et le port de l’interface utilisateur.MAINTENANCE_PASSWORD=<old cloud exchange maintenance password> JWT_SECRET=<old cloud exchange JWT secret>
JWT_SECRETest optionnel. Si vous le laissez vide, le script d’installation génère un New secret JWT. - Exécutez le script d'installation. Exécutez-le d'abord sur le nœud principal.
sudo python3 ./setup
- Démarrez le Cloud Exchange :
sudo ./start
- Ouvrez l’interface utilisateur du nœud principal dans votre navigateur à l’adresse
https://<ip>:<port>et connectez-vous avec vos identifiants Cloud Exchange existants. - Accédez à Settings > General Settings > Node Configurations et activez le commutateur Enable HA. Dans la fenêtre contextuelle Confirmer l’action, saisissez l’adresse IP ou le FQDN de Cloud Exchange uniquement si vous devez les modifier, puis cliquez sur Enable HA.
Important
Pendant que la HA est activée, Cloud Exchange est temporairement indisponible et peut redémarrer plusieurs fois.
Sur les nœuds secondaires
Effectuez les étapes 1 à 6 sur chaque nœud secondaire. Ajoutez ensuite les nœuds secondaires à partir de l'interface utilisateur du nœud primaire.
- Accédez au répertoire
ta_cloud_exchangequi contient la dernière version de Cloud Exchange :cd <ta_cloud_exchange-dir>
- Sur le nœud principal, copiez le contenu du fichier de clé CA :
<ta_cloud_exchange-dir>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
- Sur le nœud secondaire, créez le fichier de clé d’autorité de certification, collez la clé que vous avez copiée et enregistrez le fichier. La clé d’autorité de certification correspondante permet au nœud secondaire de communiquer avec le cluster HA.
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
- Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
cp cloudexchange.config.example cloudexchange.config vi cloudexchange.config
- Dans
cloudexchange.config, définissez les valeurs de ces champs :Important
Le secret JWT et la clé CA d'un nœud secondaire doivent correspondre à ceux du nœud principal. S'ils diffèrent, l'ajout du nœud secondaire au cluster HA échouera avec une erreur d'authentification. Si vous ne connaissez pas le secret JWT du nœud principal, générez-en un New et appliquez-le. Pour les étapes, reportez-vous à la section Dépannage de Cloud Exchange.
JWT_SECRET=<JWT_SECRET value of the primary node> MAINTENANCE_PASSWORD=<old maintenance password>
- Exécutez le script de configuration :
sudo python3 ./setup
- Dans l’interface utilisateur du nœud principal, accédez à Settings > General Settings > Node Configurations et ajoutez les nœuds secondaires un par un.
Il n’est pas nécessaire d’exécuter le script de démarrage sur les nœuds secondaires. Il s’exécute automatiquement lorsque vous ajoutez un nœud secondaire depuis l’interface utilisateur du nœud principal.
Les plugins CLS qui utilisent l’authentification TLS doivent être mis à jour vers une version compatible CE 7.0.0 avant de pouvoir être configurés ou utilisés sur CE 7.0.0. Consultez la base de connaissances pour connaître les plugins concernés.
Vers la version 7.0.0 à partir de la version 5.1.1, version 5.1.2, version 6.0.0, version 6.0.1, version 6.1.0 Déploiement HA
Pour passer du déploiement HA conteneurisé actuel au dernier déploiement HA conteneurisé, copiez les données du nœud principal actuel vers le New nœud principal.
Sur le déploiement HA actuel
- Arrêtez d'abord les nœuds secondaires, puis le nœud primaire, afin que les conteneurs s'arrêtent correctement :
sudo ./stop
- Sur le nœud primaire, accédez au répertoire des données et créez un fichier zip des données MongoDB :
cd <ta_cloud_exchange_directory_path>/data sudo zip -r ce_backup.zip mongo-data/
- Accédez au lecteur partagé et ajoutez les dossiers
reposetpluginsau fichier zip. Pour la v6.0.0 et les versions ultérieures, le chemin d’accès au lecteur partagé est/opt/shared/data/.cd <shared_drive> sudo zip -r <ce_backup_zip_location>/ce_backup.zip repos/ plugins/
- Si vous utilisez des plug-ins personnalisés, ajoutez-les au fichier zip :
sudo zip -r <ce_backup_zip_location>/ce_backup.zip custom_plugins/
- Copiez le fichier zip du nœud principal actuel vers le New nœud principal, qui dispose de la dernière version de Cloud Exchange :
sudo scp <ce_backup_zip_location>/ce_backup.zip <username>@<ip-of-vm>:<ta_cloud_exchange_directory_path>/data
Sur le New nœud principal
- Accédez au répertoire de données :
cd <ta_cloud_exchange_directory_path>/data
- Extraire les données :
sudo unzip ce_backup.zip "mongo-data/*" -d . sudo mkdir /opt/shared/data/ -p sudo unzip ce_backup.zip "plugins/*" "repos/*" "custom_plugins/*" -d /opt/shared/data/
- Revenir au répertoire de travail d’origine :
cd ..
- Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
cp cloudexchange.config.example cloudexchange.config vi cloudexchange.config
- Dans
cloudexchange.config, définissez les valeurs de ces champs. Définissez également les champs facultatifs que vous utilisez ou personnalisez, tels que la configuration du proxy et le port de l’interface utilisateur.HA_ENABLED=True HA_CURRENT_NODE=<current node ip> HA_PRIMARY_NODE_IP=<current node ip> HA_IP_LIST=<current node ip> MAINTENANCE_PASSWORD=<old maintenance password> JWT_SECRET=<old cloud exchange JWT secret>
JWT_SECRETest optionnel. Si vous le laissez vide, le script d’installation génère un New secret JWT. - Exécutez le script de configuration :
sudo python3 ./setup
- Migrez les données MongoDB. Exécutez cette commande une seule fois.
sudo ./restore_ha_backup
- Démarrez le Cloud Exchange :
sudo ./start
Sur les nœuds secondaires
Effectuez les étapes 1 à 6 sur chaque nœud secondaire. Ajoutez ensuite les nœuds secondaires à partir de l'interface utilisateur du nœud primaire.
- Accédez au répertoire
ta_cloud_exchange:cd <ta_cloud_exchange_directory_path>
- Sur le nœud principal, copiez le contenu du fichier de clé CA :
<ta_cloud_exchange_directory_path>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
- Sur le nœud secondaire, créez le fichier de clé d’autorité de certification, collez la clé que vous avez copiée et enregistrez le fichier. La clé d’autorité de certification correspondante permet au nœud secondaire de communiquer avec le cluster HA.
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
- Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
cp cloudexchange.config.example cloudexchange.config vi cloudexchange.config
- Dans
cloudexchange.config, définissez les valeurs de ces champs :Important
Le secret JWT et la clé CA d'un nœud secondaire doivent correspondre à ceux du nœud principal. S'ils diffèrent, l'ajout du nœud secondaire au cluster HA échouera avec une erreur d'authentification. Si vous ne connaissez pas le secret JWT du nœud principal, générez-en un New et appliquez-le. Pour les étapes, reportez-vous à la section Dépannage de Cloud Exchange.
JWT_SECRET=<JWT_SECRET value of the primary node> MAINTENANCE_PASSWORD=<old maintenance password>
- Exécutez le script de configuration :
sudo python3 ./setup
- Dans l’interface utilisateur du nœud principal, accédez à Settings > General Settings > Node Configurations et ajoutez les nœuds secondaires un par un.
Il n’est pas nécessaire d’exécuter le script de démarrage sur les nœuds secondaires. Il s’exécute automatiquement lorsque vous ajoutez un nœud secondaire depuis l’interface utilisateur du nœud principal.
Les plugins CLS qui utilisent l’authentification TLS doivent être mis à jour vers une version compatible CE 7.0.0 avant de pouvoir être configurés ou utilisés sur CE 7.0.0. Consultez la base de connaissances pour connaître les plugins concernés.