Test de replication d'un serveur memcached

Pour mettre en place la réplication d'un serveur memcached ,il faut :
- Le source de memcached
- Le patch repcached à appliquer


Sur le site du projet repcached on trouve à la fois le patch mais aussi le source memcached patché.

Pour appliquer le patch :

Aller dans le répertoire supérieur de memcache et lancer la commande :
patch -p0 < 'le_nom_du_fichier_patche'

Puis aller dans le répertoire des sources memcached et taper :
./configure --enable-replication
make && make install

Dans le répertoire source se trouve l'executable memcached et la commande :

./memcached -v -u root

donne la ligne :
replication: listen

Confirmé par un netstat -a|grep LIST

tcp 0 0 *:11211 *:* LISTEN
tcp 0 0 *:11212 *:* LISTEN

Le port 11212 sera utilisé par la réplication

Si on relance memcached en très verbeux on peut suivre les connexions :
./memcached -vv -u root

<6 server listening (replication)
replication: listen
<7 server listening
<8 send buffer was 109568, now 268435456
<8 server listening (udp)

Je lance une deuxième instance de memcached sur un port différent :
./memcached -u root -p 11310 -x localhost -vv
Les lignes en sortie donnent :

replication: connect (peer=127.0.0.1:11212)
<6 new client connection
<7 new client connection
<8 new client connection
replication: marugoto copying
<6 marugoto_end
<9 server listening
<10 send buffer was 109568, now 268435456
<10 server listening (udp)
replication: start


Dans la première console s'ajoute les lignes :

replication: accept
<6 connection closed.
<9 new client connection
<6 new client connection
<10 new client connection

Ainsi le premier serveur est en relation avec le deuxième
L'ajout d'une session sur le deuxième serveur est répercuté sur la premier serveur
(deuxième serveur)
<11 new client connection
<11 set fac097f7fb944ea33b7fb2f31b45b9b4 1 0 56
>11 STORED
<11 set fac097f7fb944ea33b7fb2f31b45b9b4 1 0 94
>11 STORED

(premier serveur)
<9 rep fac097f7fb944ea33b7fb2f31b45b9b4 1 0 56 1
REP>9 STORED
<9 rep fac097f7fb944ea33b7fb2f31b45b9b4 1 0 94 2
REP>9 STORED

Le seul mode disponible est donc le mode master/master

Si on coupe un serveur et qu'on ajoute des entrées sur l'autre , au redémarrage du serveur stoppé , les lignes suivantes vont s'afficher :
replication: marugoto start
replication: marugoto 7
replication: marugoto owari

(l'auteur est japonais et aime le manga !! )

Le serveur qui est resté en marche envoie les données que le serveur stoppé n'a pas enregistrées.

Ainsi se dispositif réalise à la fin la synchronisation ET la restauration des sessions .
Les nouvelles options de réplications ne sont fournies qu'a la deuxieme instance par les paramètres : -x host_de_l_autre_serveur -X port de réplication (defaut 11212) comme l'indique l'option -h (help)
-x hostname or IP address of peer repcached
-X TCP port number for replication (default: 11212)

L'avantage de ce dispositif est qu'il est intégré à memcached et qu'il propose un système de resynchronisation.

Activerecord et les attributs virtuels

Le modèle CRUD ( create ,read , update ,delete) de Ruby on Rails est très simple.
Le framework mappe les tables avec des modèles par activerecord et mappe le modèle à un couple controleur/vue .

Le mapping repose sur la bijection : un champs de la table correspond à un attribut de l'objet Ruby.

Exemple : la table users avec les champs ''prenom',nom' et la clé 'id' se traduit par une vue avec un formulaire avec deux champs :"prenom " et "nom".

Mais il arrive parfois que l'on veuille parfois manipuler des attributs qui non pas d'existence réelle dans une table . Par exemple je veux traiter prenom et nom comme un champs unique : 'nom complet' , ou ajouter un champs uniquement destiné à la présentation dans un formulaire.

Plusieurs possibilités s'offrent à nous : soit traiter ce champs dans le contrôleur , soit l'ajouter comme un champs virtuel au modèle .

A mon avis la deuxieme solution est la meilleure car elle insère le virtuel au plus tot dans la logique de traitement. Et ainsi elle permet de bien regrouper tous les attributs au sein d'un même objet très flexible.

Pour cela il faut ajouter deux méthodes au modèle :

# models/user.rb
def nom_complet
 [prenom, nom].join(' ')
end

def nom_complet=(chaine)
 split = chaine.split(' ', 2)
 self.prenom = split.first
 self.nom = split.last
end

Le contrôleur et la vue pourront maintenant manipuler un troisième champs 'nom_complet' .

Une autre technique permet aussi de modifier le comportement mais pas le mappage des attributs :
les méthodes write_attribute et read_attribute d'activerecord

    def length=(minutes)
     write_attribute(:length, minutes.to_i * 60)
   end

   def length
     read_attribute(:length) / 60
   end

Si les modifications à prévoir ne sont destinées qu'à l'affichage , il est préférable de d'utiliser des' helpers' mutualisables par plusieurs champs de meme type (exemple : les champs dates ou booleens ) .

voir une demo sur railscasts.

Serveur de session memcached: replication des sessions

J'utilise une architecture de gestion de session a base de memcached . Nativement les clients memcached savent repartir la charge sur plusieurs serveurs. Reste, le problème de la chute d'un serveur memcached qui provoquera la perte des sessions hébergées par ce serveur. J'ai développé il y a quelques temps un système de réplication des sessions memcached basée sur les log (mode verbeux --vv ) . Un script Perl va lire ce fichier et rejoue les opérations sur un ou plusieurs serveurs memcached . Ainsi plusieurs serveurs sont synchronisés en temps réel.
J'avais prévu un mode 'maitre-esclave' et un mode 'maitre-maitre' . Sur fresmeat le projet repcached communique sur un patch pour mecached qui lui ajoute des fonctions de réplication.

C'est une excellente nouvelle et je prévoit des tests sur le produit.

SOA :partie 2

Dans le premier post sur SOA , j'avais énuméré les différents composants d'une architecture SOA.

Je vais exposer maintenant comment développer une application sous SOA et quel sont les questions à poser pour déterminer si votre organisation est faite pour le SOA

Développer une application SOA .

Une application SOA est un agrégat de d'interaction entre des composants. L'écriture des composants ressemble au développement d'un web service. Mais se qui change c'est le déshabillages composants au profil de la base de registre. Un composant doit etre 'basique' , il doit embarquer le moins d'intelligence possible. Cette intelligence doit être stockée dans la base de registre et l'évolution du traitement métier du composant se fera par la gouvernance de cette base de registre.
On ne parlera pas de mise en oeuvre d'une application mais de la modélisation d'un processus métier par des outils de BPM (Business Process Management) .
Ces outils BPM sont connectés avec la base de registre , le moteur de workflow et le gestionnaire de version.

Questions à se poser avant d'attaquer le SOA.

1) Votre secteur d'activité est-il large et complexe ?
2) Votre secteur change-t-il rapidement ?
3) Vos applications cachent elles des richesses ?
4) Avez vous une architecture informatique flexible ?
5) Comment votre entreprise réagi aux changements ?
6) Les services sont ils interdépendants ?
7) Utilisez vous des technologies propriétaires ou des standards ouverts ?
8) Savez vous où sont vos règles de gestions ?
9) Avez vous confiance dans l'adaptation et la qualité de vos données ?
10) Pouvez vous connecter votre système avec celui de vos partenaires ?


Si vous avez une majorité de 'OUI' vous etes SOA ready .

Ajouter de la graisse de singe dans son firefox (greasemonkey)

Firefox est riche en extensions diverses , il y en a une qui est très intéressante: greasemonkey.

Cette extension permet de réaliser des traitements dynamiques sur les pages web. Pour cela , il suffit d'écrire des petits scripts en javascript et de les intégrer à firefox grace à greasemonkey.
Par exemple ce script
:
// ==UserScript==
// @name hello
// @description essai eric
// ==/UserScript==
alert ('hello world');


Affichera une fenetre pop-up sur chaque page consultée :





La gestion des scripts se fait par une nouvelle fenetre dans firefox :



Il est possible de cantonner le déclenchement d'un script pour une série de site.

Quelques usages de ces sripts :

-Bloquer des popup, des images .
-Ajouter des liens automatiquement
-Telecharger des fichiers rapidement (rapidshare)
-Réecrire des liens à la volée .

Un exemple de réécriture : ajouter automatiquement ?.jpg à la fin des url . Mais pourquoi faire ? . Des petits malins se sont aperçu que sur certains Hot-spot wifi payants , il était possible de surfer sans payer simplement en ajoutant '?.jpg' à la fin des URL. Le système ne filtre pas les images et l'ajout de cette chaine de caractère est sans conséquence pour la navigation. Vous pouvez essayer dans certains aéroports des USA.

Donc le script suivant :
// ==UserScript==
// @name addjpg
// @description essai jpg
// ==/UserScript==
if (window.location.toString().match(".jpg") == null) {
window.location.replace(window.location + '?.jpg');
}

Ajoutera systématiquement la chaine magique sur toutes les URL sauf celles possédant déjà l'extension.

L'adresse du projet Greasemonkey est www.greasespot.net. Sur ce site on trouvera un dépôt de script avec plusieurs milliers de programmes.

anniversaire benjamin et guillaume

Le 22 aout grand évenement , on a fêté l'anniversaire des garcons : 17 ans




Le reste des photos est sur l'album : ici (la ciotat , le sentier des ocres )

Un programme pour lister les differences

Un outils très pratique pour les codeurs : beediff de beesoft.org

Ce programme permet de comparer visuellement deux fichiers.
Le résultat est présenté sous cette forme :


C'est pas beau ca ?