VMware-Forum

Hallo,

ich habe da mal ein paar Verständnisfragen.

Wir planen momentan unseren ESXi4 Hypervisor durch eine vSphere Umgebung zu ersetzen und die Virtualisierung weiter voranzutreiben.

Dafür haben wir für den ersten Step folgendes geplant:
1x DELL Server mit 2x Intel E5530 CPU und 96GB Ram, 6x 1Gb/s Nic
1x HP Server mit 2x Intel E5560 CPU und 96GB Ram, 4x 1Gb/s Nic (ist der vorhandene ESXi4 Server)
2x HP P2000 4x 1Gb/s iSCSI
2x HP Remote Snap Software für die Replikation

Die Hälfte der Hardware steht jeweils in durch mehrere Brandabschnitte voneinander getrennte Serverräumen. Ziel ist es, dass ein Serverraum komplett ausfallen kann und die wichtigsten Dienste per FT weiter laufen und der Rest durch HA neugestartet wird.

So, nun meine Fragen:

1. Wenn ein HP P2000 ausfallen sollte sind die Daten ja durch die RemoteSnap Software auf das andere P2000 gespiegelt. Wie binde ich die beiden Systeme jetzt in vSphere ein, sodass bei einem Ausfall automatisch das andere P2000 genutzt wird?

2. Die wichtigsten VMs sind ja durch FT geschützt, der Rest durch HA. Wofür wird dann der Site Recovery Manager genutzt? Welche Vorteile/Ergänzungen bietet er gegenüber FT/HA?

Vielen Dank schon mal und viele Grüße
Christian

Automatisch geht bei den Remotesnaphsots der MSA P2000 gar nichts. Aber du kannst das per SRM automatisieren.

Danke für die Klarstellung. Gibt es denn andere Storagesysteme, die das können? Und falls ja, liegen die dann noch in einer ähnlichen Preisklasse wie die HP P2000?

Wie schnell ist eigentlich SRM mit der Anbindung des zweiten Speichersystems, wenn das erste ausfällt? Kann ich da ähnliche Reaktionszeiten wie bei Fault Tolerance erwarten, bzw. wie verhält sich FT mit SRM wenn sowohl der Host als auch das Storagesystem wegbricht und beides auf die Redundanten Hardware geschwenkt werden muss?

Wenn SRM zuschlägt, dann ist deine Primary Site auf die Nase gefallen. Da laufen keine VMs mehr... SRM automatisiert dir den Prozess des Anbindens der Datastores, Registrierung der VMs etc.

Wenn du einen transparenten Failover haben willst, dann suchst du etwas in Richtung DataCore SANsymphony-V, evtl. HP EVA mit CA, NetApp Metro-Cluster und Co.

bla!zilla hat geschrieben:Wenn du einen transparenten Failover haben willst, dann suchst du etwas in Richtung DataCore SANsymphony-V, evtl. HP EVA mit CA, NetApp Metro-Cluster und Co.

Und diese liegen nicht in der Preisklasse einer P2000

Wenn du deine Hardware weiterverwenden willst, ist DataCore evtl das richtige, evtl IBM SVC

Hrm, das dachte ich mir schon

Vielleicht sollte ich noch erwähnen, dass wir bis auf den HP Server noch keine HW für die Virtualisierung angeschafft haben. Ich möchte verschiedene Lösungen präsentieren, die sich halt in Preis und Level der Verfügbarkeit unterscheiden.

Was ich noch nicht so ganz verstanden habe ist, was SRM macht/machen kann bei dem Ausfall eines Serverraums.

Storage und ESXi Host brechen ja dann gleichzeitig weg. Kann dann der replizierte Storage an dem noch verfügbaren Host registriert werden und durch FT laufen die kritischen VMs weiter?

Du brauchst schon Hosts und ein vCenter in deiner secondary Site. SRM automatisiert für dich den Failover. Aber die VMs fallen erstmal alle auf die Nase.

Und wenn Du wirklich ne Menge Kohle für eine kleine wirkliche Windows-Mirrored-Umgebung auszugeben, wäre es vielleicht auch interessant das Konkurrenzprodukt XEN mit Marathon mit einzubeziehen. Multi-CPU FT, zwei Potente Standard-Server mit Discs, das wars, mehr brauchts da nicht. Zbsp. für alle kritischen Server. Die weniger kritischen könnten ja auf ein VmWare-Cluster mit 'normalem' Storage.

Vorteil: Keine teuren Storages, keine komplizierte Umgebung, es kann ausfallen was will, die VM's laufen weiter. Sogar Storage von Node 1 und zbsp. netzwerk von Node 2. Dann geht Netzwerk über Node 1 und den Storage-Part holt er sich von Node 2. Das ist dann Level 2. Level 3 ist dann wenn der Host die grätsche macht. Imho ziemlich genial, vor allem weil richtiges Storage-Mirror quasi out of the box geht. Sogar mit der Express-Variante. Zumindest für klein-Umgebungen imho sehr geeignet.

Nachteile: Weniger gute Community im Fehlerfall --> Guter Partner notwendig (wüsste einen, der macht sehr viele solcher Umgebungen für Gebäude-Zugangssysteme)