martes, 2 de noviembre de 2010

Web Garden vs Web Farm

Hola… lo reconozco! yo tampoco sabía cual era la diferencia entre ambos!

Es por ello y para que puede volver yo mismo a mi blog cuando proceda para refrescar este concepto que voy a intentar explicar las diferencias entre ambas opciones.

Lo primero y más obvio es ¿Por qué quiero Web Garden o Web Farm?.

Está claro que ambos escenarios persiguen esencialmente el mismo concepto: garantizar la disponibilidad y escalabilidad de nuestra aplicación web.

Web garden (jardín web) es “una sola máquina ejecutando varios worker proccess para una misma instancia de aplicación web”.

Web farm (granja web) es “dos o más máquinas dando solicitud a una misma instancia de aplicación web”.

Web garden.

  • Un web garden es un escenario multi-procesador donde se balancea la carga de la aplicación entre distintos procesadores de una misma máquina.
  • Lógicamente, para levantar este tipo de escenario la máquina debe tener varios procesadores. Además cada worker proccess crea afinidad con un procesador y es el propio Windows quién gestiona el balanceo entre los worker proccess.
  • Un web garden no debería ser utilizado si nuestra aplicación hace un uso intensivo de CPU puesto que la aparente mejora incurriría en un cuello de botella al no poder Windows balancear el trabajo entre los distintos worker proccess.
  • En un web garden la sesión de ASP.NET no puede ser InProc porque este proveedor guarda la sesión en memoria y cada worker proccess tiene su propio espacio de memoria, su propio AppDomain, etc. De hecho tampoco puede compartirse Application ni Cache.

Web farm.

  • Un web farm es un escenario multi-servidor donde se balancea la carga de la aplicación entre distintos servidores.
  • En un web farm la sesión de ASP.NET no puede ser InProc porque este proveedor guarda la sesión en memoria y entonces distintas peticiones procesadas en distintas máquinas no devolverían el mismo estado de sesión para el usuario. De este modo, tenemos que elegir SessionState o SqlServer. De igual modo, tampoco Application ni Cache son un método válido para compartir datos.
  • Las distintas máquinas involucradas en este escenario tiene que tener el mismo valor para el elemento machineKey en los ficheros machinge.config o web.config. Esto sirve para que lo que una máquina codifique o valide, cualquier otra máquina de su escenario sepa validar o descodificar (por ejemplo se codifica el ViewState). Más información al respecto en http://blogs.msdn.com/b/rich_crane/archive/2004/05/12/130693.aspx
  • Todos los servidores son expuestos al exterior con una única dirección IP que es virtual y que después y según el tipo de balanceo implementado redirige la petición al servidor adecuado.
  • Un web farm puede ser implementado bien para optimizar la escalabilidad (todos los servidores sirven peticiones) bien para garantizar la disponibilidad (un servidor entra en caso de que otra se caiga, a esto se le llama redundancia o tolerancia a fallos).

Un saludo!.

1 comentario:

  1. Gracias por compartirnos esta diferencia de conceptos. Muy claro y fácil de entender. Saludos!!

    ResponderEliminar