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 </archi-exploit-infra/15-services>` 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 </archi-exploit-infra/08-consul>`.

