Teilen über


Reparieren eines Servers auf Azure Stack HCI, Version 23H2

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

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

Informationen zu Reparaturservern

Azure Stack HCI ist ein hyperkonvergiertes 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 auftritt.

Bevor Sie einen Server reparieren, stellen Sie sicher, dass Sie sich mit Ihrem Lösungsanbieter erkundigen, welche Komponenten auf dem Server Feldersatzeinheiten (FRUs) sind, die Sie selbst ersetzen können und welche Komponenten einen Techniker ersetzen müssen.

Teile, die Hot Swap unterstützen, erfordern in der Regel nicht, dass Sie den Server im Gegensatz zu den nicht hot-swappablen Komponenten wie Motherboard neu abbilden müssen. Wenden Sie sich an Den Hardwarehersteller, um zu ermitteln, welche Komponentenersatz Sie zum Umbilden des Servers benötigen. Weitere Informationen finden Sie unter Komponentenersetzung.

Reparieren des Serverworkflows

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

Diagramm, das den Reparaturserverprozess veranschaulicht.

*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. Wenn möglich, beenden Sie den Server, den Sie reparieren möchten. Je nach Zustand des Servers ist ein Herunterfahren möglicherweise nicht möglich oder erforderlich.

  2. Aktualisieren Sie den Server, der repariert werden muss.

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

    Der Speicher wird automatisch auf dem reimaged server neu ausgeglichen. Die Speicherumwogenierung ist ein Vorgang mit niedriger Priorität, der je nach Anzahl der Server und des verwendeten Speichers mehrere Tage lang ausgeführt werden kann.

Unterstützte Szenarios

Durch reparieren eines Servers wird ein Server neu abbildet und mit dem vorherigen Namen und der vorherigen Konfiguration wieder in den Cluster zurückversendet.

Durch das Reparieren eines einzelnen Servers wird eine erneute Bereitstellung mit der Option zum Speichern der Datenvolumes erzielt. Nur das Systemvolume wird während der Bereitstellung gelöscht und neu bereitgestellt.

Wichtig

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

Resilienzeinstellungen

In dieser Version werden für den Reparaturservervorgang 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 als freigegebene Clustervolumes (Cluster Shared Volumes, CSVs) wiederhergestellt und angezeigt.

Die anderen Workloadvolumes, die Sie nach der Bereitstellung erstellt haben, bleiben erhalten, und Sie können diese Volumes ermitteln, indem Sie das Cmdlet ausführen Get-VirtuaDisk . Sie müssen das Volume manuell entsperren (wenn das Volume BitLocker aktiviert ist), und eine CSV -Datei (falls erforderlich) erstellen.

Hardwareanforderungen

Beim Reparieren 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 Prüfung der Mandantenfähigkeit
CPU Überprüfen Sie, ob der neue Server dieselbe Anzahl oder mehr CPU-Kerne aufweist. 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 der neue Server dieselbe Menge oder mehr Arbeitsspeicher installiert hat. Wenn der Speicher 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 dieselbe Anzahl von Datenlaufwerken für Speicherplätze Direct verfügbar ist. 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:

  • Bei einem neuen Server mit einer anderen Seriennummer als dem alten Server.
  • Mit dem aktuellen Server nach dem Umbilden.

Die folgenden Szenarien werden während des Serveraustauschs unterstützt:

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

**Datenträger, die von Speicherplätze Direct verwendet wurden, erfordern eine ordnungsgemäße Reinigung. Die Neuformatierung reicht nicht aus. Erfahren Sie, wie Sie Laufwerke bereinigen.

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-swappable 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-Swappable-Komponenten variieren je nach Originalgerätehersteller (OEM)-Hardwareanbieter. Lesen Sie die Dokumentation Ihres OEM-Herstellers, wenn eine Serverreparatur für nicht austauschbare 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 des Active Directory.
  • Angemeldet als AzureStackLCMUser oder ein anderer Benutzer mit entsprechenden Berechtigungen.
  • Die Anmeldeinformationen für die AzureStackLCMUser nicht geändert wurden.

Reparieren eines Servers

In diesem Abschnitt wird beschrieben, wie Sie einen Server mithilfe von PowerShell reparieren, den Status des Repair-Server Vorgangs überwachen und problembehandlungen, wenn Probleme auftreten.

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

    Wenn Ihr Cluster eine dedizierte Netzwerk-ATC-Absicht für den Speicher verwendet und Benutzerdefinierte Speicher-IPs verwendet, müssen Sie die IPs auf den Speichernetzwerkadaptern konfigurieren, bevor Sie den Reparaturservervorgang ausführen. Wenn Ihr Cluster eine ATC-Absicht für ein freigegebenes Netzwerk für Speicher und andere Datenverkehrstypen wie Compute und Verwaltung verwendet, müssen Sie die IPs auf den virtuellen Speichernetzwerkadaptern manuell konfigurieren, nachdem der Server repariert wurde.

  2. Registrieren Sie den Server bei Arc. Führen Sie die Schritte unter "Mit Arc registrieren" 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.

  3. Weisen Sie dem reparierten Knoten die folgenden Berechtigungen zu:

Führen Sie diese 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 beim Server an, der bereits Mitglied des Clusters ist, mit den Domänenbenutzeranmeldeinformationen, die Sie während der Bereitstellung des Clusters bereitgestellt haben. Führen Sie den folgenden Befehl aus, um den Posteingangsserver zu reparieren:

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

    Hinweis

    Der Servername muss der NetBIOS-Name sein.

  3. Notieren Sie sich die Vorgangs-ID als Ausgabe des Repair-Server Befehls. Sie verwenden dies später, um den Fortschritt des Repair-Server Vorgangs zu überwachen.

Hinweis

Wenn Sie Ihren Azure Stack HCI-Cluster mit benutzerdefinierten Speicher-IPs bereitgestellt haben, müssen Sie den Speichernetzwerkadaptern nach der Reparatur des Servers IPs manuell zuweisen.

Überwachen des Vorgangsfortschritts

Führen Sie die folgenden Schritte aus, um den Fortschritt des Add-Server-Vorgangs 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 Rebalancing-Auftrag für den Hintergrundspeicher weiterhin ausgeführt. Warten Sie, bis der Speicher-Neuausgleichsauftrag abgeschlossen ist. Verwenden Sie das folgende Cmdlet, um den Fortschritt dieses Speicherrebalancingauftrags zu überprüfen:

    Get-VirtualDisk|Get-StorageJob
    

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

Wiederherstellungsszenarien

Die folgenden Wiederherstellungsszenarien und die empfohlenen Entschärfungsschritte werden für die Reparatur eines Servers tabuliert:

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

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 darüber , wie Sie einen Server hinzufügen.