Résoudre les problèmes de serveur Azure Operator Nexus

Cet article explique comment résoudre les problèmes de serveur à l’aide des actions de redémarrage, de réinitialisation et de remplacement pour les machines physiques (matériel nu) Azure Operator Nexus. Vous devrez peut-être effectuer ces actions sur votre serveur pour des raisons de maintenance, ce qui entraînera une brève interruption de machines physiques (matériel nu) spécifiques.

Le temps nécessaire à l’exécution de chacune de ces actions est similaire. Le redémarrage est l’action la plus rapide, alors que le remplacement prend un peu plus de temps. Les trois actions sont des méthodes simples et efficaces de résolution des problèmes.

Attention

N’effectuez aucune action sur les serveurs d’administration sans avoir consulté au préalable le Support Microsoft. Cela peut affecter l’intégrité du cluster Operator Nexus.

Prérequis

• Familiarisez-vous avec les fonctionnalités référencées dans cet article en passant en revue les actions sur le matériel nu.
• Rassemblez les informations suivantes :
  • Nom du groupe de ressources managé pour la BMM
  • Nom du matériel qui nécessite une opération de gestion de cycle de vie
  • ID d’abonnement

Important

Les requêtes de commandes disruptives sur un nœud KCP (plan de contrôle Kubernetes) sont rejetées si une autre commande d’action disruptive est déjà en cours d’exécution sur un autre nœud KCP, ou si le KCP complet n’est pas disponible.

Le redémarrage, la réinitialisation et le remplacement sont tous considérés comme des actions disruptives.

Cette vérification vise à maintenir l’intégrité de l’instance Nexus et à éviter que plusieurs nœuds KCP ne tombent en panne en même temps à la suite d’actions disruptives simultanées. Si plusieurs nœuds tombent en panne, le seuil de quorum sain du plan de contrôle Kubernetes est rompu.

Identifier l’action corrective

Pour déterminer l’action corrective la mieux adaptée lors de la résolution des problèmes liés à une BMM, il est essentiel de comprendre quelles sont les options disponibles. Le redémarrage ou le réimageage d’une BMM peut être un moyen efficace de résoudre les problèmes ou de restaurer le logiciel à un état correct connu. Dans les cas où un ou plusieurs composants matériels échouent sur le serveur, il peut être nécessaire de remplacer entièrement la BMM. Cet article décrit les meilleures pratiques pour chacune de ces trois actions.

La résolution des problèmes techniques nécessite une approche systématique. Une méthode efficace consiste à commencer par la solution la moins invasive, puis à passer à des mesures plus complexes et plus radicales si nécessaire.

La première étape de la résolution des problèmes consiste à essayer de redémarrer l’appareil ou le système. Le redémarrage peut permettre d’éliminer les dysfonctionnements ou erreurs temporaires susceptibles d’être à l’origine du problème.

Si le redémarrage ne résout pas le problème, l’étape suivante consiste à essayer de réimager l’appareil ou le système.

Si le réimageage ne résout pas le problème, la dernière étape consiste à remplacer le composant matériel défectueux. Bien que le remplacement soit une mesure plus importante, il peut être nécessaire d’y recourir si le problème provient d’un défaut matériel.

N’oubliez pas que ces méthodes de résolution des problèmes ne sont pas toujours efficaces, et que d’autres facteurs peuvent nécessiter une approche distincte.

Résoudre les problèmes à l’aide d’une action de redémarrage

Le redémarrage d’une machine physique (matériel nu) est un processus qui consiste à redémarrer le serveur via un simple appel d’API. Cette action peut être utile pour résoudre certains problèmes quand des machines virtuelles de tenant (locataire) sur l’hôte ne répondent pas ou sont bloquées.

Le redémarrage est généralement le point de départ de l’atténuation d’un problème.

La commande Azure CLI suivante met hors tension (power-off) la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine power-off \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

La commande Azure CLI suivante réimage (start) la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine start \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

La commande Azure CLI suivante redémarre (restart) la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine restart \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Résoudre les problèmes à l’aide d’une action de réinitialisation

La réinitialisation d’une machine physique (matériel nu) est un processus qui vous permet de redéployer l’image sur le disque du système d’exploitation, sans affecter les données de tenant. Cette action exécute les étapes permettant de rejoindre le cluster avec les mêmes identificateurs.

L’action de réinitialisation peut être utile pour résoudre les problèmes en restaurant le système d’exploitation à un état de fonctionnement connu. Les problèmes courants qui peuvent être résolus par une réinitialisation incluent la récupération en cas de doute sur l’intégrité de l’hôte, à la suite d’une compromission suspectée ou confirmée de la sécurité, ou dans les situations d’urgence.

Une action de réinitialisation est la meilleure pratique à adopter pour réduire au minimum le risque opérationnel, et garantir l’intégrité du matériel nu.

En guise de bonne pratique, assurez-vous que les charges de travail de la BMM sont vidées à l’aide de la commande cordon, avec evacuate "True", avant d’exécuter la commande reimage.

Pour identifier si des charges de travail s’exécutent actuellement sur une BMM, exécutez la commande suivante :

Pour les machines virtuelles :

az networkcloud baremetalmachine show -n <nodeName> /
--resource-group <resourceGroup> /
--subscription <subscriptionID> | jq '.virtualMachinesAssociatedIds'

Pour les nœuds de cluster Nexus Kubernetes : (nécessite une journalisation dans le cluster Nexus Kubernetes)

kubectl get nodes <resourceName> -ojson |jq '.metadata.labels."topology.kubernetes.io/baremetalmachine"'

La commande Azure CLI suivante réimage (cordon) la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine cordon \
  --evacuate "True" \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

La commande Azure CLI suivante réimage (reimage) la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine reimage \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

La commande Azure CLI suivante annule l’isolation (uncordon) de la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine uncordon \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Résoudre les problèmes à l’aide d’une action de remplacement

Les serveurs contiennent de nombreux composants physiques qui peuvent tomber en panne au fil du temps. Il est important de comprendre quelles sont les réparations physiques qui nécessitent un remplacement de BMM et dans quelles circonstances un tel remplacement est recommandé.

Un processus de validation du matériel est mis en œuvre pour garantir l’intégrité de l’hôte physique avant le déploiement de l’image du système d’exploitation. Tout comme l’action de réinitialisation, les données de tenant (locataire) ne sont pas modifiées durant le remplacement.

Important

À compter de la version de l’API GA 2024-07-01, le contrôleur RAID est réinitialisé pendant le remplacement de BMM, en effaçant toutes les données des disques virtuels du serveur. Vous pouvez ignorer les alertes de disque virtuel du contrôleur de gestion de la carte de base (BMC) déclenchées pendant le remplacement de BMM, sauf s’il existe des alertes de disque physique et/ou de contrôleurs RAID supplémentaires.

Conformément aux meilleures pratiques, émettez d’abord une commande cordon pour supprimer le matériel nu de la planification de la charge de travail, puis arrêtez le matériel nu avant les réparations physiques.

La commande Azure CLI suivante isole (cordon) la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine cordon \
  --evacuate "True" \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Quand vous réparez une alimentation physique échangeable à chaud, aucune action de remplacement n’est nécessaire, car l’hôte de la BMM continue de fonctionner normalement après la réparation.

Quand vous effectuez les réparations physiques suivantes, nous vous recommandons d’exécuter une action de remplacement, bien qu’elle ne soit pas nécessaire pour remettre en service la BMM :

• UC
• Module DIMM (Dual In-Line Memory Module)
• Ventilateur
• Riser de carte d’expansion
• Émetteur-récepteur
• Remplacement de câble Ethernet ou en fibre optique

Quand vous effectuez les réparations physiques suivantes, une action de remplacement est obligatoire pour remettre en service la BMM :

• Fond de panier
• Carte système
• Disque SSD
• Carte adaptateur PERC/RAID
• Carte d’interface réseau Mellanox
• Carte d’interface réseau intégrée Broadcom

Une fois les réparations physiques terminées, effectuez une action de remplacement.

La commande Azure CLI suivante remplace (replace) la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine replace \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --bmc-credentials password=<IDRAC_PASSWORD> username=<IDRAC_USER> \
  --bmc-mac-address <IDRAC_MAC> \
  --boot-mac-address <PXE_MAC> \
  --machine-name <OS_HOSTNAME> \
  --serial-number <SERIAL_NUM> \
  --subscription <subscriptionID>

La commande Azure CLI suivante annule l’isolation (uncordon) de la BMM nommée bareMetalMachineName.

az networkcloud baremetalmachine uncordon \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Résumé

Le redémarrage, la réinitialisation et le remplacement sont des méthodes de résolution des problèmes efficaces qui vous permettent de résoudre les problèmes techniques. Toutefois, il est important d’avoir une approche systématique et de prendre en compte d’autres facteurs avant de prendre des mesures radicales. Pour plus d’informations sur les actions BMM, consultez l’article sur les actions BMM.

Si vous avez toujours des questions, contactez le support. Pour plus d’informations sur les plans de support, consultez les plans de support Azure.