par Ha ! La Haute dispo… Une quête permanente pour les administrateurs modernes que nous sommes…
Mais derrière cette notion se cache une petite galaxie de services, de couches, de notions et de termes plus obscurs encore…
Cluster,Failover, Loabalancer, Proxy, VIP, … beaucoup de choses étranges que l’on peut croiser. Il est temps de tenter d’y voir plus clair.
Je préviens, cet article n’est pas un article de fond, mais juste un rapide survol pour permettre d’y voir déjà un peu plus clair en tenter d’en dégager une logique commune.
Voyez le comme une introduction pour les futurs articles qui arriveront.
I – On débroussaille
Quand on parle « Haute Dispo, » on entend généralement par la qu’un service doit rester disponible même en cas de panne d’un serveur.
Les opérations de maintenance s’en retrouve aussi simplifiées, il est possible de travailler sur un serveur sans impacter le service.
Expliqué de la sorte, tout compte fait, ça a l’air plutôt simple, mais selon les services, les besoins, les envies, plusieurs options sont possibles et il convient alors de faire le bon choix.
Pour tenter de clarifier le tout, j’ai séparé la « Haute Dispo » en trois « couches » :
- Cluster : comment rendre les données, les services, redondants.
- Proxy, Loadbalancer : comment accéder à ces données, services.
- VIP (Virtual IP) : faire en sorte que le point d’entrée soit lui aussi toujours disponible.
Tout n’est pas obligatoire selon les cas et il arrive même que certains types de cluster particuliers gèrent déjà des fonctions de Proxy/Loadbalancer, VIP en interne mais la philosophie restera la même.
Les deux fonctions Proxy/LB et VIP sont d’ailleurs fortement liées.
A – Le Cluster
Au niveau « grappe de serveur », on rencontre deux catégories :
1 – Actif/Actif
Nous sommes avec plusieurs serveurs avec un contenu toujours identique, une réplication de type Master/Master.
Les accès en lecture et écriture peuvent se faire indépendamment sur n’importe quel nœud du cluster et la problématique des écritures simultanées est gérée (soit par le cluster lui même, soit par un autre mécanisme).
Exemples : Cluster Web, Cluster SQL (on peut aussi les faire en Actif/Passif, mais je parle des exemples que j’ai moi même en production).
2 – Actif/Passif
La aussi, plusieurs serveurs, mais un seul est le Master , le ou les autres sont des Slave(s).
Au niveau fonctionnement :
- Le service nécessite des écritures et des lectures : si le Master tombe, le Slave doit devenir Master (via un mécanisme du cluster). Ce dernier pourra alors supporter le service. Par exemple, Redis.
- Le service ne nécessite que des lectures ( l’écriture ne concerne que l’administration de ces services): en cas de Down du Master, on peut tout à fait garder le Slave dans son rôle de Slave. Par exemple, LDAP, DNS.
Dans le cas d’un service avec écritures et lectures, on peut aussi envisager de faire les écritures sur un serveur et les lectures sur l’autre. Par exemple, Redis en guise de tampon entre Filebeat et Logstash.
B – Proxy, Loadbalancer
Nos données sont en cluster, répliquées, etc… En cas de Down d’un serveur, elles sont toujours bien présentes. Très bien, mais maintenant il s’agit d’y accéder !
L’idée étant de ne plus demander directement un des nœuds du cluster (s’il est planté, on fait quoi ?), mais à quelque chose en amont qui se chargera d’envoyer la requête ou il faut.
On trouve la plusieurs solutions : HAProxy, Nginx, ProxySQL, etc…
A chaque type de cluster sa ou ses solutions. Et à noter au passage, certains cas ne nécessitent pas forcement cette « couche », selon le design retenu (LDAP par exemple, voir plus bas).
C – LES VIPS
Maintenant, il faut faire en sorte que notre Proxy/Loadbalancer soit toujours accessible. Introduisant un POF avec ce point d’accès unique, ce serait dommage de perdre l’accès au service fourni par le cluster alors que celui-ci se porte comme un charme.
C’est au final la partie la plus simple car il suffit de « dupliquer » le serveur et de mettre en place une VIP, IP virtuelle, qui sera soit sur l’un soit sur l’autre en cas de défaillance.
Pour faire ça, on trouve généralement d’un côté Keepalived et de l’autre Hearbeat (ou plus moderne, Pacemaker avec Corosync)
Alors la, pour la différence, c’est plus dans la philosophie du logiciel que dans son fonctionnement qu’il faut la chercher, arrivant au final au même résultat avec les deux.
Si vous posez la question à Internet, on retrouve une espèce de consensus :
- Heartbeat (ou Pacemaker/Corosync) est utile quand on doit avoir une ressource présente et active une seule fois. De par son architecture, c’est son fonctionnement (et si l’on poussait le vice, on ne lui laisserait que cela, et la VIP serait alors pour Keepalived). Mais comme il peut gérer cela aussi, autant tout faire d’un coup.
Design : on a deux serveurs avec Heartbeat, le service proposé est UP sur l’un et DOWN sur l’autre et la VIP suit la ou le service est UP.
Exemple: DRBD, voir les exemples plus bas.
- Keepalived est utilisé dans des configurations où une ressource peut être présente plusieurs fois activement sans que cela ne gêne. Selon un paramètre, la VIP est sur l’un des serveurs.
Design : on a deux serveurs avec Keepalived, qui proposent un service UP.
Exemple: HAProxy. Qu’il tourne sur les deux machines en parallèle (bien qu’un seul soit activement utilisé) ne bloque en rien le système.
Keepalived peut tout à faire ce que fait Heartbeat, mais la configuration est sensiblement plus lourde.
A l’usage, pour ma part : si ça le fait avec Keepalived, alors roule pedro.
II – Des exemples
Quelques exemples et comment je met en œuvre.
A – WEB
Cluster de type Actif/Actif, plusieurs Nginx configurés à l’identique, sur un partage NFS pour servir le même contenu.
Pour la partie Loadbalancer, Haproxy peut le faire tout comme Nginx. Il nous faut également un point de terminaison SSL et cela tombe bien, les deux peuvent le faire aussi.
Mais présentement, je garde les deux: Nginx en reverse proxy avec terminaison SSL et derrière HAProxy pour le loadbalancing. A chacun sa tâche.
D’un point de vue optimisation, j’ajoute aussi au passage du cache Varnish.
Par contre, d’un point de vue fonctionnel, il faut penser également à la gestion des « données » écrites. Typiquement : les sessions PHP. Dans ce cas, un Redis commun fait l’affaire et permet en plus de gérer d’autres cas de locks.
Pour la VIP, Keepalived avec des chekcs sur l’accès aux sites, ainsi, je vérifie à la fois le bon fonctionnement de Nginx et de Haproxy.
De toute façon, l’article la dessus arrivera un jour et détaillera tout comme il faut.
B – SQL
Cluster de type Actif/Actif, trois serveurs MariaDB, etc, … je détaille tout dans l’article consacré. Il y aura une prochaine update, mais en attendant, il reste valable.
Seul HAProxy n’était pas redondé à l’époque.
C – NFS
Cluster de type Actif/Passif, deux serveurs avec Drbd pour le coté stockage redondant et serveur NFS pour le partage. Ce dernier ne peut être UP qu’un sur un seul serveur, étant donné que côté Drbd, la partition n’est présente que sur le serveur primaire. Donc, la, c’est Hearbeat qui prendra le poste.
Rendez vous sur l’article dédié pour en savoir plus.
D – REDIS
Cluster de type Actif/Passif, deux serveurs, 1 Master, 1 Slave. Gestion de l’état Master/Slave par Redis Sentinel : le Slave passe Master si le Master tombe.
Pour la VIP, Keepalived sur les deux serveurs avec check de Redis en état Master pour définir ou se trouve la VIP.
Y’a cependant une astuce, car un loadbalancer est nécessaire dans un cas de figure (si Keepalived lui même tombe). Je détaille tout dans le prochain article à venir.
E – LDAP
Cluster de type Actif/Passif, deux serveurs, 1 Master, 1 Slave. Pas de changement d’état sur le Slave si le Master tombe.
Keepalived pour la VIP avec vérification de l’accès à l’annuaire. Si le Slave prend la VIP sur une panne du Master, c’est transparent vu que les opérations ne sont que des lectures.
Dans mon article dédié, je fais bien plus compliqué, mais je suis revenu en arrière et j’adopte maintenant un classique Master/Slave.
F – DNS
Même idée que pour le LDAP, le besoin étant avant tout de pouvoir « lire ».
G – MAIL
On pourrait faire compliquer la aussi, mais pourquoi ne pas faire un MX de secours en cas de Down du premier ? C’est prévu dans le fonctionnement du mail à la base après tout…
Un futur article en prévision…
V – Conclusion
Difficile de rester encore généraliste, car à chaque cluster que l’on veut monter, c’est vraiment toute une réflexion complète qu’il faut mener.
En fonction de ce dont vous avez besoin, de ce que vous pouvez pour permettre, de ce que d’autres contraintes peuvent imposer, etc…
J’espère que pour ceux qui n’y connaissaient rien, c’est déjà un peu moins flou, les experts, pardonnez mes raccourcis…
Pour résumer, il faut retenir que pour une « Haute Dispo », nos données doivent être répliquées (la méthode change selon le service).
Ensuite, il faut un point d’entrée réseau en adoptant la logique nécessaire selon le cas pour la répartition.
Et pour terminer, ce point d’entrée doit être redondant avec la mise en place d’une VIP.
Dans certains cas, on peut tout regrouper sur les serveurs de données (serveur, proxy et gestion de la VIP), dans d’autres, on doit les mettre sur d’autres machines. Un cluster Redis peut tourner sur juste deux serveurs, DNS, LDAP également. Un cluster MariaDB, pour permettre l’usage de la fonctionnalité proxy (passage de l’IP client au serveur, une nouveauté que je traiterais la aussi dans un futur article), nécessite que le LB soit différent du serveur, du coup, architecture avec 5 serveurs.
De toute façon, restez à l’écoute, je vais tout traiter dans des articles à venir.
Je précise que les exemples que je donne, les méthodes, etc.., tout n’est pas forcement à faire tel quel dans votre environnement, ou selon vos besoins.
Comme souvent, on peut faire de mille façons une chose , mais on ne peut pas faire de mille façons mille choses…. heu, j’vais prendre le chewing-gum…
Je donne des idées, des pistes… Et comme d’habitude, vos améliorations, suggestions, remarques sont les bienvenues !
