Mettez à niveau l'environnement d'exécution du cluster à partir d'Azure CLI

Article
12/19/2024

Ce guide pratique explique les étapes d’installation de l’interface Azure CLI et des extensions nécessaires pour interagir avec Operator Nexus.

Prérequis

L’étape Installer Azure CLI doit être effectuée.
L’extension CLI networkcloud est obligatoire. Si l’extension networkcloud n’est pas installée, vous pouvez le faire en suivant les étapes listées ici.
Accédez au portail Azure pour le cluster cible à mettre à niveau.
Vous devez être connecté au même abonnement que votre cluster cible via az login
Le cluster cible doit être dans un état d’exécution, avec tous les nœuds du plan de contrôle sains, et plus de 80 % des nœuds de calcul dans un état d’exécution et sain.

Vérification de la version d'exécution actuelle

Vérifiez la version actuelle de l'environnement d'exécution du cluster avant la mise à niveau : Comment vérifier la version actuelle de l'environnement d'exécution du cluster.

Recherche des versions de runtime disponibles

Via le portail Azure

Pour rechercher les versions de runtime pouvant être mises à niveau, accédez au cluster cible dans le portail Azure. Dans le volet de présentation du cluster, accédez à l’onglet Versions de mise à niveau disponibles.

Sous l’onglet Versions de mise à niveau disponibles, nous pouvons voir les différentes versions de cluster actuellement disponibles pour la mise à niveau. L’opérateur peut sélectionner une version parmi les versions de runtime cible listées. Après la sélection, passez à la mise à niveau du cluster.

Par Azure CLI

Les mises à niveau disponibles sont récupérables avec Azure CLI :

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

Dans la sortie, vous voyez la propriété availableUpgradeVersions et le champ 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"
    }
  ],

S'il n'y a aucune mise à niveau de cluster disponible, la liste est vide.

Configurer les paramètres de seuil de calcul pour la mise à niveau du runtime en utilisant cluster updateStrategy

La commande Azure CLI suivante permet de configurer les paramètres de seuil de calcul pour une mise à niveau 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>

Paramètres obligatoires :

strategy-type : définit la stratégie de mise à jour. Cela peut être "Rack" (Rack par Rack) OU "PauseAfterRack" (Mettre à niveau un rack à la fois, puis attendre la confirmation avant de passer au rack suivant). La valeur par défaut est Rack. Pour effectuer une mise à niveau du runtime de cluster en utilisant la stratégie « PauseRack », suivez les étapes décrites dans Mise à niveau du runtime de cluster avec une stratégie PauseRack.
threshold-type : détermine la façon dont le seuil doit être évalué, appliqué dans les unités définies par la stratégie. Cela peut être "PercentSuccess" OU "CountSuccess". La valeur par défaut est PercentSuccess.
threshold-value : valeur de seuil numérique utilisée pour évaluer une mise à jour. La valeur par défaut est 80.

Paramètres facultatifs :

max-unavailable : nombre maximal de nœuds worker pouvant être hors connexion, c’est-à-dire mis à niveau pour chaque rack à la fois. La valeur par défaut est 32767.
wait-time-minutes : délai ou période d’attente avant la mise à jour d’un rack. La valeur par défaut est 15.

L'exemple suivant concerne un client utilisant la stratégie Rack by Rack avec un pourcentage de réussite de 60 % et une pause d'une minute.

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>

Vérifiez la mise à jour :

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

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

Dans cet exemple, si moins de 60 % des nœuds de calcul provisionnés dans un rack ne parviennent pas à être provisionnés (rack par rack), le déploiement du cluster échoue. Si 60 % ou plus des nœuds de calcul sont correctement provisionnés, le déploiement du cluster passe au rack suivant de nœuds de calcul.

L'exemple suivant concerne un client utilisant la stratégie Rack by Rack avec un type de seuil CountSuccess de 10 nœuds par rack et une pause d'une minute.

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>

Vérifiez la mise à jour :

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

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

Dans cet exemple, si moins de 10 nœuds de calcul provisionnés dans un rack ne parviennent pas à être provisionnés (rack par rack), le déploiement du cluster échoue. Si 10 nœuds de calcul ou plus sont correctement provisionnés, le déploiement du cluster passe au rack de nœuds de calcul suivant.

Remarque

update-strategy ne peut pas être modifié après le démarrage de la mise à niveau de l'exécution du cluster. Quand une valeur de seuil inférieure à 100 % est définie, il est possible que les nœuds non sains ne soient pas mis à niveau, alors que l’état du « cluster » peut néanmoins indiquer que la mise à niveau a réussi. Pour résoudre les problèmes liés aux machines nues, reportez-vous à Résoudre les problèmes du serveur Azure Operator Nexus

Mettez à niveau l'environnement d'exécution du cluster à l'aide de la CLI

Pour effectuer une mise à niveau du runtime, utilisez la commande Azure CLI suivante :

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

La mise à niveau du runtime est un processus long. La mise à niveau met d'abord à niveau les nœuds worker, puis séquentiellement rack par rack pour les nœuds de travail. La mise à niveau est considérée comme terminée lorsque 80 % des nœuds worker par rack et 100 % des nœuds de gestion sont mis à niveau avec succès. Les charges de travail peuvent être affectées lorsque les nœuds worker d'un rack sont en cours de mise à niveau. Toutefois, les charges de travail de tous les autres racks ne sont pas affectées. Nous vous encourageons à placer les charges de travail en fonction de cette conception d’implémentation.

La mise à niveau de tous les nœuds prend plusieurs heures, selon le nombre de racks existants pour le cluster. En raison de la longueur du processus de mise à niveau, l'état détaillé du cluster doit être vérifié périodiquement pour connaître l'état actuel de la mise à niveau. Pour vérifier l’état de la mise à niveau, observez l’état détaillé du cluster. Cette vérification peut être effectuée en utilisant le portail ou l’interface CLI az.

Pour voir l’état de la mise à niveau dans le portail Azure, accédez à la ressource de cluster ciblée. Dans l’écran Vue d’ensemble du cluster, l’état détaillé est fourni avec un message d’état détaillé.

La mise à niveau du cluster est en cours quand detailedStatus est défini sur Updating et detailedStatusMessage montre la progression de la mise à niveau. Exemples de progression de mise à niveau indiquée dans detailedStatusMessage : Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading..., etc.

La mise à niveau du cluster est terminée quand detailedStatus est défini sur Running et detailedStatusMessage affiche le message Cluster is up and running

Pour voir l’état de mise à niveau avec Azure CLI, utilisez az networkcloud cluster show.

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

La sortie doit indiquer les informations du cluster cible, et contenir l’état détaillé et le message d’état détaillé du cluster. Pour des informations plus détaillées sur la progression de la mise à niveau, l'état de chaque nœud individuel dans chaque rack peut être vérifié. Un exemple de vérification du statut est fourni dans la section de référence sous Rôles de la machine BareMetal.

Forums Aux Questions (FAQ)

Identification du blocage de la mise à niveau du cluster

Pendant une mise à niveau du runtime, il est possible que la mise à niveau ne progresse plus, mais que l’état détaillé indique que la mise à niveau est toujours en cours. Parce que la mise à niveau du runtime peut prendre très longtemps, il n’y a pas de durée définie pour l’expiration du délai d’attente. Par conséquent, nous vous conseillons également de vérifier régulièrement l’état détaillé et les journaux de votre cluster pour déterminer si la mise à niveau tente indéfiniment de s’effectuer.

Nous pouvons identifier une situation indefinitely attempting to upgrade en consultant les journaux du cluster, le message détaillé et le message d'état détaillé. Si un délai d'attente se produit, nous observerons que le cluster se réconcilie continuellement sur la même chose indéfiniment et n'avance pas. À partir de là, nous vous recommandons de consulter les journaux du cluster ou le LAW configuré, pour vérifier s’il y a une défaillance ou si une mise à niveau spécifique provoque le blocage de la progression.

Une défaillance matérielle ne nécessite pas la réexécution de la mise à niveau

Si une panne matérielle se produit pendant une mise à niveau, la mise à niveau d'exécution se poursuit tant que les seuils définis sont respectés pour les nœuds de calcul et de gestion/contrôle. Une fois la machine corrigée ou remplacée, elle est provisionnée avec le système d’exploitation de la plateforme actuelle du runtime, qui contient la version ciblée du runtime.

Si une défaillance matérielle se produit et que la mise à niveau de l'exécution échoue parce que les seuils n'ont pas été atteints pour les nœuds de calcul et de contrôle, une nouvelle exécution de la mise à niveau de l'exécution peut être nécessaire. Cela dépend du moment où la panne s'est produite et de l'état des serveurs individuels dans un rack. Si un rack a été mis à jour avant une défaillance, la version du runtime mis à niveau est utilisée quand les nœuds sont reprovisionnés. Si la spécification du rack n’a pas été mise à jour vers la version du runtime mis à niveau avant la défaillance matérielle, la machine est provisionnée avec la version précédente du runtime. Pour effectuer une mise à niveau vers la nouvelle version d’exécution, soumettez une nouvelle requête de mise à niveau du cluster. Seuls les nœuds avec la version d'exécution précédente sont mis à niveau. Les hôtes qui ont réussi dans l’action de mise à niveau précédente ne sont pas mis à niveau.

Après une mise à niveau du runtime, le cluster affiche l’état de provisionnement « Échec »

Pendant une mise à niveau du runtime, le cluster bascule à l’état Upgrading. Si la mise à niveau de l’exécution échoue, le cluster passe dans un état de provisionnement Failed. Les composants de l'infrastructure (par exemple, le dispositif de stockage) peuvent provoquer des pannes lors de la mise à niveau. Dans certains scénarios, il peut être nécessaire de diagnostiquer l’échec avec le Support Microsoft.

Partager via