VMware-Forum

Hallo zusammen,

wir haben folgenden Fall:

Wir haben ein SAN, dessen Luns an esxi 5.1 angebunden sind.
( physical RDMs und VMFS-Luns)

Wir haben u.A. einen Exchange-Server virtualisiert.
Für kurze Zeit hatten wir unsere Exchange Datenbank auf einer einzelnen Festplatte
(2 TB,/ 7,2 K), die als VMFS-Lun ( NICHT als Raw Device) auf dem esxi und der Exchange-VM eingebunden war.

Das Backup der Exchange-DB per Windows Server Backup wird wie gehabt immer auf ein RAW Device auf einer anderen VM gelegt.


Nun zu der eigentlichen Frage:
Wir haben etwas umstrukturiert - ein Raid 5 mit 5 x 600 GB 15 K und 2 Luns angelegt. Die eine LUN wurde nun als RDM (physical) an den Exchange angebunden. Entgegen der Logig dauert das Backup der Exchange Datenbank nun 1/5 LÄNGER als vorher. Wie kann das sein? Von einem Raid 5 ( mit 15 K Platten) sollte doch eigentlich schneller gelesen werden können als von einer einzelnen 7.2 K Platte.


MfG Thiger

Es wird ein MD 3000i eingesetzt. Es ist redundant und mit Multipath -Konfiguration über 2 Switche an den esxi ( T620 ) angebunden. Es hat zwei Raid-Controller . IM SAN sind drei Raid 5 Sets konfiguriert, außerdem wird eine einzelne Platte als LUN genutzt.Was für Infos sind genau gewünscht ?

stoetzma hat geschrieben:

Nun zu der eigentlichen Frage:
Wir haben etwas umstrukturiert - ein Raid 5 mit 5 x 600 GB 15 K und 2 Luns angelegt. Die eine LUN wurde nun als RDM (physical) an den Exchange angebunden. Entgegen der Logig dauert das Backup der Exchange Datenbank nun 1/5 LÄNGER als vorher. Wie kann das sein? Von einem Raid 5 ( mit 15 K Platten) sollte doch eigentlich schneller gelesen werden können als von einer einzelnen 7.2 K Platte.


MfG Thiger

Hallo,

welcher Controller mit welcher Ausstattung und Konfiguration wird eingesetzt?

Gruss

Nur mal am Rande ne Frage: Warum als RDM?

War nicht gerade Exchange auf ein korrektes Alignment angewiesen? Wenn ich mich recht entsinne, mußte man bei einem Umzug auch genau dieses wieder treffen, wie es vorher war. Falls bei euch das Alignment vor dem Umzug, aus welchen Gründen auch immer, nicht gepaßt hatte, müßt ihr auch weiterhin mit diesem krummen Alignment weiterleben oder die Exchange-DB neu aufbauen. Dazu gab's meiner schwachen Erinnerung nach auch einen Artikel direkt bei M$.

Dayworker hat geschrieben:War nicht gerade Exchange auf ein korrektes Alignment angewiesen? Wenn ich mich recht entsinne, mußte man bei einem Umzug auch genau dieses wieder treffen, wie es vorher war. Falls bei euch das Alignment vor dem Umzug, aus welchen Gründen auch immer, nicht gepaßt hatte, müßt ihr auch weiterhin mit diesem krummen Alignment weiterleben oder die Exchange-DB neu aufbauen. Dazu gab's meiner schwachen Erinnerung nach auch einen Artikel direkt bei M$.

Was genau meinst du damit ? Die Datenbank wurde erfolgreich unter Anleitung der MS-HowTos verschoben...


Was mir aber aufgefallen ist: Nach dem Umzug der DB haben die LUN, auf der die DB liegt und die LUN, auf die das Backup geschrieben wird im MDStorageManager ( bzw auf dem SAN) das gleiche bevorzugte RaidController-Modul ( beide haben Modul-Einschub 1).
Vorher hatte die DB-LUN Einschub 0 favorisiert und die Backup-LUN Einschub 1.
Könnte der Performanceverlust damit zusammenhängen?

Hallo zusammen,

verstehe ich das richtig, das sowohl die Datenbank als auch das Backup Target auf dem RAID 5 aus 5 Platten liegen?
Falls dies zutrifft dürfte unter anderem das RAID Penalty für Writes der Grund dafür sein.
Zusätzlich dürfte sich der Umstand auswirken, das sequentielle Writes des Backups immer wieder unterbrochen werden müssen, um die Daten von der DB Lun einzulesen.

Somit wird aus einer sequentiellen Read IO Last (von der Exchange DB LUN) und der sequentiellen Write IO Last (Backup LUN) eine Random Read/Write Last für die RAID 5 Gruppe, auf der die beiden LUNs sich befinden.

Gruß,
Ralf

Hallo,

nein- die Datenbank liegt auf einer anderen Laufwerksgruppe (anderes Raid) als das Backup der Datenbank. Die beiden Raid haben lediglich das gleiche favorisierte Raidcontroller-Modul.

Sorry, wenn ich mich nicht klar ausgedrückt habe.

Hallo,

mit welchen Blocksizes arbeitet dein Backup denn beim Read und Write?
Ich vermute mal, das es mit relativ großen Blöcken lesen und mit verhältnismäßig kleinen Blöcken schreiben wird.

Aber das kannst du ja rentweder mit esxtop oder vscsiStats überprüfen.
Damit löst du zwar nicht das eigentliche Problem, bekommst jedoch ein besseres Gefühl für das Problem.

Gruß,
Ralf