Deux ans plus tard, voici (enfin) un retour sur les choix que j'ai fais rapport à ce que j'indiquais ici.
- Concernant l'accès aux données: j'ai opté pour le système de fichiers réparti et à tolérance de pannes MooseFS. C'est GPL, stable (il manque toutesfois une vraie recette pour la HA en ce qui concerne le serveur de métadonnées), extrêmement simple à configurer et faire évoluer. L'autre avantage, c'est que vous y accédez comme n'importe quel système de fichiers classique, donc vous n'avez pas à modifier les codes pour en profiter. Par contre, l'utilisation de FUSE fait qu'il n'est pas le plus rapide du monde, ce dont les utilisateurs se plaignent parfois, surtout lorsqu'il est fort sollicité. Actuellement, nous avons 8 chunkservers (serveurs de données), un master (serveur de métadonnées), un metalogger (backup des metadonnées), pour 120To totaux. Le système tourne depuis 1 an ½ et aucune perte de données n'est à signaler. La configuration type d'un chunkserver est: raid 1 2 disques pour l'os (CentOS 6.2 - la bascule du parc de 5 vers 6 est en passe d'être achevée), le reste en JBOD, le tout en ext4.
- Concernant l'authentification/le DNS interne: NIS a laissé la place à FreeIPA. 389 m'avait découragé, je suis un peu hermétique au blabla ldap. C'est assez simple à déployer, ça permet un niveau de sécurité bien plus correct (kerberos), et qui plus est, ça permet de coupler un dns. Cerise sur le gâteau, l'ajout d'une machine est aisée, ça met à jour le DNS tout seul comme un grand…et truc ultime, c'est super facile de faire des réplicas pour assurer la haute-dispo (à la fois pour l'auth et le dns) !
- concernant la problématique de la répartition de la charge: Condor a été choisi. Ici aussi, c'est assez simple d'utilisation, les utilisateurs n'ont pas de difficultés à l'utiliser, les modifications de l'existant pour pouvoir en profiter sont minimes voire nulles. Le fichier de lancement est suffisement simple pour qu'on puisse écrire un script vite fait pour générer le dit fichier de lancement (non, je ne taperais pas 17000 fois argument=fichierX\nQueue\n). Cette simplicité n'empêche pourtant pas de faire des choses bien précises et évoluées si besoin. Et ça marche™. Bref, c'est bonheur quand on traite massivement des données (et assez jouissif de voir le parc cravacher sans que tout se pète la gueule à la montée en charge aussi).
- Concernant la supervision: Après avoir essayé zabbix (package buggé qui voulait pas se connecter à postgres), cacti (dont la détection automatique des machines/services/etc ne fonctionnait pas), je me suis rabattu sur opennms. Certes c'est du java (et ça plante avec le java fourni par défaut sous CentOS 6, avec la VM officielle proprio c'est bon), mais ça reste libre, ça utilise postgres, et l'interface est relativement intuitive, la configuration assez rapide donc c'est tout bon quand on n'a pas trop le temps.
- Concernant le serveur de /home: Ça, c'est mon programme de ce week-end, qui se traduit par: drbd, nfs4, pacemaker et heartbeat. Il ne reste plus qu'à espérer que tout se passera bien :)
- Concernant PostgreSQL: Je n'ai pas encore eu le temps de m'y attaquer. À priori, je m'oriente vers un saut de la 8.3 à la 9.1 (le tout à la mimine, car avec des bases postgis, dump/restore n'est pas suffisant d'après mes essais préliminaires :(), pour utiliser la streaming replication afin d'avoir deux exemplaires des données à jour. Pour la bascule maître/esclave, il ne semble pas encore y avoir de «bonne solution» pour avoir une HA, il faut intervenir à la main. Bref, le sujet reste pour l'instant en suspens.
- Concernant Apache: De même que pour PG, je n'ai pas eu le temps de m'y atteler, et encore moins de regarder les solutions permettant la HA…un jour je reviendrais poster un journal pour parler de ces deux derniers cas :)
Merci pour les conseils que vous m'avez prodigué dans mon 1er et précédent journal !
# merci à toi pour ce retour d'experience
Posté par NeoX . Évalué à 5.
cf le titre
[^] # Re: merci à toi pour ce retour d'experience
Posté par gUI (Mastodon) . Évalué à 3.
Oui, ça c'est du journal pertinent ! Je ne connais pas la moitié des solutions présentées ici, ça me done envie d'y jeter un oeil (ne serait-ce que pour la culture).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Ca chiffre à?
Posté par Zenitram (site web personnel) . Évalué à 2.
Par curiosité, ça sature à combien (I/O et débit) sur quelle type de machine?
Parce que MooseFS a l'air sympa, mais même sans lui, ben pour de la tolérance de panne, ça passe souvent par FUSE...
[^] # Re: Ca chiffre à?
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
C'est assez difficile à chiffrer, puisque rarement seul à utiliser le FS…je peux te donner des chiffres à la louche constatés sur notre parc:
en écriture, une 30aine de mo/sec
en lecture, une 50aine.
http://www.moosefs.org/moosefs-faq.html#average
je pense (et espère un peu j'avoue) que lorsque nous recevrons notre 9ième chunkserver (pareil que la conf citée plus bas mais en version 36 disques) le FS ramera moins en charge de part une meilleure répartition des I/O.
Les écritures sont assez pénalisantes (réplication). Et oubliez mfs si vous travaillez sur des petits fichiers, il n'est pas fait pour, ça vous coutera cher en place, et les perfs seront mauvaises. Voyez plutôt du côté de GlusterFS ?
Je peux te dire qu'une 15aine de codes de calcul qui lisent chacun dans les 400/500mo, et qui en écrivent chacun 200mo font que le FS rame. Tu attends plusieurs secondes le résultat d'un ls. Mais ça ne se vautre pas :)
Une machine type est un 2U, 6 ou 8 cœurs à 2ghz (opteron), 8/16/32go de ram, avec une 3ware 9650 et 12 disques sata 2to 5400rpm, reliée en gbps avec jumbo frames (mtu 7200 à cause de quelques vieilles cartes realtek de brin qui trainent encore pour ne pas les nommer). Je ne déclare pour condor que le nombre de cœurs - 2 et la RAM - 2 ou 3 go histoire d'éviter de (trop) faire swapper les machines, afin de laisser le process chunkserver s'épanouir aussi :)
Quant à la tolérance de panne, elle est dûe à la réplication des données, pas à FUSE en tant que tel.
Un jour, quand tout ça sera production-ready, je passerais en btrfs et utiliserais ceph.
J'ai le temps de voir venir :D
[^] # Re: Ca chiffre à?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Puisqu'il y a un serveur de meta données, le 'ls' devrait être super rapide ?
[^] # Re: Ca chiffre à?
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
sauf quand la machine est chargée comme une mule :) notre serveur de métadonnées sert aussi de chunkserver, et de machine de calcul, donc des fois, elle rame un peu.
Mais sinon, effectivement, toutes les opérations sur les métadonnées sont extrêmement rapides 99% du temps.
# HA avec Apache
Posté par etenil . Évalué à 1.
Super projet.
J'ai mis au point et testé (même si pas encore déployé) un HA d'Apache pour ma boite. Le système se constitue de deux load-balancers liés à la même adresse IP (publique) qui utilisent keepalived. Il y a N nœuds Apache sous les LB (ils ont les mêmes), comme ça la redondance est bien assurée.
Comme mon site stocke tout en BDD, la redondance des données est assurée au niveau de la BDD (plusieurs nodes derrière un LB aussi, mais sur le LAN), mais on pourrait concevoir d'avoir les données sur un NAS ou SAN avec leur propre solution de redondance derrière.
La description pas à pas de ce que j'ai fait date un peu, mais les logiciels n'ont pas fondamentalement changé. La seule grosse différence est que j'utilise mod_proxy_balancer de Apache, qui est très bien fait plutôt que Pound. Mais je connais des gens qui utilisent des LB hardware ; à toi de voir.
Bonne continuation en tout cas et tiens nous au courant!
[^] # Re: HA avec Apache
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
As-tu essayé haproxy ? Parce que quand même au niveau lb c'est quand même la référence et de mon point de vue la rolls.
[^] # Re: HA avec Apache
Posté par etenil . Évalué à 1.
Non je ne connaissais pas. Mon choix s'était porté sur mod_proxy_balancer parce qu'il fait partie d'Apache et est assez simple à configurer. Après on peut aussi le rendre "aware" du contenu du site, cookies etc. de manière à toujours envoyer la même session sur le même esclave derrière (sympa pour la consistence).
Enfin au niveau load balancer, il y a largement le choix, avec toutes les implémentations disponibles, dont certaines hardware. Ça dépend aussi de ce qu'on a derrière, dans certains cas de figure, un LB hardware qui fait un bête round-robin suffit (cookies de session en BDD par exemple).
[^] # Re: HA avec Apache
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Pourquoi il existe des loadbalancers qui ne font pas ça ?
Il me semble que le problème principal de cette solution est justement que tu restes dans le modèle apache soit 1 proc/thread par client. Ce qui constitue une sérieuse limitation.
Du coup tu n'en profite pas pour évacuer les merdes au niveau du proxy. Comment fais tu au niveau du MaxClient ? Tu restes avec la même valeur des deux côtés ? Et pour le keep-alive. Tu en fais en server-side également ? Tu as fais des tests sur de simples attaques par 408 ? Qu'est-ce-que ça donne ? Tu fais le reroutage des requêtes (301, 302) au niveau du proxy ou sur ton backend ?
Si je pose ces questions c'est parce que le sujet m’intéresse hein, y a pas de piège.
[^] # Re: HA avec Apache
Posté par steph1978 . Évalué à 3.
De ce que j'ai compris, Condor permet d'orchestrer des tâches plutôt lourdes - prenant potentiellement toute une machines - et non homogènes dans leurs tailles.
Les solutions de loadbalancing orientées web répartissent la charge de très petites tâches (comparativement à la puissance d'un nœud), très nombreuses et relativement homogènes.
[^] # Re: HA avec Apache
Posté par laurent wandrebeck (site web personnel) . Évalué à 0.
Pour la HA d'apache, vu la charge (hum hum), j'aurais deux VM (kvm) sur deux machines différentes, rien de plus, il faudra que je me débrouille avec ça.
Quant à condor, il ne sert effectivement en rien à la HA, il est là pour faciliter l'utilisation de la puissance à disposition (exemple, on a X images à traiter, avant on bouclait X fois, et seul un cpu cravachait, maintenant, condor se charge de balancer les X tâches sur les cœurs dispo du parc).
# JBOD au lieu de RAID 0/5/6
Posté par 16aR . Évalué à 1.
Bonjour,
Tu utilises du JBOD au lieu d'utiliser du RAID5 ou 6.
Quelle est la raison a part le gain de place ? Un autre niveau (MooseFS ?) s'occupe des backups des données de controle ? Le probleme de performance venant de FUSE ne pourrait pas être amélioré si les temps d'écriture/lecture par defaut des device mapper était plus rapide grace a du RAID0/5/6 ?
En tout cas, merci pour ce retour d'info :)
[^] # Re: JBOD au lieu de RAID 0/5/6
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Les raisons:
- pas de perte de place.
- déjà eu plusieurs raid 5/6 qui survivaient pas à un rebuild car un autre disque explosait en vol pendant le dit-rebuild (avec des gros disques en 5400rpm c'est − un peu − long comme opération).
- pas très bons en écriture les raid 5/6, déjà que mfs n'est pas un foudre de guerre dans ce cas :)
- remplacer un disque unique évite de faire gratter à mort le reste des disques de la machine impliquée (pas bon pour les perfs).
- c'est la réplication de mfs qui se charge de la sécu des données.
Je crois que c'est tout :)
# Pacemaker
Posté par GouNiNi . Évalué à 0.
Pour la partie HA de Apache et Postgre, je partirais sur Pacemaker avec un corosync en dessous.
C'est la solution clustering de service sur Linux la plus en vogue actuellement (Redhat abandonne sa solution pour s'y mettre, Suse l'a adopté depuis un moment). L'avantage c'est que tu as des ocf (glue qui lance et arrête ton service) pour chacun de ces services, c'est à priori prévu pour.
[^] # Re: Pacemaker
Posté par laurent wandrebeck (site web personnel) . Évalué à 0.
J'ai effectivement regardé (de loin) ces softs. pour apache, pas trop trop de soucis, par contre pour pg je ne vois pas trop comment faire du maître/maître et en ayant posé la question à un guru pg ou deux, il faudrait déployer ce genre de choses via londiste et autres bousins qui fonctionnent à grands renforts de triggers.
Ce qui est un peu « too much » pour moi, je n'ai ni le temps ni l'envie de me plonger dans ce genre de softs assez complexes et dont la maintenance ne me paraît pas simple à gérer en cas de souci.
Bref, merci pour tes lumières en tout cas !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.