Recommandation d'architecture pour un site ASP.NET à charge équilibrée

Question

MISE À JOUR 2009-05-21

J'ai testé la méthode n ° 2 consistant à utiliser un seul partage réseau. Cela entraîne des problèmes avec Windows Server 2003 en charge:

http://support.microsoft.com/kb/810886

mettre à jour

J'ai reçu une proposition de site Web ASP.NET qui fonctionne comme suit:

Équilibreur de charge matérielle - > 4 serveurs Web IIS6 - > Base de données SQL Server avec cluster de basculement

Voici le problème ...

Nous choisissons où stocker les fichiers Web (aspx, html, css, images). Deux options ont été proposées:

1) Créez des copies identiques des fichiers Web sur chacun des 4 serveurs IIS.

2) Placez une copie unique des fichiers Web sur un partage réseau accessible aux 4 serveurs Web. Les webroots sur les 4 serveurs IIS seront mappés sur le partage de réseau unique.

Quelle est la meilleure solution? L'option 2 est évidemment plus simple pour les déploiements car elle nécessite la copie de fichiers vers un seul emplacement. Cependant, je me demande s’il y aura des problèmes d’évolutivité puisque quatre serveurs Web ont tous accès à un seul ensemble de fichiers. IIS mettra-t-il ces fichiers en cache localement? At-il frappé le partage réseau sur chaque demande du client? En outre, l'accès à un partage réseau sera-t-il toujours plus lent que la récupération d'un fichier sur un disque dur local? La charge sur le partage réseau est-elle considérablement aggravée si davantage de serveurs IIS sont ajoutés?

Pour vous donner une idée, il s’agit d’un site Web qui reçoit actuellement environ 20 millions de visites par mois. Récemment, il a reçu environ 200 hits par seconde.

Faites-moi savoir si vous avez une expérience particulière avec une telle configuration. Merci pour votre contribution.

MISE À JOUR 2009-03-05

Pour clarifier ma situation - les "déploiements". dans ce système sont beaucoup plus fréquents qu'une application Web typique. Le site Web est le frontal pour un système de gestion de back-office. Chaque fois que le contenu est publié dans le CMS, de nouvelles pages (aspx, html, etc.) sont automatiquement placées sur le site actif. Les déploiements sont essentiellement "à la demande". Théoriquement, cette poussée pourrait se produire plusieurs fois en une minute ou plus. Je ne suis donc pas sûr qu'il soit pratique de déployer un serveur Web à la fois. Des pensées?

Answer 1

Je partagerais la charge entre les 4 serveurs. Ce n'est pas beaucoup.

Vous ne voulez pas ce seul point de conflit, que ce soit lors du déploiement ou de ce seul point d'échec en production.

Lors du déploiement, vous pouvez les effectuer 1 à la fois. Vos outils de déploiement doivent automatiser cette opération en indiquant à l'équilibreur de charge que le serveur ne doit pas être utilisé, en déployant le code, tout travail de pré-compilation nécessaire et enfin en informant l'équilibreur de charge que le serveur est prêt.

Nous avons utilisé cette stratégie dans une batterie de serveurs de plus de 200 serveurs Web, qui a bien fonctionné pour un déploiement sans interruption de service.

Answer 2

Si votre principale préoccupation est la performance, ce qui, je suppose, réside dans le fait que vous dépensez tout cet argent en matériel, alors il n’a pas vraiment de sens de partager un système de fichiers réseau simplement pour des raisons de commodité. Même si les lecteurs réseau sont extrêmement performants, ils ne fonctionneront pas aussi bien que les lecteurs natifs.

Le déploiement de vos ressources Web est de toute façon automatisé (non?). Par conséquent, le faire en plusieurs n'est pas vraiment un inconvénient.

Si la procédure est plus compliquée que ce que vous indiquez, un système comme DeltaCopy serait peut-être utile pour synchroniser ces disques.

Answer 3

Une des raisons pour lesquelles le partage central est défectueux tient au fait que la carte réseau du serveur de partage constitue le goulot d'étranglement de l'ensemble de la batterie de serveurs et crée un point de défaillance unique.

Answer 4

Avec IIS6 et 7, le scénario d'utilisation d'un partage unique réseau sur N machines serveur Web / d'applications attachées est explicitement pris en charge. MS a effectué une tonne de tests de performances pour s'assurer que ce scénario fonctionnait bien. Oui, la mise en cache est utilisée. Avec un serveur double carte réseau, un pour l'internet public et l'autre pour le réseau privé, vous obtiendrez de très bonnes performances. Le déploiement est à l'épreuve des balles.

Cela vaut la peine de prendre le temps de le comparer.

Vous pouvez également évaluer un fournisseur de chemin virtuel ASP.NET, qui vous permettrait de déployer un fichier ZIP unique pour l'ensemble de l'application. Ou, avec un CMS, vous pouvez servir du contenu directement à partir d'une base de données de contenu, plutôt que d'un système de fichiers. Cela présente de très bonnes options pour le versioning.

VPP pour ZIP via #ZipLib .

VPP pour ZIP via DotNetZip .

Answer 5

Dans une situation de haute disponibilité idéale, il ne devrait y avoir aucun point de défaillance unique.

Cela signifie qu'une seule boîte contenant les pages Web est non-non. Après avoir effectué des travaux HA pour une grande entreprise de télécommunications, je commencerais par proposer ce qui suit:

• Chacun des quatre serveurs possède sa propre copie des données.
• À une heure de pause, mettez deux des serveurs hors ligne (c.-à-d. modifiez l'équilibreur haute disponibilité pour les supprimer).
• Mettez à jour les deux serveurs hors ligne.
• Modifiez l'équilibreur haute disponibilité pour commencer à utiliser les deux nouveaux serveurs et non les deux anciens.
• Testez-le pour vous assurer de son exactitude.
• Mettez à jour les deux autres serveurs, puis mettez-les en ligne.

C'est comme ça que vous pouvez le faire sans matériel supplémentaire. Dans le monde anal de la société de télécommunications pour laquelle j'ai travaillé, voici ce que nous aurions fait:

• Nous aurions eu huit serveurs (à l’époque, nous avions plus d’argent que vous ne pouviez en tirer). Lorsque le moment de la transition sera venu, les quatre serveurs hors ligne seront configurés avec les nouvelles données.
• Ensuite, l'équilibreur haute disponibilité sera modifié pour utiliser les quatre nouveaux serveurs et cesser d'utiliser les anciens serveurs. Cela a rendu le basculement (et, ce qui est plus important, le basculement si nous gavions) un processus très rapide et sans douleur.
• Ce n'est que lorsque les nouveaux serveurs sont en fonctionnement depuis un moment que nous considérons le prochain basculement. Jusque-là, les quatre anciens serveurs étaient maintenus hors ligne mais prêts, juste au cas où.
• Pour obtenir le même effet avec moins de dépenses financières, vous pouvez disposer de disques supplémentaires plutôt que de serveurs supplémentaires. La récupération ne serait pas aussi rapide car il faudrait éteindre un serveur pour remettre l'ancien disque, mais ce serait quand même plus rapide qu'une opération de restauration.

Answer 6

J'étais en charge du développement d'un site Web de jeux qui comptait 60 millions de visites par mois. Nous avons choisi l’option n ° 1. L'utilisateur avait la possibilité de télécharger des images et autres, et celles-ci ont été placées sur un NAS partagé entre les serveurs. Cela a plutôt bien fonctionné. Je suppose que vous faites également la mise en cache de pages et ainsi de suite, du côté des applications de la maison. Je déploierais également à la demande les nouvelles pages sur tous les serveurs simultanément.

Answer 7

Ce que vous gagnez en NLB avec 4IIS, vous le perdez avec BottleNeck avec le serveur d'applications.

Pour l'évolutivité, je recommanderai les applications sur les serveurs Web frontaux.

Ici, dans mon entreprise, nous implémentons cette solution. L’application .NET au premier plan et un serveur APP pour Sharepoint + un cluster SQL 2008.

J'espère que ça aide!

salutations!

Answer 8

Nous sommes dans une situation similaire à votre situation et notre solution consiste à utiliser un modèle éditeur / abonné. Notre application CMS stocke les fichiers dans une base de données et informe un service de publication lorsqu'un fichier a été créé ou mis à jour. Cet éditeur notifie ensuite toutes les applications Web abonnées, puis va chercher le fichier dans la base de données et le place sur son système de fichiers.

Nous avons les abonnés définis dans un fichier de configuration de l'éditeur, mais vous pouvez tout faire pour que l'application Web fasse l'abonnement lui-même au démarrage de l'application pour la rendre encore plus facile à gérer.

Vous pouvez utiliser un UNC pour le stockage, nous avons choisi une base de données pour la commodité et la portabilité entre les environnements de production et de test (nous copions simplement la base de données et nous avons tous les fichiers de site actifs ainsi que les données).

Answer 9

Une méthode très simple de déploiement sur plusieurs serveurs (une fois les nœuds configurés correctement) consiste à utiliser robocopy.

De préférence, vous devez disposer d'un petit serveur intermédiaire à tester, puis "robocopier" vers tous les serveurs de déploiement (au lieu d'utiliser un partage réseau).

