SLES11 HA Cluster

T

TheKeeper

Enthusiast
Thread Starter
Mitglied seit
11.09.2009
Beiträge
135
Hallo zusammen,

ich beschäftige mich derzeit in meinem Betrieb mit SLES 11, speziell das Clustern zweier Server mithilfe der High Availability Extension. Ich habe bereits die Hauptresourcen, die hochverfügbar gemacht werden sollen konfiguriert, jedoch mit dem Failover klappt es noch nicht.

z.B. passiert es gerne mal, dass wenn ich einen Cluster-Node vom Netzwerk trenne gleichzeitig alle Resourcen auf dem anderen Knoten gestoppt werden.

Hat vielleicht jemand eine Doku oder sonst einen Link, bei dem die Failover-Einrichtung beschrieben wird? Oder hat jemand sonst irgendeinen Rat dazu?

MFG
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hi,

ich habe keine Erfahrungen mit dem SLES-Cluster, aber mit Solaris.

In welchem Modus läuft der Cluster, active-active oder active-passiv?

'cuda
 
mit was läuft den diese "High Availability Extension"? Ist das Heartbeat?
 
Also der Cluster läuft soweit ich weiß active-passive.

in der HA Extension sind OCF2, Heartbeat, LSB, Pacemaker zusammengefasst. Man kann also alles integrieren.
 
ok also Heartbeat, warum die jetzt auf Pacemaker setzen, obwohl das noch mit in Entwicklung. naja ist egal


Wie hast du das den konfiguriert? Mit der GUI oder mit den xml-Files?
 
Zuletzt bearbeitet:
hauptsächlich mit der gui, oder halt in der CRM-Konsole, welche eigentlich die selben Funktionen beinhaltet
 
Also das hier sind die Einträge der CIB (Cluster Information Base), die alle Resourcen enthält:
Code: 
node srv-syslog-ONE \
	attributes standby="true"
node srv-syslog-TWO \
	attributes standby="true"
primitive syslog_final_ip ocf:heartbeat:IPaddr \
	operations $id="syslog_final_ip-operations" \
	op monitor interval="15s" timeout="20s" start-delay="1s" \
	params ip="10.1.1.50" \
	meta migration-threshold="none" multiple-active="stop_start" target-role="started"
primitive msa-mount ocf:heartbeat:Filesystem \
	operations $id="msa-mount-operations" \
	op monitor interval="5" timeout="0" start-delay="10" \
	params device="/dev/sda1" directory="/var/log/server-msa" fstype="ext3" \
	meta target-role="started"
primitive syslog_final_service lsb:syslog-ng \
	operations $id="syslog_final_service-operations" \
	op restart interval="0" timeout="5" \
	op monitor interval="5" timeout="15" start-delay="15" \
	meta target-role="started"
group syslog_final syslog_final_ip msa-mount syslog_final_service \
	meta is-managed="true" target-role="Started"
colocation storage inf: msa-mount syslog_final_ip
colocation syslog inf: syslog_final_service syslog_final_ip
order eins inf: syslog_final_ip msa-mount
order zwei inf: msa-mount syslog_final_service
property $id="cib-bootstrap-options" \
	dc-version="1.0.3-0080ec086ae9c20ad5c4c3562000c0ad68374f0a" \
	expected-quorum-votes="3" \
	last-lrm-refresh="1252581255"
 
Zuletzt bearbeitet:
jo das versteh ich gerade auch ni. Ich werde morgen früh mal gucken, da die server ja im betrieb stehen.
 
:wink: Also das hier ist die aktuelle CIB (das andere war ein Backup von vor ein paar Tagen):

Code: 
node srv-syslog-ONE \
	attributes standby="true"
node srv-syslog-TWO \
	attributes standby="true"
primitive syslog_final_ip ocf:heartbeat:IPaddr \
	operations $id="syslog_final_ip-operations" \
	op monitor interval="15s" timeout="20s" start-delay="1s" \
	params ip="10.1.1.50" \
	meta migration-threshold="none" multiple-active="stop_start" target-role="started"
primitive msa-mount ocf:heartbeat:Filesystem \
	operations $id="msa-mount-operations" \
	op monitor interval="5" timeout="0" start-delay="10" \
	params device="/dev/sda1" directory="/var/log/server-msa" fstype="ext3" \
	meta target-role="started"
primitive syslog_final_service lsb:syslog-ng \
	operations $id="syslog_final_service-operations" \
	op restart interval="0" timeout="5" \
	op monitor interval="5" timeout="15" start-delay="15" \
	meta target-role="started"
primitive health-client-pingd ocf:heartbeat:pingd \
	operations $id="health-client-pingd-operations" \
	op monitor interval="2" timeout="20" start-delay="1m" \
	params pidfile="/var/run/heartbeat/rsctmp/pingd-undef" user="root" dampen="1s" name="undef" host_list="10.1.1.20" host_list="10.1.1.25" host_list="10.1.1.30" section="status" host_list="10.1.1.50"
group syslog_final syslog_final_ip msa-mount syslog_final_service \
	meta is-managed="true" target-role="Started"
clone health-pingd health-client-pingd \
	meta target-role="started" clone-node-max="1"
location loc_syslog syslog_final 10: srv-syslog-ONE
location loc-or-syslog syslog_final 5: srv-syslog-TWO
colocation storage inf: msa-mount syslog_final_ip
colocation syslog inf: syslog_final_service syslog_final_ip
order eins inf: syslog_final_ip msa-mount
order zwei inf: msa-mount syslog_final_service
property $id="cib-bootstrap-options" \
	dc-version="1.0.3-0080ec086ae9c20ad5c4c3562000c0ad68374f0a" \
	expected-quorum-votes="3" \
	last-lrm-refresh="1252658315"

Wie du siehst sind das zwei Cluster-Nodes, von denen sich einer eine IP schnappt, ein SAN-Volume mounted und den Syslog-ng Daemon (startet/restartet). Das funktioniert (i.d.R.) tadellos.

Aber wie gesagt, eigentlich ist mir jetzt eine Doku oder ein Tipp zum Lösungsansatz lieber, als eine fertige Lösung, da es ja mehr um die Weiterbildung im Bereich HA geht.

MFG The Keeper
 
Zuletzt bearbeitet:
Okay ganz anders:

Hat vielleicht jemand schonmal die Muße gehabt einen solchen Cluster aufzusetzen und hat zufällig noch seine CIB-Konfiguration rumschwirren? Oder eine Beispielkonfiguration im Netz gefunden? Eine bei der der Failover funktioniert hat? :rolleyes:

...Ich hoffe zunehmend, dass das nicht auf ein Selbstgespräch hinausläuft...:heul:

MFG
 
oki, die "location" hast du drin.

Da du mit heartbeat 2.99 arbeitest, wird auch master/promot mit drin sein?

Ich hatte heartbeat 2.99 bis nur kurz getestet. So haben wir heartbeat 2.1.3 im Einsatz (zwei clusterserver und eine clusterfirewall). Dort war das Problem, dass die GUI nicht gut ist und das man master/promot bei der "location" manuell eintragen muss.

Bis jetzt gibt es keine Tut so heatbeat 3 (2.99), zumindestens habe ich noch keine gefunden.

Hast du bei der Konfiguration was mit "default_resource_stickiness" gemacht?

Vlt hilft dir das hier weiter. Ist die Doku zu Pacemaker.
 
Danke.
also ich weis schonmal nicht, was du mit "master/promot" meinst. Das hab ich auch noch nicht gelesen. Was ist das und wofür setzt man das ein?

mit "default_resource_stickiness" hab ich auch noch nichts gemacht aber ich weis, wo das eingesetzt werden muss. Aber erstma gucken was das verändert...

Und was bitte bedeutet das?
Bis jetzt gibt es keine Tut so heatbeat 3 (2.99), zumindestens habe ich noch keine gefunden.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
So hab jetzt meine Config geändert:

Code: 
node srv-syslog-ONE \
	attributes standby="false" \
node srv-syslog-TWO \
	attributes standby="false" \
node syslog-test \
	attributes standby="false" \
primitive syslog_final_ip ocf:heartbeat:IPaddr \
	operations $id="syslog_final_ip-operations" \
	op monitor interval="15s" timeout="20s" start-delay="1s" \
	params ip="10.1.1.50" \
	meta migration-threshold="2" multiple-active="stop_start" target-role="started" resource-stickiness="2000" failure-timeout="60s"
primitive msa-mount ocf:heartbeat:Filesystem \
	operations $id="msa-mount-operations" \
	op monitor interval="5" timeout="0" on-fail="standby" start-delay="10" \
	params device="/dev/sda1" directory="/var/log/server-msa" fstype="ext3" \
	meta target-role="started" migration-threshold="2" failure-timeout="60s" multiple-active="stop_start" resource-stickiness="2000"
primitive syslog_final_service lsb:syslog-ng \
	operations $id="syslog_final_service-operations" \
	op restart interval="0" record-pending="false" timeout="5" \
	op monitor interval="5" timeout="15" on-fail="restart" start-delay="15" \
	meta target-role="started" migration-threshold="2" resource-stickiness="2000" failure-timeout="60s" multiple-active="stop_start"
primitive pingd-child ocf:heartbeat:pingd \
	operations $id="pingd-child-operations" \
	op monitor interval="20s" timeout="40s" requires="nothing" start-delay="1m" \
	op start interval="0" timeout="90" requires="nothing" \
	meta target-role="Started"
primitive syslog-ng lsb:syslog-ng \
	operations $id="syslog-ng-operations" \
	op monitor interval="15" timeout="15" on-fail="restart" start-delay="15"
group syslog_final syslog_final_ip msa-mount syslog_final_service \
	meta is-managed="true" target-role="Started"
clone pingd pingd-child \
	meta clone-max="2" clone-node-max="1" target-role="Started" \
	params dampen="5s" multiplier="100"
clone general-logging-services syslog-ng \
	meta target-role="Started" clone-max="2" clone-node-max="1"
location loc_syslog syslog_final inf: srv-syslog-ONE
location loc-or-syslog syslog_final inf: srv-syslog-TWO
location loc_syslog_test_never syslog_final_ip -inf: syslog-test
location loc_syslog_test_na msa-mount -inf: syslog-test
colocation storage inf: msa-mount syslog_final_ip
colocation syslog inf: syslog_final_service syslog_final_ip
colocation col-general-logging -inf: general-logging-services syslog_final_service
order eins inf: syslog_final_ip msa-mount
order zwei inf: msa-mount syslog_final_service
order MAIN inf: pingd syslog_final
property $id="cib-bootstrap-options" \
	dc-version="1.0.3-0080ec086ae9c20ad5c4c3562000c0ad68374f0a" \
	expected-quorum-votes="3" \
	last-lrm-refresh="1253173580" \
	dc-deadtime="120s"

Ich hab noch ein paar Attribute hinzugefügt (mit den der failover konfiguriert wird; verstehe nun auch langsam das Prinzip der Konfig ;)) und eine Clone-Resource (die nur dafür da ist, dass keine Komplikationen bei den LSB-Prozessen auftreten und trotzdem auf allen Systemen noch geloggt wird).

Ich weiß aber noch nicht, wie ich "pingd" konfiguriere und weshalb nichts passiert, wenn ein System (auf dem die Hauptresourcen laufen), plötzlich vom Netzwerk getrennt wird. Da bin ich der Meinung, da sollte doch schon automatisch ein Failover kommen. (Oder mithilfe von PingD???)

MFG
 
Ich habs jetzt endlich!

es lag nur an der No-Quorum-Policy. Diese muss auf "ignore" gesetzt werden, damit ein Cluster dieser Art (d.h. mit zwei Nodes) auch funktioniert.

Jetzt muss ich nur noch ein paar Resourcen finden und konfigurieren, die z.B. auf einen Festplattenausstieg anspringen.
 
