Artigo
09/07/2015

Este artigo foi traduzido por máquina.

Windows Azure Insider

Meça e dimensione automaticamente os aplicativos de multilocação no Windows Azure

Bruno Terkaly and Ricardo Villalobos Em nossa coluna anterior (msdn.microsoft.com/magazine/dn201743), introduzimos conceitos relativos à criação de aplicativos para vários inquilinos, abrangendo dois dos quatro pilares que devem ser considerados durante a criação deste tipo de sistema: identidade e segurança e dados de isolamento e segregação. Este mês, nos concentramos em duas outras áreas importantes que são profundamente interwined: medição e autoscaling. Medição permite às empresas coletar informações sobre os diferentes componentes que estão sendo compartilhados entre todos os inquilinos; AutoScaling garante que a experiência do usuário final não é afectada durante períodos de tráfego elevado, e que os servidores são desprovisionados quando a demanda de recursos é inferior.

Recolha de informações sobre o uso de recursos é comum ao solucionar problemas de aplicativos, especialmente durante os processos de testes e desenvolvimento. Ao fazer isso, os limites e requisitos de hardware que irão garantir o melhor desempenho da solução podem ser definidos, e requisitos mínimos de hardware podem ser recomendados. No Windows, esta tarefa é realizada usando os contadores de desempenho que ajudam a determinar os gargalos do sistema e as condições de erro.

Medição torna-se particularmente importante quando executando multilocatário soluções na nuvem e não apenas durante as fases de desenvolvimento. Suporte a múltiplos usuários compartilhamento comum recursos apresenta desafios específicos, tais como a impor quotas para os inquilinos, identificar todos os usuários que podem consumir recursos excessivos, ou decidir se os níveis de preços precisam ser redefinidos. Tenha em mente que a medição de soluções para vários inquilinos não é apenas sobre a determinação ou validando o projeto de lei de uso do seu provedor de nuvem — neste caso, Windows Azure — mas também sobre como otimizar recursos na sua implantação que garantem o nível de serviço que esperam de inquilinos, normalmente expressa em um acordo de nível de serviço (SLA).

Neste artigo, nós vai concentrar-se na medição e autoscaling tipo de parte de uma solução para vários inquilinos, que é a solução de computação que é mais afetada por variações no número de usuários acessando o aplicativo. Agora que o Windows Azure oferece suporte a vários modelos de implantação de nuvem (Cloud Services, máquinas virtuais e Web Sites), é importante compreender os diferentes e opções de diagnósticos, que cada um oferece e como eles podem ser autoscaled com base nesta informação. No caso de você precisar entender melhor as diferenças básicas, benefícios e limitações desses modelos de implantação, você encontrará um bom guia no bit.ly/Z7YwX0.

Coleta de dados de serviços do Windows Azure Cloud

Cloud Services (baseados na plataforma como um conceito de serviço), coleta de dados via a infra-estrutura Windows Azure diagnósticos (WAD), que é construída sobre o framework de rastreamento de eventos para Windows (ETW). Porque os serviços de nuvem baseia-se apátrida máquinas virtuais (VMs), WAD permite que você salve dados localmente e, com base em um cronograma, transferi-lo para um repositório central no armazenamento do Windows Azure usando blobs e tabelas. Uma vez que foram coletados os dados de diagnóstico de múltiplas instâncias no papel, pode ser analisada e usada para finalidades múltiplas. Figura 1 mostra como funciona este processo.

Figura 1 Windows Azure diagnóstico para serviços em nuvem

Para habilitar o diagnóstico para serviços em nuvem, o módulo correspondente deve ser importado para a implantação de papel (via o arquivo ServiceDefinition.) e então habilitado via arquivo de configuração de WAD (diagnostics.wadcfg). Outra abordagem é programaticamente configurar diagnósticos dentro do método OnStart para o papel, mas usando o arquivo de configuração é preferível porque é carregado primeiro e erros relacionados a inicialização tarefas podem ser apanhadas e registradas. Além disso, alterações na configuração não exigem o código para ser reconstruído. Figura 2 mostra a versão mais básica do diagnóstico e definição de serviço de arquivos de configuração.

