Comment déployer le site Web à la production avec un impact minimal sur les utilisateurs

Question

J'essaie de trouver la meilleure solution d'architecture de serveur pour déployer des mises à jour mensuelles sur un site Web public externe Asp.net. Ce que je cherche, ce sont des façons de publier une nouvelle version d'un site Web avec un impact minimal sur les utilisateurs. En plus de déployer la méthode standard (c'est-à-dire arrêter IIS, copier un nouveau site web sur un site existant, démarrer IIS), quelles sont les "meilleures" solutions pour le déploiement? Ce serait bien qu'ils gardent leur session et n'aient pas à voir un message "Site en cours de maintenance" pendant la mise à jour.

Ma configuration du serveur

Nous avons 2 serveurs Web IIS (2003) et tentent de trouver la meilleure façon de les utiliser pour les déploiements. Ma première pensée a été de mettre à jour le serveur web non-actif avec la dernière version. Ensuite, pointez élégamment le trafic web vers ce serveur avec un impact minimal sur les utilisateurs (dans le meilleur des cas, l'utilisateur ne perd pas sa session). Comment allez-vous "repointing" le trafic Web du serveur 1 au serveur 2? Changement de pare-feu NAT? Changer les enregistrements DNS? Un autre moyen? Nous devons être en mesure de tester le site en direct immédiatement après la publication des nouveaux changements (duh). Par ailleurs, nous utilisons nant et le régulateur de vitesse pour automatiser les builds, et un service web personnalisé pour déployer la build en production. Tout est donc automatisé avec le clic d'un bouton.

Une meilleure solution pourrait-elle être obtenue en utilisant un 3ème serveur? Si c'est le cas, comment?

Answer 1

La façon dont nous faisons est

Nous avons un équilibreur de charge de NetScaler,

prendre un serveur web sur loadbalancer, tous les déploiements ne, font un iisreset et le remettre dans équilibreur de charge.

Faites la même chose pour server2.

Enfin, invalidez le cache loadbalancer.

Answer 2

Eh bien, il y a une ou deux choses:

• Tout d'abord, pensez à utiliser une solution d'équilibrage de charge. Le serveur Windows 2003 est livré avec l'équilibrage de charge Windows (WLBS), mais ce n'est pas le meilleur produit. C'est, cependant, libre. Avec cela, vous pouvez diriger tout le trafic vers un serveur, le mettre à jour, puis faire le contraire. Deuxièmement, vous voudrez peut-être envisager de regarder comment vous travaillez avec les sessions. HTTP est sans état, ce qui signifie que tant que vous pouvez reconstruire la session d'un utilisateur sur un hit de page, ça devrait aller. L'utilisation de l'authentification par formulaire ASP.NET constitue une étape idéale dans ce sens. Le cookie écrit par elle n'est pas lié à une session ASP.NET. Bien sûr, cette approche conduit à un risque plus élevé - il y a une chance que les utilisateurs obtiennent un écran d'erreur s'ils frappent quelque chose tout comme vous copiez des fichiers. Et puis il y aura un délai pendant que le pool d'applications se rafraîchit.

Dans l'ensemble, votre meilleure option est l'équilibrage de charge. Même avec, cependant, envisager d'essayer la deuxième option ainsi - avoir des sessions qui peuvent régénérer fonctionne bien si les utilisateurs ne sont pas collants à l'un des serveurs dans le pool.

Answer 3

Je voulais juste ajouter ceci pour la brièveté.A mon travail précédent, en utilisant la configuration suivante nous avons réalisé des déploiements sans soudure:

Un équilibreur de charge citerais les serveurs Web ASP.NET de production (deux dans votre cas, mais nous avons eu trois), et Les serveurs web auraient leur configuration de session à tirer d'un troisième serveur dédié à l'hébergement de session OutOfProc ASP.NET.

Pour déployer un site, nous retirons l'un des serveurs de l'équilibreur de charge, mettons à jour les fichiers, redémarrez-le et replacez-le dans le pool d'équilibrage de charge. Répétez pour le reste des serveurs Web. Étant donné que chaque serveur Web a reçu les données de session du serveur central, en supprimant un serveur Web, il n'a pas déconnecté les utilisateurs de ce serveur.

Si des modifications de code étaient incompatibles avec les données de session existantes, nous attendrions une fenêtre de maintenance planifiée à déployer. Sinon, les utilisateurs ayant ces données de session recevraient des erreurs jusqu'à ce qu'ils se soient déconnectés.

De plus, étant donné que cette configuration repose sur la mise en place du serveur Web, si vous souhaitez augmenter la fiabilité, vous pouvez remplacer les serveurs de session basés sur OutOfProc par SQL. Vous auriez besoin de plusieurs serveurs qui répliquent la même base de données de session et pointent les serveurs Web vers eux. Plus compliqué, mais permettrait de réduire les temps d'arrêt du site.