Problématique

Les grandes marques sont de plus en plus présentes sur Internet par l’entremise de leurs sites web marchands. Ces marques sont capables de générer des trafics colossaux sur une journée, tout particulièrement pendant des périodes particulières comme les soldes.

De plus, les grands rendez vous sont souvent les mêmes pour les sites de E-commerce ce qui fait que tous consomment beaucoup de ressources en même temps.

Les trois grands types de ressources consommées pendant ces pics de charge sont les suivants : réseau (bande passante), processeur, RAM.

Que faire lors de ces soldes, lors de ces pics et surtout pour ces grandes marques ?

Passer de 100 000 Visiteurs uniques par jour à 500 000 relève du possible pour ces grands compte. En contrepartie, passer de 3 serveurs frontaux à 15, juste pour des pics temporaires, semble couteux et peu pertinent dans le long terme, sans compter le gachis de ressources.

Le Cloud (computing)

Le cloud computing est une solution technique qui permet l’usage de ressources de type CPU / RAM, Bande passante “au compteur”. Vous payez ce que vous consommer. Il y a un coût rémanent pour l’hébergement de fichiers sur le Cloud mais il est très réduit.

Cette solution de payement à la ressource réellement consommée est donc un moyen très adapté de ne mettre en place des ressources que quand cela est nécessaire et de ne facturer que ce qui est consommer.

Plusieurs Cloud existent, Amazon S3, Rackspace etc…

Du simple C.D.N à l’infrastructure

Le C.D.N veut dire Content Distribution Network. En résumé, les données statiques, images, films, css, html simple peuvent vous être fournit depuis un lieu proche de vous plutôt que depuis l’autre coté de l’océan. Ceci améliore la rapidité de chargement mais également déleste les serveurs centraux en les allégeant du travail “idiot” de distribution de fichiers.

La première utilisation des Clouds a été ce CDN, les pionniers du décentralisé étant par exemple Akamaï. Mais de nos jours, les ténors comme Amazon ou Google ont rationalisé des infrastructures beaucoup plus vastes et complexes que ce qui avait été conçu jusque là. Ils ont mis en place des systèmes spécifiques, allant parfois même jusqu’à faire développer leur propre hardware.

Une fois la puissance rationalisée et déployable à loisir, il est devenu simple pour ces ténors de “revendre” leur capacité d’accueil. Nous sommes alors passé du simple CDN à de la capacité d’accueil réelle avec, notamment, l’ajout de systèmes de base de donnée.

E.T.C (*) : Extend to Cloud, le cloud pour Magento

Chez NBS System, on a dû très tôt trouver des solutions à ce problème. Les grands comptes étant de plus en plus nombreux à basculer sous Magento et il était indispensable de proposer une solution rationnelle pour les accueillir.

Les éléments étant réunis, le projet E.T.C : Extend To Cloud était lancé. Une discussion avec Yoav Kutner, pas mal de test et de R&D et voici E.T.C.

Le concept est, dans le principe, simple. Au moment où un site monte en volume de trafic, on instancie des parcelles du cloud pour accueillir une partie du trafic qui “déborde” de la capacité d’accueil physique, réelle. Si l’infrastructure physique permet d’accueillir 100 000 Visiteurs uniques par jour, l’E.T.C permet de multiplier par 4 à 5 cette capacité d’accueil.

Une fois les tests menés et les systèmes de déploiement / rétractation au point, il devient possible d’automatiser également la mise en place d’une extension vers
le Cloud (ETC) quand cela est nécessaire.

Conclusion

Évidemment, présenté comme cela, E.T.C c’est assez simple.

En pratique il existe pas mal de contraintes et de tests à mener. Les outils pour être complètement “élastique” sont assez technique à réaliser. Pour être francs, la R&D est “un peu” coriace mais le résultat est à la hauteur du boulot fournit !

Une capacité unique d’accueil, sans multiplier les serveurs à l’infini, mais qui peut, de manière élastique, s’auto dimensionner pour répondre à des très fortes charges temporaires. Bien évidemment il y a un coût de setup assez minime et ensuite subsiste uniquement un coût d’usage qui est très très nettement plus intéressant que le fait de multiplier les serveurs

L’offre est disponible dès ce mois de décembre  2009.

(*) E.T.C (Extend To Cloud) est une marque et une technologie NBS System.

écrit par Philippe Humeau

Introduction

Cet article est le premier d’une série de 3 sur la configuration d’un infrastructure Magento complète, comprenant pour l’exemple un serveur qui sera Firewall/Reverse proxy/Load Balancer, deux autres qui seront des Serveur Web frontaux et un quatrième qui sera en charge de la base de données.

Plan des posts

1/3 : Configuration du firewall, du load balancer et du Rproxy
2/3 : Configuration des serveurs Web (APC / Apache / PHP)
3/3 : Configuration de la base de données (Mysql)

Le setup de l’infrastructure Magento

Internet, routeurs et hop, on tombe sur quoi ?

Le Firewall, reverse proxy, load balancer.

Le premier élément réellement intelligent et puissant sur lequel on va pouvoir travailler, le premier serveur quoi. Parfois l’élément Firewall est séparé et repose sur une appliance en amont mais dans le principe, si vous faites dans le full opensource, vous aimez netfilter et donc le firewall de Linux.

C’est par ailleurs un excellent Firewall, je vais donc l’intégrer à ce petit tuto et même démarrer par là !

Pour cet exemple et le paramétrage des fichiers de configuration, le firewall/RP/LB est en 192.168.1.1, les serveurs Web sont en 192.168.1.2 et .3 et la DB est en 192.168.1.4 et le magasin “virtuel” s’appel www.demostore.fr.

Enfin, cote ip publique, j’ai utilisé 33.44.55.66 comme étant celle de demostore.fr et 88.77.111.222 comme étant celle des admins. Vous trouverez ces paramètres dans les fichiers de configuration du firewall, du reverse proxy et du load balancer, il faudra les modifier pour vos besoins.

Points non couverts dans ces 3 articles

Je vais me la jouer un peu à la Ruquier, donc ce soir, on ne recevra pas, euh pardon, dans cette série de 3 articles, on ne verra pas :

• Comment faire de la redondance mutli datacenter avec BGP et les synchros de sites & de DB
• Comment séparer les flux de bases de données en écriture & lecture sur deux DB
• Comment faire du Master/Master Master/Slave ou du Cluster en Mysql
• Comment isoler le backoffice en terme de performances sur les serveurs frontaux
• Comment isoler le backoffice en terme d’accès aux bases de données

On ne verra pas tout cela car :
D’une part parce que cela serait très long et très complexe à expliquer et que les compétences nécessaires pour faire le tour du sujet sont très vastes. D’autre part parce que ca va déjà faire un bon volume à rédiger et donc que ca va prendre du temps. Et enfin parce que ces points sont très critiques sur le terrain commercial et qu’ils sont actuellement des avantages en faveur de ma société vis à vis de ses concurrents.

Vu que la concurrence dans le milieu de l’infogérance Magento est assez active, ma société NBS System ne peux pas se permettre de révéler ses tous derniers tricks ou ses toutes dernières optimisations pour l’infogérance ou l’hébergemnt de Magento, mais ce qui sera décrit dans les 5 articles correspond à ce que nous utilisions fin décembre 2008, donc des configurations tout à fait décentes et efficaces.

En plus mes collègues bossent en ce moment même avec Zend pour faire un papier très complet sur les performances et l’optimisation avec ZAS (Zend Application Server), je ne vais donc pas dévoiler de secrets avant la publication officielle au Bargento 2.

Préambule sur GRSEC/PAX

Autre point, c’est peu décrit dans cet article mais plus dans un autre dont je donne le lien et aussi sur le net : GRSEC + PAX c’est l’assurance vie de vos serveurs. Ce n’est pas une option : c’est un pré-requis. Grsec/Pax impose de recompiler le kernel, tache un peu complexe quand on a pas l’habitude mais le couple vous protège à 99,999% contre tous les overflow, les off by one et autres cochonneries de ce genre. Que ce soit apache, mysql, php, squid, memcached, apc etc… tous ces applicatifs peuvent avoir un jour une faille de sécurité. Grsec c’est l’assurance que même si ca se produit (et ca se produira), vos serveurs ne seront pas compromis.

Le Firewall

Configuration simple

J’ai réalisé, il y a (très) longtemps de cela, un petit tutoriel pour prendre Iptables & Netfilter en main. Il est incomplet, très vieux, contient des erreurs ou des abbérations que je n’ai pas eu le temps de corriger dans les scripts mais les explications et schémas sont corrects. Vous remarquerez au passage ma maîtrise considérable dans la création de page Web, celle-ci à faillit avoir de nombreuses récompenses pour l’utilisation audacieuse des CSS, mais finalement le jury a préféré un autre site (curieusement).

Ceci étant, ce que l’on souhaite faire ici est assez simple :
- Interdire tout par défaut (comme tout firewall décent)
- Authoriser spécifiquement les connexions d’administration depuis nos IP
- Permettre d’accéder directement aux serveurs derrière également depuis nos IP

Attention, il existe de très nombreux tricks à mettre en place pour avoir le top du top, dans le /proc/sys/net/ipv4, afin d’ajouter des règles anti DOS, d’ajuster la stack IP pour la gestion des connexions demi ouvertes, gérer la réduction des timeouts, et puis aussi par des règles pour loger les attaques, ajouter des systèmes de sondes/IDS etc…

C’est un firewall assez basique que je vais exposer ici. Pour de très fortes charges, il faudra également vérifier les capacités de NAT de la machine qui repose sur un système de buckets, lui même calculé en fonction de la RAM de la machine. Il faudra également redonder la machine, etc… (Mais avant que vous en soyez là, vous pourrez largement vous payer les services de personnes qui voient très bien de quoi je parles)

Préparation du Kernel :

1. On télécharge les patchs de GRSEC ici, ici (et en option le patch pour iptables ici)
2. On télécharge le kernel qui va avec la version de grsec ici
3. On détar/dézip les archives et on applique les patchs (bzip2 -d kernel*; tar xvf grsec*;patch -p0 < gr*.patch)
4. On ajoute deux ou trois tools qui risque de manquer : install libncurses-dev ncurses-dev make gcc paxtest gradm2 chpax
5. On configure le kernel (make menuconfig), voici l’ultra minimum :
   - Pas de support des modules, tout en statique (ca évite l’insertion de backdoor)
   - networking/networking options/netfilter/ip:netfilter configuration/activer la majorité des options
   - Security options / Grsec: activez tout sauf dans kernel auditing juste les relocations et forks, dans Pax mettez tout.

C’est une config ultra minimaliste. Pour plus d’info de nombreux sites parle de la compilation du noyau, le howto iptables est un peu plus précis aussi mais c’est trop long à expliquer pour avoir une place ici. Après, de nombreuses petites ou grands optimisations peuvent être effectuées au niveau du noyau, les résultats, du coté performances, comme du coté sécurité s’en ressentiront. Disons que si vous avez correctement configuré votre kernel avec pax et grsec, normalement les autres options par défaut sont rarement débiles.

Pour le firewall à proprement parler, on va faire simple dans un premier temps :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

#!/bin/bash
# short, simple, incomplete, not really commented iptables script for Debianed firewalls/rproxy/load balancers by Philippe Humeau (c) 2009 NBS System, lord Rusty forgive me, amen
 
IPTABLES="/sbin/iptables" 
 
case "$1" in
start) 
 
date=`date +'%b %d %k:%M:%S'`
ADMIN_IP="88.77.111.222" # <-------------- Change me !
SERVERS_IP="192.168.1.0/24"
SERVERS_WEB1="192.168.1.2"
SERVERS_WEB2="192.168.1.3"
SERVERS_DB="192.168.1.4"
INET="eth0"
SERVERS="eth1"
 
echo "$date -- Starting Firewall --" >> /var/log/kern.log
 
echo -e "-> \033[40m\033[1;31mSetting Default Policies to DROP \033[0m <-"
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP 
 
echo -e "-> \033[40m\033[1;33mFlushing all rules & tables \033[0m <-"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
$IPTABLES -t nat -Z
$IPTABLES -t nat -X
$IPTABLES -N LOG_DROP
$IPTABLES -A LOG_DROP -m limit --limit 6/h --limit-burst 1 -j LOG --log-tcp-options --log-prefix 'Dropped: '
$IPTABLES -A LOG_DROP -j DROP
$IPTABLES -N syn-flood
$IPTABLES -A syn-flood -m limit --limit 10/s --limit-burst 10 -j RETURN
$IPTABLES -A syn-flood -j DROP 
 
echo -e "-> \033[40m\033[1;34m Set kernel networking tweaks \033[0m <-"
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 16384 > /proc/sys/net/ipv4/ip_conntrack_max
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 2400 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 > /proc/sys/kernel/printk
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 64 > /proc/sys/net/ipv4/ip_default_ttl
echo 2048 > /proc/sys/net/ipv4/ip_queue_maxlen
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/tcp_ecn
 
echo -e "-> \033[40m\033[1;33m INPUT RULING \033[0m <-"
$IPTABLES -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i $INET -s $ADMIN_IP -j ACCEPT
$IPTABLES -A INPUT -i $SERVERS -p tcp --dport 11211 -j ACCEPT # memcached
$IPTABLES -A INPUT -i $SERVERS -s $SERVERS_IP -j ACCEPT        # accept très (trop) générique pour les requêtes des serveurs au rp/lb/fw
$IPTABLES -A INPUT -p ICMP -i SERVERS -s $SERVERS_IP -j ACCEPT
$IPTABLES -A INPUT -p ICMP -i lo -j ACCEPT
$IPTABLES -A INPUT -i $INET -s $SERVERS_IP -m limit --limit 3/m -j LOG_DROP # "Spoofed packet: "
$IPTABLES -A INPUT -f -m limit --limit 3/m --limit-burst 1 -j LOG_DROP # "Frag packet: "
$IPTABLES -A INPUT -i $INET -p icmp -m limit --limit 12/hour --limit-burst 1 -j LOG --log-prefix "ICMP: "
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/m --limit-burst 2 -j LOG_DROP # "SSH loggin attempt"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth XMAS scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -m limit --limit 3/m --limit-burst 5 -j LOG_DROP --log-prefix "Stealth XMAS-PSH scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth XMAS-ALL scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth FIN scan"
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth SYN/RST scan"
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth SYN/FIN scan(?)"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth Null scan"
$IPTABLES -A INPUT -p tcp --dport 0 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "Port 0 OS fingerprint"
$IPTABLES -A INPUT -p udp --dport 0 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "UDP port 0 OS fingerprint"
$IPTABLES -A INPUT -p tcp --sport 0 -m limit --limit 6/h --limit-burst 5 -j LOG_DROP # "TCP source port 0"
$IPTABLES -A INPUT -p udp --sport 0 -m limit --limit 6/h --limit-burst 5 -j LOG_DRop # "UDP source port 0"
$IPTABLES -A INPUT -p tcp -m multiport --sports 20,21,22,23,80,110,143,443,993,995 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "Napta/smurfing/Drd/Dos"
$IPTABLES -A INPUT -i $INET -p tcp ! --syn -m state --state NEW -j DROP # "drop TCP connexion wich doesn't start by a syn"
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -i $INET -p tcp --syn -j syn-flood 
 
echo -e "-> \033[40m\033[1;32m FORWARD RULING \033[0m <-"
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INET -o $SERVERS --dport 80 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $INET -o $SERVERS --dport 443 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 20 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 21 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 22 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 25 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 80 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 443 -p tcp -m state --state NEW -j ACCEPT 
 