Figura 2 serviço básico de definição e arquivos de diagnóstico de configuração para serviços em nuvem

<?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>

O atributo configurationChangePollInterval define quantas vezes uma instância verifica se há alterações de configuração, enquanto o scheduledTransferPeriod especifica o intervalo para os arquivos locais ser transferido para o Windows Azure Storage (no exemplo mostrado na Figura 2, para o recipiente de blob "wad-iis"). Considere que um minuto (PT1M) é o padrão e o valor mínimo de transferência agendada de parâmetro de arquivos, mas que pode ser um exagero para a maioria dos cenários. O atributo overallQuotaInMB define a quantidade total de armazenamento de sistema de arquivos alocado para os buffers de log. O atributo bufferQuotaInMB para cada fonte de dados também pode ser deixado no padrão de zero — o que significa menos que a propriedade overallQuotaInMB é — ou pode ser definida explicitamente. O OverallQuotaInMB deve ser menor que a soma de todas as propriedades bufferQuotainMB.

Apesar de diferentes fontes de dados podem ser usadas para coletar informações de diagnóstico para serviços em nuvem, usando-os para determinar quais os inquilinos específicos estão consumindo a maior parte dos recursos de computação não é fácil. A métrica mais próxima que pode ser usada para essa finalidade é fornecida pelos logs do IIS World Wide Web Consortium (W3C), assumindo que o tráfego de usuários diferentes e inquilinos é rastreado via parâmetros de URL ou diretórios virtuais específicos. A fim de ativá-lo, você pode adicionar o nó IISLogs XML para o arquivo de configuração de diagnóstico (também incluído no Figura 2), mas seja advertido que estes logs do IIS podem ficar enormes rapidamente. Tenha em mente que informações de diagnóstico são armazenadas em uma conta de armazenamento do Windows Azure, e as alterações de configuração podem ser feitas sobre os serviços implantados e funcionando.

Para saber mais sobre outros tipos de fontes de dados via arquivo de configuração — incluindo Windows logs de eventos e contadores de desempenho, entre outros — você pode revisar a documentação do Windows Azure em bit.ly/GTXAvo. Além disso, a partir da versão 2.0 do SDK do Windows Azure, o processo de configuração de diagnóstico no Visual Studio foi muito melhorada. A seção de diagnóstico oferece agora um plano personalizado que pode ser modificado para incluir uma ou mais fontes de dados para ser registrados e transferidos para a conta especificada de armazenamento do Windows Azure (Figura 3).

Figura 3 novas opções de configuração de diagnóstico no Windows Azure SDK 2.0

Clicando no botão Editar, você pode definir dados específicos para ser coletado, incluindo contadores de desempenho do Windows, os logs de eventos e diretórios de log (Figura 4). Neste exemplo, informações de diagnóstico para a porcentagem de tempo do processador sendo usado, disponíveis megabytes de memória e o número de solicitações por segundo serão recolhidas e transferidas para a conta de armazenamento do Windows que cada 30 minutos (a definição de período de transferência). Essa nova interface simplifica o processo de configuração de diagnóstico para serviços em nuvem e obtenção de dados de medição para uso posterior.

Figura 4- Configurando o desempenho contadores no Visual Studio com o Windows Azure SDK 2.0

Para além dos serviços de nuvem monitoramento opções fornecidas pela plataforma Windows Azure, você pode querer dar uma olhada a nuvem Ninja medição bloco lançado pela equipe do Windows Azure de incubação, que engloba muitos desses recursos em uma biblioteca de fácil de usar. Está disponível em cnmb.codeplex.com.

Coletar dados do Windows Azure máquinas virtuais

Máquinas virtuais são instâncias com monitoração de estado, rodando na plataforma Windows Azure e podem ser implantadas individualmente ou conectadas a serviços em nuvem por meio de redes virtuais. Porque essas instâncias executam versões completas do Windows e Linux, reunindo diagnósticos informações são semelhantes ao processo para máquinas no local, usando os contadores de desempenho e persistência para armazenamento local. O processo de extrair esta informação varia, mas isso geralmente é realizado através da instalação de agentes locais que transferem essas informações para serviços externos.

