Planification de la production

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.

Introduction

Les premières questions auxquelles un architecte qui conçoit un environnement Zato doit répondre sont les suivantes:

• Quels processus commerciaux l'environnement doit-il supporter ? Peuvent-ils tous être identifiés à l'avance ?
• S'agit-il d'un environnement pour un seul projet, une seule initiative ou une série d'initiatives sur plusieurs années ?
• S'agit-il d'un environnement pour un département entier, une entreprise ou plusieurs entreprises ?
• Quel type de modèles, de techniques et de moyens de communication doit-il supporter ? S'agit-il principalement d'une communication de type demande-réponse, asynchrone ou de transfert par lots ? Est-ce un mélange de tout cela ?
• Quelles sont les exigences en matière de haute disponibilité ? Selon le contexte de l'entreprise, certains environnements ne pourront jamais tolérer une seconde d'indisponibilité alors que d'autres pourront être hors ligne pendant quelques minutes ou quelques heures.
• Quelles sont les compétences de l'équipe de développement et d'exploitation en matière d'automatisation ?
• Où déployez-vous ? Y aura-t-il un seul fournisseur de cloud ou plusieurs ? Déployez-vous sur promises ou dans des environnements hybrides également ?
• Quelles sont vos procédures de continuité des activités et de reprise après sinistre ?
• Connaissez-vous parfaitement l'architecture de la plate-forme ?

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.

Le déploiement en production ne doit être qu'une formalité

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.

Transactions en ligne ou traitement par lots

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.

Profitez des clusters de démarrage rapide

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.

HA - si le temps d'arrêt peut être accepté

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.

HA - si une disponibilité sans interruption est requise

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 :

• Créer un cluster multi-serveurs avec un équilibreur de charge devant eux. Cela permet d'utiliser le fait que tous les serveurs d'un même cluster Zato fonctionnent toujours de manière active-active. L'équilibreur de charge fait déjà partie de Zato, mais il est également possible d'en utiliser un externe.

• Créez plusieurs petits clusters quickstart à serveur unique avec un équilibreur de charge externe devant eux. Cela permet de tirer parti du fait que la création d'un nouveau cluster quickstart est une opération très rapide qui devrait être déjà connue de tous les développeurs et administrateurs, ce qui signifie que la conception d'un tel environnement HA peut prendre moins de temps. Cependant, dans cette configuration, chaque cluster aura sa propre base de données de configuration indépendante, ce qui signifie que WebSocket et publish/subscribe ne devraient pas être utilisés dans cette approche.

Mise à l'échelle horizontale et verticale

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.

Choix du système d'exploitation

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.

Planification des capacités

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:

• Attribuez au moins 30 Go d'espace disque à chaque VM si une seule VM contient un serveur.
• Attribuez au moins 15 Go d'espace disque à chaque serveur si une seule VM contient plus d'un serveur.

IBM MQ - Utilisation du CPU

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.

Oracle DB - ne pas utiliser plus de dix connexions dans un pool

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.

Considérations sur le Publish/subscribe

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.

Considérations sur leWebSocket

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.