Penser infrastructure web
Par Nicolas le mardi 5 mai 2009, 13:31 - Hébergement - Lien permanent
Comme vous le savez, notre système est flexible et vous permet de passer à n'importe quel moment et autant de fois que vous le souhaitez d'un serveur sur 1 part (1/64 de machine + 1/64 en boost, 256Mo de Ram) à un serveur de 16 parts (1/4 de machine + 1/4 en boost, 4Go de Ram), mais nous avons de plus en plus de clients qui après le lancement de leur service sont victimes de leur succès et se retrouvent en limite d'utilisation des 16 parts et viennent nous demander des serveurs de 24 ou 32 parts.
Notre réponse est souvent la même, nous leur conseillons alors de penser infrastructure web plutôt que serveur web.
En effet, notre solution vous permet de créer autant de serveurs que vous le souhaitez sur les ressources souscrites dans votre compte hébergement, la solution optimale consiste donc à séparer vos services pour une plus grande flexibilité et une plus grande robustesse.
Mais le plus simple est de prendre un exemple concret : comme certains le savent déjà, nous soutenons l'association Millenium pour la promotion des jeux et loisirs numériques en ligne.
Le succès grandissant du site millenium.org nous poussait à rapidement repenser l'architecture du site pour tenir la charge (de nombreuses vidéos, 17 000 visiteurs uniques/jours). Pour ne rien vous cacher, nous avons quelques priorités et projets Gandi à régler avant de nous occuper du site.
Suite à une importante mise à jour d'un des jeux suivis par Millenium (NDLR: WOW patch 3.1), et même si nous avions anticipé une charge importante en passant le serveur sur 16 parts, celle-ci a vite dépassé nos estimations avec plus de 50 000 visiteurs uniques le premier jour et surtout presque autant les jours suivants.
Le site recevait alors entre 500 et 1000 visiteurs en simultané, ce qui n'est pas viable pour un serveur unique de type LAMP avec, de plus, de très nombreuses vidéos. Nous avons donc changé l'infrastructure immédiatement, pour passer d'un modèle sur un serveur unique (qui est souvent le choix au démarrage) à un modèle en infrastructure. Nous sommes passés d'une extension verticale (plus de puissance) vers une extension horizontale (plus de serveurs) :
Comme le montre ce schéma, nous avons donc sorti la base de données sur un serveur à part et dupliqué le serveur web sur 2 machines, la répartition de charge se faisant via la zone DNS du domaine. Nous pouvions aussi envisager de dédier un serveur d'une part à la répartition de charge, mais cette solution était un peu plus longue à mettre en place. Dans notre cas, il a fallu 2 minutes pour ajouter des parts sur le compte, 6 minutes pour créer les 2 serveurs, 10 minutes pour transférer les données et 2 heures environ pour configurer les services.
Aujourd'hui, la plateforme tient 1 million de visiteurs uniques par mois pour plus de 3 millions de pages vues, ce qui est une bonne chose. Mais le mieux c'est que maintenant la plateforme est évolutive. Si la base de données souffre, il nous suffira d'augmenter le nombre de parts allouées au serveur, et si les frontaux web arrivent à saturation, il nous suffira d'en ajouter un.
Si vous vous trouvez confronté à ce genre de problématique, n'hésitez pas à nous consulter, nous nous ferons un plaisir de vous conseiller.
Notre réponse est souvent la même, nous leur conseillons alors de penser infrastructure web plutôt que serveur web.
En effet, notre solution vous permet de créer autant de serveurs que vous le souhaitez sur les ressources souscrites dans votre compte hébergement, la solution optimale consiste donc à séparer vos services pour une plus grande flexibilité et une plus grande robustesse.
Mais le plus simple est de prendre un exemple concret : comme certains le savent déjà, nous soutenons l'association Millenium pour la promotion des jeux et loisirs numériques en ligne.
Le succès grandissant du site millenium.org nous poussait à rapidement repenser l'architecture du site pour tenir la charge (de nombreuses vidéos, 17 000 visiteurs uniques/jours). Pour ne rien vous cacher, nous avons quelques priorités et projets Gandi à régler avant de nous occuper du site.
Suite à une importante mise à jour d'un des jeux suivis par Millenium (NDLR: WOW patch 3.1), et même si nous avions anticipé une charge importante en passant le serveur sur 16 parts, celle-ci a vite dépassé nos estimations avec plus de 50 000 visiteurs uniques le premier jour et surtout presque autant les jours suivants.
Le site recevait alors entre 500 et 1000 visiteurs en simultané, ce qui n'est pas viable pour un serveur unique de type LAMP avec, de plus, de très nombreuses vidéos. Nous avons donc changé l'infrastructure immédiatement, pour passer d'un modèle sur un serveur unique (qui est souvent le choix au démarrage) à un modèle en infrastructure. Nous sommes passés d'une extension verticale (plus de puissance) vers une extension horizontale (plus de serveurs) :
Comme le montre ce schéma, nous avons donc sorti la base de données sur un serveur à part et dupliqué le serveur web sur 2 machines, la répartition de charge se faisant via la zone DNS du domaine. Nous pouvions aussi envisager de dédier un serveur d'une part à la répartition de charge, mais cette solution était un peu plus longue à mettre en place. Dans notre cas, il a fallu 2 minutes pour ajouter des parts sur le compte, 6 minutes pour créer les 2 serveurs, 10 minutes pour transférer les données et 2 heures environ pour configurer les services.
Aujourd'hui, la plateforme tient 1 million de visiteurs uniques par mois pour plus de 3 millions de pages vues, ce qui est une bonne chose. Mais le mieux c'est que maintenant la plateforme est évolutive. Si la base de données souffre, il nous suffira d'augmenter le nombre de parts allouées au serveur, et si les frontaux web arrivent à saturation, il nous suffira d'en ajouter un.
Si vous vous trouvez confronté à ce genre de problématique, n'hésitez pas à nous consulter, nous nous ferons un plaisir de vous conseiller.
Commentaires
Bonjour,
Article intéressant.
Sur ce type d'infrastructure comment gérer vous l'accès des serveurs web aux fichiers du site web => données dupliquées? partage NFS?
Effectivement, c'est intéressant, mais la répartition de charge par DNS, c'est vraiment pas propre.
Un serveur de base avec un HaProxy ou Nginx ne prend pas de ressource et assure une répartition de bien meilleure qualité, avec gestion de la persistance si l'accès authentifié le requiert.
Pour le mysql, j'avais testé il y a quelques années le cluster MySQL, qui ne m'avait pas semblé très stable mais avait de l'espoir. Quelqu'un a des news la dessus ?
Marama: tout dépend de la structure et de l'architecture du site, un montage NFS est une solution possible oui.
Julien: oui la répartition de charge par DNS est loin d'être la panacée. Un serveur en amont sur une part qui sert de proxy sera en effet beaucoup plus efficace. On bosse de notre coté pour vous proposer ça en tout 'packagé' d'ici la fin de l'année. J'avais regardé aussi les clusters MySQL à leur sortie mais je suis resté sur la même conclusion que vous.
Au niveau de la NFS lorsque tu fais de la réplication de data over internet ca pose pas mal de problème. Notamment lorsque tu te retrouves avec un soucis de latence ou meme de timeout.
Après une des solutions simples pour palier au mysql-cluster c'est de faire une architecture master-master avec deux serveurs mysql simples. La aussi il y a des atouts et des inconvenients : toujours le temps de réplication entre les deux machines qui peut porter défaut.
Avec le lancement de FreeBSD sur le hosting gandi (un jour peut-etre), le nfs devrait bien mieux fonctionner !
On en reve, et on l'a pas encore fait..
Le l/b DNS, c'est clairement pas top. Meme avec des TTL a zero, les caches sont pas toujours tout a fait respectueux de la chose. Un petit LB configurable par API serait tout de meme plus sympa.
Un cluster mysql, en RAM, mais ca demande une replication consequente,
ou des donnees non critiques. Pour des sites web cela dit, pas toujours besoin de relationnel, de la coherence demontree de SQL, mais parfois juste d'un k/v store, d'un hash, d'un cache..
Pour repliquer les donnees statiques, gerer le load balancing, et la mise en production des sites, on a de jolies idees. Je pense qu'un tuto/screencast accompagnera la sortie des quelques outils sur lesquels on bosse.
Le Load Balancing avec un serveur DNS, ça marche comment ?
Bon, une rechercher sur Google m'a amené à http://www.tcpipguide.com/free/t_DN... qui m'a donné la réponse. Merci pour la piste de recherche.
Votre schéma est très intéressant, avec les limites déjà sous-lignées, et un système de déploiement pré-packagé serait d'intérêt. Quand il sera prêt ,sans doute vous aurez des suiveurs et utilisateurs avertis qu'en profiteront les possibilités et exploreront les limites.
Pour répondre à marama, une méthode simple pour partager l'accès des serveurs webs aux fichiers du site c'est de mettre en place un rsync entre les deux plateformes.
Sinon pour reprendre ce que disait pascal, une solution c'est d'utiliser l'extension memcache de php avec un serveur memcached.
article intéressant et merci pour le schéma
Un article très intéressant.... mais pas assez instructif.
Il manque derrière tout ça un tutoriel !
J'espère qu'il viendra très vite
Question bête : pourquoi de pas mettre en frontal un loadbalancer hardware ?
Pourquoi vous voulez mettre un LB hardware cher et risqué en terme de point unique. Car si vous mettez un LB il va falloir le redonder sinon le LB tombe et pouf plus rien. Le round robin dns quand à lui permet de combler cette faiblesse car on profite de la fiabilité du protocole dns. Et pour ceux qui pense que c'est pas la panacée je suis d'accord si vous êtes dans un mode applicatif avec peu de connections simultané nécessitant alors de bien suivre la répartition de la charge client suivant les ressources disponibles. Dans le cas de serveur Web à million de visiteur le round robin dns nous donne une très bonne répartition statistiques et tous cela sans dépenser ni rajouter une couche supplémentaire de type LB à cette architecture classique.
Article intéressant.
Je serais aussi très intéressé par toute votre analyse et project management pour la migration du serveur sur cette infrastructure partagée
Il est très rare que les problèmes viennent des services http web. Le SQL est le plus souvent le plus consommateur de ressources. Pour "clusteriser" le SQL c'est déjà beaucoup plus complexe...
Pour éviter une saturation liée aux téléchargement, il est préférable d'utiliser le FTP.
Question que je me pose qd je vois ce type d'architecture : en quoi est-ce plus solide qu'une répartition de charge sur de gros serveurs de 13 parts (pour reprendre un total ~ égal à ce schéma) + 1 part pour la gestion du LB ?
Car ici, le serveur SQL tombe, tout tombe, le serveur mail tombe, c'est un peu le caca.
Avec 3 "gros" serveurs en LB, on en perd un, on perd pdt un moment 33% de puissance.
Je pose vraiment la question car je n'ai pas le niveau pour y répondre.
Ça promet! Mais à quand un SAN virtuel? Je pense ici à ceux qui, comme moi, voudraient monter un environnement d'hébergement web mutualisée sur plusieurs serveurs, avec Plesk ou CPanel par exemple, et distribuée, donc avec mail/dns/db sur des serveurs distincts.
Même question que Christophe...
En tout cas très intéressant, j'ai un projet de jeu MMORPG et je me posais justement la question concernant la montée en charge, voici donc une très bonne piste, ne manque plus que le tutoriel qui va avec