ESX3 und gespiegeltes SAN

[angoletti1]

Hallo,

ich habe mal eine Frage an die Profis hier, jedoch muss ich vorweg sagen das ich nicht der SAN-Profi bin, daher nicht wundern wenn diese Erklärungen etwas seltsam sind.

Folgende Situation:
ESX3 Server mit SAN-Anbindung.
2x SAN, mit Spiegel
der ESX greift auf eine LUN auf SAN1 zu. Diese wird auf SAN2 gespiegelt, ist dort jedoch passiv.
Wenn SAN1 ausfällt wird die LUN das SAN2 aktiv geschaltet, der ESX muss dann einen rescan der LUNs machen, um diese zu finden.

Jetzt die Frage:
Klappt das einwandfrei, denn...
Die Dateien waren auf SAN1 ja im Zugriff, ich bin mir nicht sicher ob diese nicht nach der Umschaltung gesperrt sind, wenn ja wie lange?

Vom SAN her funktioniert das ganze so, das wenn der ESX etwas auf SAN1 schreibt, die Daten auf SAN2 synchronisiert werden und der ESX erst dann die Rückmeldung eines erfolgreichen Schreibvorgangs bekommt. Das ganze ist vom Zugriff her zwar nicht super schnell, aber dafür sicher.

So, wie realisiere ich das nun, um eine möglichst geringe Downtime zu haben? Momentan ist angepeilt, bei einem SAN1-Ausfall einen Rescan auf dem ESX laufen zu lassen, aber da stellt sich wie gesagt die Frage des Zugriffs

Gruß
Chris

[storageguru]

Hallo Chris,

hört sich für mich sehr interessant an, was mich interessieren würde, wie läuft die
Umschaltung, was ist wenn ne Maschine noch drauf läuft, die müsste nach deinen
Erzählungen ja abschmieren.

Ich schreibe einfach mal wie ich immer sowas baue.

Ich mache immer gerne folgende Konstellation:
- x ESX Server mit je zwei Fibrechannelanschlüssen
- mindestens 2 Fibrechannelswitche
- redundante Storageprozessoren/heads/einheiten
- optional, komplett gespiegeltes Storage auf nen zweites RZ

Alternativ könnte man dort auch was mit iSCSI bauen.

Alles wird miteinander so verbunden, dass wenn irgendeine
Komponente ausfällt, der gesamte Betrieb ohne Unterbrechung
weitergeht. Kein Umschalten, Umbiegen, Rumfrickeln, etc.

Somit hast du selbst beim Ausfall eines SANs, FC-Switches, FC-Karte
Storageprozessor, Kabel, etc. immer noch einen weiter laufenden Betrieb
ohne, dass du manuell eingreifen musst.

Bei einem Kunden wurde das sogar soweit getrieben, dass ein komplettes
Rechenzentrum zerstört werden konnte und der Betrieb läuft weiter.

Mfg Marco

[ms-net]

was für Komponenten setzt Du ein. Hast Du Produkte,mpfehlungen für uns?

Gruß, Markus

Hallo Chris,

hört sich für mich sehr interessant an, was mich interessieren würde, wie läuft die
Umschaltung, was ist wenn ne Maschine noch drauf läuft, die müsste nach deinen
Erzählungen ja abschmieren.

Ich schreibe einfach mal wie ich immer sowas baue.

Ich mache immer gerne folgende Konstellation:
- x ESX Server mit je zwei Fibrechannelanschlüssen
- mindestens 2 Fibrechannelswitche
- redundante Storageprozessoren/heads/einheiten
- optional, komplett gespiegeltes Storage auf nen zweites RZ

Alternativ könnte man dort auch was mit iSCSI bauen.

Alles wird miteinander so verbunden, dass wenn irgendeine
Komponente ausfällt, der gesamte Betrieb ohne Unterbrechung
weitergeht. Kein Umschalten, Umbiegen, Rumfrickeln, etc.

Somit hast du selbst beim Ausfall eines SANs, FC-Switches, FC-Karte
Storageprozessor, Kabel, etc. immer noch einen weiter laufenden Betrieb
ohne, dass du manuell eingreifen musst.

Bei einem Kunden wurde das sogar soweit getrieben, dass ein komplettes
Rechenzentrum zerstört werden konnte und der Betrieb läuft weiter.

Mfg Marco

[storageguru]

Hallo Marcus,

also ein Setup was richtig supi ist ist folgendes:

Network Appliance Metrocluster besteht aus:
- zwei FAS3020 Storageprozessoren (dort Köpfe genannt)
- auf jeder Seite mindestens ein Plattenshelf für seine eigenen Platten und auf der Seite
wo sein Clusterpartner steht ein Spiegelshelf für die Platten. Also insgesammt mindestens
4 Shelfs. Platten bekommt man zu 72/144/300GB Größe (14/Shelf).
- 6 Glasfaserleitungen brauchst du für die Verkabelung Shelfs und Clusterinterconnects.
- mindestens 2 besser 4 FC-Switche (verwende gerne Brocade 200E Switche), je nach-
dem wieviele Maschinen an das Storage dran sollen.
-pro ESX-Server zwei FC-Anschlüsse/Adapter, die an die seperaten Fibrechannelnetze
welche in der Fachtermonologie Fabrics genannt werden, angeschlossen werden.

Habe mal einen Beispielaufbau angehängt, damit du dir von meinem geschwafel
mal nen Bild machen kannst.

Dieses Setup hat keinen Single Point of Failure so dass alles mögliche ausfallen kann.
Dieses Setup ist für Glasfaserverbindungen bis zu 500m ausgelegt, dadrüber benötigt
man ein etwas komplexeres Setup.

Mfg Marco

[DschingisKarn]

Hallo zusammen

Ich grabe hier mal was älteres heraus weil es mich aktuell beschäftigt.

Habe ich richtig verstanden das ich mit einer "ordentlich" konfigurierten, gespiegelten, SAN Umgebung unterbrechungsfrei arbeiten kann?
Ich dachte, wie der ursprüngliche poster, das dies nicht klappen würde, gerade wegen der wechselnden LUN.

Ich versuch mal zu beschreiben wie es bei uns derzeit aussieht.

Storage:2 x EMC NS42G und CX4-480C
Switche: 4 x DS-5000B
Hosts: 6 x FSC RX600S4
HBA: je 2 x LPe 1150

Jeder ESX geht mit je einem HBA an Switch 1 und 2.
Switch 1 ist mit Switch 3 über 2 Wege verbunden.
Switch 2 ist mit Switch 4 über 2 Wege verbunden.
Switch 1 und 2 sind jeweils mit zwei Ports an der 1. CX4 angeschlossen.
Switch 3 und 4 sind jeweils mit zwei Ports an der 2. CX4 angeschlossen.

1. Brandabschnitt
ESX Hosts
Switch 1 und 2
1. CX4
1. NS42G

2. Brandabschnitt
Switch 3 und 4
2. CX4
2. NS42G

Insgesammt habe ich zur Zeit 8 LUNs mit jeweils 500GB an den ESXen. Diese sind auch noch nicht gespiegelt.

Wenn ich nun weitere LUNs hinzu füge welche gespiegelt sind, eine VM auf diesen anlege und eine Seite (die aktive) fällt aus, was würde dann passieren?
Sollte das Storage intern so intelligent geschaltet sein das dies wirklich unterbrechungsfrei funktioniert?

Wenn mir ein HBA ausfällt bleibt das ja auch nicht ganz ohne folgen für die VM, immerhin waren ja die Platten weg. Folglich habe ich einen unerwarteten reboot meiner VM, auch wenn der zweite HBA recht schnell einspringt.
Oder habe ich einen fehler in meiner Konfiguration wenn mir bei einem HBA Ausfall die VM rebootet?

Sorry für diese vielen, und vielleicht auch langen, Fragen, aber dieses Thema ist doch mehr als umfangreich.

Gruß
Jochen

Nachtrag: Und ich hab es sogar hin bekommen die zugehörige Grafik hoch zu laden.

[mangold]

Der Ausfall eines HBA sollte nicht zum Ausfall einer VM führen, dafür sorgt eigentlich der Multipath Treiber des ESX Servers. Wie schnell der Multipath Treiber reagiert hängt aber u.A. davon ab, wo in der FC Anbindung die Trennung erfolgt, es macht durchaus einen Unterschied ob der SAN Controller, das Kabel zum Switch, der FC Switch selbst, das Kabel zum HBA oder der HBA selbst ausfällt. Das sind aber eher theoretische Betrachtungen, der Multipath Treiber sollte das abfangen.

Ein gespiegeltes SAN reicht nicht aus um einen unterbrechungsfreien Betrieb zu garantieren. Nur wenn der ESX Server keine Veränderung am SAN feststellen kann, würde der Betrieb aufrecht erhalten bleiben. Aber selbst wenn der Storage so schnell umschalten kann von passiv in aktiv, werden sich die WWNs ändern. Der ESX verliert die Connection, und wie Lange ein Rescan seitens ESX dauert, wissen wir ja leider alle. Wenn dein Host die gespiegelten LUNs mit identischen IDs an das ESX System weiterreichen kann, dann müssen die VMs nicht neu konfiguriert werden. Aber das kann auch nicht jedes gespiegelte SAN. Dafür gibt es den Vmware Disaster Recovery, ist sicher auch die erste Wahl wenn kein Synchroner Mirror vorhanden ist.

Wenn die Möglichkeit zum Synchronen Mirror besteht, würde ich eine Storage Virtualisierung empfehlen wie von Falconstore oder Datacore.

[storageguru]

Hallo Jochen,

also ein gespiegeltes SAN gibt es wohl bei EMC (habe bloß vergessen wie es heißt).
Bloß kann es nicht unterbrechungsfrei arbeiten. Hierfür gibt es verschiedene Lösungen

NetApp Metrocluster - Syncroner Spiegel über zwei Rechenzentren
SAN Virtualisierung mit Datacore oder Falconstore

Wenn du also einen Standortausfall abfangen willst, wirst du wohl kaum
an eine der beiden Lösungen dran vorbeikommen.

Bei NetApp ist es so, dass du in gewissen Disasterszenarios doch noch einen
Knopf drücken musst um dem Splitbrain zu entgehen. Wie das aber bei Datacore
oder Falconstore gelöst ist habe ich keine Ahnung.

Mfg Marco

[mangold]

Der Splitbrain Zustand ist natürlich immer der unangenehmste Fall, beide RZs laufen noch, denken aber, dass das jeweils andere weg ist. Somit konkurrieren beide um die Ressourcen was in heilloses Durcheinander ausartet, wenn man nicht händisch eingreift.

[Tschoergez]

Hi,

die Frage bei soner Architektur ist immer, was denn alles ausfallen sollen darf.

Inder beschriebenen Konstellation ist vom HBA im Server über die Fabric bis zum Controller im Storage alles redundant, d.h. da darf gerne eine Komponente ausfallen.

Um den Ausfall eines kompletten SANs (sowie ich das verstanden hab, meint Christoph ein komplettes Array inkl. aller Controller) transparent abzufangen, brauchts wohl ne Storage Virtualisierung ala Datacore oder Falconstor. Die fangen den Fehler im Array ab, und präsentieren dem ESX immer das ein Storage, egal ob das jetzt dahinter auf der einen oder der anderen Seite steht.

Der ESX kann übrigens ziemlich lange ohne Storage überleben, und auch bei den VMs geht das recht lange gut.
(Um das mal auszuprobieren: Baut ein NFS-Server in einer VM, legt ne andere VM auf diesem NFS-Datastore ab, lasst diese laufen und startet den NFS-Server neu. Diese Downtime von ca. 1-2minuten wird von der VM meistens nicht bemerkt, sie friert halt ein (also ohne Downtime gehts auch nicht).

Allerdings ist ein kompletter Ausfall eines Arrays meistens mit nem Ausfall eines ganzen Racks/Serverraums/Gebäudes verbunden, und sowas abzufangen ist wohl recht aufwendig. Ich kenn noch keine Umgebung, die sowas auf BAsis von VMware AUTOMATISCH antriggern lässt. Irgendjemand muss den Button drücken (so ist das ja auch beim VMware SRM).

Viele Grüße,
Jörg

[Drumcode2003]

Hallo zusammen,

mich würde auch interessieren, wie ich einen ESX Cluster über 2 RZs redundant betreiben kann.

Folgende Config:

9x ESX auf Blade (2x SAN)
1x HP EVA4400

Ich würde gern in RZ-2 ein weiteres Bladecenter aufbauen u. das SAN spiegeln.
Da bei der Spiegelung die LUNs, etc. identisch sind, sollte das eigentlich kein Problem sein.

Nun der schwierige Teil:

Wie schaffe ich es, dass die VMs in RZ1 + 2 parallel laufen. Also nicht nur redundant, sondern auch lastverteilt?

Ich möchte damit abfangen, dass eins der RZs komplett ausfällt.
d.h. die VMs in RZ1 werden dann autom. auf die laufenden Clusternodes in RZ-2 verschoben u. neu gestartet. (HA)

Klappt das?
Benötige ich eine spezielle Konfig. dafür?
z.B. jeder ESX Host hängt jeweils mit einem Bein an beiden SAN-Boxen ?

Danke für Eure Hilfe.

[mangold]

Als erstes solltest du ausprobieren, ob es dem ESX "wirklich" egal ist, ob die Lun von einem Storage kommt oder von dem anderen, d.h. ob er die VM findet OHNE manuell eingreifen zu müssen (vm neu konfigurieren oder gar neu registrieren) dann ist der erste Schritt schon mal geschafft. In der Regel ist es aber eben nicht so, deshalb gibts ja das VDR, welches dieses "Umkonfigurieren" für einen übernimmt.

Ich denke euer Storage ist A/P? Dann können natürlich VM nur auf einer Seite des SAN arbeiten, wenn die Anbindung zwischen den beiden RZs aber normal über FC läuft, spricht nichts dagegen die ESX Server auf der "andere" Seite ebenso mit dem Aktiven Storage arbeiten zu lassen.

Der Vorteil von Storage Virtualisierung ist aber, das man sich um solche Sachen keine Gedanken machen muss (im Vorfeld natürlich schon), der ESX Server sieht im Grunde gar nicht den physischen Storage selbst, sondern nur die virtuellen LUNS, wie sie physisch existieren ist dem ESX egal.

[MatZ]

*brrrr* HP "bladecenter" da grauts mir, das teil heist c3000, c7000, bladeenclosure, bladesystem, P-class, e-class, c-class aber bladecenter heist das IBM system

ok zu der problematik:

nr1: deine 2 EVAs hinter einem "storragegateway" kaskadieren die dir zur hostseite eine LUN vorspielen und dahinter aber die beiden evas mirror'n dh fällt dir eine eva aus übernimmt die andere, fällt dir ein RZ aus bleibt eine EVA und die hälfte der hosts über und HA greift ein und bootet die gedroppten VMs aus RZ1 in den hosts von RZ2

storragegateway könnte da AFAIK auch ein SANmelody-cluster sein, und nicht das große SANsymphony

nr2:
EVAs mit CA spiegeln und im VMware SRM (site recovery manager) alles einstellen nachteil allerdings: es wird nur eine EVA produktiv genutzt, es gibt beim down deiner produktiven eva eine downtime aller VMs und es dauert denke mal etwas bis alle scripte die LUNs und zonings umgetragen haben und die hosts auch wirklich die VMs finden und booten...


so wie ich das einschätze ist ein redundantes RZ immer etwas bastelei solange die ESX selbst noch nicht auf 2 storragesystemen ihre VMs verwalten...aber denke da wird sich bestimmt noch etwas tun bis es läuft...

woran ich im sommerloch mal rumtesten werde ist ob es möglich ist einen solaris-cluster zu bauen der auf 2 storragesysteme ein ZFS spannt und dann als iSCSI anbietet...es muss halt ein cluster sein und jede note muss in einem RZ stehen und jede storrage auch...mal sehn was da so kommt habe eine solaris iSCSI-kiste im einsatz und wenn das klappt kann man ohne teure lizenzen auskommen weder für SRM und CV bzw datacore lizenzen

ps:

ich denke aber auch wenn es ein komplettes RZ zerlegt mit all seinen redundanzen (ne 2C8D eva muss man erstmal kleinkriegen) dann hat man meist größere probleme
aber kunden wollen es immer wieder bis sie die arbeitsstunden und/oder lizenzkosten sehn...und wenn selbst dann der geldgeber nicht abgeschreckt ist kann man denke ich auch noch gratis anbieten aufgrund der distanz zwischen der beiden RZ zu berechnen wie groß der meteorid maximal sein darf der auf das firmengelände trifft...wenn man wirklich empfindliche dienste hat sollte man sich einen HP-nonstop cluster (unix oder VMS) bauen und die beiden im bunker eingebauten RZ darüber absichern

[Tschoergez]

Zur grundlegenden Diskussion über Verfügbarkeit und Paranoia der Kunden bitte hier lang:
http://vmware-forum.de/viewtopic.php?t=12235

Lasst uns doch hier in diesem Thread beim Thema gespiegelte SANs bleiben, und die Fragen nach Sinn und Unsinn auf den anderen Thread verschieben.

Zum Thema:
Um so etwas mal auszuprobieren, schaut doch mal auf www.xtravirt.com , die haben ein paar appliances, die via iSCSI gespiegeltes Storage präsentieren.
(sooo viele schöne Sachen out there, so wenig Zeit )

@Chris: Hattest Du ein bestimmtes Storage im Sinn, oder sind das eher grundlegende Fragen?

Viele Grüße,
Jörg

[bla!zilla]

*brrrr* HP "bladecenter" da grauts mir, das teil heist c3000, c7000, bladeenclosure, bladesystem, P-class, e-class, c-class aber bladecenter heist das IBM system

Ich will da nur kurz einhaken:

HP hat zwei Generationen: c-Class und p-Class. Innerhalb dieser Generation ist alles kompatibel. IBM hat nun allein schon vier oder fünf Enclosures auf dem Markt, wo auch immer wieder lustig dran gebastelt wird. Ich war ein Jahr lang im 3rd Level Serversupport bei einer Versicherung und habe da nur mit IBM gearbeitet. In der Zeiten kamen zwei Updates für die Powersupplies raus, weil neuere Blades mit größeren CPUs die Netzteile platt gemacht hätten (bei Vollausbau). Zu dem Zeitpunkt hatte IBM auch keine hot-swap Platten in den Blades. Sehr doof...

storragegateway könnte da AFAIK auch ein SANmelody-cluster sein, und nicht das große SANsymphony

Jein. SANmelody nur dann, wenn ich es komplett nutze. Die Proxy-Funktion bietet nur SANsymphony.

[Drumcode2003]

Also wir haben eine 2C6D + 1xc7000 mit 9 Blades ESX in einem RZ.

d.h. 2. Center mit 4 Blades im 2. RZ
altes Center mit 5 Blades im 1.RZ
die 2. 2C6D ebenfalls im 2.RZ

die beiden EVAs sollen gespiegelt werden. (Hardware)
Der Cluster läuft komplett auf der 1. EVA im RZ1, mit Hosts im 1. + 2.RZ.
Falls also ein Center in einem RZ ausfällt, übernehmen die restlichen Hosts im anderen RZ die VMs. Das sollte ja klappen.

Falls das SAN im RZ-1 ausfällt, habe ich den Spiegel im RZ-2.
Die Frage ist: was muss ich alles tun, damit die alle VMs anschließend auf der 2. EVA laufen?
Das Stichwort: SAN rescan auf den ESX Hosts fiel schon.

Was noch?
Die 2. EVA muss aktiv geschaltet werden, da es ja eine a/p Konstellation ist.
Die Switche sind alle miteinander verbunden. RZ1+ 2
d.h. ich müsste auf der 2. EVA eigentlich nur das Masking ändern, sodass die Hosts aus RZ-2 jetzt die LUNs der 2. EVA sehen?
Was fehlt mir noch?

[MatZ]

...also wenn du es von hand machen willst dann machs so:

RZ1:

c7000 - 2 brocades SAN-SW und 4 leitungen runter an die EVA(jeder brocade SAN-SW an einen EVA controller)

also wie normal...

RZ2:

wie oben

RZ1+RZ2 verbinden:

brocade switch A in c7000_RZ1 mit brocade switch A in c7000_RZ2
brocade switch B in c7000_RZ1 mit brocade switch B in c7000_RZ2

denk aber an die ID vergabe der switche...

danach:

zoning config, mach eine config inder die hosts die EVA in RZ1 sehen + EVAs sich gegenseitig und eine "backupconfig" auf der die ESX die andere EVA sehen + EVAs untereinander, leg alle hosts auf beiden EVAs schonmal an das spart zeit nachher wenns brennt...

configurier das CA unter den EVAs und sorg dafür das du in beiden RZ einen physischen CV server hast - evtl auch offline (wird gern ma vergessen ist aber im schadensfall essentiell)

ich glaub das wärs...

im normalbetrieb heist das alle deine hosts sind in einem cluster fällt dir RZ1 aus musst du nur deine zoningconfig2 auf den brocades aktivieren, den hosts die LUN im Commandview präsentieren rescan machen, und evtl von hand die VMs anstarten - HA greift halt nich in dem fall

ich denke mal das dieser worstcase vllt 5 min arbeit sind...aber ich würde mir dann auch noch gedanken machen wo man evtl die VMs SVmotion-iert im falle einer geplanten wartung ohne downtime - wenn du schon dabei bist könnte man das auch bedenken - ich würde ZB das CV aufheben, LUN EVA RZ2 löschen und neue bauen und SVmotion umziehen und dann entweder zurück zu schieben auf EVA RZ1 oder produktiv auf EVA RZ2 arbeiten und sich von der LUN dann mit CA dan spiegen ziehen, je nachdem ob du beide rechenzentren gleichberechtigt ansiehst oder es ein primär-sekundär-szenario gibt...

bla!zilla: ich mag die IBM blades wie auch die server nicht...falls es andersrum so geklungen hat sry aber ich wollt nur mal bemerken das HP blades nicht mit bladecenter verunglimpft werden sollten


edit:

du kannst allerdings auch schon das zoning für alle ESX freischalten und die LUNs nicht präsentieren bzw LUNs präsentieren und aber per zoning nicht zeigen, geht auch find ich aber unsauber und die 2 min machens dann auch nicht

[bla!zilla]

Das wird so nicht klappen... die ESXer werden das VMFS von der replizierten Vdisk nicht fressen, da ist eine Resignatur notwendig. Daran muss im Fehlerfall gedacht werden. Es ist in jedem Fall notwendig die Maschinen danach neu im Inventory zu registrieren.

Die ESXer können die passive EVA schon sehen, die LUN sehen sie eh erst nach einem Failover. Die Presentation musst du aber später machen. Du kannst das Zoning also komplett aufbauen, wie du es am Ende des Tages brauchst.

Bei der Verkabelung der EVA:

Controller 1 HP1 und Controller 2 HP2 an den ersten Switch
Controller 1 HP2 und Controller 2 HP1 an den zweiten Switch

CA Replikation würde ich über HP2 von C1 und C2 machen. Dafür musst du eine eigene Zone bauen.

IDs innerhalb der beiden Fabrics sollten klar sein.

[Drumcode2003]

mhh... hört sich nicht optimal für mich an.

1) Zone Config ESX-Server + 2. EVA aktivieren
2) ESX Server benötigen einen HBA rescan (ist klar)

