Guten Tag,
Bin neu hier und hab schon in etlichen anderen Foren nach Rat zu meinem Problem gefragt und nachgeschaut. Ich bin, was VmWare angeht, ziemlicher Neuling... deshalb verzeiht eventuelle Unwissenheit.
Wir haben hier zwei NAS-Speicher von Qnap. Beide hosten iSCSI-Targets. Problem bei der ganzen Sache ist, dass für jedes Target nur eine LUN über die volle Größe besteht. Da das UNMAP ja nicht funktioniert, wird beim verschieben oder löschen einer VM der Speicher nicht mehr freigegeben. Resultat daraus ist, dass eine von beiden vollgelaufen ist.
Wir haben hier noch ein altes Vmware System (ESXI 4.0) und ein neueres (5.5), beide greifen auf die gleichen Targets\LUN´s zu.
Nun bin ich schon fleißig am verschieben und hab das erste NAS rein theoretisch frei. Bevor ich jetzt aber das NAs wieder neu einrichte, wollte ich mal fragen wie man das am besten einrichtet ohne das jedes mal der Speicher vollläuft? Wie wird das normalerweise gehandhabt?
Ich weiß das man mit vmkftools wieder den Speicher freigeben kann... aber das möchte ich bei diesem instabilen System lieber nicht wagen.
Sofortzuweisung würde ja nicht mehr gehen... da für jede VM bereits eine VHDK besteht. Also müsste ich wahrscheinlich, mehere Kleinere LUN´s erstellen um bei Bedarf ein Volles LUN zu löschen und ein neues einzuruchten. oder??
Wäre nett wenn mir jemand eine Machete für mein geistiges Dickicht leihen könnte.
Danke im voraus.
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!
Probleme mit Thin-Provisioning
http://kb.vmware.com/selfservice/micros ... Id=2004155
Das sagt VM-WARE dazu.
Aber da du ja noch ein ESXI 4.0 System hast, sollte dein VMFS ja noch Version 3.xx sein.
Daher mein Tipp, soweit möglich:
in der betreffenden VM per SDelete -z driveletter dem Dateisystem sagen, was ungenutzt ist. Dann die VM ausschalten und ein verschieben der VM von einem auf den anderen Datastore. So Storage-VMotion vorhanden, müsste das auch live funktioniert.
Bei der Auwahl auf neuen Storage verschieben dann halt auswählen "nicht format" übernehmen sodern thin auswählen.
Damit sollten die VMDK's auf dem Zielstorage nur die benötigte Größe haben.
Alternativ: Über die QNAP Speicher per NFS freigeben. Das ist immer thin. Und nach der "Sdelete" Behandlung werden die dort auch nur mit der nötigen Größe angelegt.
Also : Dein verschieben ist gut und schön, nur ohne das Sdelete sinnlos.
EDIT: Du schreibst, beim löschen einer VM wird der Platz nicht freigegeben?! Ist das richtig so gemeint? oder meist du beim löschen/Kopieren von Dateien in der VM? > Dafür das Sdelete und anschließende SVmotion.
Un für das volllaufen des storage solltest du das vcenter monitoren lassen sowie die HDD der VM's, wenn du schon mit thin arbeitest, nur so groß wie nötig anzulegen. Im Nachgang per Vcenter die HDD vergrößern geht immer. Nur eine 500GB VM wieder auf 50GB zu verkleinern geht nur per Converter. (Also die Festlegung der virtuellen HDD Größe)
Das sagt VM-WARE dazu.
Aber da du ja noch ein ESXI 4.0 System hast, sollte dein VMFS ja noch Version 3.xx sein.
Daher mein Tipp, soweit möglich:
in der betreffenden VM per SDelete -z driveletter dem Dateisystem sagen, was ungenutzt ist. Dann die VM ausschalten und ein verschieben der VM von einem auf den anderen Datastore. So Storage-VMotion vorhanden, müsste das auch live funktioniert.
Bei der Auwahl auf neuen Storage verschieben dann halt auswählen "nicht format" übernehmen sodern thin auswählen.
Damit sollten die VMDK's auf dem Zielstorage nur die benötigte Größe haben.
Alternativ: Über die QNAP Speicher per NFS freigeben. Das ist immer thin. Und nach der "Sdelete" Behandlung werden die dort auch nur mit der nötigen Größe angelegt.
Also : Dein verschieben ist gut und schön, nur ohne das Sdelete sinnlos.
EDIT: Du schreibst, beim löschen einer VM wird der Platz nicht freigegeben?! Ist das richtig so gemeint? oder meist du beim löschen/Kopieren von Dateien in der VM? > Dafür das Sdelete und anschließende SVmotion.
Un für das volllaufen des storage solltest du das vcenter monitoren lassen sowie die HDD der VM's, wenn du schon mit thin arbeitest, nur so groß wie nötig anzulegen. Im Nachgang per Vcenter die HDD vergrößern geht immer. Nur eine 500GB VM wieder auf 50GB zu verkleinern geht nur per Converter. (Also die Festlegung der virtuellen HDD Größe)
Innerhalb der VM geht das löschen. Aber wenn ich eine vorhandene VM von der Festplatte löschen will. Dann bleibt der Speicher trotzdem belegt.
Storage-vMotion ist leider nicht vorhanden. Ich hab die Dateien mit der Option "Migrieren" von einem Target auf das andere Target gepackt. Reicht das nicht?
Ich muss sowieso das NAS neu einrichten... aus irgendeinem Grund hat man damals nur 3 Platten verwendet und diese im RAID 5 konfiguriert. Die anderen Sind inaktiv und machen garnichts.
Gäbe es einen Nachteil bei der Verwendung von NFS? Oder eventuell gar einen Vorteil?
Andere Frage zwischendruch: Wie bekomme ich vmkdump und vsantraces von dem alten NAS runter? Benötigt man diese überhaupt? Ich kann die LUN´s nicht löschen bevor diese noch drauf sind.
Storage-vMotion ist leider nicht vorhanden. Ich hab die Dateien mit der Option "Migrieren" von einem Target auf das andere Target gepackt. Reicht das nicht?
Ich muss sowieso das NAS neu einrichten... aus irgendeinem Grund hat man damals nur 3 Platten verwendet und diese im RAID 5 konfiguriert. Die anderen Sind inaktiv und machen garnichts.
Gäbe es einen Nachteil bei der Verwendung von NFS? Oder eventuell gar einen Vorteil?
Andere Frage zwischendruch: Wie bekomme ich vmkdump und vsantraces von dem alten NAS runter? Benötigt man diese überhaupt? Ich kann die LUN´s nicht löschen bevor diese noch drauf sind.
continuum hat geschrieben:> Gäbe es einen Nachteil bei der Verwendung von NFS? Oder eventuell gar einen Vorteil?
Aus meiner Erfahrung ist die deutlich erhöhte Datensicherheit bei NFS so viel wert, dass alle eventuellen anderen Nachteile von NFS mehr als ausgeglichen werden.
Hätte ich bei NFS dasselbe Problem wie bei iSCSI, dass beim löschen einer VM danach immer noch der Speicher belegt wird?
Auf welcher Oberflaeche meinst Du jetzt?
Zumindest ICH verstehe leider nicht mehr, auf welcher Ebene (QNAP und/oder ESXi) Du hier Thin Provisioning meinst.
Das ThinProvisioning von ESXi und Storage sind i.A. voellig unabhaengig voneinander. Soll heissen: Selbstverstaendlich kann man auf einer thin-provisioned LUN eine pre-allocated Datei (vmdk) anlegen, und auch umgekehrt. [ OK, ausreichend Platz vorausgesetzt... ]
Ich hatte mal 'nen Kunden, der ebenfalls meinte, dass sein Storage den Speicherplatz nicht freigeben wuerde. Bei der Untersuchung kam dann raus, dass er munter VMs mit thin-provisioned Disks angelegt hatte, und sich dann beim Loeschen wunderte, dass diese (leeren!) geloeschten vmdks nicht dazu fuehrten, dass der freie Bereich auf seinem Storage wieder zunahm...
Zumindest ICH verstehe leider nicht mehr, auf welcher Ebene (QNAP und/oder ESXi) Du hier Thin Provisioning meinst.
Das ThinProvisioning von ESXi und Storage sind i.A. voellig unabhaengig voneinander. Soll heissen: Selbstverstaendlich kann man auf einer thin-provisioned LUN eine pre-allocated Datei (vmdk) anlegen, und auch umgekehrt. [ OK, ausreichend Platz vorausgesetzt... ]
Ich hatte mal 'nen Kunden, der ebenfalls meinte, dass sein Storage den Speicherplatz nicht freigeben wuerde. Bei der Untersuchung kam dann raus, dass er munter VMs mit thin-provisioned Disks angelegt hatte, und sich dann beim Loeschen wunderte, dass diese (leeren!) geloeschten vmdks nicht dazu fuehrten, dass der freie Bereich auf seinem Storage wieder zunahm...
Ok, also nochmals:
Die LUN´s sind Thin-Provioning.
VM´s sind Thin-Provisioning.
Entschuldigung für die schlechte Erklärungen, aber mir glüht der Kopf.
In diesem Unternehmen wurde vieles angefangen aber nichts zu Ende gebracht und das was man dann dochmal "fertig" bekommen hat funktioniert nicht richtig.
Die LUN´s sind Thin-Provioning.
VM´s sind Thin-Provisioning.
Entschuldigung für die schlechte Erklärungen, aber mir glüht der Kopf.
In diesem Unternehmen wurde vieles angefangen aber nichts zu Ende gebracht und das was man dann dochmal "fertig" bekommen hat funktioniert nicht richtig.
Das ist wahrscheinlich zuviel des guten, LUN und VM thin. Doppelt hilft hier nicht, weil zweimal thin hat den gleichen Platzbedarf wie einmal, kann aber zu unerwarteten Verhalten führen, weil unnötig komplex.
Wenn du die NAS neu aufsetzt, nimm nfs. Dies ist als default thin, weil nfs nichts anderes kann und man kann auch nichts verkehrt machen, weil es keine Einstellmöglichkeiten gibt, es anders einzurichten.
Wenn du die NAS neu aufsetzt, nimm nfs. Dies ist als default thin, weil nfs nichts anderes kann und man kann auch nichts verkehrt machen, weil es keine Einstellmöglichkeiten gibt, es anders einzurichten.
No. hat geschrieben:continuum hat geschrieben:> Gäbe es einen Nachteil bei der Verwendung von NFS? Oder eventuell gar einen Vorteil?
Aus meiner Erfahrung ist die deutlich erhöhte Datensicherheit bei NFS so viel wert, dass alle eventuellen anderen Nachteile von NFS mehr als ausgeglichen werden.
Hätte ich bei NFS dasselbe Problem wie bei iSCSI, dass beim löschen einer VM danach immer noch der Speicher belegt wird?
Nein hättest du nicht.
.
Zurück zu „vSphere 5.5 / ESXi 5.5“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 17 Gäste