Failovercluster Nodereturn nach Failover

[Hannibal Smith]

Hallo ...
Ich hab für mein Abschlussprojekt ein Failovercluster mit 3 Nodes und asynchroner Rollenverteilung gebaut.
Das bedeutet, dass zB. SQL auf Node 1 aktiv ist, während Fileserver auf Node 2 läuft.
Nach dem test weisen Failover bzw. restart der Node 1 und 2 sind beide Rollen logischerweise auf dem 3 Node aktiv ... da dies in einer Produktiven Umgebung die Server aber nicht optimal auslasten würde ist die Frage ob es geht dass die Rollen automatisch auf ihre preferred Nodes zurückspringen wenn die wieder da sind.

Gibt es da ne Möglichkeit dies zu realisieren ?
Vielen Dank im Voraus

 

[konkretor]

Windows Server Cluster? Percona MySQL Cluster.


Mit den Infos kann man wenig machen

 

[Hannibal Smith]

MS Failover Cluster .. dachte das wäre im Windows Server Forum klar

EDIT: Okay hat sich ... ist in den Properties der Rollen die Funktion Failback

 

[snaxilian]

windows... und professionelle Netzwerke

Da hier nicht nur Win-Threads sind sondern zu allen möglichen Themen kannst davon wohl eher nicht ausgehen...

Eine Lastverteilung kenne ich afaik nur im VM-Umfeld, sowohl bei VMware als auch bei HyperV. Das was du möchtest müsste ja eine Art Kontrollinstanz sein, die deine verschiedenen Failover-Cluster überprüft, den Status aller Nodes kennt und nur wenn die Nodes alle da sind, die Rollen aber auf einem liegen, dies dann um verteilt.

Selbst die unter Windows noch mir bekannte Cluster Affinity bezieht sich soweit ich weiß nur auf HyperV wo man dann festlegen kann, dass eine Ressource/VM zuerst auf einem Node mit hoher Affinität (z.B. selbes Rechenzentrum) neu starten sollte und erst wenn das nicht möglich ist auf irgendeinem Node mit niedriger Affinität (Backup-RZ).

Von daher würde ich an deiner Stelle meinen obigen Ansatz nehmen und dann selbst etwas zusammen verskripten. Das ist dann mal ne außerordentliche Eigenleistung und steigert, wenn ordentlich gemacht, gleich die Abschlussnote
Sprich du musst ein Skript schreiben was zuerst alle Nodes abfragt nach ihrem Health-Status und danach alle Failover-Cluster abfragt wo aktuell die jeweils aktive Rolle liegt.
Dann vergleichen/prüfen ob alle aktiven Rollen woanders liegen und falls nicht eben den Schwenk einleiten.
Das Skript kannst dann auf einem System außerhalb der beteiligten Cluster als Cronjob bzw Scheduled Task laufen lassen.
Oder eben heraus finden ob man auch eine art Anti-Affinität bei unterschiedlichen Clusterrollen konfigurieren kann.

Rein aus Interesse: Gibt es einen Grund warum du dies so gelöst hast und nicht z.B. per HyperV oder VMware mit den dann möglichen Lösungen für eine Lastverteilung? Bei VMware z.B. weiß ich definitiv, dass man festlegen kann, dass bestimmte VMs nicht auf dem gleichen Node laufen sollten solange man es nicht manuell erzwingt. So kann man wunderbar seine VMs, auf denen dann wiederum die teils redundanten Anwendungen laufen, voneinander fern halten. Stirbt eine VM > andere übernimmt. Stirbt ein Node und reißt die VMs mit > sichergestellt, dass andere VM nicht auch weg ist.

 

[Moe.Joe]

Es geht hier um MS Failover Cluster - nicht zwingend um VMs...wiederrum kann ein einzelner Knoten des MS Clusters eine VM sein. Sprich er hat auf jeder Node jeweils zwei Rollen installiert (SQL + Fileserver), die ein eigenes Quorum haben (eine dritte instanz, skript o.ä. wird also nicht benötigt)
@Hannibal Smith - meines Wissens nach nicht best practise. Eine Node sollte laut Microsoft immer nur eine Rolle haben.
Noch eine Frage, da das Thema ja gelöst zu schein seint. Wie löst du das Thema Backup beim Fileserver? & Was geschieht mit dem Backup falls eine Node abraucht?

 

[Hannibal Smith]

@Moe.Joe Mein Projekt behandelt den Aspekt der Datensicherung nicht, da es nur in einem Testsystem läuft und ich die 35h weit überschreiten würde, wenn ich Backup noch mit aufnehmen würde.
Ein Node sollte immer nur eine Rolle haben ... genau darum gehts in dem Projekt
Im Produktivsystem stehen 3 Cluster mit je 2 Nodes auf denen läuft auch nur eine Rolle. In meinem Testsystem mach ich dann 1 Cluster mit 3 Nodes auf denen 2 Rollen laufen (3 gingen auch aber eine davon müsste auch fürs testsystem lizeziert werden) um das ganze als möglichkeit für PS zu testen.
Bezüglich Backup ... würde es da nicht reichen Datensicherungen von der iSCSI Platte zu machen ??

 

