VMware-Forum

Hallo,

wir möchten 2 Standorte, welche bereits ein gemeinsames SAN (2 fabrics á 4 Switche, Verbindung via 4x4G) und LAN (Cisco 3750E-Stacks, Verbindung via 2x 10G) haben.

Pro Standort gibt´s jetzt bereits je 1 bzw. 2 EVA3000-Systeme und einige ESX-Server (teils im Cluster, teils Standalone) und etliche Citrix, MS-Cluster etc. pp. Server.

Wir möchten die beiden Standorte (ca. 300m Luftlinie auseinander) nun redundant ausbauen. Die Basis dafür ist ja bereits da - doch wie geht´s weiter?

Es geht mir in erster Linie um die ESX-Landschaft, welche komplett redundant ausgebaut werden soll, so dass im Worst-Case binnen einer Stunde wieder alles rennt.

Auf welcher Basis würdet ihr das Ganze aufbauen? 2 große EVA-Systeme welche mit ContinuesAccess laufen und darauf klassisch ein HA-Cluster?

Danke & Gruß

Das ist halt die Frage... will ich ein Storage welches in Echtzeit repliziert und mich fragen wie es eine Konsistenz fuer das VMFS, die VMs mit ihren Guest OS Filesystem garantiert und wenn ja wie ich auf der DR Site das ganze dann gemountet und angefahren bekomme.

Oder aber moechte ich ein Datacore dazwischen welche somit dafuer sorgt das Konsistenz auf VMFS Ebene vorhanden ist weil der Commit erst kommt wenn auf beiden Seiten die Daten im Cache sind.

Oder aber moechte ich den VMware SRM einsetzen welcher zu definierten Punkten ein Replikat anstoesst.

Dann stellen sich noch so fragen ob man einen automatischen oder manuellen Failover will bzw. was zutun ist um den Cluster zurueck zuschwenken.

Antworten hab ich da keine.... aber ich freue mich schon auf die Diskussion bzw. Loesungen von einigen der anderen hier.

Gruss
Joerg

Hallo zusammen,

du hast ja schon eine klare Vorgabe bezüglich der Anforderungen gemacht, nämlich 1h Downtime als Worst Case Scenario.

Allerdings solltet Ihr neben dieser Vorgabe weitere Rahmenbedingungen prüfen bzw. definieren, einfach damit alle Beteiligten ein gemeinsames Verständnis für die Aufgabe entwickeln.
Meine Erfahrung bei so einem Projekt ist nämlich, das der technische Part die geringsten Probleme bereitet.
Vielmehr haben alle Beteiligten (Kunde, IT Management, Administratoren) ein völlig unterschiedliches Verständnis von "Verfügbarkeit", "Worst Case" oder "Wiederanlaufzeit".

Ohne klare und abgestimmte Anforderungen (SLA's) seitens des/der Kunden geht hier gar nichts, schließlich hängen davon unter anderem die zu erwartenden Kosten bzw. die erforderlichen Mittel ab.

Rein aus technischer Sicht gibt es die bereits von Joerg aufgeführten Verfahren, die alle die eine oder andere Stärke und Schwachstelle haben.

Da ich mal annehme, das du mit

so dass im Worst-Case binnen einer Stunde wieder alles rennt

die Applikationsebene meinst, bleibt für das Wiederherstellen & Anfahren der ESX Server nicht allzuviel Zeit.

Somit mußt du in jedem Fall durch eine remote Replizierung dafür sorgen, das die Daten in beiden RZ's vorhanden sind.
Mit EVA kenne ich mich nicht aus, aber ContiuesAccess hört sich genau danach an.

Mit SRM (und einem SRA für IBM EVA) bietet sich dir die Möglichkeit, Recoverypläne für den Ernstfall vorzubereiten und zu testen.
Damit kannst du im K-Fall direkt auf vorgefertigte und getestete Prozeduren zurückgreifen, um deine ESX Landschaft wieder auf die Füße zu stellen.
Allerdings ist SRM etwas spröde und gerade in dynamischen Umgebungen ziemlich unhandlich.
Kommen dann noch VM's mit RDM Devices hinzu, wird die ganze Sache schnell ziemlich unübersichtlich.
Zusätzlich brauchst du für das Testen der Recoverypläne zusätzliche Storagekapazitäten auf der Recovery Seite.

Datacore SANMelody kann dir deine LUN's direkt replizieren, es baut dir im SAN einen Spiegel über zwei Arrays auf.
Allerdings ist das auch nicht ganz trivial und je nach Last oder Umfang nicht ganz preiswert.
Außerdem hast du damit "nur" deine Daten gespiegelt, bei Ausfall einer Seite mußt du immer noch manuell eingreifen.
Und du hast eine weitere Kompnente, die administriert und gepflegt werden muß.
Im K-Fall kann das dann ganz schnell ganz schön hektisch werden.
Vorteil ist allerdings, das es nicht eine ESX only Lösung ist.

Dann gibt es noch die Möglichkeit, den Zugriff auf die (wie auch immer) replizierten LUN's mit Hilfe von Scripten zu regeln.
Davon würde ich aber in deinem Fall abraten, da dieser Weg erst recht eine saubere Dokumentation erfordert und daher extrem anfällig für Fehler ist.

Eine Empfehlung kann ich dir daher auch nicht geben, allerdings noch einen weiteren Hinweis.
Denke bei der Festlegung der Wiederanlaufzeiten daran, das du eventuell erst einmal in die Firma fahren mußt.
Schließlich könnte ja auch euer remote Access System vom Ausfall betroffen sein, und dann nützt die schönste Lösung nichts, wenn man den Knopf nicht drücken kann.

Hoffe, das hilft dir etwas weiter und bin schon gespannt auf weitere Kommentare auf deine Anfrage.

Gruß
Ralf

Hallo,

danke schon mal für das Feedback. War die letzten 2 Tage On-Tour, daher erst jetzt wieder eine Reaktion.

Ein Szenario mit SRM ist denke ich nicht das, wonach wir suchen. Wir möchten also schon eine echte Spiegelung zwischen den beiden Standorten haben. Und da eine Replizierung mit EVA CA hier wohl zwar funktioniert, jedoch keine Konsistenz gewährleisten kann (wie auch....), scheint eine Datacore Lösung wohl das Beste zu sein.

Eine Redundanz im LAN/WAN/VPN Bereich (+Remote) wird dann gegeben sein - das ist größtenteils schon der Fall, wird in den nächsten Monaten aber noch mal angepasst / überprüft.

Nach meinem aktuellen Stand, wird es um eine Redundanz von a) ESX-Servern bzw. deren VMs, b) XENserver alias XENdesktop und c) MS Clustern gehen.

Wie hoch im Detail die Downtime im Desaster-Fall sein wird, muss man schauen - angedacht (und mehr auch noch nicht) ist 1 Stunde ... dann sollen die wichtigsten Systeme wieder zur Verfügung stehen - den Arbeitsplätzen die noch nicht im Rauch stehen

Derzeit haben die EVA-Systeme ~20TB brutto bzw. ~15TB netto (vDisks) Speicherplatz - um eine ähnliche Kapazität wird es bei dem Projekt wohl auch gehen.
6TB ESX / 4TB Cluster / Rest "diverses" (Citrix, Stand-Alone-Server, etc.)

Da es sich im Moment nur um EVA3000 handelt, würden wir auf jeden Fall entweder ein Upgrade auf EVA4x00 machen oder gleich 2 neue Systeme hinstellen.

Ich werde wohl mal Kontakt mit Datacore aufnehmen und schauen was die so dazu sagen.

Was sagt ihr dazu? Ist das so realisierbar bei den Datenmengen? Welche Produkte von Datacore wären wohl angesagt? HA (teilw. FT) sollte doch ausreichen, um hier flott wieder Online zu sein, oder sehe ich das falsch?

Gruß

Hi,
ich habe sowas mal bei einer Präsentation gesehen. Die haben damals vor die beiden SANs jeweils eine FalconStor IPStor Kiste geschaltet, die wenn ich mich recht entsinne

http://www.argus.de/stv/brochures/falconstor_nss.pdf

Vieleicht Hilft dir das weiter bei deinen Überlegungen.

Gruß Peter

Mal mein Send als Master ASE und DCIE für SANsymphony:

Redundante Serverräume sind eine Kunst. Vor allem dann, wenn es darum geht im Fehlerfall ohne große Änderungen am Routing etc. wieder anfahren zu können.

Punkt 1: Storage.

Replikation != Spiegelung. Bei einer Replikation werden Daten über andere Protokolle übertragen, zwischendurch ändert sich also das Transportprotokoll. Daher sind Replikation i.d.R. auch nur dafür gedacht, Daten an einen anderen Ort zu schaffen. Spiegelungen sind da eine Nummer schärfer: Hier werden Daten gespiegelt, das Protokoll bleibt gleich und i.d.R. ist das so ausgelegt, dass im Fehlerfall alles weiterläuft, wenn ein Spiegel wegbricht. Ob nun synchron oder asynchron gespiegelt wird, hängt hauptsächlich von der Länge der Leitungen ab. Irgendwann sind die Signallaufzeiten so lang, dass die Maschinen zu lange auf ein ACK für einen IO warten müssen. Der kommt bei einer synchronen Spiegelung erst dann, wenn der IO auf dem Spiegel im Cache angekommen ist. Das kann bei langen Leitungen dauern.

HP Continuous Access EVA wird pro TB lizenziert. Damit ist eine synchrone und asynchrone Spiegelung von EVAs möglich. Dazu kommen so Nettigkeiten wie Mirrorclones. Automatisiert werden kann das über HP Replication Solution Manager oder VMware SRM. Die übernehmen im Fehlerfall den Failover und steuern alles so, dass die Server die Volumes sehen etc. Dafür brauchst du aber zwingend VMware SRM! Microsoft Cluster, HP Serviceguard etc. lassen sich über die Clustere Extension EVA automatisieren.

DataCore SANmelody/ SANsymphony bauen einen synchronen Spiegel auf. SANmelody geht aber nur bis 32 TB. Darüber muss man SANsymphony nehmen. Die Spiegelung ist völlig transparent für die Hosts. Für die sind die SDS quasi die Speichersysteme. Aber man muss beim Setup etwas aufpassen, da man sich sonst die Performance versauen kann. Wenn DataCore mit einen dynamic-striped NVM Pools daherkommt und auf eine EVA trifft, dann kann Striping+Striping schon mal schnell in mieser Performance enden.

Punkt 2: Netzwerk.

Habt ihr euch mal Gedanken um euer Netz gemacht? So einfache Dinge wie redundante Router per VRRP, campuswide VLANs etc? Wenn nicht: Das ist die Basis. Bricht euch ein RZ weg, muss das Netzwerk trotzdem weiterhin stehen. Viele Kunden fixieren sich zu sehr auf Storage und Server und vergessen dabei das Netzwerk.

Der Verfügbarkeit der Daten setze ich nahezu gleich mit der Verfügbarkeit des Netzes.
Mit den Cisco's seid ihr schon ganz gut bedient, verwendet ihr auch Cisco Router? Die Failover-Eigenschaften sind einfach das beste was ich kenne! Wir haben für Failover der der Netzwerkräume einen doppelten FDDI-Ring verwendet, ich weiß nicht inwiefern das bei euch interessant wird, aber was nützen die Daten, wenn man sie nicht ausliefern kann...

Was haben Cisco Router damit zu tun? Wer routet denn heute noch in solchen Netzen über Router? Und FDDI ist schon seit 10 Jahren out-of-date. Dinge wie VRRP und MSTP sind offen und nicht propretär, wie z.B. HSRP von Cisco.

Hallo zusammen,

wie schon erwähnt, kann man das Netzwerk bereits als Redundant bezeichnen - das wird aber nun nochmal im Detail geprüft & ggf. korrigiert.

Wir werden das gewünschte Scenario nun kurzfristig mit Datacore aufbauen und grob durchtesten - wenn alles wie gewünscht läuft, wird´s angeboten und parallel der DCIE in Angriff genommen.

...to be continued.

Gruß

HA-Umgebungen dürfen eh nur von einem DCIE installiert werden.

...eben drum

Hallo nfbe,

nur so als kleiner "Einwurf":

Netzwerkseitig scheint ja bei euch schon alles "Paletti" zu sein und die Frage zum Storage hast du ja
eigentlich auch schon beantwortet aber dazu trotzdem noch ein kleiner Hinweis von mir:

Hast du dir schon mal NetApps (falls das eine Option sein könnte) MetroCluster inklusive SyncMirror angeschaut?

Haben wir bei uns im Einsatz, und ich kann aus Erfahrung nur sagen, dass man sich definitiv keine
Sorgen um Inkonsistenzen machen muss, wenn mal eine Seite weg ist (schon erlebt)
Dabei sei noch erwähnt dass auf den Maschinen sowohl VMFS als auch RAW Luns laufen und zusätzlich
(hat zwar nix mit LUNS und oder ESX zu tun) per CIFS Fileshares gehostet werden.

Ist zwar im Zweifelsfall nicht ganz billig, und auch davon abhängig, auf welche
Art und Weise die beiden Standorte Netzwerk bzw. SAN technisch verbunden sind,
lässt den Admin aber sehr sehr gut schlafen

Gruß Stefan

Sorgen um die Konsistenz der Daten muss man sich bei JEDER Lösung machen. Nichts ist fehlerfrei, alles kann passieren. Das ist Marketinggeschwätz. Sorry...

hi bla!zilla,

im CIFS Bereich will ich dir Recht geben, auch da ist ist der Cluster Failover nicht ganz Ruckelfrei, aber was den reinen SAN Bereich angeht,
(sofern die Timeouts der HBAs und auch in den Gast Betriebssystemen passen) kann ich dir nur aus Erfahrung berichten, dass es,
zumindest bei unserer Konfiguration, kein Problem ist.

Hängt aber wie gesagt immer dran wie die Konfiguration aussieht.
In dem Zusammenhang würde mich allerdings interessieren, was du z.B. meinst mit "alles kann passieren"??

Das was ich schon live gesehen habe war, dass auf einen Schlag eine komplette Seite (Storage Cntroller inklusive Shelfs) weg war
(Stromausfall, und leider hatte irgend jemand die Anschlüsse in dem betroffenen Schrank von der USV runter genommen ;=(( ) und
alles lief (konsistent) ohne manuele Eingriffe weiter (SQL Server Notes Server etc. pp.) da die Maschinen gar nicht merken,
(bis auf die kurzfristig längere Antwortzeit), dass einer der Storage Controller weg ist, weil der Partner Controller die Funktionen transparent übernimmt.


Gruß
Stefan

Moin, moin,

ja sowas feines kannst Du Dir auch mit Open-e bauen, viel Spaß beim Finger brechen

Aber wie bla!zilla schon sagt, ohne Fehler ist nichts (und wenn's der Dödel an der Tastatur war ).

Wenn der Dödel an der Tastatur Fehler macht...
... da ist natürlich kein Kraut gegen gewachsen.

Die Frage war ja auch eigentlich welche Möglichkeiten der redundanten Auslegung des Storage bestehen.
Und dementsprechend habe ich nur den Hinweis auf ein (meiner Erfahrung nach) sehr gut funktionierendes Konstrukt gegeben.

nicht mehr und nicht weniger :=)

Nur, wie oben bereits erwähnt, gibt es Möglichkeiten den Ausfall einer Storage Seite
unbeschadet zu überstehen, und das dürfte, je nach Aufgabe einer Umgebung, relativ
schwer wiegen.


Gruß Stefan