/var/log/greg.log

Sur quelques serveurs j'ai la chance d'avoir un montage NFS ainsi qu'un montage GlusterFS 2.0-rc4.

• un fichier de 17ko: cache_c21f969b5f03d33d43e04f8f136e7682_c57d91c82f2ed2e96c13765e33fcd5ae
• un fichier de 50mo: 50.MB

J'ai copié ces 2 fichiers sur le disque dur dans /tmp, ainsi que sur les 2 montages réseaux, puis effectuer un simple cat (plusieurs fois), et voici les résultats :

php-14:~# for f in
/var/www/cache/cache_c/cache_cf/cache_cfb/cache_c21f969b5f03d33d43e04f8f136e7682_c57d91c82f2ed2e96c13765e33fcd5ae
/nfs/tmp/cache_c21f969b5f03d33d43e04f8f136e7682_c57d91c82f2ed2e96c13765e33fcd5ae
/tmp/cache_c21f969b5f03d33d43e04f8f136e7682_c57d91c82f2ed2e96c13765e33fcd5ae
/glusterfs/50.MB /nfs/tmp/50.MB /tmp/50.MB; do
echo $f; time cat $f >/dev/null; done
/var/www/cache/cache_c/cache_cf/cache_cfb/cache_c21f969b5f03d33d43e04f8f136e7682_c57d91c82f2ed2e96c13765e33fcd5ae

real    0m0.011s
user    0m0.000s
sys     0m0.000s
/nfs/tmp/cache_c21f969b5f03d33d43e04f8f136e7682_c57d91c82f2ed2e96c13765e33fcd5ae

real    0m0.002s
user    0m0.000s
sys     0m0.000s
/tmp/cache_c21f969b5f03d33d43e04f8f136e7682_c57d91c82f2ed2e96c13765e33fcd5ae

real    0m0.001s
user    0m0.000s
sys     0m0.000s
/glusterfs/50.MB

real    0m0.081s
user    0m0.000s
sys     0m0.068s
/nfs/tmp/50.MB

real    0m0.037s
user    0m0.000s
sys     0m0.036s
/tmp/50.MB

real    0m0.028s
user    0m0.000s
sys     0m0.028s

GlusterFS est donc plus lent que NFS pour les petits fichiers ET les "gros" fichiers, mais j'en ai pas finis avec le paramètrage ! Le serveur NFS est plutot bien optimisé, alors que je découvre seulement GlusterFS et que je commence seulement les tests...

Sur un serveur, je suis tombé à court d'inodes. Initialement prévu pour MySQL, la partition de données était plus ou moins optimisé pour cet usage. Oui mais voilà, ce serveur est amené à faire plusieurs choses, et entre autre, à devenir reverse-proxy squid.

server_smurtz:/data# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1             122624   11922  110702   10% /
tmpfs                2059274       6 2059268    1% /lib/init/rw
udev                 2059274     979 2058295    1% /dev
tmpfs                2059274       1 2059273    1% /dev/shm
/dev/sda9             407680  407680       0  100% /data
/dev/sda5             122624    2734  119890    3% /tmp
/dev/sda6             122624   29619   93005   25% /usr
/dev/sda7             732960    6261  726699    1% /var

On ne peut pas augmenter le nombre d'inodes d'une partition. C'est bête. Par contre, on peut diminuer la partition avec resize2fs ! Je vais donc diminuer la partition, afin de laisser uniquement mysql sur celle-ci, et créer une nouvelle partition sur l'espace ainsi libéré, avec un max d'inodes.

• voici les infos utiles, avant resize:

server_smurtz:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1               964500    236836    678668  26% /
tmpfs                  8237096         0   8237096   0% /lib/init/rw
udev                     10240       112     10128   2% /dev
tmpfs                  8237096         0   8237096   0% /dev/shm
/dev/sda5               964500    308220    607284  34% /tmp
/dev/sda6               964500    880784     34720  97% /usr
/dev/sda7              5763616    738920   4731916  14% /var
/dev/sda9            417378712 179547644 216958220  46% /data

server_smurtz:~# df -B 4k
Filesystem           4K-blocks      Used Available Use% Mounted on
/dev/sda1               241125     59209    169667  26% /
tmpfs                  2059274         0   2059274   0% /lib/init/rw
udev                      2560        28      2532   2% /dev
tmpfs                  2059274         0   2059274   0% /dev/shm
/dev/sda5               241125     77055    151821  34% /tmp
/dev/sda6               241125    220196      8680  97% /usr
/dev/sda7              1440904    184730   1182979  14% /var
/dev/sda9            104344678  44886911  54239555  46% /data
 
