Storage - LUN-Fragen

[mullfreak]

Hallo,

wie gestaltet Ihre Eure Storages in Bezug auf LUN´s?

Für jede virtuelle Maschine eine LUN?
Wie groß soll eine LUN max. sein?
Wie viele VM´s sollen max. in einer LUN sein?

usw.

Gruß
Mull

[Tschoergez]

Hi,

aaah, die große Preisfrage ....schön wärs, wenns so einfach wäre, aber da gibts keine konkreten Richtlinien....

Ein LUN pro VM wäre mir zuviel Storage-Verwaltungsaufwand. Würd ich nur für wirklich IO-intensive VMs in Betracht ziehen (um wettbewerb zu vermdeiden, oder wenn die VM besondere storage-charakteristiekn braucht (RAID-level, cache, usw...)).

Größe der LUNs? Tja, da kommts natürlich drauf an, wie groß Deine VMs sind. Summe aller Platten, die Du in die VMs einbaust, plus Platz für die Swap-Dateien (.vswp), (gerade bei großen VMs nicht vergessen), plus Platz für Snapshots (im sichersten Fall nochmal die summe aller platten der VMs ).
Bei Durchschnittlichen VMs würd ich so ganz grob um 200GB LUNs bauen erstmal, hängt aber stark von der Umgebung ab.

Anzahl der VMs pro LUN? jaaa, da bin ich gespannt auf andere Meinungen. Es gibt keine Empfehlung von VMware, und es gibt genug Umgebungen, auf denen laufen auch 40-60 VM auf EINER LUN ohne Probleme. Auf der anderen Seite können schon drei IO-intensive Datenbankserver zu viel sein auf der selben LUN.....

Drum auch hier: It depends

Bei all den Diskussionen sollte man nicht vergessen: Die Performance hängt hauptsächlich vom Storage System dahinter ab, nicht von der Größe der LUNs oder vom Protokoll (FC,iSCSI oder NFS). Es teilen sich halt (bei den meisten Arrays) alle VMs auf der selben LUN die selbe Physik.
Und bevor Du Dir da jetzt tagelang Gedanken machst:
1. Mach das ganz pragmatisch: Bau ne LUN, pack 5-10 VMs drauf, und wenn die LUN langsam voll wird, bau ne nächste. So gibts mit der Zeit automatisch ne schöne Verteilung.
2. Achte auf io-intensive VMs, dass die nicht alle auf der gleichen LUN liegen.
3. Vorsicht mit Snapshots
4. Anstatt lange Zeit für die Planung zu verwenden, investier das lieber in Platten (mehr Spindeln = (meistens) mehr Performance), und wenn Dein Array nur 5 Platten hat, auf denen 100 VMs laufen sollen, wirst Du auch durch noch so feine Planung nicht viel Unterschiede feststellen können...

Viele Grüße,
Jörg

[philipp24]

gebe da meinem Vorschreiber vollkommen recht! Wir haben es bei uns zwar anderst gemacht aber würde heute auch erst eine neues LUN bauen wenn das erste voll ist!

Wir haben 500 GB LUNs die alle nicht über die hälfte voll sind mit so im schnitt 10 VMs drauf.
Der eine oder andere Datebankserver ist auch dabei aber das ist im moment noch kein problem. Hoffe das bleibt auch so

Wenn du aber zb einen Storage Hersteller fragst wird der dir wahrscheinlich immer FC Platten verkaufen wollen. Aber ob du dem glaubst ist dir überlassen

gruss philipp

[renny]

man sollte sich aber auch gedanken über vmotion und ha machen bei der gestalltung der luns, falls diese lizenzen vorhanden sind und genutzt werden!

gruss

[philipp24]

stehe jetzt vielleicht etwas auf der leitung aber was hat ha oder vmotion mit der lun zu tun?

[Tschoergez]

naja, mit der Größe und Performance gar nix.

Aber natürlich müssen dafür die LUNs an alle ESX im Cluster präsentiert werden...

Und wenn Du da jetzt mal ein Extrem-Beispiel nimmst: 40 VMs auf 5 ESX-Servern, und jede VM auf einer eigenen LUN.
Dann musst Du 40 LUNs an 5 Server mappen in der Storage-Konfiguration, da klickt man sich durchaus die Finger wund... (oder scriptet schön ). Und fehleranfällig ist das natürlich auch ziemlich.

Da tut man sich mit 2 großen LUNs, die an alle ESX präsentiert werden, leichter...



Viele Grüße,
Jörg

PS.: Auch wenn SVmotion mit den obigen Begriffen wiederum nix zu tun hat, da sollte man dran denken bei der Storage-Planung, macht vieles einfacher, wenn man im Nachhinein umziehen muss. Aber man handelt sich während des Vorgangs die ganzen Nachteile/Risiken/Gefahren ein, die auch bei Snapshots da sind...

[philipp24]

ok stimmt auch wieder gehe schon runter von der Leitung

[renny]

um vmotion oder ha zu nutzen muss jeder esx die luns sehen und zugreiffen können. wie jörg schon geschrieben hat

[mullfreak]

Hi,

danke für Eure Antworten. Wir nutzen ein HP MSA2012i, also iSCSI. Darin sind enthalten, 12x 146GB SAS. Wir wollen ca. 20 virtuelle Maschinen zum Schluß haben. Dazu nutzen wir zwei HP DL380G5 und haben Vmware ESX 3.5 Standard, also HA.

Wenn wir die Anlage aufgesetzt haben, berichte ich nochmal über die Konfig.

Gruß
Mull

[renny]

servus

achte darauf das ihr genügend ressourcen in euren dl380 habt. falls bei ha ein host ausfällt muss dieser alle 20 server übernehmen, falls diese natürlich geschäftskritisch sind.
ich würde 2 luns machen einmal für system c und einmal für daten d wenn es windows hosts sind. somit hast du auch bessere backupmöglichkeiten....
aber ebe es kommt auch darauf an was du für vm's drauf hast. wenn exchange, sql etc kommt sieht das alles natürlich wieder ein bisschen anders aus!

gruss

[mullfreak]

hi renny,

es ist von mir so gedacht, das ein server alle vm´s inne hat. im ausfall wird dann per ha der 2. server einspringen und die maschinen hoch fahren. da beide server gleich sind, kann ich mir immer zu 100% sicher sein, das dieser auch alle maschinen fahren kann, weil der erste kann es ja auch.

wir werden auf dieser anlage keine datenbank-server, exchange-server oder ähnlich hoch performante maschinen hosten. es werden eher low-performance maschinen werden, wie z. b. wsus, schnittstellenserver, kleinere applikationsserver. natürlich wird auf mehreren Maschinen mal ein sql-express zu finden sein. jedoch haben wir die auch bisher auf einem vmware-server unter linux seit einem jahr erfolgreich virtualisieren können. und wenn der server (sata, 64mb raid-controller raid1, 8 gb ram, 10 vm´s) die hosten kann, solls der esx erst recht können.

in den beiden servern sind jeweils zwei quad-core xeon, 16 gb ram, verbaut. das sollte fürs erste reichen.

der ansatz für zwei verschiedene partitionen zwei luns zu verwenden ist mir neu. hab ich bis jetzt noch nicht gehört. aber egal. ich denk mal drüber nach...

die frage ist noch, was ich für einen raid-level über wieviel platten verwende. über alle platten raid10? nur die hälfte verwenden mit raid1 und dann die luns auf die andere hälfte spiegeln? hier muss noch kräftig überlegt werden.

gruß
mull

[Heros]

Also ich würde die VMDK´s der VM´s nicht trennen! Hätte ich so auch noch nicht gehört.

Ich denke ich habe es nur falsch verstanden aber es macht natürlich wenig Sinn alle Maschinen auf Host A laufen zu lassen und Host B völlig leer zu lassen. Mach lieber 50/50. Denke aber das wirst du eh machen, oder?

Bezüglich des Speicher ist es natürlich schwierig. Das hängt stark von deinen Systemen ab. Da muss man, wie du schon sagst, sich ein paar Gedanken machen. Dieses Thema wird oft nicht mit der nötigen Aufmerksamkeit betrachtet

[renny]

also dafür gibt es diverse gründe...z.b. muss ein windows ja nicht auf 12 spindeln laufen sondern dem reichen eine handvoll, hingegen wäre die exchange db oder sql sehr frog wenn diese mehr spindel zur verfügung haben. sozusagen würde man die spindeln aufteilen in z.b. 4 spindeln für windows und 8 für exchange, sql etc.... bei grösseren umgebungen hat man auch mehrere enclosure mit zum teil 20x 15k platten und 20x 10k platten und da wäre es ja furchtbar wenn windows auf den 15k pallten laufen würde.
und als zweites ist backup wesentlich besser zu handlen da man c imagen kann mit san software oder vbc(snapshot) und db's oder files via agent auf dem anderen lun backupen! aber eben es ist alles eine sache der ansicht und nur ein input von mir wie ich es bei den kunden handhabe

gruss

[Tschoergez]

Die vmdks zu trennen kann Sinn machen, wenn man z.B. LUNs mit unterschiedlichen RAID-Leveln hat, und für eine VM dann z.B. fürs System andere Charakteristiken braucht als für die Datenbank, wieder was anderes für die Logs usw.
zwei vmdks für System und Daten sind ja ok, aber die dann auch auf verschiedene LUNs verteilen, würd ich nur in einzelfällen machen. (Obwohls früher tatsächlich ne Empfehlung von VMware war).

Aber meine VM ist dann auf mehrere LUNs verteilt, und das wieder mit 100 VM über 5 LUNs, da wird das ganze schnell unübersichtlich. Und wenn ich dann noch dran denke, dass die Kollegen teilweise recht unbedarft mit Snapshots umspringen, ist chaos vorprogrammiert....

Ich würde es eher aufteilen: VMs mit hohen anforderungen komplett auf ne schnelle LUN, VMs mit weniger IO-Last komplett auf langsamere LUNs. Dank SVmotion lässt sich das ja einigermaßen flexibel auch im laufenden Betrieb ändern (btw.: das schon mal probiert, wenn die VM auf verschiedenen LUNs liegt :grin ).

Den Vorteil mit den Backups hat man ja auch, wenn man c und d in verschiedenen vmdks im gleichen Datastore hat.


Um wem jetzt die Planung immer noch zu einfach erscheint: Es gibt auch Raw Device Mappings, die haben wieder andere Möglichkeiten, Strategien usw...

Viele Grüße,
Jörg

[irix]

servus

achte darauf das ihr genügend ressourcen in euren dl380 habt. falls bei ha ein host ausfällt muss dieser alle 20 server übernehmen, falls diese natürlich geschäftskritisch sind.
ich würde 2 luns machen einmal für system c und einmal für daten d wenn es windows

Aeh... wuerde ich SO nicht vorschlagen. Was sinnvoll ist das man pro Laufwerk/Mountpoint eine VMDK macht. Diese auf verschiedene Datastores bzw. LUNS aufzuteilen macht nur in speziellen Faellen sind. Was dabei zubeachten ist das bei einem Snapshot diese generell dort liegen wo die Konfigruartionsdatei der VM liegt abgelegt werden. Mit anderen Worten hier ist mehr "Platz" vorzusehen.

Mach mehrere 500GB Luns sofern das fuer dich ausreicht ansonsten mal eine 1000GB.

hosts sind. somit hast du auch bessere backupmöglichkeiten....
aber ebe es kommt auch darauf an was du für vm's drauf hast. wenn exchange, sql etc kommt sieht das alles natürlich wieder ein bisschen anders aus!

gruss

Hier kommt uns unser SAN entgegen. Die Arrays koennen immer nur einen RAID Level somit kann man nicht viele gedanken verschwenden

Gruss
Joerg

[Heros]

Da stimme ich über ein. Sicher macht es Sinn bestimmte Server auf verschiedene RAID Systeme aufzuteilen aber das allgemein zu sagen ist denke ich sehr schlecht.