Utilisez ces étapes pour migrer Cloud Exchange en tant que VM, 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.
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 :
/opt/cloudexchange/cloudexchange - 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.
- Assurez-vous que la VM peut se connecter à
https://cloud-exchange-store.s3.us-east-1.amazonaws.com. - 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.
Si vous exécutez Cloud Exchange en tant que VM (OVA ou Hyper-V) sur une version antérieure à v5.1.1, vous avez besoin des informations d'identification racine de la machine virtuelle.
Nom d'utilisateur : root
Mot de passe : M5#w6V+.T^8gv?%,
Si vous exécutez Cloud Exchange en tant que VM sur Azure ou AWS, vous pouvez effectuer ces étapes vous-même.
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 la dernière version autonome de Cloud Exchange. Exécutez le script sur la New machine virtuelle (destination). Le script nécessite le mot de passe de l’utilisateur cteadmin sur l’ancienne machine virtuelle.
- Sur la New machine, allez dans le répertoire
/opt/cloudexchange/cloudexchange. Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :cd /opt/cloudexchange/cloudexchange 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 et l'adresse IP de l'ancienne machine, ainsi que son mot de passe ou le chemin d'accès à son 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.
Déploiement HA
De la v5.1.1 à la v7.0.0, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Déploiement autonome
Avant de commencer, remplissez les prérequis et effectuez une sauvegarde. Pour plus de détails, consultez Sauvegarder Cloud Exchange.
Pour passer d'un déploiement autonome à la version la plus récente de Cloud Exchange en tant que déploiement VM HA, copiez les données de l'ancienne VM autonome vers le nœud qui devient le nœud primaire New.
Pour plus de détails sur les paramètres HA et sur la manière de configurer le cluster, consultez Haute disponibilité de Cloud Exchange. Assurez-vous que le répertoire /opt/shared/data est disponible pour que Cloud Exchange puisse stocker les ressources partagées par les nœuds du cluster.
Sur l'ancienne VM autonome
- Accédez au répertoire
/opt/cloudexchange/cloudexchange:cd /opt/cloudexchange/cloudexchange
- Arrêtez Cloud Exchange :
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 -i <public_key> ce_backup.zip <username>@<public_ip>:/opt/cloudexchange/cloudexchange/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 :
cd /opt/cloudexchange/cloudexchange/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.
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
/opt/cloudexchange/cloudexchange:cd /opt/cloudexchange/cloudexchange
- Sur le nœud principal, copiez le contenu du fichier de clé CA :
/opt/cloudexchange/cloudexchange/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 /opt/cloudexchange/cloudexchange/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 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 le 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.
- 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.
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
Avant de commencer, remplissez les prérequis et effectuez une sauvegarde. Pour plus de détails, consultez Sauvegarder Cloud Exchange.
Pour passer du déploiement HA de Cloud Exchange en tant que VM actuel au dernier, 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 Cloud Exchange s'arrête correctement :
cd /opt/cloudexchange/cloudexchange 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 /opt/cloudexchange/cloudexchange/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 -i <public_key> <ce_backup_zip_location>/ce_backup.zip <username>@<public_ip>:/opt/cloudexchange/cloudexchange/data
Sur le New nœud principal
- Accédez au répertoire de données :
cd /opt/cloudexchange/cloudexchange/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>
- 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
/opt/cloudexchange/cloudexchange:cd /opt/cloudexchange/cloudexchange
- Sur le nœud principal, copiez le contenu du fichier de clé CA :
/opt/cloudexchange/cloudexchange/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 /opt/cloudexchange/cloudexchange/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.