server_smurtz:~# cfdisk -P s /dev/sda
Partition Table for /dev/sda

               First       Last
 # Type       Sector      Sector   Offset    Length   Filesystem Type (ID) Flag
-- ------- ----------- ----------- ------ ----------- -------------------- ----
 1 Primary           0     1959929     63     1959930 Linux (83)           Boot
 2 Primary     1959930   856409084      0   854449155 Extended (05)        None
 5 Logical     1959930     3919859     63     1959930 Linux (83)           None
 6 Logical     3919860     5879789     63     1959930 Linux (83)           None
 7 Logical     5879790    17591174*    63    11711385 Linux (83)           None
 8 Logical    17591175*   21494969     63     3903795 Linux swap / So (82) None
 9 Logical    21494970   856409084     63   834914115 Linux (83)           None

server_smurtz:~# fdisk -s /dev/sda9
417457026

• il faut arrêter MySQL qui utilise cette partition, puis démonter la partition

server_smurtz:~# /etc/init.d/mysql.server stop
server_smurtz:~# umount /data

• ensuite on force un fsck, sinon resize2fs refusera toute action

server_smurtz:~# e2fsck -f /dev/sda9
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
data: 127010/407680 files (0.7% non-contiguous), 44906489/104364256 blocks

server_smurtz:~# e2fsck -D /dev/sda9
e2fsck 1.41.3 (12-Oct-2008)
data: clean, 127010/407680 files, 44906489/104364256 blocks

• on repartitionne à 198Go, pour laisser 2Go de marge pour le repartitionnement de la partition "physique"

server_smurtz:~# date -R; resize2fs -p /dev/sda9 198G; date -R
Thu, 26 Feb 2009 08:53:36 +0100
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/sda9 to 51904512 (4k) blocks.
Begin pass 2 (max = 36858691)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 3185)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 9302)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/sda9 is now 51904512 blocks long.

Thu, 26 Feb 2009 12:59:00 +0100

• un peu plus de 4h tout de même, sur des disques SAS 15kpm...

• je modifie le point de montage ainsi que la config de mysql

/data devient /var/local

server_smurtz:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sda1       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda5       /tmp            ext3    defaults        0       2
/dev/sda6       /usr            ext3    defaults        0       2
/dev/sda7       /var            ext3    defaults        0       2
/dev/sda8       none            swap    sw              0       0
/dev/sda9       /var/local      ext3    defaults        0       2
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/hda        /media/cdrom1   udf,iso9660 user,noauto     0       0


server_smurtz:~# rgrep /var/local /etc/mysql
/etc/mysql/my.cnf:datadir                                       = /var/local/mysql
/etc/mysql/my.cnf:#log-bin                              = /var/local/mysql_binlog/mysql-bin.log
/etc/mysql/my.cnf:innodb_data_home_dir                  = /var/local/mysql
/etc/mysql/conf.d/server_smurtz.cnf:#log-bin              = /var/local/mysql_binlog/mysql-bin.log
/etc/mysql/conf.d/server_smurtz.cnf:#log                  = /var/local/mysql_binlog/mysql.log
/etc/mysql/conf.d/server_smurtz.cnf:log-slow-queries      = /var/local/mysql_log/mysql-slow.log

• re fsck après le redimensionnement, et avant le montage

server_smurtz:~# e2fsck -f /dev/sda9
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
data: 127010/202752 files (0.7% non-contiguous), 44893808/51904512 blocks

• test de montage

server_smurtz:~# mount /var/local
server_smurtz:~# umount /var/local

• maintenant il faut réduire la partition, en la supprimant, et en créant une partition de 200Go. 200Go = 200x1024x1024 = 209715200k

server_smurtz:~# fdisk /dev/sda

The number of cylinders for this disk is set to 53309.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 438.4 GB, 438489317376 bytes
255 heads, 63 sectors/track, 53309 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000080

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         122      979933+  83  Linux
/dev/sda2             123       53309   427224577+   5  Extended
/dev/sda5             123         244      979933+  83  Linux
/dev/sda6             245         366      979933+  83  Linux
/dev/sda7             367        1095     5855661   83  Linux
/dev/sda8            1096        1338     1951866   82  Linux swap / Solaris
/dev/sda9            1339       53309   417457026   83  Linux

