ubuntuusers.de

Hallo, ich möchte gerne 2 Ubuntu Server 15.10 (die auf 2 ESX-Servern laufen) zu einem Failover-Cluster zusammenschalten. Eingesetzt werden als Techniken eine Quorumdisk und Interconnetcs. Fancing: Das Fencing scheint im Allgemeinen immer nach den gleichen Prinzipien zu funktionieren. Entweder der Cluster arbeitet nach STONITH "Shoot The Other Node In The Head" (ein Node steuert den ausgefallenen Node) oder dem ausgefallenen Node werden die Zugriffsrechte auf Ressourcen (SAN, etc.) entzogen werden (https://en.wikipedia.org/wiki/Fencing_%28computing%29). Weder verwenden die Server in dem Sinne gemeinsame Ressourcen (SAN), noch kann der eine Node den anderen Node steuern (bzw. soll er nicht). Gibt es noch weitere Fencingtechniken? Speziell würde ich nach einer Suchen, wo die Clusterware beim Wegfall aller Netzverbindungen den Server A herunterfährt und für den Fall, dass der Server A ausfällt und sich neustartet, die Clusterware mit dem dann aktiven System B verbindet, um sich zu erkundigen, dass System B das aktive System ist.

Kennt jmd. eine Clusterware, die als Fencing das direkte Herunterfahren des Systems unterstützt, wenn der Server keine Netzverbindung mehr hat? Ich habe mir bereits den HP ServiceGuard angeschaut, aber das Fencing scheint nur den Zugriff auf shared Storage zu entziehen.

Also ich bin mir nicht ganz sicher, was du mit Fencing meinst, aber wir nutzen für unsere Cluster Heartbeat + DRBD. Mit nem passenden Skript kann man den inaktiven Knoten im Falle einer Schaltung auch herunterfahren. Für Loadbalancing-Mechanismen gibts keepalived oder varnish (für HTTP(S)).

Eventuell ist für dich auch die Seite des Linux-HA-Projekts interessant.

Suedlicht88 schrieb:

Fancing: Das Fencing scheint im Allgemeinen immer nach den gleichen Prinzipien zu funktionieren.

Fencing bedeutet eigentlich nichts anderes wie ausgrenzenen - also die Möglichkeit einen "defekten" Node vom Cluster aus zu schliessen.

Entweder der Cluster arbeitet nach STONITH "Shoot The Other Node In The Head" (ein Node steuert den ausgefallenen Node) oder dem ausgefallenen Node werden die Zugriffsrechte auf Ressourcen (SAN, etc.) entzogen werden (https://en.wikipedia.org/wiki/Fencing_%28computing%29).

Das sind dann Massnahmen, die man anwenden kann.

Gibt es noch weitere Fencingtechniken? Speziell würde ich nach einer Suchen, wo die Clusterware beim Wegfall aller Netzverbindungen den Server A herunterfährt und für den Fall, dass der Server A ausfällt und sich neustartet, die Clusterware mit dem dann aktiven System B verbindet, um sich zu erkundigen, dass System B das aktive System ist.

Es geht ja darum, dass man Split-Brain Situationen vermeidet. Wenn der aktive Server A z.B. einen kurzen Aussetzer hat - z.B. eine Netzwerkunterbrechung und Server B nun als aktiver Node (Master) übernimmt und der ehemalige Server A, der ja noch immer den Status Master hinterlegt hat, sich wieder zu schaltet, dann knallt es. Darum würde man dann evtl. ein Stonith Device (z.B. abschaltbare Steckdose) einsetzen, die dem ausgefallenen Node dann auch komplett den Gar ausmacht 😉

In der Praxis empfiehlt es sich überdies auch, dass ein Server, der neu hinzukommt durch einen reboot zum Beispiel, dass dieser sich nicht automatisch wieder einhängt, sondern dass da ein Admin schaut und den dann frei gibt bzw. entscheidet, welcher Node nun Master und welcher Slave ist.

Kennt jmd. eine Clusterware, die als Fencing das direkte Herunterfahren des Systems unterstützt, wenn der Server keine Netzverbindung mehr hat?

Will sollte das funktionieren außer mit einer schaltbaren Stromversorgung?

Ich kenne bzw. nutze sonst auch nur DRDB und Heartbeat bzw. Pacemaker wie schon geschrieben wurde.

hoerianer schrieb:

Kennt jmd. eine Clusterware, die als Fencing das direkte Herunterfahren des Systems unterstützt, wenn der Server keine Netzverbindung mehr hat?

Will sollte das funktionieren außer mit einer schaltbaren Stromversorgung?

Nun, man könnte ein Skript schreiben, welches den Server herunterfährt, wenn das Netzwerk nicht erreichbar ist. Die Frage ist, wie man "Netzwerk nicht erreichbar" definiert. Ist beispielsweise ein Core-Switch ausgefallen, und beide der Nodes denken sie hätten kein Netzwerk, fahren sich beide runter, was meistens schlecht ist.

Wenn man allerdings ESX-Server als Hostsysteme hat, kann man die HA auch per VMware realisieren. Wir haben hier beispielsweise 4 VMware-Hostsysteme (allerdings schon ESXi), die am einem redundanten SAN hängen. Wenn ein Hostsystem ausfällt, werden die VMs auf die anderen Hostsysteme verteilt und wieder gestartet.

misterunknown schrieb:

hoerianer schrieb:

Kennt jmd. eine Clusterware, die als Fencing das direkte Herunterfahren des Systems unterstützt, wenn der Server keine Netzverbindung mehr hat?

Wie sollte das funktionieren außer mit einer schaltbaren Stromversorgung?

Nun, man könnte ein Skript schreiben, welches den Server herunterfährt, wenn das Netzwerk nicht erreichbar ist.

Du meinst ein Skript, das auf jedem Server läuft und den Server dann selbst herunterfährt? Weil wenn keine Netzwerkverbindung da ist, wie soll Server B Server A per Skript steuern? Sicherlich machbar, doch sicherlich sehr komplex.
Wobei das Thema HA Cluster an sich schon sehr komplex ist.

hoerianer schrieb:

Du meinst ein Skript, das auf jedem Server läuft und den Server dann selbst herunterfährt? Weil wenn keine Netzwerkverbindung da ist, wie soll Server B Server A per Skript steuern? Sicherlich machbar, doch sicherlich sehr komplex.

Nicht Server_B steuert, ob Server_A heruntergefahren wird, sondern Server_A selbst. Beispielsweise könnte man eine bestimmte IP im lokalen Netzwerk anpingen und wenn der Ping länger als 5 Minuten nicht ankommt, fährt sich der Server selbst herunter. Das war die Idee. Ist aber wohl eher schlecht. Ich weiß auch nicht, warum man einen inaktiven Knoten herunterfahren wollte.

@misterunknown Mit Fencing meine ich das, was hoerianer geschrieben hatte ("Fencing bedeutet eigentlich nichts anderes wie ausgrenzenen - also die Möglichkeit einen "defekten" Node vom Cluster aus zu schliessen. ") Ich konnte mich nur nicht richtig ausdrücken, da ich in der Materie neu bin.

@hoerianer Danke für die ganzen Klarstellungen ☺ ich war durch die Begrifflichkeiten schon durcheinander gekommen und Wikipedia hat mir nur halb geholfen gehabt ☺ "Darum würde man dann evtl. ein Stonith Device". Solche Devices kommen in diesem Fall leider nicht in Frage. Das Ganze ist für ein Projekt in der Firma gedacht und die Konstruktion der Architektur sieht vor, dass die virtuelle Maschine auf einem ESX-Host nicht die virtuelle Maschine auf dem anderen ESX-Host ausschalten kann. Aus sicherheitstechnischer Sicht ist dies in unserer Umgebung ausgeschlossen worden. Weiterhin kommen keine shared Devices (sprich SAN) zum Einsatz, sondern die shared Data kommen via NFS. Shared Devices könnte man zwar machen, aber macht den Aufbau der ESX-Hosts komplexer. Die abschaltabre Steckdose aus deinem Beispiel kommt leider auch nicht in Frage, da es virtualisierte Maschinen sind.

@misterunknown "Nun, man könnte ein Skript schreiben, welches den Server herunterfährt, wenn das Netzwerk nicht erreichbar ist. Die Frage ist, wie man "Netzwerk nicht erreichbar" definiert. Ist beispielsweise ein Core-Switch ausgefallen, und beide der Nodes denken sie hätten kein Netzwerk, fahren sich beide runter, was meistens schlecht ist." Für den Fall kommt ein Quorum-Server zum Einsatz. Ein Quorum könnte man auch per SAN realisieren, aber kommt aus oben genannten Gründen nicht zum Einsatz. Wir haben daher dann einen dritten Note sozuagen im Einsatz, zudem zusätzlich eine Verbindung aufgebaut wird. Ein Node gilt daher als nicht erreichbar, sobald er keinen Zugriff mehr auf das Quorum und den anderen Node hat. Ab da würde ein Failover stattfinden. Die Netzanbindungen würden natürlich über unterschiedliche Interfaces stattfinden. Die HA ist auch bereits per VMWare realisiert. Die beiden ESX-Hosts befinden sich auch in unterschiedlichen ESX-Clustern. Wenn dann mal von einem ESX-Host die Hardware abschmiert, wird das Ganze wie bei euch auf einen anderen Host im gleichen Cluster transferiert. Dies schützt aber nur vor Hardwareausfall des Hosts. Wenn jetzt aber beispielsweise noch ein SAP-System noch eine höhere Systemverfügbarkeit aufweisen muss, muss der noch geclustert werden.

Das was misterunknown als Skript vorgeschlagen hat, ist genau das, was ich als Clusterwarefunktion suche. Natürlich kann man das auch per Script machen, aber schöner wäre es, wenn man das als Clusterwarefunktion hat für den Fall, dass das groß ausgerollt werden soll.

"Ich weiß auch nicht, warum man einen inaktiven Knoten herunterfahren wollte." Nehmen wir an, dass wir 2 Server A und B haben und zusätzlich einen Qourum-Server. Server A hat 3 Netzanbindungen. Netzanbindung 01 nach außen zu den Clients, Netzanbindung 02 zu Server B und Netzanbindung 03 zum Quorum-Server. Netzabnindung 02 und Netzanbindung 03 fallen aus. Dann findet ein Failover auf Server B statt, da der Quorum-Server und Server B zusammen denke, dass Server A ausgefallen ist. Die wissen ja gar nicht, dass Server A immer noch die Anfragen von den Clients annehmen kann durch Netzanbindung 01. Um nun diesen Brain Splitt zu lösen, muss umgehend der Server A seinen Dienst einstellen. Am einfachsten wäre es in dem Sinne dann, wenn sich der Server herunterfährt. In einem einfachen Szenario wäre dies per Stonith Device möglich oder per Entzug der Schreibrechte auf einem shared-Device. Leider ist dies nicht möglich. Das nun per Skript zu lösen wäre sozuagen Frikelarbeit bzw. was passiert, wenn das Skript versagt. Idee daher, dass die Clusterware selber solch einen Verfügbarkeitscheck vornehmen kann und den Rechner runterfährt.

Suedlicht88 schrieb:

Wenn jetzt aber beispielsweise noch ein SAP-System noch eine höhere Systemverfügbarkeit aufweisen muss, muss der noch geclustert werden.

Für produktive SAP Systeme darf nur Software, die SAP zertifiziert ist, verwendet werden. Da muss man dann schon aufpassen.

Bislang ist hier eigentlich alles rein theoretisch, vielleicht solltest Du konkret sagen was Du/Ihr machen wollt, dann ist es auch einfacher einen entsprechenden Ansatz zu finden bzw. zu diskutieren.

Konkret soll ein SAP-System unter Linux geclustert werden ohne Verwendung eines SANs auf getrennten ESX-Hosts. Bisher bevorzugte Lösung ist der HP ServiceGuard. Dieser besitzt einen Quorum-Server, eine NFS-Funktionalität und ist entsprechend für SAP-zertifiziert. Problem war allerdings bisher wie der ausgefallene Cluster heruntergefahren werden soll, um die Splitt Brain Situation zu verhindern. Alternativ schaue ich mir gerade noch den Veritas Cluster Server an. Ist bei dem aber schwierig an entsprechende Informationen zu gelangen, da Symantec dieses Unternehmen wieder ausgegliedert hat und da alles im Umbruch ist. Man kann ggf. wohl auch die Clusterware anpassen lassen und die Shutdownfunktion integrieren lassen oder halt alternativ über ein Skript wie hier vorgeschlagen laufen lassen. Das Ganze ist leider nicht so einfach, da es halt 2 Sonderansprüche gibt, die man wohl so sonst nicht hat 😉

"Bislang ist hier eigentlich alles rein theoretisch, vielleicht solltest Du konkret sagen was Du/Ihr machen wollt, dann ist es auch einfacher einen entsprechenden Ansatz zu finden bzw. zu diskutieren." Mir hat die bisherige Diskussion schon viel gebracht, vor allem Verständnis ☺

Suedlicht88 schrieb:

Konkret soll ein SAP-System unter Linux geclustert werden.....

Für SAP Systeme sind nur RedHat Linux, sowie SuSE Enterprise zertifiziert 😉 Wohlgemerkt produktiv Systeme, wobei man für Test- und/oder Konsolidierungssysteme kein Cluster benötigt.

Von daher bist Du mit der Frage schon leicht im falschen Forum.

"Bislang ist hier eigentlich alles rein theoretisch, vielleicht solltest Du konkret sagen was Du/Ihr machen wollt, dann ist es auch einfacher einen entsprechenden Ansatz zu finden bzw. zu diskutieren." Mir hat die bisherige Diskussion schon viel gebracht, vor allem Verständnis ☺

Du solltest Dir dann bitte mal noch die Hinweise zur Forensyntax anschauen, damit es auch mit dem Zitieren passt.