Migrer Cloud Exchange - Documentation technique Netskope

Cloud Exchange prend en charge ces options de migration :

Version CE actuelle	Chemin de migration
v5.1.1	v6.1.0
v5.1.2	v6.1.0
v6.0.0	v6.1.0
v6.0.1	v6.1.0

Before proceeding with the migration, identify your Cloud Exchange deployment type to ensure you follow the appropriate migration path. See How to Identify your Cloud Exchange Deployment Type.

Notes

Les clients utilisant Cloud Exchange version 3.x ou 4.x qui souhaitent migrer vers la dernière version, se référent à cet article de la base de données Cloud Exchange.
Les clients utilisant Cloud Exchange version 5.0.1 dans un déploiement conteneurisé et prévoyant de migrer vers la dernière version sont invités à consulter cet article de la base de connaissances Cloud Exchange.
Customers using Cloud Exchange version 5.0.1 in a VM deployment and planning to migrate to the latest version, refer to this Cloud Exchange KB article .

Déploiement en conteneur

Important

Contactez votre SE/AMsi vous avez des questions concernant l'installation, le déploiement, la configuration et la migration de Cloud Exchange.

Conditions préalables

Avant d'entamer la migration, assurez-vous que votre instance répond à la configuration requise pour Cloud Exchange.
Désactivez tous les plugins source dans tous les modules, puis attendez que les tâches en file d'attente soient terminées avant de procéder à la migration. Suivez ces étapes pour identifier les tâches en file d'attente mentionnées ci-dessous.
1. Après avoir désactivé les plugins source dans tous les modules, attendez 20 à 30 minutes.
2. Appliquer un filtre sur les journaux :
  1. Allez à la section Logging.
  2. Cliquez sur Filter Query.
  3. Dans l'entrée Filtres, entrez ce qui suit : message Like "Ingested " || message Like "Stored " || message Like "task(s)" || message Like "Completed storing"
  4. Cliquez sur Load.
  5. Appliquez le filtre pour afficher les journaux pertinents.
3. Surveillez les journaux : Une fois le filtre de journalisation appliqué, surveillez les journaux New. Si aucun journal New n'apparaît sous ce filtre, vous pouvez passer à l'étape suivante.
4. Après avoir migré vers la dernière version de l'EC en suivant les étapes mentionnées ci-dessous en fonction de votre déploiement actuel et de la version de l'EC, veuillez activer tous les plugins source précédemment désactivés.
Assurez-vous d'avoir le mot de passe de maintenance à portée de main, car il sera nécessaire pour effectuer certaines étapes de ce processus.

Important

Si le mot de passe de maintenance est perdu, les données ne peuvent pas être conservées.

Notes

La migration des données de RabbiMQ n'est pas prise en charge en raison du changement de type de file d'attente de Classic à Quorum.

Déploiement autonome

Vers la version 6.1.0 Extrait de la version 5.1.1, v5.1.2, v6.0.0, v6.0.1 utilisant un script (autonome)

Ce script est utilisé pour migrer vers le dernier Cloud Exchange Standalone. Ce script doit être exécuté sur la machine de destination (New).

Prerequisites for this script

Lors de la migration d'une machine conteneurisée, vous devez disposer des identifiants ssh (mot de passe root ou identifiants basés sur un fichier pem) de l'ancienne machine sur laquelle CE est installé.
Afin d'exécuter le script migrate_ce, vous devez avoir le dernier dépôt Cloud Exchange cloné sur la machine New.
Utilisez cette commande pour cloner le dernier dépôt Cloud Exchange :
```
git clone https://github.com/netskopeoss/ta_cloud_exchange
```

Steps

Dans la machine New, allez dans le répertoire où la dernière version de Cloud Exchange a été clonée et exécutez la commande ci-dessous pour copier et éditer le fichier de configuration de cloudexchange.
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Mettez à jour le fichier de configuration de cloudexchange avec les valeurs des champs obligatoires. Veillez également à configurer les champs facultatifs tels que la configuration du proxy, le port de l'interface utilisateur, etc. s'ils sont utilisés/personnalisés.
```
MAINTENANCE_PASSWORD=<old cloud exchange maintenance password>
JWT_SECRECT=<old cloud exchange JWT secret> (Optional, Setup script will generate new JWT secret if not provided)
```
Dans la machine New, exécutez la commande suivante :
```
sudo ./migrate_ce
```
À l'étape suivante, il vous demandera le nom d'utilisateur de l'ancienne machine, l'adresse IP de la machine, la méthode d'authentification et le mot de passe de l'utilisateur dans le cas d'une authentification basée sur l'utilisateur ou le chemin d'accès au fichier PEM dans le cas d'une authentification basée sur le fichier PEM.
Après une connexion réussie avec l'ancienne machine, ces commandes seront exécutées automatiquement afin de procéder à la migration :
1. It will execute Stop Script in old machine.
2. Il zippera les données existantes dans l'ancienne machine et les transférera sur la machine New.
3. Après un transfert réussi vers l'ordinateur New, le fichier sera décompressé dans le dossier du paquet d'installation actuel sur l'ordinateur New.
4. Maintenant, le script d'installation sera exécuté et vous demandera les données nécessaires à l'installation de Latest Cloud Exchange.
5. In the end, it will run the Start script.
Pour vérifier l'état du conteneur, exécutez la commande suivante :
sudo docker ps. Dans le cas de podman, utilisez sudo podman ps
Ouvrez maintenant l'interface utilisateur de Latest Cloud Exchange nouvellement migré dans le navigateur web. Connectez-vous avec les informations d'identification de l'interface utilisateur CE pour vérifier les configurations et les données et vous assurer que tout fonctionne correctement.

Déploiement HA

Vers la version 6.1.0 D’après la version 5.1.1, v5.1.2, v6.0.0, v6.0.1 Déploiement autonome

Avant de poursuivre, assurez-vous que toutes les conditions préalables ont été remplies. Il est essentiel de vérifier ces exigences à l'avance afin d'éviter tout problème potentiel au cours du processus.
Pour transférer les données de l'ancien système autonome vers le dernier système HA basé sur des conteneurs, il est nécessaire de copier les données de l'ancien système autonome et de les transférer vers le dernier nœud primaire HA.
Pour transférer les données copiées dans la configuration New HA, reportez-vous au guide de déploiement HA pour obtenir des instructions sur l'ajout des paramètres HA nécessaires et l'initialisation du cluster. Ce processus facilite la migration des données MongoDB vers l'ensemble de répliques. En outre, elle implique l'importation de messages RabbitMQ dans la machine New HA, avec l'intégration ultérieure d'autres nœuds dans le cluster.
Accédez au répertoire ta_cloud_exchange de la machine autonome actuelle.
```
cd ta_cloud_exchange
```
Arrêtez les conteneurs dans la machine autonome actuelle.
```
sudo ./stop
```
Allez dans le répertoire de données de la machine autonome actuelle.
```
cd data
```
Créez un fichier zip pour les données Mongo après avoir accédé au répertoire des données.
```
sudo zip -r ce_backup.zip mongo-data/ repos/ plugins/
```
Ajoutez des plugins personnalisés au fichier zip de sauvegarde. Cette étape ne s'applique que si vous utilisez des plugins personnalisés.
```
sudo zip -r ce_backup.zip custom_plugins
```
Copiez la sauvegarde sur l'instance New à l'aide de la commande scp.
```
sudo scp ce_backup.zip <username>@<ip-of-vm>:<ta_cloud_directory>/data
```
On Primary Node Only(the node you intend to designate as primary)
Allez sur le nœud New de la machine HA qui contient la dernière version de Cloud Exchange.
```
cd <ta_cloud_directory>/data
```

Extrayez les données dans des dossiers zippés.

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/

Retourne au répertoire de travail original.
```
cd ..
```
Copiez et éditez le fichier de configuration de cloudexchange en utilisant les commandes ci-dessous :
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Mettez à jour le fichier de configuration de cloudexchange avec les valeurs des champs obligatoires. Veillez également à configurer les champs facultatifs tels que la configuration du proxy, le port de l'interface utilisateur s'il est utilisé/personnalisé.
```
MAINTENANCE_PASSWORD=<old cloud exchange maintenance password>
JWT_SECRECT=<old cloud exchange JWT secret> (Optional, Setup script will generate new JWT secret if not provided)
```
Exécutez d'abord le script d'installation dans le nœud principal à l'aide de cette commande.
```
sudo python3 ./setup
```
Exécutez le script de démarrage à l'aide de la commande ci-dessous.
```
sudo ./start
```
Ensuite, ouvrez l'interface utilisateur du nœud principal dans votre navigateur web. Connectez-vous en utilisant vos identifiants Cloud Exchange existants. Vous pouvez accéder à l'interface utilisateur en utilisant l'adresse IP du système : https://<ip>:<port>
Accédez à Paramètres > Paramètres généraux > Configurations des nœuds et activez le bouton Enable HA . Une fenêtre pop-up Confirmer l’action apparaîtra. Saisissez l’adresse IP Cloud Exchange ou FQDN uniquement si vous devez la mettre à jour ; sinon, laissez-le inchangé et cliquez sur le bouton Activer HA.

Important

Pendant le processus d'activation de HA, Cloud Exchange sera temporairement indisponible et pourra redémarrer plusieurs fois.

On Secondary Nodes Only
Naviguez vers le répertoire ta_cloud_exchange nouvellement cloné à l'aide de la commande suivante :
```
cd <ta_cloud_exchange-dir>
```

Copiez la clé CA existante du nœud primaire situé à :

<ta_cloud_exchange-dir>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

Créez New CA key sur les nœuds secondaires à l'aide de la commande suivante :
```
vi /data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Collez la clé CA copiée depuis le nœud primaire à l'étape n° 20 et enregistrez le fichier. Cela permettra au serveur de gestion de communiquer entre le nœud New et le cluster HA.

Copiez et éditez le fichier de configuration de cloudexchange.

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

Update the cloudexchange configuration file with values for
```
JWT_SECRET=<JWT_SECRET value provided in primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Notes

Pour les nœuds secondaires, le secret JWT et la clé CA doivent être identiques à ceux du nœud principal. L'utilisation de secrets JWT ou de clés CA différents entraînera des erreurs d'authentification lors de l'ajout du nœud secondaire au cluster HA à partir de l'interface utilisateur du nœud primaire.

If you don’t recall the JWT Secret value of the primary node, generate and apply new JWT token by following the steps here.
Exécutez le script d'installation à l'aide de la commande ci-dessous.
```
sudo python3 ./setup
```
Ajoutez les nœuds secondaires un par un via l’interface CloudExchange du nœud principal dans les Paramètres > Paramètres généraux > section Configuration des nœuds.

Notes

Pour les nœuds secondaires, il n'est pas nécessaire d'exécuter manuellement le script de démarrage : il est automatiquement exécuté lors de l'ajout des nœuds secondaires via l'interface utilisateur CloudExchange du nœud principal au cours de l'étape 26.

Vers la version 6.1.0 D’après la version 5.1.1, v5.1.2, v6.0.0, v6.0.1 Déploiement HA

Avant de poursuivre, assurez-vous que toutes les conditions préalables ont été remplies. Il est essentiel de vérifier ces exigences à l'avance afin d'éviter tout problème potentiel au cours du processus.
Pour transférer les données de l'HA actuelle basée sur des conteneurs vers la dernière HA basée sur des conteneurs, il est nécessaire de faire une copie des données dans le nœud primaire de l'HA actuelle et de la transférer vers le dernier nœud primaire de l'HA conteneurisée.
Pour garantir un arrêt correct du conteneur, arrêtez les deux nœuds secondaires avant d'arrêter le nœud principal à l'aide de cette commande.
```
sudo ./stop
```
Copiez les données du nœud primaire. Créez un fichier zip pour les données Mongo après avoir accédé au répertoire des données.
```
cd <ta_cloud_exchange_directory_path>/data 
sudo zip -r ce_backup.zip mongo-data/
```
Allez sur le disque partagé pour copier le dossier des plugins et des dépôts. Pour la version 6.0.0 ou supérieure, le chemin du lecteur partagé sera /opt/shared/données/.
```
cd <shared_drive> 
sudo zip -r <ce_backup_zip_location>/ce_backup.zip repos/ plugins/
```
Cette étape ne s'applique que si vous utilisez des plugins personnalisés. Ajoutez des plugins personnalisés au zip de sauvegarde.
```
sudo zip -r <ce_backup_zip_location>/ce_backup.zip custom_plugins/
```
Pour que la migration réussisse, vous devez transférer les données du nœud primaire de la machine actuelle vers le nœud primaire de la machine New, qui dispose de la dernière version de Cloud Exchange.
```
sudo scp ce_backup.zip <username>@<ip-of-vm>:<ta_cloud_exchange_directory_path>/data
```
On Primary Node Only
Allez sur le nœud primaire de la machine New HA qui contient la dernière version de Cloud Exchange.
```
cd <ta_cloud_exchange_directory_path>/data
```

Extrayez les données dans des dossiers zippés, puis revenez au répertoire de travail d'origine.

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/
cd ..

Modifiez le fichier de configuration de cloudexchange.

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

Mettez à jour le fichier de configuration de cloudexchange avec les valeurs des champs obligatoires. Veillez également à configurer les champs facultatifs tels que la configuration du proxy, le port de l'interface utilisateur, etc. s'ils sont utilisés/personnalisés.

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> (Optional, Setup script will generate new JWT secret if not provided)

Exécutez le script d'installation à l'aide de la commande ci-dessous.
```
sudo python3 ./setup
```
Pour migrer les données Mongo, utilisez cette commande une seule fois.
```
sudo ./restore_ha_backup
```
Exécutez le script de démarrage à l'aide de la commande ci-dessous.
```
sudo ./start
```
Exécutez cette commande une fois que l'interface utilisateur est accessible. Si vous utilisez l'EC conteneurisé à la fois en mode autonome et en mode HA, utilisez l'option podman-compose au lieu de docker compose pour le système d'exploitation de base RHEL.

Sur les nœuds secondaires uniquement
Naviguez vers le répertoire ta_cloud_exchange nouvellement cloné à l'aide de la commande suivante :
```
cd <ta_cloud_exchange_directory_path>
```

Copiez la clé CA existante du nœud primaire situé à :

<ta_cloud_exchange_directory_path>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

Créez New CA key sur les nœuds secondaires à l'aide de la commande suivante :
```
vi /data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Collez la clé CA copiée depuis le nœud primaire et enregistrez le fichier. Cela permettra au serveur de gestion de communiquer entre le nœud New et le cluster HA.

Copiez et éditez le fichier de configuration de cloudexchange.

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

Update the cloudexchange configuration file with values for
```
JWT_SECRET=<JWT_SECRET value provided in primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Notes

Pour les nœuds secondaires, le secret JWT et la clé CA doivent être identiques à ceux du nœud principal. L'utilisation de secrets JWT ou de clés CA différents entraînera des erreurs d'authentification lors de l'ajout du nœud secondaire au cluster HA à partir de l'interface utilisateur du nœud primaire.

If you don’t recall the JWT Secret value of the primary node, generate and apply new JWT token by following the steps here.
Exécutez le script d'installation à l'aide de la commande ci-dessous.
```
sudo python3 ./setup
```
Ajoutez les nœuds secondaires un par un via l'interface utilisateur CloudExchange du nœud principal dans la section Paramètres > Paramètres généraux > " Configurations des nœuds ".

Notes

Pour les nœuds secondaires, il n'est pas nécessaire d'exécuter manuellement le script de démarrage : il est automatiquement exécuté lors de l'ajout des nœuds secondaires via l'interface utilisateur CloudExchange du nœud principal au cours de l'étape 22.

Déploiement de Cloud Exchange en tant que VM

Conditions préalables

Avant d'initier une migration, assurez-vous que votre instance répond aux exigences du système pour Cloud Exchange.
Pour Cloud Exchange en tant que VM, la connectivité à l'URL suivante est requise :
https://cloud-exchange-store.s3.us-east-1.amazonaws.com
Désactivez tous les plugins source dans tous les modules, puis attendez que les tâches en file d'attente soient terminées avant de procéder à la migration. Suivez ces étapes pour identifier les tâches en file d'attente mentionnées ci-dessous.
1. Après avoir désactivé les plugins source dans tous les modules, attendez 20 à 30 minutes.
2. Appliquer un filtre sur les journaux :
  1. Allez à la section Logging.
  2. Cliquez sur Filter Query.
  3. Dans l'entrée Filtres, entrez ce qui suit : message Like "Ingested " || message Like "Stored " || message Like "task(s)" || message Like "Completed storing"
  4. Cliquez sur Load.
  5. Appliquez le filtre pour afficher les journaux pertinents.
3. Surveillez les journaux : Une fois le filtre de journalisation appliqué, surveillez les journaux New. Si aucun journal New n'apparaît sous ce filtre, vous pouvez passer à l'étape suivante.
4. Après avoir migré vers la dernière version de l'EC en suivant les étapes mentionnées ci-dessous en fonction de votre déploiement actuel et de la version de l'EC, veuillez activer tous les plugins source précédemment désactivés.
Assurez-vous d'avoir le mot de passe de maintenance à portée de main, car il sera nécessaire pour effectuer certaines étapes de ce processus.

Important

Si le mot de passe de maintenance est perdu, les données ne peuvent pas être conservées.

Notes

La migration des données de RabbiMQ n'est pas prise en charge en raison du changement de type de file d'attente de Classic à Quorum.

Les clients exécutant CE en tant que VM (OVA ou Hyper-V) sur des versions antérieures à 5.1.1 auront besoin d'identifiants root.
Nom d'utilisateur : root
Mot de passe : M5#w6V+.T^8gv?%,

Les clients Azure et AWS CE as VM peuvent passer à la dernière version de Cloud Exchange en suivant les étapes suivantes.

Déploiement autonome

Vers la version 6.1.0 Extrait de la version 5.1.1, v5.1.2, v6.0.0, v6.0.1 Standalone Deployment utilisant un script

Ce script est utilisé pour migrer vers la dernière version de Cloud Exchange Standalone. Ce script doit être exécuté sur la machine de destination (New).

Prerequisites for this script

Lors de la migration de CE en tant que machine VM, le script fonctionnera avec le mot de passe de l'utilisateur cteadmin.

Steps

Dans New CE en tant que machine VM, allez dans le dossier /opt/cloudexchange/cloudexchange et exécutez la commande ci-dessous pour copier et modifier le fichier de configuration de cloudexchange.
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Mettez à jour le fichier de configuration de cloudexchange avec les valeurs des champs obligatoires. Veillez également à configurer les champs facultatifs tels que la configuration du proxy, le port de l'interface utilisateur, etc. s'ils sont utilisés/personnalisés.
```
MAINTENANCE_PASSWORD=<old cloud exchange maintenance password>
JWT_SECRECT=<old cloud exchange JWT secret> (Optional, Setup script will generate new JWT secret if not provided)
```
Dans le New CE en tant que machine VM, allez dans le répertoire où la dernière version de Cloud Exchange est déployée et exécutez cette commande :
```
sudo ./migrate_ce
```
Dans l'étape suivante, il vous demandera le nom d'utilisateur de l'ancienne machine, l'adresse IP de la machine et le mot de passe de l'ancienne machine ou le chemin d'accès au fichier PEM dans le cas d'un fichier PEM.
Après une connexion réussie avec l'ancienne machine, ces scripts seront exécutés automatiquement afin de procéder à la migration :
1. Il exécutera Stop Script.
2. Il zippera les données existantes dans l'ancienne machine et les transférera sur la machine New.
3. Après un transfert réussi vers l'ordinateur New, le fichier sera décompressé dans le dossier souhaité sur l'ordinateur New.
4. Maintenant, le script d'installation va s'exécuter et vous demandera les données nécessaires pour mettre en place la dernière version de Cloud Exchange.
5. In the end, it will run the Start script.
6. Pour vérifier l'état du conteneur, exécutez la commande suivante :
  sudo docker ps. Dans le cas de podman, utilisez sudo podman ps)
7. Ouvrez maintenant l'interface utilisateur de la dernière version de Cloud Exchange qui vient d'être migrée dans le navigateur Web. Connectez-vous avec les anciens identifiants de CE pour vérifier les configurations et les données et vous assurer que tout fonctionne correctement.

Déploiement HA

Vers la version 6.1.0 D’après le verset 5.1.1, v5.1.2, v6.0.0, v6.0.1 Déploiement autonome

Avant de poursuivre, assurez-vous que toutes les conditions préalables ont été remplies. Il est essentiel de vérifier ces exigences à l'avance afin d'éviter tout problème potentiel au cours du processus.
Pour transférer les données de l'ancienne station autonome vers le dernier CE en tant que HA basé sur VM, il est nécessaire de copier les données de l'ancienne station autonome et de les transférer vers le dernier nœud primaire HA.
Pour transférer les données copiées dans la configuration New HA, reportez-vous au guide de déploiement HA pour obtenir des instructions sur l'ajout des paramètres HA nécessaires et l'initialisation du cluster. Ce processus facilite la migration des données MongoDB vers l'ensemble de répliques. En outre, elle implique l'importation de messages RabbitMQ dans la machine New HA, avec l'intégration ultérieure d'autres nœuds dans le cluster. Assurez-vous que le répertoire /opt/shared/données est disponible pour CE afin de stocker les ressources partagées entre les nœuds du cluster.
Allez dans le répertoire des paquets d’installation CE. (Pour CE en tant que VM, allez sur /opt/cloudexchange/cloudexchange/)
Arrêtez le CE en tant que VM dans la machine autonome actuelle.
```
sudo ./stop
```
Allez dans le répertoire de données de la machine autonome actuelle.
```
cd data
```
Créez un fichier zip pour les données Mongo après avoir accédé au répertoire des données.
```
sudo zip -r ce_backup.zip mongo-data/ repos/ plugins/
```
Ajoutez des plugins personnalisés au fichier zip de sauvegarde. Cette étape ne s'applique que si vous utilisez des plugins personnalisés.
```
sudo zip -r ce_backup.zip custom_plugins
```
Copiez la sauvegarde sur l'instance basée sur le cloud New à l'aide de la commande scp.
```
sudo scp -i <public_key> ce_backup.zip <username>@<public_ip>:/opt/cloudexchange/cloudexchange/data
```
On Primary Node Only(the node you intend to designate as primary)
Allez sur le nœud New de la machine HA qui contient la dernière version de Cloud Exchange.
```
cd /opt/cloudexchange/cloudexchange/data
```

Extrayez les données dans des dossiers zippés.

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/

Retournez dans le répertoire de travail d'origine.
```
cd ..
```
Copiez et éditez le fichier de configuration de cloudexchange en utilisant les commandes ci-dessous :
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Mettez à jour le fichier de configuration de cloudexchange avec les valeurs des champs obligatoires. Veillez également à configurer les champs facultatifs tels que la configuration du proxy, le port de l'interface utilisateur, etc. s'ils sont utilisés/personnalisés.
```
MAINTENANCE_PASSWORD=<old cloud exchange maintenance password>
JWT_SECRECT=<old cloud exchange JWT secret> (Optional, Setup script will generate new JWT secret if not provided)
```
Exécutez d'abord le script d'installation dans le nœud principal à l'aide de cette commande.
```
sudo python3 ./setup
```
Exécutez le script de démarrage à l'aide de la commande ci-dessous.
```
sudo ./start
```
Ensuite, ouvrez l'interface utilisateur du nœud principal dans votre navigateur web. Connectez-vous en utilisant vos identifiants Cloud Exchange existants. Vous pouvez accéder à l'interface utilisateur en utilisant l'adresse IP du système : https://<ip>:<port>

On Secondary Nodes Only
Naviguez jusqu'au répertoire /opt/cloudexchange/cloudexchange à l'aide de la commande suivante :
```
cd /opt/cloudexchange/cloudexchange
```

Copiez la clé CA existante du nœud primaire situé à :

/opt/cloudexchange/cloudexchange/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

Créez New CA key sur les nœuds secondaires à l'aide de la commande suivante :
```
vi /data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Collez la clé de l'autorité de certification copiée depuis le nœud primaire à l'étape n° 19 et enregistrez le fichier. Cela permettra au serveur de gestion de communiquer entre le nœud New et le cluster HA.

Copiez et éditez le fichier de configuration de cloudexchange.

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

Update the cloudexchange configuration file with values for
```
JWT_SECRET=<JWT_SECRET value provided in primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Notes

Pour les nœuds secondaires, le secret JWT et la clé CA doivent être identiques à ceux du nœud principal. L'utilisation de secrets JWT ou de clés CA différents entraînera des erreurs d'authentification lors de l'ajout du nœud secondaire au cluster HA.

If you don’t recall the JWT Secret value of the primary node, generate and apply new JWT token by following the steps here.
Exécutez le script d'installation à l'aide de la commande ci-dessous.
```
sudo python3 ./setup
```
Allez à Settings > General Settings > Node Configurations et activez le bouton Enable HA . Une fenêtre pop-up Confirmer l’action apparaîtra. Saisissez l'adresse IP ou le nom de domaine complet (FQDN) de Cloud Exchange uniquement si vous devez la mettre à jour ; sinon, laissez-la inchangée et cliquez sur le bouton Activer la haute disponibilité.

Important

Pendant le processus d'activation de HA, Cloud Exchange sera temporairement indisponible et pourra redémarrer plusieurs fois.
Ajoutez les nœuds secondaires un par un via l’interface CloudExchange du nœud principal dans les Paramètres > Paramètres généraux > section Configuration des nœuds.

Notes

Pour les nœuds secondaires, il n’est pas nécessaire d’exécuter manuellement le script de démarrage. Il est automatiquement exécuté lors de l’ajout des nœuds secondaires via l’interface CloudExchange du nœud principal lors de l’étape 26.

Vers la version 6.1.0 D’après la version 5.1.1, v5.1.2, v6.0.0, v6.0.1 Déploiement HA

Avant de poursuivre, assurez-vous que toutes les conditions préalables ont été remplies. Il est essentiel de vérifier ces exigences à l'avance afin d'éviter tout problème potentiel au cours du processus.
Pour transférer les données de l'EC actuel en tant qu'HA basé sur VM vers l'EC le plus récent en tant qu'HA basé sur VM, il est nécessaire de faire une copie des données dans le nœud primaire de l'HA actuel et de les transférer vers le nœud primaire de l'EC le plus récent en tant qu'HA basé sur VM.
Pour garantir un bon CE lors de l'arrêt de la VM, arrêtez les deux nœuds secondaires, puis le nœud primaire à l'aide de la commande ci-dessous :
```
sudo ./stop
```
Copiez les données du nœud primaire. Créez un fichier zip pour la base de données Mongo située dans le répertoire data.
```
cd /opt/cloudexchange/cloudexchange/data 
sudo zip -r ce_backup.zip mongo-data/
```
Allez sur le disque partagé pour copier le dossier des plugins et des dépôts. À partir de la version 6.0.0 de CE, l'emplacement du lecteur partagé sera /opt/shared/données/.
```
cd <shared_drive>
sudo zip -r <ce_backup_zip_location>/ce_backup.zip repos/ plugins/
```
Cette étape ne s'applique que si vous utilisez des plugins personnalisés. Ajoutez des plugins personnalisés au zip de sauvegarde.
```
sudo zip -r <ce_backup_zip_location>/ce_backup.zip custom_plugins/
```
Pour que la migration réussisse, vous devez transférer les données du nœud primaire de la machine actuelle vers le nœud primaire de la machine New, qui dispose de la dernière version de Cloud Exchange.
```
sudo scp -i <public_key> ce_backup.zip <username>@<public_ip>:/opt/cloudexchange/cloudexchange/data
```
On Primary Node Only
Allez sur le nœud primaire de la machine New HA qui contient la dernière version de Cloud Exchange.
```
cd /opt/cloudexchange/cloudexchange/data
```

Extrayez les données dans des dossiers zippés, puis revenez au répertoire de travail d'origine.

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/
cd ..

Modifiez le fichier de configuration de cloudexchange.

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

Mettez à jour le fichier de configuration de cloudexchange avec les valeurs des champs obligatoires. Veillez également à configurer les champs facultatifs tels que la configuration du proxy, le port de l'interface utilisateur, etc. s'ils sont utilisés/personnalisés.
```
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 d'installation à l'aide de la commande ci-dessous.
```
sudo python3 ./setup
```
Pour migrer les données Mongo, utilisez cette commande une seule fois.
```
sudo ./restore_ha_backup
```
Exécutez le script de démarrage à l'aide de la commande ci-dessous.
```
sudo ./start
```
Exécutez cette commande une fois que l'interface utilisateur du nœud primaire sera accessible.

On Secondary Nodes Only
Va dans le répertoire /opt/cloudexchange/cloudexchange nouvellement cloné en utilisant la commande suivante :
```
cd /opt/cloudexchange/cloudexchange
```

Copiez la clé CA existante du nœud primaire situé à :

/opt/cloudexchange/cloudexchange/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

Créez New CA key sur les nœuds secondaires à l'aide de la commande suivante :
```
vi /data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Collez la clé CA copiée depuis le nœud primaire et enregistrez le fichier. Cela permettra au serveur de gestion de communiquer entre le nœud New et le cluster HA.

Copiez et éditez le fichier de configuration de cloudexchange.

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

Update the cloudexchange configuration file with values for
```
JWT_SECRET=<JWT_SECRET value provided in primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Notes

Pour les nœuds secondaires, le secret JWT et la clé CA doivent être identiques à ceux du nœud principal. L'utilisation de secrets JWT ou de clés CA différents entraînera des erreurs d'authentification lors de l'ajout du nœud secondaire au cluster HA à partir de l'interface utilisateur du nœud primaire.

If you don’t recall the JWT Secret value of the primary node, generate and apply new JWT token by following the steps here.
Exécutez le script d'installation à l'aide de la commande ci-dessous.
```
sudo python3 ./setup
```
Ajoutez les nœuds secondaires un par un via l’interface CloudExchange du nœud principal dans les Paramètres > Paramètres généraux > section Configuration des nœuds.

Notes

Pour les nœuds secondaires, il n'est pas nécessaire d'exécuter manuellement le script de démarrage : il est automatiquement exécuté lors de l'ajout des nœuds secondaires via l'interface utilisateur CloudExchange du nœud principal au cours de l'étape 22.