Fail-Over-Cluster realisierbar?

[Roger Wilco 10]

Ein herzliches Hallo in die Runde! :-)

 

Ich arbeite mich zur Zeit in das Thema HA-Cluster/ IP-Failover ein.

 

Letztendlich suche ich eine Lösung für einen 4-Nodes-Cluster, der auch bei Ausfall von 3 Nodes noch verfügbar ist.

 

Soweit ich die Konzepte von Windows Server 2000 bis 2008 verstanden habe, basiert ein lauffähiger Cluster immer auf ein Quorum-Modell, wo eine Mehrheit gebildet werden muss. Das würden bei 4 Nodes 3 aktive Nodes oder 2 aktive Nodes + Quorum-Device bedeuten.

 

Zu den Anforderungen des Clusters:

 

Zwei getrennte Standorte (GeoCluster/MultiSite-Cluster). Der Cluster muss einen Dienst hochverfügbar bereit stellen. Es findet keine Datenhaltung (keine DB) statt. Es müssen keine Daten abgeglichen/konsistent gehalten werden. Der Cluster soll auf MS Windows basieren.

 

Wie ich das bisher sehe ist das mit Windows-Mitteln nicht realisierbar, oder etwa doch?

 

Ich danke im Voraus!

 

 

Viele Grüße

 

Roger Wilco :)

[Lian 2.482]

Hallo,

 

bei Windows Server 2003 gab es "nur" zwei Quorum Modelle: Single/Standard Quorum Model mit einer Shared Storage oder Majority Node Set. Bei Windows Server 2008 ist die Auswahl etwas größer:

There are four quorum modes:

 

* Node Majority: Each node that is available and in communication can vote. The cluster functions only with a majority of the votes, that is, more than half.

* Node and Disk Majority: Each node plus a designated disk in the cluster storage (the “disk witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

* Node and File Share Majority: Each node plus a designated file share created by the administrator (the “file share witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

* No Majority: Disk Only: The cluster has quorum if one node is available and in communication with a specific disk in the cluster storage. Only the nodes that are also in communication with that disk can join the cluster.

 

Siehe: Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster

 

Wichtig ist eine gemeinsame Datenhaltung für die Ablage der Konfigurationsdaten und der Statusinformationen eines Clusters.

 

Wie ich das bisher sehe ist das mit Windows-Mitteln nicht realisierbar, oder etwa doch?

Wieso sollte das nicht mit einem Windows Server Failover Cluster umsetzbar sein?

Ein Multi-Site Cluster ist keine Neuerung und gab es schon unter Windows Server 2003, hier die Einstiegsseite zu 2008: Windows Server 2008: Failover Clustering Program Overview

 

Ideal für Deine Zwecke wäre das Node and File Share Majority Model, siehe Anhang (Quelle)

[Roger Wilco 10]

Wieso sollte das nicht mit einem Windows Server Failover Cluster umsetzbar sein?

Ein Multi-Site Cluster ist keine Neuerung und gab es schon unter Windows Server 2003.

 

Danke für Deine Antwort!

 

Nein, dass MultiSite-Cluster neu bzw. unmöglich sind, hatte ich nicht gemeint. Die Quorum-Modelle habe ich mir auch schon angesehen. Nur soweit ich das eben verstehe, ist das mit diesen Modellen nicht umsetzbar, dass (bei 4 Nodes im Cluster) ein Ausfall von 3 Nodes vom Cluster "verkraftet" werden kann.

 

Ich suche eine Lösung, bei der im Wost-Case (3 Server fallen aus) der 4. Server übernimmt.

[Lian 2.482]

Nur soweit ich das eben verstehe, ist das mit diesen Modellen nicht umsetzbar, dass (bei 4 Nodes im Cluster) ein Ausfall von 3 Nodes vom Cluster "verkraftet" werden kann.

Wo steht das?

[Roger Wilco 10]

Die Modelle (außer das "Disk only"-Modell, welches nicht in Frage kommt) basieren alle auf ein Mehrheits-Prinzip. AKtiv darf nur sein, wer die Mehrheit bildet.

 

Bei 4 Nodes wären das (ohne file share /disk wittness) 3 Nodes. Bei einem Modell mit wittness disk/file share wären das 2 Nodes + Wittnes (2 + 1 = 3/5 Votes).

 

Ich benötige aber eine Lösung wo ein Node (ohne jeglichen Kontakt zu den anderen 3 Nodes im schlimmsten Fall) ganz alleine den Cluster aktiv darstellt.

 

Info:

 

Microsoft TechNet: Understanding Quorum Configurations in a Failover Cluster

 

Appendix B: Additional Information About Quorum Modes

 

Vielleicht habe ich das auch ganz falsch verstanden oder eine Möglichkeit übersehen. Hilfreich wäre z.B. auch, wenn man die Stimmenzahl die ein Node / Wittnes besitzt einstellen könnte. Kann man das?

[Lian 2.482]

Ah ok, jetzt verstehe ich worauf Du hinaus willst.

 

Da kommen wir speziell in den Fall von Node Majority und Multi-Site Clustering.

 

Generell ist eine reine Node Majority ohne Shared Storage für Even-Node cluster nicht empfohlen, das steht auch in dem von Dir zitierten Link.

 

Geht es Euch um einen File Server Cluster oder was habt Ihr vor?

[Roger Wilco 10]

Die Server dienen als Schnittstelle zwischen zwei Netzten. Die Server sammeln Daten eines Netztes und stellen sie dem anderen Netz konverteiert zur Verfügung.

 

Es werden keine Daten aufgezeichnet/gespeichert. Es werden nur "Live-Daten" weiter gereicht. Es gibt keine Datenbank und keine shared Ressourcen.

 

Im schlimmsten Fall, in dem ein Standort (mit 2 Nodes) ausfällt und gleichzeitig am anderen Standort einer der beiden Nodes den Geist aufgibt, muss der noch vorhandene letzte Node die Daten weiterhin zur Verfügung stellen.

 

Aber ich möchte Dir an dieser Stelle nochmal danken, dass Du Dir Zeit für mich nimmst!

[Lian 2.482]

Die Server sammeln Daten eines Netztes und stellen sie dem anderen Netz konverteiert zur Verfügung.

Das sind Windows Dateien, die auf einem NTFS Volume gespeichert werden, richtig?

 

Es stehen also 2 Nodes an einem Standort in einem Netz und weitere 2 an dem anderen Standort, ok.

Nachdem keine gemeinsame Datenhaltung nötig ist, kannst Du Deine Anforderung durch das Aufbauen von 2 Clustern mit jeweils 2 Nodes erreichen (Node and Disk Majority).

Der verbleibende Node kommt immer nur an seine Daten an dem einen Standort heran. Je nachdem wie die Datenreplikation funktioniert -Du schreibst etwas von "weiterreichen"- sind das sowieso die kummulierten Daten. So zumindest das Ziel.

Mehr dazu (Multi-Site Cluster und Data Replication) hier: Data Replication in Geographically Dispersed Clusters: Server Clusters (MSCS)

Microsoft verweist hier auf die Hardware & Software Vendoren, da Datenreplikation nicht der Job eines Windows Failover Clusters ist.

 

So und so: Solange die SPOFs weitestgehend ausgeräumt sind, muss schon eine Menge passieren bis mal drei Knoten ausfallen. ;)

 

Aber ich möchte Dir an dieser Stelle nochmal danken, dass Du Dir Zeit für mich nimmst!

Gerne, dazu sind wir da :wink2:

[Roger Wilco 10]

Die Server sollen eine Applikation hochverfügbar bereit stellen. Das wars eigentlich schon mit der Aufgabe aus Sicht der Server / des Clusters.

 

Was die Applikation macht ist eigentlich egal. Sie reicht Daten eines WANs an ein anderes WAN weiter. Die Daten werden dabei nicht zwischengespeichert. Fährt ein Node wegen eines Failovers die Applikation hoch, so holt sie sich die Daten aus dem Quell-WAN. Als permanente Datenquelle dient also das Quell-WAN. Wenn aus dem Ziel-WAN ein bestimmter Datenpunkt aus dem Quell-WAN angefordert wird, so geschieht das über jene Applikation.

 

Realisiert werden muss also nur ein Fail-Over-Cluster, der eine Applikation bereit stellt.

 

Ich mach mir mal Gedanken zu dem doppelten 2er-Cluster...

 

Erster Gedanke:

 

Wären das dann nicht 2 vollkommen von einander unabhängige Cluster, bei denen jeweils ein Node aktiv die Appliaktion bereit stellen würde? Woher weiß man nun aus Sicht des "Ziel-WANs" welcher der beiden Server den Dienst bereit stellt? Wie macht man ein IP-Failover zwischen den beiden Cluster?

[Lian 2.482]

Wichtig ist also IP und Generic Application (.exe)?

 

Naja, kommt immer darauf an, welchen Level von Hochverfügbarkeit Du erreichen willst und welche SLA Du wiederum auf Ersatzteile hast.

 

Woher weiß man nun aus Sicht des "Ziel-WANs" welcher der beiden Server den Dienst bereit stellt? Wie macht man ein IP-Failover zwischen den beiden Cluster?

Gar nicht. Wären denn alle Knoten in Deinem Konstrukt im gleichen Netz (Ziel-WAN)?

Ist denn das Quell-WAN redundant ausgelegt?

[Roger Wilco 10]

Wichtig ist also IP und Generic Application (.exe)?[/Quote]

 

Genau.

 

 

Ich habe noch keine konkreten Anforderungen was die Verfügbarkeit angeht. Ich kann nur sagen, dass sie "hoch" sein soll. ;)

 

Die komplette Hardware wird 1:1 als Ersatzteile von uns vorgehalten.

 

Die Anbindungen an die WANs sind redundant ausgeführt. Ob die beiden WANS redundant ausgeführt sind, kann ich Dir gerade nicht sagen. Sie haben jedenfalls eine Ring-Topologie.

 

Die Rechner aus dem "Ziel-WAN" sollen - so hatte ich es bisher gedacht - per Cluster-IP auf den jeweils aktiven Rechner zugreifen. Man bräuchte also ein IP-Failover von Standort A nach B und innerhalb der Standorte. Geht denn das bei 2 getrennten Clustern, wie Du es vorgeschlagen hast?

[zahni 562]

Nur eine Frage zwischendurch: Muss die Anwendung zwingendgleichzeitig auf mehreren Maschinen laufen ? Wenn nicht, hast Du mal über eine HA-Lösung in Verbindung mit Vmware Infrastructure nachgedacht ? Zentralen Storage vorausgesetzt (den kann man auch spiegeln) kann Vmware bei Bedarf (Ausfall einer Maschine) die VM einfach auf einer anderen Maschine neu starten. Ganz ohne Dein zutun. Alles bleibt gleich, auch die IP-Adressen. Die Server-Hardware muss auch nicht gleich sein.

 

-Zahni

[Lian 2.482]

Zur Frage: Nein, von Haus aus nicht.

 

Ohne gespiegelte SAN im Multi-Site Cluster:

 

Wenn es eine Ressource sein muss, die über alle Nodes verfügbar sein soll, dann landen wir für einen Geo-(Neu: Multi-Site)Cluster bei "Node and File Share Majority" Model.

 

Mit gespiegelter SAN im Multi-Site Cluster:

 

Für einen "Node and Disk Majority" Cluster brauchst Du im Falle eines Multi-Site Clusters Drittanbieterlösungen für die Storage wie EMC SRDF.

[Roger Wilco 10]

Nur eine Frage zwischendurch: Muss die Anwendung zwingendgleichzeitig auf mehreren Maschinen laufen ?

 

Hallo Zahni!

 

Die Applikation muss (und das habe ich bisher noch nicht gesagt) auf 2 Nodes parallel laufen, um im Fehlerfall schnell umschalten zu können.

 

 

Wenn nicht, hast Du mal über eine HA-Lösung in Verbindung mit Vmware Infrastructure nachgedacht ?

 

Nein, sagt mir nichts. Ich bin recht frisch in das Thema Clustering eingestiegen und wollte zuerst prüfen, was Windows an Möglichkeiten bietet. Werde ich mir aber heute mal ansehen.

 

Zentralen Storage vorausgesetzt (den kann man auch spiegeln) ...

 

Zentraler Storage war eigentlich nicht vorgesehen, da keine Daten gespeichert werden müssen. Das einzig zentrale an dem CLuster sind die beiden WANs.

[Lian 2.482]

Zur Frage:

In a cluster with the Node and File Share Majority configuration, the nodes and the witness file share are counted when calculating a majority. This is similar to the Node and Disk Majority quorum configuration (...) except that the witness is a file share that all nodes in the cluster can access instead of a disk in cluster storage.

Diese PPT gibt imo mehr her:

http://download.microsoft.com/download/6/d/c/6dcfa437-da3d-417d-a530-68e087b71923/WSR439.ppt (PPT Download)

 

Du musst das so sehen: Eine zentrale Storage mag für die Applikation nicht wichtig sein, aber für den Clusterbetrieb, diese stellt das Quorum selbst dar und enthält Konfigurations- und Statusinformationen oder stellt eine Stimme (Vote) dar, die im Fehlerfall mitzählt. Je nach Model.

 

Die Applikation muss (und das habe ich bisher noch nicht gesagt) auf 2 Nodes parallel laufen, um im Fehlerfall schnell umschalten zu können.

Naja, in dem Fall nimmst Du dem Cluster sozusagen die Arbeit ab... ;)

Woher weiß die Applikation welche gerade aktiv ist?