Bringen mehr LUN´s was?

[AlbertMinrich]

Hallo,

zwei ESX-Server 4.0. Ein SAN. Zugriff per Software iSCSI.
Es gibt nur eine LUN (1,2TB), auf der liegen alle 38 VM´s.
Nachdem uns jetzt auch VMWare gesagt hat, dass das zuviel ist, werden wir das doch mal ändern.

Aber dazu hab ich eine Frage.
Das SAN hat 6 SAS-Festplatten (300GB). Aus allen Festplatten wurde ein RAID6 gemacht. Wenn ich jetzt mehrere LUN´s einrichte, läuft ja trotzdem immer noch nur ein RAID darunter. Bringt das dann überhaupt irgendeinen Vorteil?

Danke
Martin

[irix]

Ja, denn bei jedesmal wenn ein ESX auf die LUN zugreift setzt er einen kurzen Lock. Wenn als 2 oder mehr ESX Hosts in den selben Datastore zugreifen muss kann fuer den anderen eine kurze Wartezeit anstehen. Das macht sich dann mit "SCSI Reserveration" Meldungen bemerkbar.

Fuer jede LUN gibts eine Warteschlage was die Anzahl der Anforderungen angeht. Wenn da nun eine grosse Anzahl an VMs in einem Datastore liegt und diese alle IOs machen wollen dann ist die Warteschlange sehr schnell voll unterumstaenden.

Eine Musterloesung gibts aber nicht weil wenn alle meine VMs keinen oder nur geringen IO produzieren kann ich davon viele in einen Datastore legen. In einem anderen Fall koennen 5 VMs schon zuviel sein.

Gleiches gilt fuer die Groesse eines Datastore. Der Grund warum viel darueber zulesen ist das man die LUNs so 400-700GB Gross machen sollte liegt nur dadrin begruendet das man in einen kleinen Datastore nicht viele VMs reintun kann.

Aber in 700GB bekomme ich keinen 1.1TB Exchange herein auch wenn der mehre vDISKs hat bleiben dir hier solange es geht zusammen in einem Datastore (KISS).

Gruss
Joerg

[AlbertMinrich]

Danke für die Antwort

[sirrossi]

Moin, moin,

die recht geringe Anzahl Deiner Spindeln auch noch weiter aufzusplitten (z.B. 2xRAID 5), wird Dir eher zum Nachteil gereichen.
Kannst Du Deinen Storage noch um einige Platten erweitern

Bei Deiner jetzigen Kapazität führen mehr als 3-4 LUN's nur zu einem noch größeren Verschnitt pro Volume.

Möglicherweise hilft auch die Anschaffung eines weiteren Storages, da Du ja Deine jetzigen VM's während der Neugenerierung der LUN's sicherlich auch verlagern mußt

[bla!zilla]

Das Array noch weiter unterteilen macht keinen Sinn. Ziel sind immer möglichst viele Spindeln pro Array. Mehr logische Laufwerke (LUNs nennt man das, was du am Ende am Host siehst) machen schon Sinn. Der Verschnitt sollte der gleiche bleiben, egal ob nun das RAID pro Array gestgelegt wird, oder pro logischem Laufwerk.

[Saturnous]

Zu grosse und zu wenig LUNs :
- zuviele Kommandos per Verbindung
- mehr Reservierungsprobleme

Zuviel LUNs auf wenig Targets :
- schlechtes scheduling
- Target kann komplett sperren wenn nur wenige VMs Vollast geben.

Zuviele Targets :
- Heap auf der Storage oder auf ESX Seite wird eng.

Eine gute Regel bei iSCSI über vSphere Software Initiator ist pro SP 1 oder 2 Targets und pro Target 4 LUNs (auf keinen Fall mehr als 8 pro physischen iSCSI Uplink). Meistens wird ein Array egal wieviele LUNs es hat nur über ein Target und SP rausgegeben. Da viele virtuelle Maschinen schreiblastig sind spielt das mit den vielen Spindeln keine soo grosse Rolle und das Verteilung über 2 SPs überwiegt.

Ist das Kind schon im Brunnen also die Konfiguration verhunzt dann lohnt sich ein Blick auf den "vmkload_mod -s /usr/lib/vmware/vmkmod/iscsi_vmk.ko" Output.

Dieser Beitrag darf ebenfalls nicht fehlen.

http://virtualgeek.typepad.com/virtual_ ... phere.html

[jl_0815]

Noch eine kurze Frage zu dem Thema:

Gilt dieses kurze Sperren der LUN auch für NFS-Datestores oder nur bei VMFS formatierten Datastores?

Danke schonmal.

JL

[Tschoergez]

Das kurze Sperren gilt nur bei VMFS, nicht bei NFS. Und auch nur, wenn die Metadaten geändert werden müssen. Also beim Neuanlegen von VMs, Starten, stoppen usw. und wenn sich Dateigrößen ändern (stichworte Snapshot-Deltas, Thin provisioned vmdks und linked clones).

Alles in allem aber kein Grund zur Sorge, solange Du nicht allzuviel Gebrauch von den genannten Stichworten bei vielen VMs auf der gleichen LUN machst.

viele grüße,
jörg

[TCuser]

Ich hätte auch mal eine Frage, was die Zuweisung bzw. Verteilung der VMs auf die einzelnen LUNs angeht.

Beispiel (ESXi 4.1 Server):

- RAID-10 (mit 4x 1 TB HDDs) aufgebaut
- 1 Target erstellt (Name: TestTarget)
- 4 LUNs (je 500GB) zugewiesen

Über den VI-Client unter Datastore ist der neu hinzugefügt Datenspeicher (VMFS) mit einer Größe von knapp 2 TB zu sehen.

Kann ich bei der Erstellung einer VM festlegen, in welchem LUN die VM liegen soll oder werden die VMs automatisch auf die 4x LUNs verteilt?

Hintergrund: Ich möchte die 4x LUNs gleichmäßig auslasten und nicht zuerst LUN1 mit VMs vollstopfen und dann LUN2 etc.

[irix]

Wie kann man 2TB sehen wenn du 4x512GB gemacht hast? Der ESX sieht nur das was das Storage ihm anbietet. Man koennte die LUNs auf ESX Seite wieder extenden aber das moechte man eigentlich nicht.

Gruss
Joerg

[TCuser]

@irix: Sorry, die LUNs wurden auf d. ESXi-Host erhöht bzw. die 4x LUNs zusammengeführt. Ist es sinnvoller, je LUN als Datastore einzubinden, bereitzustellen und selber zu etnscheiden, wo welche VM laufen soll?

[irix]

@irix: Sorry, die LUNs wurden auf d. ESXi-Host erhöht bzw. die 4x LUNs zusammengeführt. Ist es sinnvoller, je LUN als Datastore einzubinden, bereitzustellen und selber zu etnscheiden, wo welche VM laufen soll?

Ja, das ist sinnvoller und wird von 99.999999999% aller Leute auch so gemacht.

Gruss
Joerg

[faert]

@irix: Könntest du das ja vllt ein wenig erklären?

Wir betreiben mehrere Server mit einem gemeinsamem SAN und dort sind mitlerweile 9 Datastores entstanden, jeder ca 600-800GB groß. Nun war die Überlegung diese Datastores als einen zu präsentieren um nicht nicht suchen zu müssen und eventuell den Verschnitt in den Datastores zu vermeiden.

Oder sind wir dort auf einem komplett falschem Weg und es gibt eine viel genialere Lösung?

[sirrossi]

Moin, moin,

und was passiert, wenn Dir eine der extended LUNs abschmiert
Du hast nur 9 LUNs, was würde ich dafür geben

[faert]

Ich sag mal so - uns ist hier noch an keinem Standort ne Lun "abgeschmiert". Worin äußert sich sowas?

Aber alles mit der free-Version des vSphere Da wird das schon nervig, da es keine zentrale Verwaltung gibt..

[Tschoergez]

naja, wenn Du eine LUN mit datenverlust verlierst, ist bei 9 Datastores nur einer weg, bei einem gespannten Datastore wahrscheinlich alles....

performancetechnisch spielts wohl keine große Rolle, wenn die Luns im Endeffekt auf den gleichen Spindeln liegen.
die sache mit den SCSI-reservations ist beim ESX4 nicht mehr kritisch.

allerdings würd ich auch lieber mehrere kleinere Luns haben, für mich ist das übersichtlicher und granularer (wenns irgendwo probleme gibt, betreffen die eben nur den einen Datastore).

Und mal ehrlich: Wenn ihr ein Storage mit 9 * 600GB Platzbedarf habt, dann sollte doch auch ne vCenter-lizenz mit zugehörigen ESX-Lizenzen drin sein. Man gewinnt doch unglaublich viel Verfügbarkeit, Managementfunktionen, automatisierung, ....

Viele Grüße,
jörg

[faert]

Also hätte es keine Performance Nach-/Vorteile wenn man die Luns als ein Datastore präsentiert?
Es wäre halt nur alles "im Arsch" wenn auf einer LUN was schief gehen sollte?

Könntest du mir kurz erklären, wieso die Sache mit den SCSI-Reservations nicht mehr kritisch ist? Ich hatte das so verstanden, wenn ein Server Metadaten ändert (zählt dazu eig auch das die Platte sich vergrößert bei Thin-Provisioning? Wir haben sehr viele Server mit Thin-Provisioning angelegt...) er einen Lock setzt und der Rest in einer Warteschlange landet. Besteht dieses Problem etwa nicht mehr?

Unsere VMs sind meist nur 40GB groß... da kommen also schon einige zusammen und da die Maschinen durch das "wachsen" des Systems in verschiedenen Datastores liegen wird es irgendwann ziemlich unübersichtlich...


Ich danke euch für die Erklärungen!


@Tschoergez: Das Rede ich schon seit über einem Jahr... aber wir haben eine Menge CPUs und bei uns würde es billiger werden neue Blades+Lizenzen zu kaufen anstatt für die alten Blades Lizenzen... In 4 Wochen sollte das erste Neue eintreffen Vllt kommen wir irgendwann in den Genuß von Lizenzen.

[Tschoergez]

ok, bei vielen Thin-proisioned Servern kanns durchaus noch problematisch sein... Hilft aber nur ausprobieren...

Background: Seit ESX4 verwendet der ESX ein sog. Optimistic Locking. D.h. er muss nicht mehr bei jeder Metadatenänderung einen lock setzen, sonder er geht davon aus, dass die änderung höchstwahscheinlich auch ohne lock konsistent durchgeht.
Und nur, wenn zwei ESX gleichzeitig die Metadaten ändern (wollen), muss der Konflikt gelöst werden.

nähere Infos:
http://h30507.www3.hp.com/t5/Technical- ... ba-p/82672
http://www.yellow-bricks.com/2011/02/25 ... your-vmfs/
http://communities.vmware.com/thread/11 ... 0&tstart=0

Viele Grüße,
Jörg

[faert]

Danke für die super Links.

Wie meinst du das mit ausprobieren? Wo kann ich mir auf dem esxi anschauen, inwieweit er wo locks setzt bzw protokolliert er das überhaupt?

Unsere Systeme sind 4.0 und VMFS ist entweder 3.33 oder 3.46. Also solte das Optimistic Locking schon greifen.

"Worst-Case" wäre also wenn ich 3 VMs in einem DS habe und kopiert von 1 zu 2 Daten und von einer externen Quelle noch auf die 3. VM, dann würde er das locken anfangen, da er VM2 vergrößern muss und VM3 auch?

Gruß

[Tschoergez]

es geht beim locking um die ESX, nicht um die VMs...
Wenn also nur ein ESX auf die LUN zugreift (egal für wie viele VMs), kein Problem.

Ausprobieren meinte ich: Du musst halt schauen,obs in Deiner Konstellation gut läuft. Mitloggen tut der ESX die Locks nicht, nur bei Conflicts gibts nen Eintrag im vmkernel-log.
Viele Grüße,
Jörg

[irix]

Es ist schon seit einiger Zeit nicht mehr so das wenn man einen Extent in der Mitte verliert man alles verloren hat was an Extents dahinter noch kommt. Es ist nur der eine Extent betroffen und alle VMs welche drauf liegen. Allerdings bin ich der Meinung das dem ersten Extend eine ganz besondere Bedeutung zukommt und falls man diesen verliert oder er nicht zur Verfuegung steht man sagen kann "The shit hits the fan".

Gruss
Joerg

[Torsten.E]

Da klinke ich mich auch mal ein.
12 x 1 TB Platten (10k) im Augenblick komplett als RAID6 (= 9223 GB)
Anbindung über iSCSI 1 GB aber auch 2 GB möglich

Jetzt geht es ja um die Aufteilung der LUN's
1 x Domain-Controller
1 x Exchange 2010
1 x SQL-Server 2008
1 x Terminal-Server
1 x "RestlichesZeug"-Server

Jetzt gibt es ja Empfehlungen wie die LUN's z.B. für die Exchange-Datebanken und Logs eingerichtet werden sollen, für SQL. usw..

Macht das Sinn ? Dann hat man zum Schluss einen "Haufen" LUN's oder ist das eher kontrakproduktiv ?

Lieber 1 gemeinsammes LUN für die VM's und ein LUN wo die Daten Exchange/SQL drauf liegen.
liegen.

PS: Wir sind nur 12 Mann im Büro, als keine 10000

[irix]

Hallo Thorsten,

solange es moeglich ist halte die VMDKs deiner VMs zusammen in einem $Homedir und somit auf einem Datastore==LUN.

Gruende fuer viele LUNs:
- Wer, wegen VMware Snaps oder Thinprov oder vDesktops, in die Gefahr laueft SCSI Reservations zubekommen macht fuer solche dinge Extra LUNs
- Wer gezwungen ist bei der Volume Erstellung im SAN gezwungen dort einen Controller/Port anzugeben welcher die Primaere Arbeit verrichtet. Mit mehreren LUNs verteilt man hier die Last
- Trennen von gleichen/Cluster/Redundanz VM damit die nicht alle im gleichen Datastore==LUN

Bei deiner geringen Anzahl machst du 2-3 LUNs und verteilst die VMs. Immer schoen Platz lassen nach hinten raus. Im SAN sollte immer soviel Reserve verbleiben wir dein groesster Datastore/LUN Gross ist. Muss mal ein Restore oder LUN Copy gemacht werden ist es schoen wenn man das kaputte Original nicht gleich killen muss nur um den Restore zubeginnen.

Gruss
Joerg

[Torsten.E]

Hallo Thorsten,
Immer schoen Platz lassen nach hinten raus. Im SAN sollte immer soviel Reserve verbleiben wir dein groesster Datastore/LUN Gross ist. Muss mal ein Restore oder LUN Copy gemacht werden ist es schoen wenn man das kaputte Original nicht gleich killen muss nur um den Restore zubeginnen.

Das ist für mich schon eine Logik mehrere LUNs zu machen und diese damit auch "klein" zu halten. Daran hätte ich nicht gedacht.