Siete problemas comunes al desplegar una Web Farm de IIS

Cada vez es más habitual tener una Web Farm para alojar aplicaciones web. Una Web Farm es una entidad formada por un grupo de servidores que proporciona uno o varios servicios de tal modo que tú accedes al servicio de la Web Farm y no al alojado en los nodos. Esto proporciona una gran escalabilidad permitiendo añadir servidores cuando haya una carga alta de trabajo o incluso, hacer transparente al usuario que uno de los servidores deje de dar servicio. Por ello debemos igualar el contenido y el funcionamiento de las aplicaciones en cada uno de los nodos.

En el mundo en el que vivimos suele ser la parte más compleja porque solemos tender a ir montando las cosas sobre la marcha. Esto puede hacer que nuestra granja funcione bien al principio, pero según vaya siendo más compleja o vaya creciendo se vaya volviendo inestable.

Antes de continuar, tengamos en cuenta que una Web Farm no tiene nada que ver con Web Gardening (¿Qué es el Web Garden y cuándo debo utilizarlo?)

1. Autenticación

Por ello debemos pensar en primer lugar cómo se van a autenticar a la aplicación (ya hablé de eso en este artículo ¿Qué modo de autenticación debo utilizar?).

En el caso de que usemos Kerberos, deberemos utilizar el mismo usuario de dominio como Identidad de todos los Application Pools (tenéis más información en este artículo https://blogs.msdn.com/b/desarrolloweb/archive/2012/07/26/kerberos-con-iis.aspx).

2. Identidad del Application Pool

Aunque sólo debería ser obligatorio en el caso de que se utilice la autenticación de Kerberos, lo recomendado es utilizar el mismo usuario para todos los nodos, ya que así conseguiremos que la aplicación se ejecute en las mismas condiciones en todos los nodos.

Tened en cuenta que las Identidades por defecto del IIS son cuentas locales, por lo que serán diferentes en cada nodo y como hemos comentado antes, nuestro objetivo es que las aplicaciones se ejecuten de la misma forma. Por lo que deberíamos utilizar siempre el mismo usuario de dominio en todos los nodos.

Si en nuestro caso la Web Farm no está en dominio podemos crear un usuario local en cada nodo con el mismo nombre y clave. Aunque realmente no va a funcionar igual que el usar el mismo usuario de dominio, es una alternativa fácil y eficaz.

3. Estado de sesión de ASP.NET

Cada petición que se realiza mediante HTTP se trata de manera independiente, por lo que el servidor no sabe qué operaciones has realizado o qué datos has obtenido. Por ello podemos guardar los datos en sesiones de ASP.NET.

Estos son los diferentes modos que podemos utilizar:

• In-Proc: La sesión está en el propio proceso por lo que no se comparte. Tenemos que tener en cuenta que si queremos que se puede atender a un mismo usuario en diferentes nodos NO podemos utilizar este modo.
• SessionState Server: En este caso, los datos de las sesiones se almacenan en un proceso a parte y pueden ser accedidos por todos los nodos de la granja.
• SQL Server: Obviamente este modo almacena los datos de la sesión en una base de datos de SQL Server.

Todos los modos tienen sus cosas buenas y sus cosas malas, hay que elegir el que mejor se adapte a nuestras necesidades. Aunque por lo que hemos comentado antes, deberíamos descartar el modo In-Proc ya que no permite esa escalabilidad de la que hablábamos antes.

Os dejo más información en este artículo https://msdn.microsoft.com/es-es/library/ms178586(v=vs.100).aspx

4. Identificador de la aplicación

Otro detalle que tenemos que tener en cuenta es el Identificador de la aplicación, que debe ser el mismo en todos los nodos. El tener diferentes identificadores para una misma aplicación puede hacer que el SQL Server Session State no funcione porque en las tablas almacena el identificador de la aplicación.

5. Machine Keys

Ya hemos hablado de las sesiones, ahora es el turno de las cookies y de cómo se cifran.

Pues se cifran usando las claves de las Machine Keys, por lo que también deben ser iguales en todos los nodos.

6. Actualizaciones

Algo que parece obvio pero que no es fácil de mantener es el que todas las máquinas mantengan el mismo nivel de actualizaciones. Hay actualizaciones críticas que cambian el funcionamiento interno del IIS o de ASP.NET y pueden hacer que la granja no funcione. Aquí os dejo un ejemplo de lo que puede ocurrir si los servidores no están igual de actualizados: Web Farm, ¿por qué deja de funcionar la aplicación cuando se añade un nodo nuevo?

Podemos utilizar herramientas como esta Microsoft Baseline Security Analyzer para ayudarnos a mantener el nivel de actualizaciones.

7. Configuración Compartida

Un problema muy común es el creer que la configuración de los IIS y de sus aplicaciones es la misma en cada nodo. En la vida real es muy difícil ir actualizando cada nodo de manera que todos sean iguales. A partir de IIS 7.0 podemos utilizar la Configuración Compartida que nos permite el tener un sólo fichero de configuración para todos los equipos. Cada cambio en la configuración se irá replicando en el resto de los nodos de forma automática.

 

Cómo veis, la idea general que se repite una y otra vez es lo que hemos comentado al principio. Las aplicaciones de cada nodo deben de ser iguales y funcionar de la misma forma, porque eso es lo que tratamos de buscar con una Web Farm al abstraernos de los nodos y pensar en un servicio que lo pueden dar x o x+2 servidores.

Espero que os sirva de ayuda.

- José Ortega Gutiérrez