Reparieren eines Servers in Azure Stack HCI, Version 23H2

Gilt für: Azure Stack HCI, Version 23H2

In diesem Artikel wird beschrieben, wie Sie einen Server in Ihrem Azure Stack HCI-Cluster reparieren.

Informationen zu Reparaturservern

Azure Stack HCI ist ein hyperkonvergentes System, mit dem Sie Server aus vorhandenen Clustern reparieren können. Möglicherweise müssen Sie einen Server in einem Cluster reparieren, wenn ein Hardwarefehler vorliegt.

Bevor Sie einen Server reparieren, überprüfen Sie mit Ihrem Lösungsanbieter, welche Komponenten auf dem Server Feldersatzeinheiten (Field Replacement Units, FRUs) sind, die Sie selbst ersetzen können, und welche Komponenten ein Techniker ersetzen muss.

Für Teile, die Hot Swap unterstützen, müssen Sie im Gegensatz zu nicht hot-swapfähigen Komponenten wie der Hauptplatine in der Regel kein erneutes Image des Servers durchführen. Wenden Sie sich an Ihren Hardwarehersteller, um zu ermitteln, für welche Komponentenersetzungen Sie ein erneutes Image des Servers erfordern würden. Weitere Informationen finden Sie unter Austausch von Komponenten.

Reparieren des Serverworkflows

Das folgende Flussdiagramm zeigt den gesamten Prozess zum Reparieren eines Servers.

Diagramm zur Veranschaulichung des Reparaturserverprozesses.

*Der Server befindet sich möglicherweise nicht in einem Zustand, in dem das Herunterfahren möglich oder erforderlich ist.

Führen Sie die folgenden allgemeinen Schritte aus, um einen vorhandenen Server zu reparieren:

  1. Fahren Sie nach Möglichkeit den Server herunter, den Sie reparieren möchten. Je nach Status des Servers ist ein Herunterfahren möglicherweise nicht möglich oder erforderlich.

  2. Erstellen Sie ein erneutes Image des Servers, der repariert werden muss.

  3. Führen Sie den Reparaturservervorgang aus. Das Azure Stack HCI-Betriebssystem, die Treiber und die Firmware werden im Rahmen des Reparaturvorgangs aktualisiert.

    Der Speicher wird automatisch auf dem Server mit einem erneuten Image ausgeglichen. Speicherausgleich ist eine Aufgabe mit niedriger Priorität, die je nach Anzahl der Server und verwendetem Speicher mehrere Tage lang ausgeführt werden kann.

Unterstützte Szenarios

Durch das Reparieren eines Servers wird ein Server erneut erstellt und mit dem vorherigen Namen und der konfiguration wieder in den Cluster übertragen.

Das Reparieren eines einzelnen Servers führt zu einer erneuten Bereitstellung mit der Option zum Beibehalten der Datenvolumes. Während der Bereitstellung wird nur das Systemvolume gelöscht und neu bereitgestellt.

Wichtig

Stellen Sie sicher, dass Sie immer über Sicherungen für Ihre Workloads verfügen und sich nicht nur auf die Systemresilienz verlassen. Dies ist besonders in Szenarien mit nur einem Server von entscheidender Bedeutung.

Resilienzeinstellungen

In dieser Version werden für den Reparaturserverbetrieb bestimmte Aufgaben nicht auf den Workloadvolumes ausgeführt, die Sie nach der Bereitstellung erstellt haben. Für den Reparaturserverbetrieb werden nur die erforderlichen Infrastrukturvolumes und die Workloadvolumes wiederhergestellt und als freigegebene Clustervolumes (Cluster Shared Volumes, CSVs) angezeigt.

Die anderen Workloadvolumes, die Sie nach der Bereitstellung erstellt haben, werden weiterhin beibehalten, und Sie können diese Volumes ermitteln, indem Sie das Cmdlet ausführen Get-VirtuaDisk . Sie müssen das Volume manuell entsperren (wenn auf dem Volume BitLocker aktiviert ist) und bei Bedarf eine CSV-Datei erstellen.

Hardwareanforderungen

Bei der Reparatur eines Servers überprüft das System die Hardware des neuen Eingehenden Servers und stellt sicher, dass der Server die Hardwareanforderungen erfüllt, bevor er dem Cluster hinzugefügt wird.

Komponente Konformitätsprüfung
CPU Überprüfen Sie, ob der neue Server über die gleiche Anzahl von oder mehr CPU-Kernen verfügt. Wenn die CPU-Kerne auf dem eingehenden Knoten diese Anforderung nicht erfüllen, wird eine Warnung angezeigt. Der Vorgang ist jedoch zulässig.
Arbeitsspeicher Überprüfen Sie, ob auf dem neuen Server die gleiche Oder mehr Arbeitsspeicher installiert ist. Wenn der Arbeitsspeicher auf dem eingehenden Knoten diese Anforderung nicht erfüllt, wird eine Warnung angezeigt. Der Vorgang ist jedoch zulässig.
Laufwerke Überprüfen Sie, ob der neue Server über die gleiche Anzahl von Datenlaufwerken verfügt, die für Direkte Speicherplätze verfügbar sind. Wenn die Anzahl der Laufwerke auf dem eingehenden Knoten diese Anforderung nicht erfüllt, wird ein Fehler gemeldet, und der Vorgang wird blockiert.

Serverersetzung

Sie können den gesamten Server ersetzen:

  • Mit einem neuen Server, der im Vergleich zum alten Server eine andere Seriennummer aufweist.
  • Mit dem aktuellen Server, nachdem Sie ein erneutes Image erstellt haben.

Die folgenden Szenarien werden beim Ersetzen des Servers unterstützt:

Server Datenträger Unterstützt
Neuer Server Neue Datenträger Yes
Neuer Server Aktuelle Datenträger Yes
Aktueller Server (reimaged) Aktuelle Datenträger neu formatiert * No
Aktueller Server (reimaged) Neue Datenträger Yes
Aktueller Server (reimaged) Aktuelle Datenträger Yes

**Datenträger, die von Direkte Speicherplätze verwendet wurden, müssen ordnungsgemäß gereinigt werden. Die Neuformatierung reicht nicht aus. Weitere Informationen finden Sie unter Bereinigen von Laufwerken.

Wichtig

Wenn Sie eine Komponente während der Serverreparatur ersetzen, müssen Sie keine Datenlaufwerke ersetzen oder zurücksetzen. Wenn Sie ein Laufwerk ersetzen oder zurücksetzen, wird das Laufwerk nicht erkannt, sobald der Server dem Cluster beitritt.

Komponentenaustausch

In Ihrem Azure Stack HCI-Cluster enthalten nicht hot swapfähige Komponenten die folgenden Elemente:

  • Hauptplatine/Baseboard-Verwaltungscontroller (BMC)/Grafikkarte
  • Datenträgercontroller/Hostbusadapter (HBA)/Backplace
  • Netzwerkadapter
  • Grafikverarbeitungseinheit
  • Datenlaufwerke (Laufwerke, die den Austausch bei laufendem Betrieb nicht unterstützen, z. B. PCI-e-Add-In-Karten)

Die tatsächlichen Austauschschritte für Nicht-Hot-Swap-Komponenten variieren je nach OEM-Hardwareanbieter (Original Equipment Manufacturer). Lesen Sie die Dokumentation Ihres OEM-Herstellers, wenn eine Serverreparatur für Nicht-Hot-Swap-fähige Komponenten erforderlich ist.

Voraussetzungen

Bevor Sie einen Server reparieren, müssen Sie Folgendes sicherstellen:

  • AzureStackLCMUser ist in Active Directory aktiv. Weitere Informationen finden Sie unter Vorbereiten von Active Directory.
  • Angemeldet als AzureStackLCMUser oder ein anderer Benutzer mit entsprechenden Berechtigungen.
  • Die Anmeldeinformationen für haben AzureStackLCMUser sich nicht geändert.

Reparieren eines Servers

In diesem Abschnitt wird beschrieben, wie Sie einen Server mithilfe von PowerShell reparieren, die status des Repair-Server Vorgangs überwachen und probleme beheben.

Stellen Sie sicher, dass Sie die Voraussetzungen überprüft haben.

Führen Sie die folgenden Schritte auf dem Server aus, den Sie reparieren möchten.

  1. Installieren Sie das Betriebssystem und die erforderlichen Treiber. Führen Sie die Schritte unter Installieren des Azure Stack HCI,Version 23H2-Betriebssystems aus.

    Hinweis

    Sie müssen auch erforderliche Windows-Rollen installieren.

  2. Registrieren Sie den Server bei Arc. Führen Sie die Schritte unter Registrieren bei Arc aus, und richten Sie Berechtigungen ein.

    Hinweis

    Sie müssen dieselben Parameter wie die vorhandenen Knoten verwenden, um sich bei Arc zu registrieren. Beispiel: Ressourcengruppenname, Region, Abonnement und Tentant.

Führen Sie die folgenden Schritte auf einem anderen Server aus, der Mitglied desselben Azure Stack HCI-Clusters ist.

  1. Bevor Sie den Server hinzufügen, müssen Sie ein aktualisiertes Authentifizierungstoken abrufen. Führen Sie den folgenden Befehl aus:

     Update-AuthenticationToken
    
  2. Melden Sie sich bei dem Server an, der bereits Mitglied des Clusters ist, mit den Domänenbenutzeranmeldeinformationen, die Sie während der Bereitstellung des Clusters angegeben haben. Führen Sie den folgenden Befehl aus, um den Eingehenden Server zu reparieren:

    $Cred = Get-Credential 
    Repair-Server -Name "< Name of the new server>" -LocalAdminCredential $Cred
    
  3. Notieren Sie sich die Vorgangs-ID als Ausgabe des Repair-Server Befehls. Sie verwenden dies später, um den Fortschritt des Vorgangs Repair-Server zu überwachen.

Überwachen des Vorgangsstatus

Führen Sie die folgenden Schritte aus, um den Fortschritt des Vorgangs "Server hinzufügen" zu überwachen:

  1. Führen Sie das folgende Cmdlet aus, und geben Sie die Vorgangs-ID aus dem vorherigen Schritt an.

    $ID = "<Operation ID>" 
    Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID 
    
  2. Nach Abschluss des Vorgangs wird der Auftrag zum Ausgleichen des Hintergrundspeichers weiterhin ausgeführt. Warten Sie, bis der Speicherausgleichsauftrag abgeschlossen ist. Verwenden Sie das folgende Cmdlet, um den Fortschritt dieses Speicherausgleichsauftrags zu überprüfen:

    Get-VirtualDisk|Get-StorageJob
    

    Wenn der Speicherausgleichsauftrag abgeschlossen ist, gibt das Cmdlet keine Ausgabe zurück.

Wiederherstellungsszenarien

Die folgenden Wiederherstellungsszenarien und die empfohlenen Schritte zur Entschärfung werden für die Reparatur eines Servers tabellariert:

Beschreibung des Szenarios Abhilfemaßnahmen Unterstützt?
Fehler beim Reparieren des Servervorgangs. Um den Vorgang abzuschließen, untersuchen Sie den Fehler.
Führen Sie den fehlgeschlagenen Vorgang mit erneut aus Add-Server -Rerun.
Yes
Der Reparaturservervorgang war teilweise erfolgreich, musste aber mit einer neuen Betriebssysteminstallation beginnen. In diesem Szenario hat der Orchestrator (auch als Lifecycle Manager bezeichnet) seinen Wissensspeicher bereits mit dem neuen Server aktualisiert. Verwenden Sie das Reparaturserverszenario. Yes

Problembehandlung

Wenn beim Reparieren eines Servers Fehler oder Fehler auftreten, können Sie die Ausgabe der Fehler in einer Protokolldatei erfassen.

  • Melden Sie sich mit den Domänenbenutzeranmeldeinformationen an, die Sie während der Bereitstellung des Clusters angegeben haben. Erfassen Sie das Problem in den Protokolldateien.

    Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
    
  • Verwenden Sie das folgende Cmdlet, um den fehlgeschlagenen Vorgang erneut auszuführen:

    Repair-Server -Rerun
    

Nächste Schritte

Erfahren Sie mehr über das Hinzufügen eines Servers.