Menu principal

Statut de la page

Nagios : de l’open source à l’open core ?

L’open core : Community/Enterprise Je viens de tomber sur deux posts intéressants ici et là qui traitent d’un problème qui se répand de plus en plus dans les logiciels ouverts touchant au monde de l’administration et supervision système : le modèle Community/Enterprise, déjà utilisé par Zenoss par exemple. Ce modèle à un nom en fait : open core. Le principe est simple : une version open source, nommée Community, est fournie. Une version Enterprise, privatrice, est également présente et est la seule version supportée par la société éditrice du logiciel . Cette [...]
Lire la suite
Vus : 679
Publié par Naparuba : 7

Art of (free software) war

Ce texte fait suite à la lecture de trois ouvrages : « Richard Stallman et la révolution du logiciel libre », « L’art de la guerre » de Sun Tzu, et « Traité de l’efficacité » de François Jullien. Si le premier est une oeuvre bien connue des acteurs du monde du libre, les deux dernières méritent également d’être lues. L’art de la guerre est le grand classique sur la vision des affrontements du point de vue chinois. Le second en est un approfondissement. Il présente les pensés occidentales et orientales de l’efficacité de la guerre, mais aussi plus généralement de toute activité humaine. Ce sont justement ces idées que je vais tenter d’appliquer au monde du libre. Je n’ai fait que tenter d’appliquer ce [...]
Lire la suite
Vus : 622
Publié par Naparuba : 7

Déduplication : bloc fixe VS bloc variable

Intérêt de la dé-duplication J’ai testé il y a quelques temps le filesystem lessfs (site officiel du projet). C’est un filesystem très simple à mettre en place, de type Fuse (donc en user space) qui permet de monter un espace de dé-duplication à la volée.  Cette fonctionnalité permet de gagner une place considérable lorsque l’on a des données qui se ressemble fortement. Elle est complémentaire de la compression. Là où vous aller gagner sur un fichier avec la compression, si vous en avez deux, vous aller stocker deux fois la taille compressée. Avec une passe de dé-duplication avant, vous n’aurez qu’une fois chaque bloc, puis vous pouvez compresser ce qui reste. Deux méthodes : bloc de taille fixe ou variable Taille fixe Les blocs justement. Dans lessfs, [...]
Lire la suite
Vus : 557
Publié par Naparuba : 7

Déduplication : bloc fixe VS bloc variable

Intérêt de la dé-duplication J’ai testé il y a quelques temps le filesystem lessfs (site officiel du projet). C’est un filesystem très simple à mettre en place, de type Fuse (donc en user space) qui permet de monter un espace de dé-duplication à la volée.  Cette fonctionnalité permet de gagner une place considérable lorsque l’on a des données qui se ressemble fortement. Elle est complémentaire de la compression. Là où vous aller gagner sur un fichier avec la compression, si vous en avez deux, vous aller stocker deux fois la taille compressée. Avec une passe de dé-duplication avant, vous n’aurez qu’une fois chaque bloc, puis vous pouvez compresser ce qui reste. Deux méthodes : bloc de taille fixe ou variable Taille fixe Les blocs justement. Dans lessfs, ce sont des blocs de taille fixe. Donc on applique un algorithme très [...]
Lire la suite
Vus : 592
Publié par Naparuba : 7

Administration et supervision de HeartBeat/Ldirectord/IPVS

On a conçu une solution de load balancing et de répartition de charge et nous l’avons mis en place. Le travail n’est pas fini pour autant. Il nous reste à administrer et superviser ces outils. On peut administrer la solution à plusieurs niveaux : Heartbeat IPVS HeartBeat Heartbeat est particulièrement résilient. Il est plus que rare de le voir défaillir. Par contre il peut être utile de voir l’allocation des ressources et l’états des noeuds. Par exemple pour voir l’état d’un noeud, il faut lancer la commande : /usr/bin/cl_status nodestatus frontal2 Elle va afficher : cl_status[22045]: 2009/06/30_14:56:43 debug: optind: 1   argv[optindex+1]: frontal2 active On voit ici que le second noeud est bien en [...]
Lire la suite
Vus : 1115
Publié par Naparuba : 7

Mise en place d’une solution de load balancing hautement disponible

Nous avons vu le principe de la solution de load balancing hautement disponible, regardons désormais comment la mettre en place. Les load balanceurs Description Nous allons appeler les répartiteurs de charges frontal1 (192.168.0.1) et frontal2 (192.168.0.2). L’IP virtuelle (VIP) est 192.16.8.0.3, le service sera sur le port 80. La distribution de notre exemple sera ici une Redhat entreprise 4, mais il est très facile de généraliser pour d’autres. Les serveurs réels seront: reel1 (linux) en 192.168.0.4 reel2 (linux) en 192.168.0.5 Les composants importants sont: Heartbeat afin de faire la bascule en cas de mort d’un loadbalanceur ldirector qui se charge de configurer et surveiller les serveurs réels ipvsadm qui contrôle [...]
Lire la suite
Vus : 1227
Publié par Naparuba : 7

La haute disponiblité et la répartition de charge avec HeartBeat/IPVS

Intérêt et problématique Commençons par la problématique : vous avez besoin pour une application de haute disponibilité et/ou de répartition de charge. Si votre application supporte le fait au les clients arrivent sur tel ou tel serveur (puis restent connectes au même serveur) alors vous pouvez utiliser un système automatiques de répartition des utilisateurs. Là, le choix est vaste. Déjà, si l’application possède un tel répartiteur en frontal, il faut l’utiliser. Sinon on peux utiliser des switchs dédiés si vous avez un budget important et surtout des besoins de débits très important (de [...]
Lire la suite
Vus : 765
Publié par Naparuba : 7
Powered by BilboPlanet