Comprendre les serveurs Zato

Ce chapitre architecture se penche sur les détails des serveurs Zato du point de vue de l'architecture de la plate-forme. Comment ils fonctionnent, comment ils évoluent et comment les développeurs et les administrateurs peuvent y accéder.

Active-active

  • Il n'y a pas de limites quant au nombre de serveurs qu'il peut y avoir dans un seul cluster.
  • Par défaut, tous les serveurs d'un cluster sont toujours actifs et l'équilibreur de charge dirige le trafic vers chacun d'eux.
  • Il est possible de mettre un serveur hors ligne, par exemple pour appliquer des mises à jour, et l'équilibreur de charge redirigera le trafic vers le reste.
  • Tant qu'un serveur fonctionne, il synchronise son état avec les autres membres des clusters, même si ce serveur est hors ligne. Par exemple, le code déployé sur un serveur sera automatiquement distribué à tous les autres serveurs, même si, du point de vue de l'équilibreur de charge, l'un d'entre eux est hors ligne.

Conteneurs pour les services

  • Les serveurs sont des conteneurs sur lesquels les services API sont déployés.
  • Il n'y a pas de limites quant au nombre de services qu'un seul serveur peut contenir.
  • Chaque service inactif consomme jusqu'à 1 Mo de RAM. Ainsi, 1 Go de RAM peut signifier 1 000 services API ou IA professionnels.
  • Un service prend moins de 1 ms pour être déployé. Il faut moins d'une seconde pour déployer 1 000 services d'API ou d'IA d'entreprise.
  • Tous les serveurs d'un même cluster sont toujours des images miroir en termes de code et de services qu'ils exécutent.

Mise à l'échelle d'un environnement - API et IA

  • L'aspect le plus important pour savoir s'il faut ajouter plus de serveurs ou plus de clusters avec leurs propres serveurs est de comprendre la distinction entre les services qui sont liés au réseau et ceux qui sont liés au CPU.

  • Les services sont liés au réseau s'ils attendent principalement les réseaux TCP. Par exemple, imaginez un exemple de service REST ou AMQP qui peut prendre 100 ms pour se terminer. Sur ce total, 98 ms sont consacrées à l'attente de la réponse d'un endpoint ou d'un serveur distant, tandis que 2 ms seulement sont consacrées au traitement effectif des données reçues. Cela signifie que le service passe 98 % de son temps à ne rien traiter activement, il est lié au réseau. D'où le nom de network-bound.

  • Les services sont liés au CPU s'ils sont principalement bloqués, attendant que les CPU calculent un résultat attendu. Par exemple, imaginez un service qui a besoin de 200 ms pour obtenir des données et dont les algorithmes d'intelligence artificielle ont besoin de deux minutes pour aboutir. Dans ce cas, le service passe la majeure partie de son temps à attendre le CPU. D'où le nom de "CPU-bound". Un autre exemple peut être l'analyse et le traitement de fichiers volumineux, par exemple des fichiers de plusieurs Go dont l'analyse peut nécessiter du temps pour le CPU.

  • Comme chaque serveur Zato d'un même cluster exécute le même ensemble de services, les services liés au réseau ne doivent pas être mélangés avec les services liés au processeur. S'ils sont mélangés, s'ils sont déployés dans le même cluster, il peut arriver que les services liés au CPU prennent complètement le dessus sur les CPU, ne laissant aucune place aux services liés au réseau. Par exemple, si de nombreux services d'IA nécessitent du temps CPU et qu'une requête REST (TCP) arrive, les CPU peuvent être complètement occupés par les calculs d'IA, ne laissant que très peu ou pas de temps de traitement pour les événements réseau.

  • Il est tout à fait normal et attendu d'avoir plus d'un cluster, selon que la charge de travail est uniforme, c'est-à-dire uniquement liée au réseau ou uniquement liée au CPU, par opposition aux charges de travail mixtes, contenant des services des deux types. Avec des charges de travail mixtes, il est recommandé d'avoir plus d'un cluster.

Mise à l'échelle d'un cluster

  • Un cluster individuel peut être mis à l'échelle en ajoutant plus de serveurs avec un plus petit nombre de CPUs pour chaque serveur ou en ajoutant plus de CPUs à chaque serveur.

  • En général, il est plus souhaitable d'ajouter plus de petits serveurs que plus de CPU pour chaque serveur. La raison en est que, dans le véritable esprit du cloud computing, il n'y a pas de limites quant au nombre de serveurs pouvant être ajoutés alors que, en général, la limite de CPU par chaque serveur se situe entre 6 et 8, selon la marque et le modèle de CPU particuliers, et l'ajout de CPU au-delà de la limite n'améliore pas significativement les performances.

  • Les serveurs dont les services utilisent la fonction de publish/subscribe constituent un cas particulier dans la mesure où ils nécessitent toujours exactement 1 CPU par serveur. Dans ce scénario, les clusters sont mis à l'échelle en ajoutant plus de serveurs, chacun avec 1 CPU.

En savoir plus