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

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 à case activée avec votre fournisseur de solutions, quels composants sur le serveur sont des unités de remplacement de champ (RU) que vous pouvez remplacer vous-même et quels composants nécessiteraient un technicien.

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

Réparer le flux de travail du serveur

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

Diagramme illustrant le processus de réparation du serveur.

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

Pour réparer un serveur existant, suivez ces étapes générales :

  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 réparation du serveur. 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 automatiquement rééquilibré sur le serveur réinitialisé. 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 le 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 la possibilité 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 que vous 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 réparation du serveur, des 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 le fonctionnement du serveur de réparation, seuls les volumes d’infrastructure et les volumes de charge de travail requis 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 le déploiement sont toujours conservés et vous pouvez découvrir ces volumes en exécutant Get-VirtuaDisk l’applet de commande. Vous devez déverrouiller manuellement le volume (si BitLocker est activé sur le volume) 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 s’assure que le serveur répond à la configuration matérielle requise avant son ajout au cluster.

Composant Case activée de conformité
UC Vérifiez que le nouveau serveur a le même nombre de cœurs de processeur ou plus. Si les cœurs du processeur sur le nœud entrant ne répondent pas à cette exigence, un avertissement s’affiche. 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 s’affiche. 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 de l’ancien serveur.
  • Avec le serveur actuel après l’avoir réimageuré.

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

Serveur Disque Pris en charge
Nouveau serveur Nouveaux disques Yes
Nouveau serveur Disques actuels Yes
Serveur actuel (réimage) Disques actuels reformatés * No
Serveur actuel (réimage) Nouveaux disques Yes
Serveur actuel (réimage) Disques actuels Yes

**Les disques utilisés par espaces de stockage direct nécessitent un nettoyage approprié. Le reformatage ne suffit pas. 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 des lecteurs de données. Si vous remplacez un lecteur ou le réinitialisez, le lecteur ne sera pas reconnu une fois que le serveur aura rejoint le cluster.

Remplacement de composants

Sur votre cluster Azure Stack HCI, les composants non échangeables à 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)/backplacement
  • 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 échangeables à chaud varient en fonction de votre fabricant d’équipement d’origine (OEM). Consultez la documentation de votre fournisseur OEM si une réparation de serveur est requise pour les composants non échangeables à 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 autre utilisateur disposant d’autorisations équivalentes.
  • Les informations d’identification du AzureStackLCMUser n’ont pas changé.

Réparer un serveur

Cette section explique comment réparer un serveur à l’aide de PowerShell, surveiller la status de l’opération Repair-Server et résoudre les problèmes en cas de problème.

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 décrites dans Installer le système d’exploitation Azure Stack HCI, version 23H2.

    Notes

    Vous devez également installer les rôles Windows requis.

  2. Inscrivez le serveur auprès d’Arc. Suivez les étapes décrites dans S’inscrire auprès d’Arc et configurez les autorisations.

    Notes

    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.

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 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
    
  3. Notez l’ID d’opération en tant que sortie par la Repair-Server commande . Vous l’utiliserez ultérieurement pour surveiller la progression de l’opération Repair-Server .

Surveiller la progression des opérations

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 continue de 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és pour la réparation d’un serveur :

Description du scénario Limitation des risques Pris en charge ?
Échec de l’opération de réparation du serveur. Pour terminer l’opération, examinez l’échec.
Réexécutez l’opération ayant échoué à l’aide de Add-Server -Rerun.
Yes
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. Yes

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