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!

SAN Design

Hilfe bei Problemen mit Installation & Benutzung des VMware ESX/ESXi Server 3.

Moderatoren: Dayworker, irix

Member
Beiträge: 6
Registriert: 22.10.2008, 08:34

SAN Design

Beitragvon moezzz » 22.10.2008, 08:46

Hallo erstmal,

ich bin neu hier und das ist mein erster Beitrag.

Da wir gerade darüber nachdenken unser SAN auszubauen habe ich mal eine Frage. In der VMWare Doku "Fibre Channel SAN Configuration Guide" steht auf Seite 106:

"When assigning LUNs, remember that each LUN is accessed by a number of ESX Server
hosts, and that a number of virtual machines can run on each host. One LUN used by
an ESX Server host can service I/O from many different applications running on
different operating systems. Because of this diverse workload, the RAID group
containing the ESX Server LUNs should not include LUNs used by other hosts that are
not running ESX Server for I/O intensive applications "

Gerade der letzte Satz ist für mich/uns sehr interessant. Kurz zum jetzigen Status:

Wir betreiben derzeit 7 esx´e mit insg. 60 vm´s. Die vm´s liegen derzeit alle auf einem 8 tb fc array von sun, redundant an die esx´e angeschlossen. Das array ist also derzeit nur für die esx´e da. So wie VMWare es auch empfiehlt.

Da wir nun aber über die Anschaffung eines größeren SANs nachdenken, stellt sich mir die Frage ob es Sinn macht die esx LUNS mit in das neue großen SAN aufzunehmen. Allerdings wird das neue SAN nicht nur LUNS für die Virtualisierung "hosten" sondern auch für einige andere Systeme (Fileservice für user, Store für Webserver etc...). Macht das überhaupt Sinn, oder gehe ich da zu großes Risiko in Sachen Performance ein?
Hat jemand vielleicht sowas in der Art schon am Laufen?
Ich persönlich ziehe es vor das ESX Raid völlig unabhängig vom Rest zu betreiben, so wie es derzeit auch ist und wie es VMWare scheinbar empfiehlt. Mein Chef sieht das leider derzeit noch anders.

Bin gespannt auf eure Antworten,

gruß Moe :)

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 22.10.2008, 12:29

VMware schreibt ja nur, dass ESX und andere physische Systeme sich ein Raid-Array nicht teilen sollten. Wenn du unterschiedliche Arrays mit unterschiedlichen Platten hast, trennst du VM und Rest ja physisch voneinander, zumindest was die Platten angeht. Ob der Storage generell die erforderliche Leistung aufbringt alle Systeme zu versorgen ist eine ganz andere Frage.

Eigentlich gebe ich VMware recht, aber es ist dennoch möglich sich Arrays zu teilen (nicht die LUNs, die gehören ja getrennt). So was hängt immens von der eigenen Struktur und lässt sich letztendlich mit JA/NEIN beantworten.

Wir haben hier 6 ESX Server mit ca. 90 VMs zusammen mit einigen physischen Notes Servern und physischen FS Clustern und ich versuche die Arrays voneinander zu trennen. Vor allem der Fileserver an dem u.A. 30 Terminal Server hängen reagiert extrem Sensibel auf die Anwensenheit eines Notes Servers auf dem selben Array.

Aber das bekommt man aus der Erfahrung heraus. Wenn man jedoch eh alles neu macht, würde ich die Platten-Array auch trennen, aber einen EIGENEN Storage nur für ESX und einen für den Rest würde ich bei meiner (und deiner?) Größenordnung nicht machen.

Ich würde da eher in die Ausfallsicherheit des Storages investieren, denn dieser ist bei solchen Umgebungen eher der SPOF.

King of the Hill
Beiträge: 13064
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 22.10.2008, 12:54

mangold hats ja schon auf den Punkt gebracht.. ein Ja/Nein gibts da nicht. Hinzu kommt das es SANs gibt welche
1. nur ein RAID Level pro Box
2. Systeme wo man zwar sagen RAID X, aber die Box intern sowie so das macht was sie will :)

Gruss
Joerg

Benutzeravatar
Moderator
Beiträge: 3476
Registriert: 23.02.2005, 09:14
Wohnort: Burgberg im Allgäu
Kontaktdaten:

Beitragvon Tschoergez » 22.10.2008, 12:58

Hi,

Je nach Storage System kann man auch in einem Array unterschiedliche RAIDs einrichten, und darauf wieder unterschiedliche LUNs...

Ich hätte kein Problem damit, dass ESX und andere Server sich das Storage Array teilen (dafür ist das CENTRALIZED Storage ja da :grin:). Die SAN Admins müssen halt drauf achten, dass die ESX-LUNs nicht an andere Server präsentiert werden (via zoning, LUN presentation usw...).

Gott sei Dank sind auch noch die Bezeichnungen von "Array" bei jeden Hersteller unterschiedlich, damits noch ein bisschen verwirrender wird.

Was habt Ihr denn für Storage Systeme / Arrays?

viele Grüße
Jörg

Member
Beiträge: 6
Registriert: 22.10.2008, 08:34

Beitragvon moezzz » 22.10.2008, 13:02

Ich versuche natürlich jetzt im Vorfeld schon alle Eventualitäten akzuklopfen. Denn wenn der jetzige Store mit dem neuen erstmal verheiratet ist und es dann zu Performance Problemen kommt, ist es mehr oder weniger zu spät. Einen Designfehler kann man sich eigentlich nicht leisten.

Hinzukommt, das habe ich im ersten Posting vergessen zu erwähnen, dass im gleichen Zuge 5 weitere ESX Server "in Dienst" gestellt werden und sich die Zahl der VMs mittelbar um 30 - 40 erhöht.

Der Vorteil den ich jetzt durch das an sich geschlossene System (Array + FC Switche + Blade) habe ist der, dass ich im Falle von Performance Einbrüchen relativ schnell weiß wo ich nach dem Fehler suchen muss. Dahingegen befurchte ich bei einer Verschmelzung des sonstigen Storages mit dem VM Store, dass am Ende nicht mehr klar gesagt werden kann, wo jetzt eigentlich das Problem herkommt weil einfach zu viele andere Faktoren (andere Systeme die am SAN hängen) auf das SAN Einfluß haben.

Der Punkt der Ausfallsicherheit (nicht nur für die VMs sondern auch bzw. gerade für den "Rest") ist genau der Grund warum sich jetzt soviel ändern soll/wird. Der neue "Plattenturm" soll in identischerweise nochmal genau danebengestellt werden und synchron zum ersten gehalten werden.
Zur Zeit habe ich im VM Bereich ein 6140 StorageTek mit reduntanten Controllern und Netzteilen.

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 22.10.2008, 13:09

darf man Fragen mit welcher Lösung ihr den Failover Realisiert? Ist das ein reines Mirroring zwischen den Storage-Köpfen oder macht ihr auch ein transparentes failover für ESX?

Member
Beiträge: 6
Registriert: 22.10.2008, 08:34

Beitragvon moezzz » 22.10.2008, 13:18

im Falle eines Falles wechselt der ESX auf den noch aktiven Path.
So wie im Multipathing Guide von VMWare beschrieben.
Jeder ESX ist an zwei unterschiedliche Brocades angeschlossen. Jeder Brocade für sich ist wiederrum jeweils an beide Controller des 6140 angeschlossen. Im schlimmsten Falle kann als ein Brocade und ein Controller vom Raid ausfallen und alles läuft weiter.

King of the Hill
Beiträge: 13064
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 22.10.2008, 13:18

Tschoergez hat geschrieben:Was habt Ihr denn für Storage Systeme / Arrays?
Jörg


2x Equallogic PS5000 an 2 iSCSI Switchen. Je SP sind 3x1GB vorhanden welche "über Kreuz" mit den Switchen verbunden sind. Je Array 2 SP welcher im Passive Modus laueft.

bei anderen Installationen kommt Open-E zu Einsatz.

Gruss
Joerg

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 22.10.2008, 14:43

moezzz hat geschrieben:im Falle eines Falles wechselt der ESX auf den noch aktiven Path.
So wie im Multipathing Guide von VMWare beschrieben.
Jeder ESX ist an zwei unterschiedliche Brocades angeschlossen. Jeder Brocade für sich ist wiederrum jeweils an beide Controller des 6140 angeschlossen. Im schlimmsten Falle kann als ein Brocade und ein Controller vom Raid ausfallen und alles läuft weiter.


ah ok! Multipathing über redundante Fabrics und Controller ist selbstverständlich :) Aber was macht ihr wenn der/die 6140 ausfällt? Ist das redundant in irgend einer Form?

Member
Beiträge: 6
Registriert: 22.10.2008, 08:34

Beitragvon moezzz » 22.10.2008, 15:04

Der 6140 ist dahingehend redundant, dass in ihm die zwei Controller + zwei Netzteile stecken. Jeder Controller kann für sich das Raid autark betreiben.
Was natürlich nicht passieren darf ist, dass das Raid 5, bzw. zu viele Platten sterben. Davon gibt es zwar Backups (jede Nacht sichert Legato alle VM´s), der Recovery Prozess würde allerdings schon einige Zeit in Anspruch nehmen.

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 22.10.2008, 15:44

moezzz hat geschrieben:Der 6140 ist dahingehend redundant, dass in ihm die zwei Controller + zwei Netzteile stecken. Jeder Controller kann für sich das Raid autark betreiben.
Was natürlich nicht passieren darf ist, dass das Raid 5, bzw. zu viele Platten sterben. Davon gibt es zwar Backups (jede Nacht sichert Legato alle VM´s), der Recovery Prozess würde allerdings schon einige Zeit in Anspruch nehmen.


ok dann habt ihr es so wie wir derzeit. Leider hatte unser Datenbank Team mehrmals die Erfahrung machen müssen, dass sich der Storage nicht ganz so verhält wie erwartet und dadurch mehrmals Produktionsstillstände. Da wir uns immer mehr in Richtung 24x7 entwickeln ist das mein Thema Nr.1 für nächstes Jahr. backups reichen mir nicht mehr aus, ich will transparentes Failover. Ausserdem kann ich nichtmal mehr Firmware Updates machen.

Member
Beiträge: 6
Registriert: 22.10.2008, 08:34

Beitragvon moezzz » 23.10.2008, 07:36

Das ist das Gute am 6140, durch die zwei Controller kannst du auch im Betrieb Firmware Update einfahren. Dabei wird jeweils nur ein Controller "geupdatet" während der andere den Betrieb aufrecht erhält.
Habs bisher aber auch nur einmal gemacht, danach war ich fix und fertig ;)

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 23.10.2008, 09:41

moezzz hat geschrieben:Das ist das Gute am 6140, durch die zwei Controller kannst du auch im Betrieb Firmware Update einfahren. Dabei wird jeweils nur ein Controller "geupdatet" während der andere den Betrieb aufrecht erhält.
Habs bisher aber auch nur einmal gemacht, danach war ich fix und fertig ;)


ja aber von den Drives und Enclosures müssen auch Updates gemacht werden und diese dürfen zumindest bei IBM DS4xxx zu dem Zeitpunkt kein IO haben.

Member
Beiträge: 20
Registriert: 18.08.2008, 11:49

Beitragvon osu » 23.10.2008, 09:46

mangold

ja aber von den Drives und Enclosures müssen auch Updates gemacht werden und diese dürfen zumindest bei IBM DS4xxx zu dem Zeitpunkt kein IO haben.


aber nur bei disk-updates!

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 23.10.2008, 09:54

osu hat geschrieben:mangold

ja aber von den Drives und Enclosures müssen auch Updates gemacht werden und diese dürfen zumindest bei IBM DS4xxx zu dem Zeitpunkt kein IO haben.


aber nur bei disk-updates!


ja ok, aber da Stroage, Enclosure und Drives den zuneinander passenden FW Level haben müssen, kommt man meistens nicht drum herum auch diese machen zu müssen. Hat uns letztens 6 Stunden (geplante) Auszeit eingebracht. Und das Erste was IBM macht bei Support-Calls -> "machen sie mal ein FW Update, vorher reden wir nicht weiter" Vor allem wenn die FW ein Jahr alt ist :(

Member
Beiträge: 6
Registriert: 22.10.2008, 08:34

Beitragvon moezzz » 23.10.2008, 10:21

Da hast du natürlich. Deshalb habe ich auch schon "lange" kein Update mehr eingefahren.
Wobei ich sagen muss, dass SUN sich da etwas kulanter verhält. Bzw. bisher konnte ich denen immer recht schnell klar machen, dass ein Upgrade und die dazu gehörige Downtime erstmal nicht in Frage kommt. Es sei denn der Support belegt mir, dass es wirklich an der Firmware liegt.

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 23.10.2008, 11:30

letzt endlich wollte ich eigentlich damit ausdrücken, dass redundante FC Switche und Controller nicht der Weisheit letzter Schluss ist. Ob man für "bessere" Lösungen das Geld bekommt ist natürlich eine ganz andere Frage, man sollte dennoch die Verantwortlichen darauf hinweisen, damit es später nicht heisst "warum habt ihr das nicht gesagt?"

Member
Beiträge: 20
Registriert: 18.08.2008, 11:49

Beitragvon osu » 24.10.2008, 11:32

Platten-Updates sind selten, Firmware, NVSRAM und ESM gibt es regelmäßig Updates!

Benutzeravatar
Profi
Beiträge: 743
Registriert: 23.07.2008, 14:09
Wohnort: Usa
Kontaktdaten:

Beitragvon mangold » 24.10.2008, 11:36

vielleicht lag es daran, dass ich so selten updates mache, aber dann musste ich IMMER Platten updaten.

Storage ist immer noch SPOF und spätestens mit einem Backup RZ reicht das auch nicht mehr aus einen Einzelnen zu habe. Aber das ist letztendlich wollte ich nur wissen wie moezz das Failover zwischen den Storages macht und ich habe die Antwort bekommen. :D


Zurück zu „ESX 3 & ESXi 3“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste