VMware-Forum

Hallo zusammen,

ich stehe vor einem recht interessanten Problem.
Unsere Firma setzt eine nicht cluster-fähige Anwendung ein, die aus mehreren eng verzahnten Modulen besteht. Zielsetzung ist es diese Anwendung ausfallsicher zu implementieren. Sollte nachfolgendes Scenario praktibabel gelöst werden können, hätten wir ein Verfahren auch nicht cluster-föhige Anwendungen im Cluster ausfallsicher betreiben zu können. Zielsetzung ist es nicht unbedingt, dass die Anwender vom eventuellen Ausfall nichts bemerken. Eine Ausfallzeit von ein paar Minuten ist für mich durchaus aktzeptabel.

Meine Idee war es nun GSX auf den 2 Knoten des Windows 2003 Enterprise Cluster zu installieren, und die Anwendung samt einem Win2003 Standard Server in VMware zu virtualisieren. Host-System sind also 2 Knoten Windows 2003 Server Enterprise im Microsoft Cluster Verbund und Gast Windows 2003 Server Standard. Die VMDKs möchte ich in das Shared Storage des Clusters legen. Die VMware-Sitzung des Gast-Servers soll aus Custer-Sicht aktiv/passiv laufen, d.h. immer nur ein Knoten hat Zugriff auf die vdmk im Shared-Storage.

Frage 1: Ist das oben beschriebene möglich?
Frage 2: Wenn ja, kann die VMware mit ihrer Snapshot- und Script-Technologie insofern gesteuert werden, dass bei Ausfall eines Knotens die VMWare auf dem verbliebenen Knoten wieder gestartet werden kann?
Frage 3: in wie weit kann ich vor dem Start der VMware auf dem verbliebenen Knoten sicherstellen, das das File-System im Gast noch konsistent ist?

Ich hoffe ich hab nix vergessen und ihr könnt mit meiner Beschreibung etwas anfangen. Sollten wir hier gemeinsam zu einer praktikablen Lösung kommen wäre das doch eine universell einsetzbare Lösung zur Bereitstellung einer Software im MS-Cluster-Betrieb, wodurch sich die Vorteile von VMware und MSCS verbinden liessen.

Vielen Dank schonmal im voraus für eure Antworten
Grüße
StKr

Hi
wie oft willst du die einzelnen GSX bzw VMs booten - taeglich oder nur wenn es nicht anders geht?
Wie regelst du die backups?

Irgendetwas in mir wehrt sich gegen vmdks auf einer shared-disk. Angenommen du startest die VMs regelmaessig neu - dann koenntest du auch REDOs in die shared-disk legen und die vmdks jeweils lokal oder auf einem fileserver speichern - haettest aber jeweils aktuelle REDOs in der shared-disk.

Wie konsistent vmdks nach einem crash sind haengt sehr von der Art des crashs und dem timing ab. Mal ist die vmdk unbrauchbar - extrem unwahrscheinlich bei NTFS mal ist sie zu 100% ok. Je aktiver die VM zum Zeitpunkt des crashs umso wahrscheinlicher sind Fehler.

Hi Continuum,

erstmal vielen Dank für Deine Antwort

Wie oft die VMs gebootet werden sollen ist noch offen.
Es spricht nichts dagegen, die VM jede Nacht zu booten, wenn es denn notwendig ist. Nächtens wird nicht gearbeitet und wir haben da ein Zeitfenster von mehreren Stunden, welches auch für Backups genutzt wird.

Backups wollte ich mit dem schon im Einsatz befindlichen Brightstor Arcserve 11 realisieren über Client-Agent innerhalb der VM. Gibt es da Probleme? Diesen brauche ich nur um eventuell einzelne Files aus der VM wieder restoren zu können. Zusätzlich wollte ich noch die komplette vmdk sichern. Brightstor bietet hierfür mittlerweile auch einen Agent an, der erlaubt laufende VMs zu sichern. Soweit ich gelesen habe nutzen die eine Mischung aus der Snap-Technologie von VMware und VSS von W2K3. Muss ich mich aber noch genauer mit befassen.

Jetzt erstmal ein kleiner Exkurs zum Thema MS-Cluster, damit wir auch alle vom gleichen sprechen
Im MSCS organisiert man sogenannte Cluster-Gruppen, die wiederum aus sogenannten Cluster-Ressourcen bestehen. Eine Cluster-Gruppe besteht immer aus mehreren Ressourcen, wie z.B. einem physikalischen (!) Datenträger (zumindest aus Sicht des OS, in meinem Fall ein logisches Laufwerk im SAN), einer IP-Adresse, einem Netzwerk-Namen. Dies sind die MUSS-Ressourcen, die auch in Abhängigkeit zu einander stehen. Machen wir mal ein einfaches Beispiel: Ausgangsbasis ist ein 2-Knoten-Cluster als File-Server:

Cluster-Gruppe "File-Server":
- Datenträger F: (liegt im shared Volume) (MUSS)
- IP-Addresse des virtuellen File-Server (ist abhängig vom Datenträger) (MUSS)
- Netzwerk-Name (ist abhängig von IP-Adresse) (MUSS)
- Share (ist abhängig von Netzwerkname, IP und Datenträger) (KANN, je nach Rolle, die die Cluster-Ressource spielen soll. Hier Fileserver, daher Share)

Fällt nun eine oder mehrere Ressourcen aus, bzw. der Knoten der diese Gruppe gerade hält, versucht der MSCS die gesamte Gruppe erst neu auf diesem Knoten zu starten, schlägt dies fehl (was in 99% der Fälle so ist), wird versucht die gesamte Gruppe auf dem zweiten Knoten neu zu starten.
Der Datenträger wird durch den Cluster-Dienst so gesteuert, dass immer nur der Knoten, der diese Cluster-Instanz gerade hält, Zugriff auf diese hat. Ein gleichzeitiges Schreiben von beiden Knoten aus auf den Datenträger ist somit ausgeschlossen.

Soweit die Basics:
Ein weiters Feature ist die Möglichkeit, in einer Cluster-Gruppe Scripte zu hinterlegen, die bei einem Failover ausgeführt werden sollen. Hier kommt dann der für VMware interessante Teil.
Jeder Knoten hat seine eigenen lokalen Platten, auf denen auch das OS liegt. Nur die Platten der Cluster-Gruppen liegen im shared Storage, hier SAN. Mein Gedanke war der, dass VMware auf beiden Knoten lokal installiert ist und die vmdk im SAN, damit sie jederzeit von beiden Knoten aus verfügbar ist (nochmal: nicht zeitgleich, sondern immer nur vom aktiven Knoten aus). Jetzt müssten wir doch nur noch ein Script schreiben, dass
a. den Status der laufenden VM prüft (hab da glauibe ich schon was in den Sample-Scripts gesehen (hbcheck.pl).
b. die VM runterfährt, falls noch möglich. Es könnte ja schliesslich nur die Netzwerk-Verbindung ins Client-Netzwerk down sein, und die VM läuft noch.
c. die VM startet und dabei die VM soweit als möglich prüft.
Was mir noch gerade einfällt: Mann könnet das OS innerhalb der VM ja so konfigurieren, dass es automatisch bei jedem Boot einen File-System-Check macht.

Ok - wir verlassen hier eindeutig den Bereich in dem ich mich auskenne.
Zu virtuellen Festplatten und REDOs und soweiter kann ich dir vielleicht noch helfen - aber von dem Rest verstehe ich nicht viel - sorry.

Ulli

Kein Problem, danke jedenfalls trotzdem für die Mühen.
Ich sagte ja schon eingangs, dass es vielleicht ein recht interessantes Thema werden könnte. Wenn es einfach wäre, hätte ich mich ja nicht an euch hier gewendet
Bin gern bereit unser beider Know-How in einen Topf zu schmeissen und das oben skizzierte Ziel zu erreichen.

Kennst Du Dich mit dem Scripting von VMware aus?

Kannst Du mit das Prinzip der REDOs erklären?