Exportar (0) Imprimir
Expandir Tudo

Atualizar um serviço do Azure

Atualizado: maio de 2014

O Azure organiza suas instâncias de função em agrupamentos lógicos chamados de domínios de atualização. O número padrão de domínios de atualização é 5. É possível especificar um número diferente de domínios de atualização incluindo o atributo upgradeDomainCount no arquivo de definição do serviço (.csdef). Para obter mais informações sobre o upgradeDomainCount atributo, consulte Esquema WebRole ou Esquema WorkerRole.

Quando você executa uma atualização in-loco de uma ou mais funções em seu serviço, o Azure atualiza conjuntos de instâncias de função de acordo com o domínio de atualização ao qual pertencem. O Azure atualiza todas as instâncias de um determinado domínio de atualização, interrompendo-as, atualizando-as, colocando-as online novamente e, em seguida, move para o próximo domínio. Ao parar somente as instâncias que são executadas no domínio de atualização atual, o Azure garante que uma atualização ocorra com o menor impacto possível no serviço em execução. Para obter mais informações, consulte How the update proceeds mais adiante neste artigo.

noteObservação
Embora os termos atualização e upgrade tenham significados levemente diferentes no contexto do Azure, os dois podem ser usados de maneira intercambiável para os processos e descrições dos recursos deste documento.

Seu serviço deve definir pelo menos duas instâncias de uma função para que ela seja atualizada in-loco sem tempo de inatividade. Se o serviço consistir em apenas uma instância de uma função, o serviço não estará disponível até que a atualização in-loco seja concluída.

Este tópico abrange as seguintes informações sobre atualizações do Azure:

A tabela a seguir mostra as alterações permitidas para um serviço durante uma atualização:

 

Alterações permitidas para hospedagem, serviços e funções Atualização in-loco Preparada (permuta de VIP) Exclusão e nova implantação

Versão do sistema operacional

Sim

Sim

Sim

Nível de confiança do .NET

Sim

Sim

Sim

Tamanho da máquina virtual

Sim

WarningAviso
A alteração do tamanho da máquina virtual destruirá os dados locais.

noteObservação
Exige o SDK do Azure 1.5 ou versões posteriores.

Sim

Sim

Configurações do armazenamento local

Sim

Apenas aumento.

noteObservação
Exige o SDK do Azure 1.5 ou versões posteriores.

Sim

Sim

Adicionar ou remover funções em um serviço

Sim

Sim

Sim

Número de instâncias de uma função específica

Sim

Sim

Sim

Número ou tipo de pontos de extremidade para um serviço

Sim

noteObservação
Exige o SDK do Azure 1.5 ou versões posteriores.

ImportantImportante
A disponibilidade pode ser temporariamente perdida enquanto os pontos de extremidade são atualizados.

Não

Sim

Nomes e valores de parâmetros da configuração

Sim

Sim

Sim

Valores (mas não nomes) de parâmetros da configuração

Sim

Sim

Sim

Adicionar novos certificados

Sim

Sim

Sim

Alterar certificados existentes

Sim

Sim

Sim

Implantar novo código

Sim

Sim

Sim

Os seguintes itens não têm suporte durante uma atualização:

  • Alteração do nome de uma função. Remoção e alteração subsequente de uma função com o novo nome.

  • Alteração da contagem de domínios de atualização.

  • Redução do tamanho dos recursos locais.

Se você estiver fazendo outras atualizações à definição de seu serviço, como a redução do tamanho de um recurso local, deverá executar uma atualização de troca de VIP. Para obter mais informações, consulte Gerenciar atualizações para o sistema operacional convidado do Azure.

O Azure fornece flexibilidade para gerenciar serviços durante uma atualização permitindo que você inicie operações adicionais em um serviço, após a solicitação inicial de atualização ser aceita pelo Controlador de Malha do Azure. Uma reversão pode ser executada apenas quando uma atualização (alteração da configuração) ou upgrade está no estado em andamento na implantação. Uma atualização ou upgrade é considerada como estando em andamento quando há pelo menos uma instância do serviço que ainda não foi atualizada para a nova versão. Para testar se uma reversão é permitida, verifique se o valor do sinalizador de RollbackAllowed, retornado pelas operações Obter implantação e Obter propriedades do serviço de nuvem, está definido como true.

noteObservação
Faz sentido chamar a Reversão apenas em uma atualização in-loco ou upgrade pois as atualizações de permuta de VIP envolvem a substituição de uma instância em execução inteira de seu serviço por outra.

A reversão de uma atualização em andamento tem os seguinte efeitos na implantação:

  • Quaisquer instâncias de função que ainda não tiverem sido atualizadas para a nova versão não serão atualizadas, uma vez que essas instancias já estão executando a versão de destino do serviço.

  • Quaisquer instâncias de função que já tiverem sido atualizadas para a nova versão do arquivo do pacote de serviço (*.cspkg) e ou arquivo de configuração de serviço (*.cscfg) (ou os dois arquivos) serão revertidas de volta para a versão de pré-atualização desses arquivos.

Essa funcionalidade é fornecida pelos seguintes recursos:

  • A operação Atualização de reversão, que pode ser chamada em uma atualização da configuração (disparada pela chamada de Alterar configuração de implantação) ou um upgrade (disparado pela chamada de Atualizar implantação) contanto que haja pelo menos uma instância no serviço que ainda não tenha sido atualizada para a nova versão.

  • O elemento Locked e o elemento RollbackAllowed, que são retornados como parte do corpo da resposta das operações Obter implantação e Obter propriedades do serviço de nuvem:

    1. O elemento Locked permite detectar quando uma operação mutante pode ser invocada em uma determinada implantação.

    2. O elemento RollbackAllowed permite detectar quando a operação Atualização de reversão pode ser chamada em uma determinada implantação.

    Para executar uma reversão, não é necessário marcar os dois elementos Locked e RollbackAllowed. Basta confirmar se RollbackAllowed está definido como true. Esses elementos apenas serão retornados se esses métodos forem invocados usando-se o cabeçalho da solicitação definido como “x-ms-version: 2011-10-01” ou uma versão posterior. Para obter mais informações sobre cabeçalhos de controle de versão, consulte Controle de versão de gerenciamento de serviço.

Há algumas situações em que não há suporte para a reversão de uma atualização ou upgrade. São elas:

  • Redução em recursos locais - se a atualização aumentar os recursos locais de uma função, a plataforma Azure não permitirá a reversão. Para obter mais informações sobre como configurar recursos locais para uma função, consulte Configuração de recursos de armazenamento local.

  • Limitações de cota - se a atualização foi uma operação de redução, você talvez não tenha mais cota de computação suficiente para concluir a operação de reversão. Cada assinatura do Windows Azure tem uma cota associada que especifica o número máximo de núcleos que podem ser consumidos por todos os serviços hospedados que pertencem a essa assinatura. Se a execução de uma reversão de uma determinada atualização colocar sua assinatura acima da cota, a reversão não será habilitada.

  • Condição de corrida - se a atualização inicial tiver sido concluída, uma reversão não será possível.

Um exemplo de quando a reversão de uma atualização pode ser útil é quando você está usando a operação Atualizar implantação em modo manual para controlar a corrida na qual uma atualização in-loco maior de seu serviço hospedado do Azure está revertida.

Durante a reversão da atualização você chama Atualizar implantação em modo manual e começa a percorrer os domínios de atualização. Se em algum ponto, conforme monitora a atualização, você observar que algumas instâncias de função nos primeiros domínios de atualização que examina se tornaram sem resposta, você poderá chamar a operação Atualização de reversão na implantação, o que não alterará as instâncias que ainda não foram atualizadas e reverterá as instâncias que foram atualizadas para o pacote e a configuração do serviço anterior.

Em alguns casos, você pode querer iniciar várias operações de mutação simultâneas em uma implantação em andamento. Por exemplo, você pode executar uma atualização de serviço e, enquanto essa atualização está sendo revertida no serviço, desejar fazer uma alteração como, por exemplo, reverter a atualização, aplicar outra atualização ou até excluir a implantação. Isso pode ser necessário quando uma atualização de serviço contiver um código com bug que faça com que uma instância de função atualizada apresente falha repetidamente. Nesse caso, o Controlador de Malha do Azure não poderá progredir com a aplicação dessa atualização porque um número insuficiente de instâncias no domínio atualizado estão íntegras. Esse estado é conhecido como uma implantação paralisada. Você pode resolver a paralisação com a reversão da atualização ou com a aplicação de uma nova atualização sobre a atualização com falha.

Assim que a solicitação inicial para atualizar o serviço for recebida pelo Controlador de Malha do Azure, você poderá invocar operações de mutação subsequentes. Isto é, você não terá que esperar que a operação inicial seja concluída antes de poder invocar outra operação de mutação.

O início de uma segunda operação de atualização enquanto a primeira atualização está em andamento terá um desempenho semelhante à operação de reversão. Se a segunda atualização estiver em modo automático, o primeiro domínio de atualização serão atualizado imediatamente, possivelmente fazendo com que vários domínios de atualização fiquem offline no mesmo instante.

As operações de mutação são as seguintes: Alterar configuração de implantação, Atualizar implantação, Atualizar status da implantação, Excluir implantação e Atualização de reversão.

Duas operações, Obter implantação e Obter propriedades do serviço de nuvem, retornam o sinalizador Locked, que pode ser examinado para determinar se uma operação de mutação pode ser invocada em uma determinada implantação.

Para chamar a versão desses métodos que retorna o sinalizador Locked, você deve definir o cabeçalho da solicitação como “x-ms-version: 2011-10-01” ou posterior. Para obter mais informações sobre cabeçalhos de controle de versão, consulte Controle de versão de gerenciamento de serviço.

O Azure distribui instâncias de uma função uniformemente em um número definido de domínios de atualização, que pode ser configurado como parte do arquivo de definição (.csdef). O número máximo de domínios de atualização é 20, e o padrão é 5. Para obter mais informações sobre como modificar o arquivo de definição de serviço, consulte Esquema de definição de serviço do Azure (arquivo .csdef).

Por exemplo, se sua função tiver dez instâncias, por padrão cada domínio de atualização conterá duas instâncias. Se sua função tiver 14 instâncias, quatro dos domínios de atualização conterão três instâncias e um quinto domínio conterá duas.

Os domínios de atualização são identificados com um índice baseado em zero: o primeiro domínio de atualização tem uma ID de 0, o segundo tem uma ID de 1, e assim por diante.

O diagrama a seguir ilustra como um serviço que contém duas funções que são distribuídas quando o serviço define dois domínios de atualização. O serviço está executando oito instâncias da função web e nove instâncias da função de trabalho.

Distribuição de domínios de atualização

noteObservação
Observe que o Azure controla como as instâncias são alocadas nos domínios de atualização. Não é possível especificar quais instâncias são alocadas para qual domínio.

Você pode decidir se deseja atualizar todas ou uma única função dentro em seu serviço. Em qualquer caso, todas as instâncias de cada função que estão sendo atualizadas e que pertençam ao primeiro domínio de atualização são paradas, atualizadas e colocadas online. Quando eles forem colocados online, as instâncias no segundo domínio de atualização serão paradas, atualizadas e colocadas online.

O diagrama seguinte ilustra como a atualização será continuada se você estiver atualizando todas as funções no serviço:

Serviço de atualização

Este próximo diagrama ilustra como a atualização procederá se você estiver atualizando somente uma única função:

Função de atualização
noteObservação
Ao atualizar um serviço de uma para várias instâncias, seu serviço será interrompido durante o processo devido à maneira como o Windows Azure atualiza os serviços. O contrato de nível de serviço que garante a disponibilidade de serviço se aplica apenas aos serviços que são implantados com mais de uma instância. A lista a seguir descreve como os dados em cada unidade são afetados devido a cada cenário de atualização dos serviços do Windows Azure:

Reinicialização da VM:

  • C: Preservados

  • D: Preservados

  • E: Preservados

Reinicialização do portal:

  • C: Preservados

  • D: Preservados

  • E: Destruídos

Imagem do portal refeita:

  • C: Preservados

  • D: Destruídos

  • E: Destruídos

Atualização in-loco:

  • C: Preservados

  • D: Preservados

  • E: Destruídos

Migração do nó:

  • C: Destruídos

  • D: Destruídos

  • E: Destruídos

Observe que, na lista acima, a unidade E: representa a unidade raiz da função e não deve ser embutida em código. Em vez disso, use a variável de ambiente %RoleRoot% para representar a unidade.

Para minimizar o tempo de inatividade ao atualizar um serviço de uma instância única, implante um novo serviço de várias instâncias para o servidor de teste e executar uma permuta de VIP.

A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft