12
Grundsatzfrage zu Cluster
Hallo! Ich habe folgende Verständnisfrage: Angenommen, es wird ein Web-Dienst angeboten, der zur Erhöhung der Ausfallsicherheit auf zwei Servern läuft. Aufgerufen wird der Dienst über eine URL. Wo führt diese URL genau hin? Was passiert, wenn genau dieses Gerät ausgefallen ist?
Wonach muss ich suchen, um hierzu Antworten und Lösungen zu erhalten. Ich finde immer nur Lösungen, bei denen im Falle eines Ausfalls eines Servers der Ersatzserver benutzt wird. Welches Gerät genau leitet einen Request an diesen Ersatzserver weiter, der ausgefallene Server kann es ja nicht sein? Ich hoffe, ich konnte meine Frage verständlich machen.
Wonach muss ich suchen, um hierzu Antworten und Lösungen zu erhalten. Ich finde immer nur Lösungen, bei denen im Falle eines Ausfalls eines Servers der Ersatzserver benutzt wird. Welches Gerät genau leitet einen Request an diesen Ersatzserver weiter, der ausgefallene Server kann es ja nicht sein? Ich hoffe, ich konnte meine Frage verständlich machen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6576096114
Url: https://administrator.de/contentid/6576096114
Printed on: April 27, 2024 at 22:04 o'clock
12 Comments
Latest comment
Die URL führt zu der Ressource die mit einem Ressourcenverteilungssystem, bei Webservern könnte das Loadbalancer sein, aufgelöst wird.
Es gibt einige Möglichkeiten du müsstest konkreter werden.
Es gibt einige Möglichkeiten du müsstest konkreter werden.
Hallo,
Techniken gibt's da einige. Unter anderen Load Balancer oder Round-Robin DNS.
Techniken gibt's da einige. Unter anderen Load Balancer oder Round-Robin DNS.
Mindestens vier Möglichkeiten:
Die Möglichkeiten sind aufgrund der Verfügbarkeit der zusätzlichen Komponenten bzw. der Netzwerkeigenschaften unterschiedlich geeignet für Cloud- bzw. konventionelles Hosting.
Grüße
Richard
- Ein Loadbalancer auf Layer 7/"Reverse-Proxy" vor den Servern hält die IP und verteilt den Traffic
- Ein Loadbalancer auf Layer 4 vor den Servern hält die IP und verteilt den Traffic
- Ein Probing-Dienst prüft die Server und konfiguriert das DNS
- Die beiden Server prüfen sich gegenseitig; wer nichts mehr vom anderen hört, zieht eine Cluster-IP an sich.
Die Möglichkeiten sind aufgrund der Verfügbarkeit der zusätzlichen Komponenten bzw. der Netzwerkeigenschaften unterschiedlich geeignet für Cloud- bzw. konventionelles Hosting.
Grüße
Richard
1
@c.r.s. Ja, aber was passiert, wenn dann der Load-Balancer ausfällt? Bei irgend einem Gerät muss der Request ja ankommen, und das kann ausfallen. Oder ist es möglich, im DNS eine zweite IP-Adresse zu konfigurieren?
Ist der "Probing-Dienst" ein unabhängiger Monitor, der die Server beobachtet und dann - wie Du schreibst - das DNS umkonfiguriert? Aber wirklich performant ist das ja wohl nicht. Bis die neue IP-Adresse verteilt ist, kann es dauern.
Ist der "Probing-Dienst" ein unabhängiger Monitor, der die Server beobachtet und dann - wie Du schreibst - das DNS umkonfiguriert? Aber wirklich performant ist das ja wohl nicht. Bis die neue IP-Adresse verteilt ist, kann es dauern.
Moin,
Gruß,
Dani
@c.r.s. Ja, aber was passiert, wenn dann der Load-Balancer ausfällt? Bei irgend einem Gerät muss der Request ja ankommen, und das kann ausfallen. Oder ist es möglich, im DNS eine zweite IP-Adresse zu konfigurieren?
im Regel in einem Full HA Setup ist jede Komponente mindestens doppelt oder sogar mehrfach vor. Das geht bei der Internetleitung des ISP los, geht über die WAF, den Load Balancer, Webserver bis zum ggf. Application- und/oder Datenbankserver.Ist der "Probing-Dienst" ein unabhängiger Monitor, der die Server beobachtet und dann - wie Du schreibst - das DNS umkonfiguriert?
Nein, in der Regel wird dies über den LoadBalancer und WAF realisiert. Irgendwie muss der jeweilige Service feststellen, ob der Service auf dem Webserver noch tut.Aber wirklich performant ist das ja wohl nicht. Bis die neue IP-Adresse verteilt ist, kann es dauern.
Das hängt davon ab, was die Anforderung und Erwartung ist und was es kosten darf.Gruß,
Dani
Danke, aber ich verstehe das immer noch nicht. Wenn ein Rechner einen Web-Service aufruft, holt er sich vom DNS Server die IP-Adresse und schickt seinen Request dorthin. Am Ziel ist aber doch wohl nur ein Rechner oder Gerät, etwa der Load Balancer. Was passiert, wenn der down ist?
Zitat von @UserUW:
Danke, aber ich verstehe das immer noch nicht. Wenn ein Rechner einen Web-Service aufruft, holt er sich vom DNS Server die IP-Adresse und schickt seinen Request dorthin. Am Ziel ist aber doch wohl nur ein Rechner oder Gerät, etwa der Load Balancer. Was passiert, wenn der down ist?
Danke, aber ich verstehe das immer noch nicht. Wenn ein Rechner einen Web-Service aufruft, holt er sich vom DNS Server die IP-Adresse und schickt seinen Request dorthin. Am Ziel ist aber doch wohl nur ein Rechner oder Gerät, etwa der Load Balancer. Was passiert, wenn der down ist?
Hallo,
wenn ein Load Balancer down ist passiert nichts, wenn dieser im HA Setup betrieben wird. Kollege @Dani hat es bereits erklärt.
Anfrage -> DNS Server -> Virtuelle IP (WAN ) von 2 Firewalls im HA Setup -> HA LoadBalancer ( 2 Stück) -> WebServer Cluster ( 2 Stück oder mehr )....so ganz simpel erklärt
Zitat von @UserUW:
Am Ziel ist aber doch wohl nur ein Rechner oder Gerät, etwa der Load Balancer. Was passiert, wenn der down ist?
Am Ziel ist aber doch wohl nur ein Rechner oder Gerät, etwa der Load Balancer. Was passiert, wenn der down ist?
Das ist in der Tat ein Problem, aber die Frage ist immer, für wen und an welcher Stelle:
In der Variante 4 oben hast Du durch die Übergabe der Cluster-IP einen praktisch unmittelbaren (im Rahmen des ARP-Table-Updates) Übergang zwischen den zwei verfügbaren Ressourcen, ohne dritte Komponente.
Wenn Du einen einzelnen L4- oder L7-Loadbalancer vor die beiden Ressourcen setzt, ist natürlich die Redundanz auf den ersten Blick dahin. Macht man trotzdem häufig, weil der jeweilige "einzelne" Loadbalancer eine viel höhere Verfügbarkeit hat als die einzelne Ressource in seinem Backend und es ggf. nicht anders geht. Auf vielen Cloud-SDNs kannst Du die IP nicht so zwischen den Ressourcen austauschen wie in einem geswitchten Netzwerk (das würde eine deckungsgleiche Änderung der IP in der Cloud-Konfiguration per API erfordern, die vergleichsweise langsam ist; wird teils trotzdem so gemacht). Dafür gibt es dann L4-Loadbalancer als PaaS. Die können vermeintlich einzeln eine hohe Verfügbarkeit erreichen, weil der Cloudanbieter natürlich Zugang zum gesamten Netzwerk-Stack hat und unterbrechungsfreie Redundanz hinter so einer PaaS-Ressource verstecken kann. Für eine L7-Ressource wie z.B. den Azure Application Gateway wird dann nur noch der (L4) Azure Loadbalancer mit einer gemanagten Gruppe von Ubuntu-VMs mit NGINX gebündelt - das könnte man sich auch selbst bauen.
Das DNS-Balancing (Azure Traffic Manager oder Route 53) ist richtigerweise nicht sehr schnell bzw. abhängig von der TTL.
@crs: Danke, es wird also zumindest einmal nicht gehext ;- )
Wir bieten einen Web-Service an, bei dem wir es primitiv mit zwei Servern (an zwei entfernten Standorten) gelöst haben (der Service berechnet nur Daten, speichert nichts, so dass dieser Teil der Problematik nicht existiert): Die Client-Anwendung ruft in zufälliger Reihenfolge den auf dem ersten oder zweiten Server gehosteten Web-Service auf (2 URLs). Reagiert dieser nicht, wird der jeweils andere Server angefragt. Durch die zufällige Abfrage erreichen wir die gewünschte Lastverteilung.
Das ist primitiv, funktioniert aber sehr zuverlässig und ist sehr preiswert und flexibel. Wir fragen uns, ob wir das "professionalisieren" sollten, deswegen meine Fragen!
Vielen Dank, Ulrich
Wir bieten einen Web-Service an, bei dem wir es primitiv mit zwei Servern (an zwei entfernten Standorten) gelöst haben (der Service berechnet nur Daten, speichert nichts, so dass dieser Teil der Problematik nicht existiert): Die Client-Anwendung ruft in zufälliger Reihenfolge den auf dem ersten oder zweiten Server gehosteten Web-Service auf (2 URLs). Reagiert dieser nicht, wird der jeweils andere Server angefragt. Durch die zufällige Abfrage erreichen wir die gewünschte Lastverteilung.
Das ist primitiv, funktioniert aber sehr zuverlässig und ist sehr preiswert und flexibel. Wir fragen uns, ob wir das "professionalisieren" sollten, deswegen meine Fragen!
Vielen Dank, Ulrich
Zitat von @UserUW:
@crs: Danke, es wird also zumindest einmal nicht gehext ;- )
Wir bieten einen Web-Service an, bei dem wir es primitiv mit zwei Servern (an zwei entfernten Standorten) gelöst haben (der Service berechnet nur Daten, speichert nichts, so dass dieser Teil der Problematik nicht existiert): Die Client-Anwendung ruft in zufälliger Reihenfolge den auf dem ersten oder zweiten Server gehosteten Web-Service auf (2 URLs). Reagiert dieser nicht, wird der jeweils andere Server angefragt. Durch die zufällige Abfrage erreichen wir die gewünschte Lastverteilung.
Das ist primitiv, funktioniert aber sehr zuverlässig und ist sehr preiswert und flexibel. Wir fragen uns, ob wir das "professionalisieren" sollten, deswegen meine Fragen!
Vielen Dank, Ulrich
@crs: Danke, es wird also zumindest einmal nicht gehext ;- )
Wir bieten einen Web-Service an, bei dem wir es primitiv mit zwei Servern (an zwei entfernten Standorten) gelöst haben (der Service berechnet nur Daten, speichert nichts, so dass dieser Teil der Problematik nicht existiert): Die Client-Anwendung ruft in zufälliger Reihenfolge den auf dem ersten oder zweiten Server gehosteten Web-Service auf (2 URLs). Reagiert dieser nicht, wird der jeweils andere Server angefragt. Durch die zufällige Abfrage erreichen wir die gewünschte Lastverteilung.
Das ist primitiv, funktioniert aber sehr zuverlässig und ist sehr preiswert und flexibel. Wir fragen uns, ob wir das "professionalisieren" sollten, deswegen meine Fragen!
Vielen Dank, Ulrich
Kennst du Cloudflare?
Dort kannst du deine beiden Server samt DNS mehrfach redundant vertreten lassen. Außerdem kannst du WAF usw machen... Seit ein paar Jahren sind zwar unsere Systeme öffentlich, aber nur Cloudflare kann auf die direkt zugreifen. Das bringt uns wiederum ganz neue Möglichkeiten.
Cloudflare hat für und den Vorteil, dass deren Proxy und LB Strukturen an hunderten Netzwerken weltweit angeschlossen sind und wir somit noch zu einem wirklich tollen Anycasting kommen, obwohl wir teilweise auch nur zwei Server clustern für die kleinen Aufgaben. Wenn die Geschäftsführung z. B. nach Mumbai fährt, dann ist die Verbindung wirklich genial.
Wir sparen viele Terabytes Traffic bei tollen Latenzen.
Vorher hatten wir Leitungen, Backup-Leitungen, Server, Cluster, Loadbalancer usw... ein Geraffel ohne Ende. Heute sind es im Idealfall VMs in der DMZ.
Das deine Clients zufällig einen Endpoint aufrufen ist nicht primitiv, sondern schlau. Wir arbeiten mit allen unseren Datenübernahmen so. Die Clients gehen so zum WCF Service per HTTPS und der kümmert sich darum das sicher valide in die Datenbank geschrieben und gefragt wird.
@2423392070: Danke für die Hinweise.
Unter "primitiv" verstehe ich, dass die Auswahl des Ziel-Servers bzw. der URL beim Client liegt, anstatt beim Service selbst. Dem Ansatz sind auch Grenzen gesetzt hinsichtlich der Erweiterung des Serverangebots. (Es handelt sich um einen Web-Service, der von unseren Kunden in ihre Anwendungen eingebunden wird, also keine hausinterne Lösung.)
Unter "primitiv" verstehe ich, dass die Auswahl des Ziel-Servers bzw. der URL beim Client liegt, anstatt beim Service selbst. Dem Ansatz sind auch Grenzen gesetzt hinsichtlich der Erweiterung des Serverangebots. (Es handelt sich um einen Web-Service, der von unseren Kunden in ihre Anwendungen eingebunden wird, also keine hausinterne Lösung.)
Ach warum?
Unsere Clients, tausende in der Zahl, laden sich einfach eine Datei mit neuen Endpoints.
Unsere Clients, tausende in der Zahl, laden sich einfach eine Datei mit neuen Endpoints.