In den seligen Zeiten von HDDs war ja einer der Gründe für virtuelle Thick HDDs das diese schneller waren als THIN HDDs.
Nun halten SSDs vermehrt einzug unter ESXi und ich frage mich ob das noch gilt?
Meine Versuche mit VMs haben keine Geschwindigkeitseinbußen bei THIN HDDs ergeben.
Lese/Schreibraten von 450-550 MB/s sind auch da kein Problem.
Da SSDs aber immer noch deutlich kleiner/teurer sind als HDDs lohnt es sich gerade da sparsam mit dem Platz umzugehen.
Wie sehen die Profis das? Gibt es noch Gründe warum man doch auf THIN verzichten sollte?
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!
Grundsatzfrage: Thin versus Thick in Zeiten der SSDs
Bin zwar kein "richtiger" Profi aber ich habe keine Probleme feststellen können mit Thin.
Habe aktuell eine kleine Umgebung seit nem halben Jahr im Einsatz welche komplett auf SSD's basisert. Verwendet habe ich dafür ein paar 480GB 520er Discs von Intel. Storage läuft in Form einer Windows 2012 VM welcher unter anderem nen Software-RAID 10 über die SSD's via den Storage-Spaces macht . ESXi verbindet sich auf die VM via NFS. Zusätzlich habe ich Dedupe aktiviert was nochmals einiges an Daten spart.
Die Performance ist imho Grandios im Verhältniss zu den Kosten. Der Kunde ist immer noch begeistert und ich kotze ebenfals noch immer wenn ichs mit meiner SAN vergleiche (12x15k SAS, 4x 1gbit iSCSI pro Server). Auch wenn diese etwas sicherer sein dürfte dank DualController Hardware RAID. Aber sie ist extrem Resistent wie ich finde, im Vorfeld habe ich allerlei Crashes provoziert (Stromausfälle, Hardware abkoppeltn, SSD's entfernen etc.) und nie korrupte Daten gehabt. Die VM's auf diesem ESXi werden regelmässig auf den anderen ESXi kopiert + Fullbackups gezogen.
Das nächste Projekt (Meine View-Umgebung) wird mit einer PCI-Express Karte von Micron realisiert. Einer der wenige, der nicht den weg über eine SAS/SATA-Bridge geht, sondern direkt auf PCI-Express. Die Leistung ist wirklich extrem. Da ist obiges grad wieder Kinderkram. Hauptvorteil: ESXi, Windows etc. sieht die Disc als ein Stück und braucht keinen Software-RAID-Treiber wie zbsp. bei Intel 910.
Entweder einer p320 mit slc's oder der p420 mit MLC Basis. Read Iops (4k random, (komprimierbar oder nicht macht bei denen keinen Unterschied) machen bei weit über 700'000, Write die 420er stabil bei 100'000, die 320er rund das doppelte. Die SLC mit unglaublich tiefer latency fast ohne Ausreisser. Intern arbeiten sie mit diversen Error-Correction Funktionen sowie Kondis für Stromaufälle-Pufferung (MLC).
Klar, die Teile sind nicht günstig, vor allem in Europa wollen sie fast 30% mehr als in den USA, aber die Teile sind so übelst schnell, da wird mir sogar ein Performance-Impact via Windows Server 2012 total egal sein.
Habe aktuell eine kleine Umgebung seit nem halben Jahr im Einsatz welche komplett auf SSD's basisert. Verwendet habe ich dafür ein paar 480GB 520er Discs von Intel. Storage läuft in Form einer Windows 2012 VM welcher unter anderem nen Software-RAID 10 über die SSD's via den Storage-Spaces macht . ESXi verbindet sich auf die VM via NFS. Zusätzlich habe ich Dedupe aktiviert was nochmals einiges an Daten spart.
Die Performance ist imho Grandios im Verhältniss zu den Kosten. Der Kunde ist immer noch begeistert und ich kotze ebenfals noch immer wenn ichs mit meiner SAN vergleiche (12x15k SAS, 4x 1gbit iSCSI pro Server). Auch wenn diese etwas sicherer sein dürfte dank DualController Hardware RAID. Aber sie ist extrem Resistent wie ich finde, im Vorfeld habe ich allerlei Crashes provoziert (Stromausfälle, Hardware abkoppeltn, SSD's entfernen etc.) und nie korrupte Daten gehabt. Die VM's auf diesem ESXi werden regelmässig auf den anderen ESXi kopiert + Fullbackups gezogen.
Das nächste Projekt (Meine View-Umgebung) wird mit einer PCI-Express Karte von Micron realisiert. Einer der wenige, der nicht den weg über eine SAS/SATA-Bridge geht, sondern direkt auf PCI-Express. Die Leistung ist wirklich extrem. Da ist obiges grad wieder Kinderkram. Hauptvorteil: ESXi, Windows etc. sieht die Disc als ein Stück und braucht keinen Software-RAID-Treiber wie zbsp. bei Intel 910.
Entweder einer p320 mit slc's oder der p420 mit MLC Basis. Read Iops (4k random, (komprimierbar oder nicht macht bei denen keinen Unterschied) machen bei weit über 700'000, Write die 420er stabil bei 100'000, die 320er rund das doppelte. Die SLC mit unglaublich tiefer latency fast ohne Ausreisser. Intern arbeiten sie mit diversen Error-Correction Funktionen sowie Kondis für Stromaufälle-Pufferung (MLC).
Klar, die Teile sind nicht günstig, vor allem in Europa wollen sie fast 30% mehr als in den USA, aber die Teile sind so übelst schnell, da wird mir sogar ein Performance-Impact via Windows Server 2012 total egal sein.
-
Dayworker
- King of the Hill
- Beiträge: 13657
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Kleiner Rundumschlag zum Thema SSD und Thin/Thick-VMDK...
Von Seiten der Geschwindigkeit sind SSDs eine Offenbarung, während Thin-Disks nicht unnötig freien Platz belegen. Problematisch an SSDs sind deren immer wieder auftretende Firmwareprobleme, während Thin-VMDKs genau hinsichtlich freien Platz im DS und Fragmentierung beobachtet werden müssen. Bedingt durch die Fragmentierung dürfte es mit Thin-VMDKs auch wesentlich schwerer werden, im Ernstfall noch irgendwelche Daten zu retten. Aber die Chance dürfte auf einer SSD sowieso gegen Null gehen, da durch das Wear-Levelling kein direkter Bezug zwischen gemeldeten physikalischen Sektoren einer SSD ans OS und dem Speicherblock der Daten innerhalb jeder SSD besteht.
Bezüglich des Geschwindigkeitsunterschieds zwischen Thin und Thick gibt es diesen angeblich unter VMFS5 nicht mehr. Allerdings ist das VMFS auch nicht ganz frei von Problemen und viele trauen NTFS, EXT3/4 oder ZFS weit mehr über den Weg, zumal man dort wenigstens richtige Tools an der Hand hat, die Probleme auch lösen können. Das VMFS kann man ja inzwischen zwar überprüfen, die Reparatur ist aber weiterhin nicht möglich. Als Ausweg bleiben wie gehabt nur die VMDKs zu clonen und/oder den DS neu anzulegen.
Von Seiten der Geschwindigkeit sind SSDs eine Offenbarung, während Thin-Disks nicht unnötig freien Platz belegen. Problematisch an SSDs sind deren immer wieder auftretende Firmwareprobleme, während Thin-VMDKs genau hinsichtlich freien Platz im DS und Fragmentierung beobachtet werden müssen. Bedingt durch die Fragmentierung dürfte es mit Thin-VMDKs auch wesentlich schwerer werden, im Ernstfall noch irgendwelche Daten zu retten. Aber die Chance dürfte auf einer SSD sowieso gegen Null gehen, da durch das Wear-Levelling kein direkter Bezug zwischen gemeldeten physikalischen Sektoren einer SSD ans OS und dem Speicherblock der Daten innerhalb jeder SSD besteht.
Bezüglich des Geschwindigkeitsunterschieds zwischen Thin und Thick gibt es diesen angeblich unter VMFS5 nicht mehr. Allerdings ist das VMFS auch nicht ganz frei von Problemen und viele trauen NTFS, EXT3/4 oder ZFS weit mehr über den Weg, zumal man dort wenigstens richtige Tools an der Hand hat, die Probleme auch lösen können. Das VMFS kann man ja inzwischen zwar überprüfen, die Reparatur ist aber weiterhin nicht möglich. Als Ausweg bleiben wie gehabt nur die VMDKs zu clonen und/oder den DS neu anzulegen.
-
irix
- King of the Hill
- Beiträge: 13058
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Die Annahmen und Gruende fuer oder Gegen Thin/Thick hier sind falsch bzw. der Kontext ist unvollstaendig.
- Aenderungen/Erstellen von Dateien auf dem VMFS fuehren zu arbeiten an den Metadaten und somit zu einem Lock des kompletten Volumes. Das haben Thin und Snapshots nunmal so ansich im VMware Umfeld
- Ist kein Platz mehr auf dem Volume so stuerzen alle Thin und VMs mit Snapshots ab
- Die Initialisierung von noch nicht beschriebenen Speicher auf Nicht EagerZeroThink VMDKs kostet ein wenig Zeit
- Im Windows Umfelds ist das vergroessern von VMDKs/Filesystem extrem einfach, bei Linux etwas schwieriger und bei Appliances mangels Root Shell manchmal unmoeglich
- Die Anzahl von VMs auf SSD im Vergleich HDD unterscheiden sich nicht und Thin/Thick spielt her keine Rolle
Jenach dem wie man das bewertet bzw. was man an Mitteln dagegen auffaehrt entscheidet man sich. Ob nun HDD oder SSD spielt hier keine Rolle.
Gruss
Joerg
- Aenderungen/Erstellen von Dateien auf dem VMFS fuehren zu arbeiten an den Metadaten und somit zu einem Lock des kompletten Volumes. Das haben Thin und Snapshots nunmal so ansich im VMware Umfeld
- Ist kein Platz mehr auf dem Volume so stuerzen alle Thin und VMs mit Snapshots ab
- Die Initialisierung von noch nicht beschriebenen Speicher auf Nicht EagerZeroThink VMDKs kostet ein wenig Zeit
- Im Windows Umfelds ist das vergroessern von VMDKs/Filesystem extrem einfach, bei Linux etwas schwieriger und bei Appliances mangels Root Shell manchmal unmoeglich
- Die Anzahl von VMs auf SSD im Vergleich HDD unterscheiden sich nicht und Thin/Thick spielt her keine Rolle
Jenach dem wie man das bewertet bzw. was man an Mitteln dagegen auffaehrt entscheidet man sich. Ob nun HDD oder SSD spielt hier keine Rolle.
Gruss
Joerg
irix hat geschrieben:- Aenderungen/Erstellen von Dateien auf dem VMFS fuehren zu arbeiten an den Metadaten und somit zu einem Lock des kompletten Volumes. Das haben Thin und Snapshots nunmal so ansich im VMware Umfeld
- Ist kein Platz mehr auf dem Volume so stuerzen alle Thin und VMs mit Snapshots ab
Und ohne Snapshots?
- Die Initialisierung von noch nicht beschriebenen Speicher auf Nicht EagerZeroThink VMDKs kostet ein wenig Zeit
In der Praxis wohl verbnachlassigbar.
- Im Windows Umfelds ist das vergroessern von VMDKs/Filesystem extrem einfach, bei Linux etwas schwieriger und bei Appliances mangels Root Shell manchmal unmoeglich
Soll ich mir bei jeder VM vorher genau überlegen wieviel Speicher sie benötigt und dann bei jeder Programm installation manuell vergößern? Das ist für mich viel zu unpraktischl.
- Die Anzahl von VMs auf SSD im Vergleich HDD unterscheiden sich nicht und Thin/Thick spielt her keine Rolle
Verstehe ich nicht. In der Realität habe ich nur ein begrenztes Budget und daher z. B. eine SSD mit 256 GB und eine HDD mit 2 TB zur Auswahl. Nun kann ich mir überlegen wohin ich die VMs speichere. Mit thin kann ich alle auf die SSD packen und habe vielleicht noch 50 GB frei die als Reserve allen thin Vms zur Verfügung steht bei Bedarf.
Sehe ich eher so wie eine Überprovisionierung wie beim RAM ohne Sicherheitnetz. Klar muss ich den freien Speicherplatz im Auge behalten und mit Pech gehts vielleicht schief. Aber die Alternative die VMs als Thick auf die HDD zu packen ist halt VIEL lahmer. Unterm Srtrich sehe ich ein kalkulierbares erhöhtes Risiko aber dafür eine gewaltigen Geschwindigkeitssteigerung.
-
irix
- King of the Hill
- Beiträge: 13058
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Wirrkopf hat geschrieben:irix hat geschrieben:- Aenderungen/Erstellen von Dateien auf dem VMFS fuehren zu arbeiten an den Metadaten und somit zu einem Lock des kompletten Volumes. Das haben Thin und Snapshots nunmal so ansich im VMware Umfeld
- Ist kein Platz mehr auf dem Volume so stuerzen alle Thin und VMs mit Snapshots ab
Und ohne Snapshots?
Macht keinen Unterschied. Wenn eine VMDK sich nicht erweitern kann geht die VM aus.
- Die Initialisierung von noch nicht beschriebenen Speicher auf Nicht EagerZeroThink VMDKs kostet ein wenig Zeit
In der Praxis wohl verbnachlassigbar.- Im Windows Umfelds ist das vergroessern von VMDKs/Filesystem extrem einfach, bei Linux etwas schwieriger und bei Appliances mangels Root Shell manchmal unmoeglich
Soll ich mir bei jeder VM vorher genau überlegen wieviel Speicher sie benötigt und dann bei jeder Programm installation manuell vergößern? Das ist für mich viel zu unpraktischl.- Die Anzahl von VMs auf SSD im Vergleich HDD unterscheiden sich nicht und Thin/Thick spielt her keine Rolle
Verstehe ich nicht. In der Realität habe ich nur ein begrenztes Budget und daher z. B. eine SSD mit 256 GB und eine HDD mit 2 TB zur Auswahl.
Hier wuerde annaehernd die gleiche Anzahl drauf passen da hier ein waches Auge vorhanden ist.
Nun kann ich mir überlegen wohin ich die VMs speichere. Mit thin kann ich alle auf die SSD packen und habe vielleicht noch 50 GB frei die als Reserve allen thin Vms zur Verfügung steht bei Bedarf.
Sehe ich eher so wie eine Überprovisionierung wie beim RAM ohne Sicherheitnetz. Klar muss ich den freien Speicherplatz im Auge behalten und mit Pech gehts vielleicht schief. Aber die Alternative die VMs als Thick auf die HDD zu packen ist halt VIEL lahmer. Unterm Srtrich sehe ich ein kalkulierbares erhöhtes Risiko aber dafür eine gewaltigen Geschwindigkeitssteigerung.
Es haelt dich keiner davon ab. Du hast nur eine Grundsatzfrage gestellt aber die falschen Argumente.
Gruss
Joerg
SSD und Thin: Halte mich da eher an: Wo VMFS verwendet wird, verwende ich immer Thick und Eager-Zeroed. Also weniger SSD sondern eher Filesystem abhängig.
Begrenztes Budget: Da wäre ich je nach Definition von günstig bei SSD's noch deutlich vorsichtiger als bei HDD's. Geht dann schnell mal in die Richtung Grobfahrlässig. Wie von Dayworker angemerkt, stabile Firmware ist essentiell und da gibts sehr sehr viel Schrott bzw. nicht viele Hersteller die hier wirklich als zuverlässig zu betiteln sind. Billig sind keine dieser Laufwerke. Preiswert im Sinne von Preis für Leistung und Qualität ist eher was man will.
Je nach Szenario das man abdecken möchte ist auch die Alterung der SSD sehr relevant. Datenbank mit sehr viel Writes können Dir in 0,Nix eine SSD ins Grab schicken. Daran kranken teilweise auch ziemlich teure SSD auf MLC-Basis.
Verwendung von Thin wegen effektivem platzsparen halt ich für den falschen Weg (Unter Windows). Grund wurde bereits genannt, Abschiessen mit nem simplen Script oder Defrag der ganzen Umgebung. Festplatten unter Windows sind sehr easy erweitert.
Praktisch an Thin oder eher restriktiv vergebenem Platz ist aber, dass man kurz temporäre Umgebungen innerhalb der produktiven Umgebung hochziehen und wieder abschiessen kann. Nach dem abschiessen ist der Platz wieder für die Thins der produktiven frei.
Bei Verwendung von MLC und preiswerten Consumer-Modellen würde ich sogar den umgekehrten Weg gehen. Deutlich zu viel Platz um quasi selber ein Overprovisioning zu erreichen. Auch Trim hätte ich unter Umständen gerne an Bord. --> Storage VM, weil ESXi kein Trim unterstützt. Dafür sind Datenrettungen auf Filesystem-Level nach dem Löschen unmöglich. Halt alles Dinge die man berücksichtigen muss.
Wie bei allem, es gibt viele Wege nach Rom. Ebenso kann man auf viele Arten 'basteln'.
- Entweder man kauft sich eine möglichst Sorgloslösung, in diesem Falle also ein fertiges Storage mit Support und allem drum und drann von einem Systemanbieter mit der Leistung die man gerne hätte. Unter Umtänden müssen die Ansprüche eben massiv der Geldbörse angepasst werden.
- man bastelt auf hohem Niveau mit Hirn und Komponenten von Systemanbietern oder solchen die von den Systemanbieter auch verwendet werden aber zbsp. für den x-fachen Preis verkauft werden. Nimmt ein paar Einschränkungen in Kauf, ist sich dem Risiko voll bewusst und hält entsprechende Massnahmen bereit. (Überwachung, Top-Dokumentierung mit HowTo's, Ersatzteile, DR-Management usw.). In der Regel braucht das eben ne Menge Recherchier- und Testarbeit. Je nach Anforderung kann das aber dennoch deutlich günstiger und genauso sicher und schneller sein.
- man nimmt einfach Consumer-Ware und bastelt sich irgendwas zusammen freut sich über Performance und das gesparte Geld und heult dann rum wenns kaputt geht oder keine Ersatzteile verfügbar sind
Begrenztes Budget: Da wäre ich je nach Definition von günstig bei SSD's noch deutlich vorsichtiger als bei HDD's. Geht dann schnell mal in die Richtung Grobfahrlässig. Wie von Dayworker angemerkt, stabile Firmware ist essentiell und da gibts sehr sehr viel Schrott bzw. nicht viele Hersteller die hier wirklich als zuverlässig zu betiteln sind. Billig sind keine dieser Laufwerke. Preiswert im Sinne von Preis für Leistung und Qualität ist eher was man will.
Je nach Szenario das man abdecken möchte ist auch die Alterung der SSD sehr relevant. Datenbank mit sehr viel Writes können Dir in 0,Nix eine SSD ins Grab schicken. Daran kranken teilweise auch ziemlich teure SSD auf MLC-Basis.
Verwendung von Thin wegen effektivem platzsparen halt ich für den falschen Weg (Unter Windows). Grund wurde bereits genannt, Abschiessen mit nem simplen Script oder Defrag der ganzen Umgebung. Festplatten unter Windows sind sehr easy erweitert.
Praktisch an Thin oder eher restriktiv vergebenem Platz ist aber, dass man kurz temporäre Umgebungen innerhalb der produktiven Umgebung hochziehen und wieder abschiessen kann. Nach dem abschiessen ist der Platz wieder für die Thins der produktiven frei.
Bei Verwendung von MLC und preiswerten Consumer-Modellen würde ich sogar den umgekehrten Weg gehen. Deutlich zu viel Platz um quasi selber ein Overprovisioning zu erreichen. Auch Trim hätte ich unter Umständen gerne an Bord. --> Storage VM, weil ESXi kein Trim unterstützt. Dafür sind Datenrettungen auf Filesystem-Level nach dem Löschen unmöglich. Halt alles Dinge die man berücksichtigen muss.
Wie bei allem, es gibt viele Wege nach Rom. Ebenso kann man auf viele Arten 'basteln'.
- Entweder man kauft sich eine möglichst Sorgloslösung, in diesem Falle also ein fertiges Storage mit Support und allem drum und drann von einem Systemanbieter mit der Leistung die man gerne hätte. Unter Umtänden müssen die Ansprüche eben massiv der Geldbörse angepasst werden.
- man bastelt auf hohem Niveau mit Hirn und Komponenten von Systemanbietern oder solchen die von den Systemanbieter auch verwendet werden aber zbsp. für den x-fachen Preis verkauft werden. Nimmt ein paar Einschränkungen in Kauf, ist sich dem Risiko voll bewusst und hält entsprechende Massnahmen bereit. (Überwachung, Top-Dokumentierung mit HowTo's, Ersatzteile, DR-Management usw.). In der Regel braucht das eben ne Menge Recherchier- und Testarbeit. Je nach Anforderung kann das aber dennoch deutlich günstiger und genauso sicher und schneller sein.
- man nimmt einfach Consumer-Ware und bastelt sich irgendwas zusammen freut sich über Performance und das gesparte Geld und heult dann rum wenns kaputt geht oder keine Ersatzteile verfügbar sind
UrsDerBär hat geschrieben:SSD und Thin:
Verwendung von Thin wegen effektivem platzsparen halt ich für den falschen Weg (Unter Windows). Grund wurde bereits genannt, Abschiessen mit nem simplen Script oder Defrag der ganzen Umgebung. Festplatten unter Windows sind sehr easy erweitert.
So viel zu Theorie. Das klappt aber nur wenn man reale Anforderungen erhält. In meiner Umgebung ist es leider so, dass ein Großteil der Ressourceanfoderungen deutlich zu groß gestellt werden. D.h. die Leute wollen eine VM mit 2 TB vDisks und sie bekommen sie auch, weil sich niemand traut ein Projekt in Gefahr zu bringen oder die Empfehlungen der Softwareherstelller in Frage zu stellen.
Nach den letzten Statistiken haben wir 108 TB Datastores, 140 TB sind an VMs vergeben (inzwischen thick + thin VMDKs, je nach Cluster) und in den OS sind davon nur 53 TB belegt. Ideal wäre es wenn wir thin direkt im Storage machen würden, aber das geht aus politischen Gründen auch nicht.
Die einzige Lösung um zu sparen sind dann doch wieder thin vDisks. Mit den möglichen Nachteilen.
continuum hat geschrieben:Gibt es noch Gründe warum man doch auf THIN verzichten sollte?
Wenn ein VMFS nicht mehr auslesbar ist kann ich dir thick vmdks retten - thin vmdks nicht
Die wichtigen Daten werden per Windows DFS replikation fast in Echtzeit auf eine zweite SSD gespiegelt und zusätzlich gebackupt. Wenn da eine SSDs kaputtgeht ist das kein Beinbruch.
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 23 Gäste