Comment équilibrer la charge de SQL Server 2008 pour les applications ASP.NET à haute utilisation?

Imaginez que votre application Web réussie utilise ASP.NET et IIS 7. Elle génère de nombreux appels vers une base de données SQL Server 2008 et devrait être accessible au public avec un temps de disponibilité de 99,9% (temps d'arrêt de 8 heures, 45 minutes par année).

Nos objectifs sont:

• Installez les mises à jour Windows sur le serveur sans provoquer de temps d'arrêt pour nos clients
• Empêcher les pannes matérielles sur le serveur de ralentir les applications ASP.NET en raison de délais d'attente

Contrairement à l'équilibrage de charge d'une application ASP.NET, l'équilibrage de charge SQL semble être beaucoup plus difficile. Quelles sont vos meilleures pratiques pour configurer un cluster SQL Server 2008 R2 à équilibrage de charge simple pour un Micro-ISV qui utilise la pile Microsoft?

Si vous avez besoin d'une haute disponibilité, le clustering Windows / SQL Server ou la mise en miroir de bases de données SQL Server offrent des solutions. Le clustering nécessite beaucoup de planification et de familiarisation si vous ne l'avez jamais fait auparavant, mais il sera transparent pour l'application.

L'équilibrage de charge est possible avec SQL Server, mais ce n'est pas pour les timides. Il s'agit d'une solution qui utilise l'équilibrage de la charge réseau Windows (NLB) devant les serveurs SQL. Les serveurs SQL eux-mêmes dans le NLB sont plus faciles à gérer s'ils sont en lecture seule, mais ils peuvent être en lecture-écriture si vous utilisez la réplication transactionnelle avec des abonnés pouvant être mis à jour. Ce type de réplication est cependant marqué pour dépréciation dans une future version.

Une dernière possibilité est les bases de données partagées évolutives, mais elles sont définitivement en lecture seule.

Plus de lecture:

Jetez un œil aux livres Apress d'Allan Hirt sur la haute disponibilité SQL Server 2005 et la réplication Pro SQL Server 2005/2008 d'Apress.

Bases de données partagées évolutives: http://technet.microsoft.com/en-us/library/ms345392.aspx

Les systèmes de bases de données relationnelles sont rarement à charge équilibrée de la même manière que les serveurs Web. Le problème avec l'approche classique de l'équilibrage de charge est que toutes vos bases de données doivent être en synchronisation constante. Le modèle relationnel ne vaut rien si deux serveurs n'ont à aucun moment un état identique.

D'après votre question, il ne semble pas que vous essayiez même de réaliser l'équilibrage de charge, qui est principalement une mesure de performance pour garantir que seul autant d'utilisateurs atteignent chaque serveur que ce serveur peut gérer. Il semble que vous souhaitiez une configuration à haute disponibilité . Puisque vous dites que vous utilisez SQL Server, j'examinerais les basculements. Cela signifie que, si la base de données principale n'est pas disponible, les clients tenteront d'accéder aux serveurs de basculement. SQL Server gère la synchronisation de l'instance principale et de chaque basculement et gère également la resynchronisation de l'instance principale avec le basculement lorsque le principal revient en ligne après être hors ligne.

OK allons y. NE PEUT PAS ÊTRE FAIT. Pas sans changements d'application.

• Installez les mises à jour - utilisez le clustering ou la mise en miroir pour vous assurer que vous disposez de DEUX bases de données qui fonctionnent ou peuvent basculer sur un autre ordinateur plus rapidement. La mise en miroir est fortement préférée.
• Réécrivez l'application pour gérer cela (c'est-à-dire que les connexions échouent, doit se reconnecter de manière transparente pour se connecter ensuite à une copie).

Sachez que vous devez toujours supprimer l'application pour la maintenance lorsque vous déployez une nouvelle copie / apportez des modifications au schéma db.

Une réponse rentable ici est assez souvent de tamponner la base de données avec des services d'application d'hébergement de niveau serveur à bas prix et équilibrés qui fournissent un traitement logique et un stockage de données qui autrement bloqueraient les ressources de la base de données. Évidemment, cela nécessite une réflexion sur la volatilité des données et les stratégies de mise en cache.

Permettez-moi de vous donner une réponse jurassique. Si vos objectifs incluent "installer les mises à jour Windows", vous êtes au-delà du sauvetage.

J'ai la barbe grise et je me souviens d'un moment où une application pouvait fonctionner pendant 10 ans sans avoir à subir de "mises à jour du système d'exploitation". La durée de vie utile d'une application a été mesurée en décennies et non en années.

Donc, mon conseil est le suivant: établir une version de travail de votre base de données + application SQL Server et ISOLER LE SERVEUR DE BASE DE DONNÉES DES MISES À JOUR MICROSOFT. S'il n'est pas cassé, ne le réparez pas.

Utilisez des disques RAID remplaçables à chaud.

Ayez un serveur de base de données d'images miroir (selon la suggestion de TomTom) à portée de main au cas où votre matériel craquerait.