Seite 1 von 1
LUN Aufteilung im SAN ? Praktische Erfahrungen.
Verfasst: 21.03.2005, 17:07
von od73
Hi Leute,
ich würde gerne von euch wissen wir ihr das SAN mit mehr als einem ESX Server aufgeteilt habt ? Manche machen einfach eine LUN für alle Server und andere legen für jeden Server eine seperate LUN an. Da ich noch wenig praktische Erfahrung in dem Bereich gesammelt habe, gibts bestimmt einen Erfahrungsbericht ! Allein von der Übersichtlichkeit würde ich meherere LUNs anlegen. Angenommen ich habe zwei ESX 2.5 mit einer EVA 3000 an zwei SAN Switchen. Wie macht man das Zoning am besten ( hard oder soft) ? Wieviel LUNs erstelle ich ? VC soll später installiert werden ! Danke schon mal für die Antworten !
Verfasst: 21.03.2005, 18:42
von bernyw
Hi,
ich habe das bei mir auf einer EVA 5000 folgendermaßen konfiguriert.
2 LUNs:
1x Highperf mit 72 GB 15k Platten
2x Lowperf mit 146 GB 10k Platten
Meine 3 ESX Server verbinden sich auf beide LUNs und können somit die VM's starten ( zwingend Notwenig für VMotion )
Der Weg über je ein Lun pro VM halte ich für zu aufwendig und nicht notwendig.
Gruß
Bernd
Verfasst: 21.03.2005, 19:26
von od73
Du hast zuerst Hardwareseitig die Raidlevels angelegt. Dann die schnelleren Platten als ein Array und die 146GB Platten als zweites Array angelegt. Dann hast du jeweils eine LUN in den Arrays erstellt. Welche Daten werden denn Wo abgelegt ? Den Zugriffsmodus hast du doch auf "public" gelassen ?
LUN Auftteilung im SAN
Verfasst: 22.03.2005, 08:42
von derharry
Hallo,
ich habe 3 ESX Server (2.1 -jeweils ein BLADE) und einen NetApp Filer (FAS270C) im Einsatz. Jede VM Maschine hat eine eigene LUN.
Ich habe mit dieser Konstellation gute Erfahrungen gemacht.
Auch ohne VC habe ich dadurch eine sehr große Flexbilität. Und kann innerhalb kurzer Zeit VM Maschinen von einem auf den anderen Esx-verlegen.
Bei der Auswahl eines Szenario sollte man sich auch Gedanken über Backup und Restore machen.
Gruß
Torsten
Verfasst: 22.03.2005, 10:37
von GTMK
Es gibt kein "one size fits all". Grundsätzlich gibt es wohl Performance-Gewinne, wenn man die virtuellen Platten auf unterschiedliche VMFS und diese wiederum auf unterschiedliche LUNs legt. Wenn man die LUNs dann noch geschickt den Controllern zuweist, kann man einiges herausholen.
Ich würde nicht so weit gehen, jeder VM ihre eigene LUN zuzuweisen, aber doch denjenigen, die eine hohe I/O-Last zu bewältigen haben.
Ich habe hier mal einige Zahlen zusammengetragen, die unter
http://www.mps.mpg.de/homes/kettmann/ES ... skPerf.pdf
zu finden sind. Insbesondere hat mich auch interessiert, wie die Segmentgröße auf dem RAID einzustellen ist.
Da die VMware-EULA kein Benchmarking erlaubt, habe ich die Zahlen in dem Dokument normiert und insbesondere auf einen Vergleich mit realer Hardware verzichtet. Nur soviel: Die Performance der virtuellen Maschinen kann sich durchaus sehen lassen.
Georg.
Verfasst: 24.03.2005, 13:57
von arknius
1.2 VMFS Beschränkungen
Ein VMFS Speicher hat die folgenden technischen Begrenzungen:
• Maximal 128 ESX Server können auf einen ESX Server verbunden werden
• Maximal 128 Disk Flatfiles können auf einem VMFS abgelegt werden.
2.3 Größe und Anzahl der SAN Luns und VMFS Spaces
Aus Gründen der Übersichtlichkeit wird pro SAN Lun immer nur ein VMFS Space angelegt. Aus Performancegründen sollten nicht alle ESX Server auf eine große Lun zugreifen. Da jedoch VMotion die Vorgabe eines gemeinsamen VMFS hat, werden pro Server Farm vier Luns eingesetzt. Jede Server-Farm besteht dabei aus fünf bis acht ESX Hosts mit jeweils noch einem zusätzlichem ESX Host der als Hot-Standby Server dient.
2.3.1 Beispiel Produktive XXXXX Applikation Server:
Server die virtualisiert werden sollen: 73
Aufgeteilt auf 5 VMware ESX Server: 15 VMs pro ESX
Davon benötigt jeder Server 5 GB Festplattenplatz für die erste Festplatte und 50 für die Zweite. Dies ergibt eine Gesamtanforderung von 55 * ( 73 / 4 ) = 1003 GB pro Lun. Es ist also anzunehmen, dass bei dieser Beispielkonfiguration 1024 GB oder 1 TB pro Lun ausreichen werden.
Die VMs könnten folgendermaßen auf die Farm verteilt werden:
Lun 1 Lun 2 Lun 3 Lun 4
ESX 1 4 VMs 4 VMs 3 VMs 3 VMs
ESX 2 3 VMs 4 VMs 4 VMs 4 VMs
ESX 3 4 VMs 3 VMs 4 VMs 4 VMs
ESX 4 4 VMs 4 VMs 3 VMs 4 VMs
ESX 5 3 VMs 4 VMs 4 VMs 3 VMs
Konfiguration ESX Host
Hardware: IBM xSeries 365
4x Intel Xeon Prozessor
16 GB Ram
4x GBit Broadcom Ethernet
2x 2GB Fibre Channel Storage
2x 2GB Fibre Channel Backup
5x intern SCSI
So zumindest hab ichs im Moment im geplant...
Tipp
Verfasst: 29.03.2005, 05:58
von Tovaco
Status: 2* ibm x445 (8wege 2ghz xeon). je zwei hbas, dazwischen 2*2switche und am Ende 2ds4500. ("Billigspeicher lt.IBM") mit 2Controlern und 5TG pro Seite.
insgesamt 80aktive VMs auf 2 ESX-Servern mit 3TB-Plattenplatz. größenteils gespiegelt.
SAN/ESX-Config: Zoning: 1HBa-> 1SAN-Port. IBM Tipp: nicht mehrere Ports zu einem Zoning zusammenfassen. unsere Prod.LUNs sind meist ca.100GB groß (außer bei File+GhostServer, die bekommen exclusiv eine LUN, mal 200 mal 500GB). Darauf passen ca.10Gäste. die Prio. beim Spiegelneuerstellen wurde auf "hoch" gesetzt. Die Test.LUNs sind meinst 200-300groß, entsprechend mehr Gäste passen drauf. Spielprio "low".
Beide ESX-Server sehen alle LUNs (zoning, SAN-config). Bei zwei SANs muß man die LUNIDs eindeutig wählen.
Dadurch daß die Kiste beide die gleichen LUNs sehen kann man sowohl den manuellen "umzug" ohne VC realisieren oder mit VC. VC setzt das voraus, daß alle beteiligten ESX-Server die LUNs sehen.
Im SAN noch einstellen, daß wir hier eine aktiv/pasiv-Config haben (Fastt: lnxctl).
grüße thorsten
ps: wenn jeder hba nur´n Teil im SAN sieht dann kann es passieren daß esx.2.10/2.11/2.12 viel Mist beim boot produziert und PSODs wirft. 2.5 ist dagegen sehr tollerant. also wenn du noch die Wahl hast, dann 2.5
ps: performance. tests mit iometer haben ergeben:
lsilogic erreicht immer den höheren datendurchsatz. sowohl 2003 als auch 2000. die clustergröße auf dem san spielte bei meinen tests keine rolle. die ergebnisse unterschieden sich nur marginal. raid5 oder raid10 hatte ich nicht getestet. bei uns läuft alle mit raid5. iometer gab mal 180MB/s als Durchsatz an. esxtop bestätigte das