Behalten die VMs im VC ihre Gültigkeit od. muss ich jede VM per "Add to Inventory"
hinzufügen?
Was mache ich mit dem VC ? Das ist momentan der SPOF.

CV sind bereits 2 Boxen an beiden Standorten.
Gibts einen Tipp wie ich alle VMs einschalten kann?
Gibts für die "geplante" Downtime auch einen Tipp, wie ich das Scripten kann?

Merci.

PS: Bladecenter od. bladeenclosure... anyway. Ich nutze beides.

[bla!zilla]

Wenn die Destination Vdisk online geht, musst du in jedem Fall ein LVM Resignature machen. Danach die VMs wieder importieren. Könntest du mit dem VMware SRM automatisieren, CA ist supported.

[mb64de]

Hallo zusammen.
Bin Neuling in dem Thema und brauche euren Rat zu Folgendem:
Geplant ist eine Hochverfügbarkeitslösung für unsere ESXe.
An 2 Standorten sollen jeweils 2 ESX Server, 1 Fabric, 1 Switch für VMotion 1 SAN installiert werden. Alle Verbindungen untereinander sind redundant ausgelegt.

Nun meine Fragen
1. Können die VMs beim Ausfall eines Host unterbrechungsfrei auf einen der drei anderen Hosts umziehen (VMWare Enterprise ist vorhanden)?

2. Kann ich - um eine Spiegelung der SANs zu erreichen nicht einfach in jeder VM eine Software-Spiegelung auf beide SANs einrichten oder brauche ich hierfür zwingend eine SDS-Lösung wie die von Datacore?

Matthias

[mangold]

1. Können die VMs beim Ausfall eines Host unterbrechungsfrei auf einen der drei anderen Hosts umziehen (VMWare Enterprise ist vorhanden)?

2. Kann ich - um eine Spiegelung der SANs zu erreichen nicht einfach in jeder VM eine Software-Spiegelung auf beide SANs einrichten oder brauche ich hierfür zwingend eine SDS-Lösung wie die von Datacore?

1. Nein, noch nicht, kommt mit der neuen ESX Version, derzeitiges HA heisst immer Absturz der VM und neustart auf einem anderen Host.

2. es gibt leider keinen Software Spiegeln unter ESX, so wie LVM unter AIX. Vor 2 Jahren war die Argumentation von Vmware:"das können die Storage Hersteller besser", sprich "wir wollen unserer Mutter EMC nicht das Wasser abgraben".

[mb64de]

2. es gibt leider keinen Software Spiegeln unter ESX, so wie LVM unter AIX. Vor 2 Jahren war die Argumentation von Vmware:"das können die Storage Hersteller besser", sprich "wir wollen unserer Mutter EMC nicht das Wasser abgraben".

Hallo mangold.
vielen Dank für die Antwort.
Bei meiner Frage zur Sowtwarespiegelung meinte ich NICHT eine Spiegelung Seitens ESX sondern eine Spiegelung innerhalb der Virtuellen Maschinen bei der ich zB.unter Windows 200X-Server je eine "Platte" der beiden SAN mittels Software-Raid1 spiegele.

[mangold]

das bringts leider nicht, denn die vmx files, also die Metadaten, liegen auf dem Storage AUSSERHALB der VM im VMFS Volume, und diese werden vom Gast OS ja nicht gespiegelt. Dir fliegt die VM also in jedem Fall um die Ohren, wenn das Volume mit der eigentlichen VM wegbricht. Aber einen Versuch ist es wert.

[Tschoergez]

Was Du hier natürlich machen kannst, ist mit 3rd-party Tools INNERHALB des Gast-OS eine VM in eine andere VM auf der anderen Seite zu replizieren.

Hersteller sind hier z.b. Doubletake, neverfail oder Steeleye....


Viele Grüße,
Jörg

[bla!zilla]

Bin Neuling in dem Thema und brauche euren Rat zu Folgendem:

Da solltest du dir Hilfe holen. Sonst solltest du von HA Sachen lieber die Finger lassen.

Geplant ist eine Hochverfügbarkeitslösung für unsere ESXe.
An 2 Standorten sollen jeweils 2 ESX Server, 1 Fabric, 1 Switch für VMotion 1 SAN installiert werden. Alle Verbindungen untereinander sind redundant ausgelegt.

Ich hoffe das deine Fabric aus zwei Switches pro Site besteht, oder? Wie lang ist die Strecke zwischen den Standorten, wie kommst du darüber und was für Switches setzt du ein?

Nun meine Fragen
1. Können die VMs beim Ausfall eines Host unterbrechungsfrei auf einen der drei anderen Hosts umziehen (VMWare Enterprise ist vorhanden)?

So nicht, nein.

2. Kann ich - um eine Spiegelung der SANs zu erreichen nicht einfach in jeder VM eine Software-Spiegelung auf beide SANs einrichten oder brauche ich hierfür zwingend eine SDS-Lösung wie die von Datacore?

Das ist i.d.R. nicht wünschenswert. Ich verstehe nicht warum das so oft eine Anforderung ist... Wenn dir eine Seite ausfällt, dann ist das ein K-Fall. Egal ob dein Storage stirbt (warum auch immer...) oder dein RZ abbrennt. Es ist ein K-Fall. Dafür gibt es hoffentlich Pläne, wenn nicht, erstmal die Hausaufgaben machen.

Ein seamless Failover mit DataCore ist in solchen Fällen machbar (habe ich als DCIE selber bei Kunden aufgebaut), aber es ist erstmal viel wichtiger zu schauen

- was ist passiert
- was ist betroffen
- sind die Daten konsistent die angekommen sind?

Gerade bei dem letzten Fall kann das zu echt dummen Effekten führen, wenn es nicht so ist. Der Schreibvorgang wird zwar erst dann an den Host bestätigt, wenn der IO auf dem zweiten SDS im Cache angekommen ist, aber trotzdem sind Inkonsistenzen, warum auch immer, nicht auszuschließen. Immerhin hast du auf der anderen Seite auch noch ESX Server, die auch noch Daten im Cache haben/ hatten. Wenn dir nur das Storage stirbt, passiert da nicht viel, aber wenn dir das RZ stirbt, dann sterben dir auch die Gäste. Die hatten Daten im Cache. Die sind verloren. Du hast Daten auf dem Storage, aber du weißt nicht genau von wann. Also erst prüfen, dann Anfahren.

Und in dem Fall tun es auch andere Lösungen als DataCore.