Hallo,
weiß jemand von euch ob und wenn wie man ein VMFS Volume defragmentiert bzw. den Fragmentierungsstatus abfragen kann. Oder defragmentiert man die VM Disken selber wie bei der Workstation (aber eigentlich nicht oder)? Eigentlich sollte hier ja nicht viel fragmentieren aber im Laufe der Jahre könnte es schon sein das hier eine signifikante Fragmentierung stattfindet.
Zumindest duch Erweiterungen von Disken und ggf. auch durch Snapshots.
Im Moment würde ich im Rahmen einer Wartung erst den Gast dann ggf. das VMFS Volume und zuletzt die Storage defragmentieren.
Gerne würde ich zu diesem Thema hier auch eine Diskussion anstoßen.
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!
Fragmentierungsfragen
Hallo,
ich verwende zwar keinen ESX, aber die VMs werden doch mit preallocated diskspace angelegt, d.h., das Problem der Fragmentierung kann höchstens innerhalb der VMs auftreten, und dazu hat das installierte OS Bordmittel, bzw. unter Linux wird es wahrscheinlich nie nötig sein zu defragmentieren, sofern du die virt. HDD bis max. 80 - 90% vollschreibst.
Gruß
Ronny
ich verwende zwar keinen ESX, aber die VMs werden doch mit preallocated diskspace angelegt, d.h., das Problem der Fragmentierung kann höchstens innerhalb der VMs auftreten, und dazu hat das installierte OS Bordmittel, bzw. unter Linux wird es wahrscheinlich nie nötig sein zu defragmentieren, sofern du die virt. HDD bis max. 80 - 90% vollschreibst.
Gruß
Ronny
Die Disken sind zwar preallocated aber es sind ja auch eine Menge Snapshots die ständig erstellt werden. Z.B. durch VCB. Außerdem vergrößert Man ja auch hier und da die Disken.
Ich meine sicherlich dürfte es hier aufgrund der großen Blöcke und eben durch preallocated Disken nicht sonderlich stark fragmentieren. Aber das es fragmentiert halte ich für logisch. Und da ich für mich das Thema durchgängig klären möchte versuche ich Informationen darüber zu bekommen.
Ich meine sicherlich dürfte es hier aufgrund der großen Blöcke und eben durch preallocated Disken nicht sonderlich stark fragmentieren. Aber das es fragmentiert halte ich für logisch. Und da ich für mich das Thema durchgängig klären möchte versuche ich Informationen darüber zu bekommen.
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
gibt es dazu irgendwo noch mehr Informationen?
Da es sich nicht um einen Linux-kernel handelt ist der vmnix Kernel auch kein Opensource sondern Closed-source.
Man findet nicht viel darueber.
Soviel ich weiss ist es ein monolithischer Kernel der alle Treiber integriert hat - deswegen kann man auch nicht mal so eben einen Treiber hinzufuegen.
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Hi,
beim VMFS muss man sich keine großen Gedanken machen um Fragmentierung.
Dadurch, dass ja mehrere VMs gleichzeitig (evtl. sogar noch von unterschiedlichen Servern) auf die gleichen Spindeln zugreifen, spielen die Zugriffe einer einzelnen VM keine wirkliche Rolle.
Der vmkernel ist so optimiert (und da steckt ein Großteil der Erfahrung / Knoff-Hoff der VMware-Leute drin, neben dem CPU-Sheduling und Memory-Management), dass das eben für alle VMs möglichst gut funktioniert.
Für Spezialfälle (hoch IO-intensive VM alleine auf einem Server/VMFS-Partition) gibts ein paar Parameter, an denen man schrauben kann, aber das macht man normal nur mit Hilfe vom VMware-Support.
Wen's näher interessiert:
http://www.vmware-tsx.com/download.php?asset_id=40
Viel Spaß
Viele Grüße,
Jörg
beim VMFS muss man sich keine großen Gedanken machen um Fragmentierung.
Dadurch, dass ja mehrere VMs gleichzeitig (evtl. sogar noch von unterschiedlichen Servern) auf die gleichen Spindeln zugreifen, spielen die Zugriffe einer einzelnen VM keine wirkliche Rolle.
Der vmkernel ist so optimiert (und da steckt ein Großteil der Erfahrung / Knoff-Hoff der VMware-Leute drin, neben dem CPU-Sheduling und Memory-Management), dass das eben für alle VMs möglichst gut funktioniert.
Für Spezialfälle (hoch IO-intensive VM alleine auf einem Server/VMFS-Partition) gibts ein paar Parameter, an denen man schrauben kann, aber das macht man normal nur mit Hilfe vom VMware-Support.
Wen's näher interessiert:
http://www.vmware-tsx.com/download.php?asset_id=40
Viel Spaß
Viele Grüße,
Jörg
Danke für die Infos. Vor allem der letzte Link ist sehr informativ.
Mir ist klar das VMFS hier ein anderes Verhalten hat als z.B. NTFS. Ich bin niemand der glaubt das es Filesysteme gäbe die nicht fragmentieren. Ich weiß halt gerne wie es wirklich aussieht. Wie eingangs schon gesagt ist es schwer Informationen zu bekommen, die wenigsten Leute machen sich überhaupt Gedanken darüber.
Wer hier defragmentiert überhaupt seine Gäste regelmäßig? Das tun doch auch die Wenigsten oder?
Mir ist klar das VMFS hier ein anderes Verhalten hat als z.B. NTFS. Ich bin niemand der glaubt das es Filesysteme gäbe die nicht fragmentieren. Ich weiß halt gerne wie es wirklich aussieht. Wie eingangs schon gesagt ist es schwer Informationen zu bekommen, die wenigsten Leute machen sich überhaupt Gedanken darüber.
Wer hier defragmentiert überhaupt seine Gäste regelmäßig? Das tun doch auch die Wenigsten oder?
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Weils eben keine so große Rolle mehr spielt. Normalerweise macht man das ja, damit beim Zugriff auf die Platten der Lese-/schreibkopf nicht so oft hin und her springen muss.
Da beim ESX der vmkernel sowieso die Anfragen aller VMs beachten muss, und das dann automatisch gut macht, spielt ne fragmentierte Platte einer VM keine Rolle mehr. (Gibt natürlich Ausnahmen und Extremfälle)
Und wenn Du ein Storage dahinterhängen hast, das dann auch noch mehrere LUNs auf den gleichen Platten hat, die von unterschiedlichen Servern genutzt werden, dann wirds gleich noch weniger wichtig, denn da muss das Storage System die einzelnen LEse-/Schreibvorgänge geschickt anordnen.
Drum macht defragmentierung in meinen Augen nur auf workstations/nicht virtualisieruten Servern Sinn, die lokale Platten haben, und bei denen das Betriebssystem wirklich direkt die Hardware steuert bei den Plattenzugriffen.
edit: Ach ja, aufpassen beim ESX mit defragmentierung, wenn man mit Snapshots arbeitet, sonst sieht man ganz gut und schnell, warum die so gefährlich sind P)
Viele Grüße,
Jörg
Da beim ESX der vmkernel sowieso die Anfragen aller VMs beachten muss, und das dann automatisch gut macht, spielt ne fragmentierte Platte einer VM keine Rolle mehr. (Gibt natürlich Ausnahmen und Extremfälle)
Und wenn Du ein Storage dahinterhängen hast, das dann auch noch mehrere LUNs auf den gleichen Platten hat, die von unterschiedlichen Servern genutzt werden, dann wirds gleich noch weniger wichtig, denn da muss das Storage System die einzelnen LEse-/Schreibvorgänge geschickt anordnen.
Drum macht defragmentierung in meinen Augen nur auf workstations/nicht virtualisieruten Servern Sinn, die lokale Platten haben, und bei denen das Betriebssystem wirklich direkt die Hardware steuert bei den Plattenzugriffen.
edit: Ach ja, aufpassen beim ESX mit defragmentierung, wenn man mit Snapshots arbeitet, sonst sieht man ganz gut und schnell, warum die so gefährlich sind P)
Viele Grüße,
Jörg
Na ja, aber man hat ja mehrere ESX Server die mitunter die selben LUN´s nutzen. Hier greift jedenfalls diese Ominöse Logik nicht.
Ich meine ich weiß schon was du meinst, aber so richtig schlüssig ist das für mich nicht. Klar spielt es nicht DIE Rolle, aber so ganz ohne kann´s auch nicht sein.
Das mit den Snapshots ist klar, die sind gefährlich. Aber mir Snapshots arbeitet man auch nicht, es gibt nur einen Grund und das ist VCB. Alles andere ist ja schon fast fahrlässig.
Ich meine ich weiß schon was du meinst, aber so richtig schlüssig ist das für mich nicht. Klar spielt es nicht DIE Rolle, aber so ganz ohne kann´s auch nicht sein.
Das mit den Snapshots ist klar, die sind gefährlich. Aber mir Snapshots arbeitet man auch nicht, es gibt nur einen Grund und das ist VCB. Alles andere ist ja schon fast fahrlässig.
altes Thema gleiche fragen
Wir sind auch gerade wieder mal mit dem Thema beschäftigt was soll in einer virtuellen ESX Umgebung defragmentiert werden.
Die Gäste laufen ja auf dem VMFS System so gesehen aneinanderhängend in einer Datei. Spielt es nun eine Rolle ob das OS seine Daten hintereinander angelegt lesen muss oder in der virtuellen Disk zusammen suchen muss?
Gibt es da erfahrungswerte?
Die nächste Frage ist eine bereits hier besprochene jedoch nicht abgeschlossene:
der Host legte bei ESX die volle Kapazität einer virtuellen Disk an. Was passiert nun, wenn man so eine Disk vergrössert wenn davor bereits eine weiteres VM erstellt worden ist?
Wenn diese frage ein VMWare Spezi beantworten könnte würde dies sicher vielen Personen Licht ins Dunkle bringen.
Die Gäste laufen ja auf dem VMFS System so gesehen aneinanderhängend in einer Datei. Spielt es nun eine Rolle ob das OS seine Daten hintereinander angelegt lesen muss oder in der virtuellen Disk zusammen suchen muss?
Gibt es da erfahrungswerte?
Die nächste Frage ist eine bereits hier besprochene jedoch nicht abgeschlossene:
der Host legte bei ESX die volle Kapazität einer virtuellen Disk an. Was passiert nun, wenn man so eine Disk vergrössert wenn davor bereits eine weiteres VM erstellt worden ist?
Wenn diese frage ein VMWare Spezi beantworten könnte würde dies sicher vielen Personen Licht ins Dunkle bringen.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
hier mal meine 10 Cent's zu diesem Thema.
Fragmentierte Filesysteme werden meines Erachtens überbewertet, sobald man die Desktop Welt verläßt.
Dies trifft erst recht zu, wenn man sich in die VMware ESX Welt begibt.
ESX Server sind für produktive Umgebungen gedacht, in denen durch Konsolidierung eine Vielzahl von Hostsystemen ersetzt werden sollen.
Somit reden wir eigentlich davon, das ein ESX Server die IO Last von z.B. 10 - 15 klassischen Servern bedienen muß bzw. produziert.
Nun nehmen wir noch einen ESX Cluster aus 4 ESX Servern, dann ist man schnell bei ca 40 - 60 VM's, die ihren IO Bedarf über diese 4 Server abwickeln.
Nun kommt jedoch schon der erste wichtige Unterschied zur "alten" Welt.
Die "alten" Server verfügten normalerweise über dedizierte Platten, und meistens waren es mehrere.
Nehmen wir hier einfach mal 3 Platten pro System an, dann kommen wir auf ca. 150 LUN's.
Die wenigsten von euch dürften jedoch in Ihrer ESX Welt bei ca. 50 VM's 150 LUN's im Zugriff haben, ich vermute mal eher maximal um die 30 LUN's.
Damit hat nun eine LUN/Datastore die IO Anfragen von mehreren unterschiedlichen VM's zu bearbeiten, welche dann auch noch über unterschiedliche Kanäle eingekippt werden können, je nachdem, auf welchem ESX Server die VM denn gerade läuft.
Somit werden VMFS Datastores ohnehin fast ausschließlich einen random IO Workload zu bedienen haben, weil ja alle VM's völlig unabhängig voneinander ihre Requests plazieren können.
Da alle modernen Storage Arrays über einen mehr oder weniger großen Cache verfügen, sollte ein Großteil der IO Requests durch den Cache beantwortet werden, zumindest trifft dies für alle Writes zu.
Wann das Array die Daten dann wirklich auf die physikalischen Platten schreibt, ist für die angeschlossenen Server völlig transparent.
Somit reden wir hier darüber, das ESX Server fast ausschließlich random IO generieren und dieser vom verwendeten Array beantwortet werden muß.
Und daher ist es dem Array meistens egal, ob die Daten auf seinen LUN's fragmentiert sind oder nicht, es muß ohnehin Random IO's bedienen.
Die entscheidende Aufgabe ist daher eigentlich, beim Design der Umgebung darauf zu achten, es für die erwartete Last entsprechend zu dimensionieren.
Und dabei sollte man nicht die Kennzahlen der verwendeten Disks für sequentielle IO's verwenden, sondern die für Random IO's.
Leider sind diese Werte schlechter und damit nehmen Sales und Consultant Leute lieber die höheren Werte, weil das gut für die Projektkosten ist.
Und nach dem Abschluß ist dann der Support gefragt und die Herren sind zum Segeln in der Karibik verschwunden.
Kurz zusammen gefasst, wenn sich mehrere VM's ein und dieselbe LUN teilen, braucht man sich um Filesystem Fragmentierungen keinerlei Gedanken mehr machen.
Nur auf das Alignment der Filesysteme ist zu achten, sonst müssen die Arrays eventuell 10-15% mehr IO's als nötig bearbeiten.
Freue mich schon auf eure Anmerkungen.
Gruß
Ralf
hier mal meine 10 Cent's zu diesem Thema.
Fragmentierte Filesysteme werden meines Erachtens überbewertet, sobald man die Desktop Welt verläßt.
Dies trifft erst recht zu, wenn man sich in die VMware ESX Welt begibt.
ESX Server sind für produktive Umgebungen gedacht, in denen durch Konsolidierung eine Vielzahl von Hostsystemen ersetzt werden sollen.
Somit reden wir eigentlich davon, das ein ESX Server die IO Last von z.B. 10 - 15 klassischen Servern bedienen muß bzw. produziert.
Nun nehmen wir noch einen ESX Cluster aus 4 ESX Servern, dann ist man schnell bei ca 40 - 60 VM's, die ihren IO Bedarf über diese 4 Server abwickeln.
Nun kommt jedoch schon der erste wichtige Unterschied zur "alten" Welt.
Die "alten" Server verfügten normalerweise über dedizierte Platten, und meistens waren es mehrere.
Nehmen wir hier einfach mal 3 Platten pro System an, dann kommen wir auf ca. 150 LUN's.
Die wenigsten von euch dürften jedoch in Ihrer ESX Welt bei ca. 50 VM's 150 LUN's im Zugriff haben, ich vermute mal eher maximal um die 30 LUN's.
Damit hat nun eine LUN/Datastore die IO Anfragen von mehreren unterschiedlichen VM's zu bearbeiten, welche dann auch noch über unterschiedliche Kanäle eingekippt werden können, je nachdem, auf welchem ESX Server die VM denn gerade läuft.
Somit werden VMFS Datastores ohnehin fast ausschließlich einen random IO Workload zu bedienen haben, weil ja alle VM's völlig unabhängig voneinander ihre Requests plazieren können.
Da alle modernen Storage Arrays über einen mehr oder weniger großen Cache verfügen, sollte ein Großteil der IO Requests durch den Cache beantwortet werden, zumindest trifft dies für alle Writes zu.
Wann das Array die Daten dann wirklich auf die physikalischen Platten schreibt, ist für die angeschlossenen Server völlig transparent.
Somit reden wir hier darüber, das ESX Server fast ausschließlich random IO generieren und dieser vom verwendeten Array beantwortet werden muß.
Und daher ist es dem Array meistens egal, ob die Daten auf seinen LUN's fragmentiert sind oder nicht, es muß ohnehin Random IO's bedienen.
Die entscheidende Aufgabe ist daher eigentlich, beim Design der Umgebung darauf zu achten, es für die erwartete Last entsprechend zu dimensionieren.
Und dabei sollte man nicht die Kennzahlen der verwendeten Disks für sequentielle IO's verwenden, sondern die für Random IO's.
Leider sind diese Werte schlechter und damit nehmen Sales und Consultant Leute lieber die höheren Werte, weil das gut für die Projektkosten ist.
Und nach dem Abschluß ist dann der Support gefragt und die Herren sind zum Segeln in der Karibik verschwunden.
Kurz zusammen gefasst, wenn sich mehrere VM's ein und dieselbe LUN teilen, braucht man sich um Filesystem Fragmentierungen keinerlei Gedanken mehr machen.
Nur auf das Alignment der Filesysteme ist zu achten, sonst müssen die Arrays eventuell 10-15% mehr IO's als nötig bearbeiten.
Freue mich schon auf eure Anmerkungen.
Gruß
Ralf
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste