Datastore bei ESX Cluster vergrößern

[DaveG]

Wir haben 4 ESX Maschinen in einem Cluster zu laufen und wollen unseren Datastore erweitern. Wir haben VMWare erst dieses Jahr eingeführt und noch nicht so die Erfahrungen gemacht.

Der Datastore besteht derzeit aus einem Volume mit 500GB Platz. Dieser ist per iSCSI von unserem NAS Filer angebunden. Nun wollten wir die LUN auf dem Filer auf 800 GB vergrößern und das Volume entsprechend erweitern.

Kann man das Volume problemlos auf 800 GB vergrößern, werden also 2 Partitionen erstellt und beim Hinzufügen bleibt die erste unberührt?

[irix]

Ich habe leider keine Erfahrung mit NFS basierten Datastorages. Aber was VMFS auf normaln LUNs angeht waere die Vorgehensweise die folgende.

- Nein eine LUN kann nicht ohne weiteres vergroessert werden. Es wird eine 2 LUN angelegt und diese als "Extend" zu der bereits bestehenden hinzugefuegt. Das heist dein Datastore besteht aus 2 einzeln LUNs. Diese kann man 32x wiederholen mit max 2TB grossen LUNs was dann die max VMFS groesse von 64TB ausmacht.

Evtl. kann die Netapp Filer Fraktion was dazu sagen wie sich VMware hier verhaelt. Ansonsten Teste das doch selber mal in dem du eine 2 Testlun anlegst, eine VM dort erstellt und lauefen laesst und dann diese LUN vergroesser und anschliessen ein Rescan durchzufuehren.

Wenn dir das zu Heikel ist stellt sich die Frage ob wirklich eine LUN vergroesserung gebraucht wird oder obs nicht auch eine 2,3,4 LUN tut.
Weil in der realen Welt hat man immer mehr als nur eine LUN

Gruss
Joerg

[DaveG]

Nun, das mit dem vergrößern haben wir getestet und eine Fehlermeldung bekommen. Netapp seitig ist es kein Thema eine LUN zu vergrößern, aber VMWare scheint Probleme zu haben. Wir haben testweise ne kleine zweit LUN rangehangen und das funzte sofort. Nun stellt sich die Frage, wird man diese LUN wieder los, sprich, kann man diese LUN aus dem Datastore wieder entfernen?

[irix]

Mir liegt keine Info vor ob und wie man einen Extend wieder rueckgaengig macht. Mal nach einem KB Artikel geschaut?

Gruss
Joerg

[mullfreak]

Eine große LUN über 800GB würde ich sowieso nicht für gut heißen. Lieber mehrere kleine LUN´s.

[irix]

Eine große LUN über 800GB würde ich sowieso nicht für gut heißen. Lieber mehrere kleine LUN´s.

Immer eine gute Empfehlung allerdings bin ich der Meinung das man es beser auf $Anzahl der VMs bzw. in Abhaenigkeit vom IO Verhalten festmachen sollte.

Weil hier gibts auch Fileserver welche 2TB VMDKs haben.

Gruss
Joerg

[Saturnous]

Klar kann man eine LUN vergrössern und dann mit einer Partition extenden, wenn das auf Anhieb nicht klappt hat man rescan vergessen oder das VC pennt mal wieder, also mit VI Client direkt auf den Host. Timed der Wizzard aus macht mans mit vmkfstools -Z vmhbax:y:z:2 vmhbax:y:z:1 .

Die neue VMFS Version unter ESX4 kann sich vergrössern.

Konserative Empfehlung ist pro LUN 16 VMs - 8 Hosts - ca 500GB. Lieber mit RDMs bei klassischen SAN und bei Geizhals SAN hängt man lieber zwischen VMs und iSCSI vSwitch eine zweite vNIC die per iSCSI Initiator im Gast OS seine eigene iSCSI Session öffnen darf.

Bitte nicht Ontap in die Gäste installieren und die VMWare Quiecing VSS-Instanz - das beisst sich. Auf dem Bootplatten die man per VCB sichert reicht der LGTOSync aus.

Bei ESX4 öffnet er pro World / Blockbereich eine Session - wie das skaliert konnte ich mir noch nicht genau ansehen.

[DaveG]

Also einen Timeout bekommen wir nicht. Ich habe die 500 GB LUN auf dem NAS auf 800 GB vergrößert und wollte die 300 GB nun als Erweiterung hinzufügen.
Zuerst kommt der Hinweis, dass das aktuelle Festplattenlayout gelöscht wird. Alle Dateisysteme und Daten gehen verloren. Bezieht sich die Meldung nur auf die hinzugefügten 300 GB oder auf die komplette 800 GB LUN.
Jedenfalls bekomme ich am Ende des Vorgangs die Meldung: Fehler bei der Konfiguration des Hosts: Failed to update disk partition information.

Für mich sieht das so aus, als ob er die Operation nicht durchführen kann, weil auf den 500 GB virtuelle Maschinen laufen und er eigentlich die kompletten 800 GB formatieren will. Muss aber natürlich nicht so sein