L’aventure Raspberry PI – épisode 5 – De la répartition des rôles

J’ai souhaité répartir les fonctions sur chacun de mes raspberry Pi pour alléger la charge sur chacun. Quelques détails sur la méthode que j’ai adoptée.

Souvent le load balancing est fait en amont en utilisant plusieurs serveurs web et un unique ou plusieurs moteurs de bases de données. Pour mon usage, j’ai préféré procéder différemment.

Les différents composants pour délivrer une appli web

Lorsque l’on veut déployer une application web, il faut avant tout un serveur web. Il est vraiment déconseillé de faire tourner un apache sur les raspberry Pi étant donné que la solution est extrêmement gourmande en ressources. Mon choix premier s’est porté sur Lighttpd. Nous verrons plus tard que je me suis rabattu a posteriori sur nginx pour des raisons de compatibilité avec etherpad.

Il sera très fréquent que notre application web ait besoin d’une base de données. Mon choix pour le serveur de bases de données a été PostgreSQL, lui aussi beaucoup plus léger que MySQL.

Enfin, la plupart des applications que je souhaite installer sont des applications php. Il nous faudra donc un moteur capable d’interpréter les pages PHP sur demande du serveur web. J’utilise php-fpm .

Au hasard de mes recherches, je n’ai pas trouvé d’autre cas où la répartition de charges se faisait en installant chacun des composants sur une machine différente. C’est pourtant ce que j’ai fait.

Le raspberry 1 est chargé de la base de donnée, le raspberry 2 est chargé du serveur web et le raspberry 3 est chargé du moteur php.

Communication entre les différents éléments

En général, lorsqu’on est sur un serveur unique on préfère l’utilisation d’un socket pour la communication entre les différents composants. Le socket utilise un fichier placé dans le système de fichiers et en général apporte de meilleure performances.

Ici, étant donné que j’ai plusieurs serveurs, il me faut configurer chacun d’eux ainsi que les clients pour écouter et interroger sur une interface réseau et un port précis.

Spécificité concernant le serveur web et le moteur php

Le serveur web quand il demande l’interprétation d’une page au moteur php lui passe notamment en paramètre le chemin vers ce fichier. Il faudra donc que notre serveur web et notre serveur où tourne le moteur php partagent la même arborescence pour la partie de l’hébergement (le  /srv/http  sous ArchLinux).

Une option, sale mais que j’ai envisagé est la réplication pure et simple de l’un vers l’autre. Mais cette solution rendait complexe l’utilisation d’un cache et aussi toute action de mise à jour des applications web.

La solution que j’ai adoptée est donc le montage de /srv/http en nfs4, comme présenté précédemment.

À noter aussi que le lien entre l’application web et la base de donnée est très haut niveau, c’est dans la configuration même de l’application web qu’on le définira, là où le lien entre le serveur web et le moteur PHP est défini dans la configuration du serveur web.

Lundi je vous présenterai la configuration et l’installation de PostgreSQL.

Merci à Framasoft pour l’outil GéGé et à Gee de prêter ses personnages.

Merci à Framasoft pour l’outil GéGé et à Gee de prêter ses personnages.

Florck

Je suis Ingénieur en Technologies de l'Information, consultant en systèmes (GNU/Linux) et bases de données (Oracle). En recherche de contrôle sur mes informations personnelles : "La route est longue mais la voie est libre !"

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *