Principes sur les communications inter-services et le clustering ################################################################ Clusters applicatifs métier =========================== Globalement, les principes de haute disponibilité et d'équilibrage de charge peuvent se diviser en 2 grandes catégories : * Les principes utilisés par le service ``worker`` ; * Les principes utilisés par les autres services (dans le cadre des appels REST). .. caution:: Dans cette version de VITAM, 2 composants ne sont pas déployables à plus d'une seule instance : ``workspace`` et ``processing``. Pour le composant offer, il faut faire très attention, il peut être facilement multi-instancié (pour un type d'offre au sens vitam) avec des offres type swift ou s3, mais pas avec des technologies type filesystem standard. Appels REST des services métier ******************************* Chaque cluster de service possède un nom unique de service (le ``service_id``) ; chaque instance dans ce cluster possède un identifiant d'instance (``instance_id``). Globalement, les services VITAM suivent les principes suivants lors d'un appel entre deux composants : 1. Le composant amont effectue un appel à l'annuaire de services en indiquant le ``service_id`` du service qu'il souhaite appeler ; 2. L'annuaire de service lui retourne une liste ordonnée d'``instance_id``) ; c'est de la responsabilité de l'annuaire de service de trier cette liste dans l'ordre préférentiel d'appel (en fonction de l'état des différents services, et avec un algorithme d'équilibrage dont il a la charge) ; 3. Le composant amont appelle la première instance présente dans la liste. En cas d'échec de cet appel, il recommence depuis le point 1. .. note:: Ces principes ont pour but de garantir les deux points suivants : * Les clients des services doivent être agnostiques de la topologie de déploiement, et notamment du nombre d'instances de chaque service dans chaque cluster ; la connaissance de cette topologie est déléguée à l'annuaire de service. * Le plan de contrôle (choix de l'instance cible d'un appel) doit être décorrélé du plan de données (appel effectif), notamment dans un but de performance du plan de données. Workers ******* Au démarrage, ces workers s'enregistrent auprès du composant processing ; ensuite, les tâches sont distribuées par le processing aux différents workers. C'est donc processing qui a à sa charge la gestion de la distribution et de la résilience des workers. COTS & clustering ================= La gestion de l'équilibrage de charge et de la haute disponibilité doit être intégrée de manière native dans le :term:`COTS` utilisé. .. seealso:: Plus de détails seront apportés dans les chapitres spécifiques présent dans :doc:`la section ` décrivant en détail les contraintes techniques des différents services VITAM. Annuaire de services (service registry) ======================================= La découverte des services est réalisée via l'utilisation du protocole :term:`DNS`. .. note:: Les avantages de l'utilisation de ce protocole sont multiples : * Simple et éprouvé * Connu des équipes d'exploitation Le service DNS configuré lors du déploiement doit pouvoir résoudre les noms DNS associés à la fois aux ``service_id`` et aux ``instance_id``. Tout hôte portant un service VITAM devra utiliser ce service DNS par défaut. L'installation et configuration du service DNS applicatif est intégré à VITAM. .. seealso:: La solution de DNS applicatif intégrée à VITAM est présentée plus en détails dans :doc:`la section dédiée à Consul `.