Load Balancer

Webseiten wie Facebook haben nicht einen Server, sondern Tausende. Die Adresse facebook.com zeigt auf einen riesigen Load Balancer. Der schickt dich zu Server Nr. 4821 (der vielleicht gerade wenig zu tun hat). Wenn Server Nr. 4821 kaputt geht, merkt der Load Balancer das sofort ("Health Check") und schickt keine Kunden mehr hin. Du merkst nichts davon.

Praxisroutine

In der Praxis lernst du Load Balancer, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Algorithmen

Wie entscheidet er?

• Round Robin: Der Reihe nach. 1, 2, 3, 1, 2, 3... (Einfach).
• Least Connections: Wer hat gerade die wenigsten offenen Verbindungen? (Schlau).
• IP Hash: User X landet immer auf Server A (wichtig, wenn Server A den Warenkorb gespeichert hat - "Sticky Session").

2. Layer 4 vs. Layer 7

• Layer 4 (Transport): Guckt nur auf IP und Port. "Paket an Port 80? Weiter zu Server 1." (Extrem schnell).
• Layer 7 (Application): Guckt in den Inhalt. "Ist das eine Anfrage für /bilder? Dann zu den Bilder-Servern. Ist es /video? Zu den Video-Servern." (Intelligenter, aber rechenintensiver).

1. Consistent Hashing (Memcached/Redis)

Die Verteilung von User-Requests (IP Hash) auf Server hat einen fatalen Designfehler (Das "Modulo N" Problem). Hast du 5 Server und verteilst die API-Keys per Modulo (Hash(API-Key) % 5), landet der Key "123" immer auf Server 3. Fällt Server 3 aus (N=4), ändert sich der Modulo global. Plötzlich routet der LB jeden einzelnen Kunden auf den falschen Server. Bei Cache-Systemen (Redis) bedeutet das, der Cache ist tot. Die Architektur-Lösung der Großkonzerne ist Consistent Hashing: Server und User-Anfragen werden mathematisch auf einen "Ring" (Werte 0-360) geworfen. User landen bei dem Server, der ihnen im Uhrzeigersinn am nächsten steht. Fällt ein Server aus, wandern nur dessen direkte Kunden zum Nachbarn weiter. Die anderen 80% des Clusters bleiben ungestört.

2. DSR (Direct Server Return)

Beim klassischen Layer-4 Balancing ist der Load Balancer der pure Flaschenhals. Ein Client fordert via LB ein 5 GB Video von YouTube an. Der Server schickt die 5 GB über den LB zurück. Der LB stirbt am Outbound-Traffic. Bei Direct Server Return (DSR) manipuliert der LB nur die MAC-Adresse der eingehenden Request-Pakete, belässt aber die Ziel-IP unangetastet. Der Worker-Server antwortet synchron dem Client, indem er die Outbound-Route komplett am LB vorbei ins Backend-Netz nimmt. Das eingehende LB-Traffic-Volumen (< 1%) ist entkoppelt vom massiven Server-Outbound (99%), was asymmetrische Skalierung extremer Datenlasten ermöglicht.

3. DNS-Level Cloud Balancing (Global Traffic)

Wenn Facebook User in Japan aus Asien bedienen muss und Europäer aus Irland, reicht ein "lokaler" Load Balancer im Rechnerzentrum (HAProxy) nicht. Sie nutzen Global Server Load Balancing (GSLB) via DNS. Tippst du facebook.com ein, geht die Anfrage an den DNS-Nameserver (z.B. Route53). Dieser fungiert heimlich als globaler Geo-Balancer. Er prüft die IP des anfragenden Users, schaut in einer Datenbank nach Asien ("GeoIP"), testet im Hintergrund via Health-Check, ob das RZ in Tokyo lebt, und liefert dir nicht plump irgendeine IP zurück, sondern als DNS-Antwort die IP des Tokioter Reverse-Proxys.