[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HA für LAMP - wie?



Am 13.06.2017 um 12:14 schrieb Stefan Krueger:
> Hallo Matthias,
> 
> die erste Frage ist, hast du ein shared Storage? Bsp ein NFS-Server oder ein DB-Server oder ähnliches? Das würde die Sache um einiges vereinfachen, dann könntest du nämlich das ganze einfach mit HAProxy lösen. Das wäre die schöne Variante.
> Ansonsten DRBD+Pacemaker/corosync+Apache, dazu PostgreSQL oder MySQL Replikation. Hört sich schwer an, ist es aber nicht wirklich. Bevor du es produktiv schaltest, teste das ganze mehrmals ob das HA auch so funktioniert wie du es gerne möchtest.
> 
> MfG
> Stefan
> 

Wobei ein shared Storage erstmal die gleichen
Hochverfügbarkeitsansprüche erfüllen muss:

Natürlich kann man den Web-/Applicationserver mit einem Loadbalancer
(wie haproxy) redundant halten - aber dann verschiebt sich die Frage nur
dahin, wie man einen NFS- oder DB-Server hochverfügbar hält - und
zusätzlich wie man den haproxy natürlich auch hochverfügbar hält.

Wirklicher Shared Storage, der auch wirklich HA ist - ist toll - aber
vermutlich im privaten Umfeld unbezahlbar.

Bleibt DRBD+pacemaker (oder sonstige Clusterlösungen - wobei mir mit
OpenSource auch nichts ausser der genannten Kombi einfällt).
[Speziell für Postgres oder MySQL: Replikation ist super - aber da muss
man dann immer noch einen cleveren Automaten haben, der zweifelsfrei (!)
erkennt, dass der Master down ist... keine einfache Aufgabe]

Ich gebe aber zu Bedenken: Meiner Erfahrung nach ist die Komplexität,
die so eine Lösung mit sich bringt ebenfalls Grund für Ausfälle, sei es
wegen Administrationsfehlern, sei es wegen notwendigen Wartungsfenstern,
sei es wegen Software-Bugs - also sehr genau überlegen, ob tatsächliche
Verfügbarkeit der Nicht-HA-Lösung wirklich so schlecht ist, dass man das
braucht.

(Und diese Erfahrung betrifft keineswegs nur DRBD+pacemaker - ich hab
die gleichen Erfahrungen auch mit HACMP und Veritas-Clustern gemacht -
nach ein paar Jahren Betrieb sinkt das Knowhow, wie da was eingerichtet
war - und das führt zu Fehlern)

Uli




-- 
Why always beats how in the real world.
Doug Freyburger, c.u.admin


Reply to: