HA Planung

Hallo Leute,
ich bin am Anfang meiner Planung, mit der ich folgendes erreichen möcht=
e.

Ich habe vor ein aktuelles Test-System, was aktuell auf Sles 10 noch
läuft, auf Sles 11 SP1 upzugraden.
Damit soll unteranderem von Postgresql 8.3 auf 9.0 geupgradet werden.
Das ganze läuft unter einer Xen VM.

Soweit ist noch alles klar. Jetzt soll aber diese VM noch hochverfügbar
werden.
Mein erster Gedanke war eine zweite VM einzurichten, die wie die erste
VM aufgebaut ist und dann über passende Dienste zu synchronisieren. Die=
s
scheint aber doch komplizierter zu sein als gedacht.

Ich habe verschiedenes zu DRBD, Wal-Files, 2x rsync, Slony, PGPool 2
gelesen. Habe auch gesehen das es noch weitere gibt, aber so richtig
klar ist mir noch nicht, was ich wirklich nutzen soll, um den Ausfall
des Mastersystems durch ein Slavesystem vollständig zu kompensieren.
Nicht das mir z.B. der Masterserver ausfällt und der Slave nur
inkonsitente Daten hat.

Wichtig sollte sein, das diese unabhängig voneinander sind und auf 2
verschieden Server virtualisiert werden, damit ein Ausfall eines Server
nicht beide mit ins Grab reist.

Meine erste Meinung, von dem was ich gelesen hatte, war das ich PGPool 2
in Verbindung mit DRBD und Heartbeat einsetzen müsste, was aber ohne
jeglichen Praxisbezug geblidet wurde.

Wie habt ihr eure HA-Systeme realisiert?
Für was für einer Lösung würdet ihr mir raten?

Viele Grüße

Benjamin

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: HA Planung

--Apple-Mail-7-584090109
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1


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-pacemake r-OpenAIS-hear=
tbeat/dp/3897219190/ ist ein guter Einstieg zu dem Thema mit Fokus auf =
Linux

Wenn du das outsourcen möchtest scheint Linbit ein guter =
Ansprechpartner sein, die maintainen zumindest den DRBD-Stack: =
http://www.linbit.com/en/products-services/

lg,
Michael=

--Apple-Mail-7-584090109
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1

-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">

Re: HA Planung

Am Mittwoch, den 15.12.2010, 15:38 +0100 schrieb Michael Renner:
>=20
> On Dec 15, 2010, at 15:13 , Benjamin Knoth wrote:
>=20
> > Wie habt ihr eure HA-Systeme realisiert?
> > Für was für einer Lösung würdet ihr mir raten?
> >=20
>=20
> 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).
>=20
>=20
> HA ist kein triviales Thema, bevor du ans umsetzen gehst solltest du
> schauen dass du die Grundlagen gut genug verstehst.
>=20
>=20
> http://www.amazon.de/Clusterbau-Hochverfügbarkeit-pacem aker-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.=20

Die Nodes müssen möglichst synchron gehalten werden. Führ di=
eses 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 i=
n 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.=20

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.=20

Dann kommt noch da zu, das bestimmte Anbieter wie Orakle, SAP und Co nur
Support gewährleisten, für bestimmte Distributionen. Diese wieder=
um 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 h=
ast 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 über=
nehmen.
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 ei=
ne
Korruption der Daten zu folge. =20

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.=20


Gruß

Olaf


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein