Dimensionamento de Máquina Virtual do Azure Definir atualizações automáticas de imagem do SO
Nota
Muitas das etapas listadas neste documento se aplicam a Conjuntos de Escala de Máquina Virtual usando o modo de Orquestração Uniforme. Recomendamos o uso da Orquestração Flexível para novas cargas de trabalho. Para obter mais informações, consulte Modos de orquestração para conjuntos de escala de máquina virtual no Azure.
Habilitar atualizações automáticas de imagens do sistema operacional em seu conjunto de dimensionamento ajuda a facilitar o gerenciamento de atualizações, atualizando de forma segura e automática o disco do sistema operacional para todas as instâncias do conjunto de escala.
A atualização automática do SO tem as seguintes características:
- Uma vez configurada, a imagem mais recente do sistema operacional publicada pelos editores de imagens é aplicada automaticamente ao conjunto de escalas sem a intervenção do usuário.
- Atualiza lotes de instâncias de forma contínua cada vez que uma nova imagem é publicada pelo editor.
- Integra-se com sondas de integridade do aplicativo e extensão de integridade do aplicativo.
- Funciona para todos os tamanhos de VM e para imagens Windows e Linux, incluindo imagens personalizadas através da Galeria de Computação do Azure.
- Você pode desativar as atualizações automáticas a qualquer momento (as atualizações do sistema operacional também podem ser iniciadas manualmente).
- O disco do sistema operacional de uma VM é substituído pelo novo disco do sistema operacional criado com a versão de imagem mais recente. Extensões configuradas e scripts de dados personalizados são executados, enquanto discos de dados persistentes são mantidos.
- O sequenciamento de extensão é suportado .
- Pode ser ativado em um conjunto de escalas de qualquer tamanho.
Nota
Antes de ativar as atualizações automáticas de imagens do SO, consulte a secção de requisitos desta documentação.
Como funciona a atualização automática da imagem do SO?
Uma atualização funciona substituindo o disco do sistema operacional de uma VM por um novo disco criado usando a versão da imagem. Todas as extensões configuradas e scripts de dados personalizados são executados no disco do sistema operacional, enquanto os discos de dados são mantidos. Para minimizar o tempo de inatividade do aplicativo, as atualizações ocorrem em lotes, com no máximo 20% da atualização do conjunto de escala a qualquer momento.
Você deve integrar uma investigação de integridade do aplicativo do Balanceador de Carga do Azure ou uma extensão de Integridade do Aplicativo para controlar a integridade do aplicativo após uma atualização. Isso permite que a plataforma valide a integridade da VM para garantir que as atualizações sejam aplicadas de maneira segura. Recomendamos incorporar uma pulsação de aplicativo para validar o sucesso da atualização.
Atualizações de disponibilidade em primeiro lugar
O modelo de disponibilidade inicial para atualizações orquestradas de plataforma descrito abaixo garante que as configurações de disponibilidade no Azure sejam respeitadas em vários níveis de disponibilidade.
Entre regiões:
- Uma atualização será movida pelo Azure globalmente de forma faseada para evitar falhas de implantação em todo o Azure.
- Uma 'fase' pode ter uma ou mais regiões, e uma atualização só se move entre fases se as VMs elegíveis na fase anterior forem atualizadas com êxito.
- As regiões emparelhadas geograficamente não serão atualizadas simultaneamente e não podem estar na mesma fase regional.
- O sucesso de uma atualização é medido rastreando a integridade de uma VM pós-atualização.
Dentro de uma região:
- As VMs em zonas de disponibilidade diferentes não são atualizadas simultaneamente com a mesma atualização.
Dentro de um 'conjunto':
- Todas as VMs em um conjunto de escala comum não são atualizadas simultaneamente.
- As VMs em um Conjunto de Escala de Máquina Virtual comum são agrupadas em lotes e atualizadas dentro dos limites do Domínio de Atualização, conforme descrito abaixo.
O processo de atualizações orquestradas da plataforma é seguido para implementar atualizações de imagem da plataforma de sistema operacional suportadas todos os meses. Para imagens personalizadas por meio da Galeria de Computação do Azure, uma atualização de imagem só é iniciada para uma região específica do Azure quando a nova imagem é publicada e replicada para a região desse conjunto de escala.
Atualizando VMs em um conjunto de escala
A região de um conjunto de escala torna-se elegível para obter atualizações de imagem através do processo de disponibilidade inicial para imagens de plataforma ou replicando novas versões de imagens personalizadas para a Galeria de Imagens de Partilha. A atualização da imagem é então aplicada a um conjunto de escala individual de forma em lote, da seguinte forma:
- Antes de iniciar o processo de atualização, o orquestrador garantirá que não mais de 20% das instâncias em todo o conjunto de escala não estejam íntegras (por qualquer motivo).
- O orquestrador de atualização identifica o lote de instâncias de VM a serem atualizadas, com qualquer lote tendo um máximo de 20% da contagem total de instâncias, sujeito a um tamanho de lote mínimo de uma máquina virtual. Não há nenhum requisito de tamanho mínimo de conjunto de escala e conjuntos de escala com 5 ou menos instâncias terão 1 VM por lote de atualização (tamanho mínimo do lote).
- O disco do sistema operacional de cada VM no lote de atualização selecionado é substituído por um novo disco do sistema operacional criado a partir da imagem. Todas as extensões e configurações especificadas no modelo de conjunto de escala são aplicadas à instância atualizada.
- Para conjuntos de dimensionamento com testes de integridade do aplicativo configurados ou extensão de integridade do aplicativo, a atualização aguarda até 5 minutos para que a instância fique íntegra, antes de passar para atualizar o próximo lote. Se uma instância não recuperar sua integridade em 5 minutos após uma atualização, por padrão, o disco do sistema operacional anterior da instância será restaurado.
- O orquestrador de atualização também rastreia a porcentagem de instâncias que se tornam não íntegras após uma atualização. A atualização será interrompida se mais de 20% das instâncias atualizadas não estiverem íntegras durante o processo de atualização.
- O processo acima continua até que todas as instâncias no conjunto de escala tenham sido atualizadas.
O orquestrador de atualização do sistema operacional do conjunto de escala verifica a integridade geral do conjunto de escala antes de atualizar cada lote. Enquanto você atualiza um lote, pode haver outras atividades de manutenção simultâneas planejadas ou não planejadas que podem afetar a integridade das instâncias do conjunto de escala. Nesses casos, se mais de 20% das instâncias do conjunto de escalas não estiverem íntegras, a atualização do conjunto de escalas será interrompida no final do lote atual.
Para modificar as configurações padrão associadas às Atualizações Contínuas, revise a Política de Atualização Contínua do Azure.
Nota
A atualização automática do sistema operacional não atualiza a imagem de referência Sku no conjunto de escala. Para alterar o Sku (como o Ubuntu 18.04-LTS para 20.04-LTS), você deve atualizar o modelo do conjunto de escala diretamente com o Sku de imagem desejado. O editor de imagens e a oferta não podem ser alterados para um conjunto de escala existente.
Atualização de imagem do SO versus reimagem
Tanto o OS Image Upgrade quanto o Reimage são métodos usados para atualizar VMs dentro de um conjunto de escalas, mas servem a finalidades diferentes e têm impactos distintos.
A atualização da imagem do sistema operacional envolve a atualização da imagem do sistema operacional subjacente que é usada para criar novas instâncias em um conjunto de escala. Quando você executa uma atualização de imagem do sistema operacional, o Azure cria novas instâncias de VM com a imagem atualizada do sistema operacional e substitui gradualmente as instâncias de VM antigas no conjunto de escala pelas novas. Esse processo normalmente é realizado em etapas para garantir alta disponibilidade. As atualizações de imagem do sistema operacional são uma maneira sem interrupções de aplicar atualizações ou alterações ao sistema operacional subjacente das VMs em um conjunto de escala. As instâncias de VM existentes não são afetadas até que sejam substituídas pelas novas instâncias.
A criação de imagens de uma instância de VM em um conjunto de dimensionamento é uma ação mais imediata e perturbadora. Quando você optar por recriar a imagem de uma instância de VM, o Azure interromperá a instância de VM selecionada, executará a operação de reimagem e reiniciará a VM usando a mesma imagem do sistema operacional. Isso efetivamente reinstala o sistema operacional nessa instância específica da VM. A recriação de imagens geralmente é usada quando você precisa solucionar problemas ou redefinir uma instância de VM específica devido a problemas com essa instância.
Principais diferenças:
- A Atualização de Imagem do SO é um processo gradual e sem interrupções que atualiza a imagem do SO para todo o Conjunto de Dimensionamento de Máquinas Virtuais ao longo do tempo, garantindo um impacto mínimo nas cargas de trabalho em execução.
- Reimage é uma ação mais imediata e perturbadora que afeta apenas a instância de VM selecionada, interrompendo-a temporariamente e reinstalando o sistema operacional.
Quando usar cada método:
- Use o upgrade de imagem do sistema operacional quando quiser atualizar a imagem do sistema operacional para todo o conjunto de escalas, mantendo a alta disponibilidade.
- Use Reimage quando precisar solucionar problemas ou redefinir uma instância de VM específica dentro do Conjunto de Dimensionamento de Máquina virtual.
É essencial planejar e escolher cuidadosamente o método apropriado com base em seus requisitos específicos para minimizar qualquer interrupção em seus aplicativos e serviços em execução em um Conjunto de Dimensionamento de Máquina Virtual.
Imagens de SO suportadas
Atualmente, apenas algumas imagens da plataforma do SO são suportadas. As imagens personalizadas são suportadas se o conjunto de dimensionamento utilizar imagens personalizadas através da Galeria de Computação do Azure.
Os seguintes SKUs de plataforma são atualmente suportados (e mais são adicionados periodicamente):
Publisher | Oferta de SO | Sku |
---|---|---|
Canónico | UbuntuServer | 18.04-LTS |
Canónico | UbuntuServer | 18_04-LTS-Gen2 |
Canónico | 0001-com-ubuntu-servidor-focal | 20_04-LTS |
Canónico | 0001-com-ubuntu-servidor-focal | 20_04-LTS-Gen2 |
Canónico | 0001-com-ubuntu-servidor-jammy | 22_04-LTS |
Canónico | 0001-com-ubuntu-servidor-jammy | 22_04-LTS-Gen2 |
MicrosoftCblMariner | Cbl-Mariner | CBL-Marinheiro-1 |
MicrosoftCblMariner | Cbl-Mariner | 1-Gen2 |
MicrosoftCblMariner | Cbl-Mariner | CBL-Marinheiro-2 |
MicrosoftCblMariner | Cbl-Mariner | cbl-marinheiro-2-Gen2 |
MicrosoftSqlServer | Sql2017-ws2019 | empresa |
MicrosoftWindowsServer | WindowsServer | 2012-R2-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-gensecond |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-gs |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-com-Contentores |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-com-contêineres-gs |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-Core |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-Core-com-Containers |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-gensecond |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-gs |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter com Contêineres |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-com-Containers-gs |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-smalldisk-g2 |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-core |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-core-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-g2 |
MicrosoftWindowsServer | WindowsServer | Datacenter-core-20h2-com-containers-smalldisk-gs |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-azure-edition |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-azure-edition-smalldisk |
Mirantis | Windows_with_Mirantis_Container_Runtime_2019 | win_2019_mcr_23_0 |
Mirantis | Windows_with_Mirantis_Container_Runtime_2019 | win_2019_mcr_23_0_gen2 |
Requisitos para configurar a atualização automática da imagem do SO
- A propriedade version da imagem deve ser definida como mais recente.
- Deve usar testes de integridade do aplicativo ou extensão de integridade do aplicativo para conjuntos de escala que não sejam do Service Fabric. Para obter os requisitos do Service Fabric, consulte Requisito do Service Fabric.
- Use a Compute API versão 2018-10-01 ou superior.
- Certifique-se de que os recursos externos especificados no modelo de conjunto de escala estejam disponíveis e atualizados. Os exemplos incluem URI SAS para inicialização de carga útil em propriedades de extensão de VM, carga útil na conta de armazenamento, referência a segredos no modelo e muito mais.
- Para conjuntos de dimensionamento usando máquinas virtuais do Windows, a partir da versão 2019-03-01 da API de Computação, a propriedade virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates deve ser definida como false na definição do modelo do conjunto de escalas. A propriedade enableAutomaticUpdates permite a aplicação de patches na VM em que "Windows Update" aplica patches do sistema operacional sem substituir o disco do sistema operacional. Com as atualizações automáticas de imagem do SO ativadas no seu conjunto de escalas, o que pode ser feito definindo o automaticOSUpgradePolicy.enableAutomaticOSUpgrade como true, não é necessário um processo de aplicação de patches extra através do Windows Update.
- O modo de orquestração de patches não deve ser definido como
AutomaticByPlatform
na definição do modelo do conjunto de escalas. Com as atualizações automáticas de imagem do SO ativadas no seu conjunto de escalas, não é necessário um processo de correção de orquestração de plataforma.
Nota
Depois que um disco do sistema operacional é substituído por meio de reimagem ou atualização, os discos de dados anexados podem ter suas letras de unidade reatribuídas. Para manter as mesmas letras de unidade para discos anexados, sugere-se usar um script de inicialização personalizado.
Requisitos do Service Fabric
Se você estiver usando o Service Fabric, verifique se as seguintes condições são atendidas:
- O nível de durabilidade do tecido de serviço é Prata ou Ouro. Se a durabilidade do Service Fabric for Bronze, apenas os tipos de nó sem estado suportam atualizações automáticas de imagem do SO).
- A extensão do Service Fabric na definição de modelo de conjunto de escala deve ter TypeHandlerVersion 1.1 ou superior.
- O nível de durabilidade deve ser o mesmo no cluster do Service Fabric e na extensão do Service Fabric na definição do modelo do conjunto de escala.
- Uma sonda de integridade adicional ou o uso de extensão de integridade do aplicativo não é necessário para durabilidade Silver ou Gold. A durabilidade do bronze com tipos de nó somente sem estado requer uma sonda de integridade adicional.
- A propriedade virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates deve ser definida como false na definição do modelo do conjunto de escalas. A propriedade enableAutomaticUpdates habilita a aplicação de patches na VM usando "Windows Update" e não é suportada em conjuntos de escala do Service Fabric. Você deve usar a propriedade automaticOSUpgradePolicy.enableAutomaticOSUpgrade em vez disso.
Certifique-se de que as configurações de durabilidade não sejam incompatíveis no cluster do Service Fabric e na extensão do Service Fabric, pois uma incompatibilidade resultará em erros de atualização. Os níveis de durabilidade podem ser modificados de acordo com as diretrizes descritas nesta página.
Atualização automática de imagens do SO para imagens personalizadas
A atualização automática de imagens do SO é suportada para imagens personalizadas implementadas através da Galeria de Computação do Azure. Outras imagens personalizadas não são suportadas para atualizações automáticas de imagens do SO.
Requisitos adicionais para imagens personalizadas
- O processo de instalação e configuração para atualização automática de imagem do sistema operacional é o mesmo para todos os conjuntos de escala, conforme detalhado na seção de configuração desta página.
- As instâncias de conjuntos de escala configuradas para atualizações automáticas de imagens do sistema operacional serão atualizadas para a versão da imagem da Galeria de Computação do Azure quando uma nova versão da imagem for publicada e replicada para a região desse conjunto de escala. Se a nova imagem não for replicada para a região onde a escala é implantada, as instâncias do conjunto de escala não serão atualizadas para a versão. A replicação regional de imagens permite controlar a distribuição da nova imagem para seus conjuntos de escala.
- A nova versão da imagem não deve ser excluída da versão dessa imagem da galeria. As versões de imagem excluídas da versão da imagem da galeria não são implementadas na escala definida através da atualização automática da imagem do SO.
Nota
Pode levar até 3 horas para que um conjunto de escala acione a primeira distribuição de atualização de imagem depois que o conjunto de escala é configurado pela primeira vez para atualizações automáticas do sistema operacional devido a certos fatores, como janelas de manutenção ou outras restrições. Os clientes na imagem mais recente podem não obter uma atualização até que uma nova imagem esteja disponível.
Configurar a atualização automática da imagem do SO
Para configurar a atualização automática da imagem do sistema operacional, verifique se a propriedade automaticOSUpgradePolicy.enableAutomaticOSUpgrade está definida como true na definição do modelo do conjunto de escalas.
Nota
O modo de Política de Atualização e a Política de Atualização Automática do SO são configurações separadas e controlam diferentes aspetos do conjunto de escala. Quando houver alterações no modelo de conjunto de escalas, a Política mode
de Atualização determinará o que acontece com as instâncias existentes no conjunto de escalas. No entanto, a Política enableAutomaticOSUpgrade
de Atualização Automática do SO é específica para a imagem do SO e controla as alterações feitas pelo editor da imagem e determina o que acontece quando há uma atualização na imagem.
Nota
Se enableAutomaticOSUpgrade
estiver definido como true, enableAutomaticUpdates
será automaticamente definido como false e não poderá ser definido como true.
API REST
O exemplo a seguir descreve como definir atualizações automáticas do sistema operacional em um modelo de conjunto de escala:
PUT or PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet?api-version=2021-03-01`
{
"properties": {
"upgradePolicy": {
"automaticOSUpgradePolicy": {
"enableAutomaticOSUpgrade": true
}
}
}
}
Azure PowerShell
Use o cmdlet New-AzVmss para configurar atualizações automáticas de imagem do sistema operacional para seu conjunto de dimensionamento durante o provisionamento. O exemplo a seguir configura atualizações automáticas para o conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
Use o cmdlet Update-AzVmss para configurar atualizações automáticas de imagem do sistema operacional para seu conjunto de dimensionamento existente. O exemplo a seguir configura atualizações automáticas para o conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
CLI 2.0 do Azure
Use az vmss create para configurar atualizações automáticas de imagem do sistema operacional para seu conjunto de escala durante o provisionamento. Use a CLI do Azure 2.0.47 ou superior. O exemplo a seguir configura atualizações automáticas para o conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
Use az vmss update para configurar atualizações automáticas de imagem do sistema operacional para seu conjunto de escala existente. Use a CLI do Azure 2.0.47 ou superior. O exemplo a seguir configura atualizações automáticas para o conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
Nota
Depois de configurar as atualizações automáticas de imagem do sistema operacional para seu conjunto de escalas, você também deve trazer as VMs do conjunto de escala para o modelo de conjunto de escala mais recente se o conjunto de escalas usar a política de atualização 'Manual'.
Modelos do ARM
O exemplo a seguir descreve como definir atualizações automáticas do sistema operacional em um modelo de conjunto de escala por meio de modelos do Azure Resource Manager (modelos ARM):
"properties": {
"upgradePolicy": {
"mode": "Automatic",
"RollingUpgradePolicy": {
"BatchInstancePercent": 20,
"MaxUnhealthyInstancePercent": 25,
"MaxUnhealthyUpgradedInstancePercent": 25,
"PauseTimeBetweenBatches": "PT0S"
},
"automaticOSUpgradePolicy": {
"enableAutomaticOSUpgrade": true,
"useRollingUpgradePolicy": true,
"disableAutomaticRollback": false
}
},
},
"imagePublisher": {
"type": "string",
"defaultValue": "MicrosoftWindowsServer"
},
"imageOffer": {
"type": "string",
"defaultValue": "WindowsServer"
},
"imageSku": {
"type": "string",
"defaultValue": "2022-datacenter"
},
"imageOSVersion": {
"type": "string",
"defaultValue": "latest"
}
Bicep
O exemplo a seguir descreve como definir atualizações automáticas do sistema operacional em um modelo de conjunto de escala via Bicep:
properties: {
overprovision: overProvision
upgradePolicy: {
mode: 'Automatic'
automaticOSUpgradePolicy: {
enableAutomaticOSUpgrade: true
}
}
}
Usando a extensão de integridade do aplicativo
Durante uma atualização do sistema operacional, as instâncias de VM em um conjunto de escala são atualizadas um lote de cada vez. A atualização deve continuar somente se o aplicativo cliente estiver íntegro nas instâncias de VM atualizadas. Recomendamos que o aplicativo forneça sinais de integridade para o mecanismo de atualização do sistema operacional do conjunto de escalas. Por padrão, durante as atualizações do sistema operacional, a plataforma considera o estado de energia da VM e o estado de provisionamento da extensão para determinar se uma instância da VM está íntegra após uma atualização. Durante a atualização do sistema operacional de uma instância de VM, o disco do sistema operacional em uma instância de VM é substituído por um novo disco com base na versão de imagem mais recente. Após a conclusão da atualização do sistema operacional, as extensões configuradas são executadas nessas VMs. O aplicativo é considerado íntegro somente quando todas as extensões na instância são provisionadas com êxito.
Opcionalmente, um conjunto de dimensionamentos pode ser configurado com o Application Health Probes para fornecer à plataforma informações precisas sobre o estado contínuo do aplicativo. As Sondas de Integridade do Aplicativo são Testes de Balanceador de Carga Personalizados que são usados como um sinal de integridade. O aplicativo em execução em uma instância de VM de conjunto de escala pode responder a solicitações HTTP ou TCP externas indicando se está íntegro. Para obter mais informações sobre como as sondas de balanceador de carga personalizadas funcionam, consulte Compreender as sondas de balanceador de carga. Não há suporte para testes de integridade de aplicativos para conjuntos de dimensionamento do Service Fabric. Os conjuntos de escala que não são do Service Fabric exigem testes de integridade do aplicativo do Load Balancer ou extensão da Integridade do Aplicativo.
Se o conjunto de dimensionamento estiver configurado para usar vários grupos de posicionamento, as sondas usando um Balanceador de Carga Padrão precisarão ser usadas.
Nota
Apenas uma fonte de monitoramento de integridade pode ser usada para um Conjunto de Dimensionamento de Máquina Virtual, uma Extensão de Integridade do Aplicativo ou uma Sonda de Integridade. Se você tiver ambas as opções habilitadas, precisará remover uma antes de usar serviços de orquestração, como reparos de instância ou atualizações automáticas do sistema operacional.
Configurando uma Sonda de Balanceador de Carga Personalizada como Sonda de Integridade do Aplicativo em um conjunto de dimensionamento
Como prática recomendada, crie um teste de balanceador de carga explicitamente para a integridade do conjunto de escalas. O mesmo ponto de extremidade para uma sonda HTTP ou TCP existente pode ser usado, mas uma sonda de integridade pode exigir um comportamento diferente de uma sonda de balanceador de carga tradicional. Por exemplo, uma sonda de balanceador de carga tradicional pode retornar não íntegra se a carga na instância for muito alta, mas isso não seria apropriado para determinar a integridade da instância durante uma atualização automática do sistema operacional. Configure a sonda para ter uma alta taxa de sondagem de menos de dois minutos.
A sonda do balanceador de carga pode ser referenciada no networkProfile do conjunto de escala e pode ser associada a um balanceador de carga interno ou público da seguinte maneira:
"networkProfile": {
"healthProbe" : {
"id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
},
"networkInterfaceConfigurations":
...
}
Nota
Ao usar as Atualizações Automáticas do SO com o Service Fabric, a nova imagem do SO é implementada Atualizar Domínio por Domínio de Atualização para manter a alta disponibilidade dos serviços em execução no Service Fabric. Para utilizar as Atualizações Automáticas do SO no Service Fabric, o tipo de nó do cluster deve ser configurado para usar o Nível de Durabilidade Prata ou superior. Para a camada de durabilidade Bronze, a atualização automática da imagem do sistema operacional só é suportada para tipos de nó sem estado. Para obter mais informações sobre as características de durabilidade dos clusters do Service Fabric, consulte esta documentação.
Usando a extensão de integridade do aplicativo
A extensão Integridade do Aplicativo é implantada dentro de uma instância do Conjunto de Dimensionamento de Máquina Virtual e relata a integridade da VM de dentro da instância do conjunto de escala. Você pode configurar a extensão para investigar em um ponto de extremidade do aplicativo e atualizar o status do aplicativo nessa instância. Esse status da instância é verificado pelo Azure para determinar se uma instância é qualificada para operações de atualização.
Como a extensão relata a integridade de dentro de uma VM, a extensão pode ser usada em situações em que testes externos, como testes de integridade do aplicativo (que utilizam testes personalizados do Azure Load Balancer ) não podem ser usados.
Há várias maneiras de implantar a extensão Integridade do Aplicativo em seus conjuntos de escala, conforme detalhado nos exemplos deste artigo.
Nota
Apenas uma fonte de monitoramento de integridade pode ser usada para um Conjunto de Dimensionamento de Máquina Virtual, uma Extensão de Integridade do Aplicativo ou uma Sonda de Integridade. Se você tiver ambas as opções habilitadas, precisará remover uma antes de usar serviços de orquestração, como reparos de instância ou atualizações automáticas do sistema operacional.
Obtenha o histórico de atualizações automáticas de imagens do SO
Você pode verificar o histórico da atualização mais recente do sistema operacional executada em seu conjunto de escala com o Azure PowerShell, a CLI 2.0 do Azure ou as APIs REST. Você pode obter o histórico das últimas cinco tentativas de atualização do sistema operacional nos últimos dois meses.
Mantenha as credenciais atualizadas
Se o conjunto de dimensionamento usar credenciais para acessar recursos externos, como uma extensão de VM configurada para usar um token SAS para conta de armazenamento, verifique se as credenciais estão atualizadas. Se quaisquer credenciais, incluindo certificados e tokens, tiverem expirado, a atualização falhará e o primeiro lote de VMs será deixado em um estado de falha.
As etapas recomendadas para recuperar VMs e reativar a atualização automática do sistema operacional se houver uma falha de autenticação de recurso são:
- Regenere o token (ou quaisquer outras credenciais) passadas para sua(s) extensão(ões).
- Certifique-se de que qualquer credencial usada de dentro da VM para falar com entidades externas esteja atualizada.
- Atualize a(s) extensão(ões) no modelo de conjunto de escala com quaisquer novos tokens.
- Implante o conjunto de escala atualizado, que atualizará todas as instâncias de VM, incluindo as com falha.
API REST
O exemplo a seguir usa a API REST para verificar o status do conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`
A chamada GET retorna propriedades semelhantes à saída de exemplo a seguir:
{
"value": [
{
"properties": {
"runningStatus": {
"code": "RollingForward",
"startTime": "2018-07-24T17:46:06.1248429+00:00",
"completedTime": "2018-04-21T12:29:25.0511245+00:00"
},
"progress": {
"successfulInstanceCount": 16,
"failedInstanceCount": 0,
"inProgressInstanceCount": 4,
"pendingInstanceCount": 0
},
"startedBy": "Platform",
"targetImageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2016-Datacenter",
"version": "2016.127.20180613"
},
"rollbackInfo": {
"successfullyRolledbackInstanceCount": 0,
"failedRolledbackInstanceCount": 0
}
},
"type": "Microsoft.Compute/virtualMachineScaleSets/rollingUpgrades",
"location": "westeurope"
}
]
}
Azure PowerShell
Use o cmdlet Get-AzVmss para verificar o histórico de atualização do sistema operacional para seu conjunto de escalas. O exemplo a seguir detalha como você revisa o status de atualização do sistema operacional para um conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory
CLI 2.0 do Azure
Use az vmss get-os-upgrade-history para verificar o histórico de atualização do sistema operacional para seu conjunto de escalas. Use a CLI do Azure 2.0.47 ou superior. O exemplo a seguir detalha como você revisa o status de atualização do sistema operacional para um conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet
Como obter a versão mais recente de uma imagem do sistema operacional da plataforma?
Você pode obter as versões de imagem disponíveis para atualização automática do sistema operacional suportado SKUs usando os exemplos abaixo:
API REST
GET on `/subscriptions/subscription_id/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions?api-version=2021-03-01`
Azure PowerShell
Get-AzVmImage -Location "westus" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"
CLI 2.0 do Azure
az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all
Acionar manualmente atualizações de imagem do sistema operacional
Com a atualização automática de imagens do SO ativada no seu conjunto de escalas, não é necessário acionar manualmente as atualizações de imagem no seu conjunto de escalas. O orquestrador de atualização do sistema operacional aplicará automaticamente a versão de imagem mais recente disponível às instâncias do conjunto de dimensionamento sem qualquer intervenção manual.
Para casos específicos em que você não deseja esperar que o orquestrador aplique a imagem mais recente, você pode acionar uma atualização de imagem do sistema operacional manualmente usando os exemplos abaixo.
Nota
O acionamento manual de atualizações de imagem do sistema operacional não fornece recursos de reversão automática. Se uma instância não recuperar sua integridade após uma operação de atualização, seu disco do sistema operacional anterior não poderá ser restaurado.
API REST
Use a chamada da API Start OS Upgrade para iniciar uma atualização contínua para mover todas as instâncias do Virtual Machine Scale set para a versão mais recente do sistema operacional de imagem disponível. As instâncias que já estão executando a versão mais recente do sistema operacional disponível não são afetadas. O exemplo a seguir detalha como você pode iniciar uma atualização contínua do sistema operacional em um conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`
Azure PowerShell
Use o cmdlet Start-AzVmssRollingOSUpgrade para verificar o histórico de atualização do sistema operacional para seu conjunto de escala. O exemplo a seguir detalha como você pode iniciar uma atualização contínua do sistema operacional em um conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"
CLI 2.0 do Azure
Use az vmss rolling-upgrade start para verificar o histórico de atualização do sistema operacional para seu conjunto de escalas. Use a CLI do Azure 2.0.47 ou superior. O exemplo a seguir detalha como você pode iniciar uma atualização contínua do sistema operacional em um conjunto de escala chamado myScaleSet no grupo de recursos chamado myResourceGroup:
az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"
Aproveite os logs de atividades para notificações de atualização e insights
O Log de Atividades é um log de assinatura que fornece informações sobre eventos no nível de assinatura que ocorreram no Azure. Os clientes podem:
- Ver eventos relacionados a operações executadas em seus recursos no portal do Azure
- Crie grupos de ação para ajustar métodos de notificação como e-mail, sms, webhooks ou ITSM
- Configure alertas adequados usando critérios diferentes usando Portal, modelo de recurso ARM, PowerShell ou CLI para serem enviados a grupos de ação
Os clientes receberão três tipos de notificações relacionadas à operação de Atualização Automática do SO:
- Envio de solicitação de atualização para um recurso específico
- Resultado do pedido de submissão, juntamente com quaisquer detalhes do erro
- Resultado da conclusão da atualização, juntamente com quaisquer detalhes do erro
Configurando grupos de ação para alertas de registro de atividades
Um grupo de ações é uma coleção de preferências de notificação definidas pelo proprietário de uma assinatura do Azure. Os alertas do Azure Monitor e do Service Health usam grupos de ação para notificar os usuários de que um alerta foi disparado.
Os grupos de ação podem ser criados e gerenciados usando:
- Gerente de Recursos ARM
- Portal
- PowerShell:
- CLI
Os clientes podem configurar o seguinte usando grupos de ação:
- Notificações por SMS e/ou e-mail
- Webhooks - Os clientes podem anexar webhooks aos seus runbooks de automação e configurar seus grupos de ação para acionar os runbooks. Você pode iniciar um runbook a partir de um webhook
- Conexões ITSM
Investigue e resolva erros de atualização automática
A plataforma pode retornar erros em VMs ao executar a política de Atualização Automática de Imagem com Atualização Contínua. O Get Instance View de uma VM contém a mensagem de erro detalhada para investigar e resolver um erro. O Rolling Upgrades - Get Latest pode fornecer mais detalhes sobre a configuração e o status da atualização contínua. O Get OS Upgrade History fornece detalhes sobre a última operação de atualização de imagem no conjunto de escalas. Abaixo estão os principais erros que podem resultar em atualizações contínuas.
RollingUpgradeInProgressWithFailedUpgradedVMs
- O erro é acionado para uma falha de VM.
- A mensagem de erro detalhada menciona se a distribuição continuará/pausará com base no limite configurado.
MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade
- O erro é acionado quando a porcentagem de VMs atualizadas excede o limite máximo permitido para VMs não íntegras.
- A mensagem de erro detalhada agrega o erro mais comum que contribui para as VMs não íntegras. Consulte MaxUnhealthyUpgradedInstancePercent.
MaxUnhealthyInstancePercentExceededInRollingUpgrade
- O erro é acionado quando a porcentagem de VMs não íntegras excede o limite máximo permitido para VMs não íntegras durante uma atualização.
- A mensagem de erro detalhada exibe a porcentagem não íntegra atual e a porcentagem de VM não íntegra permitida configurada. Consulte maxUnhealthyInstancePercent.
MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade
- O erro é acionado quando a porcentagem de VMs não íntegras excede o limite máximo permitido para VMs não íntegras antes que uma atualização ocorra.
- A mensagem de erro detalhada exibe a porcentagem não íntegra atual e a porcentagem de VM não íntegra permitida configurada. Consulte maxUnhealthyInstancePercent.
InternalExecutionError
- O erro é acionado quando ocorre um erro não manipulado, não formatado ou inesperado durante a execução.
- A mensagem de erro detalhada exibe a causa do erro.
RollingUpgradeTimeoutError
- O erro é acionado quando o processo de atualização contínua atingiu o tempo limite.
- A mensagem de erro detalhada exibe o período de tempo que o sistema expirou após a tentativa de atualização.