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

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

--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

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 15, 2010, at 15:13 , Benjamin Knoth =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Wie habt ihr eure HA-Systeme realisiert?<br>Für was =
für einer Lösung würdet ihr mir =
raten?<br></div></blockquote></div><br><div>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).</div><div><br></div><div>HA ist kein triviales =
Thema, bevor du ans umsetzen gehst solltest du schauen dass du die =
Grundlagen gut genug verstehst.</div><div><br></div><div><a =
href=3D"http://www.amazon.de/Clusterbau-Hochverf%C3%BCgbarke it-pacemaker-O=
penAIS-heartbeat/dp/3897219190/">http://www.amazon.de/Cluste rbau-Hochverfü=
gbarkeit-pacemaker-OpenAIS-heartbeat/dp/3897219190/</a> ist ein =
guter Einstieg zu dem Thema mit Fokus auf =
Linux</div><div><br></div><div>Wenn du das outsourcen möchtest scheint =
Linbit ein guter Ansprechpartner sein, die maintainen zumindest den =
DRBD-Stack: <a =
href=3D"http://www.linbit.com/en/products-services/">http:// www.linbit.com=
/en/products-services/</a></div><div><br></div><div>lg,</div><div>Michael<=
/div></body></html>=

--Apple-Mail-7-584090109--

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=C3=BCr was f=C3=BCr einer L=C3=B6sung w=C3=BCrdet ihr mir raten?
> >
>
> DRBD mit dem was gerade aktuell f=C3=BCr 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=C3=BCrfen (und
> du das PGPool ausreichend verf=C3=BCgbar 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=C3=BCgbarkeit-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=C3=A4lle ein guter Einstieg. Auch um
=C3=BCberhaupt die ganzen Begrifflichkeiten erst mal klar zu kriegen.

Es gibt verschiedene Technologieehen. RedHat sind da bisher verschiedene
Wege gegangen. K=C3=BCnftig 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=C3=BCr die Cluster-Komunikation und zwei f=C3=BCr das
Netzwerk-Storage. Wenn irgend wo ein Kabel bricht, muss der Cluster
weiter laufen. Es gibt von allem, was der Cluster zum =C3=BCberleben bracht
mindestens zwei.

Die Nodes m=C3=BCssen m=C3=B6glichst synchron gehalten werden. F=C3=BChr di=
eses Problem
gibt es wiederum verschiedene L=C3=B6sungen. Die auch wiederum mehr oder
weniger komplex sind. So z.B. ist es m=C3=B6glich, das =C3=BCber 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.

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=C3=BCssen angepasst werden
und Dienste m=C3=BCssen 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=C3=BCr ein und die selbe Seite.

Dann kommt noch da zu, das bestimmte Anbieter wie Orakle, SAP und Co nur
Support gew=C3=A4hrleisten, f=C3=BCr bestimmte Distributionen. Diese wieder=
um nur
f=C3=BCr Pakete die von ihnen sind. Das selbe f=C3=BCr bestimmte
Hartware-Anbieter. Also gut m=C3=B6glich, das wenn du Pacemaker unter RHEL5=
..x
benutzt du Support-Vertr=C3=A4ge in f=C3=BCnf und sechs stelligen Bereich h=
ast und
am Tag X hei=C3=9Ft es dann: "Ihr Problem! Das supporten wir nicht. Das ist
nicht von uns unterst=C3=BCtzt."

Hast du das alle abgehakt, geht es an die Frage, wie viel Ausfallzeit
f=C3=BCr dich okay ist. Und wie viel Daten verloren gehen d=C3=BCrfen. Wenn=
man
ein PostgreSQL-Cluster (Obacht! Bei pg ist mit "Cluster" nicht HA
gemeint.) auf eine HA-Cluster laufen l=C3=A4sst, hat man schon eine menge
mehr Sicherheit, ohne auf HA-Cluster-Technologie von pg selber zur=C3=BCck
gegriffen zu haben. Sollte z.B. der Node auf dem der pg-Cluster l=C3=A4uft
ausfallen, w=C3=BCrden die andern Nodes das merken und den Dienst =C3=BCber=
nehmen.
Die Daten selber stehen neu gestarteten Prozess sofort zur Verf=C3=BChrung.
Ein pg-Cluster-Prozess ist in aller Regel in Sekunden (neu) gestartet.
Die IP =C3=A4ndert sich f=C3=BCr die gp-Clienten nicht. Die merken nichts, =
au=C3=9Fer
das der Server kurz mal nicht geantwortet hat. Prozeduren die nicht
vollst=C3=A4ndig geschrieben wurden, werden von postgres verworfen. Ein
abrupte Beendigung eines pg-Prozesses hat f=C3=BCr gew=C3=B6hnlich nicht ei=
ne
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=C3=9F

Olaf

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

HA Planung

Re: HA Planung

Re: HA Planung