Catégorie : Developpement

Catégories
Developpement Open-source Planet-libre Reseau Systeme

Glances: vos stats systèmes en un clin d’oeil

Il y a quelques jours, je vous avais parlé de Saidar, un logiciel permettant de regrouper dans un terminal|console un certain nombre de statistiques sur votre machine. Après quelques heures d’utilisations, j’ai identifié des choses qui ne me convenait pas:

  • pas d’affichage de la mémoire réellement disponible (comme on peut le trouver sur la deuxième ligne de la commande free -m)
  • pas de détail au niveau des processus
  • affichage des débits réseaux en octets/sec alors que j’utilise toujours les bits/sec
  • pas d’information sur l’espace disque disponible

Comme je ne trouvais pas la « killer application » dans ce domaine (même si il existe de très bon outils comme top), j’ai décidé de repartir d’une feuille blanche et de développer le logiciel Glances (licence LGPL) dont je vais vous présenter les grandes lignes dans ce billet.

Glances screenshot

Objectifs

Ils sont multiples:

  • prises en compte de mes griefs sur Saidar
  • accès à la fois depuis un environnement graphique (terminal) qu’à distance (console)
  • mise en avant des statistiques importantes à la compréhension d’un éventuel problème
  • affichage des processus triés de manière intelligente et automatique
  • développement en langage Python (je connais assez bien, c’est portable et facile à maintenir)

Installation

Après avoir téléchargé la dernière version stable disponible , il suffit de saisir les commandes suivantes:

[cc lang= »bash »]

tar zxvf glances-version.tar.gz

cd glances-version

./configure

make

sudo make install

[/cc]

Notes: remplacer « version » par le numéro de version que vous avez téléchargé…

Glances a besoin de la librairie python-statgrab version 0.5 (ou supérieure) pour fonctionner correctement. Sous Ubuntu, il suffit de lancer la commande:

[cc lang= »bash »]

sudo apt-get install python-statgrab

[/cc]

Sous Debian Squeeze, seule la version 0.4 de python-statgrab est disponible dans les dépôts. Il faut donc installer la version 0.5:

[cc lang= »bash »]

sudo apt-get install libstatgrab-dev

wget http://ftp.uk.i-scream.org/sites/ftp.i-scream.org/pub/i-scream/pystatgrab/pystatgrab-0.5.tar.gz

tar zxvf pystatgrab-0.5.tar.gz

cd pystatgrab-0.5/

./setup.py build

sudo ./setup.py install

[/cc]

Utilisation

On lance le logiciel avec la commande:

[cc lang= »bash »]

glances.py

[/cc]

Par défaut, le rafraîchissement des données se fait toutes les secondes. Il est possible de l’augmenter avec l’option -t. Par exemple pour avoir un taux de rafraîchissement de 5 secondes:

[cc lang= »bash »]

glances.py -t 5

[/cc]

Une fois lancé, les touches suivantes sont actives:

  • ‘a’: passer le tri des processus en automatique (c’est le mode par défaut). Glances utilisera par défaut un tri décroissant sur l’utilisation CPU. Si une alerte sur la mémoire globale apparaît (mémoire occupé > 70%), le tri se fera alors par occupation mémoire.
  • ‘c’: forcer le tri des processus en fonction de leurs utilisations de la CPU.
  • ‘m’: forcer le tri des processus en fonction de leurs occupations mémoire.
  • ‘q’: quitter le programme (on peut également utiliser CTRL-C).

Si votre terminal|console est compatible avec un affichage couleur, alors les statistiques importantes (à mes yeux…) sont mises en avant de la manière suivante:

  • VERT: le compteur est < 50%
  • BLEU: le compteur est > 50% et < 70%
  • VIOLET: le compteur est > 70% et < 90%
  • ROUGE: le compteur est > 90%

Limitations

L’API python-statgrab comporte actuellement un bug pour la récupération des statistiques sur les espaces disques. Dès que ce dernier sera corrigé, je pense inclure ces statistiques dans l’espace libre en bas à gauche de la fenêtre de Glances.

Un problème ?

Si vous rencontrez un problème lors de l’installation ou de l’utilisation de Glances:

  1. Vérifié que le problème n’est pas référencé
  2. Saisir le nouveau bug dans le tracker GitHub

Lors de la saisie du bug merci de fournir les informations suivantes:

  • Système d’exploitation (nom, version)
  • version de Python (python -v)
  • version de la librairie statgrab (apt-cache show statgrab)
  • version de la librairie python-statgrab (apt-cache show python-statgrab)

Contribuer ?

Le logiciel est distribué sous licence libre LGPL. Il est disponible dans le GitHub suivant: https://github.com/nicolargo/glances

Si vous trouvé ce logiciel intéressant et que vous souhaitez vous impliquer, j’ai besoin de vous sur les sujet suivants:

  • packaging de Glances pour Debian, Ubuntu (PPA), Fedora, Redhat, Free|Open|NetBSD…
  • amélioration/optimisation du code (lire le billet contribuer à un projet hébérgé sur GitHub)
  • inclure la vérification de la présence de la librairie python-statgrab lors du .configure (j’ai un bug dans le configure.ac)
  • ‘Man’ page
  • Afficher une fenêtre d’aide avec les touches disponibles quand on clique sur F1
  • Corriger le bug de python-statgrab afin que l’on puisse inclure les statistiques sur les systèmes de fichiers
  • …

J’attends vos retours. 🙂

Catégories
Developpement Open-source Web

Epitech Innovative Project 2012

Ce matin, dans ma boîte au lettre (la vraie pas la virtuelle), j’ai eu le plaisir de découvrir le catalogue des projets innovants développés par les étudiants de la promotion 2012 de l’école de l’innovation et de l’expertise informatique Epitech. Sous une très belle présentation graphique se cache 52 projets utilisant un panel très varié de technologies informatiques. Contrairement à pas mal de projets de fins d’études qui débouchent rarement sur des choses intéressantes, le projet EIP  fait partie intégrante du cursus de l’école et ceci dès la 4ém année.

Pour la version 2012, les projets sont répartis en 5 catégories:

  1. Améliorer le bien être des individus et des collectivités
  2. Mieux diffuser le progrès technologique
  3. Rendre plus efficaces les outils au profit des entreprises
  4. Ouvrir de nouveaux horizons aux passions
  5. Innover, année après année, team après team

Pour chaque projet, une double page  permet de se faire une idée générale du sujet, de mettre en avant les technologie utilisées puis de présenter l’équipe et les éventuels partenaires industriels.

A titre personnel, voici quelques projets dont je trouve les sujets intéressants:

  • Rawmarket: Relier équitablement acheteurs et fournisseurs
  • Syshome: Solution de domotique écologique et durable
  • Comeet: Un espace de Visioconférence basée sous XMPP
  • Defuze.me: Régler sa station de radio sur le succès
  • Skuld: Centre d’imagerie médicale de poche (accès à un serveur PACS depuis un mobile)

La liste complète des projets est disponible sur cette page.

Merci encore à l’équipe pédagogique de l’Epitech pour ce très beau catalogue.

Catégories
Developpement Open-source Planet-libre

Contribuer à un projet hébergé sur GitHub

Le gestionnaire de version GIT semble prendre de plus en plus de place dans le petit monde des développeurs. Les qualités des services comme Gitorious ou GitHub y sont sûrement pour quelques choses. Il y a quelques temps, j’ai donc décidé de laisser tomber mon bon vieux serveur SVN et de migrer mes projets sur le service en ligne GitHub. Comme tous ces projets sont sous licences libres, l’hébergement sur GitHub est gratuit.

Quelques lecteurs voulant contribuer à la vie des ces développements m’ont demandé comment contribuer à un projet hébergé sous GitHub. Ce billet est là pour répondre à ces demandes !

Les deux premières étapes sont à suivre seulement la première fois que vous voulez contribuer à un projet. Les étapes suivantes sont par contre à faire à chaque contribution dans un nouveau projet.

1) Créer un utilisateur sous GitHub

C’est la première étape, s’enregistrer comme utilisateur sur le site GitHub. Il faut pour cela se rendre sur la page suivante puis renseigner le formulaire. A noter que ce compte vous servira à la fois pour contribuer à des projets existants mais également à héberger des projets sous licences libres (dans la limite de 300 Mo).

2) Enregistrer sa clé SSH

Afin de sécuriser la connexion vers serveurs GitHub, une clé SSH doit être générée et échangée entre votre PC et GitHub. On va donc commencer par générer une nouvelle clé SSH sur notre PC:

cd ~/.ssh

mkdir backup

cp id_rsa* backup

rm id_rsa*

ssh-keygen -t rsa -C "utilisateur@domaine.com"

Note: remplacer utilisateur@domaine.com par l’adresse mail que vous avez utilisé lors de la création de l’utilisateur sur GitHub.

La commande suivante:

cat ~/.ssh/id_rsa.pub

devrait afficher la clé fraîchement créée:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCn3BD+Kq9qdVQrRNf9CIWGHWHrYpygPbOjidGA/34TWcKKSY0QgUVl3CYBkBDMyTMRNoDnMcF5O4bpwUDx2uXPAlrjQnUAk/WvPdQ+Clcnv+H5jgaj0i6Gfw/WSRDopmGpey7B29UGifgYW3/1MacH7tb+6Q03phUPedcBd4LNN+iBAUSfSvesYXNWW9//Wl7xi3OT2qbLOBRCGF9nlvv1AXEAbCF8h3l4Bu9w0BeVpmSIekLqNZVasEvM/4MWj+E7ayVajCQC2tm4+mt7+0kVHW35PUDlRaW2mv9muuy2mvqtJ4aW+zoPd3sWADUGBLLASWhuqY2Gmh3LIN+2gq2l  utilisateur@domaine.com

Il faut ensuite se rendre sur votre interface d’administration de GitHub puis ajouter une nouvelle clé SSH associée à votre PC (Add another public key):

Puis copier/coller la clé SSH (le contenu du fichier  ~/.ssh/id_rsa.pub) dans le formulaire:

Pour tester que la clé a bien été prise en compte, il suffit de lancer les commandes suivantes depuis votre PC:

# ssh -T git@github.com

Hi USER! You've successfully authenticated, but GitHub does not provide shell access.

Si la clé fonctionne correctement, il reste a configurer les informations suivantes:

$ git config --global user.name "Prenom Nom"

$ git config --global user.email "utilisateur@domaine.com"

3) « Forker » le projet sur lequel vous voulez contribuer

Imaginons que vous vouliez contribuer sur le projet Nagisk (mon plugin Asterisk pour Nagios), il faut dans un premier temps se rendre sur sa page GitHub puis cliquer sur le bouton .

Cette première action va dupliquer (« fork« ) dans votre espace  GitHub, le contenu du projet Nagisk. Ce nouveau projet aura sa propre vie par rapport au projet initial.

Il faut ensuite récupérer le nouveau projet en local sur votre PC:

git clone git@github.com:utilisateur/nagisk.git

cd nagisk

git remote add upstream git://github.com/nicolargo/nagisk/symfony.git

Note: Remplacer utilisateur par votre login GitHub.

Note 2: La dernière ligne va configurer le Git « source » (celui à partir duquel vous avez forké le projet) comme remote.

Il faut ensuite créer une branche dans laquelle vous aller faire vos développements:

git checkout -b NOMDELABRANCHE

Note: Choisissez une NOMDELABRANCHE qui colle à votre modification. Par exemple, si c’est une modification de bug, un nom du type PATCH_XXX avec XXX qui est égal au numéro de ticket (issue).

Il ne vous reste plus qu’à coder…

Une fois le phase de codage terminer, il faut mettre à jour la nouvelle version de votre projet avec les commandes suivantes:

git checkout master

git fetch upstream

git merge upstream/master

git checkout NOMDELABRANCHE

git rebase master

Si il y a des conflits après la dernière commande, il faut les corriger puis poursuivre le rebase:

git add ... # Liste des fichiers modifiés lors de la correction

git rebase --continue

$ git push origin NOMDELABRANCHE

Votre projet « forker » est maintenant à jour. Reste à proposer votre modification au projet source.

4) Formuler votre demande de contribution

Pour cela il suffit d’appuyer  sur le bouton  (pour plus d’informations, voir ici la page officielle de l’action Pull Request)

La demande de modification va alors être proposée au responsable du projet source qui pourra, s’il le souhaite, l’inclure dans sa prochaine version.

En cadeau bonux, une feuille A4 contenant une liste non-exhaustive des commandes Git.

Sources: Blog Lorna Jane

Catégories
Developpement Open-source Planet-libre

Kit du développeur libre sous Windows

Devant le nombre important de commentaires intéressants sur le billet de ma trousse à outils libres sous Windows, il était impensable d’en rester là. Manifestement beaucoup de libristes travaillent (ou sont forcés de travailler) sous un système d’exploitation de Microsoft. Nous allons donc reprendre dans ce billet les logiciels libres (et seulement libre) permettant de développer dans ce milieu hostile. Comme toujours, les commentaires seront là pour partager d’autres pépites !

Les compilateurs / langages

C: Cygwin fait la passerelle entre le monde Windows et GNU/Linux. Ils apportent un certain nombre d’outils et de librairies permettant notamment de compiler vos programmes en C. On peut également citer MinGW, un fork plus léger de Cygwin, offrant un environnement de développement minimal (GCC).

Python: Pas de problème ici, Windows dispose de la dernière version du langage Python. A télécharger ici pour Python 2 et là pour Python 3.

Perl: On présente plus le langage Perl. Vous pouvez télécharger la dernière version sous Windows à partir du site officiel. Je vous conseille la version Strawberry Perl.

NodeJS: C’est le framework implémentant, coté serveur, la version 8 du moteur Javascript de Google (j’en parle dans certains de mes billets). On peut télécharger la version de développement qui propose un binaire Windows ici.

Les consoles / terminaux

En tant qu’utilisateur GNU, le plus gros choc quand j’ai dans les mains une machine Windows est la qualité déplorable du terminal par défaut (le fameux cmd.exe). Non seulement c’est une hérésie complète au niveau de l’ergonomie mais en plus c’est le seul logiciel qui n’évolue pas d’une version à l’autre de Windows. Voici donc quelques alternatives obligatoires…

Console2: Avec ce logiciel libre on retrouve enfin une vrai console sous Windows. A vous les copier/coller, les agrandissements de fenêtres, les tabs…

Attention, ce n’est qu’une interface graphique permettant de saisir des commandes. Si vous ne disposez pas d’un client SSH, il vous sera impossible d’accéder avec ce protocole à vos machines sous Windows. Personnellement, pour résoudre ce besoin j’ai installé Plink (la couche SSH de Putty) puis j’ai automatisé le lancement de la commande suivante:

[cc]doskey ssh= »C:\Program Files\PuTTY\plink.exe » $*[/cc]

PuTTY: Pour ceux qui utilisent la console uniquement comme un terminal SSH/Telnet, PuTTY reste un très bon choix. Il est léger, transportable facilement sur une clé USB (il nécessite seulement un exécutable). A noter qu’il existe une extension à PuTTY nommé PuTTY Connection Manager et qui propose la gestion des tabs et autres améliorations (non libre !). Il existe également un fork de PuTTY nommé KiTTY qui semble proposer toutes ces fonctions mais je ne l’ai pas testé.

MobaXterm:  C’est un package tout en un (dans un unique exécutable) intégrant à la fois un serveur X, un terminal et une version intégrée de Cygwin. C’est la solution idéale (bien qu’un peu lourde) si vous avez besoin de travailler sous Windows comme vous le feriez (à peu près) sous GNU/Linux.  A noter qu’il existe un certain nombre de plugins permettant d’adapter votre MobbaXterm à vos besoins (GCC, Perl, Emacs…).

Les éditeurs

Vu le nombre de solutions que l’on peut trouver sur le marché des éditeurs de texte, le choix est plus une affaire de goût que de qualité. Voici donc une petite sélection hétéroclite d’éditeurs libres.

Notepad++: Concurrent direct de PSPad, qui est un freeware non libre, dans la catégorie des éditeurs de texte « grand public » (noter les guillemets). Notepad++ offre tout ce que l’on peut attendre d’un éditeur orienté développement en 2011.

Vim: A l’opposé de Notepadd++ en ce qui concerne l’UE (« user experience »), Gvim, le portage de Vim sous Windows, permettra à nos chers barbus condamnés au bagne en travaillant sous Windows à ne pas tomber dans une déprime complète et irrémédiable. Dans la même mouvance, on peut également utiliser la version Windows d’Emacs, à télécharger ici.

Winmerge: Même si ce logiciel n’est pas un éditeur à part entière, il a largement sa place dans ce kit. Il permet de comparer visuellement deux fichiers et de lancer des actions pour les synchroniser. Un must have qui a le bon goût d’être libre…

Eclipse: Difficile de faire une billet parlant de développement, de logiciel libre et de Windows sans évoquer Eclipe… Certains le touve usine à gaze, d’autres indispensable pour un « gros » développement. La vérité est surement entre les deux.

Les gestionnaires de versions

Je n’aborderai ici que la partie cliente des gestionnaires de versions tant il me semble aberrant  de vouloir héberger un serveur sur une machine Windows… On va les prendre un par un (enfin les plus connus):

CVS (oui oui il y en a encore qui utilise CVS…): TortoiseCVS intègre parfaitement CVS dans gestionnaire de fichier de Windows.

SVN: TortoiseSVN est a SVN ce que TortoiseCVS est à CVS…

Git: Si vous voulez rester dans le même style d’interface pour votre gestionnaire sous GIT, je vous conseille d’utiliser TortoiseGIT. Si le changement ne vous gène pas, il y a GitExtensions qui pour moi est la solution idéale sous Windows.

Mercurial: Je dois avouer que je n’utilise pas Mercurial. J’ai trouvé (mais donc pas testé) le pendant de Tortoise pour HG, j’ai nommé… TortoiseHG (que c’est original).

Conclusion

La liste de logiciels que nous venons d’évoquer n’est bien sûr pas exhaustive et ciblée sur mes besoins. N’hésitez pas à partager votre expérience de « développeur libre sous Windows » (sic) avec nous !

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Administration 5/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger(auteur invité).

Je rappelle que ce billet est le dernier (et oui déjà) d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

DUMP a chaud sur une base de données de type Cluster MySQL

La plus part des sociétés qui décide d’employer ce genre d’architecture pour leur base de données, pensent avant tout a la sauvegarde en ligne de leur données sans l’interruption de service. L’intérêt de MySQL Cluster est que les données sont donc toutes stockées en mémoire, ce qui rend donc possible ce processus de sauvegarde.

Une sauvegarde représente le contenu d’une base de données, à un moment donné. La sauvegarde contient 3 parties principales :

  • Les méta-données (quelles tables existents, etc.)
  • Les lignes des tables(les données )
  • Un historique des transactions archivées

Chaque partie est stockée sur tous les noeuds qui participent à la sauvegarde.

Durant une sauvegarde, chaque noeud sauve ces données sur le disque, en trois fichiers :

BACKUP-<BackupId>.<NodeId>.ctl 

Le fichier de contrôle, qui contient les données de contrôle et les méta-données.

BACKUP-<BackupId>-0.<NodeId>.data 

Le fichier de données qui contient les lignes des tables.

BACKUP-<BackupId>.<NodeId>.log 

Le fichier de log, qui contient les transactions archivées.

Dans les lignes ci-dessus, <BackupId> est un identifiant pour la sauvegarde, et <NodeId> est l’identifiant du noeud qui a créé le fichier.

Meta data

Les méta-données sont consistuées des définitions de table. Tous les noeuds ont la même définition de table, sauvée sur le disque.

Table records

Les lignes sont sauvées par fragment. Chaque fragment contient un entête qui décrit à quelle table appartient les lignes. Après un groupe de ligne, il y a pied-de-page qui contient une somme de contrôle. Différents noeuds sauvent différents fragment durant la sauvegarde.

Committed log 

L’historique contient les transactions archivées, effectuée durant la sauvegarde. Seules les transactions impliquant les tables stockées sur le noeud sont stockées dans le log. Les différents noeuds de la sauvegarde sauvent différents logs, car ils abritent différents fragments de bases de données.

Utilisation du serveur de gestion pour une sauvegarde de cluster

Il faut suivre les étapes suivantes:

  1. Lancez le serveur de management.
  2. Exécutez la commande START BACKUP.
  3. Le serveur de gestion vous indiquera « Start of backup ordered ». Cela signifie que le serveur de management a envoyé la requête au cluster, mais qu’il n’a pas encore reçu de réponse.
  4. Le serveur de gestion va indiquer « Backup <BackupId> started », où <BackupId> est l’identifiant de la sauvegarde. Cette information sera aussi enregistrée dans le log du cluster (à moins que cela ne soit configuré autrement). Cela signifie que le serveur a reçu des réponses, et que la sauvegarde a été faite. Cela ne signifie pas que la sauvegarde est complète.
  5. Le serveur de gestion va indiquer que la sauvegarde est finie avec le message « Backup <BackupId> completed ».

[cce]

ndb_mgm> start backup

Waiting for completed, this may take several minutes

Node 3: Backup 1 started from node 1

ndb_mgm> Node 3: Backup 1 started from node 1 completed

StartGCP: 76106 StopGCP: 76109

#Records: 2057 #LogRecords: 0

Data: 51188 bytes Log: 0 bytes

[/cce]

Utilisation du serveur pour annuler une sauvegarde :

  1. Lancez le serveur de gestion.
  2. Exécutez la commande ABORT BACKUP <BACKUPID>. Le numéro <BackupId> est l’identifiant de la sauvegarde, qui est inclut dans la réponse du serveur de gestion au moment de la création de la sauvegarde : « Backup <BackupId> started ». L’identifiant est aussi sauvé dans le log du cluster (cluster.log).
  3. Le serveur de gestion répond « Abort of backup <BackupId> ordered ». Cela signifie qu’il a envoyé la requête au cluster, mais n’a pas encore re¸u de réponse.
  4. Le serveur de gestion répond « Backup <BackupId> has been aborted reason XYZ ». Cela signifie que le cluster a annulé la sauvegarde, et supprimé toutes les ressources reliées, y compris les fichiers.

Dans la partition /home de votre serveur noeud vous pouvez donc voir ceci . Un dossier Backup crée par le serveur de management, puis le numeros de la sauvegarde et les fichiers nécessaire a sa restauration.

Utilisation des processus serveurs MySQL par MySQL Cluster

mysqld est le processus traditionnel du serveur MySQL. Pour être utilisé avec MySQL Cluster, il doit être compilé avec le support des tables NDB. Si le binaire mysqld a été compilé correctement, le moteur de tables NDB Cluster est désactivé par défaut.

Pour activer le moteur NDB, il y a deux méthodes. Soit vous utilisez l’option –ndbcluster au démarrage, lorsque vous utilisez la commande mysqld ou bien, insérez une ligne avec ndbcluster dans la section [mysqld] de votre fichier my.cnf.

Un moyen facile pour vérifier que votre serveur supporte le moteur NDB Cluster est d’utiliser la commande SHOW ENGINES depuis un client mysql. Vous devriez voir la valeur YES dans la ligne de NDBCLUSTER. Si vous voyez NO, c’est que vous n’utilisez pas le programme mysqld compilé avec le support de NDB Cluster. Si vous voyez DISABLED, alors vous devez simplement activer le moteur dans votre fichier de configuration my.cnf.

Le serveur MySQL doit savoir comment lire la configuration du cluster. Pour accéder à cette configuration, il doit connaître 3 choses :

  • Son propre numéro d’identifiant de noeud dans le cluster.
  • Le nom d’hôte ou l’adresse IP où le serveur de gestion réside.
  • Le port sur lequel se connecter au serveur de gestion.

Il y a actuellement trois moyens pour donner ces informations au processus mysqld. La méthode recommandée est de spécifier la chaîne de connexion de mysqld appelée ndb-connectstring, soit au démarrage de mysqld ou dans le fichier my.cnf.

Vous pouvez aussi inclure cette information dans un fichier appelé Ndb.cfg. Ce fichier doit résider dans le dossier de données de MySQL. Une autre solution est de configurer la variable d’environnement appelée NDB_CONNECTSTRING. La chaîne sera la même dans tous les cas : « [nodeid=<id>;][host=]<host>:<port> ». Si aucune information n’est fournie, cette chaîne vaudra par défaut « host=localhost:2200 ».

[cce]

shell> mysqld –ndb-connectstring=ndb_mgmd.mysql.com:2200

[/cce]

ndb_mgmd.mysql.com est l’hôte où le serveur de gestion réside : il attend sur le port 2200.

Avec cette configuraiton, le serveur MySQL sera partie prenant du cluster MySQL, et accédera à la liste complète de tous les noeuds du cluster ainsi que leur statut. Il va se connecter à tous les noeuds de stockage, et sera capable d’utiliser chacun d’entre eux comme coordonnateur de transaction, ainsi que pour accéder aux données.

ndb_mgmd, le serveur de management

Le serveur de management est le processus qui lit le fichier de configuration du cluster, et distribue cette information à tous les noeuds qui le demande. Il gère aussi le log d’activité du cluster. Les clients de gestion s’y connectent et peuvent l’utiliser pour envoyer des commandes d’analyse et d’administration.

Si vous utilisez plusieurs serveurs de gestion, une chaîne de connexion doit être fournie, et tous les noeuds du cluster doivent explicitement spécifier leur identifiant.

  • config.ini est le fichier de configuration du cluster. Il est créé par l’utilisateur et lu par le serveur de gestion.
  • ndb_1_cluster.log est le fichier où les événements du cluster sont consignés. Les événements du cluster sont, par exemple : les jalons commencés ou complétés, les incidents de noeuds, les démarrages de noeuds, les niveaux d’utilisation de mémoire, etc.
  • ndb_1_out.log est le fichier utilisé pour les entrées et sorties (stdout et stderr) lors de l’exécution du serveur de gestion comme démon. 1, dans ce contexte, est l’identifiant de noeud.
  • ndb_1.pid est le fichier de PID utilisé lors de l’exécution du serveur de gestion comme démon. 1, dans ce contexte, est l’identifiant de noeud.
  • ndb_1_cluster.log.1 , lorsque le log de cluster dépasse un millions d’octets, alors le fichier de log prend le nom indiqué ici, où 1 est le nombre de fichier de logs : si 1, 2 et 3 existent déjà, le suivant sera le numéro 4.

ndb_mgm, le client de gestion du cluster

Le dernier processus important à connaître est le client de gestion. Ce processus n’est pas nécessaire pour faire fonctionner le cluster. Son intérêt est que pouvoir vérifier le statut du cluster, de lancer les sauvegardes, et effectuer les autres activités d’administration. Il fournit un moyen d’accès et un jeu de commandes.

En fait, le client de gestion utilise une interface C qui donne l’accès au serveur de gestion : pour les utilisateurs experts, il est possible de programmer des processus spécifiques qui pourront effectuer des taches d’administration automatisées.

[cce]

shell> ndb_mgm

[/cce]

Commandes du client de gestion du Cluster

En plus du fichier de configuration central, le cluster peut aussi être contrôlé avec une interface en ligne de commande. La ligne de commande est disponible via un processus séparé de client de gestion du cluster. C’est l’interface principale de gestion du cluster.

Le client de gestion a les commandes suivantes de base. Ci-dessous, <id> indique un noeud de base de données (i.e. 21) ou le mot clé ALL qui indique que la commande doit être appliquée à tous les noeuds dans le cluster.

HELP

Affiche les informations sur toutes les commandes disponibles.

SHOW

Affiche les informations sur le statut du cluster.

<id> START

Lance le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> STOP

Stoppe le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> RESTART [-N] [-I]

Relance le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> STATUS

Affiche les informations de statut du noeud de base de données identifié par <id> (ou de tous les noeuds avec ALL).

ENTER SINGLE USER MODE <id> 

Active le mode d’utilisateur unique, où seule l’API avec le noeud <id> est autorisée pour accéder au système de base de données.

EXIT SINGLE USER MODE

Quitte le mode d’utilisateur unique.

QUIT

Quitte le client de gestion du cluster.

SHUTDOWN

Arrête tous les noeuds du cluster, hormis les serveurs MySQL, puis s’arrête.

Conclusion

Note de Nicolargo: Merci encore à Remy pour cette série d’articles sur un sujet d’actualité vu le nombre croissant de données gérées par nos applications.

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Démarrage 4/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger(auteur invité).

Je rappelle que ce billet est le 4em d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

Démarrage du Cluster

Démarrer le cluster n’est pas très difficile une fois qu’il a été configuré. Chaque noeud doit être lancé séparément, et depuis l’hôte sur lequel il réside. Même s’il est possible de lancer les noeuds dans n’importe quel ordre, il est recommandé de lancer le serveur d’administration en premier, puis les noeuds de stockage et enfin, les noeuds SQL.

Sur l’hôte de gestion, utilisez la commande suivante depuis le Shell pour lancer le processus de gestion :

[cce]

ndb_mgmd -f /var/lib/mysql-cluster/config.ini

[/cce]

Notez que ndb_mgmd doit recevoir le nom et chemin du fichier de configuration, avec l’option -f ou –config-file.

Sur chaque hôte de stockage, exécutez cette commande pour lancer les processus NDBD :

[cce]

ndbd –initial

[/cce]

Notez qu’il est très important d’utiliser le paramètre –initial uniquement lors du premier démarrage de ndbd, ou lors du redémarrage apràs une opération de restauration des données ou de modification de configuration. En effet, ce paramètre va forcer le noeud à effacer les fichiers créé par les anciennes instances de ndbd, y compris les fichiers de log.

Sur les hôtes SQL, exécutez une commande mysqld classique (sous simple utilisateur le service ne fonctionne pas si vous êtes en root ) :

[cce]

mysqld &

[/cce]

Si tout se passe bien, et que le cluster a été correctement configuré, il devrait être opérationnel à nouveau. Vous pouvez tester cela en utilisant la commande ndb_mgm, c’est à dire le client de gestion; le résultat devrait être similaire à celui-ci :

[cce]

[root@localhost ~]# ndb_mgm

— NDB Cluster — Management Client —

ndb_mgm> show

Connected to Management Server at: localhost:1186

Cluster Configuration

———————

[ndbd(NDB)] 2 node(s)

id=3 @12.0.1.30 (mysql-5.1.56 ndb-7.1.15, Nodegroup: 0, Master)

id=4 @12.0.1.31 (mysql-5.1.56 ndb-7.1.15, Nodegroup: 0)

[ndb_mgmd(MGM)] 2 node(s)

id=1 @12.0.1.10 (mysql-5.1.56 ndb-7.1.15)

id=2 @12.0.1.11 (mysql-5.1.56 ndb-7.1.15)

[mysqld(API)] 2 node(s)

id=5 @12.0.1.20 (mysql-5.1.56 ndb-7.1.15)

id=6 @12.0.1.21 (mysql-5.1.56 ndb-7.1.15)

[/cce]

Quelques pistes si vous avez des messages d’erreurs

Can’t connect to mysql server through socket ‘/tmp/mysql.sock’

Le serveur MySQL n’est pas lancé.

Le socket précisé lors du lancement du client ne correspond pas à celui du serveur (option –socket pour le client en ligne de commande

Sous UNIX, le user mysql n’a pas les droits sur le répertoire /tmp du serveur.

Access denied for user : ‘xx@xx’ (using password : Y/N)

Le mot de passe entré n’est pas le bon.

Aucun mot de passe n’a été donné alors que le serveur en attend un (option -p du client MySQL en ligne de commande par exemple).

L’utilisateur n’a pas les droits pour se connecter ou sur certaines tables. Pour voir les droits d’un utilisateur, utilisez la commande SHOW GRANTS FOR user@host. Si nécessaire, donnez les privilèges au user (voir plus haut). N’oubliez pas de faire un FLUSH PRIVILEGES pour recharger les droits

L’utilisateur est occulté par un autre plus prioritaire mais aux droits plus restreints. Le serveur MySQL considère d’abord les users les plus spécifiques (avec une adresse IP précise ou « localhost » par exemple) avant de prendre en compte les plus génériques (caractères ‘%’ ou ‘_’ dans le nom du user ou de l’hôte).

Ex : si l’utilisateur Bob se connecte à partir de la machine locale où se trouve le serveur MySQL, les droits de ‘bob@localhost’ primeront, s’ils existent, sur les droits de ‘bob@%’.

Les erreurs d’accès s’expliquent souvent par la présence d’utilisateurs anonymes (user= ») dans la table users qui masquent les droits de certains autres utilisateurs. Pour y remédier, on peut les supprimer par un DELETE FROM mysql.user WHERE user= ».

Connexion failed 1130- Host ‘X’ is not allowed to connect to this MySQL server

Il n’existe aucun utilisateur autorisé à se connecter depuis l’hôte X (dans la table des droits, il n’y a pas de user …@X).

Can’t connect to mysql server on [hôte]

L’option skip-networking du serveur est activée (au démarrage ou dans le fichier de configuration my.ini/my.cnf) et empêche les connexions TCP/IP venant de l’extérieur.

Désactivez également l’option bind-address 127.0.0.1

Arrêter le cluster

Pour arrêter le cluster, utilisez simplement cette commande dans le Shell sur la machine qui héberge le serveur de gestion MGM :

[cce]

ndb_mgm -e shutdown

[/cce]

Cela va forcer les processus ndb_mgm, ndb_mgm et ndbd à s’arrêter proprement. Tous les noeuds SQL peuvent alors être arrêté avec la commande mysqladmin shutdown classiques ou par d’autres moyens.

Pour relancer le cluster, lancez simplement ces commandes :

Sur l’hôte de gestion (12.0.1.10 et 12.0.1.11 dans notre cas) :

[cce]

ndb_mgmd -f /var/lib/mysql-cluster/config.ini

[/cce]

Sur chaque noeud de stockage (12.0.1.30 et 12.0.1.31) :

[cce]

ndbd

[cce]

N’oubliez pas d’invoquer cette commande avec l’option –initial lorque vous redémarrez un noeud NDBD normalement.

Et les hôtes SQL (12.0.1.20 et 12.0.1.21) :

[cce]

mysqld &

[cce]

Suite et fin au prochain épisode !

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Installation 3/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger(auteur invité).

Je rappelle que ce billet est le second d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

Il est préférable de télécharger directement les paquets sur le site officiel de MySQL.

Dans notre cas nous utiliserons une distribution CentOS 6.0 avec les paquets RedHat Cluster Suite . On commence donc par téléchargez les paquets suivant :

MySQL-Cluster-gpl-client-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-tools-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-storage-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-shared-7.1.15a-1.rhel5.x86_64.rpm

MSQL-Cluster-gpl-management-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-server-7.1.15a-1.rhel5.x86_64.rpm

On les installe avec la commande suivante:

[cce lang= »bash »]

rpm-ivh mysql-cluster-gpl-*

[/cce]

Je vous conseille de faire l’installation pas à pas. Si jamais lors de l’installation des paquets, vous rencontrez une erreur similaire a celle ci :

Vous devez désinstaller la librairie qui pose soucis . Car elle corrompt les paquets de MySQL-Cluster .

Serveur de management

Dans un premier temps il est préférable de commencer par les serveurs de management, il s’agit de la même configuration sur les deux, avec la même installation de paquet.

Nous devons créer config.ini dans le répertoire /var/lib/mysql-cluster qui permettra le chargement des fichiers de configuration pour le Cluster. On ajoute des directives de configuration suivantes dans le fichier.

[cce lang= »bash »]

# vim /var/lib/mysql-cluster/config.ini

[NDBD DEFAULT]

NoOFReplicas=2

LockPagesInMainMemory=1

DataMemory=4000M

IndexMemory=768M

ODirect=1

NoOfFragmentlogFiles=300

MaxNoOfConcurrentOperations=100000

TimeBetweenGlobalCheckpoints=1000

TimeBetweenEpochs=200

DiskCheckpointSpeed=5M

DiskCheckpointSpeedInRestart=50M

RedoBuffer=16M

MaxNoOfTables=9096

MaxNoOfAttributes=10000

MaxNoOfExecutionthreads=4

MaxNoOfOrderedIndexes=5000

[MYSQLD DEFAULT]

[NDB_MGMD DEFAULT]

[TCP DEFAULT]

SendBufferMemory=8M

ReceiveBufferMemory=8M

[NDB_MGMD]

NodeId=1

HostName=12.0.1.10

[NDB_MGMD]

NodeId=2

HostName=12.0.1.11

[NDBD]

NodeId=3

HostName=12.0.1.30

[NDBD]

NodeId=4

HostName=12.0.1.31

[MYSQLD]

Hostname=12.0.1.20

[MYSQLD]

Hostname=12.0.1.21

[/cce]

Il faut que les deux serveurs de management possède exactement le même fichier de configuration, si vous êtes sous CentOS et que vous n’avez jamais touché a la configuration du parefeu, pensez a le désactiver.

[cce lang= »bash »]

# chkconfig iptables off

[/cce]

Serveurs SQL et serveurs de nœud

Il vous faut installer les mêmes paquets sur ces quatres autres machines, et elles possèdent toutes le même fichier de configuration /etc/my.cnf

[cce lang= »bash »]

# vim /etc/my.cnf

[client]

port=3306

socket=/var/lib/mysql/mysql.sock

[MYSQLD] # Options du processus mysqld

ndbcluster # Fonctionne en mode NDB

ndb-connectstring=12.0.0.100 # Situation du noeud MGM

[MYSQL_CLUSTER] # Options pour le processus ndbd

ndb-connectstring=12.0.0.100 # Situation du noeud MGM

[/cce]

Sur les serveurs SQL pensez a utiliser la commande :

[cce lang= »bash »]

# mysql_secure_installation

[/cce]

Elle permet de donner un mot de passe par défaut a votre serveur SQL, ainsi que l’accès a distance .

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Concept de base 2/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger (auteur invité).

Je rappelle que ce billet est le second d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

MySQL Cluster est constitué de trois briques:

  1. Premièrement, un jeu de processus serveurs MySQL. Ce sont des serveurs MySQL traditionnelles, avec le nouveau moteur de table NDBCluster qui autorise l’accès aux tables en cluster.
  2. Le second type de processus est représenté par les noeuds de stockage de NDBCluster. Ces processus contiennent les données stockées dans MySQL Cluster. Les données de MySQL Cluster sont réparties entre les différents noeuds du cluster, et sont aussi doublées dans le cluster.
  3. Le troisième type de processus est les processus d’administration. Ces processus sont utilisées pour gérer la configuration du cluster.

Nous appelons ces processus de cluster les noeuds du cluster. Mettre en place la configuration du cluster implique la configuration de chaque noeud dans le cluster, et la configuration de chaque moyen de communication entre les noeuds du cluster.

MySQL Cluster est actuellement configuré avec le pré-requis que les noeuds sont homogènes en terme de puissance processeur, espace mémoire et largeur de bande. De plus, pour activer un point de configuration, il a été décidé de placer toute la configuration du cluster dans un seul fichier de configuration.

De plus, il y a un nombre arbitraire de clients connectés au cluster. Ils sont de deux types: ces clients accèdent au serveur de management, et émettent des commandes pour lancer ou arrêter correctement des noeuds, lancer ou arrêter la trace serveur (pour les versions de débogage), pour afficher la configuration courante, voir l’état des noeuds du cluster, afficher les versions et noeuds, lancer les sauvegardes, etc.

Configuration simple-multi serveurs

Nous allons configurer un cluster de deux noeuds, deux serveurs de management, deux LVS en FailOver, et deux serveurs SQL.

 

Naturellement, les machines multi-processeurs et celles aux fréquences supérieures seront plus rapides. Les besoins en RAM des processus du Cluster MySQL sont relativement raisonnables.

Sécurité

Les communications entre les noeuds du Cluster MySQL ne sont pas chiffrées ou protégées de quelque manière que ce soit. La seule solution pour protéger les transmissions à l’intérieur du Cluster MySQL est de placer le Cluster MySQL dans un réseau protégé. Si vous envisagez d’utiliser le Cluster MySQL pour une application Web, il est recommandé que le Cluster MySQL soit placé derrière un pare-feu, et non pas dans la zone démilitarisée (DMZ) ou ailleurs.

Efficacité

Configurer un Cluster MySQL sur un réseau privé ou protégé donne au Cluster MySQL l’exclusivité de la bande passante. En utilisant un switch dédié au Cluster MySQL aide à la protection contre les accès non autorisés, et il protège les noeuds des interférences causées par les autres machines sur le réseau. Pour une stabilité accrue, vous pouvez utiliser des switchs redondants et des cartes réseau doubles pour supprimer du réseau les points de panne.

Fonctionnement de cette architecture

Nous avons choisis de virtualiser l’ensemble des serveurs sur Vmware ESXi, cela nous donne une meilleure souplesse quand au changement matériel ( augmentation de RAM / Rajout de carte réseau ) .

Les clients contactent l’application hébergé sur nos serveurs, sur ces serveurs nous inscrivons les adresses des LoadBalancer . Le protocole de routage Round Robin alternera l’envoie des paquets sur les serveurs SQL définis dans sa pool .

Les serveurs SQL ne contiennent pas les données propres a la base de données, ils ne sont la que pour traiter les requètes . A leurs tours ils contactent les Noeuds qui possèdent la totalité de la base de données chargé dans leur RAM.

Les serveurs de management servent a renseigner les serveurs du cluster. C’est lui qui définit les rôles des serveurs . Et répartir la charge automatiquement entre les Noeuds .

L’ensemble des données stocké en RAM sont répliqué entre tous les nœuds, et la charge et partagé entre le nombre de serveurs nœud .

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Tutoriels 1/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger (auteur invité).

La problématique de répartition des données est un problème majeur des infrastructures de gestion de l’information. Alors que l’approche historique consiste à dimensionner un seul serveur de façon à ce qu’il absorbe toute la charge, on observe depuis plusieurs années une tendance inverse, inspirée des techniques de RAID pour les volumes de stockage, qui consiste a prendre un très grand nombre de machines a faible coût pour former un cluster de stockage.

Il existe plusieurs façons différente de mettre en place un Clusteur de Stockage avancé, que je vais vous faire découvrir. Cette série de billet va se focaliser sur la solution MySQL Cluster, la base de données distribuée de MySQL.

 J’installerais MySQL Cluster sur une distribution CentOS, qui peut également être adapter a une distribution RedHat, comme il s’agit de paquet disponible dans les dépôts ReDHat Cluster Suite.

De plus vous trouverez des machines virtuelles sous VMware avec l’ensemble de l’architecture .

Voici le sommaire des 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

On commence de ce pas par le premier article !

Introduction

Dans le domaine des systèmes de gestion de bases de données,MySQL fournit une solution élégante pour réaliser un cluster à faible coût permettant d’atteindre un niveau de disponibilité proche des 99,999% annuel.

 Un Cluster MySQL est un groupe de processus qui s’exécutent sur plusieurs serveurs MySQL, des noeuds NDBCluster, et des processus d’administration, ainsi que des processus d’accès spécialisés. Tous ces programmes fonctionnent ensemble pour former un Cluster MySQL. Lorsque les données sont stockées dans le moteur NDBCluster, les tables sont réparties sur les noeuds NDBCluster. Ces tables sont directement accessibles depuis tous les autres serveurs MySQL faisant partie du Cluster. Par conséquent, si une application met à jour une ligne, tous les autres serveurs le verront immédiatement.

Les données stockées dans le moteur de table de MySQL Cluster peuvent être dupliquées, et sont capables de gérer une indisponibilité d’un noeud sans autre impact que l’annulation des transactions qui utilisaient ces données.

Elle permet de répartir des données sur plusieurs serveurs sans avoir de point individuel de défaillance. Contrairement aux moteurs MyISAM et InnoDB généralement utilisés avec MySQL, l’exploitation effective du cluster nécessite l’utilisation du moteur NDB, qui contient plusieurs restrictions, comme l’absence d’index FULLTEXT.

 MySQL est capable, depuis la version 4.1 et grâce au moteur de stockage NDB de gérer une grappe de serveurs complète.

  • augmenter la disponibilité
  • faciliter la montée en charge
  • permettre une répartition de la charge
  • faciliter la gestion des ressources (processeur, mémoire vive, disques dur, bande passante réseau).

Sa structure repose sur la duplication données, c’est-à-dire que chaque nœud fera partie d’un groupe de nœud qui posséderont tous la totalité de la base

Un protocole implémenté dans chaque nœud s’occupe d’adresser chaque transaction aux différents nœuds concernés dans la grappe, il faut un minimum de 3 machines pour établir une solution de clustering MySQL et une machine (qui peut elle-même intégrer un serveur MySQL) qui va jouer le rôle de répartiteur de charge en redirigeant les requêtes sur les nœuds disponibles et les moins occupés.

Par rapport à un système de réplication, la redondance est améliorée : si un nœud tombe en panne, sa charge est automatiquement reprise par les autres nœuds.

L’ajout d’un nouveau nœud peut se faire sans avoir besoin de repartitionner la base, il suffit de le faire reconnaître par la grappe et le redémarrage d’un nœud peut se faire sans avoir à redémarrer la grappe.

Du point de vue de MySQL, chaque nœud fait partie d’un ensemble qui pourrait être reconnue comme une seule machine.

Pour le programmeur, il doit programmer son application pour communiquer avec le répartiteur de charge.

Cette solution s’adapte parfaitement lorsque la disponibilité et la sécurité des données est un problème critique et que l’on recherche un partitionnement technique responsable de l’écriture. Couplé a des fonctionnalités temps réel et a une API de programmation asynchrone NDB Cluster s’adresse principalement aux exigences du marché des télécommunications.

Vous pouvez vous rendre sur la page suivante pour voir la liste exhaustive des fonctions proposées dans la version communautaire (gratuite et open-source) de MySQL Cluster.

Catégories
Developpement Open-source Planet-libre Reseau Systeme Web

VnStat.js, un node pour VnStat

Mes derniers billets traitaient de VnStat (le logiciel pour surveiller les débits de vos interfaces Ethernet) et de Node.js (le framework permettant de créer facilement des applications réseaux coté serveur). C’est donc dans ma logique toute cartésienne, que j’ai développé un javascript permettant de disposer d’une interface Web pour consulter ces statistiques de débits sans avoir à installer un serveur Web et son plugin PHP (comme c’est le cas avec le VnStat PHP frontend).

Ce script, disponible sous licence GPL v3, s’appelle VnStat.js est disponible dans mon GitHub à l’adresse suivante:


https://github.com/nicolargo/vnstat.js

Installation

Pour fonctionner correctement, VnStat.js nécessite:

  • une installation de VnStat fonctionnelle. Je vous conseille la lecture de ce billet pour effectuer une installation « from-scratch » sur une machine tournant sous Debian / Ubuntu.
  • que le framework Node.js soit installé sur cette même machine. Le script a été validé avec la dernière version stable de Node.js (0.4.12).

On commence par récupérer la dernière version de VnStat.js depuis le dépôt Git:

[cce lag= »bash »]

cd ~

git clone git://github.com/nicolargo/vnstat.js.git

cd vnstat.js

[/cce]

Pour les personnes utilisant NPM (le package manager de Node.js), vous pouvez l’utiliser pour installer VnStat.js. Suivre les instructions de cette page.

Lancement de VnStat.js

Pour lancer le noeud VnStat.js, il suffit de saisir les commandes suivantes:

[cce lag= »bash »]

cd ~/vnstat.js

node ./vnstat.js

[/cce]

Le « node » va se mettre en écoute sur le port TCP 1337 de votre serveur (il faut donc ajouter une règle pour autoriser les requêtes entrantes vers ce port si vous avez un firewall).

A l’ouverture de l’URL http://adressedevotremachine:1337/ dans un navigateur compatible HTML5, la page principale suivante va s’afficher:

Elle affiche le résumé des statistiques de VnStat ainsi que le top 10 des journées. Le menu du haut permet de naviguer vers des statistiques plus ciblés.

Par heures (avec à la fois la vue graphique et textuelle):

Et ainsi de suite pour les jours, semaines (à noter qu’il n’y a pas de graphe spécifique par semaine généré par vnstati) et enfin par mois.

Configuration de VnStat.js

Le design de VnStat.js peut bien entendu être adapté à vos besoins en éditant le fichier css/style.css (CSS3). Si vous avez besoin de changer le port TCP d’écoute du node, il y a une variable pour cela dans le fichier lib/server.js.

C’est mon premier développement avec le framework Node.js, il y a sûrement des améliorations à faire mais la structure reste assez didacticiel pour servir de base pour d’autre développement du même type.

Lancement automatique de VnStat.js au démarrage de votre machine

 Comme vous avez pu le remarquer, le node VnStat.js est lancé à la main dans ce billet. Si vous souhaitez mettre en production ce script et le lancer automatiquement au démarrage de votre machine, je vous conseille la lecture du billet de Vincent sur son blog qui regorge d’information sur ce superbe framework qu’est Node.js.