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.
*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:
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.
Aktualisieren Sie den Server, der repariert werden muss.
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.
Nehmen Sie bei Bedarf den Server, den Sie für die Reparatur identifiziert haben, offline. Führen Sie die folgenden Schritte aus:
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.
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.
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.
Weisen Sie dem reparierten Knoten die folgenden Berechtigungen zu:
- Azure Stack HCI Geräteverwaltung Rolle
- Key Vault Secrets User For more information, see Assign permissions to the server.
Führen Sie diese Schritte auf einem anderen Server aus, der Mitglied desselben Azure Stack HCI-Clusters ist.
Bevor Sie den Server hinzufügen, müssen Sie ein aktualisiertes Authentifizierungstoken abrufen. Führen Sie den folgenden Befehl aus:
Update-AuthenticationToken
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.
Notieren Sie sich die Vorgangs-ID als Ausgabe des
Repair-Server
Befehls. Sie verwenden dies später, um den Fortschritt desRepair-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:
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
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.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter:Einreichen und Feedback anzeigen für