La meilleure façon d'équilibrer la charge sur plusieurs serveurs de fichiers statiques, même pour une distribution de bande passante?

Tout d'abord, je vais vous expliquer ma situation. Je gère un site Web assez populaire en tant que projet parallèle, donc je ne peux pas vraiment y investir une tonne d'argent. Je n'ai actuellement qu'un seul serveur avec HAProxy à l'avant qui envoie des 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 des images, donc c'est vraiment important). Ce serait bien de ne pas avoir à mettre en place un sous-domaine pour servir les images, car les URL courtes sont également très importantes, donc ma raison d'utiliser HAProxy.

J'ai trouvé un fournisseur d'hébergement qui offre une bande passante illimitée assez bon marché que j'utilise, le problème survient lorsque je commence à pousser autant de bande passante que la carte réseau de 100 Mo peut gérer, nécessitant donc un deuxième serveur.

J'ai beaucoup réfléchi à mes options, je vais donc vous expliquer chacune d'elles. J'espère que vous pourriez donner un aperçu de laquelle est la meilleure option pour moi, ou peut-être qu'il y a une autre option à laquelle je n'ai pas encore pensé.

Exigences:

• Même la distribution de bande passante est un must. J'ai un serveur assez puissant, donc la mise à l'échelle n'est pas une option. Je dois évoluer pour gagner plus de bande passante.

• URL courtes. Je n'ai vraiment pas l'habitude de configurer un sous-domaine, comme img.example.com, pour servir mes images. example.com/image.jpg est comment c'est maintenant et comment j'aimerais vraiment qu'il reste. Mais s'il n'y a pas d'autre moyen, je comprends.

• Le serveur le plus clément traitant la demande serait vraiment sympa, mais pas un must. Quelque chose à garder à l'esprit.

HAProxy pour équilibrer la charge:

• Ce serait vraiment facile à faire car j'utilise déjà HAProxy de toute façon. Cependant, je pense que le problème survient lors de la distribution de la bande passante. Je peux me tromper à ce sujet, mais HAProxy n'envoie-t-il pas la demande à un serveur sur lequel le serveur la traite, puis la renvoie via HAProxy au client? Ainsi, tout le trafic retourne via l'équilibreur de charge, ce qui lui fait utiliser autant de bande passante que tous les serveurs combinés.

DNS Round Robin:

• Cela pourrait être ma meilleure option. Répliquez simplement le site Web sur plusieurs serveurs et faites ce que je fais maintenant. L'inconvénient est que si un serveur tombe en panne, les clients y sont toujours envoyés. J'aurais également besoin de répliquer le site sur plusieurs serveurs. J'espérais en quelque sorte que je pourrais avoir un serveur principal qui gère tout sauf les fichiers statiques, puis avoir quelques serveurs de fichiers statiques. J'ai également lu que c'était en quelque sorte «l'équilibrage de la charge du pauvre», et ce serait bien d'avoir quelque chose d'un peu plus sophistiqué.

Retour direct au serveur:

• Cela semble vraiment compliqué, mais pourrait être une bonne option. Serais-je toujours en mesure d'envoyer certaines URL à certains serveurs? Comme en ce moment 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. Comme, toutes les demandes php sont gérées par le même serveur qui exécute le logiciel d'équilibrage, tandis que toutes les demandes jpg sont envoyées à plusieurs serveurs.

Idéalement, si HAProxy supportait Direct Server Return, mon problème serait résolu. Je ne veux pas non plus utiliser de CDN, car ils sont vraiment chers, et ce n'est qu'un projet parallèle après tout.

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

Dessinez une image 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 répartissant la charge sur de nombreux serveurs d'applications nécessitera la bande passante agrégée de tous les serveurs d'applications. La solution classique est RR DNS. Google, Yahoo et Amazon utilisent tous cette technique avec un court TTL. J'ai fait une enquête il y a quelque temps et j'ai documenté mes conclusions .

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'applications avec des adresses IP réelles. J'ai travaillé avec les produits Netscaler et Stonesoft. Les deux fonctionnent bien mais ont des particularités terribles et sont assez complexes.

Quelques réponses:

• Oui, tout le trafic passe par HAProxy, car il fonctionne comme un proxy de niveau HTTP. Ce sera le même, même si HAProxy est installé sur un serveur distinct qui équilibre la charge de plusieurs serveurs principaux. Ainsi, si votre hébergeur ne fournit que des ports réseau de 100 Mo et que vous appuyez déjà sur 100 Mo, vous avez un problème.
• En ce qui concerne le domaine, l'idéal serait de diffuser des images d'un domaine différent de celui de votre application Web - pas un sous-domaine, un autre, afin que les cookies ne soient pas envoyés lors des demandes d'images. Voir le travail original de Steve Souders , ou l'implémentation ici sur Stack Overflow . Si les URL courtes sont très importantes pour vous, la meilleure chose serait peut-être de déplacer la webapp hors de l'URL principale, c'est-à-dire de déplacer l'application de gestion de fichiers vers login.sitename.com?

Avez-vous besoin d'une authentification sur les demandes d'images? Sinon, que diriez-vous d'utiliser quelque chose comme Amazon S3? Il est massivement évolutif et le coût de transfert de données est assez bon marché. Dans ce cas, j'utiliserais quelque chose comme i.sitename.com en tant que DNS CNAME pour le nom d'hôte du compartiment Amazon S3, voir la documentation d'Amazons . AFAIK vous ne pouvez pas avoir le nom de domaine racine (sitename.com) en tant que CNAME, vous devez donc utiliser un sous-domaine comme i.sitename.com pour cela.

Vous pouvez également hacher vos images sur plusieurs serveurs. C'est-à-dire que vous créez une structure DNS comme login.sitename.com et a.sitename.com; b.sitename.com; c.sitename.com et cetera. Le A." et B." etc les serveurs 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 hachage d'un identifiant unique, peut-être son nom d'utilisateur, peut-être le nom de 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 a déjà été discuté. Essentiellement, ce que je propose ici est simplement d'utiliser le hachage sur le nom d'hôte également, pour répartir uniformément le trafic réseau sur plusieurs hôtes.

Je ne sais pas à quel prix vous avez besoin de cela - mais lorsque vous poussez 100 Mo de trafic réseau, «bon marché et bon» se révèle rapidement être une illusion. Vous devriez peut-être commencer par chercher un bon modèle commercial, quelque chose qui génère des revenus récurrents, puis mettre en œuvre la technologie appropriée par la suite?

Je suppose que HAProxy est sur le même serveur que vos autres applications? Vous pouvez décomposer HAProxy sur un autre système pour exécuter les demandes et l'envoyer envoyer des demandes normales à un serveur et des demandes d'image à un autre serveur. Le problème, c'est que toutes les demandes vont toujours dans une seule boîte, et si vous saturez sa bande passante, cela ne vous aidera peut-être pas beaucoup.

Vous dites que les URL courtes sont importantes. Pourquoi? Est-ce vraiment si important de passer des images de "example.com" à "i.example.com"? Vous pouvez définir "i" sur sa propre IP sur son propre serveur avec Lighttpd et contourner HAProxy entièrement, résolvant ainsi votre problème de débit. Vous bénéficierez également du navigateur Web qui permet d'ouvrir plus de demandes à la fois car il les considérerait comme des noms de domaine différents et pourrait ouvrir plus de connexions simultanées. Si le seul serveur "i" est saturé, vous pouvez utiliser le DNS round-robin pour en ajouter un autre. Espérons que d'ici là, vous générez suffisamment de revenus pour mettre en œuvre une meilleure solution.

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

Une autre façon de le faire, mais qui doit être testée, est de réécrire (en lighty ou apache) les requêtes. Par exemple: example.com/file.html reste dans apache et example.com/image.jpg redirige vers i.example.com/image.jpg. Toutes les requêtes seront gérées via apache mais les réponses (bande passante amont) vont au serveur lighttpd. Le domaine est transparent pour l'utilisateur. Vous devez toujours 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, vous ne pouvez donc pas (pour autant que je sache) effectuer un retour direct du serveur avec.

MISE À JOUR

En consultant la documentation HAproxy, j'ai trouvé le paramètre "redir". Je ne sais pas si cela peut fonctionner comme la réécriture apache mais cela peut être utile. La documentation dit:

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

Peut-être que cela fonctionne pour votre cas.

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

De nombreuses applications qui traitent ces types de problèmes utilisent le hachage du fichier et une structure de répertoires basée sur ce hachage. La structure du répertoire ressemble à ce qui suit où le chemin du répertoire est les deux premiers caractères du hachage, puis le répertoire de deuxième niveau est les deux caractères suivants du hachage.

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

L'avantage ici est que les hachages maintiennent la distribution des fichiers assez uniforme et vous offrent un espace de noms facile à diviser sur plusieurs serveurs. Fondamentalement, vous servez des parties de l'espace de hachage à partir de différents serveurs et à mesure que vous évoluez, vous pouvez le subdiviser davantage si nécessaire.

L'inconvénient est que les hachages ne sont pas parfaits et qu'il peut y avoir des collisions. Je ne sais pas comment cela est traité. Cela peut donc demander un peu de recherche de votre part. J'imagine qu'une règle de réécriture dans le proxy devrait pouvoir prendre un hachage disons A3A8BBC83261.jpg et la réécrire sur http://img3.domain.com/A3/A8/BBC83261.jpg . Cependant, vous ne pouvez pas considérer que c'est une URL courte.

Dans votre message, vous avez mentionné que vous pensiez que le round robbin DNS pourrait être votre meilleure option, mais vous craigniez qu'un seul serveur tombe en panne ...

Si tel est le cas, jetez un œil au basculement simple de JH Software. Je l'ai utilisé dans le passé et cela fonctionne très bien.

http://www.simplefailover.com

Fondamentalement, il surveille vos serveurs et quand il en voit un, il réécrit rapidement le DNS pour retirer le serveur mort de la rotation.

Voici un extrait de leur site Web:

Le basculement simple surveille en permanence vos serveurs pour déterminer ceux qui fonctionnent et ceux qui le sont, puis il met à jour dynamiquement vos enregistrements DNS en conséquence afin que votre nom de domaine pointe toujours vers un serveur fonctionnel.

Il fonctionne avec les serveurs Web (HTTP), les serveurs de messagerie (SMTP, IMAP, POP3), les serveurs FTP et pratiquement tout autre type de serveur basé sur TCP / IP.

Comme mentionné précédemment, je l'ai utilisé dans le passé pour les sites Web et les serveurs de messagerie. Cela a plutôt bien fonctionné. Le basculement a été assez rapide dans la plupart des cas (en supposant 2 à 5 minutes) et je dirais que presque tout le monde a échoué en moins de 15 minutes.

Pas nécessairement PARFAIT ... mais définitivement rapide et facile.

REMARQUE: il s'agit d'un produit Windows. Je ne sais pas s'ils ont une version linux ou non, mais vous pouvez basculer sur n'importe quel serveur que vous aimez depuis son DNS.

Dans notre cas, nous venons de le lancer sur une machine XP, avons dit à la machine de redémarrer une fois par nuit, et cela a bien fonctionné pendant des années.