VMware-Forum

Auf einem neuen Server Fujitsu RX2540 haben wir IO-Probleme mit einem RAID-System.

Konfiguration:
PRAID EP420i, Treiber-Version: 6.605.08.00, Firmware-Package-Version: 24.7.0-0061 (RAID 5) mit 8 internen Festplatten à 1TB.
ESXi 6.0.0 Build 5224934
VMWare-Tools 10.0.9.55972, Build-3917699
Windows-Server 2012 R2
Basis-VMDK mit Windows: 160 GB
Daten-VMDK mit 6 TB

Jede Nacht starten wir einen umfangreichen Kopiervorgang mit Robocopy, der mehrere hundert Gigabyte bis zu mehrere Terabyte auf ein externes Backup-Medium kopiert.

Das Problem äußert sich folgendermaßen:

1) Hardware-Monitor meldet keinerlei Probleme
2) ESXi meldet:
> Wegen Konnektivitätsproblemen kann nicht mehr
> auf Volume
> 58b96fe1-567472d2-63b5-0090facf0bd6
> (VMStorage01) zugegriffen werden. Es wird
> versucht, eine Wiederherstellung durchzuführen.
> Das Ergebnis liegt demnächst vor.
3) Windows meldet zunächst: Warnung 129:
> Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.
Dann folgen einige Meldungen: Warnung 153:
> Der E/A-Vorgang an der logischen Blockadresse "0x2aa82ec20" für den Datenträger "1" (PDO-Name: \Device\00000030) wurde wiederholt.
Sobald diese Warnungen kommen, kann es passieren, dass das Windows-System zu stehen scheint, also beispielsweise auch keine Mausbewegungen möglich sind. Das kann von ein paar Sekunden bis zu mehreren Minuten dauern.

Vorgeschichte: Als wir die Maschine in Betrieb nahmen und einen Kopiervorgang mit 20 GB starteten, "fror" die Maschine ein und in den Protokollen waren haufenweise die oben genannten Meldungen (Konnektivitätsprobleme, Warnungs-Sequenz 129, 153). Der Kopiervorgang dauerte statt einigen Minuten bis zu 12 Stunden. Währenddessen war ein Arbeiten am Server nicht möglich.
Daraufhin tauschte Fujitsu den RAID-Controller aus. Danach schien die Maschine ordnungsgemäß zu laufen, bis auf die oben genannten Probleme.

Alternativ haben wir im gleichen vCenter einen Server Fujitsu RX300 S8 genau gleich aufgesetzt und haben dort dieses Problem nicht. Auch ein vergleichbar konfigurierter Dell-Server läuft ohne jedes Problem.

Was können wir machen? Welche Protokolle oder Logs liefern uns weitere Einsichten? Wir würden gerne den Produktiv-Start unseres Servers ohne diese Warnungen beginnen.

Das sind, wenn ich deinen Beitrag richtig verstanden habe, auf dem Server (während des Robocopy-Vorganges) nur Leseoperationen? Wie ist das Backup-Medium angebunden?

Erste Anlaufstelle: vmkernel.log des ESXi - da sollte der Kernel etwas zu meckern haben.

HFMAdmin hat geschrieben:Auf einem neuen Server Fujitsu RX2540 haben wir IO-Probleme mit einem RAID-System.

Konfiguration:
PRAID EP420i, Treiber-Version: 6.605.08.00, Firmware-Package-Version: 24.7.0-0061 (RAID 5) mit 8 internen Festplatten à 1TB.

Laut Fujitsu erst mal etwas älter:
Firmware for PRAID EP4x0i (ASP for Windows) / Version (Datum)
24.7.0-0061 - 4.270.00-4869 - 1.0.0 (23.11.2015)

Aktuell wäre:
24.16.0-0097 - 4.660.00-8175 - 1.0.0 (11.04.2017)

ggf. mal mit dem 6.6.11er Probieren?
https://www.vmware.com/resources/compat ... 0&vcl=true
zweiter Link.

Grundsätzlich sollte das aber laufen und ist schon komisch.
ggf. ähnlich wie hier (wobei deine Platten ja nicht beim booten offline sind)
https://kb.vmware.com/selfservice/micro ... Id=2142661

Letztes Server Bios ist drauf? V5.0.0.11 - R1.15.0

Ansonsten, wieso so große Datenmengen per Robocopy? Ihr habt doch VM's, da sichert man über die VMWARE Schnittstelle z.B. per Veeam. Geht sicher auch schneller.
Befürchte aber, dass das normale SATA oder NL-Sata Platten sind, oder?

1. Bei dem Kontroller ist BBU optional - Ist diese vorhanden?
2. Letzte Woche war ich bei einem Kunden der hatte auf seinem Fujitsu vergessen den Cache fuer die Volume vergessen zu aktivieren. Ich kenne leider das Default Setting bei dem Kontroller nicht.
3. Sata/NL HDDs sind nunmal nicht schnellsten. Aber fuer eine VM sollte es reichen

Mich wuerde die Ausgabe von esxtop "d" und "v" interessieren wenn du den Kopierjobs startest.

Gruss
Joerg

Vielleicht hilfreich um die Konfiguration zu prüfen, sind ja schicke Bilder:
https://www.alteeve.com/w/Configuring_H ... u_Primergy

Ab dem genannten Bios 24.7.0-0061 wird wohl ein Feature namens Fastpath supported, was aber eher für SSD's gedacht ist.
Wenn man dann "Fast Path optimum" einstellt, kommt folgendes raus:

• Read Mode „No read-ahead“
• Write Mode „Write-through“
• Cache Mode „Direct“
• Disk Cache „Enabled“

https://sp.ts.fujitsu.com/dmsp/Publicat ... -ww-de.pdf

Gefuehlt sahen die Settings beim Kunden auch so aus. Die Latenz ist von 250ms auf ~5 gesunken nachdem man Write-Back und nach einen weiteren Test auch ReadAhead aktiviert hat.

Gruss
Joerg

vielen Dank für die zahlreichen Antworten. Wir sind alle Einstellungen nochmals durchgegangen. Einerseits sind sie alle korrekt, d.h. sie entsprechen den hier empfohlenen. Andererseits hat der Fujitsu-Techniker die Einstellungen nach Einbau des neuen Controllers getestet und zum Teil angepasst.

Es verdichten sich aktuell Hinweise, dass möglicherweise ein Problem im Bereich Stecker / Verbindungen / Kabel die Ursache sein könnte, z.B. kalte Lötstelle. Das würde mit anderen Faktoren zusammenpassen, nämlich dass wir das Gerät mit einem UFM Device ausgeliefert bekommen hatten, das wir dann selbst einbauen mussten. Möglicherweise war der alte Controller ok, aber durch das Umstecken hat sich das Problem im Verbindungsbereich einfach abgeschwächt.

Übrigens war auf dem alten Controller das RAID-Paket in der Version 24.16 installiert. Das war aber im März von Fujitsu noch nicht freigegeben.

Könnte unsere Vermutung zutreffen?

Gruß Helmut