12 votes

Meilleur moyen d'équilibrer la charge entre plusieurs serveurs de fichiers statiques pour une distribution uniforme de la bande passante ?

Tout d'abord, je vais vous expliquer ma situation. Je gère un site Web assez populaire en tant que projet secondaire, de sorte que je ne peux pas vraiment investir une tonne d'argent dans celui-ci. J'ai actuellement un seul serveur avec HAProxy à l'avant qui envoie les demandes normales à Apache et toutes les demandes de fichiers statiques à Lighttpd. Cela fonctionne très bien car toutes les requêtes php et post sont traitées par Apache, tandis que toutes les images sont envoyées à Lighttpd, plus rapide (le site est principalement composé d'images, donc c'est très important). Ce serait bien de ne pas avoir à configurer un sous-domaine pour servir les images, car les URL courtes sont également très importantes, d'où ma raison d'utiliser HAProxy.

J'ai trouvé un fournisseur d'hébergement qui offre une bande passante non mesurée assez bon marché que j'utilise, le problème se pose lorsque je commence à pousser la bande passante au-delà de ce que la carte réseau de 100 mégaoctets peut gérer, ce qui nécessite un deuxième serveur.

J'ai beaucoup réfléchi à mes options, je vais donc vous expliquer chacune d'entre elles. J'espère que vous pourrez m'éclairer sur la meilleure option pour moi ou qu'il existe une autre option à laquelle je n'ai pas encore pensé.

Exigences :

  • La répartition uniforme de la bande passante est une nécessité. J'ai un serveur assez puissant, donc l'extension n'est pas envisageable. Je dois passer à l'échelle inférieure pour obtenir davantage de bande passante.

  • URLs courtes. Je n'ai vraiment pas envie de créer un sous-domaine, comme img.example.com, pour servir mes images. example.com/image.jpg est tel qu'il est maintenant, et j'aimerais vraiment qu'il le reste. Mais s'il n'y a pas d'autre moyen, alors je comprends.

  • Le serveur clostest qui traite la demande serait vraiment bien, mais pas indispensable. Quelque chose à garder à l'esprit.

HAProxy pour équilibrer la charge :

  • Ce serait vraiment facile à faire puisque j'utilise déjà HAProxy de toute façon. Cependant, je pense que le problème se pose lors de la distribution de la bande passante. Je me trompe peut-être, mais HAProxy n'envoie-t-il pas la demande à un serveur qui la traite et la renvoie au client via HAProxy ? Ainsi, tout le trafic est renvoyé par l'équilibreur de charge, ce qui fait qu'il utilise autant de bande passante que tous les serveurs réunis.

DNS Round Robin :

  • Cela pourrait être ma meilleure option. Il suffit de répliquer le site Web sur plusieurs serveurs et de faire ce que je fais actuellement. L'inconvénient est que si un serveur tombe en panne, les clients sont toujours envoyés vers ce serveur. J'aurais également besoin de répliquer le site sur les multiples serveurs. J'espérais pouvoir avoir un serveur principal qui gère tout sauf les fichiers statiques, puis avoir deux serveurs de fichiers statiques. J'ai également lu qu'il s'agissait d'une sorte d'équilibrage de charge pour les pauvres, et que ce serait bien d'avoir quelque chose d'un peu plus sophistiqué.

Retour direct du serveur :

  • Cela semble vraiment compliqué, mais pourrait être une bonne option. Serait-il toujours possible d'envoyer certaines URL à certains serveurs ? Comme actuellement avec HAProxy, chaque URL qui se termine par la bonne extension de fichier est envoyée à Lighttpd, tandis que les autres extensions sont envoyées à Apache. J'aurais donc besoin de quelque chose de similaire. Par exemple, toutes les requêtes php sont traitées par le même serveur qui exécute le logiciel d'équilibrage, tandis que toutes les requêtes jpg sont envoyées à plusieurs serveurs.

Idéalement, si HAProxy prenait en charge le retour direct au serveur, mon problème serait résolu. Je ne veux pas non plus utiliser de CDN, car ils sont très coûteux et il ne s'agit que d'un projet secondaire après tout.

Comprenez-vous mon problème ? Faites-moi savoir si je n'ai pas bien expliqué quelque chose ou si vous avez besoin de plus d'informations.

1 votes

C'est Imgur, qui a récemment levé 40 millions de dollars. :O

3voto

lee Points 599

Faites un dessin de votre cycle de demande/réponse pour l'application et isolez le goulot d'étranglement. Vous avez raison de dire qu'un seul proxy distribuant la charge à de nombreux serveurs d'application nécessitera la bande passante globale de tous les serveurs d'application. La solution classique est le DNS RR. Google, Yahoo et Amazon utilisent tous cette technique avec un TTL court. J'ai fait quelques recherches il y a quelque temps et j'ai documenté mes découvertes .

Une autre solution consiste à utiliser une solution d'équilibrage de charge d'entreprise sophistiquée utilisant l'adressage IP virtuel pour équilibrer les demandes entre plusieurs serveurs d'application dotés d'adresses IP réelles. J'ai travaillé avec les produits Netscaler et Stonesoft. Tous deux sont performants mais présentent de terribles idiosyncrasies et sont assez complexes.

0 votes

Merci beaucoup. Les résultats de votre enquête ont été très utiles. Je pense que c'est la solution à laquelle je vais finalement arriver. Cependant, "comme tout bon chercheur, je n'agis pas avant d'avoir suffisamment de données". :)

0 votes

Merci pour cet aperçu. Malheureusement et ironiquement, le lien vers vos résultats semble être en panne, pouvez-vous le réparer ?

3voto

Zameer Manji Points 1213

Quelques réponses :

  • Oui, tout le trafic passe par HAProxy, car il fonctionne comme un proxy au niveau HTTP. Il en sera de même si HAProxy est installé sur un serveur distinct qui équilibre la charge de plusieurs serveurs dorsaux. Ainsi, si votre fournisseur d'hébergement ne fournit que des ports réseau de 100MBit et que vous utilisez déjà 100MBit, vous avez un problème.
  • En ce qui concerne le domaine, l'idéal serait de servir les images à partir d'un domaine différent de celui de votre application Web - pas un sous-domaine, un domaine différent, afin que les cookies ne soient pas envoyés lors des demandes d'images. Voir Travail original de Steve Souders o l'implémentation ici sur Stack Overflow . Si les URL courtes sont très importantes pour vous, la meilleure solution serait peut-être de déplacer l'application web en dehors de l'URL principale, c'est-à-dire de déplacer l'application de gestion de fichiers vers login.nomdelasituation.com ?

Avez-vous besoin d'une authentification pour les demandes d'images ? Sinon, pourquoi ne pas utiliser quelque chose comme Amazon S3 ? Il est massivement extensible et le coût de transfert des données est assez bon marché. Dans ce cas, j'utiliserais quelque chose comme i.nomdelasituation.com comme CNAME DNS pour le nom d'hôte du seau Amazon S3, voir les documents d'Amazon . A priori, vous ne pouvez pas avoir le nom de domaine racine (nom_site.com) comme CNAME, vous devez donc utiliser un sous-domaine comme i.nom_site.com pour cela.

Vous pouvez également hacher vos images sur plusieurs serveurs. C'est-à-dire que vous créez une structure DNS comme login.nomdelasituation.com et a.nomdelasituation.com ; b.nomdelasituation.com ; c.nomdelasituation.com et ainsi de suite. Les serveurs "a." et "b." etc. contiennent juste un système de fichiers avec des images, et un serveur HTTP léger (vous utilisez déjà Lighttpd, alors continuez à l'utiliser. Pour un futur projet, je proposerais de regarder nginx comme un meilleur remplacement). Lorsqu'un utilisateur télécharge une image, vous créez un fichier hachage d'un identifiant unique, peut-être son nom d'utilisateur, peut-être le nom du fichier, ou une combinaison de plusieurs identifiants . À partir de ce hachage, vous déterminez sur quel serveur stocker l'image.

Modifier J'aurais dû voir que le hachage avait déjà été discuté. Essentiellement, ce que je propose ici, c'est d'utiliser le hachage sur le nom d'hôte également, pour répartir le trafic réseau uniformément sur plusieurs hôtes.

Je ne sais pas à quel point tu as besoin que ce soit bon marché. -- mais lorsque le trafic réseau atteint 100 MBit, le "bon marché" s'avère rapidement être une illusion. Peut-être devriez-vous commencer par vous doter d'un bon modèle économique, quelque chose qui génère des revenus récurrents, puis mettre en œuvre la technologie appropriée par la suite ?

1voto

Justin Scott Points 8728

Je suppose que HAProxy est sur le même serveur que vos autres applications ? Vous pourriez répartir HAProxy sur un autre système pour y faire passer les requêtes et faire en sorte qu'il envoie les requêtes normales à un serveur, et les requêtes d'images à un autre serveur. Le problème est que toutes les demandes sont toujours envoyées à une seule boîte, et si vous saturez sa bande passante, cela ne vous aidera pas beaucoup.

Vous dites que les URL courtes sont importantes. Pourquoi ? Est-ce vraiment si important de changer les images de "exemple.com" en "i.exemple.com" ? Vous pouvez définir "i" sur sa propre IP sur son propre serveur avec Lighttpd et contourner entièrement HAProxy, ce qui résout votre problème de débit. Vous bénéficiez également de l'avantage du navigateur web qui permet d'ouvrir plus de requêtes à la fois puisqu'il les considère comme des noms de domaine différents et peut ouvrir plus de connexions simultanées. Si le serveur "i" unique est saturé, vous pouvez utiliser le DNS round-robin pour en ajouter un autre. Espérons qu'à ce moment-là, vous aurez généré suffisamment de revenus pour mettre en œuvre une meilleure solution.

