Einfache eigene Failover- und Lastverteilungslösung

[DerMitSkill]

Hallo

Server:

balancer1.example.com    10.10.10.30 10.10.10.31
balancer2.example.com    10.10.10.30 10.10.10.32
http1.example.com        10.10.10.41
http2.example.com        10.10.10.42

Zur Veranschaulichung des Failovers:
MOD: Anhang #1 & #2.

balancer1 und balancer2 bekommen die IP 10.10.10.30 konfiguriert. Auf balancer2 ist das Interface allerdings deaktiviert. balancer2 ist per SSH mit balancer1 verbunden und führt auf diesem ein Testskript minütlich aus. Kommt es zu Fehlern (z.B. weil der Server abgestürzt ist) wird das Interface mit der IP aktiviert, also erhält balancer2 ab da alle Anfragen an die IP 10.10.10.30. Das wäre das Failover zwischen den Balancern.

Die Balancer sind per SSH mit den Webservern verbunden und fragen minütlich die Last ab und führt Tests durch. Je nachdem, welcher die niedrigere Last hat und die Tests besteht, erhält die Anfragen an die IP 10.10.10.30. Die Anfragen werden per iptables von dem Balancer an den Webserver weitergeleitet, Umschaltung per Script.

Das wäre meine einfache eigene Failover- und Lastverteilungslösung.

Meinungen? Ideen?

Dankeschön

 

[d4f]

In deinem Design erhaelt jeweils ein Webserver den ganzen Traffic fuer 1 Minute - in welcher seine Load sich erhoeht, waehrend die des aktuell nicht belegten Servers sich drastig reduziert.

Ich denke haproxy, nginx und pound sollten eher Anhaltspunkte sein, zumindest haproxy kann die Erreichbarkeit des Backends testen, bei den anderen bin ich mir nicht sicher. (liesse sich aber zumindest mit heartbeat relativ leicht implementieren)

Deine Implementierung erinnert eher an eine High-Availability Loesung mit Master-Slave Setup denn an einen Loadbalancer mit Master-Master Setup

 

[DerMitSkill]

In deinem Design erhaelt jeweils ein Webserver den ganzen Traffic fuer 1 Minute - in welcher seine Load sich erhoeht, waehrend die des aktuell nicht belegten Servers sich drastig reduziert.

Ich dachte, eine Minute wäre nicht so schlimm, wenn die Server nicht an der obersten Grenzen sind.

Eine Idee, wie ich das "live" machen könnte? Cronjob kann ja nur Minuten.

Ich denke haproxy, nginx und pound sollten eher Anhaltspunkte sein, zumindest haproxy kann die Erreichbarkeit des Backends testen, bei den anderen bin ich mir nicht sicher. (liesse sich aber zumindest mit heartbeat relativ leicht implementieren)

Ich würde gerne etwas eigenes basteln

Deine Implementierung erinnert eher an eine High-Availability Loesung mit Master-Slave Setup denn an einen Loadbalancer mit Master-Master Setup

Die Balancer sind ja auch Master-Slave? ;-)

 

[d4f]

Die Balancer sind ja auch Master-Slave? ;-)

Die Balancer, aber nicht die Server dahinter
Alle Webserver sind 1:1 identisch und greifen auf den gleichen Speicher zu.

Eine Idee, wie ich das "live" machen könnte? Cronjob kann ja nur Minuten.

Indem du im Shell-Script 60 Durchlaeufe einstellst?

Ich würde gerne etwas eigenes basteln

Warum aufwaendig und fehleranfaellig eine schlechtere Loesung zusammenbasteln? Wenn es nicht alles kann, kannst du ja immer am Sourcecode herumbasteln (vorausgesetzt du beherrschst die entsprechende Programmiersprache )

 

[DerMitSkill]

Die Balancer, aber nicht die Server dahinter
Alle Webserver sind 1:1 identisch und greifen auf den gleichen Speicher zu.

Ist da jetzt etwas schlechtes daran?

Indem du im Shell-Script 60 Durchlaeufe einstellst?

Einfach und zugleich genial!

Warum aufwaendig und fehleranfaellig eine schlechtere Loesung zusammenbasteln? Wenn es nicht alles kann, kannst du ja immer am Sourcecode herumbasteln (vorausgesetzt du beherrschst die entsprechende Programmiersprache )

Warum eine große Lösung, wenn man das mit ein paar Zeilen erledigen kann?
Wenn es sich bewährt ist es gut, wenn nicht, kommt eben die große Lösung ;-)
Und ein netter Nebeneffekt: Man lernt etwas

 

[d4f]

Naja Loadbalancing funktioniert mit deiner Loesung nicht da er nicht wirklich die Last verteilen sondern nacheinander auf den einen und den anderen legt.

 

[DerMitSkill]

Jetzt wo Du es sagst.. stimmt. Einmal gehen die ganzen Anfragen auf http1, anderes mal auf http2. Das ganze vielleicht nur für eine Sekunde, wo schon die Anfrage beendet ist. Wenn, dann müsste immer die selben IP-Adressen auf einen Webserver schicken. Mh.. eine Idee? So taugt es jedenfalls doch nicht zur Lastverteilung.. allerdings als Failover.

 

[d4f]

DIe Idee habe ich bereits oben erwaeht. Du musst einen reverse-proxy dazwischen setzen und dieser programmiert sich definitiv bedeutend komplexer
Also einfach nginx, pound oder haproxy benutzen

Allerdings muessen die PHP-Sessions auch shared sein (sofern nicht die Benutzer anhand des Cookies wieder auf den gleichen Backend geleitet werden was ein Risiko von nicht-korrekter Lastverteilung birgt).

 

[DerMitSkill]

DIe Idee habe ich bereits oben erwaeht. Du musst einen reverse-proxy dazwischen setzen und dieser programmiert sich definitiv bedeutend komplexer
Also einfach nginx, pound oder haproxy benutzen

Grr.. ich überleg 's mir So lange keine Lastverteilung nötig ist, kann ich wenigstens mein eigenes Failover nutzen

Allerdings muessen die PHP-Sessions auch shared sein (sofern nicht die Benutzer anhand des Cookies wieder auf den gleichen Backend geleitet werden was ein Risiko von nicht-korrekter Lastverteilung birgt).

Sessions kommen in die Datenbank, welche repliziert wird. Kein Problem

 

[daemotron]

Ich werfe mal noch Varnish in den Ring. Der kann definitiv Loadbalancing und Health-Checking für die Backends, und als kleinen Bonus obendrauf gibt's auf Wunsch auch noch Caching. Neben der normalen Konfiguration (mit der man eigentlich so einen Standard-Fall problemlos erschlagen bekommt) kann Varnish auch noch mit inline C zu fast jeder Schandtat angestiftet werden.

 

[matzewe01]

Sessions kommen in die Datenbank, welche repliziert wird. Kein Problem

Pfui Spinne, da gehören Sie ganz bestimmt nicht hin!
Dann bau Dir lieber einen drbd gesyncten und per ocfs2 "geclusterten" mini Storage und lege dort die Sessiondaten ab.
Wenns von der Performance nicht reicht, gibt es ggf. vom Provider einen inkl. Storage im vlan.

Und wenn Datenbank, dann wenigstens die Sessions in eine Memory Tabelle legen.

 

[d4f]

MySQL hat auch Engines welche memory-based sind
Auch wenn Alternativen wie memcachedb/memcached dafuer eher geeignet sind

 

[matzewe01]

MySQL hat auch Engines welche memory-based sind

Siehe oben, -> Hatte ich bereits als "Notlösung" angemerkt mit den Memtables.