Fail-Over-Cluster realisierbar?

[Roger Wilco 10]

Diese PPT gibt imo mehr her:

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

 

Ich kenne zwar schon einige MS-Präsentationen zu Windows 2008 Server und Cluster, die sich auch stark ähneln. Aber irgendwo unterscheiden die sich doch. Und bei dieser hier finde ich den Punkt "Wittness Disk" verwirrend:

 

Nach dem Namen her würde ich das dem Quorum-Modell "Node and Disk Majority" zuordnen, da es hier eine Wittness Disk gibt. Dieses Modell entspricht ja dem "Node and File-Share Majority"-Modell vom Prinzip. Nur das Storage (Wittness) sieht technisch anders aus: Einmal direkt am Cluster angeschlossener Storage und einmal über LAN/WAN erreichbarer Storage. Im Endeffekt haben beide Methoden gleich, dass es einen zusätzlichen Zeugen(Wittnes) gibt, der eine zusätzliche Stimme besitzt.

 

Können z.B. in meinem Fall die beiden Standorte nicht mehr miteinander kommunizieren, so wird der 4er-Cluster in 2 x 2er-Cluster gespalten. Die Gruppe, die dann Verbindung zu dem Wittness (Disk oder File-Share) hat, besitzt dann 2+1 Stimme. Mit 3 Stimmen von 5 Stimmen gesamt würde diese Gruppe mit dem Wittness die Mehrheit bilden. Fällt das Wittnes aus, so kann auch ohne Wittnes eine Mehrheit gebildet werden, wenn 3 Nodes noch laufen und miteinander kommunikzieren.

 

Bei der Erklärung in der Präsentation wird aber ein "Disk-Only"-Modell beschrieben: Eine Verbindung zur Wittnes (?) Disk ist zwingend erforderlich. Das ist ja das "uralte" Quorum-Modell aus NT/W2k-Zeiten.

 

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.

 

Stimmt, das ist mir auch klar. Wenn eine MS-Cluster mit File-Share-Wittness realisierbar wäre, würde ich das auch nicht ausschließen. Nur würde ein MS-Cluster mit FS-Wittness nicht laufen, wenn 3 von 4 Nodes ausgefallen sind.

 

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

Woher weiß die Applikation welche gerade aktiv ist?

 

Die Applikation brauch es ja nicht wissen. Beide arbeiten parallel und unabhängig von einander. Das soll auch so sein. Aber die Teilnehmer des "Ziel-WAN" müssen es "wissen". Bzw. auch nicht, denn sie sollen über eine Cluster-IP automatisch auf einen von den beiden Rechnern zugreifen. Die Cluster-Software soll festlegen (durch Vergabe/Zuordnung der CLuster-IP) auf welchen Rechner zugegriffen werden soll.

 

Grundsätzlich frage ich mich, ob man bei Windows Server die Stimmenzahl konfigurieren kann: Kann man z.B. sagen: Dieser Rechner bekommt 2 Votes, die Wittness Disk erhält 3 Votes usw?

[Lian 2.482]

Es gibt immer noch zwei grundsätzlich verschiedene Modelle, was die Datenhaltung mit den Konfigurationsdaten und Statusinformationen eines Clusters angeht.

Diese übergehst Du.

Cluster mit Shared Device (hat nichts mit "alt" zu tun) auf dem per se eine konsistente Datenhaltung erfolgt oder ein Majority Node Cluster, bei dem die Daten auf jeden Node repliziert werden und erst konsistent sowie aktuell gehalten werden müssen.

 

Appendix B: Additional Information About Quorum Modes

We recommend using a disk witness instead of a file share witness as it is less likely for a “split” scenario to occur, because there is a replica on the disk witness but not on the file share witness. The disk witness can ensure that there is no partition in time since it has a copy of the replica on it and ensures that the cluster has the most up to date configuration.

 

Du läufst ggf. in das Problem, daß die Daten nicht aktuell sind - sprich: Das Replika auf den Nodes nicht aktuell:

The file share witness keeps track of which node has the most updated replica, but does not have a replica itself. This can lead to scenarios when only a node and the file share witness survive, but the cluster will not come online if the surviving node does not have the updated replica because this would cause a “partition in time.” This solution does not solve the partition in time problem, but prevents a “split” scenario from occurring.

 

Die Applikation brauch es ja nicht wissen. Beide arbeiten parallel und unabhängig von einander. Das soll auch so sein. Aber die Teilnehmer des "Ziel-WAN" müssen es "wissen". Bzw. auch nicht, denn sie sollen über eine Cluster-IP automatisch auf einen von den beiden Rechnern zugreifen. Die Cluster-Software soll festlegen (durch Vergabe/Zuordnung der CLuster-IP) auf welchen Rechner zugegriffen werden soll.

Ohne zu Wissen, was im Detail passiert und wofür die Applikation eigentlich da ist, kann man Dir schwer zu etwas raten.

 

Die Stimmenanzahl kann man nicht konfigurieren.

[GerhardG 10]

wäre bei dieser spezielle anwendung nicht auch nlb eine möglichkeit?

[Roger Wilco 10]

@Lian:

 

Hmm. Vielleicht reden wir gerade aneinander vorbei oder ich verstehe Dich nicht richtig.

 

Vielleicht nochmal grundsätzlich:

 

Es gibt 4 Quorum-Modelle, die es inzwischen bei Windows 2008 Server gibt. (Bei NT/2k gab es nur eine - die gibt es heute vom Prinzip immer noch in W2k8, das meinte ich mit "alt"). Ich konzentriere mich zur Zeit mehr auf das Thema, wieviel Nodes dürfen bei 4 Nodes insgesamt ausfallen und welche Methode steckt dahinter.

 

1.) Node Majority (gibt es vom Prinzip seit W3k)

 

Jeder Node hat eine Stimme. Die verbliebenen Nodes, die untereinader kommunizieren können müssen eine Mehrheit bilden. Also 3 Nodes müssen (von 4 gesamt) intakt bleiben, damit sie den Betrieb aufrecht erhalten.

 

2.) Disk Only (die "alte" Variante seit NT/W2k)

 

Lauffähig ist mindestens ein Node, der Verbindung zu dem Quorum-Device hat.

 

3.) Node and Disk Majority

 

Jeder Node hat eine Stimme und es existiert eine zusätzliche Speicherkomponente (Disk Wittness), die ebenfalls eine Stimme besitzt. Node oder Node + Disk Wittness müssen die Mehrheit bilden. Es dürfen also 2 Nodes ausfallen, wenn der Rest Zugriff auf das Disk Wittness hat. Sonst darf nur ein Node ausfallen.

 

4.) Node and File Share Majority

 

Vom Mehrheits-prinzip das gleiche wie bei Node and Disk Majority. Das Wittness ist hier aber eine Netzwerkressource.

 

 

Stimmen wir was diesen Part angeht überein?

 

 

wäre bei dieser spezielle anwendung nicht auch nlb eine möglichkeit?

 

Hallo Gerhard!

 

Meinst Du das Load Balancing an sich angebracht wäre, oder meinst Du, dass NLB an sich so ein Fail-Over-Verhalten bietet?

 

Ich habe mich mit dem NLB so gut wie gar nicht beschäftigt. Wie würde das Deiner Meinung nach aussehen (vom Prinzip)?

[GerhardG 10]

naja, wenn die anwendung parallel betrieben werden kann und die daten nur durchreicht - wozu einen cluster? wäre es nicht einfach die anwendung wie einen frontend webserver zu betreiben, also auf allen servern gleichzeitig? fällt ein server aus, antwortet einfach der nächste.

 

http://www.msxfaq.com/verschiedenes/nlb.htm

[Lian 2.482]

Wie gesagt: Ohne zu Wissen, was im Detail passiert und wofür die Applikation eigentlich da ist, kann man Dir schwer zu etwas raten.

 

Das von Dir sog. "alte" Quorum Model ist eigentlich eher die Königsklasse beim Clustering, dahinter eine ordentliche SAN mit SnapShots und ggf. Mirroring auf SAN Ebene (SRDF zB.): Da kommt wenig darüber;)

Die anderen Modelle (MNS) sind aus Kostengründen entstanden (2k3), die neuen Hybridmodelle unter Windows Server 2008 sind wieder interessant geworden.

 

Zum Thema stateless Applikationen:

http://www.mcseboard.de/windows-forum-ms-backoffice-31/iis-cluster-vorteil-clusftp-vbs-141667.html#post869631

 

Mag sein, daß NLB in der Tat die bessere Option für den TO ist. Das ist primär abhängig von Deiner Applikation, siehe zB: http://technet.microsoft.com/en-us/library/cc757350.aspx

[Roger Wilco 10]

naja, wenn die anwendung parallel betrieben werden kann und die daten nur durchreicht - wozu einen cluster? wäre es nicht einfach die anwendung wie einen frontend webserver zu betreiben, also auf allen servern gleichzeitig? fällt ein server aus, antwortet einfach der nächste.

 

MSXFAQ.DE - Network Load Balancing

 

Ok, Ergänzung dazu: Die Anwendung darf nur doppelt laufen, nicht 4 mal auf allen Cluster-Nodes.

 

@Lian: Mehr Infos als hier und wie in meiner PN an Dich kann ich Dir nicht geben, weil ich selber nicht mehr Infos habe. Vielleicht kannst Du konkrete Fragen stellen?

 

Wenn das "alte" (ich meinte das zeitlich und weniger als qualitative Wertung) Modell so gut sein soll, warum rät Microsoft davon ab? Immerhin ist so eine Quorum-Disk ein SPOF! Ist sie weg, dann läuft nichts mehr!

[Lian 2.482]

Das ist ein potentieller SPOF, allerdings ist eine SAN von Haus aus mehrfach redundant ausgelegt was deren Teile betrifft (FC Switche, FC Verbindungen, Storage Prozessoren, Lüfter, Netzteile, USV, Platten etc.)

In einem Multi-Site Cluster mit gespiegelter SAN darf dann sogar ein ganzes RZ wegfallen.

Für Deine Anforderungen (N-1 soll ausfallen dürfen) blieb nur das Model übrig.

 

Ich schau mir die Infos in der PN mal im Detail an.

 

Falls das eine eigens entwickelte Applikation ist, macht es ggf. Sinn die Anwendung Cluster-Aware zu programmieren. So wie es für Exchange oder den SQL Server und viele andere Anwendungen der Fall ist.

Sei es für Failover oder NLB Cluster.

[Roger Wilco 10]

Ok, ich verstehe schon, aber wenn die Verbindung zwischen den beiden Standorten wegfallen würde, dann hatte man ein klassischen Split-Brain-Szenario:

 

Jedes Cluster-Paar hat seine Verbindung zu "seinem eigenen" Quorum und wird selbstständig.

 

 

 

Zum NLB:

 

An sich würde NLB in diesem Fall passen. Nur kann man dabei sicher stellen, dass die Applikation auf max. 2 von 4 Rechnern läuft? Das wäre wichtig.

[Lian 2.482]

So ist es, daher gilt es Split Brain und Partition in Time Fälle auszuschließen, so wie die SPOFs. Hier hat sich schon einiges von Windows 2000 auf Windows 2003 verbessert und wiederum von 2K3 auf 2K8.

 

Zur Frage: Nur wenn sich Deine Applikation darum kümmert:

Falls das eine eigens entwickelte Applikation ist, macht es ggf. Sinn die Anwendung Cluster-Aware zu programmieren. So wie es für Exchange oder den SQL Server und viele andere Anwendungen der Fall ist.

[Roger Wilco 10]

Falls das eine eigens entwickelte Applikation ist, macht es ggf. Sinn die Anwendung Cluster-Aware zu programmieren.

 

Gut, ich habe eben erfahren, dass es eine eigene Software ist.

 

Stellen sich mir die Fragen:

 

- Was muss die Applikation erfüllen, damit sie "Cluster-Aware" ist?

- Welche Schnittstellen bietet mir NLB, um mit meiner Applikation das NLB zu steuern/beinflussen?

 

So kann ich mir vorstellen, dass die Applikation überwacht, dass sie im gesamten Cluster nur max. zwei mal aktiv ist. Ist sie es, so würde sie dem Node auf dem sie läuft quasi "verbieten" sich dem NLB anzubieten...

[kruda 10]

eine eigene Software ist.

 

 

- Was muss die Applikation erfüllen, damit sie "Cluster-Aware" ist?

- Welche Schnittstellen bietet mir NLB, um mit meiner Applikation das NLB zu steuern/beinflussen?

 

So kann ich mir vorstellen, dass die Applikation überwacht, dass sie im gesamten Cluster nur max. zwei mal aktiv ist. Ist sie es, so würde sie dem Node auf dem sie läuft quasi "verbieten" sich dem NLB anzubieten...

 

Habe mich noch nciht wirklich mit 2k8 beschäftigt aber bisher is es wohl so, dass du die sogenannten Entry Point Functions implementieren musst um mit dem ClusterService zu kommunizieren. Dazu gibts auch ne Cluster API die du dir ansehen kannst.

 

Beim NLB ist es doch so, das man sich hier auf Netzwerktreiberebene bewegt und hier ne eigene Schicht eingefügt wird bei jedem Node. Die Pakete vom client kommen ja immer bis zu allen Nodes und NLB entscheidet dann obs nach oben durchgereicht wird. So hab ich das verstanden.

 

Verbieten sich dem NLB anzubieten ist da meiner Meinung nach sicher nicht ganz trivial...

[Lian 2.482]

Hier die entsprechenden MSDN Links dazu:

 

Failover Cluster API: Failover Cluster API Reference (Windows)

NLB API: Finding What You Need in Network Load Balancing (Windows)

NLB WMI: Network Load Balancing WMI Classes (Windows)

 

Ein Windows Cluster bietet eine gewisse Grundfunktionalität, die Applikationen müssen aber für einen optimalen Betrieb Cluster-Aware sein - siehe Exchange oder MS SQL. Erst mit den passenden Applikationen wird eine sinnvolle Lösung daraus.

[Roger Wilco 10]

Ich danke Euch für Eure Hilfe! :thumb1:

 

Ein MS Failover-Cluster wird es auf Grund der Anforderungen nicht werden.

 

Aber das mit dem NLB werde ich mal verfolgen und mich erstmal etwas fit machen, was das Thema angeht. Anpassung der Software ist vom Prinzip her kein Problem.

[Lian 2.482]

Gerne :)

 

Das ist der richtige Ansatz: Je nach Anforderung oder Applikation sollte man zwischen Windows Server Failover Clustering (WSFC) oder Network Load Balancing (NLB) abwägen, um die passende HA Lösung zu finden.

 

Anpassung der Software ist vom Prinzip her kein Problem.

Das ist schon mal eine gute Vorraussetzung.