Comment partager des actifs entre plusieurs serveurs Web?

16

J'ai plusieurs serveurs Web Linux attachés à un équilibreur de charge, et j'aime partager des actifs (tels que des images, des vidéos et d'autres choses) entre ces serveurs. Quelle est la meilleure façon de procéder?

Actuellement, je suis monté sur un serveur de fichiers sur tous les serveurs Web, mais je crains qu'il ne tombe sous un trafic important. Comment puis-je éviter que cela se produise?

Merci d'avance.

linux web-server file-sharing

— getmizanur
source

C'est là que des choses comme Cassandra (bases de données NoSQL) sont utiles.

— Alexis Wilke

Vous envisagez d'utiliser Varnish pour améliorer les performances lors d'un trafic intense? en.wikipedia.org/wiki/Varnish_%28software%29

— Thorbjørn Ravn Andersen

12

Il existe plusieurs façons de le faire en fonction de vos besoins.

Utiliser un serveur de fichiers central monté avec fx NFS sur les serveurs Web
Comme ci-dessus, mais redondant, donc si l'un descend, l'autre prend le relais
Utilisez une sorte d'outil de synchronisation (rsync par exemple) et hébergez les fichiers localement sur les serveurs Web. Configurez ensuite un cronjob pour synchroniser les fichiers entre les serveurs à un intervalle spécifique.
Utilisez un CDN tel qu'Amazon S3, Akamai, etc.

Les deux premiers sont meilleurs si vous avez beaucoup de nouveaux fichiers à venir. Le troisième serait la solution idéale si vous n'ajoutez ou ne changez pas de fichiers aussi souvent car les utilisateurs obtiendront des 404 sur du contenu statique non encore synchronisé.

La dernière option peut être idéale à bien des égards, mais peut également s'avérer être la plus chère des 4. Vous devrez également réécrire vos sites Web pour prendre en charge cela.

— Frederik Nielsen
source

Le gros problème avec rsync est que vous obtiendrez probablement un 404 si vous téléchargez de nouvelles données et que le rsync ne se produit pas très rapidement ... De plus, un système comme Cassandra (point 4) est gratuit, même si bien sûr, avoir 10 serveurs n'est pas gratuit ... alors, je devrais peut-être dire sans frais supplémentaires (bien qu'il ait besoin de programmation pour que tout fonctionne.)

— Alexis Wilke

@AlexisWilke - Vous avez raison à propos de rsync, et je l'ai également mentionné dans la réponse. Je l'ai clarifié dans la réponse maintenant.

— Frederik Nielsen, le

Re: # 3, le `` temps mort '' entre le nouvel actif déployé et le nouvel actif synchronisé peut être minimisé si vous utilisez un observateur de système de fichiers (tel que le gardien de Facebook ) et un outil de synchronisation rapide (tel que csync2 ). Non, le délai ne descendra jamais à zéro, mais il est très minime et pourrait être plus facile à déployer que les autres alternatives.

— pepoluan

2

Un autre excellent moyen de réduire la charge sur les serveurs Web et d'effectuer l'équilibrage de charge est avec squid (à savoir squid3). Configurez-le en tant que proxy inverse avec mise en cache. Il mettra en cache le contenu statique tel que les images, etc. sur le disque dur (par défaut) ou sur la RAM (plus rapide et le meilleur) si vous le configurez de cette façon. Il est également capable de passer à la ronde vers d'autres serveurs Squid si un nœud particulier est surchargé.

— Aihngel Tech
source

1

Je pense que ce type de mise en cache échoue si vous voulez un site Web très dynamique. Parce qu'avec un fort dynamisme, vous devez toujours frapper le seul serveur principal pour beaucoup de données. Je pense que l'utilisateur envisage de fractionner le travail backend à la place.

— Alexis Wilke

1

Votre réponse est correcte sur la réduction potentielle de la charge, mais ne répond pas à la question sur le partage de fichiers d'actifs entre plusieurs serveurs.

@AlexisWilke, il échoue si vous n'avez pas configuré correctement Squid. Ajustez la façon dont il se cache (ou s'il se cache) dans les paramètres, mais vous pouvez constater qu'aucune page n'est jamais complètement dynamique. Il y a toujours quelque chose que vous pouvez mettre en cache. Andre aussi, cela aide beaucoup à partager des actifs comme le titre le décrit, mais pas à partager des fichiers. La question était de savoir comment empêcher les sites de tomber sous une forte charge. Squid est excellent dans ce domaine.

— Aihngel Tech

1

Étant donné que le besoin de plus de serveurs provient généralement des ressources nécessaires pour exécuter des sites Web / APS dynamiques, envisagez d'héberger des actifs statiques sur un autre sous-domaine / domaine. (comme static.yourdomain.com)

Vous pouvez ensuite utiliser un autre serveur / serveurs pour les héberger. L'hébergement de fichiers statiques n'utilise pas beaucoup de ressources, vous aurez donc besoin de beaucoup moins de serveurs pour votre contenu statique. Vous pourrez également libérer des ressources sur les serveurs pour votre contenu dynamique.

En fonction de votre équilibreur de charge, vous pouvez également le faire sur le même domaine, l'équilibreur de charge décidant quel serveur utiliser pour quelle demande, mais si vous utilisez un domaine distinct, vous pouvez mettre vos actifs statiques sur un CDN assez facilement, si le besoin devrait surgir!

— Josef dit de réintégrer Monica
source

1

Une solution à ce défi que j'ai utilisée consiste à avoir la copie principale en lecture / écriture des fichiers sur un lecteur NFS partagé, mais également à conserver une copie en lecture seule sur chaque serveur Web afin qu'une défaillance de l'hôte NFS mette l'accès aux fichiers en mode lecture seule plutôt que de les perdre complètement.

Fichiers en direct sur l'hôte central, partagés avec les hôtes Web via le montage NFS
rsync s'exécute toutes les 15 minutes pour conserver la copie en lecture seule sur chaque hôte Web.
Un check_linkscript bash s'exécute toutes les minutes pour s'assurer que le montage NFS est toujours là et sinon il échange un lien symbolique vers la copie en lecture seule.

Plus de détails se trouvent dans cet article à partir de la première configuration de ce système.

Avantages:

Les lectures de fichiers sont hautement disponibles
Aucune condition de concurrence pour les écritures de fichiers
De nouveaux fichiers sont instantanément disponibles pour tous les hébergeurs Web.

Inconvénients:

un peu complexe.
le nombre de copies en lecture seule varie avec le nombre d'hôtes Web, ce qui peut être excessif si vous en avez beaucoup plus de deux.
Les écritures de fichiers ne sont pas hautement disponibles.
Possibilité d'une minute d'indisponibilité avant de passer à la copie en lecture seule.

— Adam Franco
source

0

Vous voudrez peut-être envisager une base de données NoSQL. Ils sont conçus pour fonctionner sur des clusters, fournir une cohérence éventuelle. Mais attention, ils ne sont pas ACIDES.

Voici une introduction qui vous aidera à décider quel type de base de données NoSQL vous pourriez souhaiter pour votre objectif.

Voici une liste de ressources liées à NoSQL disponible.

— Azzy
source

4

Comment cette réponse aide dans le problème de synchronisation de fichiers?

— titus

@titus Dans NoSQL, lorsqu'il y a une écriture sur l'un des nœuds, elle sera répliquée sur d'autres nœuds du cluster. Les niveaux de cohérence d'écriture de Cassandra pourraient aider à clarifier les

— choses

donc le chemin à parcourir est de stocker tous les fichiers dans la base de données NoSQL?

— titus

@titus vous pouvez, mais les bases de données NoSQL peuvent faire beaucoup plus que stocker des fichiers, tout dépend de vos besoins.

— Azzy

2

OP a demandé une solution à un problème spécifique " plusieurs serveurs Web Linux attachés à un équilibreur de charge ... partagent des actifs (tels que des images, des vidéos et d'autres choses) entre ces serveurs. " Votre réponse est très générique, pouvez-vous suggérer et expliquer des outils spécifiques (et de préférence leurs configurations) pour résoudre le problème?

— kdbanman

0

Pourquoi n'essayez-vous pas une solution DFS, elles offrent un haut niveau de redondance et le volume peut être partagé entre autant de personnes que vous le souhaitez. Gluster est mon préféré et est très facile à installer et à configurer dans n'importe quelle distribution Linux célèbre

— Arash mo
source