Monter un cluster filesystem avec OCFS2

Posted in Administration by Nap on August 3, 2009 2 Comments

Intérêt de la solution

Les architectures clusters sont de plus en plus présentes. Si nous avons vu dans de précédent post la partie réseaux avec IPVS, il reste la question des applications, et tout particulièrement du partage des données, notamment les fichiers des applications, et parfois même les datafile des bases.
C’est justement un éditeur de base de données, Oracle, qui a mis au point un cluster filesystem développé sous licence GPLv2. Les noeuds doivent avoir accès au même device qui va être “formaté” en ocfs2 pour pouvoir être monté par plusieurs noeuds à la fois. c’est un cluster file system quoi…

Pour ceux qui n’ont pas suivi, voici ce que cela donne avec deux noeuds (mais après vous pouvez en mettre bien plus) :

cluster filesystem

Ici, le même disque est accessible des deux machines grâce à des liens SAN qui peuvent être Fibre ou iScsi (ce dernier suffit la plupart du temps). Dans cet exemple, chaque machine voit le disque sur un nom de device différent, mais ce n’est pas obligatoire.

Regardons un peu comment il fonctionner et comment on le met en place.

More…

Shinken : quand un python rencontre Nagios

Posted in Nagios by Nap on July 2, 2009

J’ai commencé voila quelques temps le projet Shinken. C’est une ré-implémentation de Nagios en Python qui va me permettre de maqueter certains principes pour Nagios avant de me les fader en C. C’est pour cela que j’ai choisi le langage Python qui est particulièrement élégant et jouissif. Si vous ne le connaissez pas, aller faire un petit tour sur http://www.python.org/ et laissez vous emporter par ce super langage.

Shinken est le résultat de mon étude de Nagios dont je parlerai un peu plus tard. Ce projet est déjà très efficace, mais j’étais persuadé que certains petits détails étaient encore améliorables. Par exemple, le lancement des sondes est ce qui coute le plus cher en terme de performance pour Nagios. Éviter de forker en ayant un pool de processus peut être bien plus intéressant. Ceci se code en quelques lignes de Python. De même, les aspects distribué de Nagios ne sont pas parfait. Les Nagios n’ont aucune connaissance des autres. Si avec des solutions comme Centreon il est facile de les gérer, certains problèmes persistent comme les notifications qui sont envoyées par chaque Nagios et ce séquentiellement.

L’intérêt de Shinken est de reprendre la configuration de Nagios ainsi que ses principes de supervision qui sont très pousés tout en proposant une novuelle architecture pour le programme à proprement parlé. Shinken est par exemple capable de couper automatiquement la configuration en partie totalement indépendantes qui vont pouvoir être, encore automatiquement, envoyées vers un scheduler qui va ordonnancer les vérifications et prendre les décisions en cas de problèmes.

Le nom du projet n’a pas été facile à trouver : je suis très long pour trouver des noms. Je peux dire merci à Wikipedia pour celui-là. je cherchai un nom de sabre japonais (j’aime bien la sonorité des noms japonais) et je suis tombé sur celui-là. Le sabre illustre la faculté de couper la charge automatiquement sur plusieurs machines. Et le Shinken est le sabre qui coupe le plus.

Le code est déjà bien avancé et est en licence AGPLv3.  Je reviendrai plus tard sur ce choix. Je suis en train de monter une première version sur sourceforge. Et plus important encore, le logo est déjà prêt :)

shinken

Merci à l’auteur cisoun pour sa mascotte ouaaargh qui a servi de base à ce logo :)

Pour ceux qui veulent voir un peu ce que cela donne, vous pouvez obtenir la dernière version du code avec git (paquet git-core sous debian):

git clone git://shinken.git.sourceforge.net/gitroot/shinken/shinken

Administration et supervision de HeartBeat/Ldirectord/IPVS

Posted in Administration by Nap on June 30, 2009

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.

More…

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

Posted in Administration by Nap on June 30, 2009 2 Comments

Nous avons vu le principe de la solution de load balancing hautement disponible, regardons désormais comment la mettre en place.

More…

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

Posted in Administration by Nap on June 30, 2009

LVS-nat

LVS-logo

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 l’ordre de plusieurs dizaines de Mo/s). En cas de débits moindres, il est possible d’utiliser des solutions logicielles open sources que nous allons étudier ici.

More…