Compartilhar via

Atualizar o runtime do cluster da CLI do Azure

  • Artigo

Este guia de instruções explica as etapas para instalar a CLI do Azure necessária e as extensões necessárias para interagir com o Nexus do Operador.

Pré-requisitos

  • A CLI do Azure de Instalação deve ser instalada.
  • A extensão CLI networkcloud é necessária. Se a extensão networkcloud não estiver instalada, ela poderá ser instalada seguindo as etapas listadas aqui.
  • Acesso ao portal do Azure para que o cluster de destino seja atualizado.
  • Você deve estar conectado à mesma assinatura do cluster de destino por meio de az login
  • O cluster de destino deve estar em um estado de execução, com todos os nós do plano de controle íntegros e 80% dos nós de computação em um estado em execução e íntegro.

Verificar a versão atual do runtime

Verifique a versão atual do runtime do cluster antes da atualização: Como verificar a versão atual do runtime do cluster.

Localizando versões de runtime disponíveis

Via Portal do Azure

Para encontrar versões de runtime atualizáveis disponíveis, navegue até o cluster de destino no portal do Azure. No painel de visão geral do cluster, navegue até a guia Versões de atualização disponíveis.

Captura de tela do portal do Azure mostrando a guia correta para identificar as atualizações de cluster disponíveis.

Na guia versões de atualização disponíveis, podemos ver as diferentes versões de cluster que estão disponíveis para atualização no momento. O operador pode selecionar entre as versões de runtime de destino listadas. Depois de selecionado, prossiga para atualizar o cluster.

Captura de tela do portal do Azure mostrando as atualizações de cluster disponíveis.

Via CLI do Azure

As atualizações disponíveis são recuperáveis por meio da CLI do Azure:

az networkcloud cluster show --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--subscription <subscriptionID>

Na saída, você pode encontrar a propriedade availableUpgradeVersions e examinar o campo targetClusterVersion:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Se não houver atualizações de cluster disponíveis, a lista estará vazia.

Configurar parâmetros de limite de computação para atualização de runtime usando o cluster updateStrategy

O seguinte comando da CLI do Azure é usado para configurar os parâmetros de limite de computação para uma atualização de runtime:

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks> /
--subscription <subscriptionID>

Parâmetros requeridos:

  • strategy-type: define a estratégia de atualização. Isso pode ser "Rack" (rack por rack) OU "PauseAfterRack" (Atualizar um rack de cada vez e aguardar a confirmação antes de prosseguir para o próximo rack. O valor padrão é Rack. Para realizar uma atualização de runtime de cluster usando a estratégia “PauseRack”, siga as etapas descritas em Atualização do runtime de cluster com uma estratégia “PauseRack”
  • threshold-type: determina como o limite deve ser avaliado, aplicado nas unidades definidas pela estratégia. Isso pode ser "PercentSuccess" OU "CountSuccess". O valor padrão é PercentSuccess.
  • threshold-value: o valor de limite numérico usado para avaliar uma atualização. O valor padrão é 80.

Parâmetros opcionais:

  • max-unavailable: o número máximo de nós de trabalho que podem ser offline, ou seja, rack atualizado por vez. O valor padrão é 32767.
  • wait-time-minutes: o período de atraso ou espera antes de atualizar um rack. O valor padrão é 15.

O exemplo a seguir é para um cliente que usa a estratégia de rack por rack com um percentual de sucesso de 60% e uma pausa de 1 minuto.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

Verifique a atualização:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

Neste exemplo, se menos de 60% dos nós de computação provisionados em um rack falharem ao ser provisionados (por rack), a implantação do cluster falha. Se 60% ou mais dos nós de computação forem provisionados com êxito, a implantação do cluster passará para o próximo rack de nós de computação.

O exemplo a seguir é para um cliente que usa a estratégia de rack por rack com um tipo de limite CountSuccess de 10 nós por rack e uma pausa de 1 minuto.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

Verifique a atualização:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

Neste exemplo, se menos de 10 nós de computação sendo provisionados em um rack falharem ao ser provisionados (por rack), a implantação do cluster falha. Se 10 ou mais dos nós de computação forem provisionados com êxito, a implantação do cluster passará para o próximo rack de nós de computação.

Observação

update-strategy não pode ser alterado após o início da atualização do runtime do cluster. Quando um valor limite abaixo de 100% é definido é possível que os nós não íntegros não sejam atualizados, mas o status “Cluster” ainda pode indicar que a atualização foi bem-sucedida. Para solucionar problemas com computadores bare-metal, consulte Solucionar problemas do servidor Nexus do Operador do Azure

Atualizar o runtime do cluster usando a CLI

Para executar uma atualização do runtime, use o seguinte comando da CLI do Azure:

az networkcloud cluster update-version --cluster-name "<clusterName>" /
--target-cluster-version "<versionNumber>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

A atualização de runtime é um processo longo. A atualização primeiro atualiza os nós de gerenciamento e, em seguida, sequencialmente rack por rack para os nós de trabalho. A atualização é considerada concluída quando 80% dos nós de trabalho por rack e 100% dos nós de gerenciamento foram atualizados com êxito. As cargas de trabalho podem ser afetadas enquanto os nós de trabalho em um rack estão em processo de atualização, no entanto, as cargas de trabalho em todos os outros racks não serão afetadas. A consideração do posicionamento da carga de trabalho à luz desse design de implementação é incentivada.

A atualização de todos os nós leva várias horas, dependendo de quantos racks existem para o cluster. Devido à duração do processo de atualização, o status de detalhes do cluster deve ser verificado periodicamente quanto ao estado atual da atualização. Para verificar o status da atualização, observe o status detalhado do cluster. Essa verificação pode ser feita por meio do portal ou da CLI az.

Para exibir o status da atualização por meio do portal do Azure, navegue até o recurso de cluster de destino. Na tela Visão geral do cluster, o status detalhado é fornecido juntamente com uma mensagem de status detalhada.

A atualização do cluster está em andamento quando detailedStatus está definido como Updating e detailedStatusMessage mostra o progresso da atualização. Alguns exemplos de progresso de atualização mostrados em detailedStatusMessage são Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading..., etc.

A atualização do cluster é concluída quando detailedStatus está definido como Running e detailedStatusMessage mostra a mensagem Cluster is up and running

Captura de tela do portal do Azure mostrando a atualização do cluster em andamento.

Para exibir o status de atualização por meio da CLI do Azure, use az networkcloud cluster show.

az networkcloud cluster show --cluster-name "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

A saída deve ser as informações do cluster de destino e a mensagem detalhada de status e status de detalhes do cluster deve estar presente. Para obter informações mais detalhadas sobre o progresso da atualização, o nó individual em cada rack pode ser verificado quanto ao status. Um exemplo de verificação do status é fornecido na seção de referência em Funções do computador BareMetal.

Perguntas frequentes

Identificando a Atualização de Cluster Travada/Paralisada

Durante uma atualização de runtime, é possível que a atualização não avance, mas o status de detalhes reflete que a atualização ainda está em andamento. Como a atualização de runtime pode levar muito tempo para ser concluída com êxito, não há nenhum tempo limite definido especificado no momento. Portanto, é aconselhável também verificar periodicamente o status e os logs de detalhes do cluster para determinar se a atualização está tentando atualizar indefinidamente.

Podemos identificar a situação indefinitely attempting to upgrade examinando os logs do cluster, a mensagem detalhada e a mensagem de status detalhada. Se ocorrer um tempo limite, observaremos que o cluster está continuamente reconciliando o mesmo processo indefinidamente, sem avançar. A partir daqui, recomendamos verificar os logs de cluster ou o LAW configurado para ver se há uma falha ou uma atualização específica que esteja causando a falta de progresso.

Falha de hardware não requer a re-execução da atualização

Se ocorrer uma falha de hardware durante uma atualização, a atualização de runtime continuará desde que os limites definidos sejam atendidos para os nós de computação e gerenciamento/controle. Depois que o computador é corrigido ou substituído, ele é provisionado com o sistema operacional do runtime da plataforma atual, que contém a versão de destino do runtime.

Se ocorrer uma falha de hardware e a atualização de runtime falhar porque os limites não foram atendidos para os nós de computação e controle, pode ser necessário reexecutar a atualização de runtime. Dependendo de quando a falha ocorreu e do estado dos servidores individuais em um rack. Se um rack tiver sido atualizado antes de uma falha, a versão de runtime atualizada será usada quando os nós forem reprovisionados. Se a especificação do rack não foi atualizada para a versão de runtime atualizada antes da falha de hardware, o computador seria provisionado com a versão anterior do runtime. Para atualizar para a nova versão do runtime, envie uma nova solicitação de atualização do cluster. Somente os nós com a versão anterior do runtime são atualizados. Os hosts que foram bem-sucedidos na ação de atualização anterior não serão.

Após uma atualização de runtime, o cluster mostra o estado de provisionamento "Com falha"

Durante uma atualização de runtime, o cluster entra em um estado de Upgrading. Se a atualização de runtime falhar, o cluster entrará em um estado de provisionamento Failed. Os componentes de infraestrutura (por exemplo, o dispositivo de armazenamento) podem causar falhas durante a atualização. Em alguns cenários, pode ser necessário diagnosticar a falha com o suporte da Microsoft.