Ce guide présente des informations permettant de concevoir et d'installer le bon type d'environnement de production Zato - un environnement qui répond aux exigences d'un système capable de prendre en charge un large éventail de processus commerciaux de manière efficace et efficiente.
Les premières questions auxquelles un architecte qui conçoit un environnement Zato doit répondre sont les suivantes:
Le reste de ce document part du principe que vous avez les réponses aux questions susmentionnées, car c'est de ces questions que découleront les décisions concrètes et techniques décrites ci-dessous.
La majorité des projets ou des travaux nécessitent la création d'au moins un environnement autre que l'environnement de production avant qu'une solution puisse être transférée dans l'environnement de production. Cet environnement est généralement appelé dev, développement ou test.
Cela signifie que le minimum d'environnements à créer est de deux, un pour les besoins réels de la production et au moins un autre environnement. S'il n'y a que deux environnements, c'est à vous de décider si celui dans lequel le développement et les tests ont été effectués devient la production ou si la production est créée séparément.
Cependant, le déploiement en production ne devrait être qu'une simple formalité. Dans un environnement bien planifié, et au moins partiellement automatisé, le déploiement d'une solution en production ne devrait pas être beaucoup plus qu'une répétition d'étapes qui ont déjà été effectuées dans un autre environnement.
L'utilisation de deux, trois ou plus d'environnements en plus de la production dépendra d'une situation commerciale et technique particulière - dans certains cas, il y aura des environnements de développement distincts pour chaque développeur indépendamment, ou des environnements d'intégration, d'acceptation par l'utilisateur (UAT) et de test ou de pré-production et miroir distincts.
Prévoyez d'automatiser votre configuration et vos déploiements et utilisez systématiquement les mêmes outils d'automatisation dans différents environnements. Encore une fois, le résultat final attendu est qu'un environnement de production, aussi important soit-il, devrait simplement être le même ensemble d'outils et de procédures, paramétrés différemment, en pointant vers différentes bases de données ou ressources par exemple.
Les processus impliquant principalement un travail avec de petites requêtes courtes et des réponses immédiates basées sur les entrées des utilisateurs sont appelés transactions en ligne, tandis que le travail tel que le traitement quotidien de factures ou de commandes de clients par transfert de fichiers est un traitement par lots.
Ces deux types de processus sont en concurrence pour l'utilisation des processeurs du serveur et de la mémoire vive. Par exemple, une tâche nocturne de traitement de gros fichiers téléchargés à partir de SFTP peut saturer complètement plusieurs CPU et plusieurs Go de RAM. Pendant ce temps, les processus impliqués dans les transactions en ligne n'auront pas accès à ces ressources du serveur.
Par conséquent, un certain mélange des deux types de transactions dans un même environnement est généralement acceptable mais, en règle générale, si vous concevez un environnement de traitement des transactions en ligne très performant, ne l'utilisez pas pour le traitement par lots ou l'inverse. Créez plutôt deux clusters Zato ou plus, chacun pour les types de processus spécifiques. Votre environnement de production sera alors composé de deux clusters Zato ou plus - il est tout à fait naturel d'avoir un environnement composé de plus d'un cluster. Si nécessaire, ils peuvent communiquer en utilisant des WebSockets, REST ou d'autres protocoles.
Les clusters Quickstart sont un moyen de configurer un nouvel environnement Zato en utilisant une seule commande, "zato quickstart /path/to/environment". Un cluster quickstart est un environnement autonome et entièrement fonctionnel qui comprend un serveur, un tableau de bord basé sur le Web et un équilibreur de charge.
Le cluster résultant est exactement le même que si l'on utilisait tous les composants individuels par soi-même, sauf qu'il est déjà préconfiguré et prêt à l'emploi, ce qui signifie que vous n'avez pas besoin de le faire par vous-même, mais plutôt de créer un cluster quickstart chaque fois que possible pour gagner du temps.
Les clusters quickstart sont également disponibles via des conteneurs Docker quickstart qui vous permettent de configurer le cluster via des variables d'environnement et des fichiers enmasse. Ils constituent un moyen pratique de mettre en place de nouveaux environnements qui ne nécessitent pas une HA (haute disponibilité) ininterrompue.
Les temps d'arrêt ne sont jamais agréables et la plupart des environnements aimeraient les éviter. Dans le même temps, de nombreux sites n'aimeraient pas investir trop de temps pour les éviter, car il se peut qu'il n'y ait pas de retour tangible d'un tel investissement en temps et en ressources.
Par exemple, si la nature commerciale des processus impose qu'ils soient exécutés une fois par jour, une fois par mois ou à des intervalles suffisamment larges pour que des tâches semi-automatiques ou manuelles puissent être effectuées, il peut exister une tendance naturelle à ne pas préférer concevoir et maintenir un environnement HA complet.
Dans ce cas, envisagez d'abord l'utilisation de clusters quickstart, en exécutant éventuellement Zato sous un conteneur Docker quickstart, et surveillez sa disponibilité à l'aide d'un outil externe à l'environnement.
Cet outil de surveillance peut être une requête ping REST vers /zato/ping ou quelque chose de plus spécifique au site, par exemple, vous pouvez demander au planificateur intégré de déclencher une nouvelle tâche consistant à envoyer un ping à un serveur de surveillance externe une fois par minute.
De cette manière, si l'environnement devient indisponible pour une raison quelconque, son remplacement peut être mis en place très rapidement. Il vous appartient de décider dans un contexte donné si la mise en place d'un environnement doit être entièrement automatisée, c'est-à-dire si l'absence de réponse à un événement de surveillance doit déclencher une rebuild automatiquement ou si la rebuild doit être déclenchée manuellement.
Indépendamment de la façon dont la rebuild est déclenchée, si vous utilisez les clusters quickstart et zato enmasse, la disponibilité d'un nouvel environnement ne devrait pas prendre plus de quelques minutes.
Si vous avez besoin d'un système HA complet, sans temps d'arrêt, vous devez vous assurer qu'il y a toujours au moins un serveur disponible pour accepter et traiter les demandes. Il existe deux grandes voies pour y parvenir :
Les environnements Zato peuvent être mis à l'échelle en ajoutant de nouveaux serveurs, de nouveaux CPU aux serveurs existants, ou les deux. Dans les deux cas, le résultat est le même : davantage de serveurs disponibles pour le traitement des messages.
Cependant, l'un des piliers du cloud computing est que les environnements doivent évoluer par l'ajout d'ordinateurs relativement petits et peu coûteux. Cela signifie que les serveurs Zato ne doivent pas avoir plus de 4 CPU affectées aux processus principaux.
Par exemple, si vos besoins de traitement nécessitent l'utilisation de 24 CPU, créez un environnement composé de 24 serveurs avec 1 CPU chacun, 12 serveurs avec 2 CPU chacun, ou 6 serveurs avec 4 CPU chacun plutôt que 2 serveurs avec 12 CPU chacun.
Les environnements de production doivent utiliser des systèmes Linux. Tous les systèmes doivent être identiques, c'est-à-dire utiliser systématiquement Ubuntu à la même version et au même niveau de patch partout dans l'environnement.
Les systèmes Windows peuvent être utilisés pour le développement, mais ils ne sont pas pris en charge en tant qu'environnements de production.
Bien que les serveurs Zato soient rapides et peu gourmands en ressources, dans un aperçu général comme celui-ci, il n'est pas possible de prévoir spécifiquement la quantité de RAM et de CPU dont aura besoin une solution ou un environnement particulier. Dans un cas, il peut s'agir d'une petite unité centrale, dans un autre, de plusieurs unités centrales plus grandes. Ce type d'estimation ne peut être réalisé que lors de tests de performance spécifiques à une charge de travail particulière.
La seule valeur par défaut qui peut être estimée est celle de l'espace disque nécessaire à des fins de production:
Les connexions IBM MQ utilisent des processus supplémentaires, indépendants de ceux du serveur principal, ce qui signifie qu'elles nécessitent des unités centrales supplémentaires. Chaque canal IBM MQ ou connexion sortante utilise son propre processus. Dans un système occupé, affectez davantage de CPU à une VM afin que les processus supplémentaires ne partagent pas les CPU avec les processus du serveur principal.
N'utilisez pas plus de 10 connexions dans un seul pool Oracle DB, sinon la bibliothèque SQL Oracle DB sous-jacente peut commencer à renvoyer l'erreur KPEDBG_HDL_PUSH_FCPTRMAX qui redémarrera automatiquement le processus du serveur principal, interrompant toute demande déjà en cours.
Si vous utilisez la publication/abonnement, chaque serveur peut utiliser 1 CPU. Dans ce type d'environnement, il est préférable d'ajouter des serveurs plutôt que des CPUs.
Si vous utilisez des connexions WebSocket, chaque serveur peut utiliser 1 CPU. Comme dans le cas du publish/subscribe, ces environnements s'étendent en ajoutant plus de serveurs plutôt qu'en ajoutant plus de CPUs.