Roger Wilco

Eine weitere Frage: Mit dem Application Center 2000 wurde damals auch das Component Load Balancing (CLB) eingeführt. AC2k gibt es ja nicht mehr. Wurde damit das CLB auch wieder aufgegeben oder wurde das irgendwo weitergeführt?

Eine ähnliche Hochverfügbarkeitslösung, die wir zur Zeit auf W2k-Basis betreiben läuft mit lokalen Accounts. Ich sehe schon den Sinn der zentralen Kontenverwaltung, nur ist es in unserem Fall eben zusätzlicher Mehraufwand und eine zusätzliche Fehlerquelle. Ok, da besteht also noch Optimierungsbedarf an der eigenen Informationsbeschaffungsstrategie. :o Ja, das habe ich mir auch angesehen. Ein DC ist halt eine zusätzliche Fehlerquelle. Mit NLB können wir das ganze System schlank halten. Natürlich geht das nur in unserem Fall. Würde Datenhaltung mit ins Spiel kommen, würde kein Weg an ein Failover-Cluster vorbei gehen. Oh, ich wollte nicht den Eindruck hinterlassen, dass ich das von Euch "erwartet" habe, dass Ihr mich darauf hinweist. Ich hätte es ja selber finden müssen. Liegt ja auch daran, dass ich mich hier relativ unbetucht ins kalte Wasser habe schmeißen lassen. Sprich: Über den "Service" hier bin ich mehr als zufriedem. Ich bin ganz begeistert! :) Ich sehe das halt von der Position, dass(abgesehen von den zusätzlichen Kosten und dem Installations- und Wartungsaufwand) jede dieser zusätlichen Komponenten eine weitere Fehlerquelle im System darstellt. Keep ist simple... Darf ich nochmal zur Frage zurück kommen, ob man den internen NLB-Counter irgendwie einsehen kann? Und eine weitere Frage: NLB mit W2k3 würde ja vollkommen ausreichen. Würdet Ihr empfehlen trotzdem W2k8 stattdessen einzusetezten?

Nur muss man die Bedingungen erstmal finden. ;) Ich will nicht behaupten, dass das nirgendwo steht oder nur sehr gut im "Kleingedruckten" versteckt ist, aber ich bin bei meiner langen und intensiven Recherche wirklich erst sehr spät darauf gestoßen. Kann mein Fehler gewesen sein oder es liegt daran, dass eine vorhandene Domäne normalerweise vorhanden ist. Kannst Du mir bitte eine Quelle für die Bedingungen/Anfoderungen von MSCS/WSFC geben? @Lian: Abgesehen davon wird hochverfügbarer Speicher und ein (hoch)verfügbarerer DC notwendig, der das ganze noch aufwendiger und teurer macht im Vergleich zu NLB.

Hallo, ich habe nun einige Zeit mit dem Clusterservice von Win2k3 (MSCS) als auch mit dem NLB (auch W2k3) auf virtuellen Servern getestet. Schade, dass man beim MSCS ein Ressourcen-Failover nicht in Abhängigkeit von vorhandenen Ressourcen machen kann. Die Anforderung, dass die Cluster-IP auf den Hot-Standby-Rechner, wo die Applikation bereits läuft, übergeht, ist somit leider nicht möglich. Schön wäre es wenn man festlegen könnte: "Ressource >IP-Adresse< wird von dem Node gestartet, wo die Ressource >Applikation< bereits gestartet ist." Man kann zwar festlegen, dass eine Ressource erst online geschaltet wird, wenn eine andere Ressource gestartet ist, aber das beeinflusst nur die Startreihenfolge beim Failover, aber nicht das Failover selbst. Außerdem nachteilig (und in meinem Fall ein Ausschlusskriterium): MSCS/WSFC benötigt eine Domäne! Ein DC gibt es aber in dem Netz nicht und müsste dann auch wieder redundant aufgebaut sein... Zum NLB: Die ersten Gehversuche sehen vielversprechend aus. Verlangt aber in der Tat mehr eigene Software-Entwicklungsarbeit. Ich habe dazu eine Frage: Kann man den internen Counter, der zum Lastausgleich herangezogen wird, irgendwo einsehen? Siehe auch hier: How Network Load Balancing Algorithm works internally

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.

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...

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.

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: 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? 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)?

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. 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. 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?

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. 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. Zentraler Storage war eigentlich nicht vorgesehen, da keine Daten gespeichert werden müssen. Das einzig zentrale an dem CLuster sind die beiden WANs.

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?

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!

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?