Hallo,
ich komme leider nicht weiter.
Folgende Konfiguration für ein Homelab:
Intel Xeon E3-1240V3, 4x 3.40GHz,
Supermicro X10SL7-F
32 GB ECC DDR3-1600
"Storage VM": Windows Server 2012 R2:
- per PCI Passthrough wird eine Festplatte direkt an diese VM weitergeben.
- Windows NFS Freigabe (z.B. für ghettovcb): Rückrepräsentierung an ESXI
Mit IOMeter lokal auf der Win2012 VM bekomme ich eine ca. Read/Write Performance von ca. 90 Megabytes auf die RAW HDD
Per NFS an ESXI erhalte ich beim gemounteten NFS Datastore:
- Read: 85-90 Megabytes
- Write: 3-12 Megabytes
Woran kann das liegen, dass NFS Write so langsam ist?
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
NFS Write sehr langsam / NFS Read schnell
-
MarcelMertens
- Member
- Beiträge: 360
- Registriert: 13.07.2011, 15:33
Festplatte: WD-RE4 ohne RAID
Danke für die Antwort. D.h. der ESXI wartet immer bis ein Block auf Festplatte komplett geschrieben ist, richtig?
Das dann andere Protokolle fast 10x so schnell bei der Schreibgeschwindigkeit sind, liegt also alleine am Sync Befehl?
Mich wundert es halt, dass es Unterschied so groß ist.
irix hat geschrieben:Der ESXi verwendet die Option "sync" beim Mounten des NFS.
Danke für die Antwort. D.h. der ESXI wartet immer bis ein Block auf Festplatte komplett geschrieben ist, richtig?
Das dann andere Protokolle fast 10x so schnell bei der Schreibgeschwindigkeit sind, liegt also alleine am Sync Befehl?
Mich wundert es halt, dass es Unterschied so groß ist.
Eine normale Festplatte? Das läuft grottenlahm... Die 100MB innerhalb der Windows-VM landet mit grosser Wahrscheinlichkeit irgendwo in nem Cache. Über NFS vielleicht nicht und dann ists lahmer als lahm. 
Innerhalb einer windows VM hast dann noch reine sequentielle Übertragung, das ist nochmals schneller. Sobalds über VmWare geht Block-Transfer Random 4KB. Meine ich zumindest. Bei ner schnellen SATA Disc mit ca. 150 IOPS macht das 600KB pro Sekunde. Das heisst du hast also Glück mit Deinen 3 MB.
EDIT: NFS ist nicht wirklich Block!
Habe hier mit SSD's jedenfalls keine Probleme mit der Performance...
Innerhalb einer windows VM hast dann noch reine sequentielle Übertragung, das ist nochmals schneller. Sobalds über VmWare geht Block-Transfer Random 4KB. Meine ich zumindest. Bei ner schnellen SATA Disc mit ca. 150 IOPS macht das 600KB pro Sekunde. Das heisst du hast also Glück mit Deinen 3 MB.
EDIT: NFS ist nicht wirklich Block!
Habe hier mit SSD's jedenfalls keine Probleme mit der Performance...
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
wie schnell ist denn das NFS, wenn du von einem anderem Windows Server darauf zugreifst?
Vielleicht helfen dir ja folgende Artikel weiter.
Fixing slow NFS performance between VMware and Windows 2008 R2
Configuring Flow Control on VMware ESXi and VMware ESX
Viel Erfolg,
Ralf
wie schnell ist denn das NFS, wenn du von einem anderem Windows Server darauf zugreifst?
Vielleicht helfen dir ja folgende Artikel weiter.
Fixing slow NFS performance between VMware and Windows 2008 R2
Configuring Flow Control on VMware ESXi and VMware ESX
Viel Erfolg,
Ralf
Der erste Tipp ist gut. Glatt vergessen zu erwähnen, dass man alles freigeben soll ohne mapping zu AD. Vermutlich hat er das aber eh schon. Das andere ist nämlich viel umständlicher einzustellen
--> Habe das selber über die user und group in etc. gemacht. Der genannte Befehl im unteren Bereich ist grundsätzlich nur notwendig, wen mans am Anfang mal verkackt hat. Werde ich aber auch mal näher nachforschen und austesten.
--> Habe das selber über die user und group in etc. gemacht. Der genannte Befehl im unteren Bereich ist grundsätzlich nur notwendig, wen mans am Anfang mal verkackt hat. Werde ich aber auch mal näher nachforschen und austesten.
erstmal danke für eure Antworten
Mich verwundert halt einfach der große Unterschied... 90 Megabytes SMB vs 3 Megabytes NFS (auch wenn es eine andere Art ist).
ich weis nicht wie gehttovcb genau funktioniert aber grundsätzlich sollte das doch nur ein Snapshot anlegen und dann die Dateien einfach auf die NFS Freigabe kopieren. Das das so viel langsamer ist finde ich irgendwie komisch...
Das habe ich schonmal durchgelesen jedoch habe ich kein AD und kein Usermapping.
Den Befehl habe ich auch schonmal ausprobiert, brachte aber keine Änderung.
werde ich gleich mal testen
Vllt. hilft das irgendwo weiter (lokaler Benchmark in Windows VM mit Festplatte auf die geschrieben werden soll ):
UrsDerBär hat geschrieben:Innerhalb einer windows VM hast dann noch reine sequentielle Übertragung, das ist nochmals schneller. Sobalds über VmWare geht Block-Transfer Random 4KB. Meine ich zumindest. Bei ner schnellen SATA Disc mit ca. 150 IOPS macht das 600KB pro Sekunde. Das heisst du hast also Glück mit Deinen 3 MB.
Habe hier mit SSD's jedenfalls keine Probleme mit der Performance...
Mich verwundert halt einfach der große Unterschied... 90 Megabytes SMB vs 3 Megabytes NFS (auch wenn es eine andere Art ist).
ich weis nicht wie gehttovcb genau funktioniert aber grundsätzlich sollte das doch nur ein Snapshot anlegen und dann die Dateien einfach auf die NFS Freigabe kopieren. Das das so viel langsamer ist finde ich irgendwie komisch...
http://blog.malayter.com/2012/05/fixing-slow-nfs-performance-between.html
Das habe ich schonmal durchgelesen jedoch habe ich kein AD und kein Usermapping.
Den Befehl habe ich auch schonmal ausprobiert, brachte aber keine Änderung.
wie schnell ist denn das NFS, wenn du von einem anderem Windows Server darauf zugreifst?
werde ich gleich mal testen
Vllt. hilft das irgendwo weiter (lokaler Benchmark in Windows VM mit Festplatte auf die geschrieben werden soll ):
Doch doch, die Unterschiede sind extrem. Wenn der Festplatten-Cache noch deaktiviert ist, dann ist die Übertragungsrate eben wirklich gegen 0 und entspricht in etwa der Realität was eine solche Platte grundsätzlich leistet.
Wäre die sequentielle Traum-Rate heutiger HDD wirklich in Random vorhanden, bräuchte man sehr viel seltener grosse Festplattenverbünde oder SSD's.
Test mal das ganze mit einem Festplattenprüfer wie CrystalDiskMark auf Sequentiell und Random (4KB), mit mindesten 1-2GB an Daten oder mehr.
Es gibt wenig sinnvolles wenn die Kohle für ein richtiges SAN bzw. ein richtiges + mindestens was für Backup nicht vorhanden ist. Eigentlich nur nen System mit nem gscheiten RAID-Controller, Batterie und Cache oder aber SSD's. Die SSD's entweder als Cache oder gleich als Storage.
Linux dürfte unter NFS noch etwas performanter sein als Windows.
Wäre die sequentielle Traum-Rate heutiger HDD wirklich in Random vorhanden, bräuchte man sehr viel seltener grosse Festplattenverbünde oder SSD's.
Test mal das ganze mit einem Festplattenprüfer wie CrystalDiskMark auf Sequentiell und Random (4KB), mit mindesten 1-2GB an Daten oder mehr.
Es gibt wenig sinnvolles wenn die Kohle für ein richtiges SAN bzw. ein richtiges + mindestens was für Backup nicht vorhanden ist. Eigentlich nur nen System mit nem gscheiten RAID-Controller, Batterie und Cache oder aber SSD's. Die SSD's entweder als Cache oder gleich als Storage.
Linux dürfte unter NFS noch etwas performanter sein als Windows.
UrsDerBär hat geschrieben:Doch doch, die Unterschiede sind extrem. Wenn der Festplatten-Cache noch deaktiviert ist, dann ist die Übertragungsrate eben wirklich gegen 0 und entspricht in etwa der Realität was eine solche Platte grundsätzlich leistet.
Wäre die sequentielle Traum-Rate heutiger HDD wirklich in Random vorhanden, bräuchte man sehr viel seltener grosse Festplattenverbünde oder SSD's.
dass das so extrem bei random ist, hätte ich echt nicht gedacht aber anscheinend ist es einfach so...
Random hänt eng mit den IOPS zusammen - sehe ich das richtig?
Test mal das ganze mit einem Festplattenprüfer wie CrystalDiskMark auf Sequentiell und Random (4KB), mit mindesten 1-2GB an Daten oder mehr.
UrsDerBär hat geschrieben:Es gibt wenig sinnvolles wenn die Kohle für ein richtiges SAN bzw. ein richtiges + mindestens was für Backup nicht vorhanden ist. Eigentlich nur nen System mit nem gscheiten RAID-Controller, Batterie und Cache oder aber SSD's. Die SSD's entweder als Cache oder gleich als Storage.
Heist das im Umkehrschluss, dass eigentlich nur SSDs sinn machen, wenn man nicht gleich 4 SAS Platten im Raid10 laufen lassen möchte?
Da ich die Tests schon gemacht habe (auch wenn es ein anderes Programm ist)
anderer Windowsserver bindet NFS ein. NFS-Freigabe liegt auf Sata Festplatte 7200:
anderer Windowsserver bindet NFS ein. NFS-Freigabe liegt auf SSD Festplatte:
SSD lokal ohne NFS
Was auffällt ist, dass die SSD einiges schneller ist, wenn sie lokal ist, als wenn sie über NFS eingebunden ist. Ist das normal, das über NFS so viel verloren geht?
Random-IO: Ja das ist absolut zum heulen im Vergleich. Das ist auch der Grund warum Private meist nicht verstehen, warum nicht 1-2 Discs ausreichen oder SATA doch auch doll ist usw. Und bei vielen Dienstleistern wird auch so angeboten, obwohl die Performance dann unterirdisch ist. Hauptsache CPU und RAM passt. Aber I/OS sind bei den grossen Server-Herstellern eben auch ziemlich teuer.
RAID 10: Jop, bei Magnetplatten aber bitte mit richtigem Hardware RAID. Mit 4 reisst Du auch nicht besonders viel, aber sicher besser als zwei. Hast Du nicht immer richtig viel los, reichen die Caches moderner Controller für die Writes aber so auch oft gut aus.
Für virtualisierte Desktop-Umgebungen würde ich jedoch schauen, dass richtig viel IO's bei niedriger Latenz zu Verfügung stehen. Sonst ist es einfach nur mühsam. Serveranwendungen haben oft viel mit RAM-Cache für Read's am Hut, darum ist da das Problem weniger akut und der PC selber reagiert schnell. Das ist wichtig bei Desktops fürs User-Feeling. Bei vielen virtuellen Desktop kriegst Du aber innerhalb Kürze alles in die Knie wenn man denkt, man kann da einfach ein paar Magnetplatten hinstellen und gut ist. Würde man soviele wie Anz. Desktops + 20% nehmen (+ bzw. Das doppelte Wegen RAID), würde das gut hinkommen. Aber man virtualisiert ja um Hardware zu sparen.
Bei guten SSD's kommt man dank wenig Latenz + sehr vielen IOPS aber auch mit ein paar wenigen oder sogar nur einem Paar auf ein sehr gutes Benutzer-Feeling-Ergebnis. Noch besser natürlich, wenn die Desktops im RAM laufen. --> Teure Lizenz.
ATTO ist nicht unbedingt bekannt für korrekte Werte. Zumindest früher. Würde Crystal Disk Mark nehmen.
So ganz klar ist mir ausserdem nicht ob das 256MB total oder pro Stück ist. Bei Total landet in Windows einiges davon im Cache.
RAID 10: Jop, bei Magnetplatten aber bitte mit richtigem Hardware RAID. Mit 4 reisst Du auch nicht besonders viel, aber sicher besser als zwei. Hast Du nicht immer richtig viel los, reichen die Caches moderner Controller für die Writes aber so auch oft gut aus.
Für virtualisierte Desktop-Umgebungen würde ich jedoch schauen, dass richtig viel IO's bei niedriger Latenz zu Verfügung stehen. Sonst ist es einfach nur mühsam. Serveranwendungen haben oft viel mit RAM-Cache für Read's am Hut, darum ist da das Problem weniger akut und der PC selber reagiert schnell. Das ist wichtig bei Desktops fürs User-Feeling. Bei vielen virtuellen Desktop kriegst Du aber innerhalb Kürze alles in die Knie wenn man denkt, man kann da einfach ein paar Magnetplatten hinstellen und gut ist. Würde man soviele wie Anz. Desktops + 20% nehmen (+ bzw. Das doppelte Wegen RAID), würde das gut hinkommen. Aber man virtualisiert ja um Hardware zu sparen.
Bei guten SSD's kommt man dank wenig Latenz + sehr vielen IOPS aber auch mit ein paar wenigen oder sogar nur einem Paar auf ein sehr gutes Benutzer-Feeling-Ergebnis. Noch besser natürlich, wenn die Desktops im RAM laufen. --> Teure Lizenz.
ATTO ist nicht unbedingt bekannt für korrekte Werte. Zumindest früher. Würde Crystal Disk Mark nehmen.
So ganz klar ist mir ausserdem nicht ob das 256MB total oder pro Stück ist. Bei Total landet in Windows einiges davon im Cache.
danke UrsDerBär - endlich habe ich mal einen Eindruck ... und nicht nur... das ist gut... das ist schlecht....
den Test mit Crystal Disk Mark werde ich dann nochmal machen
Darf ich mal fragen wie du das löst für VDI?
lokale SSDs in den ESXI? oder habt ihr ein SSD Storage?
den Test mit Crystal Disk Mark werde ich dann nochmal machen
UrsDerBär hat geschrieben:Für virtualisierte Desktop-Umgebungen würde ich jedoch schauen, dass richtig viel IO's bei niedriger Latenz zu Verfügung stehen. Sonst ist es einfach nur mühsam.
Darf ich mal fragen wie du das löst für VDI?
lokale SSDs in den ESXI? oder habt ihr ein SSD Storage?
Hab mal Übertragungsraten hier angeschaut: VM's verschiebe ich per Migration mit ca. 93MB/s (nicht Mbit) von meiner SAN auf meine Windows Server Storage Appliance welcher mit zwei per Storage Spaces gespiegelten SSD's den NFS Storage für den ESXi bereitstellt.
Wenn ich ne Datensicherung auf die SSD's rückspiele, dann nutze ich Windows Fileservices zur Übertragung der VM's. Da verschiebe ich von einem SATA-RAID 10, mit 4 Discs auf der gleichen Maschine mit stabilen, 380-400MB/s vom RAID 10 auf die SSD's.
Eine Übertragung auf dem gleichen physischen Host per Migration in zwei unterschiedlichen NFS-Stores läuft mit rund 125MB/s. In der Maschine habe ich mit Vmxnet3 Up und Down jeweils 1Gbit. Was hier genau limitiert, kann ich nicht sagen. Auch nicht ob eine bessere Performance geben würde, wenn ich zwei separate vmkernel ports oder Netzwerkkarten nehmen würde.
Mit dem lahmen Datastorebrowser immerhin mit noch ca. 45MB.
Zwischen zwei physischen Maschinen muss aber schon 10Gibt herrschen um schneller als 93MB zu übertragen. Oder Netzwerktechnisch etwas gemacht werden.
Interessant wäre an dieser Stelle bestimmt der Test ob die neuen Tier und Cache Features von Server 2012R2 auch in ner virtuellen Storage Appliance fruchten oder ob die Latenz an den Arsch geht und somit NFS nix mehr taugt. So könnte man Magnetplatten mit SSD's kombinieren.
--> Grundsätzlich müsste man ehrlicherweise sagen, dass das ganze unter HyperV für das Backup deutlichst besser und mit grosser Sicherheit auch performanter zu realisieren wäre, weil der Sync von NFS wegfällt und HyperverV direkt auf Host-Basis seine VM's sichern kann. Ein Job wäre also sichern auf Lokale Platten mit nem Agenten bzw. Snapshot und anschliessend wiederum mit Windowsbackup wegkopieren auf nen iSCSI Storage oder Netzwerkshare.
Wenn ich ne Datensicherung auf die SSD's rückspiele, dann nutze ich Windows Fileservices zur Übertragung der VM's. Da verschiebe ich von einem SATA-RAID 10, mit 4 Discs auf der gleichen Maschine mit stabilen, 380-400MB/s vom RAID 10 auf die SSD's.
Eine Übertragung auf dem gleichen physischen Host per Migration in zwei unterschiedlichen NFS-Stores läuft mit rund 125MB/s. In der Maschine habe ich mit Vmxnet3 Up und Down jeweils 1Gbit. Was hier genau limitiert, kann ich nicht sagen. Auch nicht ob eine bessere Performance geben würde, wenn ich zwei separate vmkernel ports oder Netzwerkkarten nehmen würde.
Mit dem lahmen Datastorebrowser immerhin mit noch ca. 45MB.
Zwischen zwei physischen Maschinen muss aber schon 10Gibt herrschen um schneller als 93MB zu übertragen. Oder Netzwerktechnisch etwas gemacht werden.
Interessant wäre an dieser Stelle bestimmt der Test ob die neuen Tier und Cache Features von Server 2012R2 auch in ner virtuellen Storage Appliance fruchten oder ob die Latenz an den Arsch geht und somit NFS nix mehr taugt. So könnte man Magnetplatten mit SSD's kombinieren.
--> Grundsätzlich müsste man ehrlicherweise sagen, dass das ganze unter HyperV für das Backup deutlichst besser und mit grosser Sicherheit auch performanter zu realisieren wäre, weil der Sync von NFS wegfällt und HyperverV direkt auf Host-Basis seine VM's sichern kann. Ein Job wäre also sichern auf Lokale Platten mit nem Agenten bzw. Snapshot und anschliessend wiederum mit Windowsbackup wegkopieren auf nen iSCSI Storage oder Netzwerkshare.
sehr intressant...
hast du zufällig noch ein Benchmark von SSD Raid10 Storage oder sind das Magnetplatten?
Was für SSDs setzt du denn ein, wenn ich fragen darf?
ich habe noch ein Benchmark (VM auf SSD Datastore direkt (d.h. direkt im ESXI ohne NFS etc) SSD: Samsung SM843T 240GB) mit CrystalDiskMark durchgeführt:
http://image-upload.de/image/h4R4O8/52d040fbe1.png
hast du zufällig noch ein Benchmark von SSD Raid10 Storage oder sind das Magnetplatten?
Was für SSDs setzt du denn ein, wenn ich fragen darf?
ich habe noch ein Benchmark (VM auf SSD Datastore direkt (d.h. direkt im ESXI ohne NFS etc) SSD: Samsung SM843T 240GB) mit CrystalDiskMark durchgeführt:
http://image-upload.de/image/h4R4O8/52d040fbe1.png
SSD's: Aktuell Intel DC-S3700
Sobald die Anzahl der VM's die man gemeinsam migriert steigt, steigt auch die Übertragungsleistung an. Sprich bei gemeinsamen Operationen unter NFS scheint der Sync jeweils nur pro VM oder sogar Disk abgewartet zu werden, nicht pro Datastore. Da kommen dann schnelle SSD's auch richtig zur Geltung, auch wenn in einer einzelnen VM theoretisch Performance verbraten wird.
Das ganze hängt wohl einfach mit der Latenz zusammen. Selbst mit RAM-Disks innerhalb der Storage-VM kommt man leider nicht unbedingt weiter. Daher würde ich auch so gerne mal ne Micron P320 verbauen, da dürfte nochmals einiges mehr gehen. Aber das Ding ist leider etwas kostspielig und hat trotz des Preises keine Kondis welche ausstehende Writes nach einem Stromausfall noch schreiben.
Bei Übertragungsraten über 1.3 Gbit wird es dann aber mit der CPU-Power (bei einem Core) eng. Schuld daran ist wohl die virtualisierte Netzwerkkarte.
RAID-10 mit SSD's: Das ist etwas verzwickt. Die Write-Werte steigen pro Übertragungs-Prozess nicht wirklich an, bei falscher Konfig werden sie pro Prozess sogar schlechter. Hier sollte zum Beispiel bei der Formatierung des Datenträgers die Sektorengrösse berücksichtigt werden. Hat man also ein RAID10 mit 4 SSD's, dann sollte dies 8092KB sein, nicht 4096. Das ergibt pro Column dann 4096KB, was wiederum der Physical Sector Size sowie optimalerweise auch der Logical Sector Size moderner SSD's entspricht.
--> Unter Server 2012 war die Logical Size eines Datastores standardmässig noch bei 512, bei 2012R2 4096. Diese lässt sich (noch) nicht pro Disc einstellen, auch wenn die Einstellung DefaultLogicalSectorSize dies vermuten lässt.
Trotzdem sind die Werte bei RAID 10 auch bei excellenten SSD's immer minimal schlechter pro Prozess (wegen der genannten Latenz). Bei 0815 SSD's sogar katastrophal schlechter, weil diese nicht über zuverlässig tiefe und gleiche Latenzen verfügen. Somit steigt die Wahrscheinlichkeit, dass eine eben nicht die gewünschte Latenz bringt und somit die Performance zusammenbricht. Das ist auch bei einem normalen Mirror der Fall. Billige SSD's funktionieren nur als single-Disc gut, nie im RAID.
Hat man aber mehrere Übertragungsprozesse am laufen, dann kommen die Vorteile der SSD im RAID 10 zum tragen.
Momentan suche ich immer noch nach einer Möglichkeit, Windows vorzugaukeln, dass es JBOD-Discs vom HBA bekommt, damit ich mit nem SingleNode-Cluster vom RAM-Cache profitieren könnte. Das dürfte dem READ nochmals nen ordentlichen Schub geben. Ohne kann man leider keinen Cluster-Storage-Space erstellen und nur dieser hat Ram-Read-Cache bis zu 80% des RAM's.
--> Windows cached physische Blöcke, also mit Dedupe weniger RAM-Bedarf
Das es sehr gut performt habe ich bereit mit Virtuellen Discs ausprobiert und dem gemeinsam verwendeten SCSI-Adapter ausprobiert (ControllerTyp: Physisch).
Sobald die Anzahl der VM's die man gemeinsam migriert steigt, steigt auch die Übertragungsleistung an. Sprich bei gemeinsamen Operationen unter NFS scheint der Sync jeweils nur pro VM oder sogar Disk abgewartet zu werden, nicht pro Datastore. Da kommen dann schnelle SSD's auch richtig zur Geltung, auch wenn in einer einzelnen VM theoretisch Performance verbraten wird.
Das ganze hängt wohl einfach mit der Latenz zusammen. Selbst mit RAM-Disks innerhalb der Storage-VM kommt man leider nicht unbedingt weiter. Daher würde ich auch so gerne mal ne Micron P320 verbauen, da dürfte nochmals einiges mehr gehen. Aber das Ding ist leider etwas kostspielig und hat trotz des Preises keine Kondis welche ausstehende Writes nach einem Stromausfall noch schreiben.
Bei Übertragungsraten über 1.3 Gbit wird es dann aber mit der CPU-Power (bei einem Core) eng. Schuld daran ist wohl die virtualisierte Netzwerkkarte.
RAID-10 mit SSD's: Das ist etwas verzwickt. Die Write-Werte steigen pro Übertragungs-Prozess nicht wirklich an, bei falscher Konfig werden sie pro Prozess sogar schlechter. Hier sollte zum Beispiel bei der Formatierung des Datenträgers die Sektorengrösse berücksichtigt werden. Hat man also ein RAID10 mit 4 SSD's, dann sollte dies 8092KB sein, nicht 4096. Das ergibt pro Column dann 4096KB, was wiederum der Physical Sector Size sowie optimalerweise auch der Logical Sector Size moderner SSD's entspricht.
--> Unter Server 2012 war die Logical Size eines Datastores standardmässig noch bei 512, bei 2012R2 4096. Diese lässt sich (noch) nicht pro Disc einstellen, auch wenn die Einstellung DefaultLogicalSectorSize dies vermuten lässt.
Trotzdem sind die Werte bei RAID 10 auch bei excellenten SSD's immer minimal schlechter pro Prozess (wegen der genannten Latenz). Bei 0815 SSD's sogar katastrophal schlechter, weil diese nicht über zuverlässig tiefe und gleiche Latenzen verfügen. Somit steigt die Wahrscheinlichkeit, dass eine eben nicht die gewünschte Latenz bringt und somit die Performance zusammenbricht. Das ist auch bei einem normalen Mirror der Fall. Billige SSD's funktionieren nur als single-Disc gut, nie im RAID.
Hat man aber mehrere Übertragungsprozesse am laufen, dann kommen die Vorteile der SSD im RAID 10 zum tragen.
Momentan suche ich immer noch nach einer Möglichkeit, Windows vorzugaukeln, dass es JBOD-Discs vom HBA bekommt, damit ich mit nem SingleNode-Cluster vom RAM-Cache profitieren könnte. Das dürfte dem READ nochmals nen ordentlichen Schub geben. Ohne kann man leider keinen Cluster-Storage-Space erstellen und nur dieser hat Ram-Read-Cache bis zu 80% des RAM's.
--> Windows cached physische Blöcke, also mit Dedupe weniger RAM-Bedarf
Das es sehr gut performt habe ich bereit mit Virtuellen Discs ausprobiert und dem gemeinsam verwendeten SCSI-Adapter ausprobiert (ControllerTyp: Physisch).
Habe nochmals ein paar Tests gefahren. Auch mit mehr CPU-Leistung. Wie ist das schön wenn man mal mit dem produktiven System spielen kann. 
Skalierung mit doppelter Kernanzahl ist ziemlich das doppelte in der Übertragungsleistung. Sprich mit zwei vCPU's mit rund 350MB/s auf die SSD's bei einer Migration von NFS auf NFS (beides auf dem gleichen Host aber unterschiedliche Stores und Discs. Lesen von der SAN bekomme ich leider nur ca. 110 zusammen.) Muss auch über die gleiche VM, also je 2.8Gbit Up und Down.
Read von SSD und Write auf zweites Volume auf gleichen SSD's bei der Migration immerhin noch je 1.8Gbit also über 200MB/s, nicht übel wie ich finde für gleichzeitig Read und Write. Übertragung von ca. 100GB bzw. 4 VM's gleichzeitig.
Ob mans braucht? Ich bis dato noch nicht. Mir reicht ein Kern.
Noch schöner wäre türlich die Auslagerung an eine Hardwarekarte.
Skalierung mit doppelter Kernanzahl ist ziemlich das doppelte in der Übertragungsleistung. Sprich mit zwei vCPU's mit rund 350MB/s auf die SSD's bei einer Migration von NFS auf NFS (beides auf dem gleichen Host aber unterschiedliche Stores und Discs. Lesen von der SAN bekomme ich leider nur ca. 110 zusammen.) Muss auch über die gleiche VM, also je 2.8Gbit Up und Down.
Read von SSD und Write auf zweites Volume auf gleichen SSD's bei der Migration immerhin noch je 1.8Gbit also über 200MB/s, nicht übel wie ich finde für gleichzeitig Read und Write. Übertragung von ca. 100GB bzw. 4 VM's gleichzeitig.
Ob mans braucht? Ich bis dato noch nicht. Mir reicht ein Kern.
Noch schöner wäre türlich die Auslagerung an eine Hardwarekarte.
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste