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!)

Software Raid-5 auf drei echten HDDs erstellen

Hilfe bei Problemen mit der Installation und Benutzung des VMware Player.

Moderatoren: irix, stefan.becker, continuum, Dayworker, Tschoergez

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Software Raid-5 auf drei echten HDDs erstellen

Beitragvon Wirrkopf » 08.10.2012, 10:17

Ich habe eine VM erstellt mit Windows Server 2008. In dieser möchte ich ein Software Raid-5 erstellen das drei echte 1,5 TB HDDs auf dem Host PC umfassen soll.

Nun habe ich in den Player Einstellungen diese drei HDDs neu als "physische" Disks eingebunden. Die HDDs waren noch ohne Partitionen. Diese erschienen auch in der VM, ich hab das Raid-5 erstellt, die HDDs wurden in dynamische Datenträger umgewandet, und alles sah fein aus.

Dann habe ich aber auf dem Host auf dem Windows 7 läuft eine Software die CD/DVD Isos emulieren soll installiert. Und schwupp konnte die VM nicht mehr auf die Disk zugreifen. Ich vermute jedenfalls das es da einen Zusammenhang gab.

Jetzt habe ich es nochmal probiert. Es reicht wenn ich auf dem Host pC in der Festplattenverwaltung bin und die HDDs neu einlese. Dann kommt:

Bild

Auch nach Neustart der VM wurde das nicht besser, es kam beim starten ein Fehler das auf die HDDs nicht mehr zugegriffen werden kann. Da noch keine Daten drauf waren war das nicht so schlimm. ABER das soll in Zukunft nicht nochmal passieren. Erst nach löschen der Partitionen konnte ich die HDDs dann auch wieder als physische Datenträger in der VM einbinden.

Ist es also schlauer den physischen Zugriff zu lassen und das Raid-5 aus ganz normalen virtuellen Disk die aus Files bestehen die auf den Disk liegen zu erstellen? Also alle drei HDDs im Host als Basis Datenträger mit einer Partition anlegen und das File für die virtuelle HDDs maximal groß zu wählen? Wie sieht es aus wenn man dann "thin" HDDs erstellt die mitwachsen? Hätte den Vorteil das ich den Restplatz auf den drei HDDs ab und zu als temporären Speicher mißbrauchen könnte.

Wie verhalten sich die Varianten in Bezug auf Geschwindigkeit, Fehleranfälligkeit, Portierungsmöglichkeit? Was würdet Ihr mir empfehlen?

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 08.10.2012, 10:35

Verstehe ich das richtig ? - du willst unter VMplayer aus 3 phys. Platten innerhalb einer VM ein RAID5 erstellen mit dynamischen disks ?

Da gehen bei mir alle Alarmglocken an - unter Windows 7 physikalische Platten mit NTFS zu verwenden ist an sich schon riskant - dann daraus auch ein RAID zu machen halte ich fuer "Daten-selbstmord"


Bei einem Windows 7 Host MUSST du die phys. Platten vorher auf "offline" setzen damit es ueberhaupt geht - dann musst du VMplayer noch als admin starten ... und evtl sogar UAC abstellen.


Einen Software-raid aus 3 wachsenden VMDKS a 1.5 TB halte ich ebenfalls fuer "Daten-selbstmord"

Brauchst du vmdks groesser als 2 Tb ? - das geht - allerdings halte ich wachsende vmdks groesser als 950 Gb fuer nicht stabil genug - ich wuerde da keine wichtigen Daten drauf packen.

Was ist das eigentliche Ziel deiner Aktion ?

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 08.10.2012, 10:59

continuum hat geschrieben:Was ist das eigentliche Ziel deiner Aktion ?


Ich würde gerne die "nicht ganz so wichtigen" Daten (hauptsächliche Filme...) sichern. Und zwar auf einen anderer PC und nicht nur innerhalb meines ESXi Servers.

Auf meinem ESXi Server habe ich bisher noch ein per VMDirectPath eingebundenes SAN mit ZFS aus 6x2 TB HDDs laufen. Das wird per DFS vom WinSer2008 freigegeben. Davon sollen die "nicht ganz so wichtigen" Daten gesichert werden.

Da ich mir zu Hause nicht noch einen echten Server hinstellen will soll das Backup also ein Client machen auf dem nur ein virtueller Server läuft. Das Backup möchte ich aber nicht nur als "dummes" Backup gestalten sondern wenn möglich als weiteres DFS Ziel zu dem nachts gesynct wird. So das bei Ausfall des ersten DFS Ziels ganz automatisch das "Backup" zur Verfügung steht.

Da das DFS syncen mit dem ZFS SAN nicht unterstützt wird muss ich dazu wohl auch noch das ZFS wieder abschaffen und auch auf dem ESXi Server zu einem Software Raid unter Server 2008 umstellen.

Also zusammengefasst eigentlich nur der ganz normale Umbauwahnsinn wenn man sich langweilt. :)

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 08.10.2012, 11:05

Ach so .... langeweile ;-)

Also wenn sehr grosse vmdks dann erstell sie als ein-teilig-preallocated. Wachsende grosse vmdks sind nicht stabil.

Du kannst uebrigens ohne weiteres in VMplayer 12 Tb vmdks benutzen - die groesste vmdk die ich selber verwende ist 32 Tb

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 08.10.2012, 11:28

Also nochmal ganz von vorne:

Ich habe in meinem Client also 3 x 1,5 TB HDDs. Die möchte ich gerne als in einer Vm unter dem VMPlayer zur Verfügung haben. Aus Bequemlichkeit nicht getrennt sondern am Stück, aus Sicherheit gerne als Raid-5.

Sollte ich also auf jeder dieser HDDs eine preallocated vmdk erstellen? Diese kann ich dann in der VM unter Server 2008 ohne Probleme in einem Software Raid-5 zusammenfassen?

Ich habe in der VMDK Konfiguration des Players keine Möglichkeit gefunden das man ihm sagen kann er soll die VMDK maximal so groß machen wie das Ziel es hergiebt. Muss man das also manuell angleichen? Kann es also passieren das ich die VMDk größer einstelle als überhaupt platz ist? und was passiert dann....?

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 08.10.2012, 11:34

Sollte ich also auf jeder dieser HDDs eine preallocated vmdk erstellen? Diese kann ich dann in der VM unter Server 2008 ohne Probleme in einem Software Raid-5 zusammenfassen?


Ja.

Kann es also passieren das ich die VMDk größer einstelle als überhaupt platz ist?


Nur wenn du wachsende vmdks verwendest - und das solltest du bei so grossen vmdks auf keinen Fall tun. Erstell dir preallocated vmdks die ein paar GB kleiner sind als die Platten selbst

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 08.10.2012, 12:56

continuum hat geschrieben:
Erstell dir preallocated vmdks die ein paar GB kleiner sind als die Platten selbst


Kann es sein das es Stunden dauert eine preallocated 1,5 TB VMDk zu erstellen? Der Fortschrittsbalken bewegt sich so gut wie gar nicht! Da bin ich mit den drei VMDks mit Glück heute Abend fertig...

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 08.10.2012, 14:56

Unter Windows kann man grosse preallocated vmdks auch sehr schnell mit fsutil oder fsz.exe erstellen.

Sag an wie gross die vmdks genau sein sollen dann geb ich dir entsprechende Kommandos.

fsz.exe ist teil der dsfok-tools

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 08.10.2012, 16:09

Unterstützt W2k8 eigentlich überhaupt Raid5 für sein Bootlaufwerk?
Alles was ich bisher gefunden habe, beruht auf einem herkömmlichen Bootplatte und dann das Raid5 als Dyn.Datenträger für die Daten.

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 08.10.2012, 16:41

Dayworker hat geschrieben:Unterstützt W2k8 eigentlich überhaupt Raid5 für sein Bootlaufwerk?

Tut es meines Wissen nicht. Also jedenfalls nicht in Software.
Alles was ich bisher gefunden habe, beruht auf einem herkömmlichen Bootplatte und dann das Raid5 als Dyn.Datenträger für die Daten.

Mehr habe ich auch nicht vor. Die VM selber liegt auf einer anderen HDD.

Die erste VMDK ist immer noch nicht fertig ,-))) Wie erzeuge ich die mit mit den Tools? und sind die schon im Player enthalten oder muß ich die irgendwo runterladen?

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 08.10.2012, 16:44

dsfok-tools gibt es hier
http://sanbarrow.com/files/dsfok.zip

wie schon gesagt - sag an wie gross die vmdk sein soll ...

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 08.10.2012, 16:51

Die HDD sagt: Freier Speicher 1.500.159.516.672 Bytes 1,36 TB

Ich würde gerne so viel Nutzen wie ohne Risiko möglich ist.

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 08.10.2012, 17:32

sag einfach die Groesse in MB an

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 08.10.2012, 18:22

Ausgehend von seiner Byte-Angabe sollten sich 1,430,663 MByte bei einem Rest von ~600KByte ergeben.

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 08.10.2012, 19:17

Code: Alles auswählen

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 2831155200 FLAT "name-flat.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "9"
ddb.geometry.cylinders = "176231"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"


fsz name-flat.vmdk 1449551462400

Diese vmdk wird 1350 Gb gross


Code: Alles auswählen

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 2977955840 FLAT "name-flat.vmdk.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "9"
ddb.geometry.cylinders = "185369"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"


fsz name-flat.vmdk 1524713390080
diese vmdk wird 1450 Gb gross


Das fsz Kommando nimmt als Argument die vmdk-Groesse in bytes.

RW 2831155200 FLAT "name-flat.vmdk"

Obige Zeile verwendet die Groesse in sectors - also Groesse in bytes / 512

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 08.10.2012, 20:20

Ehrlich gesagt verstehe ich nicht wie ich damit konkret das VMDK erzeuge.

ich habe mal testweise auf der leeren hdd fsz name-flat.vmdk 1524713390080 aufgeführt. Dabei entstand eine File namens name-flat.vmdk mit einer größe von 0.

AH weil das ZU GROSS War!

Mit : fsz Raid-5-2.vmdk 1492501135360 hat es geklappt!!!!

Jetzt ist das erste über den VMPlayer erstellte vmdk fertig. Es ist 1390 GB groß und es sind noch 7 GB frei.

In dem vmdk Beschreibunsfile steht:

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 2915041280 FLAT "Raid-5-1-flat" 0

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "181452"
ddb.uuid = "60 00 C2 97 ad b8 1f 8b-9b 55 91 11 f7 3e 79 8c"
ddb.longContentID = "befc049314e5a3b686ee3a00fffffffe"
ddb.virtualHWVersion = "7"

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 08.10.2012, 20:34

Nur das der VMPlayer das vmdk file nicht akzeptiert...

Wenn ich das der VM zufügen will kommt: "the file specizied is not a virtual disk"

Nun habe ich das deskription file kopiert und angepasst und nun läßt sich die vmdk auch einbinden. Nur die UUID ist bei allen drei gleich was beim start stört. Nur weis ich nicht wie ich die abändern soll...

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 08.10.2012, 21:10

Änder doch einfach mal die vorletzte Stelle (79) ab und mach bei den anderen einfach eine 69 und 59 draus. Dann sollte es eigentlich wieder passen.

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 09.10.2012, 09:38

JA nun gehts! Aber die erstsyncroniserung scheint SEHR langsam zu sein.

Nach ca. 12 Stunden nur 9% (vielleicht ist es ach stehengeblieben?) ... Also wird es hochgerechnet 5 Tage dauern bis das durchsyncronisiert ist. War das schon immer so langsam?

Eigentlich wollte ich den Ausfall einer HDD mehrfach testen.... Aber bei diesen Zeiten würde das ja Wochen dauern!

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 09.10.2012, 21:39

Ein Rebuild dauert bei solchen Plattengrössen halt immer wesentlich länger. ;)
Das Raid in meiner Sig beispielsweise hat nicht umsonst nur 320GB Brutto trotz der inzwischen verbauten 500GB-Laufwerke. Die 320GB sind zwar auch historisch bedingt, da beim Kauf nur eine vereinsamte Platte dieser Grösse verbaut war und erst später auf Raid1 erweitert wurde. Je nach Intel-Treiber-Version hatte ich aber trotzdem schon Zeiten zwischen 1 und 3.5 Stunden für ein Rebuild oder eine simple Überprüfung erlebt.

Du schreibst leider nicht, ob deine Sig-HW auch die Player-HW darstellt bzw welche Player-Version überhaupt zum Einsatz kommt. Beispielsweise bekommt unser Ulli weder die WS8 noch die WS9 mit allen Tricks ans fliegen, ungeklärte sporadische Hänger sind ihm vertraut und da der Player nicht mehr oder noch nie eigenständig entwickelt wurde, haben die Player 4 und 5 höchstwahrscheinlich die selben Performanceprobleme...

Unabhängig von der HW kommt es auch drauf an, wieviel RAM und CPU du dieser VM gegönnt hast. Je nach Player/WS-Version ist es dabei leider unproduktiv, mehr als 1GB vRAM an eine VM zu geben, da ab einer versionsabhängigen vRAM-Grösse nur noch ein kleiner vRAM-Teil im pRAM gehalten und der Rest von VMware als auslagerungsfähig gemeldet wird. Meist bleiben dann nur noch 500MB vRAM im pRAM und der Rest wird auf Host-HDD ausgelagert. Eine SSD im Host müßte dann wahre Wunder bewirken.

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 10.10.2012, 09:54

Dayworker hat geschrieben:Ein Rebuild dauert bei solchen Plattengrössen halt immer wesentlich länger. ;).
DAs Rebuild hat dann doch weniger als 20h gedauert. Gestern um 12:47 habe ich die VM nochmal runtergefahren, die vCPU auf 2 und das vRAM auf 4 GB gesetzt. Heute Morgen um 8 Uhr war das Rebuild schon fertig. In der Systemprotokolierung finde ich leider den genauen Zeitpunkt an dem es fertig war nicht. WO versteckt sich das?
Du schreibst leider nicht, ob deine Sig-HW auch die Player-HW darstellt bzw welche Player-Version überhaupt zum Einsatz kommt. .
Ich verwende den neusten VMWare Player 5. Host ist ein AMD System mit 8 GB RAM und einer 2,5 GHz CPU mit 4 Kernen. Platten sind 3 x 1,5 GB Samsung mit 5400 rpm. Also energiesparend und nicht gerade fix. Das System in meiner Signatur ist mein ESXi5 Server. Der läuft ja "home-produktiv" und den kann ich für solche Sachen nicht einfach mal lahmlegen :)
Unabhängig von der HW kommt es auch drauf an, wieviel RAM und CPU du dieser VM gegönnt hast..

2 vCPU und 4 GB vRAm. Die Anzeige über den Fortschritt des Rebuild des Raid-5 in der Windows Datenträgerverwaltung scheint aber auch unzuverlässig zu sein. Vielleicht ist es mit einer vCPU und 2 GB vRam auch nicht langsamer.

Datenübertragung ist leider recht lahm laut ATTO Benchmark. Beim Rebuild waren es ca. 40 MB/s was ja für einen Rebuild noch ok war. Aber danach sind es auch nur 60 MB/s.
Naja für ein Backup wird es reichen. Wobei eine einzelne Platte gute 100 MB/s in der VM geschafft hat. Da hatte ich mir dann doch deutlich mehr vom Raid-5 versrochen. Und ich erinner mich Dunkel das das Nativ auch locker zu erreichen war.

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 10.10.2012, 21:04

W hat geschrieben:
D hat geschrieben:Ein Rebuild dauert bei solchen Plattengrössen halt immer wesentlich länger. ;).
DAs Rebuild hat dann doch weniger als 20h gedauert. Gestern um 12:47 habe ich die VM nochmal runtergefahren, die vCPU auf 2 und das vRAM auf 4 GB gesetzt. Heute Morgen um 8 Uhr war das Rebuild schon fertig. In der Systemprotokolierung finde ich leider den genauen Zeitpunkt an dem es fertig war nicht. WO versteckt sich das?
Also mein Intel-Fake-Raid meldet seinen Status immer in der Ereignisanzeige der Computerverwaltung unter dem Punkt Anwendung mit den IDs 7102 (Status for array 'Array_0000' changed from 'Rebuilding' to 'No active migrations') und 7202 (Status for volume 'Raid1_320GB' changed from 'Rebuilding' to 'Normal'.). Allerdings sind diese IDs Herstellerbezogen. M$ dürfte aber auch Warnungen mit ähnlichem Inhalt generieren.


W hat geschrieben:
D hat geschrieben:Du schreibst leider nicht, ob deine Sig-HW auch die Player-HW darstellt bzw welche Player-Version überhaupt zum Einsatz kommt. .
Ich verwende den neusten VMWare Player 5. Host ist ein AMD System mit 8 GB RAM und einer 2,5 GHz CPU mit 4 Kernen. Platten sind 3 x 1,5 GB Samsung mit 5400 rpm. Also energiesparend und nicht gerade fix. Das System in meiner Signatur ist mein ESXi5 Server. Der läuft ja "home-produktiv" und den kann ich für solche Sachen nicht einfach mal lahmlegen :)
Da beim Raid5 ja die Parität berechnet werden muß, kommt es neben der CPU immer auch auf die Lese-/Schreibleistung an. Schließlich müssen alle Daten eingelesen und in einem gewissen Stripeset plus Parität auf alle Raidteilnehmer verteilt werden. Von daher sind Platten mit gemächlichen 5400rpm eher weniger dafür geschaffen, aber wenigstens sind die sparsam.
Was heißt bei dir "AMD CPU mit 2.5GHz mit 4 Kernen"? Sind das 4 reale Kerne oder eher diese Modul-Packung ala BD, PD oder Trinity mit extrem lahmer Singlethread-Performance?
Falls letzteres der Fall sein sollte, würde das in meinen Augen deine lange Rebuildzeit erklären können. Alle AMD-CPUs mit Modulkonzept kommen nur dann in die Gänge, wenn auch alle Module am selben Problem arbeiten können. Performancetechnisch kommt dabei einer bei zwei Integerkernen pro Modul wohl nicht viel über die Singlethreadperformance eines Intel Atom D2800 hinaus und wenn der Umwandlungsprozess nur auf einem CPU-Kern ausgeführt wird, dauert's einfach länger. Die Paritätsberechnung wird als XOR-Vergleich entweder im Stripeset oder Plattenzylinder1Disk1 gegen Plattenzylinder1Disk2 vorgenommen und das Ergebnis dann in Plattenzylinder1Disk3 geschrieben. Keine Ahnung ob AMD dafür eine entsprechende Einheit verbaut hat.


W hat geschrieben:
D hat geschrieben:Unabhängig von der HW kommt es auch drauf an, wieviel RAM und CPU du dieser VM gegönnt hast..
2 vCPU und 4 GB vRAm. Die Anzeige über den Fortschritt des Rebuild des Raid-5 in der Windows Datenträgerverwaltung scheint aber auch unzuverlässig zu sein. Vielleicht ist es mit einer vCPU und 2 GB vRam auch nicht langsamer.
Wie bereits geschrieben, lagern WS/Player ab einer gewissen vRAM-Grösse immer in den virt.Arbeitspeicher ergo die Host-Auslagerungsdatei aus. Das und mit der schlecht vorhersagbaren Virtualisierungsperformance aufgrund einer mit schwacher Singlethreadperformance gestraften CPU im Moduldesign sorgt nicht unbedingt für eine gute Schwuppdizität. Ich würds trotzdem mal mit nur 2GB vRAM und 1 vCPU probieren, grosse Wunder würde ich auch wegen der energiesparenden Platten trotzdem nicht erwarten.


W hat geschrieben:Datenübertragung ist leider recht lahm laut ATTO Benchmark. Beim Rebuild waren es ca. 40 MB/s was ja für einen Rebuild noch ok war. Aber danach sind es auch nur 60 MB/s.
Naja für ein Backup wird es reichen. Wobei eine einzelne Platte gute 100 MB/s in der VM geschafft hat. Da hatte ich mir dann doch deutlich mehr vom Raid-5 versrochen. Und ich erinner mich Dunkel das das Nativ auch locker zu erreichen war.
Die 40-60MB/s sprechen zum einen wirklich für eine der bereits vielfach dafür gescholtenen AMD-CPUs im Moduldesign und zum anderen für energetisch sparsame Datenträger. Selbst ein älterer Intel Atom Dualcore schafft um die 100MB/s beim Lesen und Schreiben. Wenn man dazu aber den allgemeinen Plattenaufbau mit den verschieden schnellen Medienzonen mit um 100MB/s in der Aussenzone und üblicherweise gut 50% Leistungseinbuße im Innenbereich bedenkt, sind 60MB/s auch nicht mal so schlecht. Dazu kommt, daß SATA-Platten mit 7200rpm auch nur zwischen 75-100 IOPS leisten können. Deine 5400er dürften also irgendwo zwischen 50-75 IOPS liegen.

Versuch doch mal ein kleineres Raid5 mit nur 250 bis 500GB pro Platte zu stricken. Damit solltest du auf jeder Platte immer in der schnellsten Medienzone liegen und der Druchsatz sollte sich dadurch wesentlich erhöhen. Allerdings ist ein Raid5 beim Schreiben immer langsamer, da die Daten wie bereits mehrfach erwähnt im Stripeset auf die Teilnehmer verteilt werden. Bei einem Raid5 mit 3 Teilnehmern ist daher mehr als ein Drittel der Schreibperformance einer Einzelplatte nicht zu erwarten. Alles darüber dürfte der Platten- bzw Dateisystemcache produzieren.

Member
Beiträge: 381
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 22.10.2012, 09:50

Es handelt bei der CPU um einen 4 Core Phenom 9850 mit 2,5 Ghz. Der ist sicherlich kein Intel i5 oder i7 aber völlig ausreichend um eine (oder mehrere) SATA HDD nicht auszubremsen. Die CPU Auslastung beim resync ist jedenfalls im einstelligen Prozentbereich.

Ich habe mir nun die Mühe gemacht auf der selben Hardware ein Windows Server 2008 R2 nativ zu installieren.

Die Werte des Software Raid-5 dabei sind ca. 84 MB/s write und 216 MB/s read. Und schon während des resyncs sind die Werte fast so hoch bei den größeren Dateigrößen, nur bei den kleineren ist es halb so schnell. Ich denke das ist das Maximum was die 5400rpms HDDs leisten können. Hab ich mich also doch richtig erinnert das es schneller gehen muss.

Beim kopieren von großen Dateien (357 GB Filme) übers Netz und schreiben auf das Raid-5 schaft er 68 MB/s im Durchschnitt bei einer durchschnittlichen CPU Auslastung von 40 %. Wobei ich nicht weis ob die Quelle da bremst.

Das heißt die Performance im VMWare Player ist deutlich zu niedrig. Die Aussage von VMWAre das ein VMDK inzwischen nicht viel langsamer ist als eine native Platte scheint für den Player nicht zu gelten oder es steckt irgendwo noch ein Fehler drin.

Wenn ich viel Muße habe würde ich das ganze mit der selben Hardware nochmal mit dem ESXi 5 probieren und mit dem Player/ESXi mit RDM statt VMDKs... Aber das wird wohl ein wenig dauern.

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 22.10.2012, 10:21

Die Aussage von VMWAre das ein VMDK inzwischen nicht viel langsamer ist als eine native Platte scheint für den Player nicht zu gelten oder es steckt irgendwo noch ein Fehler drin.


Ich wuesste nicht dass VMware dass je behauptet haette - wenn dann hoechstens fuer ESXi


Zurück zu „VMware Player“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast