Como atualizar um Serviço de Nuvem do Azure (clássico)
Importante
Os Serviços na Nuvem (clássicos) foram preteridos para todos os clientes a partir de 1º de setembro de 2024. Todas as implantações em execução existentes serão interrompidas e encerradas pela Microsoft e os dados serão perdidos permanentemente a partir de outubro de 2024. Novas implantações devem usar o novo modelo de implantação baseado no Azure Resource Manager Serviços de Nuvem do Azure (suporte estendido).
O processo para atualizar um serviço de nuvem, incluindo suas funções e o sistema operacional convidado, leva três etapas. Primeiro, os binários e os arquivos de configuração para o novo serviço de nuvem ou versão do sistema operacional devem ser carregados. Em seguida, o Azure reserva recursos de computação e rede para o serviço de nuvem com base nos requisitos da nova versão do serviço de nuvem. Por fim, o Azure executa uma atualização contínua para atualizar incrementalmente o locatário para a nova versão ou SO convidado, preservando sua disponibilidade. Este artigo discute os detalhes desta última etapa – a atualização contínua.
Atualizar um serviço do Azure
O Azure organiza suas instâncias de função em agrupamentos lógicos chamados domínios de atualização (UD). Domínios de atualização (UD) são conjuntos lógicos de instâncias de função que são atualizados como um grupo. O Azure atualiza um serviço de nuvem uma UD de cada vez, o que permite que instâncias em outras UDs continuem servindo tráfego.
O número padrão de domínios de atualização é 5. Você pode 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 atributo upgradeDomainCount, consulte Esquema de definição dos Serviços de Nuvem do Azure (arquivo .csdef).
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 elas pertencem. O Azure atualiza todas as instâncias em um determinado domínio de atualização, interrompendo-as, atualizando-as, trazendo-as de volta on-line e, em seguida, passa para o próximo domínio. Ao interromper apenas as instâncias em execução 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 Como a atualização prossegue mais adiante neste artigo.
Nota
Embora os termos atualização e atualização tenham um significado ligeiramente diferente no contexto do Azure, eles podem ser usados de forma intercambiável para os processos e descrições dos recursos neste documento.
Seu serviço deve definir pelo menos duas instâncias de uma função para que essa função 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 ficará indisponível até que a atualização in-loco seja concluída.
Este artigo aborda as seguintes informações sobre atualizações do Azure:
- Alterações de serviço permitidas durante uma atualização
- Como procede uma atualização
- Reversão de uma atualização
- Iniciando várias operações de mutação em uma implantação contínua
- Distribuição de funções entre domínios de atualização
Alterações de serviço permitidas durante uma atualização
A tabela a seguir mostra as alterações permitidas em um serviço durante uma atualização:
| Alterações permitidas para hospedagem, serviços e funções | Atualização in-loco | Encenado (troca VIP) | Excluir e reimplantar |
|---|---|---|---|
| Versão do sistema operativo | Sim | Sim | Sim |
| Nível de confiança do .NET | Sim | Sim | Sim |
| Tamanhoda máquina virtual 1 | Sim2 | Sim | Sim |
| Configurações de armazenamento local | Aumentar apenas2 | 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 | Sim2 | No | Sim |
| Nomes e valores das definições de configuração | Sim | Sim | Sim |
| Valores (mas não nomes) das definições de configuração | Sim | Sim | Sim |
| Adicionar novos certificados | Sim | Sim | Sim |
| Alterar certificados existentes | Sim | Sim | Sim |
| Implantar novo código | Sim | Sim | Sim |
1 Alteração de tamanho limitada ao subconjunto de tamanhos disponíveis para o serviço de nuvem.
2 Requer o SDK do Azure 1.5 ou versões posteriores.
Aviso
Alterar o tamanho da máquina virtual destruirá os dados locais.
Os seguintes itens não são suportados durante uma atualização:
- Alterar o nome de uma função. Remova e adicione a função com o novo nome.
- Alteração da contagem de Domínio de Atualização.
- Diminuir o tamanho dos recursos locais.
Se você fizer outras atualizações na definição do seu serviço, como diminuir o tamanho do recurso local, deverá executar uma atualização de troca VIP. Para obter mais informações, consulte Implantação de permuta.
Como procede uma atualização
Você pode decidir se deseja atualizar todas as funções em seu serviço ou uma única função no serviço. Em ambos os casos, todas as instâncias de cada função que está sendo atualizada e pertencem ao primeiro domínio de atualização são interrompidas, atualizadas e colocadas online novamente. Quando estiverem online novamente, as instâncias no segundo domínio de atualização serão interrompidas, atualizadas e colocadas online novamente. Um serviço de nuvem pode ter no máximo uma atualização ativa de cada vez. A atualização é sempre realizada em relação à versão mais recente do serviço de nuvem.
O diagrama a seguir ilustra como a atualização prossegue se você atualizar todas as funções no serviço:
Este diagrama seguinte ilustra como a atualização prossegue se você atualizar apenas uma única função:
Durante uma atualização automática, o Azure Fabric Controller avalia periodicamente a integridade do serviço de nuvem para determinar quando é seguro percorrer a próxima UD. Essa avaliação de integridade é realizada por função e considera apenas instâncias na versão mais recente (ou seja, instâncias de UDs que já foram executadas). Verifica se, para cada função, um número mínimo de instâncias de função atingiu um estado terminal satisfatório.
Tempo limite de início da instância de função
O Fabric Controller aguarda 30 minutos para que cada instância de função atinja um estado Iniciado. Se a duração do tempo limite passar, o Fabric Controller continuará caminhando para a próxima instância de função.
Impacto na condução de dados durante as atualizações do Serviço de Nuvem
Quando você atualiza um serviço de uma única instância para várias instâncias, o Azure reduz seus serviços enquanto a atualização é executada. O contrato de nível de serviço que garante a disponibilidade do serviço só se aplica a serviços implantados com mais de uma instância. A lista a seguir descreve como cada cenário de atualização de serviço do Azure afeta os dados em cada unidade:
| Cenário | Movimentação C | Acionamento D | E Acionamento |
|---|---|---|---|
| Reinicialização da máquina virtual (VM) | Preservado | Preservado | Preservado |
| Reinicialização do portal | Preservado | Preservado | Destruído |
| Reimagem do portal | Preservado | Destruído | Destruído |
| Atualização in-loco | Preservado | Preservado | Destruído |
| Migração de nós | Destruído | Destruído | Destruído |
Na lista anterior, a unidade E: representa a unidade raiz da função e não deve ser codificada. 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 instância única, implante um novo serviço de várias instâncias no servidor de preparo e execute uma troca VIP.
Reversão de uma atualização
O Azure fornece flexibilidade no gerenciamento de serviços durante uma atualização, permitindo que você inicie mais operações em um serviço, depois que o Azure Fabric Controller aceita a solicitação de atualização inicial. Uma reversão só pode ser executada quando uma atualização (alteração de configuração) ou atualização está no estado em andamento na implantação. Uma atualização ou atualização é considerada em andamento desde que haja pelo menos uma instância do serviço que permaneça não atualizada para a nova versão. Para testar se uma reversão é permitida, verifique se o valor do sinalizador RollbackAllowed está definido como true. As operações Get Deployment e Get Cloud Service Properties retornam o sinalizador RollbackAllowed para sua referência.
Nota
Só faz sentido chamar Rollback em uma atualização in-loco ou upgrade porque as atualizações de swap VIP envolvem a substituição de uma instância inteira em execução do seu serviço por outra.
A reversão de uma atualização em andamento tem os seguintes efeitos na implantação:
- Todas as instâncias de função que permanecem não atualizadas ou não atualizadas para a nova versão não são atualizadas ou atualizadas, porque essas instâncias já estão executando a versão de destino do serviço.
- Todas as instâncias de função já atualizadas ou atualizadas para a nova versão do arquivo do pacote de serviço (*.cspkg) ou do arquivo de configuração de serviço (*.cscfg) (ou ambos os arquivos) são revertidas para a versão de pré-atualização desses arquivos.
Os seguintes recursos fornecem essa funcionalidade:
A operação Rollback Update Or Upgrade , que pode ser chamada em uma atualização de configuração (acionada chamando Change Deployment Configuration) ou uma atualização (acionada chamando Upgrade Deployment), desde que haja pelo menos uma instância no serviço que permaneça não atualizada para a nova versão.
O elemento Locked e o elemento RollbackAllowed, que são retornados como parte do corpo de resposta das operações Get Deployment e Get Cloud Service Properties :
- O elemento Locked permite detetar quando uma operação mutante pode ser invocada em uma determinada implantação.
- O elemento RollbackAllowed permite detetar quando a operação Rollback Update ou Upgrade pode ser chamada em uma determinada implantação.
Para executar uma reversão, não é necessário verificar os elementos Locked e RollbackAllowed. Basta confirmar que RollbackAllowed está definido como true. Esses elementos só serão retornados se esses métodos forem invocados usando 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 o controle de versão do modelo de implantação clássico.
Há algumas situações em que uma reversão de uma atualização ou atualização não é suportada, essas situações são as seguintes:
- Redução de recursos locais - Se a atualização aumentar os recursos locais para uma função, a plataforma Azure não permitirá a reversão.
- Limitações de cota - Se a atualização foi uma operação de redução de escala, talvez você não tenha mais cota de computação suficiente para concluir a operação de reversão. Cada assinatura do Azure tem uma cota associada a ela. A cota especifica o número máximo de núcleos que todos os serviços hospedados pertencentes a essa assinatura podem consumir. Se a execução de uma reversão de uma determinada atualização colocar sua assinatura acima da cota, essa reversão não será habilitada.
- Condição de corrida - Se a atualização inicial for concluída, uma reversão não será possível.
Um exemplo de quando a reversão de uma atualização pode ser útil é se você usar a operação Implantação de Atualização no modo manual para controlar a taxa na qual uma grande atualização in-loco é implementada em seu serviço hospedado do Azure.
Durante a implantação da atualização, você chama Implantação de Atualização no modo manual e começa a percorrer os domínios de atualização. Se, em algum momento, ao monitorar a atualização, você notar que algumas instâncias de função nos primeiros domínios de atualização não estão respondendo, você poderá chamar a operação Reverter Atualização ou Atualização na implantação. Essa operação deixa intactas as instâncias que permanecem sem atualização e reverte as instâncias atualizadas para o pacote de serviço e a configuração anteriores.
Iniciando várias operações de mutação em uma implantação contínua
Em alguns casos, talvez você queira iniciar várias operações de mutação simultâneas em uma implantação contínua. Por exemplo, você pode executar uma atualização de serviço e, enquanto a atualização é implementada em todo o serviço, deseja fazer algumas alterações, como reverter a atualização, aplicar uma atualização diferente ou até mesmo excluir a implantação. Um caso em que esse cenário pode surgir é se uma atualização de serviço contém código buggy que faz com que uma instância de função atualizada falhe repetidamente. Nesse caso, o Azure Fabric Controller não consegue progredir na aplicação dessa atualização porque um número insuficiente de instâncias no domínio atualizado está íntegro. Esse estado é conhecido como uma implantação bloqueada. Você pode desgrudar a implantação revertendo a atualização ou aplicando uma nova atualização sobre a que está falhando.
Depois que o Azure Fabric Controller receber a solicitação inicial para atualizar ou atualizar o serviço, você poderá iniciar as operações de mutação subsequentes. Ou seja, você não precisa esperar que a operação inicial seja concluída para poder iniciar outra operação mutante.
Iniciar uma segunda operação de atualização enquanto a primeira atualização está em andamento funciona de forma semelhante à operação de reversão. Se a segunda atualização estiver no modo automático, a primeira atualização de domínio será atualizada imediatamente, possivelmente levando a instâncias de vários domínios de atualização ficando offline ao mesmo tempo.
As operações mutantes são as seguintes: Alterar configuração de implantação, Atualizar implantação, Atualizar status de implantação, Excluir implantação e Reverter atualização ou atualização.
Duas operações, Get Deployment e Get Cloud Service Properties, retornam o sinalizador Bloqueado. Você pode examinar o sinalizador Bloqueado para determinar se pode invocar uma operação mutante em uma determinada implantação.
Para chamar a versão desses métodos que retorna o sinalizador bloqueado, 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 o controle de versão do modelo de implantação clássico.
Distribuição de funções entre domínios de atualização
O Azure distribui instâncias de uma função uniformemente por um número definido de domínios de atualização, que podem ser configurados como parte do arquivo de definição de serviç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 10 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 e o segundo domínio de atualização tem uma ID de 1, e assim por diante.
O diagrama a seguir ilustra como as funções em um serviço que contém duas funções 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.
Nota
Observe que o Azure controla como as instâncias são alocadas entre domínios de atualização. Não é possível especificar quais instâncias são alocadas para qual domínio.
Próximos passos
Como gerir Serviços Cloud
Como Monitorizar os Serviços Cloud
Como configurar um Serviços Cloud