Datenübertragungsleistung von Plalte 1 zu 2 extrem langsam.

[fernet6]

Hallo,

wir habe hier ein Problem. Wir haben eine ESXi 5.1 mit folgender Hardware: Xeon SP-E3-1220v2 / 2 Stück HD2.5" SAS2 900GB Seagate ST9900805SS / 10k als RAID 1 an LSI MegaRaid 9260, 16 GB RAM zugewiesen.

Es gibt mehrere VMs auf der ESXI, die nachts regelmäßig auf eine 3. Platte (Seagate ST2000NM0011, SATA3, 6GB/s) gesichert werden sollen. Das Backup wird mittels Software, die auf einer Windows VM läuft, quasi von einer Platte auf die Backupplatte geschoben. Die Backupplatte selbst ist als Stand-alone Laufwerk auch auf dem RAID-Controller angeschlossen und in der ESXI als Speicher verfügbar gemacht. Dieser gesamte Speicher der Backupplatte wurde dann der Windows Maschine als Festplatte zugewiesen und erscheint dann als Laufwerk im Windows. Wenn ich jetzt ein Backup (hier wird also nichts anderes gemacht, als die blanken Dateien (vmdk,...) von einer Platte auf die andere kopiert). Das Problem ist aber, dass ein Kopiervorgang von 100GB bereits etwa 4-5 Stunden dauert.

Auf einer anderen ESXI haben wir eine ähnliche Konfiguration. Einziger Unterschied (mal abgesehen vom Typ der Backupplatte, die aber in etwa gleiche techn. Daten haben) ist, dass die Backupfestplatte nicht mit auf dem RAID Controller steckt, sondern direkt an einem SATA-Port des Mainboards und dann wurde dieses Laufwerk direkt der VM als RAW Laufwerk zugeordnet. Dort dauert der selbe Kopiervorgang von etwa 550 GB nur knapp 3 Stunden.

Woran kann das Problem der geringen Übertragungsleistung in ersten Konstrukt liegen? Eventuell genau an dem Unterschied zu Variante 2 ??? Werden die Datenzugriffe im RAW Modus anders geregelt?

Wir haben testweise auch schon auf die Software verzichtet und uns mit WinSCP per SSH auf die ESXI eingeloggt und so die Dateien kopiert - selbes Ergebnis.

Danke für Tips!

Rüdiger

[irix]

Hat der RAID Controller keinen WriteCache bzw. hat keinen und hat auch den Cache des Laufwerkes deaktiviert? Bei dem Controller ist BBU optional und beim Kauf muss man daran denken.

Bei der am Onboard Kontroller angeschlossen Disk ist bestimmt der Cache des Laufwerkes aktiviert.

Gruss
Joerg

[Dayworker]

Jep, bei einem HW-Raidcontroller wird aus Datensicherheitsgründen immer der Plattencache abgeschaltet. Dessen Funktion übernimmt ja der wesentlich grössere Write-Cache des HW-Controllers, sofern der Controller einen Write-Cache hat bzw dieser sich überhaupt nachrüsten läßt oder bei fehlender BBU auch aktivieren läßt.
Wenn dieselbe Platte dagegen direkt am Chipsatz hängt, bleibt der Plattencache aktiviert.

[fernet6]

OK, das kann ich mir nochmal anschauen. Also, es hat erstmal nichts damit zu tun, das die Platte quasi in dem ESXI Konstrukt hängt.
Kann ich denn nachträglich am Raidcontroller den Plattencache einschalten, ohne Datenverlusst zu haben?

[Dayworker]

Kommt immer auf den Controller an, ob man den Plattencache wieder reaktivieren kann. In den meisten Fällen lautet die Antwort ja aber, denn wenn dein HW-Controller eine BBU und somit auch Write-Cache hat, brauchst du den Plattencache nicht.
Datenverlust kannst du bei Reaktivierung des Plattencache nur verhindern, wenn der Server zumindest über eine USV abgesichert ist und deren Kapazität zumindest für den sauberen Shutdown aller laufenden VMs auf dem ESXi ausreicht.

Das sich einige HW-Controller zur Aktivierung des Write-Cache auch ohne BBU überreden lassen, sei hier nur am Rande erwähnt und muß jeder mit seinem Gewissen sowie ggf seinem Arbeitgeber ausmachen. Mit deinen zögerlichen Fragen erweckst du aber den Eindruck, als ob bei euch weder BBU noch USV im Einsatz sind und dadurch lebst du selbst bei einem Raid1-System datensicherheitstechnisch eh schon gefährlich. Denn wenn eine Spannungsschwankung beim Schreib-IO eintritt, hat eine Einzelplatte entweder die Daten geschrieben, nicht geschrieben oder wurde mittendrin unterbrochen (gut, unschön oder ganz schlecht). Ab einem Raid1 kommen noch die Fragen hinzu, welches Raidmitglied hat die Daten sowohl geschrieben als auch Vollzug an den Controller gemeldet und welche Datengrundlage nimmt der Controller beim Raid-Rebuild an. Selbst wenn der Controller nachher Konsistenz zwischen den Raidmitgliedern wiederhergestellt hat, sagt das nichts über die Nutzbarkeit der Daten aus.

[fernet6]

@Dayworker: Nein, es gibt eine große USV.

Ich muss mir das und den RAID-Controller aber wirklich in Ruhe nochmal anschauen. Aus dem Hut habe ich die Daten nicht da, ist ja grade Wochenende. Aber hier muss man sicher mit äußerster Vorsicht ran gehen, das ist klar.

Danke nochmals, ich schreibe dann, wie es weiterging...

[kastlr]

Hallo Rüdiger,

ich glaube nicht, das es etwas mit dem Cache zu tun hat.
Schließlich willst du ca. 550GB transferieren, da ist der Cache schon nach wenigen Sekunden aus dem Spiel.

Ich gehe eher davon aus, das die Anzahl der verwendeten Kontroller sowie die Lastverteilung die Ursache ist.

Sofern die Datenmenge auf beiden Systemen vergleichbar ist, muß der LSI Controller im ersten Fall 1,1 TB an Daten transferieren.
Und zwar 550GB Read von LUN0 und 550GB Write auf LUN1.

Im zweiten Fall werden zwar auch 1.1TB an Daten transferiert, aber hier verteilt sich die Last auf zwei verschiedene Kontroller.
Dein LSI RAID Kontroller darf sich ausschließlich um Read IO kümmern, dein SATA Kontroller um die Writes.
Somit verteilt sich die Last, wobei du dann auch noch mehr Resourcen zur Verfügung stehen hast.

Wenn z.B. dein LSI RAID und der SATA Controller während des Backups je 500 IO's (Backups verwenden große IOs) bedienen könnten, stehen dir im Fall 1 nur Resourcen für insgesamt 500 IO's für die Lese und Schreib Operationen zur Verfügung.
Im zweiten Fall könntest du 1000 IO's bedienen.

Im zweiten Beispiel stehen dir also bei gleicher Last deutlich mehr Resourcen zur Verfügung.

Gruß,
Ralf

[fernet6]

So, heute nochmal Zwischenbericht.

Also tatsächlich war der Cache auf dem Controller an den Platten nicht eingeschalten. Das wurde nun nachgeholt. Allerdings hat sich nicht sonderlich viel an der Situation geändert. In ersten Test bringt er nur 570MB / min auf die Waage, wo das andere System etwa 4,1 GB / min bringt.

Ich werde jetzt mit Variante 2 testen, die auch Ralf beschrieben und gut erklärt hat. Allerdings müsste das System ja bals 4 x so schnell werden, um die Raten zu erreichen.

Grüße

Rüdiger

[Dayworker]

der Cache auf dem Controller an den Platten nicht eingeschalten

Das ist etwas mißverständlich. Entweder hast du den Controller- oder den Platten-Cache eingeschaltet. Beide Caches zu aktivieren bringt dir keinen Vorteil und verringert in meinen Augen durch doppeltes Caching sogar den Durchsatz.

Aufgrund des Raid1 wirst du diese Raten trotzdem nicht erreichen. Wenn der Controller geschickt ist, kann er beim Lesen zumindest beide Platte parallel zur Erhöhung des Durchsatzes ausnutzen. Selbst wenn der Controller beide Platten nutzt, berechnet dieser beim Lesen immer noch Prüfsummen zur Wahrung der Raidkonsistenz. Beim Schreiben muß er jedoch auf den Vollzug aller Raidteilnehmer warten und kann dann seinerseits erst Vollzug vermelden. IOPS- und Durchsatz-technisch helfen dir beim Schreiben weder ein Raid1 noch ein Raid5 wirklich weiter.


Du mußt deine IO-Werte aber auch mal ins Verhältnis setzen. Der ESXi ist als Virtualisierungsplattform eh nicht der beste Ort für IO-Rekorde, da der ESXi mehr Ressourcen für die reine VM-Ausführung reserviert. Deine gemessenen MB/min-Raten dürften aber auch noch erreicht werden, wenn der Host viele IO-Anforderungen stemmen muß. Für die gefühlte Schwuppdizität in einer VM ist es von daher besser, wenn die Übertragung vielleicht langsam aber gleichmäßig ist. Ständig schwankender Durchsatz verstärkt meist als Ruckelgefühl.

[fernet6]

Also, es wurden auf dem Controller für die Virtuellen Platten folgende Einstellungen an dem LSI gemacht:

Access: RW
I/O: direct -> Cached
Read: Always Read Ahead
Disk Cache: enable
Disable BGI: no -> disable
Default Write: Write Through -> Write back

Dies wurde nochmals von LSI über den Hersteller so empfohlen. Andere Caches kann ich am Controller nicht instellen.

Ich kann, von den Zeiten her, ob mit oder ohne Cache, keine nennenswerten Unterschiede feststellen.

Aber auch meine Variante mit der RAW Platte direkt am Mainboard Controller hat eher dazu geführt, dass es sogar noch etwas länger dauert.

Ich meine, hier muss doch ein prinzipielles Problem sein. Es geht doch letztlich nicht um 5min sondern um fast 10x mehr Stunden. Wenn ich eine externe HDD nehme und an einen USB Anschluss eines PCs schließe, dann gibt es ja dort bereits eine höhere Datenübertragungsrate.

Es gibt doch noch einen Unterschied zwischen den beiden Systemen. Bei dem bedeutent schnellerem ist eine SSD drin, auf dieser ist nur die ESXI-Software selber drauf. Aber das dürfte auch nicht zu diesen Unterschieden führen.

[kastlr]

Hallo,

lass doch einfach mal esxtop oder vscsiStats mitlaufen, dann haben wir auch mal ein paar handfeste Daten.

Gruß,
Ralf

[fernet6]

Hallo nochmals,

wir haben den Fehler gefunden. Es ist im Grunde so simpel, dass ich mich fast schäme, es hier auszubreiten...

Problem war hier der Virenscanner. Selbstverständlich haben wir diesen gleich als Erstes in Verdacht gehabt. Auch wurde er testweise abgeschalten usw. Allerdings wird hier in einem extra Bereich der Webstream separat (http und https) geprüft. Da das Backupprogramm ja über die Protokolle zugreift, scheint er beim Kopieren der ESXI-Dateien immer weiter geprüft zu haben, obwohl der Virenclient abgeschalten war. Was mir dabei wieder mal vor Augen geführt wurde, dass man für solche Tests den Virenscanner eben nicht nur deaktivieren, sondern testweise komplett deinstallieren sollte...

Dadurch hat sich nun die Kopierzeit für die 700GB von 20 Stunden auf 5,5 Stunden reduziert.

Es bleibt ein kleiner Wehrmutstropfen. Irgendwas stimmt im Verhältnis zur anderen fast baugleichen Maschine (500GB in 2,5 Stunden) trotzdem nicht ganz. Wäre zwar interessant das noch heraus zu finden, aber mit den Zeiten kann man ja leben.

Alle Helfern nochmals vielen Dank, vielleicht kommt ja mal jemand an ne ähnliche Stelle, da ist das ja vielleicht d e r Tip.

Schöne Adventszeit

Rüdiger