14116
02.10.2005, aktualisiert am 21.10.2005
10954
3
0
CentOS 4.1 - Fileserver Cluster bauen mit Resource Locking
so wie ein MS Clusterserver
Hallo, Ich muß in der nächsten Zeit folgendes lösen:
Ich habe zwei CentOS 4.1 Server welche eine gemeinsame Storage verwenden. Leider ist es auch unter Linux so, daß ein gleichzeitiger Zugriff auf die LUN (oder SCSI Shared DISK) zu komischen Ergebnissen im Filesystem (EXT3) führt.
Auf dieser gemeinsamen Platte liegen Dateien, die von einer Serviceapplikation verwendet werden.
Ich muß es also schaffen, daß die jeweilige Resource (DISK) von einem Server gelockt wird. Bei einem Ausfall des Server soll natürlich der andere diese übernehmen können.
Ein Failover der Applikation ist in meinem Fall nicht so wichtig. Das wird händisch erledigt.
Ich habe mich schon mit Linux-HA herumgeplagt jedoch fehlen mir da immer irgendwelche Pakete.
Hat irgendjemand ein ISO für mich oder eine vernünftigere Seite?
Günter
Hallo, Ich muß in der nächsten Zeit folgendes lösen:
Ich habe zwei CentOS 4.1 Server welche eine gemeinsame Storage verwenden. Leider ist es auch unter Linux so, daß ein gleichzeitiger Zugriff auf die LUN (oder SCSI Shared DISK) zu komischen Ergebnissen im Filesystem (EXT3) führt.
Auf dieser gemeinsamen Platte liegen Dateien, die von einer Serviceapplikation verwendet werden.
Ich muß es also schaffen, daß die jeweilige Resource (DISK) von einem Server gelockt wird. Bei einem Ausfall des Server soll natürlich der andere diese übernehmen können.
Ein Failover der Applikation ist in meinem Fall nicht so wichtig. Das wird händisch erledigt.
Ich habe mich schon mit Linux-HA herumgeplagt jedoch fehlen mir da immer irgendwelche Pakete.
Hat irgendjemand ein ISO für mich oder eine vernünftigere Seite?
Günter
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 17049
Url: https://administrator.de/forum/centos-4-1-fileserver-cluster-bauen-mit-resource-locking-17049.html
Ausgedruckt am: 23.12.2024 um 16:12 Uhr
3 Kommentare
Neuester Kommentar
Hallo Günter,
Linux selbst verwendet normal kein Locking (z.B. SCSI-Lock) wenn es ein Filesystem mounted. Daher kannst du auch problemlos auf zwei Rechnern das mount Kommando für ein Filesystem ausführen, das auf einen gemeinsamen Storage liegt. Das Problem dabei: normale Filesysteme (wie ext3, reiserfs, ...) werden durch eine solche Aktion zerstört und die Daten sind meist verloren.
Du kannst grundsätzlich zwei Dinge tun:
1.) Du stellst sicher, dass immer nur ein einzelner Server das Filesystem gemountet hat.
1.a.) Wenn du das manuell machst, ist es allerdings etwas gefährlich. Da es kein Locking gibt, wird ein versehentliches gleichzeitiges Mounten des Filesystems am zweiten Server nicht unterbunden - das Filesystem ist dann mit großer Wahrscheinlichkeit zerstört und die Daten verloren.
1.b.) Diverse Linux-Cluster-Manager haben unterschiedliche Strategien, um den gemeinsamen Storage zu schützen. Heartbeat (http://www.linux-ha.org) nützt dazu zum Beispiel STONITH (shoot the other node in the head). Bevor der zweite Server z.B. einen Failover macht (und somit auch das Filesystem mountet), wird der erste Server brutal resettet. Meist geschiet das über einen Power Switch. Konkret heist das: Server 2 merkt, dass ein Failover nötig ist -> er nimmt den Strom für Server 1 für 5 Sekunden weg (das passiert, indem z.B. der Powerswitch übers Netzwerk informiert wird, er soll für Server 1 für 5 Sekunden den Strom wegnehmen) -> erst dann führt Server 2 den Failover durch und mountet das Filesystem.
2. Du verwendest ein Clusterfilesystem. Unter Linux gibt es da das GFS (Global File System, siehe http://www.redhat.com/software/rha/gfs/) oder GPFS (http://www-03.ibm.com/servers/eserver/clusters/software/gpfs.html). GFS ist opensource, GPFS ist kommerziell und kommt von IBM. Die Verwendung eines Clusterfilesystems ist allerdings nicht ganz trivial, es gibt bei diesen Clusterfilesystemen auch integrierte Locking- und Mehrheitsmechanismen. Diese Systeme erlauben auch >2 Server gleichzeit und direkt auf das Filesystem zuzugreifen.
Ein paar Fragen hätt ich noch:
1. Welche Applikation willst du eigentlich betreiben, die am gemeinsamen Storage liegen soll?
2. Welchen gemeinsames Storage verwendest du?
lg aus Österreich,
Werner
Linux selbst verwendet normal kein Locking (z.B. SCSI-Lock) wenn es ein Filesystem mounted. Daher kannst du auch problemlos auf zwei Rechnern das mount Kommando für ein Filesystem ausführen, das auf einen gemeinsamen Storage liegt. Das Problem dabei: normale Filesysteme (wie ext3, reiserfs, ...) werden durch eine solche Aktion zerstört und die Daten sind meist verloren.
Du kannst grundsätzlich zwei Dinge tun:
1.) Du stellst sicher, dass immer nur ein einzelner Server das Filesystem gemountet hat.
1.a.) Wenn du das manuell machst, ist es allerdings etwas gefährlich. Da es kein Locking gibt, wird ein versehentliches gleichzeitiges Mounten des Filesystems am zweiten Server nicht unterbunden - das Filesystem ist dann mit großer Wahrscheinlichkeit zerstört und die Daten verloren.
1.b.) Diverse Linux-Cluster-Manager haben unterschiedliche Strategien, um den gemeinsamen Storage zu schützen. Heartbeat (http://www.linux-ha.org) nützt dazu zum Beispiel STONITH (shoot the other node in the head). Bevor der zweite Server z.B. einen Failover macht (und somit auch das Filesystem mountet), wird der erste Server brutal resettet. Meist geschiet das über einen Power Switch. Konkret heist das: Server 2 merkt, dass ein Failover nötig ist -> er nimmt den Strom für Server 1 für 5 Sekunden weg (das passiert, indem z.B. der Powerswitch übers Netzwerk informiert wird, er soll für Server 1 für 5 Sekunden den Strom wegnehmen) -> erst dann führt Server 2 den Failover durch und mountet das Filesystem.
2. Du verwendest ein Clusterfilesystem. Unter Linux gibt es da das GFS (Global File System, siehe http://www.redhat.com/software/rha/gfs/) oder GPFS (http://www-03.ibm.com/servers/eserver/clusters/software/gpfs.html). GFS ist opensource, GPFS ist kommerziell und kommt von IBM. Die Verwendung eines Clusterfilesystems ist allerdings nicht ganz trivial, es gibt bei diesen Clusterfilesystemen auch integrierte Locking- und Mehrheitsmechanismen. Diese Systeme erlauben auch >2 Server gleichzeit und direkt auf das Filesystem zuzugreifen.
Ein paar Fragen hätt ich noch:
1. Welche Applikation willst du eigentlich betreiben, die am gemeinsamen Storage liegen soll?
2. Welchen gemeinsames Storage verwendest du?
lg aus Österreich,
Werner
Hallo Werner,
Mal eine wirklich erschöpfende Antwort. Findet man selten.
Die Methode mit STOINTH ist in meinem Fall nicht möglich, da ich auf meiner Storage (HP MSA-1000) mehrere Partitionen verwende. Als Applikation verwende ich den VMWare GSX Server.
Mein Kunde hat sich aus kostengründen für den GSX anstatt des ESX's entschieden.
Mein Wunsch ist ganz trivial:
Pro VM habe ich eine LUN auf der SAN.
Beide Knoten mounten unterschiedliche LUN's.
Fällt nun ein Knoten aus, soll der andere die Möglichkeit haben, diese VM zu starten.
Es ist in meinem Fall nicht nötig, daß dies automatisch geschieht. Ich werde in einem solchen Fall sowiso angerufen.
lg aus Klagenfurt
Günter
Mal eine wirklich erschöpfende Antwort. Findet man selten.
Die Methode mit STOINTH ist in meinem Fall nicht möglich, da ich auf meiner Storage (HP MSA-1000) mehrere Partitionen verwende. Als Applikation verwende ich den VMWare GSX Server.
Mein Kunde hat sich aus kostengründen für den GSX anstatt des ESX's entschieden.
Mein Wunsch ist ganz trivial:
Pro VM habe ich eine LUN auf der SAN.
Beide Knoten mounten unterschiedliche LUN's.
Fällt nun ein Knoten aus, soll der andere die Möglichkeit haben, diese VM zu starten.
Es ist in meinem Fall nicht nötig, daß dies automatisch geschieht. Ich werde in einem solchen Fall sowiso angerufen.
lg aus Klagenfurt
Günter
Hallo Günter,
STONITH schießt nur den anderen Clusterknoten ab - nicht ein ggf. gemeinsam verwendetes Storage-System. Es gibt bei den STONITH-Plugins für den Heartbeat-Cluster auch z.B. das 'meatware'-Plugin - wo man manuell den fehlerhaften Knoten ausschalten muss und dass dann auf der Kommandozeile des überlebenden Knoten bestätigt.
Ich vermute, dass du aber eh eher keinen Cluster verwenden willst, sondern alle Schritte im Falle des Falles selbst durchführen willst. Da wäre vielleicht folgende Vorgehensweise hilfreich:
Unterstützt die HP MSA-1000 ein Zuordnung von LUNs an dedizierte HBAs (also an die WWPNs)? Sozusagen ein Zoning auf Storage-System-Ebene? Bei manchen Herstellern ist dieses Feature als 'Storage Partitioning' bezeichnet, etwa bei der IBM DS4xxx Serie. Kann man auf der HP MSA-1000 auch unterschiedliche Konfigs für dieses Zoning ablegen?
Zum Beispiel:
Knoten1 verwendet im Normalfall: LUN1, LUN2, LUN3
Knoten2 verwendet im Normalfall: LUN4, LUN5, LUN6
Falls die MSA-1000 unterschiedliche Konfiguration ablegen kann, würde ich folgende Konfigurationen definieren:
Konfig1 (Normalbetrieb):
WWWPN-Knoten1 - Zugriff auf LUN1, LUN2, LUN3 erlaubt
WWWPN-Knoten2 - Zugriff auf LUN4, LUN5, LUN6 erlaubt
Konfig1 (Ausfall Knoten1):
WWWPN-Knoten2 - Zugriff auf LUN1, LUN2, LUN3, LUN4, LUN5, LUN6 erlaubt
Konfig3 (Ausfall Knoten2)
WWWPN-Knoten1 - Zugriff auf LUN1, LUN2, LUN3, LUN4, LUN5, LUN6 erlaubt
Bei einem solchen Setup ist allerdings zu beachten, dass nach dem Aktivieren einer anderen Konfig auf dem Storage-System die Server sehr wahrscheinlich rebootet werden müssten, da sich die Devicenamen für die LUNs ändern könnten wenn neue LUNs dazukommen. Außerdem wären ohne Reboot auch ein paar Tricks notwendig, um die LUNs unter Linux sichtbar zu machen (mittels echo "scsi add-single-device <host> <bus> <target> <lun>" > /proc/scsi/scsi - siehe http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO/mlproc.html). Das Ganze macht dann diese Lösung eventuell nur bedingt praktikabel einsetzbar.
Beiden Server-Knoten den Zugriff auf alle LUNs im SAN zu gewähren, und manuell die richtigen LUNs mounten ist auf der anderen Seite aber doch ziemlich riskant. Wenn man sich einmal vertut, und eine LUN mountet, die aber auch am anderen Server gemountet ist, dann ist das Filesystem mit allen Daten drauf mit hoher Wahrscheinlichkeit zerstört!
Eine Frage: so wie ich das verstehe läuft auf beiden Knoten ein GSX Server, ist das richtig?
STONITH schießt nur den anderen Clusterknoten ab - nicht ein ggf. gemeinsam verwendetes Storage-System. Es gibt bei den STONITH-Plugins für den Heartbeat-Cluster auch z.B. das 'meatware'-Plugin - wo man manuell den fehlerhaften Knoten ausschalten muss und dass dann auf der Kommandozeile des überlebenden Knoten bestätigt.
Ich vermute, dass du aber eh eher keinen Cluster verwenden willst, sondern alle Schritte im Falle des Falles selbst durchführen willst. Da wäre vielleicht folgende Vorgehensweise hilfreich:
Unterstützt die HP MSA-1000 ein Zuordnung von LUNs an dedizierte HBAs (also an die WWPNs)? Sozusagen ein Zoning auf Storage-System-Ebene? Bei manchen Herstellern ist dieses Feature als 'Storage Partitioning' bezeichnet, etwa bei der IBM DS4xxx Serie. Kann man auf der HP MSA-1000 auch unterschiedliche Konfigs für dieses Zoning ablegen?
Zum Beispiel:
Knoten1 verwendet im Normalfall: LUN1, LUN2, LUN3
Knoten2 verwendet im Normalfall: LUN4, LUN5, LUN6
Falls die MSA-1000 unterschiedliche Konfiguration ablegen kann, würde ich folgende Konfigurationen definieren:
Konfig1 (Normalbetrieb):
WWWPN-Knoten1 - Zugriff auf LUN1, LUN2, LUN3 erlaubt
WWWPN-Knoten2 - Zugriff auf LUN4, LUN5, LUN6 erlaubt
Konfig1 (Ausfall Knoten1):
WWWPN-Knoten2 - Zugriff auf LUN1, LUN2, LUN3, LUN4, LUN5, LUN6 erlaubt
Konfig3 (Ausfall Knoten2)
WWWPN-Knoten1 - Zugriff auf LUN1, LUN2, LUN3, LUN4, LUN5, LUN6 erlaubt
Bei einem solchen Setup ist allerdings zu beachten, dass nach dem Aktivieren einer anderen Konfig auf dem Storage-System die Server sehr wahrscheinlich rebootet werden müssten, da sich die Devicenamen für die LUNs ändern könnten wenn neue LUNs dazukommen. Außerdem wären ohne Reboot auch ein paar Tricks notwendig, um die LUNs unter Linux sichtbar zu machen (mittels echo "scsi add-single-device <host> <bus> <target> <lun>" > /proc/scsi/scsi - siehe http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO/mlproc.html). Das Ganze macht dann diese Lösung eventuell nur bedingt praktikabel einsetzbar.
Beiden Server-Knoten den Zugriff auf alle LUNs im SAN zu gewähren, und manuell die richtigen LUNs mounten ist auf der anderen Seite aber doch ziemlich riskant. Wenn man sich einmal vertut, und eine LUN mountet, die aber auch am anderen Server gemountet ist, dann ist das Filesystem mit allen Daten drauf mit hoher Wahrscheinlichkeit zerstört!
Eine Frage: so wie ich das verstehe läuft auf beiden Knoten ein GSX Server, ist das richtig?
