Déploiement Docker

Exigences Logicielles

• Docker CE 19+ ou Docker EE équivalent

Installation

• Récupérez l'image docker en ligne ou chargez l'image docker hors ligne
  
  • En ligne : docker pull [docker url]/tag:version
    
  • Hors ligne : docker load -i < 'fichier image docker' >
• Récupérez l'ID de l'image docker : docker images
• Démarrez le conteneur docker

docker run -itd --net=host 
-v <absolute_path_to_data_folder>:/opt/ultipa-server/data 
-v <absolute_path_to_config_folder>:/opt/ultipa-server/config 
-v <absolute_path_to_log_folder>:/opt/ultipa-server/log 
-v <absolute_path_to_mlog_folder>:/opt/ultipa-server/mlog 
-v <absolute_path_to_algo_folder>:/opt/ultipa-server/algo 
-e TZ=Europe/Paris 
--name ultipa-server --ulimit nofile=90000:90000 --privileged `image ID`
docker exec -it ultipa-server bash 
start

Docker signalera une erreur 'No config files found' lors du premier démarrage, tout en créant automatiquement un fichier exemple nommé example.config. Copiez et renommez example.config en server.config, et modifiez ce fichier en suivant la Configuration du Serveur (voir ci-dessous) avant de redémarrer.

• Options de la commande docker run
  
  • Définir le fuseau horaire : -e TZ=Europe/Paris
    
  • Augmenter la limite du nombre de fichiers ouverts : -ulimit nofile=90000:90000 --privileged
    
  • Activer le débogage GDB : --cap-add=SYS_PTRACE --security-opt seccomp=unconfined
• Raisons courantes pour lesquelles docker ne démarre pas

Déploiement en Cluster

• Préparez les machines du cluster, vérifiez l'IP et le port pour la communication interne et les services externes, assurez-vous que chaque machine peut accéder aux ports privés des autres machines.
• Il est recommandé d'utiliser ultipa_doctor_linux_v4.0 gen_config pour générer un fichier de configuration de cluster, puis copier le fichier sur la machine correspondante, comme détaillé dans la documentation Ultipa Doctor 4.0. Vous pouvez également configurer le cluster manuellement.
• Installez ultipa-server sur chaque machine en utilisant Docker et démarrez le service pour toutes les machines.
• Vérifiez les points suivants une fois le déploiement terminé :
  1. Vérification du processus. Chaque machine doit avoir le processus ultipa-server. Si ce n’est pas le cas, localisez le problème en vérifiant le journal du serveur et le journal htap.
  2. Vérification du statut du cluster. Il est recommandé d'utiliser ultipa_doctor_linux_v4.0 health_check comme détaillé dans la documentation Ultipa Doctor 4.0. Vous pouvez également utiliser curl http://private_addr:private_ip/raft_admin, le cluster est déployé avec succès si le Leader est élu normalement.
  3. Utilisez Ultipa Manager (si disponible) pour vérifier si le cluster est bien affiché.
  4. Importez des données de test. Entrez dans le conteneur ultipa-server à partir de n'importe quelle machine pour exécuter l'importation : cd example && sh import_example.sh.
• Remarque : Lorsqu'un nouveau cluster est déployé, les données initiales de chaque instance doivent être vides, et ne pas copier le catalogue de données dans un environnement de production !

Configuration du Serveur

Chemin du Fichier de Configuration

config/server.config

Configuration Globale

section:[Server]

Configuration des Journaux

section:[Log]

Configuration du Superviseur

section:[Supervisor]

Configuration de la Persistance

section:[BaseDB]

Configuration du Moteur

section:[Engine]

HTAP

section:[HTAP]

Configuration Détailée du Cluster

Raft

Raft utilise normalement un nombre impair de nodes, tels que 3, 5, 7, etc. Cela est dû au fait que Raft ne peut fonctionner que lorsque plus de la moitié des nodes sont en ligne, et 'plus de la moitié' signifie N/2+1 plutôt que N/2. Par exemple, cela nécessite >=2 nodes en ligne pour un cluster de 3 nodes, et >=3 nodes en ligne pour un cluster de 5 nodes.

Pour les clusters avec un nombre pair de nodes, Raft exige que les 2 nodes d'un cluster de 2 nodes soient tous les deux en ligne, et qu'un cluster de 4 nodes ait >=3 nodes en ligne.

Bien qu'un nombre pair de nodes consomme plus de ressources matérielles qu'un nombre impair de nodes mais apporte une disponibilité moindre, dans certains scénarios de forte cohérence, un nombre pair de nodes a plus d'avantages en termes de tolérance aux sinistres de données pour garantir la sécurité des données.

Dans le système Ultipa, chaque GraphSet a un groupe Raft, et chaque groupe Raft est complètement indépendant avec un Leader et un Follower différents.

Remarque : Le GraphSet nouvellement créé ne peut être utilisé immédiatement que lorsque le cluster Raft élit le Leader. Le délai est déterminé par le temps d'élection configuré.

Rôle

• Rôle 0 : Le node ne peut pas fournir de lectures lorsqu'il est Follower, il est utilisé pour des lectures cohérentes
• Rôle 1 : Le node peut fournir des lectures lorsqu'il est Follower, il est utilisé pour un équilibrage de charge de lecture
• Rôle 2 : Node algorithme qui peut exécuter des algorithmes, mais ne peut pas participer à l'équilibrage de charge de lecture
• Rôle 3 : Node algorithme qui peut participer à l'équilibrage de charge de lecture
• Rôle 4 : Node de sauvegarde qui ne fait que synchroniser les données, mais ne participe pas aux élections

Remarques :

• Le node de rôle 2, 3 ou 4 ne peut pas être élu Leader.
• Le nombre de nodes algorithme (rôle 2 ou 3) dans un cluster ne peut pas dépasser 50%.

Délai d'Attente pour l'Élection

Pour éviter les élections simultanées initiées par plusieurs nodes, Raft définit un délai d'attente pour l'élection aléatoire :

Délai d'Attente Réel pour l'Élection = random(election_timeout, 2*election_timeout)
Temps de Heartbeat = max(election_timeout/election_heartbeat_factor, 10)

Opération du Cluster

Journaux

Journal du cluster : htap-yyyymmdd-HHMMSS.log
Journal du serveur : server-yyyymmdd-HHMMSS.log

Les journaux commençant par [HTAP] dans le journal du serveur sont liés à la synchronisation du cluster, pour les visualiser : cat server-yyyymmdd-HHMMSS.log |grep "[HTAP]"

Outil d'Opération

ultipa_cluster_cli

Veuillez l'utiliser avec une extrême prudence !

Ajouter un Node

Les données initiales du node à ajouter doivent être les mêmes que celles des autres nodes. Démarrez le node nouvellement rejoint tout en s'assurant que le répertoire data/htapp est vide, sinon de nouvelles données peuvent ne pas être synchronisées.

ultipa_cluster_cli add --peer="$peer_being_added" --conf="$current_conf"

./ultipa_cluster_cli add \ 
--peer="127.0.0.1:60163|127.0.0.1:60063:1" \ 
--conf="127.0.0.1:60161|127.0.0.1:60061:1,\ 
            127.0.0.1:60162|127.0.0.1:60062:1" 

Supprimer un Node

ultipa_cluster_cli remove --peer="$peer_being_removed" --conf="$current_conf"

./ultipa_cluster_cli remove \ 
--peer="127.0.0.1:60163|127.0.0.1:60063:1" \ 
--conf="127.0.0.1:60161|127.0.0.1:60061:1,\ 
					  127.0.0.1:60162|127.0.0.1:60062:1,\ 
            127.0.0.1:60163|127.0.0.1:60063:1" 

Modifier le Node du Cluster

ultipa_cluster_cli change_conf --conf="$current_conf" --new_conf="$new_conf"

Créer un Snapshot, Compresser le Journal

ultipa_cluster_cli snapshot_leader --peer="$target_peer"

Changer de Leader

ultipa_cluster_cli change_leader --peer="$target_leader" --conf="$current_conf"

Resynchronisation

Lorsqu'un node a une incohérence de données, il doit être réinitialisé. Suivez strictement les étapes ci-dessous pour resynchroniser les données. Remarque : Les opérations suivantes doivent être effectuées sur le node à resynchroniser !

1. Utilisez ultipa_cluster_cli pour supprimer le node à resynchroniser
2. Arrêtez le node à resynchroniser : ./ultipa-server stop
3. Supprimez l'ensemble du répertoire de données du node à resynchroniser
4. Redémarrez le node à resynchroniser
5. Utilisez ultipa_cluster_cli pour ajouter le node à resynchroniser

Surveillance du Cluster

Page de surveillance : http://private_host:private_port/raft_admin

FAQs du Cluster

1. Erreurs Courantes

• Ce follower n'est pas lisible: La requête de lecture a été envoyée à un node non lisible.
  
• Ce follower charge le snapshot: Le node charge le snapshot, services temporairement indisponibles.
  
• Ce peer n'est pas leader, veuillez rediriger vers le peer leader: Le node n'est pas leader.
  
• Ce cluster raft n'a pas de leader: Aucun Leader n'a été élu dans le cluster.

2. Si l'erreur suivante se produit lors du redémarrage de ultipa-server, cela indique que le serveur peut avoir une incohérence de données due à une sortie anormale pendant le log apply process. Pour la cohérence des données, utilisez ./ultipa-server -d -safe pour réparer les données automatiquement.

[HTAP] IMPORTANT ! xxx pre_applied_index xxx != applied_index xxx, il pourrait y avoir des incohérences de données. 
[HTAP] Exécutez ./ultipa-server -d -safe pour démarrer le serveur en toute sécurité. 

Si ./ultipa-server -d -safe échoue à démarrer, veuillez suivre strictement les étapes correspondantes pour resynchroniser.

[HTAP] Échec du démarrage en toute sécurité ! Veuillez resynchroniser ce peer selon le document !

3. L'erreur 'reject term_unmatched AppendEntries' se produit lors du redémarrage

Cela indique que le statut du cluster du node est incorrect, ce qui peut être causé par la suppression du répertoire htap. Étant donné que le dernier prev_log_term du node est enregistré dans le cluster, et que local_prev_log_term devient 0 après la suppression des données localement, la synchronisation des données est rejetée car local_prev_log_term < prev_log_term.

Lorsque le statut du cluster du node présente un problème, utilisez ultipa_cluster_cli pour resynchroniser.

4. Modifier le fichier de configuration et redémarrer pour changer l'IP ou le port d'écoute du node ne prend pas effet. C'est parce que le cluster a déjà enregistré les informations du node, vous devez donc utiliser ultipa_cluster_cli change_conf pour mettre à jour les informations du cluster après le redémarrage.

./ultipa_cluster_cli change_conf \ 
--conf="127.0.0.1:60161|127.0.0.1:60061:1,\ 
127.0.0.1:60162|127.0.0.1:60062:1,\
127.0.0.1:60163|127.0.0.1:60063:1" \ 
--new_conf="127.0.0.1:60261|127.0.0.1:60061:1,\ 
            127.0.0.1:60262|127.0.0.1:60062:1,\ 
            127.0.0.1:60263|127.0.0.1:60063:1" 

5. Modifier le fichier de configuration et redémarrer pour changer de rôle ne prend pas effet. C'est parce que le cluster a déjà mis en cache cette configuration, vous devez donc utiliser ultipa_cluster_cli change_conf pour mettre à jour les informations du cluster après le redémarrage.

./ultipa_cluster_cli change_conf \ 
--conf="127.0.0.1:60161|127.0.0.1:60061:2,\ 
        127.0.0.1:60162|127.0.0.1:60062:1,\ 
        127.0.0.1:60163|127.0.0.1:60063:1" \ 
--new_conf="127.0.0.1:60161|127.0.0.1:60061:1,\ 
            127.0.0.1:60162|127.0.0.1:60062:1,\ 
            127.0.0.1:60163|127.0.0.1:60063:1" 

6. Si vous supprimez le répertoire htap sans supprimer le répertoire de données GraphSet, il y aura un problème lorsque vous utiliserez l'outil ultipa_cluster_cli pour supprimer le node et le rajouter après le redémarrage du service. C'est parce que les données sont synchronisées depuis le début à cause de la suppression du répertoire htap, et pendant que le répertoire de données n'est pas supprimé, il y aura une incohérence de données due aux journaux d'exécution en double ! Ainsi, n'oubliez pas de supprimer tous les répertoires de données GraphSet (y compris global) lorsque vous supprimez le répertoire htap !

7. Lorsque ni le répertoire htap ni le répertoire de données n'est supprimé, les données seront synchronisées depuis le dernier emplacement lorsque le node est supprimé et rajouté en utilisant l'outil ultipa_cluster_cli. C'est parce que le cluster se souvient toujours de l'emplacement lors de la dernière synchronisation du journal.