Hallo,
bin mit dem Thema nicht so vertraut.
Hier taucht die Frage auf, ob man für jede VM eine LUN angeben bzw erstellen muss.
Nach meinem bisherigen Verständnis repräsentiert eine LUN eine Art Partition. Somit würde ich mit dieser Einstellung doch schon die max. Grösse einer VM festlegen. Ist dies sinnvoll?
Ich weiss, dass VMware bis zu 16 VM's pro LUN zulässt.
Wie wird dies adressiert?
PS: Es sind zwei ESX geplant, die an einem SAN hängen. Da ich das Ganze noch konfigurieren / installieren muss, habe ich hier relativ freie Hand.
Danke!
der Tester
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!
Jede VM eine LUN?
- angoletti1
- Experte
- Beiträge: 1323
- Registriert: 08.07.2005, 16:41
- Wohnort: bei Trier
Hi,
wenn du RAW-Mapping verwendest benötigst du natürlich pro VM eine LUN. Da ich bei z.B. WindowsVMs da jedoch keine Notwendigkeit sehe und diese immer mit VMDKs betreibe, kannst du ruhig mehrere VMs auf eine LUN legen.
Eine LUN ist wie du auch geschrieben hast wie eine Partition zu betrachten und dort kann man ja auch mehr als eine Datei speichern, oder?
Gruß
Chris
wenn du RAW-Mapping verwendest benötigst du natürlich pro VM eine LUN. Da ich bei z.B. WindowsVMs da jedoch keine Notwendigkeit sehe und diese immer mit VMDKs betreibe, kannst du ruhig mehrere VMs auf eine LUN legen.
Eine LUN ist wie du auch geschrieben hast wie eine Partition zu betrachten und dort kann man ja auch mehr als eine Datei speichern, oder?
Gruß
Chris
Natürlich geht das. Solange du nur eine LUN an einen Host präsentierst, ist das auch kein Thema. Eine LUN an mehrere Hosts und dann auch noch mehrere Partitionen geht i.d.R. schief.
Der ESX handelt das etwas anders. Da macht es durchaus Sinn, mehrere große LUNs allen ESX Maschinen zur Verfügung zu stellen, vor allem wenn Dinge wei HA oder VMotion genutzt werden sollen. Da handeln die ESX das locking aber untereinander.
Mit einem speziellen Dateisystem kann man auch eine LUN / Partition mehreren Hosts präsentieren, siehe GPFS von IBM, GFS von RedHat, Oracle Filesystem unter Linux usw.
Der ESX handelt das etwas anders. Da macht es durchaus Sinn, mehrere große LUNs allen ESX Maschinen zur Verfügung zu stellen, vor allem wenn Dinge wei HA oder VMotion genutzt werden sollen. Da handeln die ESX das locking aber untereinander.
Mit einem speziellen Dateisystem kann man auch eine LUN / Partition mehreren Hosts präsentieren, siehe GPFS von IBM, GFS von RedHat, Oracle Filesystem unter Linux usw.
- angoletti1
- Experte
- Beiträge: 1323
- Registriert: 08.07.2005, 16:41
- Wohnort: bei Trier
Hi,
je nach SAN-Konfig macht das natürlich einen Unterschied, wenn bloß eine VM auf einer LUN liegt. Dies bringt allerdings auch Nachteile mit sich, denn so musst du auf jeder LUN noch Reserven für Snaps haben.
Kommt also drauf an, was wichtiger ist, Speicherplatz oder Performance.
In Einzelfällen ist es bestimmt gerechtfertigt (Powerdatenbank, Exchange mit >1000 Postfächern, ...) aber bei einem normalen Server wie DC, ... ist es nicht nötig.
Unterschiede bei VMotion gibt es nicht. Ich glaube bei RDM und VCB war irgendeine Einschränkung.
je nach SAN-Konfig macht das natürlich einen Unterschied, wenn bloß eine VM auf einer LUN liegt. Dies bringt allerdings auch Nachteile mit sich, denn so musst du auf jeder LUN noch Reserven für Snaps haben.
Kommt also drauf an, was wichtiger ist, Speicherplatz oder Performance.
In Einzelfällen ist es bestimmt gerechtfertigt (Powerdatenbank, Exchange mit >1000 Postfächern, ...) aber bei einem normalen Server wie DC, ... ist es nicht nötig.
Unterschiede bei VMotion gibt es nicht. Ich glaube bei RDM und VCB war irgendeine Einschränkung.
- angoletti1
- Experte
- Beiträge: 1323
- Registriert: 08.07.2005, 16:41
- Wohnort: bei Trier
Hi,
eine große LUN geht über sagen wir mal 10 physikalische Platten. Da liegen dann 20VMs drin. Diese 20 konkurieren um die Performance der 10 Platten.
Hast du nun eine LUN für 1VM über 10 Platten, so hatte diese VM die Power der Spindeln für sich alleine.
Kommt immer auf die Konfig des SANs an, aber generell kann man es sich so vorstellen.
eine große LUN geht über sagen wir mal 10 physikalische Platten. Da liegen dann 20VMs drin. Diese 20 konkurieren um die Performance der 10 Platten.
Hast du nun eine LUN für 1VM über 10 Platten, so hatte diese VM die Power der Spindeln für sich alleine.
Kommt immer auf die Konfig des SANs an, aber generell kann man es sich so vorstellen.
- Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Einschränkungen bei RDM und VCB gibts nicht mehr in der neuesten Version, Du musst halt aufpassen mit physical RDMs, weil für die keine Snapshots angelegt werden können.
Ansonsten ist es, wie Chris beschrieben hat:
Kleinere LUNs bedeuten:
Weniger Flexibilität, evtl. mehr Overhead, weil Du auf jede LUN Platz für die Snapshots brauchst, aber weniger Wettbewerb, und weniger Gefahr von Engpässen
Dafür erhöht sich der Verwaltungsaufwand, weil Du ja dafür sorgen musst, dass jeder ESX und der VCB Proxy jede LUN sieht, Du musst erstmal ne ganze Reihe von LUNS anlegen usw.
Ich kenn sowohl Umgebungen, wo es für jede VM eine LUN gibt (aber eher historisch bedingt, weil das ja bei den phsikalischen Servern auch so war), und ich kenn Umgebungen, auf denen 40 VMs auf der gleichen VMFS-PRatition und der gleichen LUN laufen ohne Probleme.
Ein pragmatischer Mittelweg ist wohl das Beste. Bau einfach ne LUN, pack VMs drauf, und wenn Du LUN langsam voll wird, baust Du halt ne neue für die nächsten VMs. Nur für die angesprochenen "Spezialfälle" rentieren sich wohl extra LUNs.
Viele Grüße,
Jörg
PS.: sorry, hab erst jetzt Deinen letzten Post gesehen:
der vmkernel pflegt für jede LUN intern eine Warteschlange, und normalerweise haben auch die Storage-Controller für jede LUN eine Queue. Drum gibts einfach weniger Wettbewerb, wenn Du mehrere LUNs hast. (Die Größe spielt dabei keine Rolle)
Außerdem kannst Du bei nem active/active-SAN für jede LUN nen extra bevorzugten physikalischen Pfad angeben, und so die Last auch wieder feiner manuell verteilen.
Ansonsten ist es, wie Chris beschrieben hat:
Kleinere LUNs bedeuten:
Weniger Flexibilität, evtl. mehr Overhead, weil Du auf jede LUN Platz für die Snapshots brauchst, aber weniger Wettbewerb, und weniger Gefahr von Engpässen
Dafür erhöht sich der Verwaltungsaufwand, weil Du ja dafür sorgen musst, dass jeder ESX und der VCB Proxy jede LUN sieht, Du musst erstmal ne ganze Reihe von LUNS anlegen usw.
Ich kenn sowohl Umgebungen, wo es für jede VM eine LUN gibt (aber eher historisch bedingt, weil das ja bei den phsikalischen Servern auch so war), und ich kenn Umgebungen, auf denen 40 VMs auf der gleichen VMFS-PRatition und der gleichen LUN laufen ohne Probleme.
Ein pragmatischer Mittelweg ist wohl das Beste. Bau einfach ne LUN, pack VMs drauf, und wenn Du LUN langsam voll wird, baust Du halt ne neue für die nächsten VMs. Nur für die angesprochenen "Spezialfälle" rentieren sich wohl extra LUNs.
Viele Grüße,
Jörg
PS.: sorry, hab erst jetzt Deinen letzten Post gesehen:
der vmkernel pflegt für jede LUN intern eine Warteschlange, und normalerweise haben auch die Storage-Controller für jede LUN eine Queue. Drum gibts einfach weniger Wettbewerb, wenn Du mehrere LUNs hast. (Die Größe spielt dabei keine Rolle)
Außerdem kannst Du bei nem active/active-SAN für jede LUN nen extra bevorzugten physikalischen Pfad angeben, und so die Last auch wieder feiner manuell verteilen.
- Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
anmerkung noch:
Der Verwaltungsaufwand steigt dabei natürlich stark an (bei kleinen LUNs und manueller Verteilung der Pfade), und "überlisten" lässt sich die Physik auch nicht.
Was brennt besser als Hexen?
Viele Spindeln und viel Schreibcache helfen viel (und sind meist wirtschaftlicher, als wenn sich jemand tagelang hinhocken muss um das so fein auszutüfteln von den Einstellungen)
Der Verwaltungsaufwand steigt dabei natürlich stark an (bei kleinen LUNs und manueller Verteilung der Pfade), und "überlisten" lässt sich die Physik auch nicht.
Was brennt besser als Hexen?
Viele Spindeln und viel Schreibcache helfen viel (und sind meist wirtschaftlicher, als wenn sich jemand tagelang hinhocken muss um das so fein auszutüfteln von den Einstellungen)
Zurück zu „vCenter / VMware VirtualCenter“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 15 Gäste