Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Alles zum Thema vSphere 6.5, ESXi 6.5 und vCenter Server.

Moderatoren: irix, continuum, Dayworker, Tschoergez

Member
Beiträge: 9
Registriert: 02.08.2017, 09:44

Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Beitragvon Maxicko » 03.08.2017, 15:35

Hallo Forengemeinde,

ich habe ein größeres Problem und hoffe, dass sich möglicherweise hier jemand findet, der etwas weiterhelfen kann.

Es geht um einen recht neuen ESX 6.5-Server. Der ESX läuft auf einer kleinen 16GB-SSD.
Dazu kommt ein RAID6 mit 6 HDDs und ein RAID1 mit SSDs für die VMs. Die Platten hängen an einem LSI Megaraid 9361-4i.

Aufgekommen ist das Problem mit der ersten Sicherung der VMs, die auf der SSD liegen. Die Appliance von Acronis liegt auf dem HDD-Raid.
Während der Sicherung ist es zu extremen Latenzen auf den RAIDS gekommen, wo sämtliche VMs kaum mehr ansprechbar waren.
Wenn die Acronis-VA abgeschossen wird, scheint alles wieder zu passen.

Inzwischen konnten wir das Problem auch recht gut eingrenzen. Es reicht bereits eine Datenübertragung vom SSD-Raid auf das HDD-Raid aus um den Fehler zu reproduzieren. Datenübertragung von HDD auf SSD dagegen erzeugt den Fehler nicht.

Im Anhang habe ich einen Screenshot von esxtop hinzugefügt.
Was mich auch etwas verwundert, ist die zusätzliche Disk ganz oben. Diese ist so nicht existent und wird als Local LSI Enclosure Svc Dev erkannt.

In der vmkernel.log wird zudem quasi sekündlich folgende Meldung abgegeben :
lsi_mr3: megasas_hotplug_work:258: event code: 0x71.
Leider habe ich zu dem Code nichts finden können.

Hin und wieder sind auch ein paar SCSI-Fehlercodes zu sehen.
Soweit ich das beurteilen kann, deuten diese aber nur auf das Problem, nicht aber auf die Ursache hin (H:0x2 und selten auch D:0x2).

Dazusagen muss ich noch, dass die SSDs Anfangs nicht als SSD erkannt worden sind und ich mit dem Befehl "esxcli storage nmp satp rule add" das RAID als SSD markiert habe.

Für sämtliche Tipps, die uns in die richtige Richtung bringen, wäre ich sehr dankbar! ;)

Geplant ist momentan ein Wartungsfenster am Freitag Abend, wo wir den LSI-Treiber und die Firmware des RAID-Controllers auf den aktuellsten Stand bringen werden.

Vielen Dank im Voraus.

VG
Max
Dateianhänge
ESX1 Kopiervorgang von SSD auf HDD.JPG

Experte
Beiträge: 1266
Registriert: 04.10.2011, 14:06

Re: Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Beitragvon JustMe » 03.08.2017, 17:32

Nuja, Du hast einen "LSI Megaraid 9361-4i", und daran angeschlossen 6 Platten. Also ist das "Enclosure Device" der Port Multiplier auf der Disk Backplane, der auch vmtl. bestimmte Management-Funktionalitaeten erfuellen kann, und eben als SAS-Device angesprochen wird.

Dass ein konfiguriertes RAID nicht als SSD erkannt wird, ist ganz normal. Es ist ja keine SSD, sondern eben ein RAID Volume. Das muss man auch nicht als SSD "bekanntgeben", wenn es nicht ganz bestimmte Zwecke im ESXi erfuellen soll. Der ESXi erkennt es halt als "recht schnellen Massenspeicher".

Folgende Fragen ergeben sich:
- Was fuer Platten haengen denn am Controller? Etwa SATA oder "NL-SAS"?
- Steht der Cache des Controllers auf WriteBack? Eine BBU wird vmtl. nicht verbaut sein...
- Wie verhaelt sich der Controller bei Verwendung von nur 4 Platten, die aber direkt angeschlossen?
- Hast Du mal probiert, auch die SSDs am RAID-Controller zu betreiben? Dann natuerlich wieder per Backplane.

Als einigermassen fixe Abhilfe koennte man die Ressourcen/Shares der Backup-VM begrenzen.

Member
Beiträge: 9
Registriert: 02.08.2017, 09:44

Re: Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Beitragvon Maxicko » 09.08.2017, 11:55

Erstmal vielen Dank für die Antwort!

Enclosure Device hatte ich bisher so noch nicht gesehen. Liegt aber vermutlich daran, dass alle unsere bisherigen ESX mit 8i-Controllern ausgestattet sind oder 4, bzw. weniger Laufwerke haben.

Die Platten, die am Controller über die Backplane hängen sind 6x SAS 10k (ST1200MM0018) und 2x SAS SSD (ST400FM0303).
Somit würde sich der Punkt 4 erledigen. Die SSDs sind bereits am Controller.

Für beide VDs ist WriteBack standardmäßig aktiv. BBU ist keine verbaut, da die Server eh an einer USV hängen.

Punkt 3 wird fast unmöglich sein durchzuführen, da der Server ja bereits im Betrieb ist.


Es gibt aber auch eine Neuigkeit, nach dem Wartungsabend am Freitag.
Wir haben die neuesten LSI-Treiber am ESX eingespielt, sowie die neueste Firmware am Controller geflasht.
Nachdem der Server eh schon im Wartungsmodus war, habe ich noch das neue Update 1 für ESX 6.5 aufgespielt.

Es läuft nun deutlich besser, aber gelöst ist das Problem damit nicht.
Kopiervorgang von HDD auf SSD läuft (wie bisher) ohne Probleme mit etwas über 100MB/s
Kopiervorgang von SSD auf HDD geht nun schneller (aber immernoch deutlich unter 50MB/s) und die Latenzen sind nicht mehr so extrem wie vorher.
Beim Test (Etwas über 2GB kopiert) kam es auch nur selten vor, dass etwas in die Queue gegangen ist. Auf dem Screenshot ist daher ca. das Maximum bei der Übertragung zu sehen.

Weitere Hinweise nehme ich dankend entgegen.

VG
Max
Dateianhänge
ESX1 - Kopiervorgang von SSD auf HDD nach Update - Kopie.JPG

Experte
Beiträge: 1240
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Re: Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Beitragvon Supi » 09.08.2017, 12:10

Maxicko hat geschrieben:Für beide VDs ist WriteBack standardmäßig aktiv. BBU ist keine verbaut, da die Server eh an einer USV hängen.

Punkt 3 wird fast unmöglich sein durchzuführen, da der Server ja bereits im Betrieb ist.

VG
Max


Schau mal hier: https://www.thomas-krenn.com/de/wiki/SS ... ance-Tests
....am RAID-Controller ist Read-Ahead deaktiviert und der Controller Cache auf Write-Through.

Kann man das pro VD einstellen? Nicht das der Cache mit den Reads der SSD voll läuft und dann die Writes nicht buffern kan.

Ebenso ist aber der Gedanke keine BBU da USV extrem naiv. Gerade diese stellt doch im Zusammenspiel sicher, dass die Daten des Cache sauber auf das Raid geschrieben werden. Wie erkennt dein Controller, dass die USV einen Fehler hat? Der schreibt dann immer noch per WB auf die VD... komme was da wolle.

Member
Beiträge: 9
Registriert: 02.08.2017, 09:44

Re: Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Beitragvon Maxicko » 09.08.2017, 13:58

Hallo Supi,

Für das SSD-RAID ist bereits No Read Ahead eingestellt. (siehe Screenshot)

Der naive Gedanke bezüglich Write-Back ist ja eben, dass die USV die ESX-Server herunterfährt, bevor der Akku leer ist. Oder was gäbe es sonst noch für ein Szenario?

Danke und VG
Max
Dateianhänge
VD-List.JPG

Member
Beiträge: 9
Registriert: 02.08.2017, 09:44

Re: Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Beitragvon Maxicko » 09.08.2017, 14:26

Hallo nochmal,

bin gerade dem Consist=No nachgegangen und habe gleichzeitig mit LSI telefoniert.

Consistency Check kann nicht gestartet werden, da die Background Initialisierung nicht lief.
Diese lässt sich allerdings auch nicht starten. "ErrorCode: 255 Resume BGI not possible"

Daher wird der nächste Schritt sein, die restlichen VMs vom RAID zu nehmen und dieses neu zu erstellen.
Nachdem die Performance nicht mehr ganz so in den Keller geht, ist es zumindestens kein riesiges Problem mehr.

Zum Thema Write-Back war die Aussage, dass es mit USV kein Problem darstellen sollte.

VG
Max

Experte
Beiträge: 1266
Registriert: 04.10.2011, 14:06

Re: Hohe Latenzen bei Datenübertragung von einem RAID zum anderen

Beitragvon JustMe » 09.08.2017, 15:58

@Maxicko:

Als problematische Szenarien bleiben dann z.B. noch:

Was ist, wenn die USV so spinnt, dass sie nicht nur die eine Haelfte Netzteile im Server ausfallen laesst (die andere Haelfte ist ja sicher anders und nicht ueber dieselbe USV angeschlossen), sondern derart stoert, dass der Server komplett stirbt?
Was ist, wenn ein Problem zwischen USV und Server auftritt?

Aber es stimmt schon: Die Wahrscheinlichkeit solcher Ereignisse muss man fuer sich selbst (und ggfs. die Geschaeftsfuehrung) beurteilen...


Zurück zu „vSphere 6.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast