praktische Erfahrungen SRM?

[mangold]

moin,
hat hier jemand praktische, langfristige Erfahrung mit SRM?

Hintergrund; Der Storage bleibt immer wieder SPOF. Ein Storage mit Spiegel ist vorhanden, die Umschaltung auf den Spiegel im Falle eines Ausfalles des Aktiven Storage Kopfes gestaltet sich aber nach einigen Test als sehr Aufwändig und Fehler trächtig. Fazit war; wir haben zwar eine synchrone Kopie unserer VMs aber dem VMware System beizubringen im Failoverfall diese auch zu nutzen, ist ziemlich kompliziert. In der Theorie schaltet man den aktiven Storage auf den Spiegel, Scannt die HBAs damit die neuen Pfade erkannt werden, registriert die VMs über die neuen Pfade und fährt die Wieder hoch. In der Praxis bekommt der ESX nicht wirklich mit, dass der Storage ausgefallen ist, "glaubt" immer noch, dass die VMs laufen (was sie natürlich nicht tun), so dass die VMs nicht neu registriert und neu gestartet werden können-

Storagevirtualisierung kommt (leider) nicht in Frage. Was bleibt? SRM scheint genau in diese Bresche zu schlagen.

Nun will ich aber wissen ob sich die Ausgabe lohnt, ob man damit im Desaster Fall (z.B. Ausfall eines RZs) ein zuverlässiges Tool erhält, und man sich kein Moloch ans Bein bindet, welches einem die Arbeit unnötig erschwert.

[bla!zilla]

SRM ist auch nur ein Tool, welches Fluch und Segen sein kann. Wenn es funktioniert, dann ist es sehr nett, muss aber vom Speichersystemhersteller auch unterstützt werden. Also vorher brav die HCL durchschauen.

Die Liste ist recht aktuell, da sind alle Storagesysteme gelistet, die unterstützt werden.

[mangold]

Interessant, in der HCL stehen unter EMC (handelt sich um ne EMC Symmetrix) nur NFS und iSCSI als Protokolle, keine FC. Etwas irritierend, dass gerade die Symmetrix von EMC nicht drin sein soll. Aber nochmal danke für den Tipp, werde nochmal klären lassen, ob alle Voraussetzungen im Storage erfüllt werden, obwohl es der Storage Betreiber (leider nicht mehr ich selbst) damals bestätigt hat.

Ich bin ja schon froh, dass ich bei Ausfall eines Storages nicht die Restores von 100 VMs anstoßen muss, auch wenn ich die Farm komplett neu starten muss, aber ein kontrollierter, geplanter Mechanismus wär wir dennoch lieber.

Das mit dem Fluch und Segen ist eben so ne Sache, hängt davon ab, was davon man mehr bekommt.

[kastlr]

Hallo,

für EMC Symmetrix Storage gibt es definitiv SRA's zum SRM in Verbindung mit FC.

Hier mal ein paar EMC Links zu diesem Thema.
     TechBook: Using SRDF Adapter for VMware vCenter Site Recovery Manager
     SRDF Adapter for VMware Site Recovery Manager Release Notes
     Using EMC Symmetrix Storage in VMware Infrastructure and vSphere Environments

SRM selber ist eigentlich nur eine grafische Oberfläche für eine ganze Menge Scripte, welche die Umgebung im Test/K-Fall steuern.
Der wichtigste Punkt ist eigentlich, das SRM im K-Fall manuell aktiviert werden muß.
Soll heißen, ein berechtigter User verbindet sich mit dem SRM und startet die Recovery Prozedur(en).
SRM führt dann alle weiteren Schritte selbständig durch.

Das kann gerade bei rigiden SLA's zu Problemen führen, wenn der K-Fall außerhalb der normalen Arbeitszeiten auftritt.

Ansonsten ist SRM nach meiner Ansicht während der Einrichtung etwas spröde, speziell wenn du eine größere Umgebung mit unterschiedlichen SLA Anforderungen damit abdecken mußt.
Sofern sich die Änderungsrate in Grenzen hält, ist das alles aber nicht wirklich ein Problem.

Wahrscheinlich kennst du das folgende Dokument bereits.
     VMware vCenter™ Site Recovery Manager:Performance and Best Practices for Performance

Falls du noch weitere Infos benötigst, einfach posten.

Viel Spaß bei der Lektüre
Ralf

[mangold]

Die Arbeitsweise von SRM ist mir in den Grundzügen bekannt, auch das kein automatisches Failover erfolgt. Soll ja im Desaster Fall genutzt werden und nicht regelmäßig. SLAs sind in der Tat ein wichtiges Thema, aber eher intern zu klären Wie ich schon sagte, Storage virtualisierung mit Transparentem Failover wär mir lieber (auch wenn dabei Vieles zu berücksichtigen ist) aber leider kein Thema mehr.

Mir gehts um praktische Erfahrungen, natürlich auch bei der Einführung, vor allem aber auch im normalen Alltag.

Auf der anderen Seite betreibe ich VMware Farm selbst als quasi Dienstleister, die Zeite als ich noch fast alle VMs eh selbst betreut habe, sind vorbei. Die Abhängigkeiten der VMs sind hier kaum Dokumentiert, ich erhoffe hier durch den Zwang das erfassen zu MÜSSEN auch in diesem Bereich Besserung.

Wie du schon geschrieben hast, im Grunde laufen vor geplante Skripte ab, das ist mir wichtig, dass in in einem K Fall nicht noch überlegt werden muss welche Schritte als nächstes zu tun sind, auch wenn so was natürlich in einem regelmäßig gepflegten Betriebshandbuch dokumentiert sein sollte

[kastlr]

Nun ja, mit praktischen Erfahrungen ist das so eine Sache.

Im SRM Umfeld steht und fällt das nun mal mit einer sauberen Arbeitsweise.
Da SRM beim Erstellen der Recovery Pläne die Abhängigkeiten überprüft, ist dieser Teil relativ simpel.

Aber wenn ich deinen Post richtig interpretiere, werden die VM's von einem anderem Team verwaltet, während du für die SRM Administration zuständig bist.
Somit besteht die latente Gefahr, das sich im K-Fall wichtige VM's eben nicht starten lassen, da vom Team vorgenommene Änderungen durch dich noch nicht in SRM übernommen wurden.

Interessant wird es nämlich immer dann, wenn z.B.

- mit SRM geschützte VM's neue Disks bekommen, die auf ungeschützten Datastores liegen,
- VMware Admins mit sVMotion VM's auf ungeschützte Datastores verschieben,
- VM's mit pRDM's eingesetzt werden,
- neue VM's erstellt werden, welche in einer Abhängigkeit zu von SRM geschützten VM's stehen,
- geschützte VM's in neue Port Gruppen verschoben werden,
- die ESX Umgebung wachsen muß und aus Kostengründen erst einmal nur in einem RZ neue Server installiert werden, so das eine neue Bewertung der SRM Umgebung stattfinden muß.

Das ist alles kein Hexenwerk, allerdings findet dabei keine erneute automatische Prüfung durch SRM statt, dies obliegt dem Administrator.

Und dann kriegst du als Dienstleister die Torte ins Gesicht, egal ob du verantwortlich bist oder nicht.
(IMHO ist das einer der Gründe, warum Firmen auf Dienstleister setzen, die kann man so schön quälen )

Und ein Riesenthema ist dabei noch gar nicht berücksichtigt worden, wie komme ich wieder zurück, wenn der K-Fall beendet ist!
Das erfordert nämlich einen nicht unerhebliche Aufwand und läuft aktuell nicht automatisiert.

Alles in allem ist das ein ziemlich komplexes Thema, das
     eine saubere Arbeitsweise auf Seiten der Admins sowie
     klare Ansagen über die Erwartungshaltung sowie die technischen Möglichkeiten
erfordert, damit nicht im Anschluß das beliebte Finger Pointing losgeht.

Bin mal gespannt wie das hier weitergeht.

Gruß
Ralf

[mangold]

danke nochmal für deinen Beitrag,
habe mich aber wohl missverständlich ausgedrückt. Die VM innerhalbs des VMware System werden ausschließlich durch mich und einen Kollegen betreut. Das "nicht betreut" bezieht sich auf die Inhalte der VMs, nicht auf die VM im Sinne des Hypervisors. Da konfiguriert keiner rum, zum Glück. Dienstleister bin ich also in dem Sinne, dass ich für die interne IT Server zur Verfügung stelle, in denen BS und Applikationen in _einigen_ Fällen nicht von mir kommen. Bei 130 VMs ist das sicherlich verständlich, wenn man nebenbei noch etwas anderes machen soll.

Ich meinte vielmehr die Abhängigkeiten im Sinne von, welche VM muss zuerst wieder hergestellt werden, bevor die andere VM gestartet werden darf.

Und ein Riesenthema ist dabei noch gar nicht berücksichtigt worden, wie komme ich wieder zurück, wenn der K-Fall beendet ist!
Das erfordert nämlich einen nicht unerhebliche Aufwand und läuft aktuell nicht automatisiert.

Davon habe ich auch gehört, und soll angeblich für einige Kunden ein K.O. Thema gewesen sein, kannst auf dieses Problem näher eingehen?

[kastlr]

Das liegt größtenteils an der Art und Weise, wie VMware den SRM entwickelt hat.
Nach meinem Empfinden haben Sie den Failback einfach vergessen, somit ist das aktuell "works as designed".

Das soll jedoch in der neuen SRM Version behoben sein.

Technisch spielen da genau die Punkte eine Rolle, die SRM verwendet, um den FailOver durchzuführen, wie z. B.

- Nutzung von Placeholder VM's im VC des Ausweichs RZ für jede geschützte VM
- Resignature aller geschützten Datastores im Ausweich RZ und anpassen aller Komponenten an die neuen Signaturen (z. B. in den *.vmx Dateien)
- kein Clean Up des produktiven VC, wenn dieser wieder zur Verfügung steht (VM's sind immer noch registriert)

Wenn dein produktives RZ wieder verfügbar ist, hast du daher einen unsauberen Zustand, der erst durch manuelle Clean Up Tasks ein Rückschwenk erlaubt.
Und damit haben halt speziell Firmen zu kämpfen, die im Ausweich RZ nicht über ausreichend

- Serverblech
- Storageperformance
- LAN Bandbreite
etc.

verfügen.

Die wollen natürlich schnellstmöglich zurück ins andere RZ, aber das muß dann alles manuell durchgeführt werden.
Und da fehlt es halt oft am erforderlichen Know How, zumal ja auch noch der Storage Part hinzukommt, schließlich muß auch dort ein Failback durchgeführt werden.

Aber wie gesagt, VMware hat das erkannt und will das offenbar im nächsten SRM Release umsetzen, da dieser Funktionsumfang vielfach gefordert worden ist.

Hoffe, das hilft dir weiter.

Gruß
Ralf