Penser architecture web - Aller plus loin avec plusieurs centres de données
Par Nicolas le vendredi 8 juillet 2011, 13:33 - Hébergement - Lien permanent
Un peu dans l'esprit de l'article Penser architecture web que nous avions publié il y a 2 ans, nous allons aborder dans cet article les problématiques que nous savons récurrentes pour nos clients hébergement ainsi que dans le monde du web en général : que faire quand mon serveur web est surchargé ou mes sites web sont lents ?
1. Vérifier d'abord votre code source, puis les configurations des services
Bien entendu, avant de se lancer dans les optimisations du serveur ou plus loin dans une architecture spécifique, il convient d'identifier les problèmes inhérents aux code source.Puis il est nécessaire de vérifier si les services (serveur web, de bases de données, ...) sont bien configurés par rapport au serveur d'hébergement (ses ressources, notamment RAM et processeur).
2. Augmenter la puissance du serveur en adaptant les configurations des services
Une fois que vous avez optimisé le code source et que les configurations sont optimales, si le service manque toujours de réactivité, si le serveur ne parvient pas à honorer les requêtes de vos visiteurs (syndromes de la page blanche, de pages incomplètes ou encore expiration de la connexion), vous pourrez augmenter la puissance et reconfigurer les services en accord avec ces nouveaux paramètres.Sur un serveur physique, il sera difficile d'augmenter les ressources sans changer d'offre.
Sur un serveur cloud Gandi, il vous suffit d'ajouter du processeur et de la mémoire vive, à chaud, sans redémarrage (dans une certaine limite)
Si vous avez déjà poussé tous les paramètres à fond, il va falloir aller plus loin...
3. Optimiser les services
Il y a plusieurs services qui peuvent être optimisés, prenons l'exemple d'un blog qui connaît un nombre important de connexions qui fonctionne sous PHP/MySQL, soit une grande partie des sites web aujourd'hui.Serveur web (Apache, Nginx, Cherokee, ...)
Pour chacun d'entre eux, les gestionnaires de connexions diffèrent, il est préférable de vérifier les bonnes pratiques pour les configurer par rapport à la puissance du serveur, la consommation de ressources maximum par visite, ... Leurs documentations restent le bon point de départ pour les appréhender au mieux.Module/interpréteur PHP
Apache est connu pour faire fonctionner l'interpréteur PHP à la volée, soit le démarrer lorsqu'il y a du code PHP à exécuter. Démarrer l'interpréteur peut etre long à s'instancier, cela peut paraître infime, cependant, c'est une source majeure de ralentissements. Pour éviter cela, on peux sortir PHP du serveur web en passant du mode module (mod_php) en FastCGI. L'interpréteur démarre donc au meme moment que le serveur web, reste en arriere plan et est disponible immédiatement. Il est donc recommandé de passer PHP en mode FastCGI. Notez que Cherokee ou Nginx sont paramétrés comme cela nativement.
Serveur de bases de données MySQL
Il existe sur MySQL plusieurs optimisations comme sur cet article (qui date un peu).La documentation à jour est disponible sur cette page.
Comme vous le verrez dans cet article provenant de MySQL, ils demandent bien de trouver les goulots d'étranglement inhérents au code source, au serveur, aux liaisons entre les services, ... avant de se lancer dans les optimisations qui peuvent être :
- matérielles : comme adapter la version du système selon la taille des bases et de la mémoire vive (32/64bits), les disques (lire plusieurs blocs à la fois) ou le système d'exploitation (nombre de fichiers ouverts avec ulimit)
- la réplication pour avoir plus de serveurs permettant d'augmenter le nombre de requêtes possibles en simultané
- augmenter le nombre de threads et/ou de connexions sur chaque serveur
- optimiser les requêtes SQL et utiliser un moteur convenant à l'utilisation faite
- utiliser les caches (query, key myisam ou buffer innodb)
- ...
Systèmes de caches
Vous pouvez installer des systèmes de cache à plusieurs niveaux : nous l'avons vu pour MySQL rapidement, sachez qu'il existe des caches à placer devant le serveur web (cache HTTP tel que Varnish) qui garde une copie de la page web complète en mémoire. D'autres systèmes de cache pour les interpréteurs comme Xcache pour PHP. Ils consomment un peu de ressources mais évitent une charge supplémentaire sur les services principaux en limitant les appels que pour le recalcul de la page web et le remplaçement dans le cache.Pour le cache Web/HTTP, il permet aussi d'éviter que le serveur web ne soit directement accessible depuis l'extérieur, offrant un protection légère mais non négligeable.
4. Opter pour une architecture répartie
Si, au terme de ces optimisations, le serveur ne supporte toujours pas la charge, il faudra donc penser architecture webCela implique de multiplier les serveurs où sont installés les services pour répartir la charge sur chacun d'eux, il est possible de dupliquer tout ou partie de l'infrastructure : web, caches, bases de données, ... La répartition peut se faire au niveau du cache HTTP (Varnish), des DNS (Round Robin) ou d'un proxy (tel qu'Haproxy) selon les souhaits et la taille de la plateforme.
Avec des systèmes de vérification (de type "healthcheck" sur Haproxy, Heartbeat ou encore Varnish par exemple), nous pouvons éviter d'envoyer un visiteur sur un serveur dont les services ne fonctionnent pas.
La géolocalisation des visiteurs ou l'exploitation de plusieurs centres de données pour le même service
Avec l'architecture répartie, nous avons trouvé une solution qui permet d'honorer la charge en terme de visites simultanées en masse. Cependant, certains visiteurs éloignés du pays de localisation des serveurs peuvent avoir une latence importante (depuis la Nouvelle Zélande ou le Chili vers la France par exemple). Une solution est de mettre à disposition des serveurs plus proches d'eux, en géolocalisant par pays par exemple, le serveur DNS Bind avec le système de "vues" (views) allié à la base MaxMind qui contient les plages d'adresses IP par pays effectue bien cette opération.
Un exemple concret avec un blog Wordpress sur 2 centres de données
A titre d'information, nous avons pris des serveurs d'une part chacun :
- un DNS,
- deux serveurs Web,
- deux serveurs de bases de données.
Commentaires
Bonjour,
Article intéressant.
Mais quand seront disponibles les réseaux privés (vlan ?) entre différents serveurs ?
C'est une fonctionnalité qui me semble indispensable lorsqu'on veut penser « Architecture Web » et je l'attends avec impatience depuis... 2009 !
@Daniel Dupont : on travaille encore sur cette fonctionnalité de réseau privé qui est loin d'etre simple. On vise fin 2011.
Je suis d'accord avec Daniel.
Lors de votre 1er article, j'ai voulu monter chez vous un cluster (2 loadbalancer, 2 tomcat, 2 mysql, 2 memcached)... le gros hic c'était la bande passante interne.
Nous avons testé avec juste 1 lb, 1 tomcat, 1 mysql... Avec des instances à 15 ou 25Mb/sec, c'est pas jouable...
Payer plus de 200€/mois/nœud juste pour avoir du 100Mb rend complètement caduque cette approche. Nous avons du coup loué des dédiés ailleurs, mais c'est dommage, j'aime bien votre approche.
En débit sortant, 20Mb me suffisent, mais en interne, il faut le max, sinon on paie de la RAM/CPU... pour rien du tout.
En effet, la bande passante, surtout dans le cas du répartiteur de charge, est importante.
Comme indiqué sur le PoC, il est possible de ne pas tout répartir, par exemple en laissant le cache HTTP s'occuper de la répartition de charge sur les serveurs web.
Cela dépend des besoins et de l'architecture souhaitée, il est toutefois possible de s'affranchir des répartiteurs en entrée.
Bientôt les VLANs :)
Je suis d'accord avec gregware qui est d'accord avec moi :-)
Il y a effectiverment deux problématiques différentes :
- la bande passante disponible entre deux serveurs virtuels chez Gandi
- la facilité de l'architecture réseau induite pas la possibilité de mettre en place un réseau virtuel entre deux machines chez Gandi (avec des adresses RFC1918)
J'ose espérer que la fonctionnalité tant attendue réglera ces deux aspects simultanément.
Quoi qu'il en soit, je vous serait très reconnaissant d'arrêter de faire l'apologie de l'« Infrastucture Web » avant d'avoir mis en place ces réseaux privés. L'un sans l'autre est pure hérésie.
Enfin, à la vue de la réponse qui est à nouveau faite ici (« On vise fin 2011 ») je sens que je vais probablement profiter de l'été pour mettre en œuvre la même solution que gregware : allez voir ailleurs, non sans regrets, soyez-en certains.
À moins que pour nous faire patienter vous puissiez au minimum offrir une bande passante supérieure entre serveurs Gandi (au moins ceux appartenant à un même client).
"Recette" intéressante... disons que c'est un peu le B.A-BA d'un admin sys/web.
Après je trouve que l'approche manque d'informations sur les otpimisations système possibles, tel que :
- les options filesystem et/ou le type de FS
- le monitoring / optimisation des I/O disk
- la possibilité d'utiliser du matériel flash ssd sur du cache (la partie de son infra la plus utilisée)
- l'utilisation de type de stockage externe (et les liens) / interne, config matériel.
- les ipcs
- l'utilisation de liaisons autres que Ethernet et/ou l'optimisation de ces liens côté "OS" en fonction du kernel
- le protocole de routage choisi
- les options DNS possibles
- les MàJ firmware et ou pilote du matériel
- les matrices de compatibilité matériels réseaux
...etc ...
La liste peut être très longue.
Bref, un peu trop porté sur la partie logiciel qu'hardware
Cette vision est présentée de telle sorte que ce soit vu pour un client d'un web Hoster, ce qui est logique, vu vos offres, mais ne peut pas servir de guide d'optimisation généraliste. Pour ça que le côté :"...ainsi que dans le monde du web en général." me semble un peu trop généraliste, mais ce n'est qu'un détai
Bonne continuation @aegiap (et au plaisir de te recroiser à l'occaz)
Bon, je crois que le message est passé, en tout cas si votre cible de clientèle sont les petites infra virtualisées :-)
Emerick > Grave qu'elle compta la bande passante pour du LB :-) Surtout que dans mon cas, ce n'est pas du "web editorial", mais des outils intranet, donc peu de mise en cache des pages, à part les 3 css et 5 planches de sprites...
En effet ca dépend de l'archi, mais se passer des frontaux du LB rend la maintenance des nœuds applicatifs hyper compliquée (ssl, hot-update, ajout d'un noeud complémetaire, gestion des versions des moteurs de calcul...), pour moi ce n'est pas du tout une option aujourd'hui.
Et prends le problème à l'autre extrémité... par exemple pour le cache distribué qui doit se synchroniser sur toutes les instances dispo, pour de la HA. Lorsque mon utilisateur manipule un (petit) cube de 35Mo de données, je ne peux pas me permettre de lui demander d'attendre 20s pour que tout le monde se synchronise.
Nocktames > on parle ici de virtualisation, tout ce que tu évoques en plus est surtout valable quand tu mets ton hardware en colo sur tes baies, non ?
Perso, c'est pour ne plus à me demander si mon cable nullmodem pour heartbeat est bien branché (dernière fausse alerte en date chez moi) que je cherche le genre de produits que Gandi veut mettre en place.
Dsl de paraître le poil a gratter sur la partie hébergement, mais je trouve ce sujet sur la virtualisation tout en étant intéressant techniquement parlant, un peu léger dans la considération "sécurité" des données... En effet quelle est la position de Gandi sur le Patriot Act en particulier pour son datacenter US à Baltimore ? Les données SQL répliquées depuis la base EU, sont elle soumise au dit Patriot Act ? Bref une infrastructure ou la confidentialité des données n'est plus assuré, n'est pas pour moi une infrastructure fiable à la base... et c'est aujourd'hui, la problématique majeur auquel tous les acteurs de l'infrastructure virtualisé sont confrontés... (d'ovh, à Crosoft, Gandi y compris sauf démenti)...
Bref, un autre data center en prévision au Quebec / Canada ?
Bonne question tdldp :)
Et pour rester en Europe, pourquoi pas en Suisse qui est quand même bien protectrice des données personnelles ?
Est-ce que le Patriot Act impose une limite sur les technos de cryptage ?
Sinon, les techniques standard de cryto de bdd et de fs te mettent à l'abri.
La NSA peut surement les casser, mais est-ce que nos données (pauvres mortels) valent leur temps d'expertise ?
Ouaip pour le cryptage, j'y ai évidemment pensé mais dans quelle mesure cela ne met il pas l’hébergeur et le crypteur (client donc) hors la loi vis à vis du patriot Act: Pour information
- under the Patriot Act, any use of encryption in furtherance of felony incurs a five year sentence amplifier
- All keys, algorithms (down to the byte and type of encryption) must be submitted in a an application to the US Commerce Approvals office for review and approval prior to legally exporting any software, data, etc in an encrypted format so the US Government can decipher if needed (note this was in effect prior to the Patriot Act as part of standard Export Approvals).
Ces 2 points me laisse penser que le cryptage du FS peut conduire à des condamnations à priori tant pour l'hébergeur qui peut voir son activité purement interdite, et pour l'utilisateur des données pour cause de "Felony" (comme pour le pépère DSK). (ca n'aura aucun impact pour un européen ou une entreprise européenne qui ne présente pas aux usa mais en cas de condamnation, le territoire américain te devient interdit, même pour un transit aérien).
Bref, éclaircissement à attendre à ce sujet... (la Commission Européenne le fait d'ailleurs en ce moment en demandant aux USA des explications)
"So the US Government can decipher if needed" !
Incroyable, ca quand même... sérieusement, jamais je vais déclarer ma clef si je veux faire qqc de mal (ce serait le dernier de mes soucis de me faire coincer pour ca), à part l'espionnage industriel, je vois pas à quoi ca sert.
Je trouve en effet que les hébergeurs EU devraient clarifier leur position.
En Fr/Eu, on a juste des limites sur les technos employées, non ?
@gregware:
> En Fr/Eu, on a juste des limites sur les technos employées, non ?
Non, depuis 10 ans (à peu près, je n'ai plus les dates exactes et la flemme de fouiller dans legifrance, le chiffrement est libre en France. Tu chiffres ce que tu veux, comme tu veux, mais sur requête de la police/justice dans le cadre d'une enquête tu dois fournir les clés (sinon., lourde condamnation assurée, au moins pour complicité).
Sinon, il serait intéressant de faire du bittorrent depuis le DC Gandi@Baltimore, pour voir si Gandi applique la procédure "cease and desist" DMCA suite aux mails de WebSheriff pour le MPAA ou la procédures "3 avertissements et coupure" Creation et Internet suite aux relevés d'IP pour HADOPI. Ou les deux :)