Sencillez de autoescalado en Windows Azure con “WASABi”

Muy buenas,

Desde hace algún tiempo quería realizar algunas pruebas en profundidad con  “WASABi” (MICROSOFT ENTERPRISE LIBRARY 5.0 INTEGRATION PACK FOR WINDOWS AZURE  AUTOSCALING APPLICATION BLOC).

La semana pasada, nuestro compañero, Luis Panzano indico en en este post los pasos más importantes para llevar a cabo una prueba/demo muy fácil y rápida, así que aprovecho la misma para profundizar y resolver algunas dudas que se plantean por los foros de Azure.

Antes de nada, me gustaría aclarar, que para el autoscalado, se utilizará un WorkerRole, quien será el encargado de analizar en todo momento la configuración y reglas de escalado a partir de ficheros de los configuración.

Detalle de los pasos para trabajar con WASABi:

1. Acceder y descargar los prerrequisitos necesarios desde aquí.
2. Role o nodo a escalar (ej.: Aplicación web):
   • Indicar en los ficheros de configuración de los proyectos  “ServiceDefinitios.csdef” y “ServiceConfiguration.*.cscfg”, el AccountName y AccountKey del “Azure Storage Account”.
   • Añadir una nueva cadena de conexión (“ConfigurationSettings”) en esta demo, para hacer uso de una cola de Azure, que será monitorizada por el “AutoScaler” en función de su número de elementos de la misma. Si no se utilizará el número de elemento de la cola, no sería necesario.
   • Desplegar la aplicación en Azure.
3. Worker Role, AutoScaler (El autoescalador):
   • Indicar en los ficheros de configuración de los proyectos  “ServiceDefinitios.csdef” y “ServiceConfiguration.*.cscfg”, el AccountName y AccountKey del “Azure Storage Account”.
   • Incluir el thumbprint de un certificado en los fichero “*.cscfg” en la sección <certificates>, teniendo como “Store Location”, LocalMachine o CurrentUser independientemente.
   • Configurar el “app.config” con la información necesaria para WASABi. Puede hacerse desde la consola de EntLib que permite la configuración del autoscalado mas gráficamente:

• Rules-store.xml: Es el nombre del fichero donde se configuran las reglas de autoescalado. Aquí puede obtenerse más detalle sobre todos sus atributos. Una de las cosas curiosas de este fichero es que el valor del “timespan” del  operando “queueLength” no puede ser inferior a “00:05:00”, en cuyo caso se producirán las excepciones:
  • A first chance exception of type ‘System.ArgumentOutOfRangeException’ occurred in Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.dll
  • A first chance exception of type ‘System.InvalidOperationException’ occurred in Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.dll

<operands>

    <queueLength alias="QueueLengthAvg" queue="cola-wasabi" aggregate="Last" timespan="00:05:00"/>

</operands>

• Services-information-store.xml: Es el nombre del fichero donde se indica toda la información necesaria para que el AutoScaler pueda acceder a la subscripción de Azure y poder realizar el incremento o disminución de instancias: SubscriptionId, información del certificado local y subido a Azure, y muy importante, para cada servicio, el “DNS Prefix” y el nombre del Role.
• Al ejecutar el AutoScaler desde el Emulador de Azure, se podrán producir errores, que pueden verse en en el output:
  • A first chance exception of type ‘Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.Security.CertificateException’ occurred in Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.dll
  • A first chance exception of type ‘Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.Security.CertificateException’ occurred in Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.dll
  • A first chance exception of type ‘Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.ServiceManagement.ServiceManagementClientException’ occurred in Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.dll
• Indicar el valor “CurrentUser”  para el attributo “certificateStoreLocation” además de corroborar en la consola de certificados que este existe y se corresponde con el valor del  “certificateThumbprint”. Esto es debido en muchos de los casos a Windows 8, que como ya he comentado alguna vez, es bastante más exhaustivo con los permisos
• Ambos ficheros de configuración (XML) tienen sus esquemas “AutoscalingRules.xsd” y “AutoscalingServiceModel.xsd” que se encuentran junto a la descarga de WASABi y que será recomendable incluir en el proyecto “AutoScaler” a fin de que la edición de la configuración sea más sencilla.
• WasabiStorageAccount: Es el nombre del Connection String referente al “Storage Account de Azure” donde se encuentran los ficheros antes indicados. Es decir, los ficheros anteriores deberán almacenarse en dicha cuenta bajo el container “autoscaling” que deberá generarse manualmente y que tendrá que coincidir con el valor de atributo “Blob Container Name” (según puede verse indicado por la flecha en la figura anterior).
• Si no se quiere hacer uso del Storage de Azure para almacenar los ficheros de recursos, bien, porque se está trabajando en una solución híbrida, bien porque se está probando en local, etc, puede optarse por cambiar el “Rules Store” y el “Service Information Store”, e indicar una ruta física. Adicionalmente siempre puede establecerse un almacenamiento “Custom”.

Finalizada la fase de configuración, y sin necesidad de desplegar en Azure, el AutoScaler esta listo. Siguiendo con la Demo, cuando la cola tiene tres elementos, y una vez hayan transcurridos 5 minutos desde la inserción del último elementos, la nueva instancia comenzará a ponerse en marcha:

IMPORTANTE: Si el “AutoScaler”, necesita ser ejecutado en más de una instancia, debido al la gran carga de reglas de autoescalado o al alto número de roles que pueda tener la aplicación, es posible, que más de una de estas instancies evalué las reglas de autoescalado, lo que implicaría “un doble autoscalado” no deseado. Para evitar esto, el “AutoScaling Application Block” permite indicar un valor “true”, para la propiedad “Use Blob Execution Lease” como puede verse en la siguiene figura.  No obstante, si este no es el caso, es recomendable dejar este valor a “false” para  evitar “overhead”.

El “Service Management Request Tracker”, permitirá habilitar mensajes de log durante el escalado, tanto de éxito como de fallo. Para ello, el “AutoScaling Application Block” utiliza automáticamente una cola de Windows Azure “requesttracker” donde recoge dichos mensajes.

Es importante conocer, que el “AutoScaling Application Block”, utiliza el valor “utcOffset” para convertir información de configuración de tiempo al formato UTC que es el que utiliza utiliza Windows Azure. “Michael S. Collier” comenta este tema y otros más en su blog.

Y por último comentar que tras algunos intentos, y tras el error “‘Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.DataPointsCollection.DataPointsCollectionException’ occurred in Microsoft.Practices.EnterpriseLibrary.WindowsAzure.Autoscaling.dll”, el AutoScalado de una aplicación en local parece que por el momento no es posible, así que tendremos que “hilar fino” con las reglas.

Y, como dirían en mi pueblo, ¡que ustedes lo escalen bien!

Juanlu, ElGuerre

Si necesitas más detalle, siempre puedes echar un vistazo al “How to”.