VMware-Forum

Im Rahmen eines VMWare-Projektes beschäftige ich mich (bin noch relativ neu auf dem Gebiet der virtuellen Infrastruktur) mit möglichen Systemvarianten eines VMWare ESX Server...

Dabei habe ich mir bisher eine "Low-Budget" Variante überlegt, die zwei ESX-Server auf jeweils einem 8-Wege Server beinhaltet. Die ESX-Server sind wiederum mit zwei HBAs redundant an FC-SWitches angeschlossen und hinter den Switchen hängt eine Storage-Einheit (hp MSA 1500).
Darüberhinaus sind die beiden Server per CrossLink verbunden, um die VMotion-Funktionalität zu gewährleisten.

Neben dieser Low-Budget Varinate habe ich auch versucht eine Hochverfügbarkeitslösung zu modellieren. Hier existieren auch wieder zwei ESX-Server die redundant an zwei FC-Switches angebunden sind. Allerdings hängen hinter diesen Switchen zwei Storages, die jeweils redundant angebunden und zusätzlich online gespiegelt sind. Natürlich auch hier ein CrossLink zwischen den ESX-Servern für VMotion-Funktionalität

Für beide Varianten besteht außerdem noch eine Backupanbindung pro Virtuelle Maschine(TSM), denn falls sich "Fehler" einschleichen sollten, werden diese ja einfach auf der Storage mit weggesichert und das BAckup bietet hier gute Möglichkeiten die gemachten Backups "vor dem Fehler" wiedereinzuspielen.

Nun endlich zu meiner Frage: Wie könnte ein System aussehen, das zwischen diesen beiden o.a. Systemvarianten angesiedelt ist?

Würde sich hier eher eine Lösung mit zwei Storageeinheiten anbieten oder eine Lösung mit nur einer Storageeinheit. Wie würde man den Datenabgleich zwischen den Storages veranlassen, vorausgesetzt es wird mit Storages gearbeitet die keine Online Sicherung unterstützen (sind nämlich sehr teuer...)

So viel erstmal...Freue mich über Ideen und Vorschläge...
Gruß

Wenn ich ehrlich bin... ich wäre froh, wenn ich mir Deine "Low Budget"-Varíante leisten könnte...

SCNR,

Georg.

es sind nicht meine Ansprüche, sondern die des Unternehmen :wink: ...eine Idee für eine Lösung dazwischen hast du nicht?

hallo chrissuperstar,

dann denken wir mal nach...

hochverfügbar heißt ja, alles doppelt zu kaufen.

also 2Server...4 oder 8wege ist jetzt mal egal. am besten noch an 2 unterschiedlichen locationen. pro location ein san mit 2controlern und 2switchen. jeder switch hat verbindung mit jedem san-controler pro location. die beiden locationen werden mit 2ISL (interswitchlink) verbunden. jeder server hat 2hbas...die jeweils zu einem switch pro location führen.
somit ist die SCSI-Seite erschlagen.

zum ip: man nehme mal mindestens 2netzwerkkarten. sinnvollerweise dann schon dualport-teile. baue jeweils 2vSwitche draus...(also vswitch aus port0-karte0 + port1-karte1 und port1-karte0 + port0-karte1). drauf dann max.58maschinen loslassen (64max-vPorts - 1für COS - 1für VMotion - 4pNics). Das COS + VMotion können auch über vSwitche geleitet werden. Das COS-IP und das VMotion-IP über getrennte VLANs erledigen. Das IP für die Gäste...(dmz, non-dmz) auch über getrennte VLANs. Bestenfalls jedem Gast ein eigenes VLAN geben (esx nennt das portgroup). jeweils den port0-nic jeder karte zum router A, die port1-nics zu router B ziehen.

die maschinen regelmäßig per plattendump wegsichern...und nächtliche incremental-sicherungen einplanen.

die esx-server ebenfalls per plattendump wegsichern und auch incrementelle sicherungen einplanen.


was ich jetzt noch nicht angesprochen habe: die hochverfügbarkeit der Gäste. Du müßtest beispielsweise für´ne Web-Application 2VMs definieren, jeweils eins auf einem ESX-Server. Diese VMs sollten einen Cluster bilden (frag mich jetzt nicht wie das unter ESX geht, habe ich noch nicht bauen dürfen). Also beide VMs sollten auf die gleichen Platten zugreifen und im failoverfall sollte halt das überlebende System die Aufgaben des gestorbenen übernehmen.

das was ich da jetzt oben geschrieben habe ist natürlich die maximallösung. man kann einzelne teile rausstreichen, muß sich dann aber mit den einschränkungen arrangieren.


nicht daß du denkst das wäre jetzt nun theorie. wir haben so´ne konfig am laufen. allerdings auch mit kleinen einschränkungen...die doppelte router-anbindung kommt erst im herbst/2005. die san-anbindung geht von den switchen nur zu einem SAN-Controler pro location und nicht zu zwei.

die plattendumps werden nicht gemacht. aber alles ander läuft schon seit ca. einem jahr bis 1.5jahren.

die Erfahrung hat aber gezeigt, daß eher die IP als die SAN-Welt hier Probleme bereitet. nicht wegen ESX sondern mit den möglichkeiten die die virt.Infrastruktur-Technik bietet erschließen sich neue Möglichkeiten die man leider erst mal verstehen muß und dann auch technisch in die Tat umsetzen sollte.

hier mal ein paar knapppunkte: san-failover...man muß im esx timeout-werte definieren...aber man sollte das auch in den gästen machen, sonst bekommen die scsi-timeouts während des failover-vorgangs. das will man nicht.

geht ein ethernet-kabel kaputt und wird getauscht dauert dort ein failback zwischen 30 und 90 sekunden. das will man bei fileservern auf vmware nicht wirklich.

ich hoffe mal es sind einige deiner fragen beantwortet und auch neue gedanken mit ins spiel gebracht worden.

grüße
thorsten

ps: es ist vmware mit san und ip alles eine frage des zieles welches verwirklicht werden soll und natürlich auch des budgets das man zur verfügung hat. zumindest das ziel muß zu beginn klar sein. Man kann mit vmware esx so viele dinge machen, die man mit konventioneller hardware so gut nicht hinbekommt.