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!

SSD unter ESXi5 - muss man etwas beachten?

Moderatoren: irix, Dayworker

Benutzeravatar
Member
Beiträge: 168
Registriert: 25.11.2004, 21:29
Wohnort: VCP #768

Beitragvon IronEagle » 07.09.2012, 13:00

Also zum Thema VMWare find ich auf den Produktseiten der Software irgendwie nichts, oder bin ich blind? Oder ist das so gedacht das man 2 VMDKs anlegt, einmal auf nem schnellen Storage-Tier, einmal auf nem langsameren, und dann das ganze als Software in der VM betreibt? Das erscheint mir unnoetig komplex.

Dazu kommt, wie Dayworker ja schon schreibt, das man sich sehr wohl Gedanken ueber das Altern der SSD machen muss (oder um spontane Ausfaelle, die kommen da auch gern vor), sobald man die SSD auch als Write Cache nimmt.

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 07.09.2012, 15:21

@Dayworker: Die Jungs von stec scheinen schon ziemlich Pioniere auf dem Gebiet zu sein. Sind halt eher OEM-Verkäufer darum weniger bekannt. Ihre SSD's stecken angeblich in den meisten grösseren Enterprise Storage-Systemen. Info schon etwas älter, keine Ahnung ob das noch so ist.
Da die restlichen Performance Angaben sich im realistischen Bereich bewegen, dürfte das auch nicht gelogen sein.

@IronEagle: Letzeres, der Vermerk wie das für VmWare funktioniert kommt zu unterst in der FAQ.

Korrekt, man braucht eine zusätzliche RAW-Disk. Als RDM oder VMDK, Local oder auf SAN (für vMotion). Schaltet sich auf OS Ebene irgendwo dazwischen.

Klar ist das komplexer als auf Host- oder Storageebene, aber wenn man einzelne VM's, DB's oder auch einen physischen Server mit verhältnissmässig einfachen Mitteln massiv beschleunigen möchte, ein guter Ansatz wie ich finde. Sofern der Impact nicht zu heftig ist. Dürfte deutlich billiger sein, als ein ganzes Storage-System auf die Performance auszurichten.
Bricht die Performance für die Zeit die man für den Wechsel braucht ein, kann man das vermutlich verantworten. Die SSD darf ja kaputt gehen, so habe ich das zumindest verstanden. Obs auch in der Praxis funktioniert mit einer sterbenden Disk müsste man wohl ausprobieren.

Fals es tut, könnte ein solcher Accelerator für die DB'Server in einer kleineren Umgebung super sein. SSD's in einer kleinen SAN kosten ein Vermögen, bei jedem Storage-Vendor. :)

Betreffend Preis: Mit 400 irgendwas Dollar pro Jahr eigentlich nicht soooo teuer. Testen darf man es auch 30 Tage lang. Wer hat Lust? :D

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

Beitragvon Wirrkopf » 07.09.2012, 15:24

Ich hab heute meine "OCZ Vertex 3 Max IOPS 240 GB" bekommen. Sobald sie in meinem ESXi 5 eingebaut ist werd ich mal messen. Wenn jemand Vorschläge hat wie ich messen soll dann nur zu.

Ansonsten binde ich sie als lokaler Speicher ein, setzt da ein neues Windows 7, 32bit auf uns lass den Atto Diskbench 2.47 laufen. Vielleicht mach ich mir auch die Mühe sie vorher in einen nativen Client einzubauen um Vergleichswerte nativ <> Virtualisierung zu haben.

Laut z. B. diesem Test soll sie ja sogar besser sein als eine SSD 320 mit 600 GB von Intel (unter Windows). Mal sehen ob sie auch unter ESXi überzeugt und wie lange sie hält :lol:

Bild

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

Beitragvon Wirrkopf » 12.09.2012, 12:50

Hier mal Vergleichswerte der "OCZ Vertex3 Max IOPS" nativ und unter ESXi5.1.

Zuerst die Messwerte nativ auf dem Board unter Windows 7 professional, 64Bit mit 6 Kern AMD Phenom, 8 GB RAM.. Das WIn7 64Bit ist auf einer normalen HDD und die SSD ist als zusätzliches Laufwerk O eingebunden.

Bild

Hier der Messswert unter ESXi 5.1 auf dem selben Board. ESXi startet von einem USB Stick. Das Win7 64Bit ist auf einer virtuellen HDD auf der SSD installiert und ein zusätzliches virtuelles Laufwerk O ebenfalls auf der SSD. Nur damit es mit der Messung auf dem nativen Board vergleichbarer ist. Bei beiden Messungen wird also nicht das Systemlaufwerk C: gemessen sondern ein zusätzliches Laufwerk O: auf der SSD

Bild

Die Werte im virtuellen Win7 sind unterm Strich sogar besser als nativ :). Sicherlich durch Cacheeffekte des ESXi vermute ich. Jedenfalls sind die Werte im Vergleich zu einer normalen 500 GB HDD sehr viel besser.

Hier mal die Benchmarkwerte auf einer normalen lokalen 500 GB HDD. (Einschränkung: selbes Bord und CPU aber ESXi 5.0 und diverse laufende VMs....)

...folgen sobald der benschmark mal fertig ist. Das dauert sehr lange. Die Werte sind im Vergleich mit der SSD unterirdisch.

Member
Beiträge: 76
Registriert: 06.08.2008, 13:13

Beitragvon m.msc01 » 25.09.2012, 09:40

Hallo Zusammen

Ich habe einen PowerEdge T410 mit einem Perc H700 Controller, die Lesewerte sind soweit ganz gut aber die Schreib Werte sind voll nix, muss ich etwas am Controller noch einstellen? schaut euch mal bitte die werte an

Samsung SSD 830 256 GB als Raid 0, ESX 5.0

AS SSD Benchmark
Seq - Lesen 427,52 MBs - Schreiben 69,24 Mbs
4K - Lesen 9,28 Mbs - Schreiben 9,26 Mbs

Iops
16MB - Lesen 26,72 iops - Schreiben 4,33 iops
4K - Lesen 2376 iops - Schreiben 2371 iops


danke gruss
Michi

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

Beitragvon Supi » 25.09.2012, 10:31

vielleicht mal den schreibcache auf Write-Through stellen?

Member
Beiträge: 76
Registriert: 06.08.2008, 13:13

Beitragvon m.msc01 » 25.09.2012, 14:40

Danke :idea: werde es heute Abend gleich testen

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 25.09.2012, 15:49

Schicke Ergebnisse, macht Lust auf mehr.
Meine neue Test-Kiste lässt leider noch etwas auf sich warten.

Werde mal nur die Hälfte des Platzes der SSD (520er Intel) zu Verfügung stellen und testen. Da wird die SSD hoffentlich nicht ganz so schnell alt. Ist ja nicht ganz so tragisch wie bei nem Server der abraucht.


Interessant auch das hier:
Basically VHDX disks report themselves as thin provision capable. That means that any deletes as well as defrag operation in the guests will send down “unmaps” to the VHDX file, which will be used to ensure that block allocations within the VHDX file is freed up for subsequent allocations as well as the same requests are forwarded to the physical hardware which can reuse it for it’s thin provisioning purpose. This means that an VHDX will only consume storage for really stored data & not for the entire size of the VHDX, even when it is a fixed one. You can see that not t just the operating system but also the application/hypervisor that owns the file systems on which the VHDX lives needs to be TRIM/UNMAP aware to pull this off. It is worth nothing this mean that it only works on the SCSI attached storage in the virtual machine, not on IDE connected VHDX disks.

von hier
Nicht das ich meine VM's auf Hyper-V möchte (keine Ahnung ob man solche VM's irgendwie bei View veröffentlich kann), aber wenn MS das kann, wird VmWare bestimmt nachziehen.

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

Beitragvon Dayworker » 25.09.2012, 17:10

Der Vorteil von M$ ist aber, daß bis auf wenige Ausnahmen auschließlich Windows als Gast und damit NTFS, wenn auch in verschiedenen Versionen und damit unterschiedlichem Funktionsumfang, verwendet wird.
Damit das unter VMware klappt, müßte vSphere in meinen Augen aber das beim jeweiligen Gast eingesetzte Dateisystem zumindest lesen können.

Mir stellt sich aber gerade die Frage, wie M$ das auf einem Raid abbilden will. Es ist ja schön, daß der Host die vom Gast gemeldeten ungenutzten Sektoren auswerten/weiterreichen kann, nur interessiert es bisher den darunterliegenden Raid-Controller herzlich wenig. Beim Einsatz von SSDs im Raidverbund fällt in den meisten Fällen als erstes der TRIM-Support weg und die SSD muß sich selbst wieder um eine gescheite GC kümmern.

Ausgehend von http://www.anandtech.com/show/6124/the-intel-ssd-910-review:: "Each PCB has 17 NAND packages on the front and 11 on the back. If you look closely (and remember Intel's NAND nomenclature) you'll realize that these are quad-die 25nm MLC-HET NAND packages with a total capacity of 32GB per package. Do the math and that works out to be 1792GB of NAND on a 800GB drive (I originally underestimated how much NAND Intel was putting on these things). Intel uses copious amounts of NAND as spare area in all of its enterprise class SSDs (the 2.5" 200GB Intel SSD 710 used 320GB of NAND). Having tons of spare area helps ensure write amplification remains low and keeps endurance high, allowing the 910 to hit Intel's aggressive 7 - 14 Petabyte endurance target."
...würde ich mir eine weitere Halbierung der Nutzkapazität sparen, da zumindest die Enterprise-Versionen schon von Hause aus ausreichend Ausweichplatz mitbringen.

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 25.09.2012, 17:31

Auf RAID abbilden wird auch MS nicht können, bis die Anbieter da was gscheites bringen. Da MS scheinbar eh etwas in Richtung RAID-Unabhängig tendiert (Exchange, Replikation, Cluster ohne Shared Storage usw.) dürfte es auch ohne RAID-Controller ausfallsicher abzubilden sein. Quasi nach dem Motto: Lieber drei unabhängige billige Quellen ohne hohe Komplexität (Hardware), als eine teure die trotzdem nicht unbedingt ohne Fehler ist.
Kann man angeblich schon für VM-Images auf 2012 machen für File-Server noch nicht empfohlen. Wie genau das funzt habe ich mich auch noch zu wenig damit auseinander gesetzt.

Werde aber wohl eine 520er einsetzen und nicht 710/910, die hat nicht soviel auf der hohen Kante und IOPS zumindest gemäss Datenblatt deutlich höher. ;)

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

Beitragvon Dayworker » 25.09.2012, 18:35

Auf RAID abbilden wird auch MS nicht können, bis die Anbieter da was gscheites bringen. Da MS scheinbar eh etwas in Richtung RAID-Unabhängig tendiert (Exchange, Replikation, Cluster ohne Shared Storage usw.) dürfte es auch ohne RAID-Controller ausfallsicher abzubilden sein. Quasi nach dem Motto: Lieber drei unabhängige billige Quellen ohne hohe Komplexität (Hardware), als eine teure die trotzdem nicht unbedingt ohne Fehler ist.
Kann man angeblich schon für VM-Images auf 2012 machen für File-Server noch nicht empfohlen. Wie genau das funzt habe ich mich auch noch zu wenig damit auseinander gesetzt.
Sowas spricht entweder für den Einsatz der beim alten WHS noch vorhandenen Ordner-Replikation bzw dessen verbesserter Nachfolger oder für Dynamische Datenträger und der damit möglichen Zusammenfassung als SW-Raid. Interessant ist in diesem Zusammenhang das mit Win8 bzw WinServer2k12 einhergehende Equvivalent zu VMwares Thin/Sparse-Format, bei dem man Datenträger wesentlich grösser einrichten kann und erst bei Bedarf auch wirklich nachstecken muß.

Werde aber wohl eine 520er einsetzen und nicht 710/910, die hat nicht soviel auf der hohen Kante und IOPS zumindest gemäss Datenblatt deutlich höher. ;)
Also ausgehend von http://www.intel.com/content/www/us/en/ ... eries.html und http://www.intel.com/content/www/us/en/ ... eries.html scheint die http://www.intel.com/content/www/us/en/ ... eries.html wirklich wesentlich langsamer zu sein, die 910 aber je nach Grösse nur beim Schreiben. Bei der 910 kommt aber noch hinzu, daß die einzelnen "LUNs" der SSD durch den zugrundeliegenden LSI-Controller als separate Laufwerke gemeldet werden. Das Raid muß dadurch anscheinend durch das OS gebildet werden.

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 25.09.2012, 19:19

Dayworker hat geschrieben:Controller aus
Auf RAID abbilden ....
Sowas spricht entweder für den Einsatz der beim alten WHS noch vorhandenen Ordner-Replikation bzw dessen verbesserter Nachfolger oder für Dynamische Datenträger und der damit möglichen Zusammenfassung als SW-Raid. Interessant ist in diesem Zusammenhang das mit Win8 bzw WinServer2k12 einhergehende Equvivalent zu VMwares Thin/Sparse-Format, bei dem man Datenträger wesentlich grösser einrichten kann und erst bei Bedarf auch wirklich nachstecken muß.

Deshalb auch meine Frage im Hardware-Bereich ob bei dynamischen Datenträgern im RAID 1 die Trim-Fähigkeiten bestehen bleiben. Würde das ganze massiv vereinfachen und die paar MHZ CPU die gefressen wird für Software-RAID1 ist zu vernachlässigen, ebenfalls der IOPS-Overhead bei SSD. Wäre zumindest mal SSD-Technisch gut gelöst. Dann noch die Clusterung über zwei Hosts und das ganze ist schon ziemlich lecker wie ich finde. Noch dazu zu einem fast unschlagbaren Preis (Schon bei Standard mit dabei). Wie weit da MS wirklich ist, wird sich wohl erst mit den RC's zeigen. Storage vMotion ohne Shared storage ist auf alle Fälle auch schon dabei. Aktuell geht der Kram aber angeblich nur, wenn auch die VM's das ganze unterstützen.

Betreffend dem FileCluster und warum das nur für Images gedacht ist: Wegen den vielen AD-Abfragen oder so ähnlich würde aktuell die Performance zusammenbrechen bei "Missbrauch" der neuen Features für einen Fileserver, weil das irgendwie immer hin und her muss.

Des weiteren könnte man mit dem neuen Feature angeblich sogar ein High-Available-NFS Storage für VmWare bereithalten ohne dass man teure EMC, Netapp etc. braucht. Wird auch Hier beschrieben.

Wenn das allesso funktioniert wie es schick erklärt wird, dann könnte man für Kleinumgebungen durchaus mit einem ziemlich kleinen finanziellen Aufwand sehr lecker richtiges Hochverfügbar Out-Of-The Box erreichen, sogar für Kleinstumgebungen.

Intel-Teile: Jo genau, 910er ist zu teuer und PCIex, was etwas komplizierter ist aktuell und die 710er ist lahm. Deshalb 520er, die bringt einen guten Kompromiss und ist ziemlich preiswert. Da kann man auch die Hälfte oder ein Drittel an Platz verschenken. ;)

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 03.10.2012, 22:20

Also Trim funktioniert definitiv wenn Windows als Software-RAID-Hersteller genommen wird. Hier habe ich das ausführlich beschrieben.

Eröffnet vielleicht neue Möglichkeiten mit verhältnissmässig günstigem SATA-SSD-Storage. --> NFS Storage auf Windows für VmWare?, Nachwachsende Disc, Shrinken usw. Wäre doch saucool :D

Member
Beiträge: 82
Registriert: 12.09.2012, 20:56

Beitragvon albiderbaer » 10.10.2012, 22:06

Hallo zusammen,

ich hänge mich mal hier ran...
Ich habe einen LSi 9261 Raid-Controller an dem 2 Samsung SSD 830 im Raid 1 dran hängen. Im Controller werden die Platten als SSD erkannt; im ESXi 5.0 U1 zeigt er sie mir allerdings als Nicht-SSD an :?
Was muss ich denn noch einstellen, dass er mir die SSDs als solche anzeigt und auch so behandelt (siehe Alignment etc.)

Danke im voraus.

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

Beitragvon Dayworker » 10.10.2012, 22:22

Der ESX(i) kann dir die SSDs nicht mehr als solche anzeigen, da der Raid-Controller diese zu einem Raid zusammengefaßt hat und nur noch das entstandene Array an den ESX(i) meldet.
Das ist aber auch unabhängig vom Alignment. Sobald du einen DS über den Vi-/vSphere-Client einrichtest, beachtet VMware zumindest ab dem ESXi5 von sich aus das Alignment und richtet auch die Gäste entsprechend aus. Interessanten Lesestoff dazu gibts im VMTN unter disk alignment in ESXi oder als Blogs-Eintrag unter Guest OS Partition Alignment.
Anders sieht es allerdings mit TRIM aus. Momentaner Stand ist, daß VMware TRIM nicht unterstützt und die SSD selbst eine gute GC mitbringen muß und daran happert es wohl bei vielen SSDs.

Member
Beiträge: 82
Registriert: 12.09.2012, 20:56

Beitragvon albiderbaer » 10.10.2012, 23:02

@Dayworker Danke für die schnelle Antwort. Werde ich mir mal zu Gemüte führen...

Unverständlich ist mir allerdings, dass die mit vSphere erstellte Systempartition eines W2K3 im As SSD Benchmark als ok angezeigt wird und eine nachträglich erzeugte virtuelle Daten-Festplatte im gleichen Datastore eben nicht?? Oder muß ich etwa für jede Festplatte einen eigenen Datastore einrichten?

Alles weitere muß ich erst mal lesen.

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

Beitragvon Dayworker » 11.10.2012, 17:41

W2k3 beachtet meines Wissens nach wie XP oder W2k nicht das Alignment, da es bei Festplatten noch von den langjährigen 512Byte Sektorgrösse ausgeht und dort ist es dann auch egal, ob die Partition bei Sektor 63 oder wie bei W7, Vista ab SP1, Linux ab Kernel 2.6.34 bzw mit Linux-fdisk ab Version 2.17.1 und Mac OS X erst ab Sektor 2048 anfängt.
Umgehen kannst du das Alignmentproblem mit älteren OS prinzipiell nur, wenn du vor deren Inst die vDISK extern partitionierst. Ansonsten erhältst du wieder eine eine "Unaligned" Partition. Für das Alignment kannst du gparted, jede aktuelle Linux Live-CD, die W7-CD oder WinPE nutzen. Ab Vista mit SP1 ist das OS dann auch selbst in der Lage, Partitionen unter Beachtung des Alignment anzulegen.

Es wäre eigentlich auch ausreichend, wenn man die Partition bei Sektor 64 beginnen würde. Wenn man allerdings auf das empfohlene Alignment von 1MByte ausrichten will, landet man mit der aktuellen Adressierung in 512 Byte großen logischen Sektoren genau auf Sektor 2048. Eine Partition beginnt damit also nicht schon nach 31.5KByte sondern erst nach 1MByte.


[add]
Einem Imager sollte das Alignment ebenfalls bekannt sein. Ansonsten spielt dieser womögliche das Image wieder beginnend bei Sektor 63 ein und verursacht dadurch 25% Schreibperformanceverluste.
Im Zusammenhang mit vermutlich nicht nur M$-SQL sollte man auch wissen, daß der SQL-Server seine Daten nach einem Restore ebenfalls entweder aligned wissen will oder die DB-Partition wieder am früheren Partitionsbeginn anfangen muß. Zumindest der M$SQL-Server verweigert in allen anderen Fällen seine Mitarbeit und gibt eine entsprechende Fehlermeldung aus.

Benutzeravatar
Member
Beiträge: 168
Registriert: 25.11.2004, 21:29
Wohnort: VCP #768

Beitragvon IronEagle » 12.10.2012, 09:04

Die 25% Schreibverluste sind sehr optimistisch, gerade bei SSDs, wo dann bei den grossen Erase-Block-Groessen deutlich mehr zusammen kommen kann.

Auch bei klassischen Festplatten im Raid ist das Alignment essentiell wichtig, da reden wir ja auch ganz schnell von x-fachem Mehraufwand fuer die Festplatten, nicht nur Faktor 2 - das explodiert ganz schnell ins vielfache.

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

Beitragvon Dayworker » 12.10.2012, 16:07

Die 25% Schreibverluste sind sehr optimistisch, gerade bei SSDs, wo dann bei den grossen Erase-Block-Groessen deutlich mehr zusammen kommen kann.
Wieso sind 25% Schreibverluste sehr optimistisch?
Partitionen von älteren OS kommen auf Sektor 63 zu liegen und damit genau 512Byte vor einem aligned Sektor. Das hinten dann ein Teil fehlt, spielt für die Performance meines Wissens keine Rolle mehr.


Auch bei klassischen Festplatten im Raid ist das Alignment essentiell wichtig, da reden wir ja auch ganz schnell von x-fachem Mehraufwand fuer die Festplatten, nicht nur Faktor 2 - das explodiert ganz schnell ins vielfache.
Solange du keine Platten über 2TB bzw Platten mit von 512Byte abweichender Sektorgrösse oder SSDs einsetzt, spielt das Alignment auch in einem Raid keine Rolle.

Benutzeravatar
Member
Beiträge: 168
Registriert: 25.11.2004, 21:29
Wohnort: VCP #768

Beitragvon IronEagle » 13.10.2012, 10:49

Dayworker hat geschrieben:
Die 25% Schreibverluste sind sehr optimistisch, gerade bei SSDs, wo dann bei den grossen Erase-Block-Groessen deutlich mehr zusammen kommen kann.
Wieso sind 25% Schreibverluste sehr optimistisch?
Partitionen von älteren OS kommen auf Sektor 63 zu liegen und damit genau 512Byte vor einem aligned Sektor. Das hinten dann ein Teil fehlt, spielt für die Performance meines Wissens keine Rolle mehr.

Bei SSDs gehts nicht um Sektoren, sondern um Write- und Erase-Blocks. SSDs koennen ja nicht einfach 512 Byte oder 4 Kilobyte irgendwo hin schreiben, da die Write-Blocks deutlich groesser sind. Direktes schreiben geht auch nur wenn der Write-Block "leer" ist. Wenn in einem Write-Block, von dem der Controller denkt das er belegt ist, ein 4k Block (also die kleinste Einheit, die ein aktuelles Dateisystem kennt) geschrieben werden soll, dann muss der SSD-Controller erstmal den kompletten Erase-Block einlesen, die 4k einsetzen, und dann den ganzen krams wieder wegschmeissen. Soweit das normale Verhalten von SSDs. Um dem entgegen zu wirken gibts die Spare Area, Garbage Collection, Trim... Aber wenn man da jetzt nicht richtig ausgerichtete Partitionen hat hantiert man dann gern mal mit deutlichem Mehraufwand, dann werden halt direkt 2 Erase-Blocks eingelesen/weggeschrieben, was dann auch auch (Stichwort Write Amplification) auf die Lebenszeit der SSD geht,

Dayworker hat geschrieben:
Auch bei klassischen Festplatten im Raid ist das Alignment essentiell wichtig, da reden wir ja auch ganz schnell von x-fachem Mehraufwand fuer die Festplatten, nicht nur Faktor 2 - das explodiert ganz schnell ins vielfache.
Solange du keine Platten über 2TB bzw Platten mit von 512Byte abweichender Sektorgrösse oder SSDs einsetzt, spielt das Alignment auch in einem Raid keine Rolle.


Auch kleinere Platten haben mittlerweile 4k Sektoren. Und wir reden hier ja auch von Storage-Systemen, die ja im grunde ihr eigenes Dateisystem auf die Platten werfen, und darin dann im Endeffekt Dateien ablegen, welche dann als LUN dem OS praesentiert werden. (fuer Ablage der VMDKs auf NFS gilt das gleiche). WAFL (das NetApp Dateisystem) hat z.b. ne Blockgroesse von 4k. Wenn ich dort eine LUN anlege ist die auf 4k aligned. Wenn jetzt aber der Nutzer der LUN herkommt und das Dateisystem in der LUN nicht auf 4k aligned hab ich ein Problem: Für jeden 4k Block der (aus Serversicht) von der LUN gelesen werden soll muss das Storage System 2 Bloecke lesen. Beim Schreiben muessen jetzt nicht nur 2 Bloecke geschrieben werden, sondern von 2 Stripes die Daten neu eingelesen werden, damit die Parity neu berechnet werden kann. Und schon haben wir einen Mehraufwand der deutlich hoeher liegt als Faktor 2, und das System massiv runterzieht.

http://www.netapp.com/us/library/techni ... -3747.html erklaert das sicher verstaendlicher als ich :)

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

Beitragvon Dayworker » 15.10.2012, 05:03

Ich hab da mal ein "klitzekleines" HowTo - Nachträgliches Alignment auf Sektor 2048 für Windows und Linux verfaßt. :D

Benutzeravatar
Member
Beiträge: 446
Registriert: 11.03.2008, 12:28
Wohnort: Seligenstadt

Beitragvon sirrossi » 15.10.2012, 11:28

Ronald, Du bist echt ein Typ ;)

Wenn ich mal wieder ein Handbuch zu erstellen habe, ruf ich Dich an 8)

Member
Beiträge: 3
Registriert: 03.02.2013, 21:01

OCZ Vertex2

Beitragvon codeguru » 08.02.2013, 08:52

also ich erstand neulich für wenig Geld eine OCZ Vertex2 mit 240 GB und Sandforce Controller. Der hat mit Intel ICH basiserenden Chipsätzen so Probleme, Windows vista und Windows 7 auf einem ICH6 Notebook hattten 40 MB/Sekunde beim linearen Lesen von großen Dateien. Ganz anders sah das auf meinem AMD 970 Chipsatz aus.... mehr als 200 MB/Sekunde.

Mein Notebook war nämlich eines Tages tot, und ich baute die SSD in meine Whitebox ein. Zunächst als Swapdrive (aber wer swappt denn bitteschön mit 32 GB) und zum Installieren. Windows 2008R2 und Windows 7 starten in wenigen Sekunden, auch sind Installationsvorgänge abenteuerlich schnell erledigt.

Ich hab noch zwei Hitachi 1 TB Platten mit 7200 RPM verbaut, die beide 60-100 MB/sec liefern und das ist ein merklicher Unterschied. So richtig gemessen hab ich das noch nicht...

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 08.02.2013, 10:32

Habe ja grad einen Produktiven Server mit SSDs und einer Server 2012 in der Testphase. Das Teil rennt schon ziemlich schnell.

--> Durchsatz von zwei VM's auf dem gleichen Host, wo eine VM auf dem VMFS Datastore parallel neben der StorageApp läuft und eine VM auf dem NFS (auf welche ich schreibe) liegt bei jeweils deaktiviertem Schreibcache ca. 100 MB/s konstant bei RAID 1 für grosse Files. Am Anfang rund 3x so schnell (Cached OS/ESXi auch?). Für sehr viele kleine Files sinkt der Durchsatz bis auf ca. 37 wenn ein paar tausend aufs mal kopiert werden. Im RAID 10, also wenn die Daten über zwei Discs gestriped werden, ist der Durchsatz rund verdoppelt.

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

Beitragvon Dayworker » 08.02.2013, 11:33

UrsDerBär hat geschrieben:liegt bei jeweils deaktiviertem Schreibcache ca. 100 MB/s konstant bei RAID 1 für grosse Files. Am Anfang rund 3x so schnell (Cached OS/ESXi auch?).
Welchen Kopierumfang in GiB hattest du dabei im Test?
Ob OS oder ESXi auch cachen weiß ich nicht. Es ist aber für Desktop-SSDs nichts ungewöhnliches, wenn diese nach einigen GiB einbrechen. Die Anzahl freier Sektoren ist halt begrenzt und dazu kommt, daß für Desktop-SSDs auch keine Worst-Case-Zeiten garantiert werden, bis auch wirklich alle anstehenden Schreiboperationen abgearbeitet sind. Sowas hat meines Wissens bisher erst Intel mit seiner Server SSD DC S3700 spezifiert.

Lustig finde ich bei SSDs allgemein, daß deren hohen Transferraten allerorten nur in einer 8GiB grossen Testdatei ermittelt werden. Die ermittelten Werte haben daher zumindest beim Servereinsatz nur noch einen rein illusorischen Charakter. Aber diese Illusion läßt ganz schnell vertreiben, indem man einfach mal schlecht kompimierbare Testdateien (Bilder im Gigapixel-Format, Videodateien etc) in GB-Grösse und 90% SSD-Kapazitätsumfang benutzt oder die SSD gemeinerweise mit Truecrypt verschlüsselt...


Zurück zu „vSphere 5 / ESXi 5 und 5.1“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste