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.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6576096114

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

Ausgedruckt am: 24.11.2024 um 04:11 Uhr

12 Kommentare

Neuester Kommentar

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.

Hallo,

Techniken gibt's da einige. Unter anderen Load Balancer oder Round-Robin DNS.

Mindestens vier Möglichkeiten:

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

@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.

Moin,

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?

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?

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

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

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.)