echo -e "-> \033[40m\033[1;32m OUTPUT RULING \033[0m <-"
$IPTABLES -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -p ICMP -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 20 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 21 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 80 -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 443 -j ACCEPT
 
echo -e "-> \033[40m\033[1;33m Masquerading \033[0m <-"
$IPTABLES -t nat -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
$IPTABLES -t nat -A POSTROUTING -i -o $INET -j MASQUERADE
 
echo -e "-> \033[40m\033[1;32m Firewall Setup complete, activating Forward \033[0m <-"
echo 1 > /proc/sys/net/ipv4/ip_forward 
 
echo -e "------------------------> \033[40m\033[1;32mEOF : End of Firewall \033[0m<-----------------------"
;; 
 
stop)
echo -e "\033[40m\033[1;31m----------------------> Shutting down Firewall ! <----------------------\033[0m"
echo " "
IPTABLES="/sbin/iptables"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
$IPTABLES -t nat -Z
$IPTABLES -t nat -X
echo 0 > /proc/sys/net/ipv4/ip_forward
echo "-> DONE ! <-"
;;
 
*)
echo "Usage: /etc/init.d/firewall {start|stop}"
exit 1
;;
 
esac
exit 0

Quelques points :
- N’oubliez pas de durcir tous vos noyaux de serveurs, tout spécialement celui-ci, avec le patch GRSEC pour le kernel Linux. (ca doit aussi être décrit dans le howto de mémoire).

- Si on veut être plus méchant, au lieu de DROP on peut utiliser TARPIT si on a compilé iptables avec, ca fait un bel effet sur la machine attaquante !

- Si le scipt ne charge pas c’est que j’ai fais un faute de frappe quelque part, corrigez là Si il ne charge pas parcequ’il manque des target, ajoutez les dans le noyau au moment de sa compilation.

Le Reverse Proxy

Introduction

Le Firewall est une fonction en soit est très peu consommatrice car, sur un noyau linux, c’est embarqué. Netfilter et son application de pilotage iptables sont des outils très puissants et très économes.

Dans le cas qui nous préoccupe, c’est d’autant plus vrai qu’on va filtrer très peu de chose, ce n’est pas non plus le firewall du pentagone, on va juste protéger les accès d’administration. Sur notre beau serveur, on a dépensé 0,000001% de la capacité CPU, que faire du reste ?

Hummmmm du folding@home, du calcul de Pi, un serveur Quake 3, du Seti project : non !

On va faire un reverse proxy et un load balancer qui eux peuvent commencer à occuper un peu la machine sur ses 99,999999 % de temps CPU restant.

Le reverse proxy, c’est une histoire un peu plus complexe. Si on part sur une solution simple, Squid est très capable. Pour de la dentelle, qui nécessite aussi une optimisation du code pour en tirer le plein partit, Varnish est une solution plus costaud mais réellement plus longue à mettre en place. On va donc ici s’atteler à concevoir un Squid correcte.

Rôle

Le rôle du reverse proxy c’est ca :

Réduire les accès aux serveurs Web en les allégeants de tout ce qui n’a pas de valeur ajouté, tout ce qui n’est pas généré. J’ai pris volontairement une page très lourde pour la démonstration.

En l’occurence on va cacher :

• Le HTML
• Les CSS
• Les images
• Les fichiers Javascript

et forcément, le serveur Web, ca lui fait du bien. En résumé, il se concentre sur les requêtes Ajax et le PHP, il laisse les transferts “de base” au Rproxy. Evidemment, un tour de magie de ce type, ca consomme un maximum en RAM car il faut tout stocker en RAM pour aller vite. Si on doit charger chaque éléments depuis le disque dur, c’est plutôt lent. Un bon reverse proxy a donc beaucoup de RAM et un processeur correct, sans plus puisque la charge processeur est faible.

Au final, même si l’exemple ici, un peu exagéré, montre un gain de 97%, on gagne quand même en général au minimum 75% de trafic en moins vers le ou les serveurs Web. Donc qu’on ait un serveur Web ou plusieurs, le reverse proxy est in-dis-pen-sable.

Une autre optimisation intelligente sur ce point est à faire au niveau du code. Un fichier JS, un fichier CSS et pas des millions, ca change des choses. Du coup, concaténer tout cela intelligemment, c’est un plus non négligeable. Un gars s’est pris la tête à faire le boulot pour vous et encore mieux, il en a fait un plugin Magento, que demande le peuple ? Au fait ca s’appel Fooman speedster module et, depuis l’invention de la fénéantise, c’est un des outils les plus indispensable pour optimiser sans se fatiguer.

Installation de Squid

Vous êtes des gens biens, vous avez une Debian.

Vous pouvez aussi être des gens bien et ne pas avoir de Debian mais dans ce cas vous savez installer une tarball ou un package. Il y a même des gens bien qui travaillent avec OpenBSD par exemple, ils ont toute ma considération mais je ne ferai pas de howto pour (Il n’y a plus de gens bien sous HPUX rassurez moi ?)

Le coté “à la main”, je sais faire aussi mais, personnellement, j’adore APT et DPKG

Attention, on se concentre, installer Squid ce n’est pas simple sous debian :

~> su (on passe root car on est jamais loggé en root par défaut)
~> apt-get install squid

Ok on respire, on a fait le plus dur. Un petit café pour se récompenser s’impose, bravo, vous avez bien bossé ! (merci aux gars de Gnu aussi). Ca c’est fait, Squid est installé, on souffle, on respire, c’était dur mais la vie est dure parfois.

Configuration de squid en reverse proxy Magento

Phase 2, on essaye de faire croire aux patrons qu’on est payé à faire quelque chose de balaise et incompréhensible, qui mérite probablement une augmentation énorme mais qu’on va se contenter de 10% et une voiture de fonction : on édite le fichier de configuration.

Bon Squid c’est un proxy et un reverse proxy. En gros ca permet dans un cas comme dans l’autre de gérer un cache pour que les fichiers régulièrement demandés soient dans un cache rapide, mémoire de préférence, plutot que redemandés voir ré interprétés par le serveurs Web. Ca allège énormément les serveurs dans le cas du reverse proxy. Le proxy cache les réponses des serveurs Web aux browsers http pour les acheminer au client sans les redemander. Le reverse proxy lui fait l’inverse (d’où le reverse), il stocke les réponses les plus souvent envoyées par le serveurs aux clients afin de servir ceux-ci sans demander quoique ce soit aux serveurs Web.

Bref Squid c’est complexe, énorme, un fichier de conf de base ca fait dans les 7000 lignes avec les commentaires, je vous livre donc ici une version expurgée des commentaires, juste préparer pour du reverse proxy et dont toutes les fonctions ne sont pas activées, juste les principales. Encore une précision, quand vous utilisez un reverse proxy, n’oubliez pas que votre serveur Web ne verra plus toutes les requêtes… Eh oui, c’est bien le but d’ailleurs. Donc ce qui est intercepté doit être minutieusement loggé pour pouvoir avoir des stats et compléter celles des serveurs Web sous Apache.

Allez, voici la configuration :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

# Squid sooooo basic configuration for Magento, by Philippe Humeau & Adrien Urban (c) 2009 NBS System
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 443		# https
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
icp_access deny all
htcp_access deny all
 
http_port 192.168.1.1:80 transparent name=proxy_int_IP
http_port 33.44.55.66:80 transparent name=ip_demostore
hierarchy_stoplist cgi-bin ?
 
cache_mem 6144 MB
maximum_object_size_in_memory 8 MB
memory_replacement_policy heap lfuda
cache_dir null /tmp
 
 
access_log /var/log/squid3/access.log squid
access_log /var/log/squid3/access-apache.log combined
refresh_pattern (cgi-bin|\?)	0	0%	0
refresh_pattern .		0	20%	4320
icp_port 3130
 
acl localhost src 127.0.0.1/8
acl localnet src 192.168.1.0/24
 
acl debianUpdate dstdomain ftp.fr.debian.org              # pour les updates Debian
acl debianUpdate dstdomain security.debian.org          # pour les updates Debian
acl dstOutAllowed dstdomain ws.mperf.com                # pour le mailing, remplacer mailperf par votre fournisseur
acl dstOutAllowed dstdomain chart.apis.google.com      # pour les beaux graphs à la google style
acl dstOutAllowed dstdomain www.magentocommerce.com     # devinez
acl dstOutAllowed dstdomain connect.magentocommerce.com # devinez v2.0
acl dstOutAllowed dstdomain pear.php.net                           # devinez v3.0
acl dstOutAllowed dstdomain schemas.xmlsoap.org                # pour les wsdl, soaperie et autres webservices
 
http_access allow localnet debianUpdate
http_access allow localnet dstOutAllowed
 
acl IpInternal myportname proxy_int_IP
acl IpExternal myportname ip_demostore
acl dstdemostore dstdomain www.demostore.fr
acl dstdemostore dstdomain demostore.fr
never_direct allow dstdemostore
 
# demostore
cache_peer 192.168.1.2 parent 80 0 no-query round-robin sourcehash
cache_peer 192.168.1.3 parent 80 0 no-query round-robin sourcehash
cache_peer_access 192.168.1.2 allow dstdemostore
cache_peer_access 192.168.1.3 allow dstdemostore
 
cache_peer_access 192.168.1.2 deny all
cache_peer_access 192.168.1.3 deny all
 
http_access allow dstdemostore
 
http_access deny all
 
access_log /var/log/squid3/demostore-squid.log squid demostore
access_log /var/log/squid3/demostore-apache.log combined demostore

Dans cet exemple, votre serveur dispose de 8 Go de Ram et on en prend 6 pour le cache de squid. C’est évidemment à ajuster en fonction de votre configuration. (cache_mem 6144 MB) On a aussi une taille maximal de fichier à 8 Mo pour cacher les gros objets et on interdit le cache sur disque pour ne pas gréver les performances. On a paramétré le service Squid pour gérer www.demostore.fr et demostore.fr et donné l’accès aux serveurs vers d’autres hosts comme Magento connect ou les updates de Debian.

Le load balancer

Bonne nouvelle : c’est déjà fait !

Eh oui en donnant deux peers vous avez dit à Squid qu’il avait deux serveurs Web dont il devait s’occuper. Vous pourriez vouloir donner un poids différent (ici dans l’exemple c’est du 50/50) si vous avez des serveurs de puissance différentes. Il faudra alors ajouter Weight comme directive dans la déclaration des peers.

Le piège serait de faire du load balancing IP. Netfilter sait le faire, c’est même assez simple à mettre en oeuvre et pour tout vous dire c’est ce qu’on faisait à NBS System avant. Mais cela posait des problèmes quand le client arrivait d’une IP qui changeait en cour de session (gros firewall corporate qui nat par une autre connexion ou même simplement une adsl en ip variable). Du coup il vaut mieux passer par cette solution qui est plus propre.

Memcached

Introduction

Nous y voila, la fin de l’aventure Firewall / Load Balancer / Reverse Proxy est proche…

Si je finis par ce point c’est aussi parce que c’est le plus facile quelque part.

On peut mettre memcached un peu partout dans l’infrastructure, sur le proxy, sur les serveurs Web ou même sur les serveurs de base de données. L’idée c’est de garder les sessions des surfers non pas en fichiers mais en mémoire. D’un point de vue performance, c’est très préférable et c’est simple à réaliser alors pourquoi s’en passer…

Installation

On peut le mettre dans plusieurs endroit ce fameux memcached mais je préconise un serveur qui est unique et accédé / accessible par tous comme la base de données (si on a qu’un serveur de DB) ou le reverse proxy mais, si possible, pas sur les serveurs Web. En effet si l’un tombe, autant que l’autre puisse bosser et reprendre ses sessions. Evidemment, il vaut mieux que le dit serveur soit redondant ou bien costaud pour ne pas tomber sinon c’est toutes les sessions qu’on perd mais vu que le site tombera avec, ca sera un moindre problème

Oui, je sais, toujours un peu douleureuse cette phase sous Debian :
~> su (on passe root car on est plus loggé en root, normal)
~> apt-get install memcached php5-memcached

Allez, ca va aller, c’est finit… On respire lentement, le rythme cardiaque redescend !

Configuration

Dans le fichier local.xml de Magento, vous devriez pouvoir ajouter :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<global>
  <cache>
    <backend>memcached</backend>
    <memcached>
      <compression/>
      <cache_dir/>
      <hashed_directory_level/>
      <hashed_directory_umask/>
          <file_name_prefix/>
          <servers>
             <default>
              <host>192.168.1.1</host>
              <port>11211</port>
             <persistent>1</persistent>
           </default>
          </servers>
      </memcached>
  </cache>
<session_save><![CDATA[memcache]]></session_save>
<session_save_path><![CDATA[tcp://192.168.1.1:11211?persistent=1]]></session_save_path>
</global>

On peut aussi mettre memcached en dehors de Magento et de sa configuration, tout simplement en installant le démon avec une configuration dans le /etc/memcached.conf :

1
2
3
4
5
6
7

# memcached ultra simplistic config file by philippe Humeau (c) 2009 NBS System
-d
logfile /var/log/memcached.log
-m 1024
-p 11211 
-u nobody
-l 192.168.1.1

Conclusion

1. Vous méritez un café après tout ce travail
2. Je mérite un café après ce travail de rédaction
3. Il est incompréhensible que les producteurs de café soient pauvres
4. La personne qui monte un site Magento entièrement dédié au café, il va se faire du blé

Oui… Je sais… J’ai toujours un petit soucis sur les conclusions mais bon, vous commencez à être habitués depuis le temps et puis je me soigne.

Prochain exercice de style, l’article 2/3 : Configuration d’un serveur Web pour Magento !

PS : N’oubliez pas de vous inscrire pour Bargento 2, il reste encore quelques places et après on est complet, ce qui implique que même en arrivant à l’improviste sur place, on ne pourra pas vous faire rentrer pour rester dans les capacités d’accueil de la salle.

De plus, le papier sur Zend Application Server et les performances de Magento devrait apporter un jour nouveau et pas mal de complément sur ce mini tuto / howto.

Par manque de temps, je n’ai pas eu le temps de tout tester sur un serveur donc si il y a des boulettes dans les fichiers de configuration, n’hésitez pas à me les signaler, je modifierai l’article.

écrit par Philippe Humeau \\ tags: firewall, firewall magento, firewall reverse proxy load balancer, load balancer, load balancer magento, memcached magento, reverse proxy, reverse proxy magento, squid magento

Un excellent article (en anglais) : Magento SEO, écrit sur le blog Yoast et qui donne de très bons tips sur la SEO et plus généralement sur un paquet d’optimisations à passer sur la bête.

C’est beau, c’est clair et… très pertinent !

Ils nous parlent aussi du fooman speedster module qui vient de passer dans le magento connect depuis le 22/03 !

En un mot comme en 100, jetez y un oeil ca vaut le coup. Depuis le temps que je grogne sur le fait que les sites nous arrivent en hébergement sont, neuf fois sur dix, pas optimisés pour un rond… Enfin un homme bon et généreux vous propose de grouper et compresser vos CSS et vos JS !

Globalement, ce joli petit module vous permet de regrouper (presque) tous vos Javascript en un ficher, idem pour les CSS. Il y a quelques exceptions, le classique print.css par exemple, mais sinon, sincèrement, s’en passer c’est se tirer dans le pied !

écrit par Philippe Humeau \\ tags: fooman, SEO, speedster

Avant toute chose, le Wiki a été mis à jour sur la partie dimensionnement des infrastructures Web. Ca se passe ici, si vous voyez des erreurs, n’hésitez pas à corriger.

Alors, où en est-on sur le front des performances ?

Eh bien si vous avez mis en place les optimisations qui sont recommandées, celles que l’ont vous a expliqué chez Fragento ou ici, celles que l’on va vous exposer dans les prochains posts, bref si vous faites les choses correctement, vous pouvez atteindre de 200 à 800 sessions “Magento connectées” par core (coeur) de vos processeurs récents.

Mais avant de parler des optimisations en elles mêmes, il faut avoir des moyens de comparer, des unités et des repères communs. Je vous propose d’adopter des “S.M.C” comme unité.

S.M.C ?

En premier lieu “Sessions Magento Connectées”, qu’est-ce que cela peut bien représenter… ?

Déjà, on va réduire le nom à SMC pour éviter de trimbaler 5 lignes. On peut prendre de nombreux points de repères différents pour estimer la charge : les sessions apache, les Visiteurs Uniques (V.U) journaliers, horaires, le nombre de page vues, etc… Alors pourquoi choisir les SMC ?

Les SMC cela reste un indicateur pertinent car c’est Magento qui mesure cette valeur. Elle peut donc être utilisées dans d’autres contexte, pour faire d’autres calculs mais surtout elle est mesurée partout de la même façon, ce qui est important pour avoir des repères. Comme c’est Magento qui la mesure, on travail tous sur la même valeur.

Comment les récupérer ? Avec une requête SQL en base de données tout simplement :
select count(*) from log_visitor where ADDTIME(utc_timestamp(), -1500) < last_visit_at;

Cela nous donne les sessions ayant eu une activité lors des 15 dernières minutes. C’est très proche de ce que l’on a dans le backoffice. Une dataquery et un script bash plus tard,

On en fait un beau graphique pour les clients dans Cacti ou avec RRD, MRTG etc… :

Là, par exemple, on voit un mailing. Monté en charge progressive du nombre de SMC pour atteindre les 1200 vers 18H00. Ca se corrèle bien avec le graphique d’utilisation des cores :

On 4 cores utilisés pour 1200, donc 300 utilisateurs par core, en l’occurence ce sont des AMD Shanghai 2374 à 2,3 Ghz. Comme ce sont des quad cores, on utilise un processeur complet. Évidemment on ne peut pas se permettre d’avoir tous les cores à 100% donc les autres processus Linux tournent sur un autre core dédié d’un autre processeur. Coté base de données, ca glandouille gentillement :

Il faut lire 0,2 core (200 milli). Ceci étant ce site spécifique sollicite peu la base de données donc ce n'est pas représentatif non plus.

Tester les performances, tests de charge & Benchmark !

De nombreux outils existent, qui mesurent différentes choses. En test de charge purs, on a par exemple Load runner, Apache bench, Opensta etc… Coupler tout cela à des analyseurs de code ou de requêtes SQL (comme la console Mysql enterprise par exemple) permet d’optimiser le code mais ce n’est pas le sujet de ce post et Gilles nous fera peut être un petit article là dessus.

Non, ce qui nous intéresse ici, c’est d’évaluer le nombre de SMC que l’on peut servir dans de bonnes conditions avec la plateforme que l’on aura préparé. Pour cela, load runner et Opensta sont de bons outils. Apache bench n’est pas très adapté sincèrement car son test est toujours le même, donc avec la chaine de cache, à la fin de ces 2000 itérations, il vous sort joyeusement 250 000 connectés

Opensta permet de définir des scénarii de tests et d’en jouer plusieurs, de front, à suivre, plusieurs fois les mêmes etc… Le soft tourne sous Windows, il est gratuit et opensource. On peut le trouver ici et même s’il n’est plus entretenu, il fonctionne bien et fait le boulot demandé.

Le but ici n’est pas de faire un manuel ou un howto d’opensta mais globalement d’expliquer ce qui représente de bonnes circonstance de tests, tout au moins réaliste. Ce que je fais, en général, c’est que je demande à mes clients, c’est de réaliser entre vingt et trente scénarii classique de surf. On enregistre un très simple de la personne qui vient sur la home et se déconnecte, un autre ou il fait une recherche un autre ou il clique de produit en produit, etc… Le plus le mieux mais également, le plus logique le mieux !

Le scénario de connexion à la home puis déconnexion, on va le jouer 25% du temps, puis celui du parcours de produit 1, le 2 et aussi les recherches. On mixe le tout savamment et on demande à plusieurs scénarii de se jouer sur le site. Trois qui surf, des connexions déconnexions sur la home, deux recherches en même temps etc… A la fin, on regarde les performances affichées par l’interface d’Opensta et celles collectées dans Cacti. On corrèle les graphs, on analyse et on arrive à estimer la charge que peux tenir un système ! En laissant tourner les scénarii un moment, le graph sera réaliste et on saura dire combien de S.M.C peut faire tenir un core standard.

La suite est un jeu d’enfant, on prend le nombre de V.U prévu en pic, on déduit le nombre de S.M.C que l’on doit pouvoir encaisser et on divise par la performance unitaire d’un Core. On sait alors combien de core on doit mettre en place et donc combien de processeurs !

Bon si une bonne âme veut bien écrire un tuto/howto sur Opensta, je passe mon tour pour le moment et je vous laisse juste en compagnie de deux shoots d’écran, le modeler et le commander :

On définit son scénario dans le modeler ci-dessous, on planifie dans le commander ci-dessus, et on a un autre module qui collecte et affiche les statistiques.

Et voila !

écrit par Philippe Humeau \\ tags: benchmark, performance, sessions magento, test

Ce qui est intéressant quand on fait des tutoriels c’est qu’on s’aperçoit que l’on a soit même mal appliqué les astuces que l’on va énoncer.

Je voulais vous faire un petit tutorial sur comment optimiser un peu les pages en elles-mêmes, et finalement on va commencer par quelque chose de plus basique la compression des pages.

La première étape que je vous propose, c’est de télécharger pour ceux qui ne le connaissent pas encore un plugin pour firefox nommé Yslow qui nous donne de nombreuses informations sur l’optimisation de votre site. Ce plugin développé par Yahoo fait parti d’un ensemble de bonnes pratiques pour optimiser le temps de chargement de vos pages. Vous pouvez en retrouver la liste (en anglais) ici : http://developer.yahoo.com/performance/rules.html#cdn

Et en complément quelques idées supplémentaires sur leur blog de développement:
http://developer.yahoo.net/blog/archives/2008/03/yahoos_latest_p.html

Le premier onglet de ce plugin « Performance » nous donne des indications sur le respect de votre site de ces bonnes pratiques. Chaque élément est noté entre A et F et nous donne une idée des points que l’on a pu oublier, comme par exemple activer la compression gzip sur le serveur (bien que la note totale -souvent F- ne présente pas beaucoup d’intérêt car certaines règles sont difficiles à mettre en pratique).

On observe d’ailleurs que Magento respecte naturellement nombres de ces règles (une bien connue maintenant étant la minification des js).

Ce qui nous amène au deuxième onglet, l’onglet « Stats », celui-ci permet d’obtenir le poids total de votre page, ainsi que la répartition du poids entre les différents éléments (images, css, flash, html) ainsi que le poids de votre page une fois que les éléments ont été chargé une première fois et sont dans le cache du navigateur.

On voit ainsi dans cet exemple la différence de poids que l’on peut avoir entre une page d’accueil avec ou sans la compression gzip. Je pense que je n’ai pas besoin de vous expliquer l’intérêt d’économiser 200Ko de trafic pour chaque internaute qui chargera votre page d’accueil.

Enfin l’onglet « Components » nous permet d’avoir le détail pour chaque élément son poids (avant et après compression gzip), comme l’onglet Net (Réseau en français) du plugin Firebug, on peut voir en rouge les éléments qui n’ont pas été chargés ainsi que le temps de chargement de chaque élément. Cet onglet est intéressant puisqu’on peut classer les éléments par poids. On peut ainsi s’apercevoir qu’on a des images qui mériteraient une compression jpg plus forte, ou qu’un flash mériterait d’être optimisé (voir déplacé ou remplacé par quelque chose de plus léger si par exemple il est sur une la page d’accueil d’un site à fort trafic).

J’arrive à mon deuxième point, la compression gzip. En complément du plugin Yslow ce lien http://www.whatsmyip.org/mod_gzip_test/ permet de vérifier immédiatement que la compression est bien activée pour une url donnée.

Pour activer la compression gzip cela suppose que le module apache adéquat soit chargé (mod_gzip qui se nomme maintenant mod_deflate), je vous laisse vous tourner vers votre hébergeur ou google pour vérifier que ce module est chargé.

Ensuite quand le module est chargé, il faut également que les règles apache correspondantes aient été chargées, chose qui n’aura pas toujours été faite quand on vous livre un serveur. On a alors toutes les règles nécessaires dans le fichier .htaccess de notre bon vieux magento qu’il suffit de décommenter :

############################################
## enable resulting html compression

php_flag zlib.output_compression on

############################################
## enable apache served files compression
## http://developer.yahoo.com/performance/rules.html#gzip

# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems…
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don’t compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don’t deliver the wrong content
Header append Vary User-Agent env=!dont-vary

(On peut évidemment appliquer directement ces règles dans le httpd.conf d’apache quand on sait ce que l’on fait).

écrit par Olivier \\ tags: compression, gzip, yslow

La performance d’un site est vitale pour ses ventes ou sa consultation, deux géants célèbres ont fait des études sur ce point : Google et Amazon. Le premier a déterminer que si sa latence augmentait de 0,5s, il perdait 20% de son trafic et le second a déterminer qu’en répondant en 100 ms de plus, il perdait 1% de CA !

Il est très complexe de dimensionner les serveurs nécessaires et ajuster les paramètres systèmes afin d’être sûr d’obtenir une navigation agréable pour un grand nombre d’utilisateurs. L’empirisme commence à bien fonctionner avec le recul de plusieurs sites hébergés mais je pense qu’on peut faire mieux et commencer à structurer des calculs plus scientifiques. Lire la suite »

écrit par Philippe Humeau \\ tags: calcul de charge, dimensionnement