Jump to content

Esxi 6.7 reagiert sehr langsam während Raid 6 rebuild


Direkt zur Lösung Gelöst von Squire,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo, 

 

kann es sein, das ein DL380 Gen10 beim Raid-rebuilden (Smart Array hat die Spareplatte automatisch aktiviert) dermaßen langsam ist das man eigentlich alle VMs ausschalten muss/Feierabend machen sollte?

Es sind 8x 1.2 TB SAS 10k mit Hotspare drin.  Der Rebuild läuft seit 1-2 Tagen.  Die aktuelle "Rebuild-Prio"   wurde in den HPE Boot Tools nicht nachgeprüft/geändert.

Es ist mittlerer SQL + kleiner Exchange Server drauf.

Meines Wissens nach war Systemspeed bei bisherigen Festplattendefekten selten ein merkbares Thema. (das waren aber auch andere Server)

Die neuste HPE Firmware ist noch nicht installiert, so dass noch nicht alle möglichen Ursachen abgeklopft sind.

Im esxi Eventlog war diese Meldung auffälliger, die wohl auch mit Heartbeat zusammenhängen soll.

Warnung:
Der Zugriff auf Volume 5c38727b-fxxxxxxx8-c97a-5xxxxxxxxxx4 (Datastore) wurde nach Konnektivitätsproblemen wiederhergestellt.
ca. 10-20 Sekunden später:
Wegen Konnektivitätsproblemen kann nicht mehr auf Volume c38727b-fxxxxxxx8-c97a-5xxxxxxxxxx4 (Datastore) zugegriffen werden. Es wird versucht, eine Wiederherstellung durchzuführen. Das Ergebnis liegt demnächst vor.

 

 

bearbeitet von Dirk-HH-83
Link zu diesem Kommentar
  • 2 Wochen später...
Am 25.6.2020 um 16:38 schrieb Squire:

ich geh mal davon aus, dass die Rebuild Prio auf Hoch steht (beliebter Fehler beim Einrichten. Auf Low oder Normal lassen!) Je nachdem ob Dein Kontroller BWWC hat oder nicht und macht der jetzt nix anderes als Rebuild und alles andere läuft im Schneckentempo

stimmt  Rebuild Prio   ist auf HOCH

 

+++++++++++++++++++

 

Kontroller mit BWWC ? >  es ist der "normale"  P408i-a/2GB FBWC

 

+++++++++++++++++++

 

anders gesagt:   restlos klar+deutlich den Sachverhalt aufklären ist im Nachhinein schwierig und nicht notwendig weil ein Ersatzserver tadellos läuft.

Es ist nur etwas seltsam warum trotz Spare das RAID 6 gar nicht nach kurzer Zeit "grün" geworden ist.  (sondern erst nach wenigen Stunden nachdem die defekte Platte 4 gegen eine neue Platte getauscht wurde.)    

 

+++++++++++++++++++

 

Der HPE Kommentar lautete so: 

 

Die BIOS/FW Versionen des Servers sind alt (von 2018) und eine Aktualisierung mit dem SPP ist sehr empfehlenswert wegen der Server Performance. Anbei Video Anleitung -> https://www.youtube.com/watch?v=ghA2B91my6s

 

SPP Gen10 Service Pack for ProLiant - 2020.03.0(3 Apr 2020): https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_d1f232bbe34b44f797a95b298c

 

Wegen des u.g. Erros muss man nun nicht unternehmen:

 

1716-Slot 0 Drive Array – Unrecoverable Media Errors Detected on Drives during previous Rebuild or Background Surface Analysis scan. Errors will be corrected when the sector(s) are overwritten. Backup and Restore recommended.

 

+++++++++++++++++++++

+++++++++++++++++++++

 

 

Im ILO log standen solche Einträge, ist jetzt leider nicht die haar-genaue-historische Reihenfolge:

logical drive changed to recoving

spare status inactive

spare status active

logical drive status is changed to rebuilding

spare status is changed to building

drive is failed

 

Es ist ein RAID 6 (mit Hotspare)   mit  HDD 8x 1.2 TB SAS 10k

Bevor die neue Ersatzfestplatte eingebaut wurde war der ILO status tagelang "DEGRADED"  in den ersten Tagen stand dort "rebuilding" danach stand dort nur noch  failed oder degraded.

 

+++++++++++++++++++++

+++++++++++++++++++++

 

Es hat ca. 4-6 Tage gedauert bis die Ersatzfestplatte eingebaut wurde.  (danach war das RAID innerhalb weniger Stunden rebuilded = GRÜN)

Beim booten hat der Server  dennoch Meldung, aber laut Support "eher harmlos" / erst SPP Firmware Update:

1716-Slot # Drive Array – Unrecoverable Media Errors Detected on Drives

Symptom

1716-Slot # Drive Array – Unrecoverable Media Errors Detected on Drives during previous Rebuild or Background Surface Analysis (ARM) scan. Errors will be fixed automatically when the sector(s) are overwritten. Backup and Restore recommended.

Cause

A media error is detected on a drive and cannot be corrected because of degraded fault tolerance or a media error at the same location on another drive in the same array. An unrecoverable read error is returned to the operating system when this block address is read.

Action

Back up and restore the data on the drive. Sequential write operations to the affected blocks should resolve the media errors.

 

+++++++++++++++++++++

+++++++++++++++++++++

 

bearbeitet von Dirk-HH-83
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...