Command (m for help): d
Partition number (1-9): 9

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (1339-53309, default 1339): 1339
Last cylinder or +size or +sizeM or +sizeK (1339-53309, default 53309): +209715200K

Command (m for help): p

Disk /dev/sda: 438.4 GB, 438489317376 bytes
255 heads, 63 sectors/track, 53309 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000080

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         122      979933+  83  Linux
/dev/sda2             123       53309   427224577+   5  Extended
/dev/sda5             123         244      979933+  83  Linux
/dev/sda6             245         366      979933+  83  Linux
/dev/sda7             367        1095     5855661   83  Linux
/dev/sda8            1096        1338     1951866   82  Linux swap / Solaris
/dev/sda9            1339       27447   209720511   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

• reboot

server_smurtz:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             942M  232M  663M  26% /
tmpfs                 7.9G     0  7.9G   0% /lib/init/rw
udev                   10M  112K  9.9M   2% /dev
tmpfs                 7.9G     0  7.9G   0% /dev/shm
/dev/sda5             942M   18M  877M   2% /tmp
/dev/sda6             942M  861M   34M  97% /usr
/dev/sda7             5.5G  724M  4.6G  14% /var
/dev/sda9             198G  171G   18G  91% /var/local

• on peut maintenant ajuster la partition pour qu'elle fit bien dans les 200Go

server_smurtz:~# /etc/init.d/mysql.server stop
Shutting down MySQL................................
server_smurtz:~# umount /var/local

server_smurtz:~# e2fsck -f /dev/sda9
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
mysql: 127016/202752 files (0.7% non-contiguous), 45231149/51904512 blocks
server_smurtz:~# date -R; resize2fs /dev/sda9; date -R
Thu, 26 Feb 2009 13:51:54 +0100
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/sda9 to 52430127 (4k) blocks.
The filesystem on /dev/sda9 is now 52430127 blocks long.

Thu, 26 Feb 2009 13:52:04 +0100
server_smurtz:~# e2fsck -f /dev/sda9
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
mysql: 127016/204928 files (0.7% non-contiguous), 45231251/52430127 blocks
server_smurtz:~# mount /var/local

 * on a gagné (52430127-51904512) x 4048 / 1024 / 1024 = 2029Mo

• maintenant, création d'une partition sur sda10 avec un max d'inodes

server_smurtz:~# mkfs.ext3 -L data -O dir_index -b 2048 -i 2048 /dev/sda10
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=data
OS type: Linux
Block size=2048 (log=1)
Fragment size=2048 (log=1)
103874560 inodes, 103868240 blocks
5193412 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=641728512
6340 block groups
16384 blocks per group, 16384 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        16384, 49152, 81920, 114688, 147456, 409600, 442368, 802816, 1327104,
        2048000, 3981312, 5619712, 10240000, 11943936, 35831808, 39337984,
        51200000

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.


server_smurtz:~# tune2fs -l /dev/sda10
tune2fs 1.41.3 (12-Oct-2008)
Filesystem volume name:   data
Last mounted on:          <not available>
Filesystem UUID:          189850f6-fb66-40e3-b188-750a7f5901e7
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              103874560
Block count:              103868240
Reserved block count:     5193412
Free blocks:              90827363
Free inodes:              103874549
First block:              0
Block size:               2048
Fragment size:            2048
Reserved GDT blocks:      512
Blocks per group:         16384
Fragments per group:      16384
Inodes per group:         16384
Inode blocks per group:   2048
Filesystem created:       Thu Feb 26 13:43:59 2009
Last mount time:          n/a
Last write time:          Thu Feb 26 13:49:34 2009
Mount count:              0
Maximum mount count:      34
Last checked:             Thu Feb 26 13:43:59 2009
Check interval:           15552000 (6 months)
Next check after:         Tue Aug 25 14:43:59 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      41f7656a-cf10-4abe-b88c-483c919b3750
Journal backup:           inode blocks

• fstab devient, avec l'option noatime pour ces 2 partitions de données :

server_smurtz:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sda1       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda5       /tmp            ext3    defaults        0       2
/dev/sda6       /usr            ext3    defaults        0       2
/dev/sda7       /var            ext3    defaults        0       2
/dev/sda8       none            swap    sw              0       0
/dev/sda9       /var/local      ext3    defaults,noatime        0       2
/dev/sda10      /data           ext3    defaults,noatime        0       2
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/hda        /media/cdrom1   udf,iso9660 user,noauto     0       0

• et voilà ! Après redimenssionnement, voilà ce que donne l'état des partitions et des inodes :

server_smurtz:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             942M  232M  663M  26% /
tmpfs                 7.9G     0  7.9G   0% /lib/init/rw
udev                   10M  116K  9.9M   2% /dev
tmpfs                 7.9G     0  7.9G   0% /dev/shm
/dev/sda5             942M   18M  877M   2% /tmp
/dev/sda6             942M  861M   34M  97% /usr
/dev/sda7             5.5G  724M  4.6G  14% /var
/dev/sda10            174G   83M  164G   1% /data
/dev/sda9             200G  173G   18G  91% /var/local
server_smurtz:~# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1             122624   11923  110701   10% /
tmpfs                2059274       6 2059268    1% /lib/init/rw
udev                 2059274     987 2058287    1% /dev
tmpfs                2059274       1 2059273    1% /dev/shm
/dev/sda5             122624      18  122606    1% /tmp
/dev/sda6             122624   29656   92968   25% /usr
/dev/sda7             732960    6266  726694    1% /var
/dev/sda10           103874560      11 103874549    1% /data
/dev/sda9             204928  127020   77908   62% /var/local

MySQL devrait sortir ce mois-ci la version 5.1.31, qui corrigera entre autre le bug #38883 concernant InnoDB, qui cause des crashs aléatoires, lors de l'interrogation du status innoDB du serveur:

• SHOW INNODB STATUS
• innodb-status-file=1
• MySQL enterprise monitor

MySQL 5.1 GA est sortie en grande pompe, et tout le monde y va de son billet, pour ou contre. J'ai pu le mettre en environnement de production en mode master/slave et slave: le premier est slave d'un 5.0.56, et master d'un 2ème serveur en 5.1.30.

On peut nettement apercevoir sur le graph CPU suivant, la mise en prod de la version 5.1.30, avec une très nette augmentation des IO disques ! Le slave (22), en 5.0, prenait parfois du délais lors de la regénération de tables, en 5.1 il prend nettement plus de délais. Je n'ai même pas testé les nouvelles fonctionnalités comme le partitionnement, ayant lu sur plusieurs articles que cette version était encore trop buguée si on les utilisait...

Ah oui, et c'est pas tout... Le master/slave (21) a lamentablement crashé, après 6 jours seulement d'utilisation ! Un ticket est ouvert chez MySQL, qui n'a pas de solution, et attend le prochain crash avec cette fois les core dump d'activés. En espérant que ce crash n'arrive pas pendant les fêtes !

Présentation

• Gluster.org
• Création d'un cluster de fichiers à la fois serveur et client

Avantages

• GlusterFS est comparable à NFS, en beaucoup plus performant, plus scalable et prévu pour la haute-dispo.
• Le wiki est complet avec beaucoup de docs et de tutorials.
• L'architecture du projet permet d'empiler les fonctionnalités, on peut donc mixer les fonctionnalités pour faire du mirroring, striping, unification, read-ahead, write-behind, encryption etc.
• Automagic self-healing si un serveur tombe.
• Roadmap importantes avec plein de fonctionnalités intéressantes comme le mod apache, hot-plug de brick, interface web, etc.

Inconvénients

• Le projet est jeune.
• pas vraiment de retour d'expériences en environnement de production.
• Fonctionne en Userspace (FUSE) plutôt que dans un module kernel. Voir les implications sur les perfs.
• la doc est uniquement dans le wiki, un trac serait mieux...
• à vérifier: les données ne semble synchronisés qu'une fois lu, c'est à dire que si on écrit un fichier sur serveur B, les données sont tout de suite lisible, MAIS si on écrit d'autres fichiers sur serveur B, et qu'on ne les lit pas, ils ne sont pas synchronisés. Il faut donc forcer une lecture, par exemple:

find /mnt/rep -type f -exec head -n 1 {} \;
ou, plus efficace :
find /mnt/rep -type f -mtime -1 -exec head -c 1 {} > /dev/null \;

Dans le prochain billet: l'installation.

Actuellement, pour les sessions, nous utilisons un gros serveur et MySQL avec des tables en HEAP pour stocker les sessions. Problème, ces tables ne supportent pas les types BLOB et TEXT, ce qui implique d'utilise un champ VARCHAR, limité à 255 caractères, on atteint très vite cette limite.

Je suis donc à la recherche d'alternatives, sachant qu'on va stocker plus d'informations pour éviter au maximum les cookies, et que les performances requises sont importantes: aujourd'hui environ 2000 requêtes de sessions / secondes, demain ce sera bien pire à cause du web 2.0.

