Re: Hochverfuegbarkeit

On 2000-07-03 22:24 +0200, Schumacher Christoph <chris_schumacher(at)t-online.de> wrote:
> Gibt es auch fuer FBSD eine Loesung zur Hochverfuegbarkeit...
> Ich hab zwar die MailingListe des FreeBSD archieves durchsucht, aber
> keines hat mir zugesagt, d.h. alle waren entweder nicht frei oder waren
> nicht auf TCP/IP Basis (meist nameserver).
> Gibt es denn ein Moeglichkeit FBSD zu Clustern bzw. hochverfuegbar zu
> machen ohne Kosten ?

Ich habe etwas Erfahrung mit HA-CMP (der Hochverfügbarkeitslösung
für IBM RS/6000 AIX-Cluster und speziell die SP/2).

Was dort gemacht wird, das können wir in FreeBSD auch ;-)

Die Frage ist nur, ob wir das wollen :)

HA-CMP erlaubt es, einen Rechner im Standby zu halten, der dann bei
Ausfall des ersten, dessen Aufgaben übernimmt. Dazu muß also erst
einmal ein Mechanismus zum Übertragen eines "Heartbeat" existieren,
der über Ethernet oder eine dedizierte serielle Verbindung aufgebaut
werden kann. Daemon-Proszesse auf beiden Systemen tauschen darüber ihre
Status-Informationen aus.

Als zweites braucht man einen Satz von RC-Dateien, die den Zustandswechsel
zwischen Standby und aktivem Betrieb regeln.

Beim Aktivieren des Ersatz-Systems muß evt. ein FSCK auf gemeinsam
genutzten Platten durchgeführt werden. Außerdem kann man die IP-
Adresse (und ggf. auch die Ethernet MAC-Adresse) des ausgefallenen
Systems übernehmen. (Wenn die MAC-Adresse sich geändert hat, dann
sollte man dafür sorgen, daß die ARP-Caches aller Systeme im LAN
die neue MAC-Adresse lernen.)

Nachdem die Platten sauber verfügbar sind und das Netz-Interface
verfügbar ist, könenn die Anwendungen wieder gestartet werden.
Dazu sind eventuell aber noch "Cleanup"-Vorgänge auf Anwendungsebene
nötig. Z.B. kann es notwendig sein, einen konsistenten Zustand von
Datenbanken herzustellen.

Nach dem Hochfahren muß unbedingt vermieden werden, daß der erste
Rechner wieder aktiv wird. Daher wird er nach dem Reboot normalerweise
im Standby gehalten, bis die Rückübergabe veranlaßt wird.

Es gibt eine Reihe von Modifikationen dieses Verfahrens. Z.B. ist es
im Prinzip möglich, redundante Netz-, SCSI- oder FC-Adapter in einem
System zu haben. Bei einem Ausfall einer Komponente würde dann eine
Übernahme innerhalb eines Rechners durchgeführt, die aber ähnlich
wie bei der Übergabe an andere Rechner stattfindet.

Etwas komplizierter wird es, wenn man eine konstellation mit zwei oder
mehr Servern aufbaut, die gegenseitig als Redundanz dienen können.
Dann muß einer die Last des anderen zusätzlich übernehmen könne,
falls es zu einem Ausfall kommt. Das hat aber noch andere Implikationen.
Man kann z.B. nicht mehr die MAC-Adresse übernehmen (es sei denn, man hat
Netzkarten im Standby). Dazu sollte man aber dann eine Netzarchitektur
sorgfältig passend planen.

In jedem Fall wird auch bei einer etablierten Lösung wie HA-CMP die
Hauptlast der Recovery auf die anwendungsabhängige Wiederherstellung
eines konsistenten Zustands verwendet.

AIX implementiert einen Kernel-Dienst für den Watchdog, der in FreeBSD
als KLD ausgeführt sein könnte. Allerdings könnte ein Prozess, der
auf Real-Time Priorität läuft und im Speicher "locked" ist, wohl den
gleichen Zweck erfüllen.

Die Möglichkeiten sind also eindeutig gegeben. Wenn man bedenkt, daß
selbst bei HA-CMP die Hauptlast in der Implementierung des Applikations-
Restart liegt, halte ich es für nicht unwirtschaftlich, die nötige
Infrastruktur ebenfalls zu entwickeln.

Man benötigt im wesentlichen den Watchdog-Prozess und eine State-Machine,
die für die konsistenten Zustandswechsel im System sorgt. Beides ist
nicht wirklich schwierig.

Ich würde mich gerne (im Rahmen meiner zeitlichen Möglichkeiten) an der
Spezifikation und Implementierung eines solchen Systems beteiligen.

Wenn dabei zuerst einmal nur das Modell der Übernahme durch eine Idle-
Standby erforderlich ist, dann sollte es kein großes Problem sein. Wenn
die State-Machine sauber definiert ist, dann kann man alles andere später
da hineinhängen.

Gruß, STefan

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 04 Jul 2000 - 12:54:35 CEST