Recomendación de arquitectura para el sitio ASP.NET con carga equilibrada

Question

ACTUALIZACIÓN 2009-05-21

He estado probando el método # 2 de usar un solo recurso compartido de red. Está causando algunos problemas con Windows Server 2003 bajo carga:

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

finalizar actualización

He recibido una propuesta para un sitio web ASP.NET que funciona de la siguiente manera:

Balanceador de carga de hardware - > 4 servidores web IIS6 - > Base de datos de SQL Server con clúster de conmutación por error

Aquí está el problema ...

Estamos eligiendo dónde almacenar los archivos web (aspx, html, css, images). Se han propuesto dos opciones:

1) Cree copias idénticas de los archivos web en cada uno de los 4 servidores IIS.

2) Coloque una única copia de los archivos web en un recurso compartido de red accesible por los 4 servidores web. Las raíces web en los 4 servidores IIS se asignarán al recurso compartido de red único.

¿Cuál es la mejor solución? La opción 2 obviamente es más simple para las implementaciones, ya que requiere copiar archivos a una sola ubicación. Sin embargo, me pregunto si habrá problemas de escalabilidad ya que cuatro servidores web están accediendo a un solo conjunto de archivos. ¿IIS almacenará estos archivos en caché localmente? ¿Golpearía la red compartida en cada solicitud de cliente? Además, ¿el acceso a un recurso compartido de red siempre será más lento que obtener un archivo en un disco duro local? ¿La carga en la red compartida empeora considerablemente si se agregan más servidores IIS?

Para dar perspectiva, esto es para un sitio web que actualmente recibe ~ 20 millones de visitas por mes. En el pico más reciente, estaba recibiendo alrededor de 200 visitas por segundo.

Avíseme si tiene una experiencia particular con dicha configuración. Gracias por la entrada.

ACTUALIZACIÓN 2009-03-05

Para aclarar mi situación: las "implementaciones" en este sistema son mucho más frecuentes que una aplicación web típica. El sitio web es el front-end para un CMS de back office. Cada vez que se publica contenido en el CMS, las páginas nuevas (aspx, html, etc.) se envían automáticamente al sitio en vivo. Los despliegues son básicamente "a pedido". Teóricamente, este impulso podría ocurrir varias veces en un minuto o más. Por lo tanto, no estoy seguro de que sea práctico implementar un servidor web a la vez. Pensamientos?

Answer 1

Yo compartiría la carga entre los 4 servidores. No son tantos.

No desea ese único punto de contención al implementar ni ese único punto de falla en la producción.

Al desplegar, puedes hacerlos 1 a la vez. Sus herramientas de implementación deben automatizar esto notificando al equilibrador de carga que no debe usarse el servidor, implementando el código, cualquier trabajo de precompilación necesario y, finalmente, notificando al equilibrador de carga que el servidor está listo.

Utilizamos esta estrategia en una granja de servidores web de más de 200 y funcionó muy bien para la implementación sin interrupción del servicio.

Answer 2

Si su principal preocupación es el rendimiento, que supongo que es porque está gastando todo este dinero en hardware, entonces no tiene sentido compartir un sistema de archivos de red solo por conveniencia. Incluso si las unidades de red tienen un rendimiento extremadamente alto, no funcionarán tan bien como las unidades nativas.

La implementación de sus activos web está automatizada de todos modos (¿verdad?), por lo que hacerlo en múltiples no es realmente un inconveniente.

Si es más complicado de lo que estás dejando, tal vez algo como DeltaCopy sería útil para mantener esos discos sincronizados.

Answer 3

Una razón por la cual el recurso compartido central es malo es porque hace que la NIC en el servidor compartido sea el cuello de botella para toda la granja y crea un único punto de falla.

Answer 4

Con IIS6 y 7, se admite explícitamente el escenario de uso de un recurso compartido de red único en N máquinas web / servidor de aplicaciones conectadas. MS hizo un montón de pruebas de rendimiento para asegurarse de que este escenario funcionara bien. Sí, se usa el almacenamiento en caché. Con un servidor NIC dual, uno para Internet público y otro para la red privada, obtendrá un rendimiento realmente bueno. El despliegue es a prueba de balas.

Vale la pena tomarse el tiempo para compararlo.

También puede evaluar un proveedor de ruta virtual ASP.NET, que le permitiría implementar un solo archivo ZIP para toda la aplicación. O, con un CMS, puede servir contenido directamente desde una base de datos de contenido, en lugar de un sistema de archivos. Esto presenta algunas opciones realmente buenas para el control de versiones.

VPP para ZIP a través de #ZipLib .

VPP para ZIP a través de DotNetZip .

Answer 5

En una situación ideal de alta disponibilidad, no debería haber un único punto de falla.

Eso significa que un solo cuadro con las páginas web en él es un no-no. Después de haber realizado un trabajo de HA para una empresa de telecomunicaciones importante, inicialmente propondría lo siguiente:

• Cada uno de los cuatro servidores tiene su propia copia de los datos.
• En un momento de silencio, desconecte dos de los servidores (es decir, modifique el equilibrador HA para eliminarlos).
• Actualice los dos servidores fuera de línea.
• Modifique el equilibrador HA para comenzar a utilizar los dos servidores nuevos y no los dos servidores antiguos.
• Prueba eso para asegurar la corrección.
• Actualice los otros dos servidores y luego póngalos en línea.

Así es como puedes hacerlo sin hardware adicional. En el mundo anal-retentivo de Telco para el que trabajé, esto es lo que hubiéramos hecho:

• Hubiéramos tenido ocho servidores (en ese momento, teníamos más dinero del que podrías meter). Cuando llegara el momento de la transición, los cuatro servidores sin conexión se configurarían con los nuevos datos.
• Luego, el equilibrador HA se modificaría para usar los cuatro servidores nuevos y dejaría de usar los servidores antiguos. Esto hizo que la conmutación (y, lo que es más importante, la conmutación hacia atrás si rellenamos) un proceso muy rápido e indoloro.
• Solo cuando los nuevos servidores se hayan estado ejecutando por un tiempo, consideraremos el siguiente cambio. Hasta ese momento, los cuatro servidores antiguos se mantenían fuera de línea pero listos, por si acaso.
• Para obtener el mismo efecto con menos desembolso financiero, podría tener discos adicionales en lugar de servidores adicionales completos. La recuperación no sería tan rápida ya que tendrías que apagar un servidor para volver a colocar el disco viejo, pero aún así sería más rápido que una operación de restauración.

Answer 6

Estaba a cargo del desarrollo de un sitio web de juegos que tenía 60 millones de visitas al mes. La forma en que lo hicimos fue la opción # 1. El usuario tenía la capacidad de cargar imágenes y demás, y se colocaron en un NAS que se compartió entre los servidores. Funcionó bastante bien. Supongo que también está haciendo el almacenamiento en caché de la página, etc., en el lado de la aplicación de la casa. También desplegaría bajo demanda, las nuevas páginas a todos los servidores simultáneamente.

Answer 7

Lo que gana en NLB con el 4IIS lo pierde con el BottleNeck con el servidor de aplicaciones.

Para la escalabilidad, recomendaré las aplicaciones en los servidores web front-end.

Aquí en mi empresa estamos implementando esa solución. La aplicación .NET en el front-end y un servidor de aplicaciones para Sharepoint + un clúster SQL 2008.

Espero que ayude!

saludos!

Answer 8

Tenemos una situación similar a usted y nuestra solución es utilizar un modelo de editor / suscriptor. Nuestra aplicación CMS almacena los archivos reales en una base de datos y notifica a un servicio de publicación cuando un archivo ha sido creado o actualizado. Este editor luego notifica a todas las aplicaciones web suscritas y luego van y obtienen el archivo de la base de datos y lo colocan en sus sistemas de archivos.

Tenemos a los suscriptores configurados en un archivo de configuración en el editor, pero usted puede ir por completo y hacer que la aplicación web se suscriba al inicio de la aplicación para que sea aún más fácil de administrar.

Puede usar un UNC para el almacenamiento, elegimos una base de datos por conveniencia y portabilidad entre entornos de producción y prueba (simplemente copiamos la base de datos y tenemos todos los archivos del sitio en vivo, así como los datos).

Answer 9

Un método muy simple de implementación en múltiples servidores (una vez que los nodos están configurados correctamente) es usar robocopy.

Preferiblemente tendría un pequeño servidor de ensayo para realizar pruebas y luego 'robocopy' a todos los servidores de implementación (en lugar de utilizar un recurso compartido de red).

robocopy está incluido en MS ResourceKit : utilícelo con el modificador / MIR.

Answer 10

Para pensar un poco, podría mirar algo como Microsoft Live Mesh . No estoy diciendo que sea la respuesta para usted, pero el modelo de almacenamiento que utiliza puede ser.

Con Mesh, descarga un pequeño servicio de Windows en cada máquina de Windows que desee en su Mesh y luego nomina carpetas en su sistema que forman parte de la malla. Cuando copia un archivo en una carpeta de Live Mesh, que es exactamente la misma operación que copiar a cualquier otro foler en su sistema, el servicio se encarga de sincronizar ese archivo con todos sus otros dispositivos participantes.

Como ejemplo, guardo todos mis archivos fuente de código en una carpeta Mesh y los sincronizo entre el trabajo y el hogar. No tengo que hacer nada para mantenerlos sincronizados, la acción de guardar un archivo en VS.Net, el bloc de notas o cualquier otra aplicación inicia la actualización.

Si tiene un sitio web con archivos que cambian con frecuencia que necesitan ir a varios servidores, y presumiblemente múltiples autores para esos cambios, entonces podría poner el servicio Mesh en cada servidor web y, a medida que los autores agregan, cambian o eliminan archivos, las actualizaciones serían empujadas automáticamente. En lo que respecta a los autores, solo guardarían sus archivos en una carpeta antigua normal en su computadora.

Answer 11

Utilice una herramienta de implementación, con un proceso que se implementa de uno en uno y el resto del sistema sigue funcionando (como dijo Mufaka). Este es un proceso probado que funcionará tanto con los archivos de contenido como con cualquier parte compilada de la aplicación (cuya implementación provoca un reciclaje del proceso asp.net).

Con respecto a la tasa de actualizaciones , esto es algo que puedes controlar. Haga que las actualizaciones pasen por una cola y tenga un único proceso de implementación que controle cuándo implementar cada elemento. Tenga en cuenta que esto no significa que procese cada actualización por separado, ya que puede tomar las actualizaciones actuales en la cola e implementarlas juntas. Las nuevas actualizaciones llegarán a la cola y se recogerán una vez que finalice el conjunto actual de actualizaciones.

Actualización: sobre las preguntas en el comentario. Esta es una solución personalizada basada en mi experiencia con procesos pesados ??/ largos que necesita controlar su tasa de actualizaciones. No he tenido la necesidad de usar este enfoque para los escenarios de implementación, ya que, para ese contenido dinámico, generalmente utilizo una combinación de DB y caché en diferentes niveles.

La cola no necesita contener toda la información, solo necesita tener la información adecuada (id / rutas) que permitirá que su proceso pase la información para comenzar el proceso de publicación con una herramienta externa. Como es un código personalizado, puede hacer que se una a la información que se va a publicar, para que no tenga que lidiar con eso en el proceso de publicación / herramienta.

Los cambios en la base de datos se realizarían durante el proceso de publicación, nuevamente, solo necesita saber dónde está la información para los cambios necesarios y dejar que el proceso de publicación / herramienta lo maneje. Con respecto a qué usar para la cola, los principales que he usado son msmq y una implementación personalizada con información en el servidor SQL. La cola está justo ahí para controlar la velocidad de las actualizaciones, por lo que no necesita nada especialmente dirigido a las implementaciones.

Actualización 2: asegúrese de que los cambios en su base de datos sean compatibles con versiones anteriores. Esto es realmente importante, cuando está enviando cambios en vivo a diferentes servidores.

Answer 12

Suponiendo que sus servidores IIS ejecutan Windows Server 2003 R2 o superior, definitivamente investigue Replicación DFS . Cada servidor tiene su propia copia de los archivos, lo que elimina un cuello de botella en la red compartida, como muchos otros han advertido. La implementación es tan simple como copiar sus cambios a cualquiera de los servidores en el grupo de replicación (asumiendo una topología de malla completa). La replicación se encarga del resto automáticamente, incluyendo el uso de la compresión diferencial remota para enviar solo los deltas de archivos que han cambiado.

Answer 13

Estamos muy contentos de usar 4 servidores web, cada uno con una copia local de las páginas y un servidor SQL con un clúster de conmutación por error.