TheKeeper schrieb:
Jetzt muss ich nur noch ein paar Resourcen finden und konfigurieren, die z.B. auf einen Festplattenausstieg anspringen.
Zum Vergrößern anklicken....

was genau meinst du mit Festplattenausstieg? Meinst du, wenn bei einem Node die Platte abraucht? Dann sollte ja der 2. Node die Arbeit übernehmen.
 
Genau das meinte ich damit, aber der Node bzw. der Cluster muss ja erst registrieren, dass die Festplatte hinüber ist. Ich hatte schonmal einen Test gewagt und die Festplatte im laufenden Betrieb rausgezogen aber es ist nicht sonderlich viel passiert.
Oder sollte ich das mit der allerneusten Konfig nochma probieren?

EDIT:
Um die Frage gleich wieder aus dem Weg zu räumen: Ich hab es nochmal getestet. Eine fehlende/defekte Festplatte wird nicht erkannt/behandelt.
 
Zuletzt bearbeitet:
ich versteh nicht so ganz was du möchtest?

Also heartbeat eine kaputte Platte erkennen oder was?
 
Ja so in etwa.

Wenn eine Festplatte aussteigt, soll der Cluster bemerken: Aha! Bei dem Knoten, auf dem gerade die und die Resourcen laufen, ist irgendein schwerwiegender Fehler eingetreten ---> da leiten wir doch mal mal einen Failover ein....

Das habe ich dazu gefunden:
http://lists.linux-ha.org/pipermail/linux-ha/2007-December/029550.html

Ach und wie gesagt, ich hätte gedacht, dass es evtl. Resourcen gibt, die den genauen Systemzustand überwachen, aber bisher habe ich noch keine gefunden. Außer vllt. SysInfo, aber die Informationen, die er da abfragt sind gerade die, die ich nicht unbedingt brauche (CPU-Takt, -Modell, etc.) Ich habe mir eben überlegt, dass wenn eine Resource, die ständig Informationen über spezielle Systemkomponenten sammelt, bemerkt, dass einige Infos nicht ermittelt werden konnten, das an den Cluster (Heartbeat, OCF) meldet und dieser wiederum einen Failover einleitet. (Verständlich?:confused:)

Ich informiere mich grade parallel dazu mit "Watchdogs", wie es in einer der mails vorkommt. Mal sehen ob mich das irgendwie weiterbringt...

Und Sorry für die banale Ausdrucksweise....

MFG
 
Zuletzt bearbeitet:
es gibt doch die Resource Filesystem. Dort kannst du einen Platte auswählen und diese dann in Verbindung mit location/colocation bringen.
 
Also ich hab der Filesystem-Resource mal gesagt sie soll das das /-Verzeichnis einhängen, was zwar mir zwar auch schon etas suspekt erscheint, aber egal. Jedenfalls macht er das schonma nicht mit, die Resource wechselt sofort in den "unmanaged" Modus und lässt sich auch partout nicht dazu bewegen, es trotzdem zu versuchen.

Ich glaub nicht, dass es an meiner Konfig liegt, weil ich hab ja bereits erfolgreich ein SAN-Volume mit der Filesystem-Resource gemounted und bin jetzt eigentlich gleich vorgegangen.

Ich bin nebenbei noch am testen, ob mir dieser Watchdog-Daemon was bringt. Der kann sich z.B. einschalten, wenn er eine IP nicht mehr anpingen, oder eine bestimmte Datei nicht mehr auf Veränderungen überprüfen kann. Wenn das eintritt, kann er den Rechner/Server runterfahren. (Im moment fährt er sich gleich kurz nachdem ich den Daemon starte von selbst runter, aber bin ja noch nicht fertig mit konfigurieren)
Der Daemon läuft dann ohne Linux HA.

Ich danke dir trotzdem für deine Hilfe!
MFG
 
Ich würde sagen das Thema kann geschlossen werden.
War irgendwie alles etwas Random.

Danke!

MFG
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh