Verständnisfrage zu Open-E DSS Failover Replikation

[ta_jb]

Hallo,

wir planen die Installation einer möglichst redundanten ESX-Umgebung. Bei begrenztem Budget und nicht immensen Anforderungen an Leistung und Anzahl VMs erscheint mir iSCSI auf 1GbE-Basis bisher die beste Wahl.

In der ersten Ausbaustufe sollen zwei ESX4 (inkl. VMotion) zum Einsatz kommen. Als Storage-Lösung spricht mich bisher der DSS V6 von Open-E am meisten an. Vielseitig und flexibil einsetzbar, und das zu vertretbaren Preisen.

Um auch den kompletten Storage als SPoF auszuschalten würde ich gerne zwei DSS mittels Failover Replikation aufsetzen. Den aktiven Knoten mit (teuren) SAS-Platten ausstatten, den passiven Knoten mit günstigen und großen (500 oder 750GB) SATA-Platten und ggf. ein per SCSI angebundenes LTO-Tape oder eine Library. Der Kapazitäts-Überhang auf dem SATA-Knoten soll z.B. für zusätzliche VM-Backups mittels vRanger oder GhettoVCB genutzt werden. Diese könnte man dann zusätzlich aufs Tape und somit gänzlich extern sichern.

Lange Rede, kurzer Sinn: Ist ein Failover vom ersten DSS auf den zweiten wirklich ohne Ausfall und somit transparent für die laufenden VMs möglich? Ich muss prinzipiell gewährleisten, dass die VMs ohne Ausfall 24x7 laufen. Von geplanten Wartungen mal abgesehen.

Vielen Dank schon mal fürs Gedanken machen und lesen!

Gruß,
Jens

[storitback]

Hallo Jens,

ja das ist möglich. Die beiden DSS Server nutzen die gleiche IP-Adresse, die aber nur auf einem System aktiv ist. Fällt das aktive System (Master) aus, so wird auf das Slave System umgeschaltet (= die IP-Adresse wandert). Jetzt greifen die ESX auf den anderen Server, aber gleiche IP zu.
Es dauert natürlich eine gewisse Zeit, bis die DSS Server umschalten und solange muss es ESX (bzw. die VMs) verkraften. Die Default-Parameter passen da aber schon mal ganz gut. Das ESX merkt zwar, das die Platten weg waren (Log-Einträge) evtl. merkt es auch die VM, die Betriebssysteme sollten das aber solange tollerieren.

Zum Design:
Da synchron repliziert wird, sollten Master und Slave gleich ausgestattet werden. Die Schreib-IOs richten sich immer nach dem langsamsten System. Klar der Master muss zusätzlich auch die lesenden IOs verarbeiten (also eigentlich schnellere Platten), aber bei vielen Schreib IOs merkt man schon den "langsamen" Slave.

Und wichtig: Durch die synchrone Replikation wird das Gesamtsystem immer langsamer als ein Einzelsystem (das ist bei jedem Hersteller so). Auch das sollte beim Design berücksichtigt werden. Also lieber etwas mehr Speicher, ein etwas besserer RAID-Controller, etwas bessere Platten ...

Gruß
Stephan

[ta_jb]

Hallo Stephan,

das hört sich ja schon mal gut an.

Die Infos bzgl. der synchronen Replikation sind Gold wert. Wenn man etwas drüber nachdenkt liegt es irgendwie nahe, dass ein schneller Master alles nichts nützt wenn der Slave die Daten nicht zeitgleich auch wegschreiben kann.

Die Frage ist ja auch, ob die ohnehin sehr teuren SAS-Platten bei "nur" iSCSI-Anbindung überhaupt Sinn machen. Der aktuelle Plan sieht ein bzw. dann zwei Supermicro Chassis mit je max. zwöf Platten vor. Als RAID-Controller den Adaptec 5405Z, im Chassis ist ein SAS/SATA Expander integriert. Zwölf SATA-Platten (500 oder 750 GB) als RAID10 liefern immer noch (für uns ausreichende) 3 oder 4,5 TB brutto Kapazität. Der zu erwartende Durchsatz dürfte ja wohl immer noch weit über dem vom iSCSI liegen oder?

Seid ihr eigentlich Open-E Reseller bzw. habt ihr die Lizenzen im Angebot?

Gruß,
Jens

[storitback]

Hallo Jens,

na ja, das mit den SAS Platten ist immer so eine Sache. Bei sequentiellen Zugriffen ist kaum ein Unterschied zur SATA Platte, bei wahfreien Zugriff (Datenbanken) aber schon (sogar deutlich merkbar). Es kommt also auf die Nutzung an. Die reine Übertragungsrate von iSCSI (max. 80 MB/s) schaffen schon 4 SATA-Platten im RAID, das wäre kein Problem.

Wir sind auch Open-E Reseller (und auch Supermicro), das sollten wir dann aber persönlich besprechen (eine Mail ist gleich unterwegs).

Gruß
Stephan