L’OS à la boule rouge se dote d’un nouvelle arme pour conquérir le monde du stockage.

En effet les armées de lutins courant dans les câbles ou dans les air peuvent désormais répliquer/synchroniser n’importe quel périphérique de stockage, permettant ainsi d’assurer la haute disponibilité de ces derniers.

Après les classes geom (journal, gate, mirror, eli, …) après le port de ZFS, pjd@ améliore encore les possibilités de stockage de FreeBSD.

L’arrivée dans l’arbre officiel se passe ici, annoncée là et relayée par ros ici.

Pour plus d’informations, une page sur le wiki est disponible

Comme je l’expliquais voila quelques jours, je monte en ce moment un proof of concept de solution haute dispo.

Pour ce faire, j’utilise evidemment intensivement la virtualisation, et particulièrement KVM entre autres pour sa parfaite intégration au système Debian, l’OS cible.

Alors que je cherchais de la documentation sur une solution pratique de maquettage de solutions HA utilisant 1. KVM et 2. le standard 802.1Q, je suis tombé sur ceci.

ATTENTION VOYAGEUR DE L’INTARWEBZ, ne clique pas sans avoir lu cet avertissement, ce document est ce qu’on appelle communément un gouffre à temps dans le jardin magique. En effet, tu vas peut-être cliquer pour les mêmes raisons que moi, seulement voila, KVM et 802.1Q ne sont qu’une infime partie des éléments couverts par ce document: VRRP, keepalived, LVS, OpenVPN Multi-Vlan et performances de l’ensemble sont quelques uns des concepts que t’envoie ce document à travers la tronche.

On t’aura prévenu.

Je profite de cette periode de calme pour tenter un nouveau type de nouvelle, “Ask GCU”, à mi chemin entre le forum et l’information.
GCU, c’est au minimum 150 ingénieurs sur IRC, avec chacun leurs experiences, leur connaissances et leurs blagues toujours du meilleur goût. À travers les années, nombre de questions ont trouvé leurs réponses sur le canal, mais même si loggée si dessus, la vie du canal est bien trop mouvementée pour former une knowledge base où puiser rapidement et efficacement (si des lutins parmis vous ont une idée sur la question, j’écouterai les propositions avec intérêt).

Je me lance donc le premier avec une question pour laquelle j’ai un intérêt immédiat et réel.

J’ai démarré un nouveau job voila quelques semaines, et il m’incombe de trouver une methode fiable de Haute Disponibilité. Ma plateforme doit :

• Répondre le plus rapidement possible
• Être tolérante aux pannes
• Permettre le remplacement d’équipement de façon la plus transparente possible
• Être scalable, là encore de manière transparente

Les services visés en premier lieu sont des serveurs HTTP/HTTPS, mais la solution devra probablement assez rapidement pouvoir gêrer d’autres types de services (SMTP,DNS,IMAP…).

Il y a quelques années, dans un autre boulot, c’étaient des Switchs Load Balancers de type Foundry, grâce au protocole VRRP pour la redondance, qui prenaient en charge ces opérations. Dans mon précédent job, c’étaient des machines GNU/Linux équipées d’IPVS affublées d’un script maison pour assurer un semblant de redondance.

Aujourd’hui, des lutins du canal m’ont parlé du couple HAProxy / keepalived qui semble présenter un nombre important d’avantages, comme notamment le fait qu’il fonctionne parfaitement sous Xen (au contraire d’IPVS) ou encore sa capacité à gêrer la persistance de session.

Et vous, avez-vous mis en place ce type d’architecture ? Si oui, quel menu avez-vous choisi ? (réponses souhaitées en commentaire evidemment)

Alors que je réalisais une petite étude pour le boulot sur une architecture LDAP hautement disponible, je suis tombé sur cette page, dans laquelle l’auteur nous explique comment monter, à moindres frais, une architecture HA à base d’OpenLDAP multimaitre, IPVS et heartbeat

En prime, ce document, également orienté scalability, expose benchmarks et chiffres qui seront du meilleur effet sur la table de votre service marketing favori.

“L’opainesoursse ? mais ça marchera jamais enfin !”(c)