URL: https://linuxfr.org/users/low/journaux/quelles-solutions-adopter-pour-ameliorer-un-parc-existant-la-suite Title: Quelles solutions adopter pour améliorer un parc existant ? La suite ! Authors: laurent wandrebeck Date: 2012-02-01T17:45:37+01:00 License: CC By-SA Tags: ldap, cluster, hpc, administration_système, retour_d_expérience, administration et système_de_fichiers Score: 30 Deux ans plus tard, voici (enfin) un retour sur les choix que j'ai fais rapport à ce que j'indiquais [ici](https://linuxfr.org/users/low/journaux/quelles-solutions-adopter-pour-am%C3%A9liorer-un-parc-existant). * Concernant l'accès aux données: j'ai opté pour le système de fichiers réparti et à tolérance de pannes [MooseFS](http://www.moosefs.org/). 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](http://fr.wikipedia.org/wiki/Filesystem_in_Userspace) 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](http://fr.wikipedia.org/wiki/JBOD), le tout en ext4. * Concernant l'authentification/le DNS interne: NIS a laissé la place à [FreeIPA](http://freeipa.org/page/Main_Page). 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](http://research.cs.wisc.edu/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](http://www.zabbix.com/) (package buggé qui voulait pas se connecter à [postgres](http://www.postgresql.org/)), [cacti](http://www.cacti.net/) (dont la détection automatique des machines/services/etc ne fonctionnait pas), je me suis rabattu sur [opennms](http://www.opennms.org). 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](http://www.drbd.org/), [nfs4](http://fr.wikipedia.org/wiki/Network_File_System), [pacemaker](http://www.clusterlabs.org/) et [heartbeat](http://linux-ha.org/wiki/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](http://wiki.postgresql.org/wiki/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 !