Este artigo foi traduzido por máquina.

Previsão: Mostly cloudy

Domínios de implantação do Windows Azure

Joseph Fultz

Ultimamente, eu estive dando um monte de pensamento para a implantação de aplicativos. Gira para fora que para aplicações, a matriz para caminho de tolerância e de atualização falha fica um pouco complicada — e ainda mais complicado quando aplicativos têm uma combinação de processos de serviços, uma interface de usuário da Web e back-end. Adicionar na distribuição geográfica e a logística tornam-se ainda mais enlameada.

Em grandes organizações de TI, uma implantação mínima de qualquer Web ou aplicativo servidor muitas vezes envolve dois servidores que estão geograficamente separados. Isso move com facilidade até quatro servidores se dois servidores são especificados para a carga esperada e você tem um site de espelhamento com a mesma configuração (naturalmente, outra comprovativos infra-estrutura de servidor e banco de dados podem empurrar o número ainda mais elevado). O que acontece se a empresa atende a vários locais, como a América do Norte e Europa, Oriente Médio e África (EMEA)? Agora a instalação Obtém replicada para ambos os lados do Atlântico, transformar o que começou como dois servidores Web em oito servidores para failover de geo e preparo activos mais perto dos consumidores.

Eventualmente, um aplicativo é implantado em todos esses servidores e tudo está funcionando perfeitamente — e, em seguida, algum desenvolvedor atrevido cria nova funcionalidade e quer atualizar a implantação.

Como você pode imaginar, demora um bom bocado de planejamento para determinar a ordem em que servidores irá drenar ligações, obter atualizados e testados e, em seguida, ser posto para trás na piscina. Algumas pessoas gastam noites trabalhando através de planos de atualização, e que é mesmo quando não existem problemas reais.

Windows Azure não elimina a necessidade de um plano de atualização, mas faz exame de muita da complexidade do upgrade por manipulação mais do mesmo como parte do tecido. Nesta coluna, eu estou indo para cobrir falhas domínios e atualização e escrever um pouco de código para aplicar uma atualização em toda a implantação.

Atualização de domínios e a falhas

Windows Azure inclui os conceitos de culpa domínios e atualização, tanto dos que são quase totalmente descritos por seus nomes. Domínios de falhas definem uma unidade física de implantação para um aplicativo e normalmente são alocados no nível da cremalheira. Colocando domínios falha em prateleiras separadas, você separa instâncias de implantação de aplicativos de hardware suficiente que é improvável que tudo iria falhar ao mesmo tempo. Além disso, uma falha no domínio de uma avaria não deve precipitar o fracasso de outro. Quando você implantar uma função com duas instâncias configuradas, o tecido garante que as instâncias são levantadas em dois domínios diferentes falhas. Infelizmente, com domínios de falha, você não tem controle sobre quantos domínios são usados ou como papéis são atribuídos a eles.

Domínios de atualização são outro assunto. Você tem controle sobre esses domínios e pode executar atualizações incrementais ou rolamento em uma implantação com a atualização de um grupo de instâncias de cada vez. Considerando que os domínios de falha são sobre implantação física dos papéis, atualização de domínios dizem respeito à implantação lógica. Como um domínio de atualização é um agrupamento lógico de funções, um único aplicativo Web facilmente poderia existir em cinco diferentes domínios atualização divididos em apenas duas implantações físicas separadas (domínios de falha). Neste caso, para atualizar um aplicativo da Web, você pode atualizar todas as funções no grupo 0 (atualização domínio 0) e, em seguida, todas as funções no grupo 1 e assim por diante. Você pode exercer mais controle finito atualizando funções individuais, um por vez em cada domínio de atualização.

Em resumo, um aplicativo que requer mais de uma instância será dividido em, pelo menos, dois domínios de culpa. Para tornar a atualização de um aplicativo da Web através de toda a exploração mais fácil, são combinadas em agrupamentos lógicos que são atualizados ao mesmo tempo.

Exibindo a configuração de implantação

O Console de gerenciamento do Windows Azure mostra uma coluna de atualização de domínio, mas não uma coluna de domínio falha (ver Figura 1). (Note-se que atualizar o domínio e atualizar o domínio são termos intercambiáveis. A documentação muitas vezes refere-se a atualizar domínios, mas na API é chamado um domínio atualização.)

Figura 1 Console de gerenciamento Azure do Windows

Em Figura 1você pode ver que os números para meus quatro implantações compreendido entre 0 e 3. Por padrão, o Windows Azure usa cinco domínios de atualização para cada serviço e atribui-los em um estilo de rodízio. Isso é algo que você pode alterar no arquivo de definição de serviço, atribuindo o número desejado de domínios de atualização para o atributo upgradeDomainCount do elemento ServiceDefinition. Você encontrará links para cada um dos esquemas para funções de Web e trabalhador no msdn.microsoft.com/library/ee758711. Para forçar um WebRole para usar somente três domínios de atualização, por exemplo, você definir a upgradeDomainCount no arquivo de definição de serviço:

<ServiceDefinition name="<service-name>" xmlns=”https://schemas.microsoft.com/ServiceHosting/2008/10/
      ServiceDefinition” upgradeDomainCount="3">
  <WebRole name="<web-role-name>" vmsize="[ExtraSmall|Small|Medium|Large|ExtraLarge]"
    enableNativeCodeExecution="[true|false]">
    ...
</WebRole>
</ServiceDefinition>

Isto é importante, porque o número de domínios de atualização afeta em última análise, o plano e execução. Infelizmente, não há nenhuma coluna que lhe permite ver atribuições de domínio falha. Ao escrever um pouco de código, no entanto, você pode puxar a cortina um pouco sobre a implantação e ver ambos atualizar atribuições de domínio do domínio e falhas, como Figura 2 mostra.

Figura 2 Localizando informações de função

protected void GetRoleInfo()
{
  List<RoleInfo> RoleInfos = new List<RoleInfo>();

  foreach (var role in RoleEnvironment.Roles)
  {
    RoleInfo info = new RoleInfo();
    info.RoleName = role.Value.Name;

    foreach (RoleInstance roleInstance in role.Value.Instances)
    { 
      info.InstanceId = roleInstance.Id;
      info.FaultDomain = roleInstance.FaultDomain.ToString();
      info.UpgradeDomain = roleInstance.UpdateDomain.ToString();
           
    }
    RoleInfos.Add(info);
  }
  GridView1.DataSource = RoleInfos;
  GridView1.DataBind();

}

Este código não mostra uma pequena classe que i definida para armazenar todas as informações pertinentes. E infelizmente, apesar de eu ter este loop aninhado agradável que atravessa os papéis e as instâncias, a API permite que o código executando na página para retornar dados relacionados apenas à instância específica a execução do código. Assim, o código produz uma pequena grade com apenas as informações atuais de WebRole nele (ver Figura 3), sem qualquer outra informação de instância.

Figura 3 atual WebRole informações

Este código fornece um olhar rápido em domínios de falha e a atualização do WebRole atual, mas você vai precisar usar o URI de resto de implantação obter para obter dados mais abrangentes. Ele retorna a implantação XML, que contém, entre outras coisas, elementos para <Configuration/> e para cada um do <RoleInstances/>. Uma vez que você tenha buscado a configuração, você pode alterá-lo e colocá-lo de volta. Dê uma olhada na minha coluna de outubro de 2010 (msdn.microsoft.com/magazine/gg232759) para obter exemplos que mostram muitas das operações mesmas que estaria envolvidas aqui.

Estratégias de atualização

Existem duas estratégias básicas para atualizar uma implantação de Windows Azure: atualizações in-loco e troca virtual de IP (ou VIP). VIP swap é a abordagem mais simples e permite o teste completo do aplicativo novo ou atualizado antes de abrir as portas ao público. Além disso, o aplicativo pode ser executado em plena capacidade, logo é ao vivo. Deve haver problemas quando a troca for concluída, você pode rapidamente colocar a versão anterior volta no lugar enquanto a nova implantação está sendo trabalhada.

Você vai encontrar uma boa referência que descreve o que pode e não pode ser feito em cada modelo de implantação na bit.ly/x7lRO4. Aqui estão os pontos que podem forçar uma escolha:

• Atualização in-loco ou excluir e implantar são necessários para alterar o tipo ou número de pontos de extremidade.
• VIP trocar ou excluir e implantar são necessários quando alterar a contar de domínio de nome ou atualização da função, ou quando diminuir o tamanho dos recursos locais.

Além destes pontos e algumas considerações de versão do SDK, cabe a você decidir.

Trocar o VIP dos ambientes de teste e produção é uma solução muito boa para muitos, se não mais, casos quando lançar uma nova versão. Às vezes é a única maneira de manter o site na maior parte disponível ao fazer alterações, embora se você estiver atualizando uma implantação de grande porte, trazendo uma outra implantação completa pode ser complicada. Também há um custo associado com a implantação de uma cópia completa — uma computação hora cobram para cada instância e, em seguida, as horas de computação adicional para as duas cópias em execução implantados.

Em farms da Web hoje em dia, atualizações são geralmente desenroladas através de um farm por um ou outro: tendo um servidor off-line em um momento, atualizando, colocar o servidor online e enviá-lo para o pool de fazenda; ou dividir a fazenda em segmentos e drenando as conexões em um segmento de cada vez e, em seguida, atualizar cada segmento, colocá-lo online e retorná-lo ao farm e finalmente passar para o próximo segmento.

Uma atualização in-loco funciona como o segundo padrão. No entanto, quanto mais atualizar domínios usados, quanto mais o padrão assemelha-se a primeira opção. A cabeça do uso de um maior número de domínios de atualização é que a capacidade do site diminui apenas pelo tamanho do segmento durante a atualização inteira.

O principal desafio que enfrentam as implantações tradicionais de nuvem não é o mesmo para implantações de nuvem: Quando você executa atualizações sem interrupção, mistos versões do aplicativo serão executado. As instâncias podem fornecer diferentes efeitos visuais, usar dados diferentes e conexões de serviço e assim por diante. Isso pode levar a erros de site ou experiências de usuário mesmo indesejáveis, e pode ser completamente inaceitável para o seu negócio. Além disso, ele coloca uma carga pesada sobre as equipes de desenvolvimento e teste para certificar-se de que o aplicativo será executado quando há várias versões em jogo.

O que você faz se você não pode usar swap VIP e requisitos de disponibilidade impedem uma exclusão e implantar? Você pode tentar usar apenas dois domínios de atualização e executar uma atualização no local, que mantém uma única versão do aplicativo em execução durante a implantação. A desvantagem: metade da capacidade do seu site vai estar disponível durante o período de transição.

A grade em Figura 4 pode ajudá-lo a considerar qual abordagem empregar em executar uma atualização.

Figura 4 atualização decisão Matrix

Atualização in-loco

Agradáveis avanços foram feitos na capacidade de realizar o upgrade dentro do console de gerenciamento e por meio de scripting. Para pequenas para organizações de médio porte com um número relativamente modesto de implantações, é mais fácil gerenciar as atualizações através do Console de gerenciamento do Windows Azure, mostrado na Figura 5.

Figura 5 Windows Azure Management Console

Como você pode ver no canto superior esquerdo da tela, um Manual de Upgrade está sendo executado. Isso requer o clique no botão Iniciar para iniciar o processo para cada domínio atualização — que é a parte manual do mesmo. Uma vez que a actualização é iniciada, o console exibe o que está acontecendo nas ocorrências em cada domínio, conforme mostrado na Figura 6.

Figura 6 a atividade de atualização

O manual, botão pulsador método funciona bem para implantações menores. Para implantações maiores, ou aqueles onde deseja automatizar o processo de implantação de teste de compilação, você deve escolher uma abordagem com scripts. Você pode automatizar o processo usando a ferramenta de linha de comando CSManage, que você pode baixar de bit.ly/A6uQRi. CSManage irá iniciar a actualização e percorrer o processo de upgrade de uma atualização de domínio cada vez a partir da linha de comando. Embora isso seja útil, não há um nível de controle fino que só pode ser feito usando a API REST diretamente.

Personalizar a estratégia de atualização com falha domínios

Se, por uma razão ou outra que você decidiu não andar os atualização de domínios de 0 – n e em vez disso, planeja usar o seu próprio ponto de partida ou ordem, você precisará ter um olhar para a combinação de domínios de atualização e de falhas. A grade em Figura 7 faz com que seja óbvio que se você atualizar atualizar o domínio 1, e falha de domínio 0 com defeito durante a atualização, o site seria completamente para baixo. Isso normalmente deve ser abrangido pela malha, embora, e a grade mostra que se a atualização ocorrer em ordem, sempre haverá domínios diferentes falhas executando.

Figura 7 domínio Matrix

A lição aqui é considerar potenciais consequências durante o planejamento e não "corrigir" algo que já está a trabalhar.

Resumindo

Quando você estiver criando um aplicativo Windows Azure, você precisará considerar a arquitetura de implantação. Windows Azure fornece a funcionalidade do tecido para garantir que um aplicativo não será falha devido a uma falha de hardware único, ao mesmo tempo, fornecendo uma maneira fácil e automática de atualização incremental a implantação. Ainda assim, o suporte para uma atualização no local é algo que tem de ser concebido para o aplicativo — e a atualização do está sendo enviada.

Você pode atualizar um serviço Windows Azure usando VIP swap ou um plano de dois actualização de domínios, no local onde uma atualização completa no local não é suportada. Por último, há interface do usuário e programáticos meios para controlar a implantação e atualizações para que você pode executar uma atualização agendada ou até mesmo usar uma agenda de implantação de teste de compilação ou uma atualização agendada.

Joseph Fultz é arquiteto de software da Hewlett-Packard Co. e trabalha no grupo de TI global do HP.com. Anteriormente ele era arquiteto de software da Microsoft e trabalha com o seu top-tier clientes corporativos e ISV definindo soluções de arquitetura e design.

Graças ao seguinte especialista técnico para revisão deste artigo: Don Glover