Este artículo proviene de un motor de traducción automática.

Windows Azure Insider

Mida y escale automáticamente las aplicaciones multiempresa en Windows Azure

Bruno Terkaly
Ricardo Villalobos

En nuestra columna anterior (msdn.microsoft.com/magazine/dn201743), hemos introducido conceptos relativos a la creación de aplicaciones multi-tenant, cubriendo dos de los cuatro pilares que deben considerarse al construir este tipo de sistema: identidad y seguridad y los datos de aislamiento y segregación. Este mes, nos concentramos en dos otras áreas importantes que están profundamente relacionados: medición y autoescalado. Medición permite a las empresas reunir información sobre los diferentes componentes que se comparten entre todos los inquilinos; AutoScaling garantiza que la experiencia del usuario final no se ve afectada durante períodos de alto tráfico, y que los servidores están desabastecidos cuando la demanda de recurso es menor.

Recopilación de información sobre el uso de recursos es común al solucionar problemas de aplicaciones, especialmente durante el desarrollo y los procesos de pruebas. Al hacer esto, pueden establecerse umbrales y requisitos de hardware que le garantizan un rendimiento óptimo de la solución, y requisitos mínimos de hardware pueden ser recomendados. En Windows, esta tarea se realiza mediante el uso de contadores de rendimiento que ayuda a determinar los cuellos de botella de sistema y condiciones de error.

Medición se vuelve particularmente importante cuando se ejecuta soluciones multi-tenant en la nube y no sólo durante las etapas de desarrollo. Apoyo a varios usuarios compartir los recursos regalos específicos desafíos comunes, tales como aplicar las cuotas para los inquilinos, identificar aquellos usuarios que podrían consumir recursos excesivos, o decidir si los niveles de precios necesitan ser redefinido. Tenga en cuenta que la medición soluciones multi-tenant no es sólo de determinar o validar el proyecto de ley de uso de tu proveedor de nube — en este caso Windows Azure — pero también sobre la optimización de recursos en su implementación que garantizan el nivel de servicio que esperan de los inquilinos, normalmente expresado en un acuerdo de nivel de servicio (SLA).

En este artículo, nos concentraremos en medición y autoescalado tipo de la porción del cálculo de una solución multi-tenant, cual es la solución que más se ve afectada por variaciones en el número de usuarios que acceden a la aplicación. Ahora que Windows Azure soporta múltiples modelos de implementación de la nube (Cloud Services, máquinas virtuales y sitios Web), es importante entender la tala diferente y opciones de diagnóstico que ofrece cada uno, y cómo pueden ser ajustado basado en esta información. En caso de que usted necesita comprender mejor las diferencias básicas, beneficios y limitaciones de estos modelos de implementación, encontrarás una buena guía en bit.ly/Z7YwX0.

Recogida de datos de Windows Azure Cloud Services

(Basados en la plataforma como un concepto de servicio), servicios en la nube recopila datos a través de la infraestructura de Windows Azure diagnósticos (Taco), que se construye en el marco del evento Tracing para Windows (ETW). Porque los servicios en la nube se basa en apátridas máquinas virtuales (VMs), Taco permite guardar datos localmente y, basado en un calendario, transfiérala a un repositorio central de almacenamiento de Windows Azure utilizando blobs y tablas. Una vez que se ha recogido los datos de diagnóstico de las instancias múltiples en el papel, puede ser analizado y utilizado para múltiples propósitos. Figura 1 muestra cómo funciona este proceso.

Figura 1 Windows Azure diagnósticos para servicios en la nube

Para permitir diagnósticos a servicios en la nube, el módulo correspondiente debe ser importado en el despliegue de la función (a través del archivo ServiceDefinition.csdef) y luego habilitado mediante el archivo de configuración de taco (diagnostics.wadcfg). Otro enfoque es configurar mediante programación diagnósticos dentro del método OnStart para el papel, pero utilizando el archivo de configuración es preferido porque se carga primero y errores relacionados con el arranque de las tareas pueden ser capturadas y registradas. Además, cambios en la configuración no requieren el código a ser reconstruido. Figura 2 muestra la versión más básica de la definición de servicio y diagnostico de los archivos de configuración.

Figura 2 servicio básico definición y archivos de configuración de diagnósticos para servicios en la nube

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MyHostedService" xmlns=
  "https://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition"
  schemaVersion="2012-10.1.8">
  <WebRole name="WebRole1">
    <!--<Sites> ...
</Sites> -->
    <!-- <Endpoints> ...
</Endpoints> -->
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>
</ServiceDefinition>
<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns=
  "https://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
  configurationChangePollInterval="PT1M"
  overallQuotaInMB="4096">
  <Directories bufferQuotaInMB="0" scheduledTransferPeriod="PT30M">
    <IISLogs container="wad-iis" directoryQuotaInMB="0" />
  </Directories>
</DiagnosticMonitorConfiguration>

El atributo configurationChangePollInterval define cómo a menudo una instancia busca cambios de configuración, mientras que el scheduledTransferPeriod especifica el intervalo de los archivos locales sea transferida al almacenamiento de Windows Azure (en el ejemplo mostrado en figura 2, en el contenedor de blob "wad-iis"). Considerar que un minuto (PT1M) es el predeterminado y el valor mínimo para la transferencia programada de parámetro de archivos, pero que podría ser excesivo para la mayoría de los escenarios. El atributo overallQuotaInMB define la cantidad total de almacenamiento de sistema de archivo asignado para los búferes de registro. Tampoco se puede dejar el atributo bufferQuotaInMB para cada origen de datos en el valor por defecto de cero — que significa que es menos que la propiedad overallQuotaInMB — o se puede establecer explícitamente. El OverallQuotaInMB debe ser menor que la suma de todas las propiedades de bufferQuotainMB.

Aunque diferentes fuentes de datos pueden utilizarse para recopilar información de diagnóstico para servicios en la nube, usándolos para determinar que los inquilinos específicos están consumiendo la mayor parte de los recursos computacionales no es fácil. La métrica más cercana que puede ser utilizada para este propósito es proporcionada por los registros de IIS World Wide Web Consortium (W3C), suponiendo que el tráfico de los distintos usuarios y los inquilinos se realiza un seguimiento mediante parámetros de URL o directorios virtuales específicos. Para activarlo, puede agregar el nodo XML IISLogs en el fichero de configuración de diagnósticos (también incluido en figura 2), pero se advirtió que estos registros IIS pueden conseguir enormes rápidamente. Tenga en cuenta que se almacena información sobre el diagnóstico en una cuenta de almacenamiento de Windows Azure, y pueden realizar cambios de configuración en servicios implementados y funcionando.

Para aprender más sobre otros tipos de orígenes de datos mediante el archivo de configuración — incluyendo los registros de sucesos de Windows y contadores de rendimiento, entre otros — usted puede revisar la documentación de Windows Azure en bit.ly/GTXAvo. También, a partir de la versión 2.0 de Windows Azure SDK, el proceso de configuración de diagnósticos en Visual Studio se ha mejorado mucho. La sección de diagnóstico ahora ofrece un plan personalizado que puede modificarse para incluir uno o más orígenes de datos para ser registrado y transferido a la cuenta especificada de almacenamiento de Windows Azure (figura 3).

Figura 3 nuevas opciones de configuración de diagnósticos en Windows Azure SDK 2.0

Haciendo clic en el botón Editar, puede definir los datos específicos para ser recogido, incluyendo Windows contadores de rendimiento, registros de eventos y directorios de registro (figura 4). En este ejemplo, información de diagnóstico para el porcentaje de tiempo de procesador se utiliza, disponibles megabytes de memoria y el número de solicitudes por segundo será recogido y transferido a la cuenta de almacenamiento de Windows que cada 30 minutos (la configuración de período de transferencia). Esta nueva interfaz simplifica el proceso de configuración de diagnósticos para servicios en la nube y la obtención de datos de medición para su uso posterior.

Figura 4 configuración rendimiento contadores en Visual Studio con el Windows Azure SDK 2.0

Además de los servicios de nube monitoreo opciones proporcionadas por la plataforma Windows Azure, tal vez quieras echar un vistazo a la nube Ninja medición bloque lanzado por el equipo de incubación de Windows Azure, que abarca muchas de estas características en una biblioteca de fácil de usar. Está disponible en cnmb.codeplex.com.

Recogida de datos de Windows Azure máquinas virtuales

Máquinas virtuales son instancias stateful en la plataforma Windows Azure y puede ser desplegadas individualmente o conectadas a servicios en la nube a través de redes virtuales. Debido a estas instancias funcionan las versiones completas de Windows y Linux, reuniendo diagnósticos información es similar al proceso para máquinas locales, mediante contadores de rendimiento y persistencia para almacenamiento local. El proceso de extraer esta información varía, pero generalmente se logra mediante la instalación de los agentes locales que transferir esta información a servicios externos.

Recogida de datos de Windows Azure webs

Ahora volvamos nuestra atención a sitios Web de Windows Azure. Diagnóstico de reunir información de sitios Web es un proceso simple que puede activarse directamente en el portal de gestión. Con el fin de supervisar las aplicaciones multi-tenant, Web servidor de registro (el formato de archivo de registro extendido W3C) debe ser activado y descargaron los archivos de registro vía FTP. Aquí están los pasos a seguir:

1. Acceso manage.windowsazure.com.
2. Seleccione sitios Web y el sitio específico que debe configurarse.
3. Haga clic en configurar y desplácese hacia abajo hasta la sección "diagnóstico del sitio". Encienda el servidor Web de registro.
4. Puede descargar los registros de /LogFiles/http/RawLogs. Log Parser 2.2, disponibles en Microsoft Download Center (bit.ly/119mefJ), puede ser utilizado para analizar y registre la consulta IIS.

Como con Windows Azure Cloud Services, información de los archivos de registro puede utilizarse para determinar el uso de los recursos por diferentes arrendatarios, mediante el seguimiento de los parámetros de URL o directorios virtuales individuales.

Como un servicio de medición

Además de las opciones de diagnóstico nativamente proporcionadas por Windows Azure, algunas compañías ofrecen servicios de medición para Windows Azure. Por ejemplo, Dell Inc. ha creado un producto llamado Foglight que proporciona datos en tiempo real sobre la salud de las aplicaciones y lazos a la UX. También incluye un servicio de notificación que avisa a los desarrolladores de problemas críticos. Hoy, la niebla­luz es compatible con servicios en la nube y Windows Azure SQL Database, basado en la infraestructura WAD, como se muestra en la figura 5.

Figura 5 el Foglight Dell Portal de monitoreo

Opciones de autoescalado

Una vez que se ha recogido los datos de medición y performance counter, puede ser utilizado para determinar el nivel de aprovisionamiento que se necesita para cumplir los requisitos de rendimiento de la aplicación. AutoScaling en Windows Azure se refiere al acto de sumar o restar a instancias de una implementación específica (escalado), con la idea de mantener soluciones y funcionando con el menor costo posible. Aunque es posible escalar (aumentar los recursos para una sola máquina), esto implica generalmente downtime de las aplicaciones, que no es deseable. Básicamente hay tres formas de Autoescala un despliegue de Windows Azure.

Utilice un Autoscaling Block un enfoque de autoescalado un despliegue de Windows Azure, que específicamente se aplica a Windows Azure Cloud Services, es añadir un bloque de autoescalado aplicación a la solución. Hay un par de bibliotecas listo para ser utilizado para este propósito. Una biblioteca es parte de la empresa integración Pack para Windows Azure, y utiliza un conjunto de reglas definidas por el usuario, límites de ajuste para el número mínimo y máximo de instancias de papel en el despliegue basado en las mediciones recogidas por Taco o contadores. Este enfoque ha sido ampliamente documentada por los patrones de Microsoft & equipo de prácticas y se puede encontrar en bit.ly/18cr5mD. Figura 6 muestra una arquitectura multi-tenant básica con un bloque de autoescalado agregado a la solución.

Figura 6 utilizando una aplicación de autoescalado bloquear el enfoque para servicios en la nube

Utilizar un servicio externo hay algunos servicios de escalado de salida disponibles para las implementaciones de Windows Azure que actúan como bloques de aplicación externa autoescalado. Microsoft adquirió recientemente MetricsHub (metricshub.com), que proporciona un servicio gratuito de vigilancia y autoescalado para suscriptores de Windows Azure. La lógica de escalado se basa en promedios sostenidos, indicadores principales, los datos y programas específicos. Puede agregar el servicio directamente desde el portal de gestión en la sección Add-ons (Windows Azure Store). MetricsHub soporta tanto Windows Azure Cloud Services y Windows Azure máquinas virtuales, basado en una arquitectura que extrae información de taco y recibe información de los agentes instalados en instancias únicas de stateful (ver figura 7).

Figura 7 MetricsHub arquitectura

Una vez que se haya configurado el servicio, el portal MetricsHub ofrece diferentes umbrales para mantener un ambiente sano de la nube, basado en parámetros tales como gama de CPU de destino y el número de mensajes en una cola. También proporciona un coste previsión antes y después de aplicar las opciones de autoescalado, verdaderamente automatizar el aprovisionamiento de proceso de la manera más inteligente posible, equilibrar el costo con rendimiento (ver figura 8).

Figura 8 el Portal de autoescalado MetricsHub arquitectura

Utilice Windows Automated Scripts PowerShell el tercer método se basa en los scripts de Windows PowerShell que se crean manualmente y ejecutados directamente contra la API de administración de Windows Azure. Este enfoque proporciona un alto nivel de control y flexibilidad, porque estas secuencias de comandos pueden utilizarse dentro de las aplicaciones personalizadas o marcos de integración continua. Por otra parte, los cmdlets de Windows PowerShell para Windows Azure apoyar los modelos de tres despliegue, incluyendo la automatización del proceso de aprovisionamiento para sitios Web de Windows Azure. Por ejemplo, cambiando el número de instancias para una implementación específica es tan fácil como ejecutar el siguiente comando:

PS C:\> Set-AzureWebsite –Name {WebSiteName} –NumberOfWorkers {Instances}

Para obtener instrucciones sobre cómo configurar e instalar Windows Azure cmdlets, consulte bit.ly/QqctsU. Usted puede encontrar documentación sobre cómo usar cada uno de los cmdlets en bit.ly/U0vOEp.

En resumen

Este artículo concluye nuestra serie de dos partes en la construcción de soluciones multi-tenant en Windows Azure. Además de identidad y datos de aislamiento en el primer artículo, presentamos el proceso de configuración y extraer información de rendimiento de cada uno de los modelos de implementación de Windows Azure — servicios en la nube, las máquinas virtuales y sitios Web. Al mismo tiempo, se analizaron tres maneras diferentes de los despliegues de autoescalado via componentes internos y externos y servicios. Aprovechando el modelo económico de nube — que se basa en el coste del uso y piscinas de recursos compartidos, más empresas están lanzando soluciones que pueden ser eficientemente adaptadas a sus necesidades.

Bruno Terkaly es evangelizador desarrollador para Microsoft. La profundidad de sus conocimientos los debe a años de experiencia en el sector, al escribir código con diversas plataformas, lenguajes, marcos, SDK, bibliotecas y API. Se dedica a programar, publicar en su blog y a realizar presentaciones en vivo sobre la creación de aplicaciones basadas en nube, específicamente con la plataforma Windows Azure. Puede leer su blog en blogs.msdn.com/b/brunoterkaly.

Ricardo Villalobos es un arquitecto de software sazonada con más de 15 años de experiencia diseñando y creando aplicaciones para empresas en la industria de gestión de cadena de suministro. Sostiene diferentes certificaciones técnicas, así como una maestría en administración de empresas por la Universidad de Dallas, trabaja como un arquitecto de la nube en el grupo de incubación de Windows Azure CSV para Microsoft. Puedes leer su blog en blog.ricardovillalobos.com.

Terkaly y Villalobos conjuntamente presentar conferencias de la industria en general. Animan a los lectores de Windows Azure Insider en contacto con ellos para disponibilidad. Terkaly puede ser contactado en bterkaly@microsoft.com y Villalobos puede ser contactado en Ricardo.Villalobos@microsoft.com.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Trent Swanson (escala completa 180)
Trent Swanson es un arquitecto de software y director trabajando con nube y tecnologías de datos grande de 180 de escala completa. Han estado trabajando con Windows Azure desde el principio, ayudando a los clientes la construcción del mundo, implementar y gestionar sus soluciones en la nube de Windows Azure. Si se está moviendo a una aplicación existente a la nube o crear otras nuevas, disfruto el ciclo de vida completo de soluciones cloud escalable, confiable y fácil de administrar en Windows Azure. Al no trabajar en proyectos interesantes y desafiantes, también me gusta pasar tiempo en el gimnasio, artes marciales mixtas, apoyo a pequeñas empresas locales y ser activo en mi iglesia.