Vue d'ensemble #
Le but de cet article est d’expliquer comment agrandir les capacités des serveurs d’applications tels que TomCat, Jboss or IIS en les rendant très évolutifs sur le Web et en les mettant en haute disponibilité afin d’être tolérants aux pannes et de renforcer la cybersécurité.
Qu'est-ce que la haute disponibilité? #
La haute disponibilité est la qualité d'un système ou d'un composant qui assure un niveau élevé de performance opérationnelle, généralement une disponibilité, pendant une période supérieure à la normale.
En mettant en place Serveurs d'application en haute disponibilité, nous résolvons les problèmes suivants:
- Un seul serveur perd de son efficacité lorsqu'il traite un grand nombre de demandes
- Les données de session sont conservées en cas de panne du serveur
- Mise à jour de l'application sans interruption du service
Qu'est-ce que l'échelle web? #
En appliquant des principes Web aux serveurs d'applications, tous les processus d'entreprise, quelle que soit leur taille, peuvent évoluer, être optimisés, être automatisés et être évolutifs.
Qu'est-ce qu'un serveur d'application? #
Un serveur d'applications est une structure logicielle qui fournit la logique métier d'un programme d'application. Cela signifie qu'il administre des ressources pour créer des applications Web et un environnement de serveur pour les exécuter.
Bien que cet article puisse être utilisé comme guide pour n’importe quel serveur d’application, nous allons expliquer quelques détails sur les plus populaires, à savoir:
- L' TomCat logiciel (ou également serveur Apache Tomcat ou Tomcat): implémentation open source des technologies Java Servlet, JavaServer Pages, Java Expression Language et Java WebSocket.
- JBoss or WildFly: le serveur d'applications développé par Red Hat.
- IIS (Internet Information Services): serveur d'applications développé par Microsoft.
Mise en place RELIANOID Load Balancer #
Avec le RELIANOID Load Balancer nous pouvons garantir la haute disponibilité et l’évolutivité des serveurs d’applications. Notez que pour suivre ces instructions, vous devrez installer une instance de RELIANOID Load Balancer et plusieurs instances de serveurs d'applications. L’environnement que nous allons décrire est le suivant :
Étape 0: réplication de serveur #
Dans notre exemple, nous utilisons deux serveurs principaux pour chaque application, mais nous pouvons en inclure autant que nécessaire. Il est essentiel d'assurer la cohérence afin que, lors de la connexion à un serveur d'applications, nous voyions toujours la même chose et que toutes les données enregistrées dans l'application ne soient pas perdues. Pour ce faire, la réplication de session au sein des serveurs doit être configurée. Nous appelons cela étape 0 comme cela doit être fait dans les serveurs d'applications.
TomCat fournit une réplication de session en mémoire intégrée: DeltaManager Gestionnaire de sauvegarde. La principale différence entre ces deux réplicateurs est que DeltaManager est plus lent, mais plus fiable en cas de panne.
JBoss fournit également un moyen simple d'activer la réplication de session: en marquant l'application comme étant distribuable dans le dossier web.xml descripteur.
Réplication du service pour IIS peut être réalisé en utilisant DFSR (Réplication de système de fichiers distribuée).
Étape 1: Créer une adresse IP virtuelle #
Une fois RELIANOID Load Balancer est installé, il est nécessaire pour créer une nouvelle IP virtuelle, depuis le menu principal, sélectionnez Réseau-> Interfaces virtuelles-> Actions-> Créer
Trouvez l'interface physique où vous voulez créer une adresse IP virtuelle
Tapez le nom et l'adresse de votre nouvelle adresse IP virtuelle. Puis enregistrez-le en cliquant sur le bouton «Créer».
Étape 2: Créer une batterie de serveurs http #
Une batterie de serveurs ou un cluster est un ensemble de serveurs informatiques fournissant une fonctionnalité de serveur augmentant considérablement sa capacité. Bien que nous utilisions les termes ferme grappe en tant que synonymes, il existe une légère différence entre eux. Quand on parle d'un grappe, la redondance est implicite, mais quand on parle d'un ferme, il peut y avoir ou non une redondance. Dans notre cas, comme nous aurons une configuration tolérante à l’échec, nous pourrions parler de la batterie de serveurs ou du cluster en tant que synonymes.
De cette manière, en mettant en place une batterie de serveurs d’applications, nous augmenterons ses performances et sa tolérance aux pannes, ce qui est essentiel pour la haute disponibilité. Pour y parvenir, allez à LSLB-> Fermes-> Créer
Sélectionnez un nom et HTTP comme profil. Nous sélectionnons le profil http, car il s'agit de la meilleure option pour les services Web, car nous pouvons fournir des options de commutation de contenu sous le même IP virtuel et le même port.
Deux autres options seront affichées. Sélectionnez l'adresse IP virtuelle créée à l'étape 1 et un port (dans l'exemple, nous choisissons 80, car il s'agit du protocole HTTP par défaut) et cliquez sur le bouton Enregistrer .
Étape 3: Ajouter les services #
L'idée principale est de servir différentes applications de différents serveurs d'applications à partir du même IP virtuel et du même port. Ainsi, une fois la batterie créée, nous devons la modifier pour ajouter de nouveaux services. Dans notre exemple, nous allons mettre en place trois services. Un pour chaque serveur d'applications. S'il vous plaît cliquer sur le bouton modifier la ferme.
Plusieurs détails de la batterie peuvent être modifiés, dans l'exemple, nous allons définir les valeurs par défaut et les services.
Dans la capture d'écran ci-dessus, nous avons Ajout d'un service avec le nom de service «app1».
Comme nous allons accéder aux trois services via la même batterie de serveurs, nous devons faire la distinction entre ces services. Pour ce faire, nous pouvons définir une valeur pour Modèle d'URL. Ce champ permet de déterminer un service Web en fonction de l'URL demandée par le client via un modèle d'URL spécifique. Dans notre exemple, nous allons taper ^ / app1. *, ^ / app2. * ^ / app3. *. Cliquez sur Modifier appliquer des modifications.
Prendre en compte que le backend doit trouver l'adresse http://[VIRTUAL_IP]:[PORT]/[YOUR_SERVICE] (dans notre exemple http://192.168.56.200/app1), afin de garantir cela, le contexte doit être défini dans votre application. Dans nos exemples, nous allons définir le contexte / app1 pour TomCat, / app2 pour Jboss / app3 pour IISL’ Contexte représente une application Web qui s'exécute sur un hôte virtuel particulier. Dans le cas particulier de IIS, les contextes sont appelés applications.
Dans cet exemple, nous avons deux serveurs principaux par application. Nous sélectionnons IP, port (8080 par défaut pour TomCat JBosset 80 pour IIS), timeout et poids et cliquez sur sauvegarder le backend .
Nous voulons éviter la commutation de serveur: si, au cours de notre session, nous passons d’un serveur à l’autre, nous perdons en efficacité, en données et même en communication. Afin d'éviter cela, le Session de persistance doit être configuré. Nous choisirons de maintenir une session par identifiant de session, ce qui signifie que lors d’une session, nous ne nous connecterons qu’à un seul serveur.
Dans les paramètres globaux du service, nous pouvons maintenant changer le champ de session de persistance pour COOKIE: un certain cookie
Choisir Jsessionid comme identifiant de session de persistance pour Tomcat et Jboss et ID de session pour IIS, cliquez ensuite sur Mettre à jour au bas de la page.
Maintenant, sous la même ferme, nous allons ajouter 2 services supplémentaires de la même manière que app1 pour app2 et app3, y compris le cookie de persistance pour JBoss (la valeur par défaut est appelée Jsessionid) et IIS (le cookie par défaut pour ASP.NET est ASPXAUTH), mais vous pouvez utiliser le cookie requis par l'application. Chaque service de la ferme a son propre backend qui peut être partagé entre des fermes ou des services de fermes.
Notez que l'ordre des services est important pour correspondre au modèle d'URL correct.
Enfin, nous devons appliquer les modifications en redémarrant la batterie.
Félicitations! vous avez configuré vos serveurs d'applications en haute disponibilité. Vous pouvez y accéder en tapant http://[VIRTUAL_IP]:[PORT]/[YOUR_SERVICE] (dans notre exemple http://192.168.56.200/app1, http://192.168.56.200/app2 or http://192.168.56.200/app3).
Étape 4: Vérification avancée #
Nous allons maintenant configurer le gardien de la batterie de serveurs afin de procéder à des vérifications de l'état de santé avancées des systèmes dorsaux, afin de s'assurer qu'ils sont opérationnels et fonctionnent correctement, ainsi que le comportement correct de l'application, et pas uniquement la vérification du port TCP. Veuillez localiser le Gardien de ferme dans votre service, nous avons mis en place à l'étape 3. Cliquer sur Utilisez FarmGuardian pour vérifier les serveurs principaux, vous pouvez également modifier le temps entre le contrôle et enfin, dans Commande à vérifier textbox, tapez la commande suivante.
check_http -I HOST -w 10 -c 10 -t 10 -e 200 -p PORT -s ' '
Enfin, cliquez sur Mettre à jour au bas de la page.
La commande check_http teste les connexions HTTP avec l'hôte spécifié. Dans notre cas, nous utilisons les options suivantes:
-J'ai l'hôte: Le jeton HOST sera remplacé par l'adresse IP principale définie.
-w 10: temps de réponse donnant lieu à un avertissement: secondes 10
-c 10: temps de réponse à l'état critique: secondes 10
-t 10: 10 secondes avant l'expiration de la connexion
-e 200: attend la chaîne 200 dans l'état de la réponse du serveur
-p PORT: Le jeton PORT sera remplacé par le port principal défini.
-s ' ': la chaîne à attendre dans le contenu est ' '
Donc, ce que cette commande va faire est essentiellement de vérifier que nous obtenons une réponse 200 OK, et que la commande de réponse contient la chaîne ' ». Nous sélectionnons cette chaîne car elle se trouve à la fin de la réponse, de cette façon nous pouvons garantir que nous obtenons une réponse complète des backends.
Step 5: Haute sécurité #
Des communications sécurisées peuvent être facilement mises en place avec RELIANOID Load Balancer, l'étape suivante consiste donc à activer l'écouteur HTTPS : sur le Modifier les paramètres globaux de la batterie écran, veuillez modifier le programme d'écoute de la batterie de HTTP à HTTPS et le port virtuel à 443.
Maintenant, vous pouvez accéder aux services en tapant https://[Your_virtual_ip]/[yourappservice] dans votre navigateur.
Les communications sécurisées sont en cours d’exécution, mais nous pouvons aller plus loin en configurant les paramètres HTTPS: dans les paramètres globaux de la batterie, localisez le Paramètres HTTPS section. Nous pouvons changer le chiffrements à Haute sécurité.
Le champ chiffrements est utilisé pour créer une liste de chiffrements acceptés par les connexions SSL afin de renforcer la connexion SSL. En sélectionnant Haute sécurité, nous allons définir par défaut les chiffrements.
kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED
Une autre option est la Certificats HTTPS disponibles: une liste de certificats sera sélectionnée pour être sélectionnée pour la batterie actuelle (uniquement pour les batteries HTTP, ce qui est notre cas). Nous pouvons en sélectionner un dans la liste et cliquer sur Ajouter. Enfin, cliquez sur Modifier et redémarrez la batterie pour appliquer les modifications.
Pour plus d'informations, s'il vous plaît voir Fermes de profils HTTP.
HTTPS peut également être activé sur vos serveurs d’application. Si tel est le cas, vous devez activer l’option Les backends HTTPS.