robocopy est inclus dans le MS ResourceKit - utilisez-le avec le commutateur / MIR.

Answer 10

Pour vous donner un peu de matière, pensez à le maillage en direct de Microsoft. . Je ne dis pas que c'est la solution pour vous, mais le modèle de stockage qu'il utilise peut être.

Avec le maillage, vous téléchargez un petit service Windows sur chaque machine Windows de votre maillage, puis vous nommez les dossiers de votre système qui font partie du maillage. Lorsque vous copiez un fichier dans un dossier Live Mesh, ce qui correspond exactement à la copie dans un autre dossier de votre système, le service s'occupe de la synchronisation de ce fichier sur tous vos autres périphériques participants.

Par exemple, je conserve tous mes fichiers source de code dans un dossier Mesh et les synchronise entre travail et domicile. Je n'ai rien à faire du tout pour les synchroniser lors de l'enregistrement d'un fichier dans VS.Net. Le bloc-notes ou toute autre application lance la mise à jour.

Si vous avez un site Web avec des fichiers qui changent fréquemment et qui doivent être redirigés vers plusieurs serveurs, et probablement plusieurs auteurs pour ces modifications, vous pouvez placer le service Mesh sur chaque serveur Web et, à mesure que les auteurs ajoutent, modifient ou suppriment des fichiers, les mises à jour seraient poussées automatiquement. Pour ce qui est des auteurs, ils ne feraient que sauvegarder leurs fichiers dans un vieux dossier normal de leur ordinateur.

Answer 11

Utilisez un outil de déploiement, avec un processus qui se déploie un à la fois et le reste du système continue de fonctionner (comme l'a dit Mufaka). Il s’agit d’un processus éprouvé qui fonctionnera à la fois avec les fichiers de contenu et avec tout élément compilé de l’application (son déploiement entraîne un recyclage du processus asp.net).

En ce qui concerne le taux de mises à jour , vous pouvez le contrôler. Faites en sorte que les mises à jour passent par une file d'attente et ayez un processus de déploiement unique qui contrôle quand déployer chaque élément. Notez que cela ne signifie pas que vous traitez chaque mise à jour séparément, car vous pouvez récupérer les mises à jour actuelles dans la file d'attente et les déployer ensemble. D'autres mises à jour arriveront dans la file d'attente et seront récupérées une fois que l'ensemble de mises à jour actuel sera terminé.

Mise à jour : à propos des questions du commentaire. Il s’agit d’une solution personnalisée basée sur mon expérience des processus lourds / longs qui nécessite de contrôler leur taux de mises à jour. Je n'ai pas eu besoin d'utiliser cette approche pour les scénarios de déploiement, car pour un contenu aussi dynamique, j'utilise généralement une combinaison de base de données et de cache à différents niveaux.

La file d'attente n'a pas besoin de contenir toutes les informations, elle a simplement besoin des informations appropriées (identifiants / chemins) qui permettront à votre processus de les transmettre pour lancer le processus de publication avec un outil externe. S'agissant d'un code personnalisé, vous pouvez le faire joindre aux informations à publier, de sorte que vous n'ayez pas à le gérer dans le processus / l'outil de publication.

Les modifications de la base de données seraient effectuées pendant le processus de publication. Là encore, il vous suffit de savoir où se trouvent les informations relatives aux modifications requises et de laisser le processus / l'outil de publication les gérer. En ce qui concerne ce qu'il faut utiliser pour la file d'attente, les principaux que j'ai utilisés sont msmq et une implémentation personnalisée avec info dans le serveur SQL. La file d’attente n’est là que pour contrôler le taux de mises à jour, vous n’avez donc besoin de rien spécialement conçu pour les déploiements.

Mise à jour 2: , assurez-vous que vos modifications de base de données sont compatibles avec les versions antérieures. Ceci est vraiment important lorsque vous transmettez des modifications en direct à différents serveurs.

Answer 12

En supposant que vos serveurs IIS exécutent Windows Server 2003 R2 ou une version ultérieure, recherchez Réplication DFS . Chaque serveur dispose de sa propre copie des fichiers, ce qui élimine les goulets d’étranglement partagés sur le réseau, comme beaucoup d’autres l’ont prévenu. Le déploiement est aussi simple que de copier vos modifications sur l'un des serveurs du groupe de réplication (en supposant une topologie de maillage complet). La réplication s'occupe automatiquement du reste, notamment en utilisant la compression différentielle à distance pour n'envoyer que les deltas des fichiers modifiés.

Answer 13

Nous sommes ravis d'utiliser 4 serveurs Web, chacun avec une copie locale des pages, et un serveur SQL Server avec un cluster de basculement.