[snaxilian]

Wenn ein Node immer nur eine Rolle haben sollte, dann implementiert man diesen Node aber auch nicht für mehr als einen Cluster. Genau dieses Setup beschreibst du aber im Eingangspost. Ein Testsystem was nicht die Bedingungen von der Prod-Umgebung widerspiegelt ist auch eher suboptimal weil viele Settings dann eben doch nicht so identisch sind und man in Prod in Probleme läuft, die man im Test nicht hatte und umgedreht.
Der Failover-Cluster bietet eine Affinität eben nur für HyperV, alles andere musst du dann scheinbar selbst implementieren (siehe mein vorheriger Post) oder auf bestehende Drittsoftware zurück greifen, die dies ggf. schon für dich erledigt.

Ein reines Backup der Disk mit Daten, unabhängig ob diese lokal, per iSCSI, FC oder sonst wie angebunden ist, reicht nicht. Dann hast du zwar die Daten aber nicht die Einstellungen der "Rolle" Fileserver (SMB-Berechtigungen, Quotas, etc). Löscht ein Anwender Daten, dann reicht deine Methode. Raucht euch der Server oder der Cluster ab dann reicht es eben nicht.

 

[Hannibal Smith]

@snaxilian Warum denn nicht ? Was ist den falsch daran den Cluster so einzustellen dass eben nicht die komplette Last auf einem Knoten liegt sondern auf den 3 verfügbaren ?
Bezüglich des Backups ... wie oben schon beschrieben hätte das mein Projekt viel zu komplex und zeitaufwendig gemacht um die IHK Richtlinien zu erfüllen.

 

[snaxilian]

Prinzipiell nix außer, dass es eben mit den gegebenen Tools nicht geht und man sollte natürlich aufpassen, dass man sich nirgends anders einen Single Point of Failure einbaut, sprich auch die NICs der beteiligten Server auf mindestens zwei Switche redundant aufteilen und auf die Quorum Disk sollte dann auf einem System liegen, dass gewisse Redundanzen bietet.
Wobei man da natürlich auch immer Einzelfallabwägungen treffen sollte. Jedes Unternehmen hat da andere Anforderungen.

Wenn man die Verteilung automatisiert hin bekommt und sei es per selbst geschriebenem Skript ist es gut, wenn es manuelle Arbeit bedeutet: meh
Das frisst nur unnötige Zeit und dann sollte man sich fragen:

• Warum automatisiere ich dies nicht?
• Welchen Vorteil erhoffe ich mir davon bzw was spricht dagegen, die Rollen nicht sich selbst zu überlassen, wo sie laufen?

Das wären so die ersten zwei Fragen, die ich als Prüfer der IHK stellen würde

Unabhängig von deinem jetzigen Projekt hier ggf. noch ein Denkanstoß für deine Zukunft:
Ebenso bin ich persönlich auch eher ein Freund davon, Applikationen selbst hochverfügbar anzubieten anstatt nur die Infrastruktur darunter. Zum einen kann ich dann ohne Downtime auch die Applikation mit Updates versorgen und zum anderen ist die Anwendung noch erreich- und nutzbar wenn sich ein Knoten, warum auch immer, verabschiedet hat. Stand jetzt unterstützt Cluster Aware Updating nämlich kein SQL. Sprich du als Admin musst entweder regelmäßig, sprich bei jedem Patchday, außerhalb der Arbeitszeiten der anderen Mitarbeiter den SQL-Server (Rolle) aktualisieren oder eure Mitarbeiter können/müssen mit einer Downtime während der Arbeitszeit leben. Das ist ggf. vertretbar für Anwendungen, die nicht superhochkritisch und relevant sind aber früher oder später kommt so eine Anfrage. Daher würde ich bei Systemen, bei denen kein Cluster Aware Updating (im Windows Umfeld) möglich ist oder wo eine Downtime nur zu deinen Lasten geht, sprich in deiner Freizeit bzw außerhalb der regulären Bürozeiten, immer auf eine elegantere Lösung gehen.
Vielleicht ist dir dies jetzt noch egal weil du ggf. jung bist und es dir nix ausmacht auch mal abends beruflich 1-2h am PC zu sitzen und vielleicht ist der Vergütungsbonus für abends arbeiten besonders hoch aber früher oder später wirst du es schätzen, wenn du abends eben wirklich Zeit für Hobbies, Freunde, Kinder etc hast.