portal4 - azureweb

¿Hay alguna forma de determinar por qué se reinició el Servicio de aplicaciones de Azure?

Question

Tengo un montón de sitios web que se ejecutan en una sola instancia del Servicio de aplicaciones de Azure, y todos están configurados en Siempre encendido. Todos se reiniciaron repentinamente al mismo tiempo, lo que provocó que todo fuera lento durante unos minutos, ya que todo afectaba a una solicitud fría.

Esperaría esto si el servicio me hubiera trasladado a un nuevo host, pero eso no sucedió, todavía tengo el mismo nombre de host.

El uso de la CPU y la memoria era normal en el momento del reinicio, y no inicié ninguna implementación ni nada de eso. No veo una razón obvia para el reinicio.

¿Hay algún registro en algún lugar que pueda ver para averiguar por qué se reiniciaron? ¿O es esto solo una cosa normal que el Servicio de aplicaciones hace de vez en cuando?

Answer 1

Entonces, parece que la respuesta a esto es "no, realmente no puedes saber por qué , puedes inferir que sí ".

Quiero decir, puede agregar un registro de Application Insights como

 private void Application_End()
{
log.Warn($"The application is shutting down because of ''{HostingEnvironment.ShutdownReason}''.");
TelemetryConfiguration.Active.TelemetryChannel.Flush();
// Server Channel flush is async, wait a little while and hope for the best
Thread.Sleep(TimeSpan.FromSeconds(2));
}

y terminará con "The application is shutting down because of ''ConfigurationChange''." o "The application is shutting down because of ''HostingEnvironment''." , pero realmente no te dice lo que está sucediendo a nivel de host.

Lo que necesitaba aceptar es que el Servicio de aplicaciones reiniciará las cosas de vez en cuando y me preguntará por qué me importaba. Se supone que el Servicio de aplicaciones es lo suficientemente inteligente como para esperar a que el grupo de aplicaciones se caliente antes de enviarle solicitudes (como el reciclaje superpuesto). Sin embargo, mis aplicaciones permanecerían allí procesando la CPU durante 1-2 minutos después de un reciclaje.

Me tomó un tiempo descifrarlo, pero el culpable fue que todas mis aplicaciones tienen una regla de reescritura para redirigir de HTTP a HTTPS. Esto no funciona con el módulo de inicialización de la aplicación: envía una solicitud a la raíz, y todo lo que obtiene es un redireccionamiento 301 desde el módulo de reescritura de URL, y la canalización de ASP.NET no se ve afectada en absoluto, el trabajo duro no fue alcanzado. en realidad hecho El Servicio de aplicaciones / IIS pensó que el proceso de trabajo estaba listo y luego le enviaba el tráfico. Pero la primera solicitud "real" en realidad sigue a la redirección 301 a la URL HTTPS, y ¡bam! Ese usuario golpea el dolor de un arranque en frío.

Agregué una regla de reescritura descrita aquí para eximir al módulo de Inicialización de aplicaciones de la necesidad de HTTPS, de modo que cuando llegue a la raíz del sitio, realmente activará la carga de la página y, por lo tanto, todo el canal:

<rewrite>
<rules>
<clear />
<rule name="Do not force HTTPS for application initialization" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="localhost" />
<add input="{HTTP_USER_AGENT}" pattern="Initialization" />
</conditions>
<action type="Rewrite" url="{URL}" />
</rule>
<rule name="Force HTTPS" enabled="true" stopProcessing="true">
<match url="(.*)" ignoreCase="false" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
</rule>
</rules>
</rewrite>

Es una de las muchas entradas en un diario sobre cómo mover aplicaciones antiguas a Azure. Resulta que hay muchas cosas con las que puedes salir cuando algo se está ejecutando en una máquina virtual tradicional que rara vez se reinicia, pero se necesitará un poco de TLC para resolver el problema. Se tuerce al migrar a nuestro nuevo mundo valiente en la nube ...

-

ACTUALIZACIÓN 10/27/2017: desde este escrito, Azure ha agregado una nueva herramienta en "Diagnosticar y resolver problemas". Haga clic en "Web App Restarted", y le indicará el motivo, generalmente debido a la latencia del almacenamiento o las actualizaciones de infraestructura. Sin embargo, lo anterior sigue vigente, ya que cuando se muda al Servicio de aplicaciones de Azure, la mejor forma de avanzar es que realmente solo tiene que convencer a su aplicación para que se sienta cómoda con reinicios aleatorios.

-