MySQL Cluster

MySQL n'est pas encore sortie en version stable en 5.1, version nécéssaire pour avoir un MySQL Cluster. Avec tous les problèmes que l'on rencontre avec 5.1 (enfin, uniquement les nouvelles fonctionnalités), le temps de mise en oeuvre, le coût des serveurs, cette solution est fortement compromise. D'autant plus que MySQL n'utilise pas sa propre solution pour ses propres besoins...

Zend Cluster

Alléchant sur le papier, mais beaucoup trop cher ! Ils vont devoir s'aligner pour espérer continuer à en vendre...

memcached

http://www.danga.com/memcached/

Comme stipulé à plusieurs endroits dans la doc, memcached est un serveur de cache avant tout. Ce qui veut dire perte de données en cas d'arrêt du démon. Il a été prévu pour faire du cache, et le fait d'ailleurs très bien. Son modèle cluster est orienté scalability et pas du tout redondance ni failover. Admettons que nous avons 3 serveurs memcached en cluster, A B et C. A chaque requête PHP en écriture (ajout, remplacement d'une session), le client se connecte à tous les serveurs, créé une clef en fonction de ces serveurs, et choisis un des serveurs: B. Seul B aura la valeur pour cette clef. La requête suivante, en lecture, veut lire cette clef, le client PHP se connecte aux 3 serveurs, génère la clef, et va chercher la valeur sur B. Très bien, on répartie la charge sur ces 3 serveurs, et la mémoire n'est pas gaspillé car les données ne sont pas duppliqué. Ainsi, si B tombe, on perd uniquement les données de sessions de ce serveur, on déconnecte donc seulement 1/3 des utilisateurs. Seulement voilà, c'est pas aussi beau. Si un noeud tombe, la liste des serveurs dans le pool change, et le client va regénérer toutes les clefs !! En d'autre terme, si un noeud tombe, on perd tout le cache ! On se retrouve donc avec autant de POF (Point Of Failure) que de serveurs. Dropped.

memcachedb

http://memcachedb.org/

Reprenant le moteur de memcached, le principe est différent, et cette fois le but n'est pas de faire du cache mais de stocker des données persistentes. En mode cluster, on a un fonctionnement identique à MySQL: un noeud est maitre, les autres noeuds répliquent et peuvent être accédé en lecture. Les performances sont là, leur benchmark indique atteindre 20000 écritures / secondes, et 45000 lectures / secondes, ce qui est amplement suffisant. Mais le principe du single master to many slaves est genant: il m'arrive régulièrement de retirer un serveur de la production, pour le mettre à jour, le restaurer, ou en cas de problèmes hardware... et si c'est le master qui a un problème ? on doit créer un autre master, et changer la config des slaves afin qu'ils répliquent leurs données depuis un autre master ! Dropped.

Sharedance

http://sharedance.pureftpd.org/

Ce logiciel a été créé pour cet usage et uniquement pour cet usage. Tout comme memcached, il excèle dans son travail. Tous les commentaires que j'ai pu trouvé sur le net en font l'éloge, et surtout on retrouve tout le temps "Ca n'a jamais planté". Un utilisateur atteint 200Mbps x 2 sur un seul serveur, époustouflant ! C'est la solution quasiment idéal... et oui, le soucis, c'est que c'est un SPOF ! Si ce serveur tombe, on n'a plus de sessions. Alors on pourrait implémenter un 2ème serveur avec Heartbeat, mais ce 2ème serveur n'aurait pas les données, en cas de crash on déconnecte alors tout le monde. Sharedance reste pour l'instant la meilleur solution, même si je ne l'ai pas encore testée, ça ne saurait tardé. Il manquerait une réplication type DRBD sur une partition tmpfs, pour allier performance et failover.

mcache

http://www.mohawksoft.org/?q=node/8

mcache semble le produit idéal, sur le papier. Il stock les données en ram et les copie (si besoin) sur disque régulièrement, possède un garbage collector pour supprimer les sessions périmées, et fonctionne en environnement distribué: un mcache par serveur PHP. Il faut que je le mette en place avec plusieurs noeuds, et vérifier les points suivants : si un noeud tombe, que se passe t'il ? Il faut aussi valider les performances.

Je vais donc créer plusieurs images Xen 32bits afin de tester mcache, et en parallèle tester sharedance. La suite aux prochains billets !