Re: Cluster wie Raid mit verteilten CPU-Ressourcen

Moin,

Es hat sonst keiner drauf reagiert, also versuche ich mal
mein Glück ...

Nils Beyer <NilsBeyer(at)web.de> wrote:
> ich spiele mit den Gedanken, bei uns (im Betrieb) ein
> Cluster aus (erstmal) zwei Rechnern aufzubauen.

Da fangen schon die Probleme an. Verschiedene Leute haben
verschiedene Vorstellung davon, was sie als »Cluster« be-
zeichnen. Für einige ist es schon ein Cluster, wenn die
Kisten vernetzt sind und eine PVM-Software drauf läuft.

Das andere Extrem sind dann Leute, für die ein Cluster
schon eine schnelle Kopplung erfordert (Fastethernet ge-
nügt da nicht), und der Cluster muß sich wie ein einziger
Rechenr verhalten, d.h. er hat nur eine IP, und wenn man
sich darauf einloggt, kann man nicht sagen, auf welchen
Node(s) die Login-Shell läuft.

> 1. Die beiden getrennten Platten sollen synchron
> sein, d.h. der Master-Knoten (PC01) gibt vor,
> was auf der Platte sein soll, und der Slave-Knoten
> (PC02) gleicht den Inhalt seiner Platte dement-
> sprechend an.

Das ist mit normalen Mitteln schonmal alles andere als
trivial. Es gibt mehrere Möglichkeiten, wie man es re-
alisieren könnte, mit unterschiedlichem Preisaufwand.

Das sicherste und performanteste (aber auch teuerste)
wäre ein separater Filer bzw. Filer-Cluster (z.B. von
NetApp), der die Daten dann an die beiden Rechner via
NFS liefert.

> 2. Die CPUs der beiden Rechner sollen gemeinsam
> alle Anwendungen berechnen, die sonst ein einzel-
> ner PC rechnen würde. Also alles das, was halt
> standardmäßig und ohne extra genannt zu werden
> gebootet, ge-init.d usw. wird: sshd, ftpd, dhcpd
> usw.

Dafür ist mir keine FreeBSD-Software bekannt. Auch hier
könnte man wieder die »gehobene« Lösung empfehlen: Setze
die beiden Rechner separat auf und schalte einen L8-Switch
davon (z.B. Nortel Alteon). Dann hast Du Load-Balancing
und Redundanz bzw. automatisches Fail-Over.

Man kann sowas ähnliches natürlich auch mit Bordmitteln
emulieren. Ist eine Frage der Zeit und des Aufwands.

> 3. Fällt ein PC aus, übernimmt der andere die Auf-
> gaben. Ist der defekte PC wieder intakt, soll
> er halt wie bei 1. sein Dateisystem synchroni-
> sieren und wieder bei 2. mitmachen.

Das Problem ist, daß Du viele verschiedene Dinge auf einmal
machen möchtest (Datensicherheit durch Replikation, Load-
Balancing der Prozesse und Dienste, Redundanz für High-
Availability bzw. Fail-Over).

Man kriegt das alles nicht einfach so mit einem Finger-
schnippen. Ich glaube auch, Du hast Dir noch keine genau-
eren Gedanken darüber gemacht, was Du eigentlich wirklich
erreichen willst.

Was genau bieten die Rechner für Dienste an, bzw. was sind
ihre Hauptaufgaben? Was genau sind die Anforderungen an
die Verfügbarkeit, sprich, wie hoch darf eine Ausfallzeit
maximal sein? Wie lange darf eine Recovery dauern? Welche
Ausrüstung steht aktuell zur Verfügung, und wieviel kann
für zusätzliche Hardware ausgegeben werden? Wieviel Zeit
kann investiert werden?

Wenn man die Anforderungen kennt, gibt es dann vermutlich
zahlreiche Möglichkeiten, die diese zu implementieren.

Ich schätze, daß in Deinem Fall die Anforderungen nicht un-
bedingt allzu hoch sein werden, d.h. eine Recovery-Zeit von
-- sagen wir mal -- einer halben bis einer Stunde sollte
akzeptabel sein, und Load-balancing ist nicht unbedingt er-
forderlich. In dem Fall sollte es genügen, den zweiten
Rechner als Cold-Standby daneben stehen zu haben. Wenn
dann der erste die Grätsche macht, schaltet man den zweiten
ein, und gut is'.

Gegen Plattenausfälle hilft ein lokales RAID-1. Das kann
man mit einem Hardware-RAID-Controller ebenso realisieren
wie per Software (bei FreeBSD: vinum oder ccd).

Eine weitere Möglichkeit wäre, einen dritten Rechner hin-
zustellen, der nichts weiter tut als Fileserver zu spielen
(sozusagen ein poor-man's-Filer). Die beiden Produktiv-
Server mounten dann die Daten via NFS. So ist sicherge-
stellt, daß beide Server immer den identischen Datenbestand
haben.

Alle genannten Maßnahmen entbinden selbstverständlich nicht
von der Pflicht, regelmäßig Backups anzufertigen.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message