Ce document décrit le fonctionnement de la Haute Disponibilité (HA) dans Cloud Exchange. Après avoir examiné la liste des fonctionnalités du schéma architectural, les conditions préalables et les directives de dimensionnement, déployez HA dans Cloud Exchange. Après la section sur le déploiement, des sections expliquent la migration, la mise à niveau, le durcissement, les limitations connues et le dépannage.
Architecture HA
Features
- Configurations actives-actives pour les nœuds de Cloud Exchange, améliorant la disponibilité du système et la tolérance aux pannes.
- Le conteneur Cloud Exchange Core est conçu pour fonctionner comme un travailleur dédié capable de gérer plusieurs tâches simultanément. Pour une installation de taille moyenne, il peut gérer 10 tâches, tandis qu'une installation de grande taille permet d'en gérer 20. Ces tâches peuvent inclure des opérations telles que l'interrogation, l'ingestion et la surveillance des battements de cœur. Dans une grappe à haute disponibilité (HA) à trois nœuds, la puissance de traitement est effectivement triplée, ce qui améliore la capacité d'exécution du système.
- L'attribution des tâches est coordonnée par RabbitMQ, qui distribue les tâches aux travailleurs du conteneur principal en fonction de leur charge actuelle et du nombre de tâches qu'ils traitent activement. En cas de redémarrage d'un conteneur central ou de défaillance d'un nœud, les tâches de transformation et d'ingestion sont remises en attente afin de garantir qu'aucune donnée n'est perdue. Pendant ce temps, les tâches de récupération des données sont réaffectées à un autre nœud, généralement dans les cinq minutes qui suivent la panne, en fonction de la charge de travail du nœud New.
- Pour l'encapsuler, le conteneur principal est conçu avec une HA au niveau des tâches et au niveau des nœuds afin de garantir un fonctionnement continu et l'intégrité des données.
- Dans un cluster, il y aura plusieurs instances de MongoDB et de RabbitMQ. Si un nœud tombe en panne, les autres nœuds continueront à répondre aux demandes, ce qui garantit un temps d'arrêt nul.
- Les multiples nœuds identiques de Cloud Exchange fonctionneront simultanément. Et tous traitent activement et simultanément des tâches de plugin.
Pour regarder une vidéo sur la configuration de Cloud Exchange HA, cliquez sur lecture.
Pour regarder une vidéo sur le fonctionnement du basculement HA de Cloud Exchange, cliquez sur lecture.
Tableau de bord de l'interface utilisateur pour l'état des clusters
Vérifiez l'état actuel du cluster sur la page d'accueil de Cloud Exchange.
Le service Core dépend des services UI. Pour des raisons de sécurité, nous ne rendons pas le service de base public. Le service Core sera accessible par le service UI, et il sera accessible par un réseau interne. Si le service de l'interface utilisateur est en panne, le tableau de bord affichera un état inconnu.
Remarques importantes
- If you are transitioning from a standalone configuration to a High Availability (HA) setup, you should know your maintenance password, as it is required to migrate the Mongo data into the new setup.
- Si vous utilisez Cloud Exchange comme une VM, vérifiez ce point et changez le nom d’hôte en conséquence.
Assurez-vous que toutes les machines ont des noms d’hôte différents. Utilisez cette commande pour changer le nom d’hôte d’une machine particulière.sudo hostnamectl set-hostname <new_hostname>
- Assurez-vous que chaque machine peut se connecter aux ports énumérés ci-dessous sur chaque machine, y compris la machine elle-même. La raison d'inclure la machine actuelle est que les appels API seront faits à l'adresse IP du serveur, et l'appel API sera fait à partir de l'intérieur du conteneur docker. La connectivité du port à l'aide de l'adresse IP doit donc être autorisée. Les politiques de pare-feu pour ces ports listés et toutes les machines doivent être configurées pour assurer une connexion transparente entre les machines.
- 4369 (Un service de découverte de pairs utilisé par les nœuds RabbitMQ et les outils CLI)
- 8000
- 5671 (utilisé par les clients AMQP 0-9-1 et AMQP 1.0 sans TLS)
- 15671 (clients API HTTP, interface de gestion et rabbitmqadmin sans TLS)
- 25672 (utilisé pour la communication entre l'internode et les outils CLI)
- 35672 (utilisé pour la communication avec les outils CLI)
- 27017 (Le port par défaut pour les instances mongod et mongos.)
- Port de l'interface utilisateur sélectionné (par défaut 443 pour HTTPS et 80 pour HTTP) (pour accéder à l'interface utilisateur et au contrôle de santé de l'internode)
- 24007-24029 (ports GlusterFS utilisés pour la communication entre nœuds, les contrôles de santé, le démon auto-soignant, la communication en brique)
Si vous utilisez Cloud Exchange en tant que VM,
firewalld est déjà installé et désactivé par défaut. Vous devrez activer le pare-feu en exécutant ces commandes et en redémarrant le service Docker.sudo systemctl enable firewalld
sudo systemctl start firewalld
sudo systemctl restart docker
Exemple de commande pour ouvrir le port 443 à l'aide d'un pare-feu :
sudo firewall-cmd --permanent --add-port=443/tcp
Ces ports seront utilisés pour la mise en cluster des services MongoDB et RabbitMQ. Les ports de l'interface utilisateur doivent également effectuer un contrôle de l'état de santé de toutes les machines.
Déployer HA dans Cloud Exchange
Mise en place d'un nœud primaire
- Clonez le dépôt Github
netskopeoss/ta_cloud_exchangesur toutes les machines où Netskope CE sera déployé :mkdir netskope cd netskope git clone https://github.com/netskopeoss/ta_cloud_exchange cd ta_cloud_exchange
Si vous avez déjà cloné le repo, supprimez tous les changements locaux et récupérez la dernière version.
git reset --hard
git pullCheckout the Desired Version. Before proceeding, checkout the desired version of the repository. For example, to checkout version 6.1.0.
git checkout v6.1.0
Si vous utilisez CE en tant que VM, le répertoire sera disponible sur le chemin
/opt/cloudexchange/cloudexchange. Changez le répertoire actuel pour le répertoirecloudexchange.cd /opt/cloudexchange/cloudexchange
- (facultatif) Copiez et modifiez le fichier
cloudexchange.config.cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
- Les mots de passe de maintenance et JWT Secret sont utilisés en interne dans Cloud Exchange pour l'authentification de la base de données. Ces mots de passe seront nécessaires lors de la restauration d'une sauvegarde.
- Non‑ASCII characters (e.g., accented letters, other scripts, emoji) are not supported for the Maintenance and JWT Secret Password, some of the processes might not work and might cause system failures if you use these special characters.
- Modifiez les variables en fonction de vos besoins et enregistrez le fichier. Exécutez ensuite la commande suivante :
sudo systemctl stop cloud-exchange && sudo systemctl disable cloud-exchange
- Exécutez la configuration.
sudo ./setup
- Exécutez start pour démarrer l'instance autonome.
sudo ./start
- Une fois le nœud en ligne, allez à Settings > General > Node Configuration.
- Cliquez sur Enable HA et confirmez votre choix. Observez les journaux diffusés. Lors de l'activation de la haute disponibilité, le nœud redémarrera une fois.
Une fois le nœud opérationnel, vérifiez l'état des services RabbitMQ, MongoDB, Core et UI.
Mise en place d'un nœud secondaire
- Copiez la clé secrète JWT depuis le nœud principal. Si vous ne vous souvenez pas de la valeur JWT Secret du nœud principal, générez et appliquez New jeton JWT en suivant les étapes ici.
- Clonez le dépôt public Github
netskopeoss/ta_cloud_exchange. - Checkout the Desired Version. Before proceeding, checkout the desired version of the repository. For example, to checkout version 6.1.0, Skip this three steps if you are using CE as a VM image (go to
/opt/cloudexchange/cloudexchangepath for CE as a VM Image).
git checkout v6.1.0
- Dans le nœud secondaire, dans le dossier où le référentiel
cloudexchangeest cloné, modifiez le fichiercloudexchange.configet mettez à jour la clé JWT Secret du nœud primaire.
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
sudo systemctl stop cloud-exchange && sudo systemctl disable cloud-exchange
- Copiez la clé de l'autorité de certification existante à partir de
ta_cloud_exchange/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.keydu nœud principal. - Collez-le sur le même chemin sur le nœud secondaire. Le nom du fichier doit être exactement le même que le
tls_cert_ca.key. - Exécutez l'installation sur le nœud secondaire. Une fois l'installation terminée sur un nœud New, les certificats New pour ce nœud seront générés et signés par une autorité de certification existante, ce qui permettra au serveur de gestion de communiquer entre le nœud New et le cluster HA.
sudo ./setup
Ajouter des nœuds secondaires au cluster HA
- Une fois le script de configuration exécuté avec succès dans tous les nœuds, connectez-vous au nœud principal et accédez à Settings > General > Node Configurations (Paramètres Généralités Configurations des nœuds).
- Cliquez sur le bouton Ajouter un nœud New et entrez le FQDN/l'adresse IP du nœud New.
- Cliquez sur l’icône + à côté du nœud New pour l’ajouter en tant que nœud New .
Observez les journaux diffusés. En ajoutant un nœud New , le nœud principal redémarre également.
Gestion des nœuds HA
- Pour ajouter un New nœud secondaire à un cluster, allez à Settings > General > Node Configurations.
- Cliquez sur Add et fournissez l’adresse IP du nœud secondaire, puis cliquez sur l’icône ajouter (+).
- Utilisez l'icône Arrêter située à côté du nœud pour arrêter un nœud.
- L’utilisateur peut également consulter le nœud historique pour le processus de configuration du nœud en utilisant l’icône Journaux .
- Utilisez l'icône Supprimer pour retirer un nœud secondaire du cluster.
- De même, utilisez l'icône Redémarrer pour redémarrer n'importe quel nœud depuis l'interface utilisateur de Cloud Exchange.
Si vous souhaitez repasser en mode autonome, regardez cette vidéo pour savoir comment procéder.
Lignes directrices sur le durcissement
- Afin d'établir la connectivité nécessaire entre les services Docker sur différentes machines et de faciliter l'intégration des nœuds dans le cluster, nous avons exposé les ports listés ci-dessous à partir des services Docker. Il est impératif que ces ports restent accessibles depuis toutes les machines où le déploiement de Cloud Exchange HA est prévu. Pour renforcer les mesures de sécurité, il est également conseillé de restreindre l'accès à ces ports à partir d'autres adresses IP.
Ces ports seront utilisés pour la mise en cluster des services MongoDB et RabbitMQ. Les ports de l'interface utilisateur doivent également effectuer un contrôle de l'état de santé de toutes les machines.- 4369 (Un service de découverte de pairs utilisé par les nœuds RabbitMQ et les outils CLI)
- 5672 (utilisé par les clients AMQP 0-9-1 et AMQP 1.0 sans TLS)
- 15672 (clients API HTTP, interface de gestion et rabbitmqadmin sans TLS)
- 25672 (utilisé pour la communication entre les nœuds et les outils CLI)
- 35672 (utilisé pour la communication avec les outils CLI)
- 27017 (Le port par défaut pour les instances mongodb et mongos)
- Port de l'interface utilisateur sélectionné (par défaut 443 pour HTTPS et 80 pour HTTP) (pour accéder à l'interface utilisateur et au contrôle de santé de l'internode)
- L'installation et la configuration de GlusterFS se feront par l'intermédiaire de l'interface utilisateur et du serveur de gestion de Cloud Exchange, qui servira de stockage partagé et aura également des capacités HA. Toutes les machines virtuelles impliquées dans le cluster HA doivent être connectées à la base de données GlusterFS lors de la configuration HA.
Exigences relatives au nombre de nœuds de la grappe
Dans le cadre des exigences de réplication MongoDb et de miroir RabbitMQ en cas de panne, il est crucial de s'assurer que le cluster HA reste opérationnel avec la majorité des nœuds Cloud Exchange ACTIFS/ EN LIGNE. Un cluster HA avec un nombre impair de nœuds Cloud Exchange a plus de chances de rester opérationnel qu'un cluster avec un nombre pair de nœuds Cloud Exchange.
| Nombre total de nœuds CE dans un cluster HA. | Nombre minimum de nœuds d'EC ACTIFS/ EN LIGNE requis dans un cluster HA à tout moment pour un fonctionnement réussi. |
|---|---|
| 3 | 2 |
| 4 | 3 |
| 5 | 3 |
| 6 | 4 |
| 7 | 4 |
| 8 | 5 |
| 9 | 5 |
Limites
- Vous devez vous assurer de la connectivité à la base de données GlusterFS lors de l'installation de HA.
- L'exécution de plusieurs instances redondantes de Cloud Exchange nécessite du matériel et des ressources informatiques supplémentaires.
- Dans certains cas, les configurations HA peuvent entraîner une augmentation de la latence en raison de la nécessité de répliquer les données ou de coordonner entre les instances actives.
- Lorsque des modifications sont apportées aux adresses IP ou aux configurations liées aux nœuds, il est nécessaire d'exécuter les scripts d'installation et de démarrage sur toutes les machines du système afin de s'assurer que les modifications sont correctement propagées et synchronisées à travers le cluster. Il est recommandé d'ajouter toutes les machines nécessaires en une seule fois et d'utiliser des adresses IP fixes pour les machines.
- Il est crucial de maintenir la majorité des nœuds opérationnels en permanence, car tout manquement à cette règle entraînerait une défaillance du cluster. Par exemple, dans un cluster à 3 nœuds, au moins 2 nœuds doivent être opérationnels à tout moment ; de même, dans un cluster à 5 nœuds, au moins 3 nœuds doivent être en fonctionnement. Le même schéma se répète pour les groupes plus importants. En effet, MongoDB ne lancera pas le processus d'élection primaire dans de telles circonstances. De plus, nous avons implémenté une option pause_minority pour RabbitMQ afin d'atténuer les problèmes liés aux incohérences induites par les partitions réseau. Le problème devrait se résoudre une fois que le nœud sera de nouveau opérationnel et connecté au cluster. Consultez la section « Nombre minimal de nœuds requis pour un cluster » pour connaître le nombre minimal de nœuds opérationnels nécessaires.
Référence : https://www.mongodb.com/docs/v5.0/core/replica-set-elections/#network-partition | https://www.rabbitmq.com/partitions.html#options - Dans de rares cas, lorsqu'un cluster subit des défaillances successives de nœuds, il existe un risque de perte de données dans RabbitMQ car la file d'attente devient fréquemment leader et se duplique. Dans ce cas, les autres nœuds peuvent perdre les données qui ne sont pas encore synchronisées.
Réf. : https://www.rabbitmq.com/ha.html#behaviour - Pour utiliser le SSO, nous ne pourrons ajouter que l'adresse IP d'un seul nœud comme URL de redirection. En option, nous pouvons configurer l'équilibreur de charge pour toutes les adresses IP et utiliser l'adresse IP de l'équilibreur de charge pour configurer le SSO. Il redirigera la demande vers n'importe quel nœud disponible.
Dépannage de HA dans Cloud Exchange
- Le script
./stopdans HA supprimera le nœud MongoDB et RabbitMQ du cluster. Et arrêtez les services sur cette machine. Il est essentiel que les services soient activés lors de l'exécution de la commande ./stop le scénario. Sinon, le script risque d'échouer car il ne pourra pas créer le client Mongo pour supprimer le nœud. - Au cours de la migration, si vous rencontrez des problèmes avec le renommage des nœuds, vérifiez les conditions préalables et restaurez la sauvegarde de la première étape. Réessayez ensuite la migration à partir de la deuxième étape.
sudo rm -rf <path-to-ta_cloud_exchange>/data/mongo-data/data/* sudo cp -R <temp-mongo-path>/*
<path-to-ta_cloud_exchange>/data/mongo-data/data/ - Assurez-vous que les services docker/podman sont en cours d'exécution. Si ce n'est pas le cas, exécutez les services à l'aide de la commande suivante
sudo systemctl restart docker
- Si l'interface utilisateur affiche un état d'arrêt pour un conteneur pendant une longue période, vérifiez l'état du conteneur et redémarrez-le si nécessaire. Utilisez le podman chaque fois que c'est possible.
- Vérifiez l'état du conteneur. Si tous les services fonctionnent, passez à l'étape suivante. Sinon, exécutez à nouveau le script de démarrage pour récupérer le conteneur.
docker ps
- Vérifiez l'état du cluster MongoDB. Exécutez ces commandes pour lancer la commande à l'intérieur du conteneur MongoDB.
docker compose exec -- mongodb-primary bash mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD rs.status()
Si l'état indique autre chose que PRIMARY et SECONDARY pendant une longue période, exécutez cette commande pour redémarrer le conteneur sur une machine spécifique.
docker compose restart mongodb-primary
- Vérifiez l'état du cluster RabbitMQ. Exécutez ces commandes pour lancer la commande à l'intérieur du conteneur RabbitMQ.
docker compose exec -- rabbitmq-stats bash rabbitmqctl cluster_status
Vérifiez la section des nœuds en cours d'exécution dans la sortie et déterminez les nœuds connectés et en cours d'exécution. Redémarrez le conteneur RabbitMQ si nécessaire.
docker compose restart rabbitmq-stats
- Vérifiez l'état du conteneur. Si tous les services fonctionnent, passez à l'étape suivante. Sinon, exécutez à nouveau le script de démarrage pour récupérer le conteneur.
- Si un nœud est victime d'une erreur de perte de travailleur, par exemple si le travailleur n'est pas connecté à RabbitMQ, redémarrez le conteneur central spécifique pour récupérer les travailleurs. Ce problème est susceptible de se produire lorsque le cluster RabbitMQ est arrêté pendant une longue période.
docker compose restart core
- Erreurs d'installation de GlusterFS lors du démarrage de Cloud Exchange : Lors de l'exécution du script de démarrage, si vous voyez l'erreur failed to install glusterfs, vous pouvez ignorer cette erreur si vous souhaitez utiliser Cloud Exchange comme une instance autonome et n'avez pas besoin d'activer un cluster HA. Si vous souhaitez utiliser le clustering HA, assurez-vous que l'environnement dispose d'une connectivité au repo GlusterFS et suivez les étapes de cette documentation Mise à niveau d'un OS sous-jacent de Cloud Exchange sur une VM.