2.2 Clustering

La mise en place d'un système de clustering consiste à utiliser plusieurs machines pour servir les pages web et accéder aux services d'administration. Il est en effet primordial de pouvoir compter sur l'appui d'autres machines lorsqu'une défaillance est détectée pouvant nécessiter un arrêt prolongé.  Ainsi, d?autres machines prennent le relai.

2.1.1 Clustering de basculement

Dans cette architecture, une seule machine s'occupe de délivrer les pages. Si elle tombe en panne, une machine de secours prend immédiatement le relai. Ce schéma est plus adaptée à une banque de données avec un serveur particulièrement puissant en frontal, monoprocesseur et couteux.

2.2.2 Clustering avec répartition de charge

Cette architecture se caractérise par n serveurs chargés de répondre aux différentes requêtes. Si le clustering est matériel, le gestionnaire de charge va répartir les requêtes en fonction de règles préétablies ou algorithmes.  Ce type d'architecture est particulièrement bien adapté aux serveurs Web pour répartir la charge de façon uniforme (symétrique) ou en fonction d'un coefficient déterminé par un administrateur (asymétrique).

Round Robin est par exemple un répartiteur de charge efficace. Notez cependant que les serveurs doivent posséder les mêmes capacités de traitement. Je vous invite à consulter le site de Microsoft France sur le système de répartiteur de charges à mettre en place pour TYPO3.

2.2.3 La gestion des sessions

Les sessions peuvent éventuellement poser un problème lorsque les données sont recopiées d'un serveur à un autre. Si la base de données n'est hébergée que sur un seul serveur, il n'y a pas de problème de ce coté là et concernant TYPO3, les sessions sont activées principalement dans la partie "administration" (Backend). Dans le cas contraire, il aurait été judicieux de procéder à un transfert asynchrone des états de session pour conserver la session si l?utilisateur est redirigé vers un autre serveur pendant sa navigation.

3. Solution proposée

3.1 Justification

Système de Cluster - 2 machines en RAID 5 avec synchronisation entre les deux
+
Redondance disque

Prévoir une machine dédiée pour la base de données MySQL. La perte de performance MySQL est de l'ordre de 7.5% lorsque les données ne sont plus transmises via un socket (Unix) mais par une connexion réseau TCP/IP, ce qui est négligeable. L'avantage consiste à séparer Apache et MySQL pour réduire de part et d'autres les ressources consommées.

Typo3 fait appel à un cache chargé de recueillir les pages générée pour un affichage plus rapide. Les pages de contenu sont essentiellement situées dans la base MySQL. Il existe également un cache au niveau du serveur Apache mais celui concerne surtout des extensions, des images (thumbnails générés dynamiquement par ex) ...

Double protection

• au niveau du cluster -> si une machine tombe en panne, il faut que la seconde machine supporte la charge à elle seule un temps minimum (temps de la réparation)
• au niveau de la mise en place du RAID -> un disque dur qui tombe en panne, le serveur continue à distribuer les données depuis le second disque. De plus, cette solution s?apparente à une sauvegarde des données du disque 1 vers le disque 2 même si elle ne doit pas se substituer à une réèlle solution de backup de vos données (dans un autre batiment, sur une autre machine...

Evolutive

Il est toujours possible de rajouter une machine si la charge devient trop importante pour les deux serveurs.

 Il faudra néanmoins :

• s'assurer que l'une des deux machines puisse soutenir la charge si l'autre tombe en panne.
• procéder à un backup hebdo de la base et du système de fichiers.
• avoir les mêmes données sur le serveur en veillant à dupliquer le cache d'une machine à l'autre (/typo3temp, /fileadmin/_temp_, /fileadmin/user_upload/_temp_, /typo3conf). Il existe un cache SQL mais nous n'aurons qu'une base.
• Déterminer l'espacement des synchronisations entre les deux serveurs.
• disposer d'outils de monitoring.

Remarques sur les outils de monitoring :

Si vous recherchez un outil simple d'utilisation, vous pouvez vous tourner vers Nagios. Cet outil de monitoring réseaux vous permettra de surveiller l'état de vos services sur vos serveurs Web. Notez que Nagios stocke ses données soit dans des fichiers textes, soit dans une base de données. On peut même greffer des add-ons pour faciliter davantage la procédure de configuration et d'administration.  Oreon le fait très bien :)