jan4321
Goto Top

State of the art redundanz und lastverteilung für webaplicationen

Hi,
Ich muss mich momentan mit dem Aufbau eines Webbackendes für eine App befassen und bräuchte etwas input.
Momentan haben wir eine Failover IP und 2 gesyncte Webserver. Fällt der Aktive Webserver aus, veranlasst ein 3. Server per Script den Failover auf den Passiven node. Diese Konstellation funktioniert soweit ganz Ok, ist allerdings weder skalierbar noch besonders Hübsch und so langsam kommt das backend an seine Leistungsgrenzen.

Ich hab mich in das Thema etwas eingelesen, aber bis jetzt relativ wenig zu dem Thema gefunden, was in die Tiefe geht.

Was ich erreichen möchte:
1. kein Single Point of fairture mehr. (wie löse ich ich das, das der User nach außen hin zwar nur eine IP sieht, intern ich aber eine Redundanz habe)
1. möglichst geringe Ausfallzeiten
2. Neustarten der nodes ohne größeren Aufwand (Für Updates ezt.)
3. Skalierbarkeit und Loadbanacing

Mometan bin ich mit den Servern bei hostEurope und würde das Backend auch nur ungerne Komplett in die Cloud verlegen.


was ich bisher im Sinn hatte:
1. Hardware loadbanacer (Teuer und benötigt ein Eignes RZ bzw. colo + eigene Server)
2. Clouddienste wie AWS Elastic Load Balancing oder ähnliche

Was wäre euer input dazu?

Content-Key: 303009

Url: https://administrator.de/contentid/303009

Ausgedruckt am: 29.03.2024 um 15:03 Uhr

Mitglied: aqui
aqui 27.04.2016 um 12:37:55 Uhr
Goto Top
Warum nicht einen sinnvollen SW Balancer wie ex SteelApp nun Brocade vADC oder etwas ähnliches ?
So löst man sowas eigentlich professionell.
Mitglied: Dani
Dani 27.04.2016 um 20:27:13 Uhr
Goto Top
Moin,
ich würde schauen, dass du je nach Leistungumfang zwei vServer in auf zwei verschiedene Clustern und Brandabschnitt hast. Für das LoadBalancing kannst du sehr gut mit haproxy realisieren. Über die Konfiguration können entsprechende Regel für LB und FO getroffen werden. Da kannst du problemlos nach oben skalieren.

1. kein Single Point of fairture mehr. (wie löse ich ich das, das der User nach außen hin zwar nur eine IP sieht, intern ich aber eine Redundanz habe)
Der Benutzer spricht immer die Failover-IP des haproxy-Cluster an. Darum muss auch dieser redudant sein.

Liefern die Webserver nur Daten aus, so könnte man ein über ein zentrale Repo die Änderungen hochladen und von dort werden die Änderungen auf alle Webserver synchronisiert.

1. möglichst geringe Ausfallzeiten
Hast der Hoster ein Routingproblem nützt dir alles nichts. face-smile


Gruß,
Dani
Mitglied: jan4321
jan4321 28.04.2016 um 11:41:20 Uhr
Goto Top
Super danke, das bringt mich schon mal etwas weiter face-smile Wenn wer noch was einzubringen hat, immer her damit
Mitglied: Sheogorath
Sheogorath 28.04.2016 um 18:50:21 Uhr
Goto Top
Moin,

1. Hardware loadbanacer (Teuer und benötigt ein Eignes RZ bzw. colo + eigene Server)

Möglich aber nicht unbedingt notwendig.

Wenn du wirklich in Richtung "State of the art" gehen möchtest:
Diverse Server bei Digital Ocean, Amazon AWS und ähnliches nutzen (Am besten noch automatisiert deployen ;)). Dazu Round-Robin-DNS auf mehrere HA-Proxies verweisen lassen, die die Verteilung auf Docker Swarm Manager organisieren.

Das skaliert sauber solange du dein DB Backend gut organisierst.

Das einzige was dann noch wirklich kaputt gehen könnte (vorausgesetzt, alles ist richtig konfiguriert) ist die Anwendung selbst oder DNS :D

Viel Spaß

Gruß
Chris
Mitglied: StefanKittel
StefanKittel 16.08.2016 aktualisiert um 12:39:06 Uhr
Goto Top
Hallo,

kaufen oder mieten
AWS oder ProfitBricks

1 LB
2+ WebServer
1 DB Master
1 DB Slave
1x NFS Master für Mediendateien
1x NFS Slave
GIT für Softwarepflege

Zwischen LB und Web passen meist auch noch
SSL Offloader
Caching-Proxy (z.B. Varnish)

Stefan