tag:linuxfr.org,2005:/users/lowLinuxFr.org : les contenus de laurent wandrebeck2012-02-14T17:17:41+01:00/favicon.pngtag:linuxfr.org,2005:Diary/321232012-02-01T17:45:37+01:002012-02-01T17:45:37+01:00Quelles solutions adopter pour améliorer un parc existant ? La suite !Licence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<p>Deux ans plus tard, voici (enfin) un retour sur les choix que j'ai fais rapport à ce que j'indiquais <a href="https://linuxfr.org/users/low/journaux/quelles-solutions-adopter-pour-am%C3%A9liorer-un-parc-existant">ici</a>.</p>
<ul><li>Concernant l'accès aux données:
j'ai opté pour le système de fichiers réparti et à tolérance de pannes <a href="http://www.moosefs.org/">MooseFS</a>. 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 <a href="http://fr.wikipedia.org/wiki/Filesystem_in_Userspace">FUSE</a> 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 <a href="http://fr.wikipedia.org/wiki/JBOD">JBOD</a>, le tout en ext4.</li>
<li>Concernant l'authentification/le DNS interne:
NIS a laissé la place à <a href="http://freeipa.org/page/Main_Page">FreeIPA</a>. 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) !</li>
<li>concernant la problématique de la répartition de la charge:
<a href="http://research.cs.wisc.edu/condor/">Condor</a> 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).</li>
<li>Concernant la supervision:
Après avoir essayé <a href="http://www.zabbix.com/">zabbix</a> (package buggé qui voulait pas se connecter à <a href="http://www.postgresql.org/">postgres</a>), <a href="http://www.cacti.net/">cacti</a> (dont la détection automatique des machines/services/etc ne fonctionnait pas), je me suis rabattu sur <a href="http://www.opennms.org">opennms</a>. 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.</li>
<li>Concernant le serveur de /home:
Ça, c'est mon programme de ce week-end, qui se traduit par: <a href="http://www.drbd.org/">drbd</a>, <a href="http://fr.wikipedia.org/wiki/Network_File_System">nfs4</a>, <a href="http://www.clusterlabs.org/">pacemaker</a> et <a href="http://linux-ha.org/wiki/Heartbeat">heartbeat</a>. Il ne reste plus qu'à espérer que tout se passera bien :)</li>
<li>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 <a href="http://wiki.postgresql.org/wiki/Streaming_Replication">streaming replication</a> 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.</li>
<li>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 :)</li>
</ul><p>Merci pour les conseils que vous m'avez prodigué dans mon 1er et précédent journal !</p><div><a href="https://linuxfr.org/users/low/journaux/quelles-solutions-adopter-pour-ameliorer-un-parc-existant-la-suite.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/89283/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/low/journaux/quelles-solutions-adopter-pour-ameliorer-un-parc-existant-la-suite#comments">ouvrir dans le navigateur</a>
</p>
laurent wandrebeckhttps://linuxfr.org/nodes/89283/comments.atomtag:linuxfr.org,2005:News/270532010-06-24T23:27:18+02:002010-06-24T23:27:18+02:00MooseFS, système de fichier réparti à tolérance de panne<div>MooseFS est un système de fichiers distribué méconnu regorgeant de qualités.
<br />
<br />
En vrac :<ul><li>Le code est distribué sous GPLv3 ;
<br />
</li><li>Il utilise <a href="http://fr.wikipedia.org/wiki/Filesystem_in_Userspace">FUSE</a> et fonctionne en espace utilisateur ;
<br />
</li><li>Il dispose d'une poubelle automatique à durée de rétention modifiable à souhait ;
<br />
</li><li>Il est très simple à déployer et administrer : comptez une heure, lecture de la documentation comprise pour avoir un serveur maître et quatre serveurs de données fonctionnels ;
<br />
</li><li>Compatible <a href="http://fr.wikipedia.org/wiki/POSIX">POSIX</a>, il ne requiert aucune modification des programmes pour pouvoir y accéder ;
<br />
</li><li>L'ajout de machines pour agrandir l'espace disponible est d'une simplicité enfantine ;
<br />
</li><li>Vous choisissez le nombre de réplicas que vous désirez, par fichier ou par répertoire, pour la tolérance de panne, avec une seule commande, le tout à chaud…</li></ul>
<br />
Le développement de MooseFS a débuté en 2005, et il a été libéré le 30 mai 2008.</div><ul><li>lien nᵒ 1 : <a title="http://www.moosefs.org/" hreflang="en" href="https://linuxfr.org/redirect/67826">Site officiel de MooseFS</a></li><li>lien nᵒ 2 : <a title="https://lists.sourceforge.net/lists/listinfo/moosefs-users" hreflang="en" href="https://linuxfr.org/redirect/67827">Liste de diffusion</a></li><li>lien nᵒ 3 : <a title="http://centos.kodros.fr/" hreflang="en" href="https://linuxfr.org/redirect/67828">Dépôt CentOS</a></li></ul><div><b>MooseFS est un système de fichiers méconnu regorgeant de qualités :</b>
<br />
<br />
Un peu d'histoire. Une société polonaise a, pour ses besoins internes, développé (en C) un système de fichiers réparti et à tolérance de panne. Il a fini par être libéré (sous l'impulsion seule de la société semble-t-il), sous licence GPLv3, en décembre 2009.
<br />
<br />
Reposant sur l'utilisation de FUSE, le système de fichier est compatible POSIX et ne nécessite aucune adaptation des programmes pour pouvoir l'utiliser ! Il est donc fonctionnel sous tous les systèmes disposant de FUSE (GNU/Linux, *BSD…).
<br />
<br />
C'est stable ! Le plus gros déploiement connu monte à 1.5 Pio, ce qui n'est pas tout à fait négligeable. D'autres déploiements existent, et sont tous de l'ordre de la dizaine ou centaine de Tio.
<br />
<br />
Il est très simple d'assurer une réplication de vos données par une simple commande :
<br />
<i>mfssetgoal GOAL fichier ou chemin</i>
<br />
Un simple -r pour la récursivité vous permet d'appliquer cette valeur de manière… récursive, comme son nom l'indique. Le tout est géré de manière transparente, avec le système de fichier monté et en production. La hausse, mais aussi bien sûr la baisse du nombre de réplicas sont gérées.
<br />
<br />
Le système est réparti : les fichiers sont découpés en paquets de 64 Mio et distribués sur les machines dites « chunkserver », ou encore serveurs de données. Les fichiers inférieurs à cette taille ne sont, bien entendu, pas concernés par cette découpe.
<br />
<br />
MooseFS tolère les pannes : si, et seulement si (en toute logique), vous avez indiqué un « but » (voir réplication des données un peu plus haut) supérieur à 1 pour vos fichiers, la disparition d'un serveur de données ne gênera pas la disponibilité des données. Bien sûr, cela a un coût en matière de place, mais la disponibilité à un prix.
<br />
<br />
Il est aussi tout à fait possible d'agrandir le volume. Il suffit d'ajouter une ou des machines, de les configurer en tant que serveur de données (installation, dix secondes via apt-get ou yum, configuration, deux lignes à changer, trente secondes, lancement du service compris, vous en avez pour une minute !). Le serveur maître les détectera, et la répartition des données vers les nouveaux arrivés débutera sans que vous deviez intervenir !
<br />
<br />
Un système de poubelle à durée de rétention configurable est disponible par défaut. Tout fichier supprimé s'y retrouve tant que la durée de rétention n'est pas dépassée. Fini les rm malheureux sur des données non sauvegardées (ou dont la récupération est un calvaire).
<br />
<br />
Enfin, un serveur en Python permet de visualiser aisément et rapidement l'état du volume, la charge des serveurs, etc.
<br />
<br />
<b>Bien sûr, tout n'est pas si parfait.</b>
<br />
<br />
Il n'existe pas (encore) de procédure simple pour assurer la haute disponibilité du système de fichier. En effet, un serveur maître se doit d'être présent pour permettre les montages et l'accès aux données. Si le maître tombe, les fichiers ne sont plus accessibles.
<br />
<br />
Un serveur dit « metalogger » peut être mis en place. Il recueille tous les événements du système de fichier et peut permettre, si le maître est vraiment mal en point (perte de ses metadada, ou de son historique), de lui faire rejouer les logs pour que le volume reste cohérent.
<br />
<br />
La documentation est légère, tout comme les commentaires dans le code. À noter qu'il est prévu l'implémentation d'un algorithme permettant d'obtenir l'équivalent de quatre réplicas des données pour le coût physique de deux. Pour le moment, un fichier avec un « goal » de 3 prendra 3 fois sa taille d'origine (peu ou prou). Enfin, un canal IRC, #moosefs est ouvert depuis peu sur freenode, où vous êtes bien entendu les bienvenus.</div><div><a href="https://linuxfr.org/news/moosefs-systeme-de-fichier-reparti-a-tolerance-de-panne.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/26030/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/moosefs-systeme-de-fichier-reparti-a-tolerance-de-panne#comments">ouvrir dans le navigateur</a>
</p>
laurent wandrebeckhttps://linuxfr.org/nodes/26030/comments.atomtag:linuxfr.org,2005:Diary/291592009-12-15T12:25:58+01:002009-12-15T12:25:58+01:00Quelles solutions adopter pour améliorer un parc existant ?
Bonjour à tous,<br />
<br />
Pour mon premier journal, j'aimerais titiller les neurones des admins systèmes qui moulent dans le coin :)<br />
<br />
Pour donner ma situation, admin sys/réseau/bdd/dév/etc dans une toute petite PME, donc l'admin est parent (très) pauvre.<br />
Je vous explique en gros notre parc actuel: (sachant qu'il a grossi machine par machine)<br />
<br />
1 serveur NIS/NFS qui sert /home, qui fait aussi DNS interne et Samba.<br />
1 serveur PostgreSQL/PostGIS<br />
1 serveur Web<br />
1 serveur ssh/ftp<br />
1 machine de sauvegarde de /home<br />
une dizaine de serveurs de calcul et stockage,<br />
6 machines utilisateurs<br />
<br />
Tout les serveurs sont en gbps (switchs compris), avec un dual/quad, 8go de ram, CentOS 5.4 x86_64, une 3ware et les disques qui vont avec (de 2 à 14to par machine - pour un total d'environ 70).<br />
<br />
Ce que j'envisage de/aimerais faire:<br />
1) Basculer NIS/NFS vers Centos Directory Server (389)<br />
2) Virtualiser la machine de sauvegarde pour:<br />
- faire une réplication 389 pour reprise d'activité à chaud (fonctionnalité fournie de base semble-t-il) + réplication des données /home (nfs toujours ?)<br />
- faire une réplication PostgreSQL pour…reprise d'activité à chaud (Log Shipping ?)<br />
- faire une réplication Apache (?) pour…<br />
3) Enfin, idéalement, j'aimerais pouvoir transformer chaque machine de calcul et son stockage en une grappe/grille. Histoire que les utilisateurs ne voient plus qu'une machine et un espace de stockage. Et que les tâches soumises s'y répartissent comme des grandes. Actuellement, chaque serveur est « dédié » à un satellite, et bien sûr, petits moyens, y'a un peu de tout partout, donc des montages nfs dans tous les sens.<br />
<br />
Les contraintes:<br />
1) Ne pas empêcher les utilisateurs de bosser - ou un minimum.<br />
2) L'espace disque dispo est rare, pas plus de 10To. Il n'est pas (ou difficilement) envisageable de devoir déplacer toutes les données. Au mieux, une machine peut être « nue » pour enclencher la création de la grille/grappe. Pas de budget.<br />
3) Il est inenvisageable de devoir réécrire/ modifier lourdement les codes existants pour qu'ils fonctionnent normalement dans la grille/grappe<br />
4) Le déploiement doit être relativement rapide.<br />
5) Cela ne doit pas être trop compliqué, parce que je débute en matière de grilles/grappes. Et que je ne peux pas me consacrer à 100% à l'admin.<br />
6) Idéalement, la notion de proximité des données est la bienvenue. Comme on traite des images satellite, on lit/écrit pas mal de Go. Si on peut éviter au mieux la latence/relative lenteur du réseau c'est un plus.<br />
<br />
Je pensais éventuellement à XtreemOS et XtreemFS, hadoop est hors course du fait du travail nécessaire pour l'adaptation map/reduce. Mais j'avoue être un peu perdu dans tout ça, et il n'est pas simple de comparer les solutions existantes.<br />
<br />
Pensez-vous que le plan d'évolution soit viable ? sain ? Faut-il utiliser autre chose que 389 qui semble-t-il fonctionne bien et est assez simple à administrer ?<br />
Quels outils me conseilleriez-vous pour faire la grille/grappe ?<br />
<br />
Bref, vos conseils, votre expérience m'intéressent.<br />
<br />
Merci d'avance !<div><a href="https://linuxfr.org/users/low/journaux/quelles-solutions-adopter-pour-am%C3%A9liorer-un-parc-existant.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/55461/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/low/journaux/quelles-solutions-adopter-pour-am%C3%A9liorer-un-parc-existant#comments">ouvrir dans le navigateur</a>
</p>
laurent wandrebeckhttps://linuxfr.org/nodes/55461/comments.atomtag:linuxfr.org,2005:News/181572005-01-25T17:44:59+01:002005-01-25T17:44:59+01:00Metalog - Reprise du développement<div>Après presque deux années d'inactivité, Metalog, confrère de syslogd et syslog-ng, reprend son évolution. Bien que manquant encore de certaines fonctionnalités, la simplicité et la flexibilité de son fichier de configuration en font un logiciel rapidement pris en main.
<br />
Après tant de silence, le projet a bien évidement perdu en popularité, et cette dépêche est là pour renverser la tendance. Ainsi, pour vous amuser, une nouvelle version est disponible, la 0.8-rc1.
<br />
Les modifications sont les suivantes:
<br />
* Ajout d'une page de manuel pour metalog.conf.
<br />
* Correction d'un bogue sur l'enregistrement des messages noyaux.
<br />
* La rotation des journaux peut être désactivée.
<br />
* Un nouveau mot-clé (break) améliore la flexibilité du fichier de configuration.
<br />
* Un bogue possible (race condition) sur le lancement de processus fils a été corrigé.
<br />
<br />
Tests, rapport de bogues, et correctifs sont les bienvenus :)</div><ul><li>lien nᵒ 1 : <a title="http://metalog.sourceforge.net/" hreflang="en" href="https://linuxfr.org/redirect/39574">Page principale</a></li><li>lien nᵒ 2 : <a title="http://prdownloads.sourceforge.net/metalog/metalog-0.8-rc1.tar.gz?download" hreflang="en" href="https://linuxfr.org/redirect/39575">Téléchargement (0.8-rc1)</a></li></ul><div>Bien que n'ayant pas atteint le Saint-Graal 1.0, Metalog est d'ores et déjà parfaitement utilisable. Les prochaines fonctionnalités qui vont être implémentées sont les suivantes:
<br />
* Compression des journaux.
<br />
* Possibilité d'enregistrer les journaux de machines distantes.
<br />
* Ajouter la gestion du signal SIGHUP pour prendre en compte les modifications du fichier de configuration.
<br />
* Rendre le format des lignes de journaux entièrement configurable.
<br />
* Permettre l'utilisation d'unités (Ko, Mo...) pour la taille des journaux.
<br />
* Fonctionnalité identique dans le cadre du temps de rotation des journaux.
<br />
<br />
Si une fonctionnalité citée (ou non) vous intéresse, n'hésitez pas à proposer voter contribution !</div><div><a href="https://linuxfr.org/news/metalog-reprise-du-developpement.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/17470/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/metalog-reprise-du-developpement#comments">ouvrir dans le navigateur</a>
</p>
laurent wandrebeckhttps://linuxfr.org/nodes/17470/comments.atomtag:linuxfr.org,2005:News/103882002-11-22T10:07:42+01:002002-11-22T10:07:42+01:00GCC 3.2.1<div>Bien qu'en retard par rapport à la date initiale de sortie prévue, la nouvelle mouture de gcc est disponible.
<br />
La page principale du site de gcc n'est pas encore à jour, mais les mirroirs eux le sont. Au menu corrections de bogues bien sûr, et aussi des améliorations.</div><ul><li>lien nᵒ 1 : <a title="http://gcc.gnu.org" hreflang="en" href="https://linuxfr.org/redirect/19479">GCC Homepage</a></li><li>lien nᵒ 2 : <a title="http://gcc.gnu.org/gcc-3.2/changes.html" hreflang="fr" href="https://linuxfr.org/redirect/19480">Changelog</a></li><li>lien nᵒ 3 : <a title="ftp://ftp.club-internet.fr/pub/gcc/" hreflang="fr" href="https://linuxfr.org/redirect/19481">mirroir français (Club-int)</a></li><li>lien nᵒ 4 : <a title="ftp://ftp.uvsq.fr/pub/gcc/" hreflang="fr" href="https://linuxfr.org/redirect/19482">Autre miroir français</a></li><li>lien nᵒ 5 : <a title="ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/" hreflang="fr" href="https://linuxfr.org/redirect/19483">encore un autre</a></li><li>lien nᵒ 6 : <a title="ftp://ftp.lip6.fr/pub/gcc/" hreflang="fr" href="https://linuxfr.org/redirect/19484">un dernier pour la route</a></li></ul><div></div><div><a href="https://linuxfr.org/news/gcc-321.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/9742/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/gcc-321#comments">ouvrir dans le navigateur</a>
</p>
laurent wandrebeckhttps://linuxfr.org/nodes/9742/comments.atomtag:linuxfr.org,2005:News/34892001-05-11T09:42:55+02:002001-05-11T09:42:55+02:00Le Window Maker nouveau est arrivé<div>La version 0.65.0 de Window Maker, qualifiée de "major release" est disponible. Au programme: Correction de nombreux bugs, notamment relatifs à Gnome, les appicons, l'affichage. Quelques améliorations aussi au niveau de la rapidité. L'API de WING a évolué, ainsi que la bibliothèque wraster. D'après l'équipe de Windowmaker, le nouveau site ne devrait pas tarder à faire son apparition, avec une nouvelle interface et une maintenance facilitée.</div><ul><li>lien nᵒ 1 : <a title="http://www.windowmaker.org" hreflang="en" href="https://linuxfr.org/redirect/5529">Le site officiel</a></li><li>lien nᵒ 2 : <a title="http://windowmaker.org/src/ChangeLog" hreflang="en" href="https://linuxfr.org/redirect/5530">Le Changelog</a></li><li>lien nᵒ 3 : <a title="http://windowmaker.org/src/NEWS" hreflang="en" href="https://linuxfr.org/redirect/5531">Les NEWS</a></li></ul><div></div><div><a href="https://linuxfr.org/news/le-window-maker-nouveau-est-arrive.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/3473/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/le-window-maker-nouveau-est-arrive#comments">ouvrir dans le navigateur</a>
</p>
lowhttps://linuxfr.org/nodes/3473/comments.atomtag:linuxfr.org,2005:News/33282001-04-27T10:51:08+02:002001-04-27T10:51:08+02:00Le ftp de la slack est de retour :)<div>Depuis le 24, le ftp sur lequel la slackware est disponible est de retour. Sans revenir sur les problèmes avec BSDi, la distro est dorénavant hébergée chez sourceforge. Les afficionados de la Slackware seront heureux d'apprendre que les urls restent les mêmes :)</div><ul><li>lien nᵒ 1 : <a title="http://www.slackware.com" hreflang="en" href="https://linuxfr.org/redirect/5219">Site Officiel de la Slackware</a></li><li>lien nᵒ 2 : <a title="http://www.linuxmafia.org" hreflang="en" href="https://linuxfr.org/redirect/5220">Site proposant des packages Slackware</a></li><li>lien nᵒ 3 : <a title="http://www.userlocal.com" hreflang="en" href="https://linuxfr.org/redirect/5221">News concernant la Slackware</a></li></ul><div></div><div><a href="https://linuxfr.org/news/le-ftp-de-la-slack-est-de-retour.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/3314/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/le-ftp-de-la-slack-est-de-retour#comments">ouvrir dans le navigateur</a>
</p>
lowhttps://linuxfr.org/nodes/3314/comments.atom