But de la rétro: empêcher le frontend de saturer de trop de requêtes transporteurs
Répartition de charge, parallélisme et scalabilité : load balancing de cluster . Scalabilité verticale/horizontale
Ceci est la 2ème vidéo de la série. Retrouvez la 1ere partie, l'envoi des emails par le backend, en cliquant ici ou bien la 3eme partie,
reprise sur failover de manière asychrone : service redondé. Réplication des données, en cliquant ici
Une question? Posez-la ici
Tout d’abord, un petit examen des logs, car l’on doit être capable de regader le déroulement de l’activité en cas d’erreur, pour débugguer :
Pour vérifier qu’il y a bien une trace de la transaction, je vais ouvrir le log :
Les 2 serveurs tomcat/Heatbeat1/logs/karcolb/karcoLBl.log
je vois la creation des objets session
-les object mockitos créés
-les tentatives d’envoie d’emails
Voici l'interface utilisateur 1 sur Edge
Comme on l’a mentionné dans l’analyse des risques, « la surcharge des serveurs peut provoquer un ralentissement du temps de traitement, voire un arrêt de la plateforme » Comme par exemple, si tous les transporteurs se connectent en même temps sur l’UI1 et renseignent leur prise en charge de session, leur nombre de place, le prix, leur modele de voiture comme on a vu à la video précédante.
Dans ce cas là on a un pic d’utilisation de la plateforme
-Le backend ne récupère plus les sessions à prendre en charges depuis la base,
-le transporteur ne peut plus se connecter à l’UI pour prendre en charge les sessions,
Exemple erreurs 500 que l’on voit des fois sur les sites WEB
Ca arrive des fois lorsqu’on est sur internet par exemple, qu’on remplit sa déclaration des revenus : comme par hasard tout le monde la remplit le dernier jour. Et en plus à la même heure, à 23h ! Qu’est-ce qui se passe ? PAF, pic d’activité, le serveur sature, il tombe, erreur 500.
Et donc rupture de production :
-Les emails ne sont plus envoyés, etc.
Bref, on a donc un SPOF ! Single point of failure
D’où l’idée de ce scenario2 cad de redonder le traitement: (montrer le diagramme de séquences)
On veut toujours 1 backend Heartbeat1 qui gère TOUJOURS l’affichage des pages web ET l’envoi d’email MAIS maitenant si ce process Heartbeat1 crash l’interface utilisateur doit continuer à s’afficher et les mails doivent aussi continuer à partir QUAND MEME pour que le transporteur puisse prendre en charge ses sessions.
Je mets donc un 2eme process heartbeat en parallèle. L’idée c’est que comme ca si l’un heartbeat crash, l’autre prend AUTOMATIQUEMENT le relai. Fini le SPOF !
L’astuce pour le load balancing: j’utilise 2 serveurs Tomcat : c’est ce qu’on appelle le parallélisme.
J’ai mes 2 serveurs Tomcat dans le repertoire téléchargement (raccourci « les 2 serveurs tomcat »)
Dans chacun des repertoires webapps on voit chaque war déployé
Je montre les WAR
J’ai donc codé sous Eclipse , compilé mes 2 war, et déployé mes 2 war sur mes 2 serveurs tomcats différents.
J’ai complié mes projets, copié les war dans les TOMCATS et je les ai renommé en heartbeat1 et heartbeat2 pour que ca soit plus parlant. Les codes sont différents aussi, le heatbeat1 est le master du cluster, le nœud-maitre en français, alors que le heartbeat2 est l’esclave.
Mais comme j’ai maintenant 2 serveurs TOMCAT, il faut que je change les ports d’écoute
Je retourne dans le répertoire CONF
Montrer édition repertoires heartbeat1/conf/server.xml bouton droit et modifier, Changer port
« Server port » 8005 et 8006 sur le 2eme
Et plus bas, Connector port 8080 et le 2eme je l’ai mis sur 9191
Redirect port 8443/8444 and
Démonstration
Je fais la même démonstration, mais cette fois avec 2 process Tomcat
Je lance
heartbeat2/bin/startup.bat
Le 1 et le 2 tournent en parallèle, voir les 2 icones tasses à café
Je montre que les 2 ports sont en écoute en lancant netstat -n
Le 1 c’est le master du cluster
Je lance Edge
Je tape l’adresse http://localhost:8080/heartbeat1/ (affichage welcome to karkolb)
Je tape l’adresse http://localhost:9191/heartbeat1/ (affichage welcome to karkolb)
Je peux donc distribuer les services pour mes transporteurs sur ces 2 fronts
Et ainsi de suite je peux scaler, rajouter autant de serveurs Tomcat que je veux, ce qui me fera autant de fronts possibles à interroger. Si le temps de réponse des serveurs Tomcats diminue, je peux ajouter de la mémoire, ou mettre un processeur plus puissant : c’est la scalabilité verticale.
J’ai maintenant 2 interfaces, je peux répartir la charge des interrogations web des transporteurs sur ces 2 fronts via roundrobin DNS ( ou tourniquet en français) pour eviter de surcharger les fronts : il s’agit du load balancing. Le client via son navigateur itnerroge une url, l’url cia le port 53 arrive sur le DNS et ce serveur DNS oriente ainsi le traffic alternativement vers le 1er seveur web, puis le 2nd, puis le 1er, puis le 2nd et ainsi de suite, comme un tourniquet, enfin là il n’y a que 2 serveurs , mais s’il y en avait 4, le DNS tournerait autour des 4.
Sur le DNS, il faut renseigner les hosts comme ceci :
HeatBeat1 Host(A) 192.168.1.20
HeatBeat1 Host(A) 192.168.1.21
HeatBeat1 Host(A) 192.168.1.22
Pour l'exemple, et simuler un serveur DNS sur une station Windows j’utilise le fichier Host situé dans:
C:\Windows\System32\drivers\etc\hosts
Sur le serveur DNS vec l’option round robin qui va bien, et ainsi chaque IP sera servie successivement.
Si besoin je pourrai même scaler et positionner chaque serveur Tomcat sur des serveurs physiques différents, dans le cloud, sur OVH par exemple, ou AZURE, c’est ce que l’on appelle la scalabilité horizontale.
Voilà mon backend est prêt à être scalé en fonction des pics de charges: fini le SPOFs