Coleta de dados de Windows Azure Web Sites

Agora vamos voltar nossa atenção para Sites da Web do Windows Azure. Diagnósticos de coleta informações de Sites da Web são um processo simples que pode ser ativado diretamente no portal de gerenciamento. Para fins de monitoramento de aplicações para múltiplos inquilinos, Web Server log (o formato de arquivo do log estendido do W3C) deverá ser ativado, e log arquivos baixados via FTP. Estão são as etapas a serem seguidas:

Acesso manage.windowsazure.com.
Selecione Sites da Web e o site específico que precisa ser configurado.
Clique em Configure e role para baixo até a seção "diagnóstico do site". Ative log do servidor Web.
Você pode baixar os logs do /LogFiles/http/RawLogs. Log Parser 2.2, disponível a partir do Microsoft Download Center (bit.ly/119mefJ), podem ser usados para analisar e consulta IIS logs.

Como com os serviços de nuvem do Windows Azure, informações de arquivos de log podem ser usadas para determinar o uso dos recursos pelos inquilinos diferentes, seguindo parâmetros de URL ou diretórios virtuais individuais.

Como um serviço de medição

Além das opções de diagnóstico fornecidas nativamente pelo Windows Azure, algumas empresas oferecem serviços de medição para o Windows Azure. Por exemplo, a Dell Inc. criou um produto chamado Foglight que fornece dados em tempo real sobre a saúde dos aplicativos e laços de volta para o UX. Ele também inclui um serviço de notificação que avisa os desenvolvedores de problemas críticos. Hoje, a névoaluz suporta serviços em nuvem e Windows Azure SQL Database, com base na infra-estrutura do WAD, como mostrado na Figura 5.

Figura 5 o Foglight Dell monitoramento Portal

AutoScaling opções

Uma vez que foram coletados os dados do contador de desempenho e de medição, ele pode ser usado para determinar o nível de provisionamento que é necessária para atender aos requisitos de desempenho do aplicativo. AutoScaling no Windows Azure refere-se ao ato de adição ou subtração de instâncias de uma implantação específica (escalar), com a idéia de manter soluções ativo e funcionando para o menor custo possível. Mesmo que seja possível ampliar (aumentar os recursos para uma única máquina), isto implica geralmente de inatividade do aplicativo, que nunca é desejável. Existem basicamente três maneiras de autoscale uma implantação do Windows Azure.

Use um Autoscaling Block uma abordagem ao autoscaling uma implantação do Windows Azure, que aplica-se especificamente para o Windows Azure Cloud Services, é adicionar um bloco de aplicação autoscaling à solução. Há um par de bibliotecas pronto-para-ser-usado para essa finalidade. Uma biblioteca é parte do Enterprise Integration Pack para o Windows Azure, e ele usa um conjunto de regras definidas pelo usuário, Configurando limites para o número mínimo e máximo de instâncias de função na implantação com base em contadores ou medições coletadas pelo WAD. Esta abordagem tem sido extensivamente documentada pelos padrões de Microsoft & práticas de equipe e pode ser encontrado em bit.ly/18cr5mD. Figura 6 mostra uma arquitetura para múltiplos inquilinos básica com um bloco de autoscaling adicionado à solução.

Figura 6 usando um aplicativo Autoscaling bloquear abordagem para serviços em nuvem

Usar um serviço externo existem alguns serviços de dimensionamento-out disponíveis para implantações do Windows Azure que atuam como blocos de aplicativos externos autoscaling. Recentemente, a Microsoft adquiriu MetricsHub (metricshub.com), que fornece um serviço de monitoramento e autoscaling gratuito para assinantes do Windows Azure. A lógica para escalar é baseada em médias sustentadas, principais indicadores, dados à direita e horários específicos. Você pode adicionar o serviço diretamente do portal de gerenciamento na seção de Complementos (Windows Azure loja). MetricsHub suporta os serviços de nuvem do Windows Azure e Windows Azure Virtual máquinas, baseado em uma arquitetura que extrai informações de WAD e recebe informações de agentes instalados em única instâncias com monitoração de estado (ver Figura 7).

Figura 7 MetricsHub arquitetura

Uma vez que o serviço foi criado, o portal MetricsHub oferece diferentes limiares para a manutenção de um ambiente de nuvem saudável, baseado em parâmetros como alvo gama de CPU e o número de mensagens em uma fila. Ele também fornece um custo previsão antes e depois de aplicar as opções autoscaling, verdadeiramente automatizar o provisionamento processar da maneira mais inteligente possível, equilibrar o custo com desempenho (ver Figura 8).

Figura 8 o MetricsHub arquitetura Autoscaling Portal

Use o Windows Automated Scripts do PowerShell, o terceiro método é baseado em scripts do Windows PowerShell que são manualmente criados e executados diretamente contra o API de gerenciamento do Windows Azure. Essa abordagem fornece um alto nível de controle e flexibilidade, porque esses scripts podem ser usados dentro de aplicativos personalizados ou estruturas de integração contínua. Além disso, os cmdlets do Windows PowerShell para Windows Azure apoiar os modelos de implantação de três, incluindo a automação do processo de provisionamento para Sites da Web do Windows Azure. Por exemplo, alterando o número de instâncias para uma implantação específica é tão fácil quanto executar o seguinte comando:

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

Para obter instruções sobre como configurar e instalar o Windows Azure cmdlets, consulte bit.ly/QqctsU. Você pode encontrar documentação sobre como usar cada um dos cmdlets no bit.ly/U0vOEp.

Conclusão

Este artigo conclui nossa série two-part na construção de soluções para vários inquilinos no Windows Azure. Além do isolamento de identidade e dados no primeiro artigo, apresentamos-te para o processo de configuração e extrair informações sobre o desempenho de cada um dos modelos de implantação do Windows Azure — serviços de nuvem, máquinas virtuais e Web Sites. Ao mesmo tempo, analisamos três maneiras diferentes de implantações autoscaling através de componentes internos e externos e serviços. Aproveitando o modelo econômico de nuvem — que é baseado no custo de uso e pools de recursos compartilhados — mais empresas estão lançando soluções que podem ser eficientemente adaptadas às suas necessidades.

Bruno Terkaly é desenvolvedor e divulgador da Microsoft. Seu profundo conhecimento é fruto de anos de experiência no campo, escrevendo código com uma grande quantidade de plataformas, linguagens, estruturas, SDKs, bibliotecas e APIs. Ele gasta tempo escrevendo código, blogar e fazer apresentações ao vivo na construção de aplicativos baseados em nuvem, especificamente usando a plataforma Windows Azure. Você pode ler seu blog em blogs.msdn.com/b/brunoterkaly.

Ricardo Villalobos is a seasoned software architect with more than 15 years of experience designing and creating applications for companies in the supply chain management industry. Segurando diferentes certificações técnicas, bem como um mestrado em Administração pela Universidade de Dallas, ele trabalha como arquiteto de nuvem no grupo de incubação Windows Azure CSV para Microsoft. Você pode ler seu blog em blog.ricardovillalobos.com.

Terkaly e Villalobos conjuntamente apresentar conferências da indústria em geral. Eles incentivam os leitores do Windows Azure Insider contatá-los para disponibilidade. Terkaly pode ser contatado em bterkaly@microsoft.com e Villalobos pode ser contatado em Ricardo.Villalobos@microsoft.com.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Trent Swanson (escala completa 180)
Trent Swanson é um arquiteto de software e diretor trabalhando com cloud e tecnologias de grande volume de dados em escala 180 graus. Eu tenho trabalhado com o Windows Azure desde o início, ajudando os clientes à criação do mundo, implantar e gerenciar suas soluções de nuvem Windows Azure. Se está se movendo um aplicativo existente para a nuvem ou construindo novos, desfrutar de todo o ciclo de fornecimento de soluções de nuvem escalável, gerenciável e confiável no Windows Azure. Quando não trabalhando em projetos desafiadores e interessantes, também gosto de passar tempo na Academia, artes marciais mistas, apoiar pequenas empresas locais e ser ativo na minha igreja.