Dernièrement avec un de mes Smart Server, j’ai pu faire un tas de tests, j’ai installé plusieurs webmail, testé le relaying de courriel via le réseau privé. J’ai aussi fait du reverse proxy et du load balancing avec lighttpd, nginx et varnish-cache. J’ai bien aimé expérimenter avec mod_security et memcached. J’ai aussi regardé les solutions pour les graphiques et monitoring via divers logiciel tels que mrtg, cacti, monit, munin et nagios. Parmi tous ces sujets intéressants, décider sur quoi j’allais blogger est devenu une lourde tâche! J’ai vraiment aimé jouer avec mod_proxy et le réseau privé relié aux Smart Server alors allons-y avec cela.
Mon scénario est très simple: j’ai un client qui de temps à autre utilise trop de ressources pour être seul sur son serveur. Vous savez ces fameux chroniqueurs politiques, ils passent aux nouvelles de 18h et pouf 18h02 une montagne de trafic, le serveur ralentis, les gens voient que le site se comporte bizarrement, ces gens deviennent des cliqueurs agressifs de piton reload croyant que ça va aider les choses.
Le setup que j’ai configuré inclut trois serveurs. Idéalement il en faudrait plus, surtout si on vise devenir redondant et à l’épreuve des pannes. Que se soit un bris de matériel, une panne réseau, une panne électrique ou simplement une mise à jour qui tourne mal le résultat est le même: Site Web = DOWN = client pas content!
Sur mon backend j’avais deux serveurs web qui pourraient facilement être hébergés n’importe où sur le web même sur Amazon EC2. Ici on utilise des Smart Server car l’objectif est de tester et d’utiliser leur réseau privé. Cela ajoute une couche de sécurité puis que web1 et web2 n’ont pas à être directement accessible sur Internet. Dans notre cas, le serveur agissant comme loadbalancing fait du ProxyPass. Ce setup fonctionne assez bien quand le client ne fait pas trop de modifications à son site, lire: upload d’images, changement de template, mises à jour!
Ce que j’ai fait c’est que j’ai isolé le /wp-admin/ afin qu’il tombe toujours sur le même serveur, le proxy dans mon cas et j’y ai ensuite configuré un petit cron avec une commande rsync pour synchroniser les fichiers aux 10 minutes. Pour le moment ce scénario me satisfait même s’il est loin d’être idéal ou parfait. Il y aurait moyen d’automatiser un synchronisme des fichiers sur l’ensemble des serveurs, mais je n’ai pas vraiment expérimenté avec des solutions telles que FAM ou DRBD.
En gros, j’ai effectué mon installation standard de wordpress sur le serveur qui fait le ProxyPass. Ensuite, j’ai configuré le site ainsi qu’installé les extensions et templates. J’ai configuré une BD SQL sur ce serveur, dans notre cas c’est aussi le proxy mais il serait idéal de l’isoler seul sur son serveur ou de l’off loader sur Amazon RDS voir même sur un DaaS comme Xeround. Dans mes configurations de wordpress, apache, mysql, et memcached je spécifie toujours les IP du réseau privé interne puisque tous mes serveurs sont chez iWeb sont des Smart Servers. Cela élimine du trafic sur le réseau public. Ça rend le setup beaucoup plus sécuritaire.
Tous les serveurs ont subi un durcissement de base dont j’ai déjà donné les grandes lignes. Ils ont iptables sur les deux interfaces réseau, ne relayent pas de trafic entre les deux interfaces réseau. Ils ont le service memcached de configuré sur le réseau privé. Il parait qu’on n’en a jamais assez de cette cache.
Sur web1 et web2, j’ai configuré les serveurs Apache pour écouter uniquement sur le réseau privé, pas de ftp de bd sql. J’ai bloqué presque tout le trafic sur le réseau public et autorisé seulement les protocoles utilisés sur le réseau privé.
Sur le serveur qui fait face à Internet, j’ai configuré mysql pour écouter uniquement sur le réseau privé. Apache et vsftpd, eux, écoutent sur le réseau public. J’ai configuré des clefs ssh afin de pouvoir synchroniser facilement mon DocumentRoot via rsync. J’ai alors laissé le temps me faire parvenir les fichiers. Quelques minutes plus tard, après le passage du cron, je me retrouve avec une belle installation de WordPress! Ajouter un web3, 4, etc. devient un jeu d’enfant.
Sur mes serveurs web1 et web2 j’ai fait une configuration similaire à celle-ci en utilisant le port 488 puisqu’il est déjà autorisé dans SeLinux.
NameVirtualHost 10.X.Y.Z1:488 <VirtualHost 10.X.Y.Z1:488> ServerAdmin webmaster@horizonlinux.org DocumentRoot /usr/local/sites/www.horizonlinux.org ServerName 10.X.Y.Z1 ErrorLog logs/www.horizonlinux.org-error_log CustomLog logs/www.horizonlinux.org-access_log combinedio </VirtualHost>
Sur le serveur proxy voici la configuration que j’ai utilisée.
<VirtualHost www.horizonlinux.org:80>
ServerAdmin webmaster@horizonlinux.org
ServerName www.horizonlinux.org
ServerAlias horizonlinux.org
DocumentRoot /usr/local/sites/www.horizonlinux.org
ErrorLog logs/www.horizonlinux.org-error_log
CustomLog logs/www.horizonlinux.org-access_log combinedio
ProxyRequests Off
ProxyPreserveHost On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /balancer-manager !
ProxyPass /wp-admin !
ProxyPass / balancer://mycluster/ stickysession=BALANCEID nofailover=On
ProxyPassReverse / http://10.X.Y.Z1:488/
ProxyPassReverse / http://10.X.Y.Z2:488/
<Proxy balancer://mycluster>
BalancerMember http://10.X.Y.Z1:488 route=hrz1
BalancerMember http://10.X.Y.Z1:488 route=hrz2
ProxySet lbmethod=byrequests
</Proxy>
<Location /balancer-manager>
SetHandler balancer-manager
Order deny,allow
Allow from all
</Location>
</VirtualHost>
