recomendación Arquitectura para la carga equilibrada sitio ASP.NET

Question

ACTUALIZACIÓN 2009-05-21

He estado probando el método # 2 de la utilización de un único recurso compartido de red. Se está dando lugar a algunos problemas con Windows Server 2003 bajo carga:

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

actualización final

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

Hardware load-balancer -> 4 servidores web IIS6 -> SQL Server DB 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 sola copia de los archivos web en un recurso compartido de red accesible por los 4 servidores web. Los webroots 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 en 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. ¿Caché IIS estos archivos localmente? ¿Golpearía la red compartida en cada solicitud del cliente? Además, ¿el acceso a una red compartida siempre será más lento que obtener un archivo en un disco duro local? ¿La carga en el recurso compartido de red empeora sustancialmente si se agregan más servidores IIS?

Para dar una perspectiva, esto es para un sitio web que actualmente recibe ~ 20 millones de visitas por mes. En el pico reciente, recibía alrededor de 200 visitas por segundo.

Háganme saber si tiene experiencia particular con dicha configuración. Gracias por el aporte.

ACTUALIZACIÓN 2009-03-05

Para aclarar mi situación - los "despliegues" en este sistema son mucho más frecuentes de lo 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. Las implementaciones son básicamente "a pedido". Teóricamente, este empuje podría ocurrir varias veces en un minuto o más. Así que no estoy seguro de que sea práctico implementar un servidor web a la vez. ¿Pensamientos?

Answer 1

Compartí la carga entre los 4 servidores. No son tantos.

No desea ese único punto de contención ni cuando se despliega ni ese único punto de falla en la producción.

Al implementar, puede hacerlas de a una por vez. Sus herramientas de implementación deberían automatizar esto notificando al equilibrador de carga que no se debe usar 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, lo cual supongo que es porque está gastando todo este dinero en hardware, entonces realmente 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 (¿no?) Por lo que hacerlo en múltiplos no es realmente una gran molestia.

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

Answer 3

Una de las razones por las cuales la compartición central es mala 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

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 la parte frontal y un servidor de APP para Sharepoint + un clúster de SQL 2008.

Espero que ayude!

respetos!

Answer 5

Utilice una herramienta de implementación, con un proceso que se implementa de a uno por vez 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 (que implementar causa un reciclaje del proceso asp.net).

En cuanto a la tasa de actualizaciones esto es algo que puede controlar. Haga que las actualizaciones pasen por una cola, y tenga un único proceso de implementación que controle cuándo desplegar cada elemento. Tenga en cuenta que esto no significa que procesa cada actualización por separado, ya que puede tomar las actualizaciones actuales en la cola e implementarlas juntas. Más actualizaciones llegarán a la cola, y serán recogidas una vez que el conjunto actual de actualizaciones haya terminado.

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

No es necesario que la cola contenga toda la información, solo necesita tener la información adecuada (ids/paths) que le permita a su proceso pasar 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 publicará, para que no tenga que lidiar con eso en el proceso/herramienta de publicación.

Los cambios en la base de datos se realizarían durante el proceso de publicación, de nuevo solo necesita saber dónde está la información para los cambios necesarios y dejar que el proceso de publicación/herramienta lo maneje. En cuanto a qué usar para la cola, los principales que he utilizado es msmq y una implementación personalizada con información en el servidor sql. La cola está 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 sus cambios en la base de datos sean retrocompatibles. Esto es realmente importante cuando está impulsando cambios en vivo a diferentes servidores.

Answer 6

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 se ha creado o actualizado un archivo. Luego, este editor notifica a todas las aplicaciones web que se suscriben y luego obtienen el archivo de la base de datos y lo colocan en sus sistemas de archivos.

Tenemos los suscriptores configurados en un archivo de configuración en el editor, pero usted podría irse por completo y hacer que la aplicación web haga la suscripción 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 un DB por comodidad y portabilidad entre entornos de producción y prueba (simplemente copiamos el DB y tenemos todos los archivos del sitio en vivo, así como los datos).

Answer 7

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

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

robocopy está incluido en el MS ResourceKit - úselo con el modificador/MIR.

Answer 8

Para darle algo de reflexión, podría ver algo como Microsoft's Live Mesh . No digo que sea la respuesta para usted, pero el modelo de almacenamiento que utiliza puede ser.

Con la malla descarga un pequeño servicio de Windows en cada máquina con Windows que desee en su malla y luego designa las carpetas en su sistema que son parte de la malla. Cuando copias un archivo en una carpeta de Live Mesh, que es exactamente la misma operación que para copiar en cualquier otro dispositivo de tu sistema, el servicio se encarga de sincronizar ese archivo con todos tus otros dispositivos participantes.

Como ejemplo, conservo todos mis archivos fuente de código en una carpeta de malla 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 frecuentemente que necesitan ir a varios servidores, y presumiblemente múltiples autores para esos cambios, puede poner el servicio Mesh en cada servidor web y como autores agregaron, cambiaron o eliminaron archivos las actualizaciones se enviarán automáticamente. En lo que respecta a los autores, guardarían sus archivos en una carpeta antigua normal en su computadora.

Answer 9

Con IIS6 y 7, se admite explícitamente el escenario de utilizar una red compartida única en N máquinas de servidor web/de aplicaciones. MS hizo una tonelada de pruebas de perforación para asegurarse de que este escenario funcione bien. Sí, se usa el almacenamiento en caché. Con un servidor dual NIC, uno para Internet pública 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 evaluarlo.

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 bien, con un CMS, podría servir contenido directamente desde una base de datos de contenido, en lugar de un sistema de archivos. Esto presenta algunas opciones realmente agradables para versionar.

VPP For ZIP via #ZipLib.

VPP for ZIP via DotNetZip.

Answer 10

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

Answer 11

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 sí tenía la capacidad de cargar imágenes y esas y esas se colocaron en un NAS compartido entre los servidores. Funcionó bastante bien. Supongo que también está haciendo el almacenamiento en caché de la página y demás, en el lado de la aplicación de la casa. También implementaría bajo demanda, las nuevas páginas a todos los servidores simultáneamente.

Answer 12

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

Eso significa que una sola caja con las páginas web es un no-no. Una vez hecho el trabajo HA para una importante empresa de telecomunicaciones, inicialmente propongo lo siguiente:

• Cada uno de los cuatro servidores tiene su propia copia de los datos.
• En un momento de tranquilidad, 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 usar los dos servidores nuevos y no los dos servidores antiguos.
• Pon a prueba que para garantizar la corrección.
• Actualiza los otros dos servidores y ponlos en línea.

Así es como puede hacerlo sin hardware adicional. En el mundo anal retentivo de la compañía telefónica que trabajaba, esto es lo que habría hecho:

• Nos hubiera tenido ocho servidores (en el momento, que tenían más dinero que usted podría meter un palo). Cuando llegó el momento de la transición, los cuatro servidores fuera de línea se configurarían con los nuevos datos.
• Luego, el equilibrador de HA se modificará para usar los cuatro servidores nuevos y dejar de usar los servidores antiguos. Esto hizo que el cambio (y, lo que es más importante, la conmutación de retorno si se llena) un proceso muy rápido e indoloro.
• Solo cuando los nuevos servidores estuvieron en funcionamiento durante un tiempo consideraremos la siguiente conmutación. Hasta ese momento, los cuatro servidores antiguos se mantuvieron fuera de línea pero listos, por las dudas.
• Para obtener el mismo efecto con menos gasto financiero, puede tener discos adicionales en lugar de servidores adicionales completos. La recuperación no sería tan rápida, ya que tendría que apagar un servidor para volver a colocar el disco anterior, pero aún sería más rápido que una operación de restauración.

Answer 13

Estamos muy contentos de utilizar 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.