5
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?
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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 303009
Url: https://administrator.de/contentid/303009
Ausgedruckt am: 08.11.2024 um 18:11 Uhr
5 Kommentare
Neuester Kommentar
Warum nicht einen sinnvollen SW Balancer wie ex SteelApp nun Brocade vADC oder etwas ähnliches ?
So löst man sowas eigentlich professionell.
So löst man sowas eigentlich professionell.
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.
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.
Gruß,
Dani
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. Gruß,
Dani
Super danke, das bringt mich schon mal etwas weiter Wenn wer noch was einzubringen hat, immer her damit
Wenn wer noch was einzubringen hat, immer her damit
Moin,
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
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
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
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
1
