Avec PLOSSYS 5, SEAL Systems développe la prochaine génération de son système d’output management. Bien qu’il soit toujours possible d’installer PLOSSYS 5 localement, c’est-à-dire sur site, le système a été conçu dès le départ pour fonctionner dans le cloud. Au lieu d’un système monolithique, PLOSSYS 5 fonctionne dans le cloud sous la forme d’un cluster de microservices qui peuvent être démarrés ou arrêtés en fonction de la charge. Le système n’utilise donc que le nombre de ressources réellement nécessaires.

Dans ce blog, nous présentons ce processus dans la pratique – et comment votre système d’output management pourrait être flexible à l’avenir. Comme exemple d’environnement cloud, nous avons choisi un cluster Kubernetes basé sur Amazon Web Services (AWS). Nous aurions également pu faire appel à d’autres fournisseurs et gestionnaires de clusters, comme Azure ou OpenShift. La combinaison choisie nous permet seulement de démontrer les avantages de cette technologie.

Scénario

Ce que nous voulons montrer dans cet article est un scénario typique pour un déploiement de PLOSSYS 5 de petite à moyenne taille : une base de données opérationnelle (sécurisée en fonctionnement composé de trois instances de base de données), une instance de base de données de logs et un ensemble de microservices PLOSSYS 5. Ce scénario convient parfaitement, par exemple, à l’impression du spool SAP et Windows avec jusqu’à 100 000 travaux d’impression par jour. Nous expliquons la structure du scénario et montrons comment la technologie des clusters combine fiabilité et utilisation économique des ressources.

Architecture Technique

La base de référence est PLOSSYS 5, que nous avons préparé sous forme de conteneurs logiciels pour l’exploitation dans le cloud. Pour notre cluster, nous avons mis en place quatre machines virtuelles sur AWS, qui sont gérées par Kubernetes en tant que node et combinées pour former un cluster. Un node manager assure la surveillance, le contrôle, l’équilibrage de charge, la configuration et le réseau interne. Trois node worker font fonctionner la base de données du cluster et fournissent la puissance de calcul restante pour le fonctionnement réel de PLOSSYS 5. Le manager s’assure à son tour que cette puissance est utilisée de manière optimale. Les node manager sont réalisés sous la forme d’un groupe autoscale distinct : en cas de défaillance des node manager, AWS redémarre automatiquement les nouveaux node manager afin que le cluster ne soit jamais complètement défaillant. Nous surveillons les performances du cluster avec Prometheus et créons des tableaux de bord avec Graphana.

L’image suivante montre l’état du cluster avec trois node, deux cœurs CPU et 16 Go de RAM (6 cœurs et 48 Go de RAM au total). Il y a 36 services actifs sur le cluster, dont les bases de données, les services PLOSSYS et le monitoring. Les services réservent 79% de la capacité CPU disponible et 16% de la RAM disponible. La charge réelle est très faible (voir le diagramme à gauche). Sous la charge, les barres bleues indiquent l’utilisation réelle des ressources dans le cluster au fil du temps.

Travailler avec des Machines Virtuelles Volatiles

Nous utilisons ce qu’on appelle des instances ponctuelles pour tous les node de cluster sur AWS. Amazon peut arrêter ces machines virtuelles à tout moment avec un préavis de quelques minutes si des ressources sont nécessaires ailleurs. D’un autre côté, les instances ponctuelles sont beaucoup moins chères que les machines virtuelles fonctionnant en permanence. Nous pouvons utiliser cet avantage parce que la technologie des clusters et les microservices rendent PLOSSYS 5 indépendant des machines virtuelles fixes. Si l’une des instances ponctuelles est arrêtée, elle tombe simplement hors du cluster. Le gestionnaire de cluster enregistre le manque de ressources et de services, démarre une nouvelle machine virtuelle, l’intègre dans le cluster et redémarre automatiquement les microservices manquants.

PLOSSYS 5 utilise également le même mécanisme pour assurer un fonctionnement sans faille dans le cluster. La seule différence entre la défaillance d’une machine virtuelle et l’arrêt d’une instance ponctuelle est le délai de mise en oeuvre. Après un court laps de temps, PLOSSYS 5 détecte la défaillance du matériel virtuel même sans pré-exécution et réagit exactement comme après avoir éteint une instance ponctuelle: une nouvelle VM est créée, intégrée et les services manquants sont redémarrés.

Auto Scaling

Comme dans le cas d’une défaillance de node, le cluster réagit également à l’augmentation des besoins en ressources en cas de forte charge.  Si le cluster nécessite plus de ressources que ce que le cluster peut fournir, l’autoscalling automatique devient actif. Le gestionnaire de cluster démarre alors automatiquement des instances de worker supplémentaires pour démarrer des services supplémentaires et absorber les pics de charge. Si la charge diminue à nouveau par la suite pour que le cluster puisse gérer avec moins d’instances de worker, le gestionnaire efface progressivement les instances de worker et les désactive automatiquement. La figure montre le cluster dans un état dans lequel plus de services ont été démarrés que le cluster ne peut fonctionner (reconnaissable par le nombre de cœurs CPU demandés et les sept instances de service manquantes, indiquées en rouge).

Dans ce cas, le Cluster Manager démarre automatiquement des instances de worker supplémentaires avec six cœurs supplémentaires et 36 Go de RAM et les intègre dans le cluster. C’est ici que commencent les services supplémentaires demandés. Cela normalise le fonctionnement et la charge se trouve à nouveau dans la plage nominale.

Cette situation peut être vue dans l’image suivante: Le nombre de cœurs CPU dans le cluster est passé à 12, la mémoire disponible est passée à 84 Go. Au total, 83 services sont actifs à l’heure actuelle.

Avantages Financiers Énormes

Les avantages d’une application native au Cloud avec architecture microservice en mode cluster sont multiples. Cela permet non seulement d’ajuster automatiquement le nombre de services requis, mais aussi le nombre de serveurs, ce qui permet d’économiser des coûts directs. D’autres économies résultent de l’utilisation d’instances Spot, peu coûteuses et volatiles, qui peuvent être en cas de défaillances, absorbées par Kubernetes. La fiabilité au niveau du service et du serveur fait déjà partie de PLOSSYS 5.

Le renouvellement constant des instances élimine également le besoin de maintenance et d’entretien des serveurs. Les systèmes dont le système d’exploitation est obsolète sont automatiquement remplacés par de nouveaux systèmes avec un système d’exploitation à jour. La dépendance à l’égard du fournisseur de cloud computing appartient également au passé : Kubernetes et Openshift peuvent maintenant être installés chez presque tous les fournisseurs de cloud computing.

Vous souhaitez en savoir plus?

Demandez à nos experts de vous contacter sans engagement !

*Pas de newsletter, pas de transfert de données, contact uniquement pour le prupose mentionné.