0 votes

Oui, HAProxy est sur le même serveur - je n'en ai qu'un seul pour l'instant. Même si je le répartissais sur un autre serveur, toutes les données ne passeraient-elles pas par le serveur avec HAProxy, comme je l'ai expliqué ci-dessus ? Les URL courtes sont importantes car c'est en quelque sorte le but du site. C'est un croisement entre ImageShack et TinyPic. Plus l'URL est longue, moins mon site a d'intérêt. Mais comme je l'ai dit, si la seule option viable est de créer un sous-domaine, alors je dois le faire. Mais je préférerais vraiment ne pas le faire.

1voto

hdanniel Points 4263

Votre fournisseur d'hébergement offre-t-il des services d'équilibrage de charge ? Je pense que c'est la meilleure solution.

Une autre façon de faire, mais qui doit être testée, est de réécrire (dans lighty ou apache) les requêtes. Par exemple : exemple.com/file.html reste dans apache et exemple.com/image.jpg redirige vers i.exemple.com/image.jpg . Toutes les requêtes seront gérées par apache mais les réponses (bande passante en amont) vont vers le serveur lighttpd. Le domaine est transparent pour l'utilisateur. Vous devez tout de même tester si apache peut gérer toutes les requêtes ou peut-être laisser lighttpd faire ce travail.

Vous avez raison, toutes les données passent par HAProxy, donc vous ne pouvez pas (pour autant que je sache) faire un retour direct au serveur avec cela.

UPDATE

Regarder à l'intérieur Documentation sur HAproxy J'ai trouvé le paramètre "redir". Je ne sais pas si cela peut fonctionner comme apache rewrite mais cela peut être utile. La documentation dit :

L'utilisation principale consiste à augmenter bande passante pour les serveurs statiques en faisant les clients s'y connectent directement.

Peut-être que ça marche pour votre cas.

0 votes

Hey, merci pour la réponse. J'ai déjà essayé cette solution, mais elle ne fonctionne pas aussi bien en pratique qu'en théorie. La raison est qu'Apache gère toutes les requêtes, donc chaque fois qu'un utilisateur clique sur une image, Apache est lancé, regarde l'url, puis l'envoie à la lumière. Ce qui n'est pas différent que de laisser Apache gérer l'image en premier lieu. Je suis d'accord qu'un équilibreur de charge fourni par mon hôte est la meilleure option, mais c'est aussi l'une des plus chères. Ils facturent par connexion simultanée, et j'en ai des centaines.

0 votes

La différence réside dans le fait que le serveur Lighty enverra la réponse directement au client en consommant sa propre bande passante. Le problème est que le serveur Apache va gérer un grand nombre de demandes. Vérifiez la mise à jour de ma réponse, j'ai trouvé une autre solution.

1voto

3dinfluence Points 12361

Je suppose qu'avec un ensemble assez important d'images, vous ne stockez pas les images en fonction de leur nom de fichier original, car vous auriez rapidement des conflits de noms.

Un grand nombre d'applications qui traitent ce type de problèmes utilisent le hachage du fichier et une structure de répertoire basée sur ce hachage. La structure de répertoire ressemble à ce qui suit : le chemin d'accès au répertoire est constitué des deux premiers caractères du hachage, puis le répertoire de deuxième niveau est constitué des deux caractères suivants du hachage.

/image root/AA/AA/images  
/image root/AA/AB/images

L'avantage est que les hachages permettent de conserver une distribution assez homogène des fichiers et de disposer d'un espace de noms facile à répartir sur plusieurs serveurs. En fait, vous servez des portions de l'espace de hachage à partir de différents serveurs et, au fur et à mesure que vous évoluez, vous pouvez subdiviser cet espace selon vos besoins.

L'inconvénient est que les hachages ne sont pas parfaits et qu'il peut y avoir des collisions. Je ne suis pas sûr de la façon dont cela est traité. Cela peut donc nécessiter un peu de recherche de votre part. J'imagine qu'une règle de réécriture dans le proxy devrait pouvoir prendre un hash, disons A3A8BBC83261.jpg, et le réécrire en http://img3.domain.com/A3/A8/BBC83261.jpg . Vous ne pouvez cependant pas considérer qu'il s'agit d'une url courte.

0 votes

Oui, c'est exactement comme ça que je stocke les images. Mais le problème n'est pas le stockage, c'est la distribution de la bande passante.

0 votes

Mais si vous stockez les numéros AA à 33 sur un serveur et les numéros 34 à 99 sur un autre serveur, vous équilibrez non seulement le problème de stockage, mais aussi la répartition de la bande passante.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X