¿Cómo equilibrar la carga de SQL Server 2008 para aplicaciones ASP.NET de alto uso?

Imagine que tiene una aplicación web exitosa que usa ASP.NET e IIS 7. Genera muchas llamadas a una base de datos de SQL Server 2008 y se espera que esté disponible al público con un tiempo de actividad del 99.9% (tiempo de inactividad de 8 horas, 45 minutos por año).

Nuestros objetivos son:

• Instalar actualizaciones de Windows en el servidor sin causar tiempo de inactividad a nuestros clientes
• Evite que los bloqueos de hardware en el servidor ralenticen las aplicaciones ASP.NET debido a los tiempos de espera

A diferencia del equilibrio de carga de una aplicación ASP.NET, el SQL de equilibrio de carga parece ser mucho más difícil. ¿Cuáles son sus mejores prácticas para configurar un clúster simple de SQL Server 2008 R2 con equilibrio de carga para un Micro-ISV que utiliza la pila de Microsoft?

Si necesita alta disponibilidad, entonces Windows / SQL Server Clustering o SQL Server Database Mirroring ofrecen soluciones. La agrupación en clúster requiere mucha planificación y familiarización si nunca lo ha hecho antes, pero será transparente para la aplicación.

El equilibrio de carga es posible con SQL Server, pero no es para corazones débiles. Es una solución que utiliza Windows Network Load Balancing (NLB) frente a los servidores SQL. Los servidores SQL en el NLB son más fáciles de administrar si son de solo lectura, pero pueden ser de lectura y escritura si usa la replicación transaccional con suscriptores actualizables. Sin embargo, este tipo de replicación está marcado por desuso en una versión futura.

Una última posibilidad son las Bases de datos compartidas escalables, pero definitivamente son de solo lectura.

Más lectura:

Eche un vistazo a los libros Apress de Allan Hirt sobre la alta disponibilidad de SQL Server 2005 y la replicación Pro SQL Server 2005/2008 de Apress.

Bases de datos compartidas escalables: http://technet.microsoft.com/en-us/library/ms345392.aspx

Los sistemas de bases de datos relacionales rara vez tienen un equilibrio de carga de la misma manera que los servidores web. El problema con el enfoque clásico para el equilibrio de carga es que todas sus bases de datos deben estar en sincronización constante. El modelo relacional no tiene valor si dos servidores no tienen un estado idéntico en algún momento.

Según su pregunta, parece que ni siquiera está tratando de lograr un equilibrio de carga, que es principalmente una medida de rendimiento para garantizar que solo tantos usuarios lleguen a cada servidor como ese servidor pueda manejar. Parece que quieres una configuración de alta disponibilidad . Como usted dice que está utilizando SQL Server, buscaría failovers. Esto significa que, si la base de datos primaria no está disponible, los clientes intentarán acceder a los servidores de conmutación por error. SQL Server se encarga de mantener sincronizada la instancia primaria y cada conmutación por error y también se encarga de resincronizar la instancia primaria a la conmutación por error cuando el primario vuelve a estar en línea de estar fuera de línea.

OK aquí vamos. NO SE PUEDE HACER. No sin cambios de aplicación.

• Instale actualizaciones: use la agrupación en clúster o la duplicación para asegurarse de tener DOS bases de datos que funcionen o puedan conmutar por error a otra computadora más rápido. Duplicar fuertemente preferido.
• Vuelva a escribir la aplicación para manejar eso (es decir, fallas en las conexiones, debe volver a conectarse de manera transparente para que luego se conecte a una copia).

Tenga en cuenta que todavía necesita quitar la aplicación por mantenimiento cuando implemente una nueva copia / realice cambios en el esquema de base de datos.

Una respuesta rentable aquí es a menudo proteger la base de datos con servicios de aplicaciones de alojamiento de nivel de servidor equilibrados y baratos que proporcionan procesamiento lógico y almacenamiento de datos que de otro modo estarían atando los recursos de la base de datos. Obviamente, esto requiere pensar en la volatilidad de los datos y las estrategias de almacenamiento en caché.

Déjame darte una respuesta jurásica. Si sus objetivos incluyen "instalar actualizaciones de Windows" está más allá del rescate.

Tengo la barba gris y puedo recordar un momento en que una aplicación podría ejecutarse 10 años sin tener que sufrir "actualizaciones del sistema operativo". La vida útil de una aplicación se midió en décadas, no en años.

Así que mi consejo es el siguiente: establezca una versión funcional de su base de datos + aplicación de SQL Server, y AISLE EL SERVIDOR DE BASES DE DATOS DE LAS ACTUALIZACIONES DE MICROSOFT. Si no está roto, no lo arregles.

Utilice discos RAID intercambiables en caliente.

Tenga a mano un servidor de base de datos de imágenes espejo (por sugerencia de TomTom) en caso de que su hardware se dañe.