IISReset vs AppPool Recycle – Exchange 2016/2013

Hola amigos,

En esta sencilla publicación hablaremos sobre que conlleva ejecutar un IISRESET contra realizar un App Pool Recyle para IIS en Exchange Server (coff coff también conocido como el Poderoso Exchangiiiiiiiii). No hablaremos a bajo nivel, pues la publicación esta intencionada para que puedan diferenciar ambas acciones y sobra decir que al tratarse de IIS esto no es exclusivo de Exchange Server

En muchas ocasiones he visto (he de admitir que en un inicio también lo hacia) que los administradores de Exchange, para cualquier cambio que realizan, llámese modificar un valor, una URL etc sobre los directorios virtuales como ECP, OWA,  Powershell etc o bien si estan remediando un problema en particular, llamese las conexiones a OWA o de Active Sync  ejecutan acto seguido un IISRESET, causando Downtime innecesario sobre su ambiente

Si bien la información de la metabase debe ser actualizada,  no siempre es necesario ejectuar IISRESET, entonces ¿Cuando es bueno realizar un IISRESET y cuando un AppPool Recycle? ¿Existe diferencia entre uno y otro?

Primero algunos conceptos:

Application Pool (AppPool)

Application Root (AppRoot)

Application Domain (AppDom)

En un AppPool, puede haber mas de un AppRoot, el cual se define por una web application la cual contiene su propio archivo de configuración web.config. Cada AppPool tiene al menos un AppDom, el cual básicamente es la conexión entre el AppRoot y el AppPool

Es decir pueden tener varios Directorios Virtuales  (AppRoots) con su propio App domain dentro del mismo AppPool o de forma independiente cada uno con un AppPool

El AppPool es un proceso vaya, dentro del cual el AppDom es quien esta asociado con el AppRoot. si tenemos pues 5 Directorios Virtuales (AppRoots) en el mismo AppPool, por ende tendremos 5 AppDoms en el mismo proceso

A partir de la versión 7 de IIS, todos las peticiones son manejadas en modo kernel de manera predeterminada (por HTTP.sys), y pasados al Service Host (svchost.exe) que a su vez lo pasa al Web Application donde el Worker Process (w3wp.exe) la maneja

Aquí una imagen tomada prestada de MSDN que puede ayudar de forma mas gráfica:

Fuente: https://blogs.msdn.microsoft.com/cmarin/2014/10/10/arquitectura-de-iis-7/

IISRESET

Cuando ejecutamos un IISRESET, se rompen las conexiones del Service Host a todos los worker process, es decir afectamos todas las aplicaciones que usa el Service Host.

El worker process (w3wp.exe) es un proceso de Windows que ejecuta aplicaciones Web y es el responsable de manejar peticiones enviadas a un Application Pool dentro de un servidor Web. Pueden ver la lista de Worker process con el comando: appcmd list wps

Cabe mencionar que IISRESET no corta las conexiones abrupta mente, de igual forma permite un periodo de gracia pero al final del día lo que hace es detener los servicios de IIS, lo cual causa downtime.

Comportamiento:

1. Se pierde acceso a las paginas (OWA, ECP, etc)
2.  http.sys perderá las conexiones existentes de los clientes y nuevas conexiones deberan ser establecidas
3. Abra downtime durante la ejecución de IISRESET

APPPOOL RECYCLE

Cuando realizamos un recycle, solo rompemos la conexión a un App pool, esto tomara por default 90 segundos, este valor se puede incrementar para AppPools que son muy activos, para permitir que los procesos termine de forma correcta. Lo que pasa tras bambalinas es que se crea un segundo worker process el cual atiende las nuevas peticiones mientras que el worker process que esta fallando, ya no recibe nuevas, simplemente termina de atender las peticiones que ya tenia antes de ser terminado, dependiendo cuantas peticiones tenia en espera, es la razón por la cual puede tardar mas tiempo

Comportamiento:

1. Mas rapido que IISRESET
2. Los clientes siguen conectados a IIS, no hay perdida de conexiones ni downtime

AppDom Recycle

También es posible hacer recycle del AppDom (Aunque comúnmente solo es utilizado cuando se esta reparando un problema especifico, asi que lo omitiremos)

¿Entonces cuando debemos utilizar IISRESET?

Recordemos que cualquier cambio de IIS  deberia actualizarse por si solo (la paciencia es una virtud), siempre debemos intentar un App Recycle primero y IISRESET solo debe ser utilizado cuando nada de lo anterior ha funcionado (Esperar o un recycle), pero es bueno comentar que en primera instancia se debería ejecutar con los siguientes parámetros:

Iisreset /noforce (20 segundos de gracia)

o

iisreset /noforce /timeout:500 (500 segundos de gracia)

Ambos comandos arriba mencionados, darán un periodo de «gracia» el cual permitirá que las conexiones terminen por si solas antes de terminarlas

Si todo falla y se considera necesario romper todas las conexiones, debera ser usado:

iisreset

¡Enhorabuena!, acaban de aprender la teoría básica sobre cual es la diferencia entre IISRESET y un AppPool Recycle, aunque no entramos a bajo nivel, pues ya estaríamos entrando mas a temas de IIS  y el interés principal de esta publicación es solo comentar las diferencias para cuestiones de Exchange, para que tengan mejores practicas en su día a día. Dense una palmada en la espalda y coman una galleta como premio, se la han ganado.

Por Geovany Acevedo

Coman frutas y verduras