Partager via

Réparer un serveur sur Azure Stack HCI, version 23H2

  • Article

S’applique à : Azure Stack HCI, version 23H2

Cet article explique comment réparer un serveur sur votre cluster Azure Stack HCI.

À propos des serveurs de réparation

Azure Stack HCI est un système hyperconvergé qui vous permet de réparer des serveurs à partir de clusters existants. Vous devrez peut-être réparer un serveur dans un cluster en cas de défaillance matérielle.

Avant de réparer un serveur, veillez à vérifier auprès de votre fournisseur de solutions quels composants sur le serveur sont des unités de remplacement de champ (FRU) que vous pouvez remplacer vous-même et quels composants exigeraient qu’un technicien remplace.

Les parties qui prennent en charge l’échange à chaud ne nécessitent généralement pas que vous réimagez le serveur contrairement aux composants non permutables à chaud tels que la carte mère. Consultez votre fabricant de matériel pour déterminer quels remplacements de composants vous obligeraient à réimager le serveur. Pour plus d’informations, consultez Remplacement du composant.

Flux de travail du serveur de réparation

Le diagramme de flux suivant montre le processus global de réparation d’un serveur.

Diagramme illustrant le processus de serveur de réparation.

*Le serveur peut ne pas être dans un état où l’arrêt est possible ou nécessaire

Pour réparer un serveur existant, procédez comme suit :

  1. Si possible, arrêtez le serveur que vous souhaitez réparer. Selon l’état du serveur, un arrêt peut ne pas être possible ou nécessaire.

  2. Réimagez le serveur qui doit être réparé.

  3. Exécutez l’opération de serveur de réparation. Le système d’exploitation, les pilotes et le microprogramme Azure Stack HCI sont mis à jour dans le cadre de l’opération de réparation.

    Le stockage est rééquilibré automatiquement sur le serveur réimagené. Le rééquilibrage du stockage est une tâche de faible priorité qui peut s’exécuter pendant plusieurs jours en fonction du nombre de serveurs et du stockage utilisé.

Scénarios pris en charge

La réparation d’un serveur réimage un serveur et la ramène au cluster avec le nom et la configuration précédents.

La réparation d’un serveur unique entraîne un redéploiement avec l’option permettant de conserver les volumes de données. Seul le volume système est supprimé et nouvellement provisionné pendant le déploiement.

Important

Assurez-vous que vous disposez toujours de sauvegardes pour vos charges de travail et ne vous fiez pas uniquement à la résilience du système. Cela est particulièrement critique dans les scénarios à serveur unique.

Paramètres de résilience

Dans cette version, pour l’opération de serveur de réparation, les tâches spécifiques ne sont pas effectuées sur les volumes de charge de travail que vous avez créés après le déploiement. Pour l’opération de serveur de réparation, seuls les volumes d’infrastructure requis et les volumes de charge de travail sont restaurés et exposés en tant que volumes partagés de cluster (CSV).

Les autres volumes de charge de travail que vous avez créés après la conservation du déploiement et vous pouvez découvrir ces volumes en exécutant l’applet Get-VirtuaDisk de commande. Vous devez déverrouiller manuellement le volume (si bitLocker est activé) et créer un fichier CSV (si nécessaire).

Configuration matérielle requise

Lors de la réparation d’un serveur, le système valide le matériel du nouveau serveur entrant et garantit que le serveur répond à la configuration matérielle requise avant son ajout au cluster.

Composant Vérification de la conformité
UC Vérifiez que le nouveau serveur a le même nombre de cœurs d’UC ou plus. Si les cœurs du processeur sur le nœud entrant ne répondent pas à cette exigence, un avertissement est présenté. L’opération est toutefois autorisée.
Mémoire Vérifiez que le nouveau serveur a la même quantité de mémoire installée ou plus. Si la mémoire sur le nœud entrant ne répond pas à cette exigence, un avertissement est présenté. L’opération est toutefois autorisée.
Lecteurs Vérifiez que le nouveau serveur a le même nombre de lecteurs de données disponibles pour espaces de stockage direct. Si le nombre de lecteurs sur le nœud entrant ne répond pas à cette exigence, une erreur est signalée et l’opération est bloquée.

Remplacement du serveur

Vous pouvez remplacer l’intégralité du serveur :

  • Avec un nouveau serveur qui a un numéro de série différent par rapport à l’ancien serveur.
  • Avec le serveur actuel une fois que vous l’avez réimager.

Les scénarios suivants sont pris en charge lors du remplacement du serveur :

Serveur Disque Pris en charge
Nouveau serveur Nouveaux disques Oui
Nouveau serveur Disques actuels Oui
Serveur actuel (réimaged) Disques actuels reformatés * Non
Serveur actuel (réimaged) Nouveaux disques Oui
Serveur actuel (réimaged) Disques actuels Oui

**Les disques utilisés par espaces de stockage direct nécessitent un nettoyage approprié. La reformatage n’est pas suffisante. Découvrez comment nettoyer les lecteurs.

Important

Si vous remplacez un composant pendant la réparation du serveur, vous n’avez pas besoin de remplacer ou de réinitialiser les lecteurs de données. Si vous remplacez un lecteur ou réinitialisez-le, le lecteur ne sera pas reconnu une fois que le serveur rejoint le cluster.

Remplacement de composants

Sur votre cluster Azure Stack HCI, les composants non permutables à chaud incluent les éléments suivants :

  • Contrôleur de gestion de la carte mère/carte de base (BMC)/carte vidéo
  • Contrôleur de disque/adaptateur de bus hôte (HBA)/backplace
  • Carte réseau
  • Unité de traitement graphique
  • Lecteurs de données (ne prenant pas en charge l’échange à chaud, comme les cartes complémentaires PCI-e)

Les étapes de remplacement réelles pour les composants non permutables à chaud varient en fonction de votre fabricant de matériel oem (OEM). Consultez la documentation de votre fournisseur OEM si une réparation de serveur est requise pour les composants non permutables à chaud.

Prérequis

Avant de réparer un serveur, vous devez vous assurer que :

  • AzureStackLCMUser est actif dans Active Directory. Pour plus d’informations, consultez Préparer Active Directory.
  • Connecté en tant qu’utilisateur AzureStackLCMUser ou un autre utilisateur disposant d’autorisations équivalentes.
  • Les informations d’identification pour le AzureStackLCMUser n’ont pas changé.

Réparer un serveur

Cette section explique comment réparer un serveur à l’aide de PowerShell, surveiller l’état de l’opération Repair-Server et résoudre les problèmes, s’il existe des problèmes.

Vérifiez que vous avez examiné les conditions préalables.

Suivez ces étapes sur le serveur que vous essayez de réparer.

  1. Installez le système d’exploitation et les pilotes requis. Suivez les étapes de l’installation du système d’exploitation Azure Stack HCI version 23H2.

    Remarque

    Si votre cluster utilise une intention ATC réseau dédiée pour le stockage et que vous utilisez des adresses IP de stockage personnalisées, vous devez configurer les adresses IP sur les cartes réseau de stockage avant d’exécuter l’opération Repair-Server. Si votre cluster utilise une intention ATC de réseau partagé pour le stockage et d’autres types de trafic comme le calcul et la gestion, vous devez configurer manuellement les adresses IP sur les cartes réseau virtuelles de stockage une fois le serveur réparé.

  2. Inscrivez le serveur auprès d’Arc. Suivez les étapes de l’inscription auprès d’Arc et configurez les autorisations.

    Remarque

    Vous devez utiliser les mêmes paramètres que les nœuds existants pour vous inscrire auprès d’Arc. Par exemple : nom du groupe de ressources, région, abonnement et Tentant.

  3. Affectez les autorisations suivantes au nœud réparé :

Suivez ces étapes sur un autre serveur membre du même cluster Azure Stack HCI.

  1. Avant d’ajouter le serveur, veillez à obtenir un jeton d’authentification mis à jour. Exécutez la commande suivante :

     Update-AuthenticationToken

  2. Connectez-vous au serveur qui est déjà membre du cluster, avec les informations d’identification de l’utilisateur de domaine que vous avez fournies pendant le déploiement du cluster. Exécutez la commande suivante pour réparer le serveur entrant :

    $Cred = Get-Credential 
Repair-Server -Name "< Name of the new server>" -LocalAdminCredential $Cred

    Remarque

    Le nom du serveur doit être le nom NetBIOS.

  3. Notez l’ID d’opération comme sortie par la Repair-Server commande. Vous l’utilisez ultérieurement pour surveiller la progression de l’opération Repair-Server .

Remarque

Si vous avez déployé votre cluster Azure Stack HCI à l’aide d’adresses IP de stockage personnalisées, vous devez affecter manuellement des adresses IP aux cartes réseau de stockage une fois le serveur réparé.

Surveiller la progression de l’opération

Pour surveiller la progression de l’opération d’ajout de serveur, procédez comme suit :

  1. Exécutez l’applet de commande suivante et fournissez l’ID d’opération de l’étape précédente.

    $ID = "<Operation ID>" 
Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID

  2. Une fois l’opération terminée, le travail de rééquilibrage du stockage en arrière-plan continuera à s’exécuter. Attendez que le travail de rééquilibrage du stockage se termine. Pour vérifier la progression de ce travail de rééquilibrage du stockage, utilisez l’applet de commande suivante :

    Get-VirtualDisk|Get-StorageJob

    Si le travail de rééquilibrage du stockage est terminé, l’applet de commande ne retourne pas de sortie.

Scénarios de récupération

Les scénarios de récupération suivants et les étapes d’atténuation recommandées sont tabulées pour la réparation d’un serveur :

Description du scénario Limitation des risques Pris en charge ?
Échec de l’opération de serveur de réparation. Pour terminer l’opération, examinez l’échec.
Réexécutez l’opération ayant échoué à l’aide Add-Server -Rerunde .		 Oui
L’opération de réparation du serveur a réussi partiellement, mais a dû commencer par une nouvelle installation du système d’exploitation. Dans ce scénario, l’orchestrateur (également appelé Gestionnaire de cycle de vie) a déjà mis à jour sa base de connaissances avec le nouveau serveur. Utilisez le scénario de serveur de réparation. Oui

Dépannage

Si vous rencontrez des échecs ou des erreurs lors de la réparation d’un serveur, vous pouvez capturer la sortie des échecs dans un fichier journal.

  • Connectez-vous avec les informations d’identification de l’utilisateur de domaine que vous avez fournies pendant le déploiement du cluster. Capturez le problème dans les fichiers journaux.

    Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt

  • Pour réexécuter l’opération ayant échoué, utilisez l’applet de commande suivante :

    Repair-Server -Rerun

Étapes suivantes

En savoir plus sur l’ajout d’un serveur.