Un tips rapide en anglais, parce que disponible nul part en ligne…

So you have a website behind Varnish that uses AJAX XMLHTTPRequest and by using a set of DNS redirection you are actually in a cross domain configuration ? Well, I know, it’s a pain in the ass…

For GET requests, it’s pretty easy, you have a nice solution here : https://www.varnish-cache.org/trac/ticket/541. Now if you use AJAX POST request, it a bit different, you will get a 503 Guru Meditation. In fact, by default Varnish will “pass” the request. It means that Varnish will send the request by default to the backend(s) and when will then receive the answer. The problem is that the answer will not be understood by Varnish and you will end up with a “FetchError c http format error”.

The solution wil be to change this default behavior from pass to “pipe”. In the configuration, Varnish will just stream bytes from the client to the backend back and forth directly without any manipulation. To do so, here is the configuration to put in your vcl_recv :

#matching all the AJAX XMLHTTPRequest form my site
if (req.http.host ~ "(?i)^www.site.com$" && req.http.X-Requested-With == "XMLHttpRequest" ) {
 #Rewrite the header if needed
 set req.http.host = "backends.site.com";
 #Setting the backend to forward to
 set req.backend = backends_servers;
 #Setting the pipe mode
 return(pipe);
}

Here you go ! I hope you liked it…

Presque un an d’arrêt. Et pourtant je vous assure que plein de chose on bougé d’un point de vu technique et je compte bien coucher ça sur le papier (enfin, dans ma base de données !). Ce soir c’est un peu différent, j’ai envie de vous parler d’un sujet que j’ai déjà abordé : la révolution syrienne, mais sous un autre angle.

Tout le monde connais mes positions contre le régime criminel en place en Syrie. Les rares qui se positionnent encore avec le régime sont des partisans du régime qui ont quelque chose à gagner ou à perdre ainsi que les idiots. De toute façon ce soir je vais pas trop insulter le régime, même si ça me démange… Ce soir je vais vous parler d’un truc utile, simple et efficace.

On a une infra haute dispo, mais pas encore vraiment haute perf. Pour y passer, on va utiliser Varnish qui mettra en cache les pages de notre site ! Ce n’était pas prévu au planning initial que j’ai posé une nuit très tard… Mais c’est un MUST !

Varnish sera situé entre le load balancer et les frontaux (qu’il load balancera). Sont fonctionnement est simple :

1. Je reçois une requête pour la page X
2. L’ai-je dans mon cache ?
3. Si oui je fournis == je soulage un frontal et les bases de X requêtes
4. Si non je récupère et je la cache si possible (on ne peut pas cacher les pages d’utilisateur logé par exemple)

Il est cependant vrai qu’en environnement de production, on mettra les caches devant les load balancer afin d’éviter de charger les load balancer pour rien. Leur load balancing se fera alors en Round-Robin DNS.

Vous allez voir, c’est simple et efficace ! Je vais montrer pour une des deux VM, la deuxième sera une copie conforme.

On continu d’avancer et on touche presque à la fin. A la fin de ce tuto, on aura une plateforme web fonctionnelle. Aujourd’hui nous allons mettre en place le load balancer HAPROXY qui aura pour objectif de répartir la charge entre les deux frontaux web installés mais aussi stunnel qui s’occupera de gérer la couche SSL (HAPROXY en étant dépourvu). Cette machine portera l’IP publique de notre site.

Le flux passera donc par HAProxy pour les connexions HTTP qui répartira la charge sur les frontaux web. Dans le cas du HTTPS, stunnel reçoit la connexion, la forward à HAProxy qui la forward au frontaux web.

J’entend d’ici : mais c’est un SPOF ! On se calme, l’étape 5 va nous permettre de clusteriser cette brique (et le MySQLProxy aussi ) .

Sans plus attendre, on attaque !

Poursuivons le Summer Camp qui devient plus au Autumn Camp… Après la mise en réplication de nos bases de données, on va mettre en place le slipt Read/Write sur nos bases. La base maitre servira pour l’écriture de données et la base slave pour la lecture. Il est à noter que l’on peut ajouter autant e slave que l’on veut. Il suffit de rajouter quelque ligne à la configuration de MySQLProxy. On attaque donc la dernière brique MySQL de la série !

C’est plus trop l’été mais bon… On va le faire perdurer ici ! On a donc les frontaux… sur lesquels on a monté les partages de fichiers statiques. Mon PHP est bien fonctionnel… mais j’ai pas encore de bases pour stocker ma donnée.

Contrairement à ce que j’ai annoncé, nous n’allons pas utiliser un MySQL Cluster. Ce choix est justifié par la spécificité de MySQL Cluster qui demande un développement spécifique. En effet, le moteur de base est différent et n’est que très rarement supporté par des CMS ou même des développement spécifique. à la place, je vous propose de faire un Split Read/Write via MySQL Proxy. Il s’agit donc de répartir la lecture sur plusieurs bases (répliqués entre elles) mais de faire les insertions que sur une seule. Typiquement on écrit sur un serveur et on lit sur l’autre.

On attaque donc cette partie qui nous amènera un peu plus près de la fin du projet. Aujourd’hui on va faire de la réplication MySQL.

Dans le post précédent du Summer Camp, nous avons vu comment monter les frontaux web. Aujourd’hui, nous allons voir comment mettre en place le serveur de fichier. Mais avant de commencer, pourquoi mettons nous en place des serveurs de fichiers ? Pourquoi le frontal ne porte-t-il pas la donnée directement.

La réponse est simple : un frontal est une machine “jetable”. Elle a pour but d’être déployée rapidement et simplement. Si un frontal porte 250Go de données, il sera lent à répliquer et gourmand en espace disque. Sans compter les problèmes de réplications de données entre les frontaux. Pour répondre à tout cela, nous allons mettre en place un serveur de fichier avec un partage réseau NFS qui sera monté sur les frontaux. Le système de fichier utilisé sera ZFS sous FreeBSD. En effet il offre des possibilités de réplication et de sauvegarde très interessantes, mais là n’est pas l’objet du billet, nous y reviendrons.