Re: HA Planung

Am Mittwoch, den 15.12.2010, 15:38 +0100 schrieb Michael Renner:
>
> On Dec 15, 2010, at 15:13 , Benjamin Knoth wrote:
>
> > Wie habt ihr eure HA-Systeme realisiert?
> > Für was für einer Lösung würdet ihr mir raten?
> >
>
> DRBD mit dem was gerade aktuell für HA verwendet wird unter Linux,
> schau mal was SLES da schon mitbringt. PGPool wirst du nur brauchen
> wenn Clients bei einem Failover nicht disconnected werden dürfen (und
> du das PGPool ausreichend verfügbar bekommst).
>
>
> HA ist kein triviales Thema, bevor du ans umsetzen gehst solltest du
> schauen dass du die Grundlagen gut genug verstehst.
>
>
> http://www.amazon.de/Clusterbau-Hochverfügbarkeit-pacemaker-OpenAIS-heartbeat/dp/3897219190/ ist ein guter Einstieg zu dem Thema mit Fokus auf Linux

Ja, ich habe das Buch. Auf alle fälle ein guter Einstieg. Auch um
überhaupt die ganzen Begrifflichkeiten erst mal klar zu kriegen.

Es gibt verschiedene Technologieehen. RedHat sind da bisher verschiedene
Wege gegangen. Künftig wird das aber - absehbar - wieder etwas
zusammenwachsen. Ich arbeite arbeite in einer Firma die sich auf
HA-Cluster spezialisiert hat (atix.de). Das ganze Thema ist nicht
einfach. Ausfallsicherheit erreicht man durch Redundanz. Und Redundanz
ist immer komplex. HA-Cluster haben z.B. in aller Regel mindestens vier
Netzwerkkarten. Zwei für die Cluster-Komunikation und zwei für das
Netzwerk-Storage. Wenn irgend wo ein Kabel bricht, muss der Cluster
weiter laufen. Es gibt von allem, was der Cluster zum überleben bracht
mindestens zwei.

Die Nodes müssen möglichst synchron gehalten werden. Führ dieses Problem
gibt es wiederum verschiedene Lösungen. Die auch wiederum mehr oder
weniger komplex sind. So z.B. ist es möglich, das über Netzwerk in und
das selbe Image auf allen Nodes gebootet wird. Und das alle Nodes als
Root-Verzeichnis das selbe Netzwerk-Storage benutzen. Das bringt
wiederum ein Rattenschwanz an an Besonderheiten mit sich. So bracht man
ein modifizierten Kernel.

Auch die Wahrung eines Cluster ist nicht ohne. Ein Update/Upgrade ist
hoch riskant. Das rauf und runter fahren von Clustern ist auch nicht
immer ohne. Prozesse, Dienste und Init-Skripte müssen angepasst werden
und Dienste müssen Cluster-Tauglich sein. So kann es seien, das
PHP-Applikationen die auf einem normalen Server keine Probleme bereiten,
auf einen Cluster unerwartet amoklaufen, weil sie mit konkurrierende
Netzwerkzugriffe nicht klar kommen und 15 Node auf einmal versuchen
einen Cash auf zu bauen, für ein und die selbe Seite.

Dann kommt noch da zu, das bestimmte Anbieter wie Orakle, SAP und Co nur
Support gewährleisten, für bestimmte Distributionen. Diese wiederum nur
für Pakete die von ihnen sind. Das selbe für bestimmte
Hartware-Anbieter. Also gut möglich, das wenn du Pacemaker unter RHEL5.x
benutzt du Support-Verträge in fünf und sechs stelligen Bereich hast und
am Tag X heißt es dann: "Ihr Problem! Das supporten wir nicht. Das ist
nicht von uns unterstützt."

Hast du das alle abgehakt, geht es an die Frage, wie viel Ausfallzeit
für dich okay ist. Und wie viel Daten verloren gehen dürfen. Wenn man
ein PostgreSQL-Cluster (Obacht! Bei pg ist mit "Cluster" nicht HA
gemeint.) auf eine HA-Cluster laufen lässt, hat man schon eine menge
mehr Sicherheit, ohne auf HA-Cluster-Technologie von pg selber zurück
gegriffen zu haben. Sollte z.B. der Node auf dem der pg-Cluster läuft
ausfallen, würden die andern Nodes das merken und den Dienst übernehmen.
Die Daten selber stehen neu gestarteten Prozess sofort zur Verführung.
Ein pg-Cluster-Prozess ist in aller Regel in Sekunden (neu) gestartet.
Die IP ändert sich für die gp-Clienten nicht. Die merken nichts, außer
das der Server kurz mal nicht geantwortet hat. Prozeduren die nicht
vollständig geschrieben wurden, werden von postgres verworfen. Ein
abrupte Beendigung eines pg-Prozesses hat für gewöhnlich nicht eine
Korruption der Daten zu folge.

Ich vermute das man durch Replikation der Datenbank die Ausfallzeit von
wenigen Sekunden, auf noch weniger Sekunden verringert werden kann. Was
aber garantiert nicht geht, ist Sitzungen zu retten und Rollbacks zu
verhindern.

Gruß

Olaf