Affichage des articles dont le libellé est cluster. Afficher tous les articles
Affichage des articles dont le libellé est cluster. Afficher tous les articles

dimanche 11 mars 2012

module forever de #node.js: pour une production sure

Dans un post précédent j'ai évoqué le fonctionnement de Node.js. Il existe un module appelé 'forever' qui industrialise le lancement de script javascript pour Node.js.
L'installation se fait comme d'habitude par la commande

sudo npm -g install forever

Le résultat doit etre:


/usr/local/lib/node_modules/forever
├── pkginfo@0.2.3
├── timespan@2.0.1
├── watch@0.5.0
├── microtime@0.2.0
├── daemon@0.4.1
├── node-fork@0.4.2
├── nssocket@0.3.7 (eventemitter2@0.4.8 lazy@1.0.8)
├── cliff@0.1.7 (colors@0.6.0-1 eyes@0.1.7)
├── portfinder@0.2.1 (mkdirp@0.0.7)
├── optimist@0.2.8 (wordwrap@0.0.2)
├── broadway@0.1.13 (colors@0.6.0-1 eventemitter2@0.4.8 optimist@0.3.1)
├── minimatch@0.0.5 (lru-cache@1.0.5)
├── utile@0.0.10 (async@0.1.18 mkdirp@0.3.0 rimraf@1.0.9 ncp@0.2.5)
├── flatiron@0.1.14 (director@1.0.9-1 optimist@0.3.1 prompt@0.1.12)
├── nconf@0.5.1 (async@0.1.18 ini@1.0.2 optimist@0.3.1)
├── ps-tree@0.0.2 (parse-table@0.0.0)
└── winston@0.5.10



Le lancement d'un programme par forever est très simple :

forever start 'monprogramme.js'


Exemple :(commande start et list)

 forever start cluster1.js

info:   Forever processing file: cluster1.js

german@german-1001PX:~$

german@german-1001PX:~$ forever list

info:   Forever processes running

data:       uid  command script      forever pid  logfile                        uptime     

data:   [0] YJVa node    cluster1.js 2857    2858 /home/german/.forever/YJVa.log 0:0:0:7.882


Si le programme lancé par forever vient à tomber, il  sera relancer automatiquement.
Forever est lui même en mode daemon (on peut fermer son terminal de lancement) 

L'aide sur forever est la suivante:

L'article http://blog.nodejitsu.com/keep-a-nodejs-server-up-with-forever et le site de forever complètent mon propos.
Sur stackoverflow : un exemple d'usage de forever à l'intérieur d'un programme.

samedi 10 mars 2012

#node.js en cluster


Dans son mode de fonctionnement normal Node.js sera vu  par le système d'exploitation comme un programme mono-thread tournant sur un seul processeur. Ce mode d’exécution est optimum pour Node.js: il n'aura pas à partager des variables ni à synchroniser des threads. C'est plus une philosophie qu'une limite de Node.js.
Si vous avez  besoin de renforcer votre infrastructure en utilisant tous les processeurs,vous pouvez utiliser le module cluster. Ce dispositif permet de lancer le même  programme javascript sur plusieurs instances Node.js. Attention tous les programmes ne se prêtent pas à cette forme d'écriture et d'utilisation. Dans certains cas il sera nécessaire de mettre en place une communication inter-processus, mais c'est une autre histoire. L'installation se fait par


npm install -g cluster


Structure du programme.


La structure du programme est classique pour ce type d'utilisation :
La partie père du programme  accède à une fonction qui  retourne la liste des processeurs disponibles sur le PC. Puis en fonction du nombre, la partie père lance autant de fils que nécessaire. Dans l'exemple proposé, un numéro de PID pair d'un fils retourne un code OK '200', un numéro impair retourne une erreur '400'.
 


Après le lancement du script via node.js, la commande ps ax|grep node donnera:

 ps ax|grep node

 2596 pts/0    Sl+    0:00 node cluster1.js

 2598 pts/0    Sl+    0:00 /usr/local/bin/node /home/german/cluster1.js

 2599 pts/0    Sl+    0:00 /usr/local/bin/node /home/german/cluster1.js



La première ligne correspond au job du père, les deux autres aux  fils. Ce sont eux qui prennent indifféremment les connexions entrantes.
En cas de perte d'une instance le flux sera pris par la deuxième.
Les règles de répartion sont gérées par l'OS.
La fonction cpus donne sur ma machine:



[ { model: 'Intel(R) Atom(TM) CPU N450   @ 1.66GHz',
    speed: 1667,
    times:
     { user: 1768110,
       nice: 31500,
       sys: 936040,
       idle: 2281930,
       irq: 160 } },
  { model: 'Intel(R) Atom(TM) CPU N450   @ 1.66GHz',
    speed: 1667,
    times:
     { user: 1753240,
       nice: 40410,
       sys: 910150,
       idle: 2252070,
       irq: 140 } } ]


Tests avec jmeter

J'ai utilisé le projet libre jmeter pour tester le bon fonctionnement du dispositif.
Les copies d'écran présentent le plan de charge et le résultat de son exécution. 
Le plan de test

En  vert les codes retour 200 (OK)  en rouge les codes 400 (erreurs)


La aussi pas de surprise: plus la taille de l'échantillon augmente et plus la répartition est proche de la médiane.

En conclusion: Le mode cluster est à réserver pour un usage limité. Si on recherche de la tolérance de panne, le module forever sera plus adapté.

samedi 20 décembre 2008

Administrer un cluster de serveur avec ssh

Il est possible de mutualiser des configurations de serveur avec rsync et monit. Il suffit de modifier sur une machine 'maitre' un fichier pour qu'après un délais programmé les services rsync et monit diffusent le fichier aux autres noeuds du cluster. Le service monit sur les noeuds 'esclaves' detectera la reception et donc la modification du fichier et déclachera alors une action définie (ex: redemarrer un service Apache) . Par contre il est parfois necessaire dde lancer une même serie de commandes sur chaque noeud du cluster. Il existe un outils qui va soulager bien des administrateurs de cluster: Cluster ssh. Ce programme basé sur du Tcl/Tk propose une fenetre qui diffuse les commandes sur chaque noeud (en bas à droite) . Il est aussi possible de gerer individuellement chaque noeud.

Voici une copie d'écran: