Construire son infrastructure Magento, partie 1/3 : firewall / RProxy / load balancer

Philippe Humeau — Fri, 22 May 2009 12:55:35 +0000

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 :

On télécharge les patchs de GRSEC ici, ici (et en option le patch pour iptables ici)
On télécharge le kernel qui va avec la version de grsec ici
On détar/dézip les archives et on applique les patchs (bzip2 -d kernel*; tar xvf grsec*;patch -p0 < gr*.patch)
On ajoute deux ou trois tools qui risque de manquer : install libncurses-dev ncurses-dev make gcc paxtest gradm2 chpax
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 :

^?View Code BASH

#!/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 --" &gt;&gt; /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 &gt; /proc/sys/net/ipv4/ip_forward
echo 1 &gt; /proc/sys/net/ipv4/ip_dynaddr
echo 0 &gt; /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 &gt; /proc/sys/net/ipv4/tcp_timestamps
echo 1 &gt; /proc/sys/net/ipv4/tcp_syncookies
echo 0 &gt; /proc/sys/net/ipv4/conf/all/accept_redirects
echo 2 &gt; /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 &gt; /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 16384 &gt; /proc/sys/net/ipv4/ip_conntrack_max
echo 1 &gt; /proc/sys/net/ipv4/conf/all/log_martians
echo 30 &gt; /proc/sys/net/ipv4/tcp_fin_timeout
echo 2400 &gt; /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 &gt; /proc/sys/kernel/printk
echo 1800 &gt; /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 &gt; /proc/sys/net/ipv4/tcp_window_scaling
echo 0 &gt; /proc/sys/net/ipv4/tcp_sack
echo 64 &gt; /proc/sys/net/ipv4/ip_default_ttl
echo 2048 &gt; /proc/sys/net/ipv4/ip_queue_maxlen
echo 1 &gt; /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 &gt; /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 &gt; /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 &gt; /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 &gt; /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 :

^?View Code BASH

# 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 :

^?View Code XML

>
  >
    >memcached>
    >
      />
      />
      />
      />
          />
          >
             >
              >192.168.1.1>
              >11211>
             >1>
           >
          >
      >
  >
>>
>>
>

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 :

^?View Code BASH

# 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

Vous méritez un café après tout ce travail
Je mérite un café après ce travail de rédaction
Il est incompréhensible que les producteurs de café soient pauvres
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.

Partager cet article :

Communauté Magento francophone » memcached magento

Construire son infrastructure Magento, partie 1/3 : firewall / RProxy / load balancer

Introduction

Plan des posts

Le setup de l’infrastructure Magento

Points non couverts dans ces 3 articles

Préambule sur GRSEC/PAX

Le Firewall

Configuration simple

Le Reverse Proxy

Introduction

Rôle

Installation de Squid

Configuration de squid en reverse proxy Magento

Le load balancer

Memcached

Introduction

Installation

Configuration

Conclusion