5.1.3. Principes sur les communications inter-services et le clustering

5.1.3.1. 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).

Prudence

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.

5.1.3.1.1. 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.

5.1.3.1.2. 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.

5.1.3.2. 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 COTS utilisé.

Voir aussi

Plus de détails seront apportés dans les chapitres spécifiques présent dans la section décrivant en détail les contraintes techniques des différents services VITAM.

5.1.3.3. Annuaire de services (service registry)

La découverte des services est réalisée via l’utilisation du protocole 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.

Voir aussi

La solution de DNS applicatif intégrée à VITAM est présentée plus en détails dans la section dédiée à Consul.