Atualizar o tempo de execução do cluster da CLI do Azure

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 Operator Nexus.

Pré-requisitos

• A CLI do Azure Install deve ser instalada.
• A networkcloud extensão CLI é necessária. Se a networkcloud extensão não estiver instalada, ela pode ser instalada seguindo as etapas listadas aqui.
• Acesso ao portal do Azure para o cluster de destino a ser atualizado.
• Tem de ter sessão iniciada na mesma subscrição que o cluster de destino através 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 de execução e íntegro.

Verificando a versão atual do tempo de execução

Verificar a versão atual do tempo de execução do cluster antes da atualização: Como verificar a versão atual do tempo de execução do cluster.

Localizando versões de tempo de execução disponíveis

Através do portal do Azure

Para encontrar versões de tempo de execução 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.

Na guia Versões de atualização disponíveis, podemos ver as diferentes versões de cluster que estão atualmente disponíveis para atualização. O operador pode selecionar entre as versões de tempo de execução de destino listadas. Uma vez selecionado, prossiga para atualizar o cluster.

Através da CLI do Azure

As atualizações disponíveis podem ser recuperadas por meio da CLI do Azure:

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

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

  "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 tempo de execução 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 tempo de execução:

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 necessários:

• strategy-type: Define a estratégia de atualização. Pode ser "Rack" (Rack by Rack) OU "PauseAfterRack" (Atualize um rack de cada vez e aguarde a confirmação antes de prosseguir para o próximo rack. O valor predefinido é Rack. Para realizar uma atualização do tempo de execução do cluster usando a estratégia "PauseRack", siga as etapas descritas em Atualizando o tempo de execução do cluster com uma estratégia de rack de pausa
• tipo de limiar: Determina como o limiar deve ser avaliado, aplicado nas unidades definidas pela estratégia. Isto pode ser "PercentSuccess" OU "CountSuccess". O valor predefinido é PercentSuccess.
• valor-limite: o valor do limite numérico usado para avaliar uma atualização. O valor predefinido é 80.

Parâmetros opcionais:

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

O exemplo a seguir é para um cliente que usa a estratégia Rack by Rack com uma porcentagem 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 que estão sendo provisionados em um rack falharem no provisionamento (em uma base Rack by Rack), a implantação do cluster falhará. Se 60% ou mais dos nós de computação forem provisionados com êxito, a implantação de 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 Rack by 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 que estão sendo provisionados em um rack falharem no provisionamento (em uma base Rack by Rack), a implantação do cluster falhará. Se 10 ou mais dos nós de computação forem provisionados com êxito, a implantação de cluster passará para o próximo rack de nós de computação.

Nota

update-strategy não pode ser alterado após o início da atualização do tempo de execução do cluster. Quando um valor de limite abaixo de 100% é definido, é possível que quaisquer 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 máquinas bare metal, consulte Solucionar problemas do servidor Azure Operator Nexus

Atualizar o tempo de execução do cluster usando a CLI

Para executar uma atualização do tempo de execução, 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 do tempo de execução é um processo longo. A atualização primeiro atualiza os nós de gerenciamento e, em seguida, sequencialmente Rack by 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 são 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 são afetadas. É encorajada a consideração da colocação da carga de trabalho à luz desta conceção de implementação.

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 para o estado atual da atualização. Para verificar o status da atualização, observe o status detalhado do Cluster. Esta verificação pode ser feita através do portal ou az CLI.

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 junto com uma mensagem de status detalhada.

A atualização de cluster está em andamento quando detailedStatus é 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 é definido como Running e detailedStatusMessage mostra a mensagem Cluster is up and running

Para exibir o status da 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 a informação do cluster de destino e o estado detalhado e a mensagem de estado detalhado do cluster devem estar presentes. 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 da máquina baremetal.

Perguntas Mais Frequentes

Identificando a atualização de cluster paralisada/presa

Durante uma atualização em tempo de execução, é 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 tempo de execução pode levar muito tempo para ser concluída com êxito, não há um tempo limite definido especificado atualmente. Portanto, é aconselhável também verificar periodicamente o status e os logs detalhados do cluster para determinar se a atualização está tentando atualizar indefinidamente.

Podemos identificar uma indefinitely attempting to upgrade situação observando os logs do Cluster, a mensagem detalhada e a mensagem de status detalhada. Se ocorrer um tempo limite, observaremos que o Cluster está continuamente se reconciliando sobre o mesmo indefinidamente e não avançando. 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 reexecução de atualização

Se ocorrer uma falha de hardware durante uma atualização, a atualização em tempo de execução continuará desde que os limites definidos sejam atingidos para os nós de computação e gerenciamento/controle. Depois que a máquina é fixada ou substituída, ela é provisionada com o sistema operacional do tempo de execução da plataforma atual, que contém a versão de destino do tempo de execução.

Se ocorrer uma falha de hardware e a atualização de tempo de execução falhar porque os limites não foram atingidos para nós de computação e controle, a reexecução da atualização de tempo de execução pode ser necessária. Dependendo de quando a falha ocorreu e do estado dos servidores individuais em um rack. Se um rack foi atualizado antes de uma falha, a versão de tempo de execução atualizada será usada quando os nós forem reprovisionados. Se a especificação do rack não foi atualizada para a versão de tempo de execução atualizada antes da falha de hardware, a máquina será provisionada com a versão de tempo de execução anterior. Para atualizar para a nova versão de tempo de execução, envie uma nova solicitação de atualização de cluster. Somente os nós com a versão de tempo de execução anterior são atualizados. Os anfitriões que foram bem-sucedidos na ação de atualização anterior não o farão.

Após uma atualização de tempo de execução, o cluster mostra o Estado de Provisionamento "Falha"

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