Aislamiento de aplicaciones en IIS 8.x en entornos de hosting
En entornos de hosting o cuando se alojan en IIS diversas aplicaciones sobre las que no se tiene control directo, la mayor prioridad desde un punto de vista de administración y arquitectura es que un posible problema en una de las aplicaciones tenga el menor impacto posible en el resto de aplicaciones que se alojan en el mismo servidor.
IIS favorece este aislamiento dado que cada sitio web se ejecuta en un proceso separado de forma predeterminada, lo cual es un buen comienzo. Sin embargo, existen ciertos recursos a nivel de sistema operativo que son compartidos por todos los procesos, como puede ser la memoria física, el procesador o el ancho de banda de red. Si un proceso dispara su consumo de CPU al 100% por cualquier motivo, esto va a tener un impacto en el rendimiento de todo el resto de procesos de la máquina. El mismo impacto podría tener que un proceso que tengo un excesivo consumo de memoria de ancho de banda de red.
A continuación comparto algunas recomendaciones para conseguir el máximo aislamiento y “sandboxing” de aplicaciones en entornos de hosting.
Aislamiento de procesos
Cada sitio web debe ejecutarse en un application pool separado (o en varios), y cada uno de estos debe ejecutarse con una identidad distinta. Por defecto, a partir de IIS 7.5, los application pools se ejecutan con la identidad ApplicationPoolIdentity que automáticamente genera unas cuentas virtuales (virtual accounts) distintas para cada application pool. El uso de ApplicationPoolIdentity es viable en entornos de un único servidor, pero en el caso de granjas de servidores, se hace necesario el uso de cuentas de dominio, o cuentas locales idénticas en el caso de que los servidores no se encuentren en dominio. Es aconsejable también que la identidad de acceso anónimo sea la misma que la identidad del application pool.
Finalmente, es fundamental configurar las ACLs (Access Control List) de las carpetas de contenido de forma que únicamente la identidad de cada application pool tenga acceso, en la medida de lo posible, sólo de lectura.
Más información sobre aislamiento de application pools en el siguiente artículo:
https://www.iis.net/learn/manage/configuring-security/application-pool-identities
Limitar consumo de CPU por application pool
IIS permite tomar ciertas acciones en función del consumo de CPU de un application pool, y sobre todo a partir de IIS 8.0 es posible limitar de forma efectiva el uso de CPU de los application pools.
IIS 8.0 introduce una funcionalidad llama CPU throttling (en inglés throttle significa regulador/válvula reguladora/estrangular), precisamente con el propósito de permitir configurar un límite de consumo de CPU por cada application pool. Es funcionalidad es posible debido a una nueva API en modo kernel que permite poner un límite de CPU sobre un “job”, y en el contexto de IIS, el objeto “job” es el application pool. En este caso tanto si el application pool consta de varios procesos (web garden), como si ejecutan aplicaciones PHP mediante FastCGI en procesos php-cgi.exe, el límite de consumo de CPU se aplica sobre el conjunto de todos los procesos que conforman el application pool. La suma de consumo de todos los procesos no podrá superar el límite configurado para el application pool.
Existen cuatro posibles acciones a tomar cuando se llega al límite configurado:
· NoAction: Registra un evento en el log de eventos de que se ha superado el límite configurado.
· KillW3wp: Finaliza el application pool durante el periodo de tiempo configurado. Esta opción se tiene que configurar en combinación con la propiedad Limit Interval que se configura en minutos. De este modo, si se configura un application pool con un límite del 25% con un intervalo de dos minutos, si la aplicación se pone al 100% de CPU, a los 30 segundos se finalizará (el 25% del tiempo de dos minutos) y permanecerá parada hasta que no transcurra el minuto y medio restante.
· Throttle (nuevo en IIS 8.0): Limita el consumo de CPU al % límite configurado. Es decir, el sistema operativo nunca va a permitir al proceso consumir más % de CPU de lo que se ha configurado en ninguna circunstancia.
· ThrottleUnderLoad(nuevo en IIS 8.0): Limita el consumo de CPU al % límite configurado, siempre y cuando existan contención a nivel de CPU. De no existir contención, se permitirá al proceso consumir un % de CPU superior al límite configurado.
Una aplicación que debido a los motivos que sean tiene consumo elevado de CPU, obviamente resta ciclos de CPU para otras aplicaciones en el mismo servidor.
Configurando CPU throttling en IIS 8.0 (o posteriores versiones), podemos limitar el uso de CPU en las propiedades avanzadas del application pool, en el ejemplo a un máximo de 50% de CPU (50.000 puesto que se configura a nivel de 1/1000 de %):
Una vez configurado el límite, quedan más recursos de CPU disponibles para otros procesos en el mismo servidor:
Más información sobre CPU throttling en el siguiente artículo:
Limitar consumo de memoria por application pool
Si bien no es posible “estrangular” o “regular” el consumo de memoria de un proceso de la misma forma que el consumo de CPU, IIS permite configurar reciclados de un application pool al alcanzar un determinado límite de consumo de memoria. Los reciclados pueden tener diferente impacto sobre las aplicaciones web dependiendo de la arquitectura, de donde se mantiene el estado de sesión, donde se almacena la caché, etc. Potencialmente, todo esto son datos que se almacenan en el proceso, y por tanto, al reciclarlo, se pierden estos datos.
En todo caso, en entornos de hosting tiene sentido limitar el consumo de memoria a un límite razonable, que dependerá del tipo de aplicación, de la memoria física del instalada en el servidor, y del número total de aplicaciones alojadas y la carga de usuarios esperada para cada una de estas aplicaciones. En todo caso, configurar un límite demasiado bajo será contraproducente, puesto que los constantes reinicios tendrán potencialmente un mayor impacto que el permitir un mayor consumo de memoria. Antes de configurar estos límites, es recomendable monitorizar el consumo de memoria de las distintas aplicaciones utilizando contadores de rendimiento para hacerse una idea del consumo de memoria de estas en condiciones normales.
Más información sobre la configuración de reciclados de los application pools:
Limitar el consumo de ancho de banda de red y número de conexiones
Es recomendable limitar también el límite máximo de ancho de banda de red por sitio web (en bytes por segundo) para evitar sobrecargar la red debido a la actividad excesiva de un determinado sitio web.
Más información en:
https://www.iis.net/configreference/system.applicationhost/sites/site/limits
En la misma línea, IIS permite bloquear dinámicamente direcciones IP externas que realicen “demasiadas” peticiones durante un determinado intervalo de tiempo (ambos parámetros son configurables). Esta funcionalidad, llamada dynamic IP restrictions ayuda a prevenir ataques de denegación de servicio. Este mecanismo, de nuevo, ayuda a prevenir que un problema en uno de los sitios web (en este caso, un potencial ataque), pueda afectar a otros sitios web corriendo en el mismo servidor.
Más información en:
https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-dynamic-ip-address-restrictions
No es posible dar recomendaciones genéricas relativas a los valores que deben configurarse para cada uno de los parámetros mencionados en este post, puesto que los valores concretos dependen de las características del entorno. Muchas veces, encontrar el valor optimo en cada entorno, se consigue con la experiencia, y mediante prueba y error.
Espero que os sea de utilidad.
- Daniel Mossberg