Scénario3 : si ce service backend heartbeat1 crashe? Reprise sur failover de manière asychrone : service redondé. Réplication des données

Une question? Posez-la ici

Rappel de ce que j'ai mis en place sur les 2 premières parties:

-à la vidéo de la démo 1 : prise en charge session et envoi d'email et

-à la vidéo de la démo 2 : si le front sature de trop de requêtes transporteurs : répartition de charge, parallélisme et scalabilité : load balancing de cluster . Scalabilité verticale/horizontale (serveur dédié OVH)

Nous avons 2 serveurs applicatifs backend Heartbeat1 et Heartbeat2 Tomcat en parallèle (on parle de parallélisme dans les système sdistribués), en clusters sur lesquels il y a une répartition de la charge des requetes transporteurs. On a aussi de la scalabilité : le load balancing du cluster est assuré par un round robin DNS, ou tourniquet en français. La scalabilité verticale et/ou horizontale est maitrisée et est rendue facile à mettre en place en cas de pic d’activité ou de charge importante. C’est le fameux « on demand », « à la demande » du Cloud : on paye les ressources en fonction du besoin.

Je vais maintenant vous montrer le scénario où le heartbeat1 crash au moment d’envoyer des emails : le heartbeat 2 prend alors le relai de manière transparente et continue à envoyer les mails qui ne sont pas partis.

Que va-t-il se passer ?

Regardez bien ça va allez très vite. L’avantage de la vidéo c’est que l’on peut rejouer si l’on a pas bien vu.

-Je vais purger ma base de la présence de sessions (truncate, drop...).

-je vais lancer le 2eme process Heartbeat2

-Je vais relancer via l’ui2 la création des sessions à prendre en charge (objets Mockitos qui fakent les sessions à prendre en charge), je prepare l’interface et j’attends que le heartbeat1 fasse son cycle de 30 secondes, cela me laissera 30 secondes, pour retourner sur la  base et raffraichir.

Je vais clique sur UI1 par exemple, bouton « create mockito Objects »

-le heatbeat1 va scanner la base de donnée toutes les 30 secondes, et les quand il va voir ces sessions, il va commencer à envoyer les emails.

Je regarde le process1 au bout de 30 secondes, il envoie bien les emails

-je vais voir dans la base de donnée que les emails partent bien en raffraichissant HeidiSQL

-au milieu de l’envoi des emails, j’attends qu’il envoie 12 mails sur 20 et "PAF", je kill le process heartbeat1 en cliquant sur la croix (je simule un crash ou un freeze)

-le heartbeat2 va prendre le relai automatiquement, et finir d’envoyer les mails

DEMONSTRATION !

Je  vais regarder la colonne « emailsent » de la base de donnée

la colonne « emailsent » passe de False à True jusqu’à 50% environ

A 50% environ je crashe manuellement le process1 (je simule le crash en fermant le process avec la croix tout simplement)

Au bout de 30 secondes de heartbeat, le process2 prend le relai, il envoie les mails

Je regarde la table sessiontransport : la colonne emailsent passe de false à true pour chaque email envoyé, soit 12 sur 20

Je regarde les logs, les x derniers mails envoyés du log2 sont bien ceux qui manquaient au log1

Les services backend check sessions et envois d'emails sont donc bien redondés.

C’est bien ce que le cahier des charge me demandait :

 « La redondance porte avant tout sur le traitement. Les services ‘backend’ doivent donc être eux aussi redondés. »

De plus, comme

J’ai un serveur d’email sur gmail (Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!) classique, comme tout le monde

J’ai monté un serveur d’email Postfix en local dans mon labo, domaine localhost , mails moisur@dns-de-mon-fai, ca ne fait pas très pro 

J’ai loué un serveur d’email Postfix dans le cloud, domaine alapache.com (Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!)

J’ai mon lien de session qui est bien répliqué sur 3 serveurs, impossible donc de perdre cette donnée :

Les emails avec les liens de session sont bien répliqués sur les 3 serveurs d’emails

Je montre l’interface de roundcube sur PC avec tous les emails & liens de session

Je surligne en haut l’adresse email Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Mail.ovh.net

C’est bien ce que le client avait demandé sur le cahier des charges:

'Rendre le système de messagerie autonome’ implique un serveur POSTFIX autonome. C’est-à-dire qui est lié à votre propre nom de domaine et qui est capable router les mais directement, sans passer par un relai tel que GMAIL.COM. Le serveur de mail doit être déployé sur un hôte dédié, sur le réseau. Le redonder est aussi quelque chose sur lequel il est nécessaire de réfléchir.'

Voici les serveurs DNS du domaine Alapache, on voit qu’il y a 3 enregistrements MX correspondants aux enregistrements à mes 3 serveurs d’emails (points rouges).

Le chiffre devant le serveur d’email représente la priorité, c'est-à-dire que le round robin tourniquet enverra toujours les emails sur le plus petit chiffre s’il est disponible, c'est-à-dire, le 2. S’il n’est pas disponible, il passera au serveur qui a l’autre chiffre le plus petit, c'est-à-dire le 5.

J’espère que cette vidéo vous plue, cette démonstration de fault tolerance, de reprise sur failover, d’envoi d’emails sur 6 serveurs d’emails.

A bientôt pour d’autres démos.