ACTUALIZACIÓN 02/11/2018: Después de migrar varios sistemas heredados a una sola instancia de un Plan de Servicio de Aplicación mediano (con una gran cantidad de CPU y sobrecarga de memoria), estaba teniendo un problema desconcertante en el que mis implementaciones de las ranuras de almacenamiento se realizarían sin problemas, pero siempre Me enviaron a un nuevo host debido al mantenimiento de la infraestructura de Azure, todo iría mal con un tiempo de inactividad de 2-3 minutos. Me estaba volviendo loco intentando averiguar por qué sucedía esto, porque se supone que el Servicio de aplicaciones esperará hasta que reciba una respuesta exitosa de tu aplicación antes de enviarte al nuevo host.

Estaba tan frustrado por esto que estaba listo para clasificar el Servicio de aplicaciones como basura empresarial y volver a las máquinas virtuales IaaS.

Resultaron ser varios problemas, y sospecho que otros los encontrarán mientras portan sus propias aplicaciones ASP.NET heredadas de bestias al Servicio de aplicaciones, así que pensé que las encontraría todas aquí.

Lo primero que debes verificar es que realmente estás haciendo un trabajo real en tu Application_Start . Por ejemplo, estoy usando NHibernate, que aunque es bueno en muchas cosas es bastante complicado para cargar su configuración, así que me aseguro de crear el SessionFactory durante Application_Start para asegurarme de que se realice el trabajo duro.

La segunda cosa que debe verificar, como se mencionó anteriormente, es que no tiene una regla de reescritura para SSL que interfiera con la revisión de calentamiento del Servicio de aplicaciones. Puede excluir los controles de calentamiento de su regla de reescritura como se mencionó anteriormente. O, desde el momento en que escribí originalmente esa solución, el Servicio de aplicaciones ha agregado un indicador Solo HTTPS que le permite realizar la redirección de HTTPS en el equilibrador de carga en lugar de dentro de su archivo web.config. Ya que se maneja en una capa de direccionamiento indirecto sobre el código de su aplicación, no tiene que pensarlo, así que recomendaría la marca Sólo HTTPS como la forma de hacerlo.

La tercera cosa a considerar es si está utilizando o no la opción de caché local del Servicio de aplicaciones . En resumen, esta es una opción donde el Servicio de aplicaciones copiará los archivos de su aplicación en el almacenamiento local de las instancias en las que se está ejecutando en lugar de salir de un recurso compartido de red, y es una excelente opción para habilitar si a su aplicación no le importa si pierde los cambios escritos en el sistema de archivos local. Acelera el rendimiento de E / S (lo cual es importante porque, recuerda, el Servicio de aplicaciones se ejecuta en papas ) y elimina los reinicios causados ​​por cualquier mantenimiento en la red compartida. Pero, hay una sutileza específica con respecto a las actualizaciones de la infraestructura del Servicio de Aplicaciones que está mal documentada y debe tenerlo en cuenta. Específicamente, la opción de caché local se inicia en segundo plano en un dominio de aplicación separado después de la primera solicitud, y luego se cambia al dominio de la aplicación cuando la caché local está lista. Eso significa que el Servicio de aplicaciones realizará una solicitud de calentamiento contra su sitio, obtendrá una respuesta exitosa, dirigirá el tráfico a esa instancia, pero (¡vaya!) Ahora el caché local está moliendo la E / S en segundo plano, y si tiene muchos sitios En este caso, se ha detenido porque la E / S del Servicio de aplicaciones es terrible. Si no sabes que esto está sucediendo, los registros tienen un aspecto espeluznante porque parece que tu aplicación se está iniciando dos veces en la misma instancia (porque lo está). La solución es seguir esta publicación del blog de Jet y crear una página de calentamiento de inicialización de la aplicación para monitorear la variable de entorno que le indica cuándo está disponible la memoria caché local. De esta manera, puede forzar que el Servicio de aplicaciones demore el inicio de la sesión en la nueva instancia hasta que la Caché local esté completamente preparada. Aquí hay uno que uso para asegurarme de que también pueda hablar con la base de datos:

public class WarmupHandler : IHttpHandler
{
public bool IsReusable
{
get
{
return false;
}
}
public ISession Session
{
get;
set;
}
public void ProcessRequest(HttpContext context)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
var request = context.Request;
var response = context.Response;
var localCacheVariable = Environment.GetEnvironmentVariable("WEBSITE_LOCAL_CACHE_OPTION");
var localCacheReadyVariable = Environment.GetEnvironmentVariable("WEBSITE_LOCALCACHE_READY");
var databaseReady = true;
try
{
using (var transaction = this.Session.BeginTransaction())
{
var query = this.Session.QueryOver<User>()
.Take(1)
.SingleOrDefault<User>();
transaction.Commit();
}
}
catch
{
databaseReady = false;
}
var result = new
{
databaseReady,
machineName = Environment.MachineName,
localCacheEnabled = "Always".Equals(localCacheVariable, StringComparison.OrdinalIgnoreCase),
localCacheReady = "True".Equals(localCacheReadyVariable, StringComparison.OrdinalIgnoreCase),
};
response.ContentType = "application/json";
var warm = result.databaseReady && (!result.localCacheEnabled || result.localCacheReady);
response.StatusCode = warm ? (int)HttpStatusCode.OK : (int)HttpStatusCode.ServiceUnavailable;
var serializer = new JsonSerializer();
serializer.Serialize(response.Output, result);
}
}

También recuerde mapear una ruta y agregar la inicialización de la aplicación a su web.config :

<applicationInitialization doAppInitAfterRestart="true">
<add initializationPage="/warmup" />
</applicationInitialization>

La cuarta cosa a considerar es que, a veces, el Servicio de aplicaciones reiniciará su aplicación por razones aparentemente ilegales. Parece que la configuración de la propiedad fcnMode en Disabled puede ayudar; evita que el tiempo de ejecución reinicie su aplicación si alguien hizo con los archivos de configuración o el código en el servidor. Si usa ranuras de almacenamiento y realiza implementaciones de esa manera, esto no debería molestarlo. Pero si espera poder enviar un FTP y mezclarlo con un archivo y ver ese cambio reflejado en la producción, no use esta opción:

 <httpRuntime fcnMode="Disabled" targetFramework="4.5" />

La quinta cosa a considerar, y este fue principalmente mi problema desde el principio , es si está usando o no ranuras de AlwaysOn con la opción AlwaysOn habilitada. La opción AlwaysOn funciona haciendo ping a su sitio cada minuto para asegurarse de que esté caliente para que IIS no lo reduzca. Inexplicablemente, esto no es una configuración pegajosa , por lo que es posible que haya activado AlwaysOn tanto en la producción como en las ranuras de preparación para que no tenga que meterse con ella todas las veces. Esto causa un problema con las actualizaciones de la infraestructura del Servicio de aplicaciones cuando lo inician en un nuevo host. Esto es lo que sucede: digamos que tiene 7 sitios alojados en una instancia, cada uno con su propia ranura de ensayo, todo con AlwaysOn habilitado. App Service realiza el calentamiento y la inicialización de la aplicación en sus 7 ranuras de producción y espera debidamente a que respondan con éxito antes de redirigir el tráfico. Pero no hace esto para las ranuras de puesta en escena. Así que dirige el tráfico a la nueva instancia, pero luego AlwaysOn comienza en 1-2 minutos más tarde en las ranuras de preparación, por lo que ahora tiene 7 sitios más que se inician al mismo tiempo. Recuerde, el Servicio de aplicaciones se ejecuta en papas , por lo que toda esta E / S adicional que ocurra al mismo tiempo destruirá el rendimiento de sus ranuras de producción y se percibirá como tiempo de inactividad.

La solución es mantener AlwaysOn apagado en sus ranuras de almacenamiento de modo que no se vea afectado por este frenesí simultáneo de E / S después de una actualización de infraestructura. Si está utilizando un script de intercambio a través de PowerShell, mantener este "Desactivado en la preparación, Activado en producción" es sorprendentemente detallado:

Login-AzureRmAccount -SubscriptionId {{ YOUR_SUBSCRIPTION_ID }}
$resourceGroupName = "YOUR-RESOURCE-GROUP"
$appName = "YOUR-APP-NAME"
$slotName = "YOUR-SLOT-NAME-FOR-EXAMPLE-STAGING"
$props = @{ siteConfig = @{ alwaysOn = $true; } }
Set-AzureRmResource `
-PropertyObject $props `
-ResourceType "microsoft.web/sites/slots" `
-ResourceGroupName $resourceGroupName `
-ResourceName "$appName/$slotName" `
-ApiVersion 2015-08-01 `
-Force
Swap-AzureRmWebAppSlot `
-SourceSlotName $slotName `
-ResourceGroupName $resourceGroupName `
-Name $appName
$props = @{ siteConfig = @{ alwaysOn = $false; } }
Set-AzureRmResource `
-PropertyObject $props `
-ResourceType "microsoft.web/sites/slots" `
-ResourceGroupName $resourceGroupName `
-ResourceName "$appName/$slotName" `
-ApiVersion 2015-08-01 `
-Force

Esta secuencia de comandos configura la ranura de AlwaysOn para que AlwaysOn active, hace el intercambio para que la puesta en escena ya esté en producción, luego configura la ranura de AlwaysOn para que AlwaysOn se desactive, de modo que no explote las cosas después de una actualización de infraestructura.

Una vez que lo consiga, es bueno tener un PaaS que maneje las actualizaciones de seguridad y las fallas de hardware por usted. Pero es un poco más difícil de lograr en la práctica de lo que sugieren los materiales de marketing. Espero que esto ayude a alguien.