6
ESXi Swapfile auf OCZ Z-Drive auslagern?
Hallo Forum,
folgende Situation:
Wir betreiben derzeit einen VMware vSphere-Cluster bestehend aus:
3x IBM x3650 M3 Server (Jeweils, 2x6C Xeon, 96GB RAM, 2x 8Gb/s FC HBAs)
1x IBM DS3500 + Expansion insgesamt 24x2TB NL SAS Platten angebunden über FC
Primäre Aufgabe des Clusters ist die Bereitstellung von Testumgebungen für unsere Entwicklungsabteilung (Ein Haufen unterschiedliche OS und Datenbanken in allen möglichen Versionen und Ausführungen).
So weit so schön, Problem ist nur: Wie groß man so ein System auch mal konzeptioniert gehabt haben mag, irgendwann ist es zu klein.
In unserem Speziellen Fall mangelt es (oder besser gesagt: wird es bald mangeln) einfach an RAM um die verschiedenen VM Guests zu betreiben.
Folgende Optionen haben wir uns nun überlegt:
- RAM in den Geräten aufstocken - Ginge, ist aber teuer, weil nur noch 8GB Riegel eine Verbesserung bringen würden und wir einen Haufen bereits gekaufter 4GB Riegel in die Tonne kloppen können).
- Einen weiteren Server in den Cluster nehmen - Ginge auch, nur leider gibt das unsere vSphere Lizenz (Essentials Plus) nicht her, die nächstgrößere Lizenz ist auch fürchterlich teuer.
- Wir stocken nicht den RAM auf, sondern lassen einfach zu, dass der ESXi auf sein Swapfile (beziehungsweise die einzelnen Auslagerungsdateien der Guests) zurück fällt. Und damit der Performance-Einbruch nicht ganz so arg ausfällt spendieren wir jedem der Server ein PCIe SSD-RAID, wie zum beispiel die Z-Drives von OCZ (http://www.ocztechnology.com/products/solid_state_drives/pci-e_solid_st ..) und definieren dieses Laufwerk als Speicherort der Swapfiles.
Wie besagt, es handelt sich primär um Testsysteme bei denen die Performance nicht ganz so wichtig ist. Außerdem Idlen sehr viele der Maschinen den Großteil des Tages und wären somit in einem Swapfile eigentlich ganz gut aufgehoben.
Konkret meine Fragen nun:
1) Können die Server-EFIs mit so einem Teil umgehen?
2) Kann der ESXi 4.1 mit so einem Teil umgehen?
3) Ist der ESXi schlau genug die Maschinen die gerade Idlen in den Swap zu stecken und die aktiven im RAM zu belassen oder wird das einfach gleichmäßig zwischen den VMs verteilt?
Hoffe jemand von euch hat mit so etwas schon Erfahrungen gemacht, oder kann mir eine andere Gute Idee vorschlagen.
Grüße
Bastian
folgende Situation:
Wir betreiben derzeit einen VMware vSphere-Cluster bestehend aus:
3x IBM x3650 M3 Server (Jeweils, 2x6C Xeon, 96GB RAM, 2x 8Gb/s FC HBAs)
1x IBM DS3500 + Expansion insgesamt 24x2TB NL SAS Platten angebunden über FC
Primäre Aufgabe des Clusters ist die Bereitstellung von Testumgebungen für unsere Entwicklungsabteilung (Ein Haufen unterschiedliche OS und Datenbanken in allen möglichen Versionen und Ausführungen).
So weit so schön, Problem ist nur: Wie groß man so ein System auch mal konzeptioniert gehabt haben mag, irgendwann ist es zu klein.
In unserem Speziellen Fall mangelt es (oder besser gesagt: wird es bald mangeln) einfach an RAM um die verschiedenen VM Guests zu betreiben.
Folgende Optionen haben wir uns nun überlegt:
- RAM in den Geräten aufstocken - Ginge, ist aber teuer, weil nur noch 8GB Riegel eine Verbesserung bringen würden und wir einen Haufen bereits gekaufter 4GB Riegel in die Tonne kloppen können).
- Einen weiteren Server in den Cluster nehmen - Ginge auch, nur leider gibt das unsere vSphere Lizenz (Essentials Plus) nicht her, die nächstgrößere Lizenz ist auch fürchterlich teuer.
- Wir stocken nicht den RAM auf, sondern lassen einfach zu, dass der ESXi auf sein Swapfile (beziehungsweise die einzelnen Auslagerungsdateien der Guests) zurück fällt. Und damit der Performance-Einbruch nicht ganz so arg ausfällt spendieren wir jedem der Server ein PCIe SSD-RAID, wie zum beispiel die Z-Drives von OCZ (http://www.ocztechnology.com/products/solid_state_drives/pci-e_solid_st ..) und definieren dieses Laufwerk als Speicherort der Swapfiles.
Wie besagt, es handelt sich primär um Testsysteme bei denen die Performance nicht ganz so wichtig ist. Außerdem Idlen sehr viele der Maschinen den Großteil des Tages und wären somit in einem Swapfile eigentlich ganz gut aufgehoben.
Konkret meine Fragen nun:
1) Können die Server-EFIs mit so einem Teil umgehen?
2) Kann der ESXi 4.1 mit so einem Teil umgehen?
3) Ist der ESXi schlau genug die Maschinen die gerade Idlen in den Swap zu stecken und die aktiven im RAM zu belassen oder wird das einfach gleichmäßig zwischen den VMs verteilt?
Hoffe jemand von euch hat mit so etwas schon Erfahrungen gemacht, oder kann mir eine andere Gute Idee vorschlagen.
Grüße
Bastian
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 164242
Url: https://administrator.de/forum/esxi-swapfile-auf-ocz-z-drive-auslagern-164242.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
6 Kommentare
Neuester Kommentar
So schön SSDs auch sind: hast Du Dir mal angeschaut wie schnell RAM im Vergleich zum besten PCIe SSD-RAID ist? Da liegen auch bei einem RAID noch Welten dazwischen (vielleicht Faktor 10-20 zu DDR3 geschätzt). Ich fürchte, das wird nicht viel bringen, nur viel kosten. Aber hör Dich mal um, ob das schon jemand gemacht hat.
Lass die Finger von SSDs in Servern. Ich hab von einem großen Unternehmen gehört, welches probeweise SSDs eingesetzt hat, sogar die von IBM freigegebenen, dass SSDs innerhalb von 3 Monaten kaputtgeschrieben sind. Im genauen ging es um Exchangeserver. Swapspace auf SSD ist ja nochmal schlimmer.
Ich würde mal eher sagen, dass war ein Fall von Fehlplanung. Ich hab exakt das gleiche Besteck im Unternehmen stehen, mit dem Unterschied, dass das Storage per SAS angebunden ist. Wir haben direkt die 8er Riegel genommen.
Wir sind zwar noch im Aufbau, aber unser Systemhaus sprach davon, dass die exakt den Aufbau problemlos mit 60 Servern laufen lassen, also irgendwie scheint es bei dir wirklich ne große Fehlplanung gegeben zu haben.
Was aber irgendwie Performancemäßig nicht passt ist das Storage. Da sollte man wirklich schon 15k-Platten nehmen, weil die Platten da nicht hinterherkommen und so der RAM vollläuft. VMs und DBs auf 15k Platten, unkritische Dateien auf 7k2.
Ich würde mal eher sagen, dass war ein Fall von Fehlplanung. Ich hab exakt das gleiche Besteck im Unternehmen stehen, mit dem Unterschied, dass das Storage per SAS angebunden ist. Wir haben direkt die 8er Riegel genommen.
Wir sind zwar noch im Aufbau, aber unser Systemhaus sprach davon, dass die exakt den Aufbau problemlos mit 60 Servern laufen lassen, also irgendwie scheint es bei dir wirklich ne große Fehlplanung gegeben zu haben.
Was aber irgendwie Performancemäßig nicht passt ist das Storage. Da sollte man wirklich schon 15k-Platten nehmen, weil die Platten da nicht hinterherkommen und so der RAM vollläuft. VMs und DBs auf 15k Platten, unkritische Dateien auf 7k2.
Hallo Bastian,
uns allen geht mal so, wir stellen fest das wir etwas vergessen haben oder an etwas nicht gedacht haben. Aber genau in diesem Augenblick wissen wir, dass wir das vergessen oder falsch geplant haben, diese Sache aber immer wieder zu mach, zu vergessen oder immer nach einem Workaround zu suchen und am Ende fest zu stellen, das man dann nur Flickschusterei hat ist nicht die stabile Basis auf der man weiter aufbauen kann.
Es ist natürlich auch nicht schön dem Chef zu erzählen das man wieder mal Geld brauch, kennen wir doch alle ;) aber den Fehler zu wiederholen bis zum nächsten Problem
(was natürlich auch an Dir hängen bleibt) ist nichts als aufschieben.
Hast Du ein Problem dann löse es, kauf die 8 GB Riegel und tausche alle 4 GB Module aus. Mal anders gefragt was passiert denn, wenn das produktivsystem nicht mehr mithalten kann? Schließt Ihr den Laden dann ? Oder kauf Ihr erst dann neue Hardware. Probleme geschickt umgehen können wir alle irgendwie, selberbauen und sich selber loben, aber bitte nur zu Hause und nicht im Betrieb. Vorrausschau ist auch eine Tugend !!! Und um den betrieblichen Erfolg weiterhin zu gewährleisten muss man auch was in Hardware investieren, gerade dann wenn guter Rat teuer ist sich aber durchen kauf von standard Hardware gut, sicher und schnell lösen lässt.
Denn mal ehrlich von was reden wir hier denn von RAM Modulen und einem 19" NAS mit SAS Platten die man als Raid an ein bestehen System einbaut und anbindet.
Sprich mit deinem Chef und (von mir aus auch stepp bei stepp) und schaff Dir nen NAS mit SAS platten an, ich weiß es hört sich an wie Hochmut doch glaub mir die Foren sind voll mit Tipps und Tricks und super Vorschlägen die Du weder nachvollziehen noch angucken kannst, aber die RAM Riegel sind schnell gewechselt und das NAS, na ja wie schon gesagt habe ich mal einen Fehler gemacht gebe ich das eben zu und dazu gehört auch Größe und Rückrad aber ich mache nicht den gleichen Fehler wieder denn dann ist es Dummheit.
Um nicht also newbie aufzufallen schließe ich mich mal leise der Meinung von DerWoWusste an, denn ich würde die Dinger (SSD) nur zu Hause einsetzten und nicht im Betrieb.
Ich weis das ich die Fragen die gestellt wurden nicht beantwortet habe, aber eine ehrliche Meinung die einen von einer zweiten Fehlplanung abbringt ist doch auch was.
uns allen geht mal so, wir stellen fest das wir etwas vergessen haben oder an etwas nicht gedacht haben. Aber genau in diesem Augenblick wissen wir, dass wir das vergessen oder falsch geplant haben, diese Sache aber immer wieder zu mach, zu vergessen oder immer nach einem Workaround zu suchen und am Ende fest zu stellen, das man dann nur Flickschusterei hat ist nicht die stabile Basis auf der man weiter aufbauen kann.
Es ist natürlich auch nicht schön dem Chef zu erzählen das man wieder mal Geld brauch, kennen wir doch alle ;) aber den Fehler zu wiederholen bis zum nächsten Problem
(was natürlich auch an Dir hängen bleibt) ist nichts als aufschieben.
Hast Du ein Problem dann löse es, kauf die 8 GB Riegel und tausche alle 4 GB Module aus. Mal anders gefragt was passiert denn, wenn das produktivsystem nicht mehr mithalten kann? Schließt Ihr den Laden dann ? Oder kauf Ihr erst dann neue Hardware. Probleme geschickt umgehen können wir alle irgendwie, selberbauen und sich selber loben, aber bitte nur zu Hause und nicht im Betrieb. Vorrausschau ist auch eine Tugend !!! Und um den betrieblichen Erfolg weiterhin zu gewährleisten muss man auch was in Hardware investieren, gerade dann wenn guter Rat teuer ist sich aber durchen kauf von standard Hardware gut, sicher und schnell lösen lässt.
Denn mal ehrlich von was reden wir hier denn von RAM Modulen und einem 19" NAS mit SAS Platten die man als Raid an ein bestehen System einbaut und anbindet.
Sprich mit deinem Chef und (von mir aus auch stepp bei stepp) und schaff Dir nen NAS mit SAS platten an, ich weiß es hört sich an wie Hochmut doch glaub mir die Foren sind voll mit Tipps und Tricks und super Vorschlägen die Du weder nachvollziehen noch angucken kannst, aber die RAM Riegel sind schnell gewechselt und das NAS, na ja wie schon gesagt habe ich mal einen Fehler gemacht gebe ich das eben zu und dazu gehört auch Größe und Rückrad aber ich mache nicht den gleichen Fehler wieder denn dann ist es Dummheit.
Um nicht also newbie aufzufallen schließe ich mich mal leise der Meinung von DerWoWusste an, denn ich würde die Dinger (SSD) nur zu Hause einsetzten und nicht im Betrieb.
Ich weis das ich die Fragen die gestellt wurden nicht beantwortet habe, aber eine ehrliche Meinung die einen von einer zweiten Fehlplanung abbringt ist doch auch was.
Hallo Allerseits,
erst einmal vielen Dank für die Beiträge.
Ich habe jedoch das Gefühl, dass sich dieser Thread in die falsche Richtung entwickelt. Es geht mir hier weder darum auf biegen und brechen kosten zu sparen, noch meinem Chef im unklaren über die aktuelle Situation zu lassen (der ist schon lange eingeweiht). Falls es sich am Ende herausstellt, dass wir den Cluster einfach skalieren müssen, dann werden wir das wohl tun.
Mir ging es viel mehr darum zu evaluieren ob ein SSD-RAID nicht eigentlich den Anforderungen unseres Clusters gut Rechnung trägt. (gibt auch irgendwo ein Whitepaper von MS dass ich gerade nicht finden kann, indem sie zu dem Schluss kommen, dass die Leistungscharakteristika einer SSD ziemlich genau den Anforderungen eines Swapfiles entsprechen)
Wie oben beschrieben: Maschinen Idlen den Großteil des Tages und könnten gut in ein Swapfile ausgelagert werden, bis sie tatsächlich wirklich gebraucht werden.
Die alle im RAM vorzuhalten auf den verdacht hin, dass irgendwer, irgendwann mal, vielleicht, möglicherweise darauf zugreifen muss erscheint mir schlicht unökonomisch.
Zum Thema 15k-Platten oder 7,2K-Platten. Wir sind mit der Performance unseres SANs sehr zufrieden. Es geht hier, wie eingangs beschrieben, um Testsysteme keine produktiven DBs oder ähnliches (hier wäre Swap absolut tödlich, das sehen wir bei unseren Kunden oft genug).
Grüße
Bastian
erst einmal vielen Dank für die Beiträge.
Ich habe jedoch das Gefühl, dass sich dieser Thread in die falsche Richtung entwickelt. Es geht mir hier weder darum auf biegen und brechen kosten zu sparen, noch meinem Chef im unklaren über die aktuelle Situation zu lassen (der ist schon lange eingeweiht). Falls es sich am Ende herausstellt, dass wir den Cluster einfach skalieren müssen, dann werden wir das wohl tun.
Mir ging es viel mehr darum zu evaluieren ob ein SSD-RAID nicht eigentlich den Anforderungen unseres Clusters gut Rechnung trägt. (gibt auch irgendwo ein Whitepaper von MS dass ich gerade nicht finden kann, indem sie zu dem Schluss kommen, dass die Leistungscharakteristika einer SSD ziemlich genau den Anforderungen eines Swapfiles entsprechen)
Wie oben beschrieben: Maschinen Idlen den Großteil des Tages und könnten gut in ein Swapfile ausgelagert werden, bis sie tatsächlich wirklich gebraucht werden.
Die alle im RAM vorzuhalten auf den verdacht hin, dass irgendwer, irgendwann mal, vielleicht, möglicherweise darauf zugreifen muss erscheint mir schlicht unökonomisch.
Zum Thema 15k-Platten oder 7,2K-Platten. Wir sind mit der Performance unseres SANs sehr zufrieden. Es geht hier, wie eingangs beschrieben, um Testsysteme keine produktiven DBs oder ähnliches (hier wäre Swap absolut tödlich, das sehen wir bei unseren Kunden oft genug).
Grüße
Bastian
also die "schlechtesten" SSD mit MLC Technik haben einen wearout von 5000 Schreibzyklen, das ist für Consumer die da ein Windows 7 drauf betreiben, in etwa so also ob die ssd in 50 Jahren verbraucht ist.
Genauer betrachtet kann man also die gesamte Kapazität 5000x vollschreiben (bei den Intel Server SSD 50.000 mal) und dann muß man noch beachten daß da noch ca. 50% Reserve in den SSDs drin ist. Eine 100 GB SSD, die 100 MB/Sec beim Schreiben macht, hält also bei permanenten Schreiben 57 Tage. Das ist aber rein theoretisch, die Nutzung eines Swapfiles ist 50/50, also wären wir schon bei 114 Tagen. Nutzt man aber nur ein Swapfile von 10 GB, dann macht das schon 1000 Tage bei permanentem Paging. Oder ca. 3 Jahre bei PERMANENTEM Paging welches nur bei exremer Überlast auftritt.... Beispiel: Server mit 4 GB Ram hat 7,5 GB alloziertes Ram für alle Anwendungen (war ein Terminalserver) und selbst bei DER Last hat er nur 20% der Zeit mit Paging verbracht. Der würde die SSD nach mehr als 10 Jahren kaputtschreiben.
Und eine Server-SSD mit 100 GB kost vielleicht 250 Euro, Consumer SSDs sind da schon unter 100 Euro erhältlich.
Ich würd das mal als schnelle Abhilfe für Speichermangel betrachten, aber um eine SSD zum Swap Device zu machen, müßte man
a) mit dem FDisk eine Partition vom Typ SWAP anlegen und mit mkfs formatieren.
b) in einer (wohlmöglich in /etc liegenden Datei) mit dem Namen mounttab den Ort des Swap Filesystems ändern
Selbst eine einzelne SSD kommt heutzutage an das Limit eines SAS Kanals heran, bzw. ist etwas größer als SATA kann (3 Gbit / Sekunde) bei SATA2 bzw. 6 Gbit/sec bei SATA3 / SAS 2.
Deshalb wird ein Raid wohl nicht allzuviel bringen, meines ERachtens ist es bei halbwegs zugänglichen Servern mal zu testen, ob da irgendwo onboard eine simple SATA Schnittstelle da ist, an der man die SSD dann anstöpselt.
Es gibt noch ne option - man kann eine SSD auch nachträglich einbinden, und dann in der Konfiguration einer VM bestimmen, auf welchem Datastore (mit VMFS3 oder 5) die Swapdatei der VM liegen soll. Irgendwo kann man das nämlcih eisntellen, aber eine Swapdatei mit der VM zusammen auf demselben Datastore zu legen ist eher uneffektiv. Und hier käme die SSd ins Spiel, es gibt irgendwo nämlcih eine Einstellung, auf welchem Datastore die Auslagerungsdateien standardmäßig zum liegen kommen, und zumindestens bei der Installation legt man das fest wo die Partition vom Typ SWAP liegt.
Das später zu ändern erfordert Linux-Kenntnisse, denn das OS unter VMware ist ein Redhat.
Ich würd aber auf keinen Fall da irgendwo ein Raid1 oder 10 in einem EXTERNEN Speichergehäuse einbauen, denn allerhöhcstwahrscheinlich hat man schon mit einer GUTEN SSD die gesamte Transferrate eines SAS Kanals ausgschöpft - merke, es gibt mittlerweile SSDs die irgendwo bie 600-700 MB/Sekunde beim Lesen und schreiben sind wenn man das Geld dafür hat. Also warum 4 kaufen wenn die Nettoleistung schon von einer im Rechner eingebauten SSD erreicht werden kann? Wir haben auf der Arbeit einen Externus 60, über den SAS Controller macht das Ding maximal 12 Gbit/Sekunde theoreitsch, es ist mit 12x2 TB Platten bestückt, die ca. 130 MB/sec beim linearen Lesen bringen, aber trotzdem bin ich beim Kopieren von einem Stripeset aus 6 Platten auf ein zweites Stripeset mit weiteren 6 Platten irgendwo bei 150 bis 200 MB/Sekunde steckengeblieben auch wenn theoretisch Werte bei 600 MB/Sec hätten drinsein müssen.
Sowas macht man nur um bei Datenbanken die Latenzzeit zu senken.... die da netto ca. 7 ms beträgt bei random I/O bei rotierenden 15K HDs und ca. 3 ms bei SSD. Und die 3 ms sind dem Controller auf der SSD selbst geschuldet (die maximal 100.000 iop/s schaffen) und auch der Hardware zwischen OS und den Daten.
Genauer betrachtet kann man also die gesamte Kapazität 5000x vollschreiben (bei den Intel Server SSD 50.000 mal) und dann muß man noch beachten daß da noch ca. 50% Reserve in den SSDs drin ist. Eine 100 GB SSD, die 100 MB/Sec beim Schreiben macht, hält also bei permanenten Schreiben 57 Tage. Das ist aber rein theoretisch, die Nutzung eines Swapfiles ist 50/50, also wären wir schon bei 114 Tagen. Nutzt man aber nur ein Swapfile von 10 GB, dann macht das schon 1000 Tage bei permanentem Paging. Oder ca. 3 Jahre bei PERMANENTEM Paging welches nur bei exremer Überlast auftritt.... Beispiel: Server mit 4 GB Ram hat 7,5 GB alloziertes Ram für alle Anwendungen (war ein Terminalserver) und selbst bei DER Last hat er nur 20% der Zeit mit Paging verbracht. Der würde die SSD nach mehr als 10 Jahren kaputtschreiben.
Und eine Server-SSD mit 100 GB kost vielleicht 250 Euro, Consumer SSDs sind da schon unter 100 Euro erhältlich.
Ich würd das mal als schnelle Abhilfe für Speichermangel betrachten, aber um eine SSD zum Swap Device zu machen, müßte man
a) mit dem FDisk eine Partition vom Typ SWAP anlegen und mit mkfs formatieren.
b) in einer (wohlmöglich in /etc liegenden Datei) mit dem Namen mounttab den Ort des Swap Filesystems ändern
Selbst eine einzelne SSD kommt heutzutage an das Limit eines SAS Kanals heran, bzw. ist etwas größer als SATA kann (3 Gbit / Sekunde) bei SATA2 bzw. 6 Gbit/sec bei SATA3 / SAS 2.
Deshalb wird ein Raid wohl nicht allzuviel bringen, meines ERachtens ist es bei halbwegs zugänglichen Servern mal zu testen, ob da irgendwo onboard eine simple SATA Schnittstelle da ist, an der man die SSD dann anstöpselt.
Es gibt noch ne option - man kann eine SSD auch nachträglich einbinden, und dann in der Konfiguration einer VM bestimmen, auf welchem Datastore (mit VMFS3 oder 5) die Swapdatei der VM liegen soll. Irgendwo kann man das nämlcih eisntellen, aber eine Swapdatei mit der VM zusammen auf demselben Datastore zu legen ist eher uneffektiv. Und hier käme die SSd ins Spiel, es gibt irgendwo nämlcih eine Einstellung, auf welchem Datastore die Auslagerungsdateien standardmäßig zum liegen kommen, und zumindestens bei der Installation legt man das fest wo die Partition vom Typ SWAP liegt.
Das später zu ändern erfordert Linux-Kenntnisse, denn das OS unter VMware ist ein Redhat.
Ich würd aber auf keinen Fall da irgendwo ein Raid1 oder 10 in einem EXTERNEN Speichergehäuse einbauen, denn allerhöhcstwahrscheinlich hat man schon mit einer GUTEN SSD die gesamte Transferrate eines SAS Kanals ausgschöpft - merke, es gibt mittlerweile SSDs die irgendwo bie 600-700 MB/Sekunde beim Lesen und schreiben sind wenn man das Geld dafür hat. Also warum 4 kaufen wenn die Nettoleistung schon von einer im Rechner eingebauten SSD erreicht werden kann? Wir haben auf der Arbeit einen Externus 60, über den SAS Controller macht das Ding maximal 12 Gbit/Sekunde theoreitsch, es ist mit 12x2 TB Platten bestückt, die ca. 130 MB/sec beim linearen Lesen bringen, aber trotzdem bin ich beim Kopieren von einem Stripeset aus 6 Platten auf ein zweites Stripeset mit weiteren 6 Platten irgendwo bei 150 bis 200 MB/Sekunde steckengeblieben auch wenn theoretisch Werte bei 600 MB/Sec hätten drinsein müssen.
Sowas macht man nur um bei Datenbanken die Latenzzeit zu senken.... die da netto ca. 7 ms beträgt bei random I/O bei rotierenden 15K HDs und ca. 3 ms bei SSD. Und die 3 ms sind dem Controller auf der SSD selbst geschuldet (die maximal 100.000 iop/s schaffen) und auch der Hardware zwischen OS und den Daten.
also.... die Antwort:
Ich hab ne OCZ Vertex 240 GB aus einem toten Notebook ...
in den Rechner reingesteckt, ich hab ne Whitebox - da isses egal - an einen ICH9 SATA Port. ESX 4.1 und höher erkennen da Datastores, 3.5 nicht. Ich hab 4.1 gehabt, gerade auf 5.1 upgegraded. Wird also im VMware dann über "speicher" "speicher hinzufügen" mit 100 GB VMFS3 formatiert und "SSD" benannt.
scheinbar wichtig: alle VMs runtefahren. Dann Wartungsmodus einschalten.
Dann: Reiter Konfiguration, Erweitert (untere Hälfte) Speicherort der Auslagerungsdatei - rechts oben auf "bearbeiten" klicken, dann erscheint ne Dialogbox. Obere Option: "immer mit VM auf dem Datastore speichern wo die VM liegt" und "Speicherort festlegen" mit einer Liste der VMFS formatierten Dateastores. Also die untere Radiobutton-Option auswählen, "SSD" auswählen, dann auf ok klicken. Wartungsmodus ausschalten.
Bei neu angelegten VMs wird diese Einstellung dann wohl verwendet, auch bei allen, die über den VMware Converter vom Workstation (oder sonstige Quellen) ins ESX hineingebeamt werden. Im Konverter gibts ne Option "Auslagerungsdatei separat speichern", ist standardmäßig schon so eingestellt, daß dder im System vermerkte Datastore verwendet wird. Nur den muß man nachträglich ändern, wenn eine SSD hinzukommt.
Das ist nebenbei bemerkt die billigste Option, denn schon ein einzelndes 8 GB DDR2 Registered ECC Modul (für die Profimaschinen) kost mehr als eine 120er Enterprise Edition SSD von Intel.
Ich hab ne OCZ Vertex 240 GB aus einem toten Notebook ...
in den Rechner reingesteckt, ich hab ne Whitebox - da isses egal - an einen ICH9 SATA Port. ESX 4.1 und höher erkennen da Datastores, 3.5 nicht. Ich hab 4.1 gehabt, gerade auf 5.1 upgegraded. Wird also im VMware dann über "speicher" "speicher hinzufügen" mit 100 GB VMFS3 formatiert und "SSD" benannt.
scheinbar wichtig: alle VMs runtefahren. Dann Wartungsmodus einschalten.
Dann: Reiter Konfiguration, Erweitert (untere Hälfte) Speicherort der Auslagerungsdatei - rechts oben auf "bearbeiten" klicken, dann erscheint ne Dialogbox. Obere Option: "immer mit VM auf dem Datastore speichern wo die VM liegt" und "Speicherort festlegen" mit einer Liste der VMFS formatierten Dateastores. Also die untere Radiobutton-Option auswählen, "SSD" auswählen, dann auf ok klicken. Wartungsmodus ausschalten.
Bei neu angelegten VMs wird diese Einstellung dann wohl verwendet, auch bei allen, die über den VMware Converter vom Workstation (oder sonstige Quellen) ins ESX hineingebeamt werden. Im Konverter gibts ne Option "Auslagerungsdatei separat speichern", ist standardmäßig schon so eingestellt, daß dder im System vermerkte Datastore verwendet wird. Nur den muß man nachträglich ändern, wenn eine SSD hinzukommt.
Das ist nebenbei bemerkt die billigste Option, denn schon ein einzelndes 8 GB DDR2 Registered ECC Modul (für die Profimaschinen) kost mehr als eine 120er Enterprise Edition SSD von Intel.
