13.7 Load Balancing und Skalierung
Einordnung
Diese Seite gehört zum Kapitel:
Server, Virtualisierung und Hochverfügbarkeit
Auf den vorherigen Seiten ging es um Cluster, Hochverfügbarkeit, Failover, Quorum und Split-Brain.
Jetzt geht es um:
Load Balancing und Skalierung
Diese Themen sind wichtig, wenn Dienste nicht nur ausfallsicherer, sondern auch leistungsfähiger und besser verteilbar betrieben werden sollen.
Grundidee
Ein einzelner Server kann nur eine bestimmte Menge an Anfragen verarbeiten.
Beispiele:
| Dienst | Mögliche Last |
|---|---|
| Webserver | Viele Webseitenaufrufe |
| API-Server | Viele Anwendungsanfragen |
| Datenbankserver | Viele Lese- und Schreibzugriffe |
| Terminalserver | Viele Benutzer gleichzeitig |
| Fileserver | Viele Dateioperationen |
| Mailserver | Viele E-Mails und Benutzerzugriffe |
Wenn ein Server überlastet ist, gibt es zwei grundsätzliche Möglichkeiten:
| Möglichkeit | Bedeutung |
|---|---|
| Server stärker machen | Mehr CPU, RAM, Storage oder Netzwerk |
| Mehr Server hinzufügen | Last auf mehrere Systeme verteilen |
Was bedeutet Load Balancing?
Load Balancing bedeutet Lastverteilung.
Ein Load Balancer verteilt Anfragen auf mehrere Server.
Beispiel:
| Komponente | Aufgabe |
|---|---|
| Client | Stellt eine Anfrage |
| Load Balancer | Verteilt die Anfrage |
| WEB01 | Webserver 1 |
| WEB02 | Webserver 2 |
| WEB03 | Webserver 3 |
Vereinfacht:
Client
↓
Load Balancer
↓
WEB01 / WEB02 / WEB03
Der Benutzer greift auf eine zentrale Adresse zu.
Der Load Balancer entscheidet, welcher Server die Anfrage verarbeitet.
Merksatz
Load Balancing verteilt Anfragen auf mehrere Server, damit Last besser verteilt und Verfügbarkeit erhöht wird.
Warum nutzt man Load Balancing?
| Grund | Erklärung |
|---|---|
| Mehr Leistung | Mehrere Server teilen sich die Arbeit |
| Höhere Verfügbarkeit | Fällt ein Server aus, können andere übernehmen |
| Skalierbarkeit | Weitere Server können ergänzt werden |
| Wartbarkeit | Einzelne Server können aus dem Betrieb genommen werden |
| Bessere Benutzererfahrung | Anfragen werden schneller beantwortet |
| Ressourcennutzung | Systeme können gleichmäßiger ausgelastet werden |
Einfaches Beispiel
Eine Webseite läuft nur auf einem Server.
Problem:
| Situation | Folge |
|---|---|
| Viele Besucher | Server wird langsam |
| Server fällt aus | Webseite ist nicht erreichbar |
| Wartung notwendig | Dienst muss abgeschaltet werden |
Lösung:
Mehrere Webserver werden betrieben und ein Load Balancer davor geschaltet.
| Komponente | Aufgabe |
|---|---|
| Load Balancer | Nimmt Anfragen entgegen |
| WEB01 | Bearbeitet Teil der Anfragen |
| WEB02 | Bearbeitet Teil der Anfragen |
| WEB03 | Bearbeitet Teil der Anfragen |
Load Balancer
Ein Load Balancer ist ein System, das eingehende Anfragen verteilt.
Er kann als Hardware, Software, virtuelle Appliance oder Cloud-Dienst umgesetzt sein.
Beispiele:
| Art | Beispiel |
|---|---|
| Hardware Load Balancer | Spezielle Appliance |
| Software Load Balancer | HAProxy, Nginx, Apache, Traefik |
| Cloud Load Balancer | Load Balancer eines Cloud-Anbieters |
| Firewall mit Load-Balancing-Funktion | Firewall verteilt Anfragen |
| Kubernetes Service / Ingress | Lastverteilung in Containerumgebungen |
Backend-Server
Backend-Server sind die Server hinter dem Load Balancer.
Beispiel:
| Backend | Aufgabe |
|---|---|
| WEB01 | Webserver |
| WEB02 | Webserver |
| WEB03 | Webserver |
Der Client sieht meist nur den Load Balancer.
Die Backend-Server arbeiten im Hintergrund.
Frontend und Backend
Beim Load Balancing unterscheidet man oft zwischen Frontend und Backend.
| Begriff | Bedeutung |
|---|---|
| Frontend | Adresse oder Dienst, den der Client anspricht |
| Backend | Servergruppe, auf die Anfragen verteilt werden |
Beispiel:
| Bereich | Beispiel |
|---|---|
| Frontend | https://intranet.firma.local |
| Backend | WEB01, WEB02, WEB03 |
VIP – Virtuelle IP-Adresse
Eine VIP ist eine virtuelle IP-Adresse.
Clients verbinden sich mit dieser IP-Adresse.
Der Load Balancer nimmt die Verbindung an und verteilt sie an Backend-Server.
Beispiel:
| Komponente | IP-Adresse |
|---|---|
| Load Balancer VIP | 192.168.10.100 |
| WEB01 | 192.168.10.101 |
| WEB02 | 192.168.10.102 |
| WEB03 | 192.168.10.103 |
Die Benutzer rufen nur die VIP auf:
192.168.10.100
Der Load Balancer verteilt dann intern weiter.
DNS und Load Balancing
Oft zeigt ein DNS-Name auf die Adresse des Load Balancers.
Beispiel:
| DNS-Name | IP-Adresse |
|---|---|
| intranet.firma.local | 192.168.10.100 |
Die IP-Adresse gehört zur VIP des Load Balancers.
Vorteil:
Benutzer müssen keine einzelnen Servernamen kennen.
Load Balancing auf verschiedenen Ebenen
Load Balancing kann auf verschiedenen Netzwerkebenen arbeiten.
| Ebene | Beispiel | Bedeutung |
|---|---|---|
| Layer 4 | TCP/UDP | Verteilung nach IP und Port |
| Layer 7 | HTTP/HTTPS | Verteilung nach Inhalt der Anfrage |
Layer-4-Load-Balancing
Layer 4 arbeitet auf Transportebene.
Dabei werden Anfragen anhand von IP-Adressen und Ports verteilt.
Beispiel:
| Kriterium | Beispiel |
|---|---|
| Protokoll | TCP |
| Port | 443 |
| Ziel | WEB01 oder WEB02 |
Der Load Balancer betrachtet nicht den Inhalt der Webseite, sondern nur die Verbindung.
Vorteil:
Schnell und einfach.
Nachteil:
Weniger intelligente Entscheidungen auf Anwendungsebene.
Layer-7-Load-Balancing
Layer 7 arbeitet auf Anwendungsebene.
Bei Webdiensten kann der Load Balancer Inhalte der HTTP/HTTPS-Anfrage auswerten.
Beispiele:
| Kriterium | Beispiel |
|---|---|
| URL-Pfad | /shop geht zu SHOP01 |
| Hostname | api.firma.local geht zu API01 |
| Header | Entscheidung nach HTTP-Header |
| Cookie | Sitzung einem Server zuordnen |
Vorteil:
Sehr flexibel.
Nachteil:
Komplexer und oft rechenintensiver.
Layer 4 vs. Layer 7
| Merkmal | Layer 4 | Layer 7 |
|---|---|---|
| Ebene | Transport | Anwendung |
| Entscheidung nach | IP, Port, Protokoll | URL, Hostname, Header, Cookie |
| Beispiel | TCP 443 verteilen | /api auf API-Server verteilen |
| Geschwindigkeit | Oft schneller | Mehr Verarbeitung |
| Flexibilität | Geringer | Höher |
Health Check
Ein Health Check prüft, ob ein Backend-Server erreichbar und funktionsfähig ist.
Beispiel:
Der Load Balancer prüft regelmäßig:
| Prüfung | Bedeutung |
|---|---|
| Ping | Server erreichbar? |
| TCP-Port | Dienstport offen? |
| HTTP-Status | Webserver antwortet korrekt? |
| API-Prüfung | Anwendung funktioniert wirklich? |
| Datenbankprüfung | Backend kann Datenbank erreichen? |
Wenn ein Server nicht gesund ist, nimmt der Load Balancer ihn aus der Verteilung.
Warum Health Checks wichtig sind
Ohne Health Checks könnte der Load Balancer weiterhin Anfragen an einen defekten Server senden.
Beispiel:
| Situation | Ohne Health Check | Mit Health Check |
|---|---|---|
| WEB02 fällt aus | Benutzer bekommen Fehler | WEB02 wird entfernt |
| Anwendung hängt | Anfragen landen trotzdem dort | Server wird als fehlerhaft erkannt |
| Wartung | Benutzer werden gestört | Server kann vorher deaktiviert werden |
Backend aus der Verteilung nehmen
Ein Backend-Server kann bewusst aus der Lastverteilung genommen werden.
Das nennt man oft:
| Begriff | Bedeutung |
|---|---|
| Disable | Server deaktivieren |
| Drain | Bestehende Verbindungen auslaufen lassen |
| Maintenance Mode | Server wird gewartet |
| Out of Rotation | Server erhält keine neuen Anfragen |
Typischer Ablauf bei Wartung:
| Schritt | Erklärung |
|---|---|
| Server aus Rotation nehmen | Keine neuen Anfragen |
| Bestehende Sitzungen auslaufen lassen | Benutzer nicht hart trennen |
| Updates installieren | Server warten |
| Funktion prüfen | Dienst testen |
| Server wieder aktivieren | Neue Anfragen erlauben |
Load-Balancing-Methoden
Der Load Balancer kann unterschiedliche Verfahren nutzen.
Wichtige Methoden:
| Methode | Erklärung |
|---|---|
| Round Robin | Anfragen werden der Reihe nach verteilt |
| Least Connections | Server mit wenigsten Verbindungen bekommt nächste Anfrage |
| Weighted Round Robin | Server mit höherem Gewicht bekommt mehr Anfragen |
| IP Hash | Client-IP entscheidet über Zielserver |
| Random | Zufällige Verteilung |
| Response Time | Schnellster Server wird bevorzugt |
Round Robin
Round Robin verteilt Anfragen der Reihe nach.
Beispiel:
| Anfrage | Zielserver |
|---|---|
| 1 | WEB01 |
| 2 | WEB02 |
| 3 | WEB03 |
| 4 | WEB01 |
| 5 | WEB02 |
Vorteil:
Einfaches Verfahren.
Nachteil:
Berücksichtigt nicht automatisch, ob ein Server stärker oder schwächer ist.
Least Connections
Least Connections verteilt neue Anfragen an den Server mit den wenigsten aktiven Verbindungen.
Beispiel:
| Server | Aktive Verbindungen |
|---|---|
| WEB01 | 50 |
| WEB02 | 20 |
| WEB03 | 35 |
Die nächste Anfrage geht an WEB02.
Vorteil:
Sinnvoll, wenn Verbindungen unterschiedlich lange dauern.
Weighted Round Robin
Bei Weighted Round Robin bekommen stärkere Server mehr Anfragen.
Beispiel:
| Server | Gewicht |
|---|---|
| WEB01 | 3 |
| WEB02 | 1 |
| WEB03 | 1 |
WEB01 bekommt mehr Anfragen, weil er leistungsfähiger ist.
IP Hash
Bei IP Hash wird anhand der Client-IP entschieden, welcher Backend-Server genutzt wird.
Vorteil:
Ein Client landet häufig wieder auf demselben Server.
Nachteil:
Die Verteilung kann ungleichmäßig werden, wenn viele Clients über dieselbe öffentliche IP kommen.
Session Persistence
Session Persistence bedeutet, dass ein Benutzer während einer Sitzung immer wieder beim gleichen Backend-Server landet.
Andere Begriffe:
| Begriff | Bedeutung |
|---|---|
| Sticky Session | Benutzer bleibt am gleichen Server |
| Session Affinity | Sitzung wird einem Backend zugeordnet |
Das ist wichtig, wenn eine Anwendung Sitzungsdaten lokal auf dem Backend-Server speichert.
Warum Sticky Sessions nötig sein können
Beispiel:
Ein Webshop speichert den Warenkorb lokal auf WEB01.
Wenn der Benutzer bei der nächsten Anfrage auf WEB02 landet, kennt WEB02 den Warenkorb nicht.
Lösung:
| Lösung | Erklärung |
|---|---|
| Sticky Session | Benutzer bleibt auf WEB01 |
| Gemeinsamer Session-Speicher | Alle Webserver greifen auf dieselbe Session zu |
| Anwendung stateless bauen | Keine lokale Sitzung auf Webserver |
Nachteil von Sticky Sessions
Sticky Sessions können die Lastverteilung verschlechtern.
Beispiel:
Wenn viele aktive Benutzer auf WEB01 gebunden sind, wird WEB01 stärker belastet als andere Server.
Besser ist oft:
| Ansatz | Vorteil |
|---|---|
| Zentraler Session-Speicher | Benutzer können auf jedem Webserver landen |
| Stateless-Anwendung | Einfacher zu skalieren |
| Datenbank oder Redis für Sessions | Einheitlicher Sitzungszustand |
Stateless
Stateless bedeutet zustandslos.
Ein Server speichert keinen wichtigen Sitzungszustand lokal.
Beispiel:
Jede Anfrage enthält alle nötigen Informationen oder nutzt einen zentralen Speicher.
Vorteil:
| Vorteil | Erklärung |
|---|---|
| Einfacher zu skalieren | Anfragen können auf jeden Server |
| Einfacher ausfallsicher | Ausfall eines Servers weniger kritisch |
| Besser für Load Balancing | Keine feste Bindung nötig |
Stateful
Stateful bedeutet zustandsbehaftet.
Ein Server speichert Informationen über den aktuellen Zustand einer Sitzung oder Anwendung.
Beispiele:
| Zustand | Beispiel |
|---|---|
| Benutzersitzung | Login-Session |
| Warenkorb | Webshop |
| Lokale Datei | Upload liegt nur auf einem Server |
| Datenbankzustand | Transaktionen |
Stateful-Anwendungen sind schwieriger zu skalieren.
Stateless vs. Stateful
| Merkmal | Stateless | Stateful |
|---|---|---|
| Sitzungsdaten lokal | Nein | Ja |
| Skalierung | Einfacher | Schwieriger |
| Load Balancing | Einfacher | Oft Sticky Sessions nötig |
| Ausfallsicherheit | Besser | Komplexer |
| Beispiel | Statische Webseite | Warenkorb lokal auf Webserver |
Failover vs. Load Balancing
Failover und Load Balancing werden oft verwechselt.
| Begriff | Hauptziel |
|---|---|
| Failover | Übernahme bei Ausfall |
| Load Balancing | Verteilung von Last |
Beispiel Failover:
Eine VM läuft auf HV01.
HV01 fällt aus.
Die VM wird auf HV02 gestartet.
Beispiel Load Balancing:
Drei Webserver laufen gleichzeitig.
Ein Load Balancer verteilt Benutzeranfragen auf alle drei Server.
Failover-Cluster vs. Load-Balancing-Cluster
| Merkmal | Failover-Cluster | Load-Balancing-Cluster |
|---|---|---|
| Ziel | Ausfallsicherheit | Lastverteilung |
| Normalbetrieb | Oft eine aktive Ressource | Mehrere aktive Server |
| Ausfall | Dienst wechselt oder startet neu | Anfragen gehen an andere Server |
| Beispiel | VM-Failover | Webserver-Farm |
| Unterbrechung | Häufig kurz möglich | Oft weniger spürbar |
Load Balancing und Hochverfügbarkeit
Load Balancing kann auch zur Hochverfügbarkeit beitragen.
Wenn ein Backend-Server ausfällt, kann der Load Balancer ihn aus der Verteilung nehmen.
Beispiel:
| Backend | Zustand |
|---|---|
| WEB01 | Online |
| WEB02 | Ausgefallen |
| WEB03 | Online |
Der Load Balancer sendet neue Anfragen nur noch an WEB01 und WEB03.
Wichtig:
Der Load Balancer selbst darf kein Single Point of Failure sein.
Load Balancer als Single Point of Failure
Wenn es nur einen Load Balancer gibt, kann dieser selbst zur Schwachstelle werden.
Beispiel:
| Komponente | Risiko |
|---|---|
| Ein Load Balancer | Fällt er aus, ist der Dienst nicht erreichbar |
| Mehrere Webserver | Helfen nicht, wenn der Load Balancer ausfällt |
Lösung:
Load Balancer redundant betreiben.
Redundante Load Balancer
Bei redundanten Load Balancern gibt es mindestens zwei Load-Balancer-Systeme.
Beispiel:
| Load Balancer | Zustand |
|---|---|
| LB01 | Aktiv |
| LB02 | Standby |
Fällt LB01 aus, übernimmt LB02.
Das kann über eine virtuelle IP-Adresse erfolgen.
VRRP
VRRP steht für Virtual Router Redundancy Protocol.
Es wird verwendet, um eine virtuelle IP-Adresse zwischen mehreren Systemen hochverfügbar bereitzustellen.
Beispiel:
| System | Zustand |
|---|---|
| LB01 | Master |
| LB02 | Backup |
| VIP | 192.168.10.100 |
Wenn LB01 ausfällt, übernimmt LB02 die VIP.
Keepalived
Keepalived ist eine Software, die häufig VRRP unter Linux bereitstellt.
Typischer Einsatz:
| Komponente | Aufgabe |
|---|---|
| HAProxy | Load Balancing |
| Keepalived | VIP-Failover zwischen Load Balancern |
So kann ein Load Balancer selbst hochverfügbar aufgebaut werden.
Reverse Proxy
Ein Reverse Proxy nimmt Anfragen von Clients entgegen und leitet sie an interne Server weiter.
Er kann auch Load Balancing übernehmen.
Beispiele:
| Reverse Proxy | Einsatz |
|---|---|
| Nginx | Webserver, Reverse Proxy, Load Balancer |
| HAProxy | Load Balancer und Proxy |
| Traefik | Reverse Proxy für Containerumgebungen |
| Apache | Webserver und Reverse Proxy |
| Caddy | Webserver mit automatischer TLS-Verwaltung |
Reverse Proxy vs. Load Balancer
| Begriff | Bedeutung |
|---|---|
| Reverse Proxy | Vermittelt Anfragen an interne Server |
| Load Balancer | Verteilt Anfragen auf mehrere Server |
Ein Reverse Proxy kann gleichzeitig ein Load Balancer sein.
Beispiel:
Nginx nimmt HTTPS-Anfragen entgegen und verteilt sie auf WEB01, WEB02 und WEB03.
SSL/TLS-Terminierung
SSL/TLS-Terminierung bedeutet, dass der Load Balancer oder Reverse Proxy die verschlüsselte HTTPS-Verbindung entgegennimmt und entschlüsselt.
Beispiel:
| Verbindung | Verschlüsselung |
|---|---|
| Client → Load Balancer | HTTPS |
| Load Balancer → Backend | HTTP oder HTTPS |
Vorteile:
| Vorteil | Erklärung |
|---|---|
| Zentrale Zertifikatsverwaltung | Zertifikate nur am Load Balancer |
| Backend entlasten | Verschlüsselung wird zentral verarbeitet |
| Inhalt auswertbar | Layer-7-Regeln möglich |
Nachteil:
Wenn intern HTTP genutzt wird, muss das interne Netzwerk ausreichend geschützt sein.
Ende-zu-Ende-Verschlüsselung
Bei Ende-zu-Ende-Verschlüsselung bleibt die Verbindung auch bis zum Backend verschlüsselt.
Beispiel:
| Verbindung | Verschlüsselung |
|---|---|
| Client → Load Balancer | HTTPS |
| Load Balancer → Backend | HTTPS |
Vorteil:
Auch interner Verkehr ist verschlüsselt.
Nachteil:
Zertifikatsverwaltung und Fehleranalyse können komplexer werden.
Skalierung
Skalierung bedeutet, ein System leistungsfähiger zu machen.
Es gibt zwei Grundarten:
| Art | Bedeutung |
|---|---|
| Vertikale Skalierung | Einzelnes System stärker machen |
| Horizontale Skalierung | Weitere Systeme hinzufügen |
Scale-Up
Scale-Up bedeutet vertikale Skalierung.
Dabei wird ein einzelner Server stärker gemacht.
Beispiele:
| Maßnahme | Wirkung |
|---|---|
| Mehr RAM | Mehr Arbeitsspeicher |
| Mehr CPU-Kerne | Mehr Rechenleistung |
| Schnellere SSDs | Bessere Storage-Performance |
| Schnellere Netzwerkkarte | Mehr Netzwerkdurchsatz |
| Größere VM | Mehr Ressourcen für Anwendung |
Vorteile von Scale-Up
| Vorteil | Erklärung |
|---|---|
| Einfaches Konzept | Ein System wird stärker |
| Weniger Architekturänderung | Anwendung bleibt meist gleich |
| Keine Lastverteilung nötig | Ein Server verarbeitet alles |
| Gut für bestimmte Anwendungen | Besonders bei nicht verteilbaren Anwendungen |
Nachteile von Scale-Up
| Nachteil | Erklärung |
|---|---|
| Hardwaregrenze | Irgendwann ist maximale Größe erreicht |
| Teuer | Große Systeme können sehr teuer sein |
| Single Point of Failure bleibt möglich | Ein Server bleibt kritisch |
| Wartung schwieriger | Dienst hängt an einem System |
| Nicht beliebig skalierbar | Begrenzung durch Hardware |
Scale-Out
Scale-Out bedeutet horizontale Skalierung.
Dabei werden mehrere Systeme eingesetzt.
Beispiel:
Statt einem Webserver werden drei Webserver betrieben.
| Server | Aufgabe |
|---|---|
| WEB01 | Webserver |
| WEB02 | Webserver |
| WEB03 | Webserver |
Ein Load Balancer verteilt die Anfragen.
Vorteile von Scale-Out
| Vorteil | Erklärung |
|---|---|
| Gut erweiterbar | Weitere Server können ergänzt werden |
| Bessere Ausfallsicherheit | Ausfall eines Servers kann abgefangen werden |
| Lastverteilung möglich | Arbeit wird verteilt |
| Wartung einfacher | Einzelne Server können aus Rotation genommen werden |
| Günstigere Standardhardware möglich | Mehrere kleinere Systeme statt ein sehr großes |
Nachteile von Scale-Out
| Nachteil | Erklärung |
|---|---|
| Anwendung muss geeignet sein | Nicht jede Anwendung kann verteilt arbeiten |
| Mehr Komplexität | Load Balancer, Sessions, Datenhaltung |
| Datenkonsistenz beachten | Mehrere Systeme müssen gleiche Daten sehen |
| Monitoring aufwendiger | Mehr Komponenten |
| Netzwerk wichtiger | Kommunikation zwischen Systemen |
Scale-Up vs. Scale-Out
| Merkmal | Scale-Up | Scale-Out |
|---|---|---|
| Prinzip | Ein System stärker machen | Mehr Systeme hinzufügen |
| Beispiel | Mehr RAM in DB01 | WEB01, WEB02, WEB03 |
| Komplexität | Oft einfacher | Komplexer |
| Grenze | Hardwarelimit | Architekturlimit |
| Ausfallsicherheit | Nicht automatisch besser | Kann besser werden |
| Typischer Einsatz | Datenbanken, einzelne Anwendungen | Webserver, APIs, Microservices |
Vertikale Skalierung bei VMs
Bei virtuellen Maschinen ist Scale-Up oft einfach möglich.
Beispiele:
| Änderung | Beispiel |
|---|---|
| Mehr vCPU | 2 vCPU auf 4 vCPU |
| Mehr RAM | 4 GB auf 8 GB |
| Größere vDisk | 80 GB auf 160 GB |
| Schnellere Storage-Klasse | HDD auf SSD/NVMe |
Wichtig:
Mehr Ressourcen helfen nur, wenn die Anwendung dadurch wirklich profitiert.
Horizontale Skalierung bei VMs
Bei horizontaler Skalierung werden mehrere VMs mit gleicher oder ähnlicher Aufgabe betrieben.
Beispiel:
| VM | Aufgabe |
|---|---|
| WEB01 | Webserver |
| WEB02 | Webserver |
| WEB03 | Webserver |
Ein Load Balancer verteilt die Anfragen.
Das funktioniert besonders gut bei Webservern und APIs.
Skalierung bei Datenbanken
Datenbanken sind schwieriger horizontal zu skalieren als Webserver.
Gründe:
| Problem | Erklärung |
|---|---|
| Datenkonsistenz | Alle Daten müssen korrekt bleiben |
| Schreibzugriffe | Mehrere schreibende Systeme sind komplex |
| Transaktionen | Vorgänge müssen vollständig und korrekt sein |
| Replikation | Daten müssen übertragen werden |
| Konflikte | Gleichzeitige Änderungen müssen behandelt werden |
Datenbank-Replikation
Replikation bedeutet, dass Daten von einer Datenbank auf eine andere übertragen werden.
Typische Varianten:
| Variante | Bedeutung |
|---|---|
| Primary/Replica | Eine Hauptdatenbank, eine oder mehrere Kopien |
| Read Replica | Kopie für lesende Zugriffe |
| Multi-Master | Mehrere Systeme können schreiben |
| Synchrone Replikation | Bestätigung erst nach Schreiben auf mehrere Systeme |
| Asynchrone Replikation | Übertragung zeitversetzt |
Read Replica
Eine Read Replica ist eine Kopie der Datenbank für lesende Anfragen.
Beispiel:
| Datenbank | Aufgabe |
|---|---|
| DB01 | Schreiben und Lesen |
| DB02 | Lesen |
| DB03 | Lesen |
Vorteil:
Leselast kann verteilt werden.
Nachteil:
Schreibzugriffe laufen weiterhin über die Hauptdatenbank.
Webserver-Skalierung
Webserver sind oft gut horizontal skalierbar.
Beispiel:
| Komponente | Aufgabe |
|---|---|
| LB01 | Load Balancer |
| WEB01 | Webserver |
| WEB02 | Webserver |
| WEB03 | Webserver |
| DB01 | Datenbank |
Wichtig:
Alle Webserver müssen auf dieselben Inhalte oder dieselbe Anwendung zugreifen können.
Gemeinsame Daten bei mehreren Webservern
Wenn mehrere Webserver genutzt werden, müssen gemeinsame Daten sauber behandelt werden.
Möglichkeiten:
| Lösung | Erklärung |
|---|---|
| Gemeinsames Dateisystem | Alle Webserver greifen auf gleiche Dateien zu |
| Deployment auf alle Server | Anwendung wird identisch verteilt |
| Objekt-Speicher | Dateien liegen zentral |
| Datenbank | Dynamische Daten liegen zentral |
| Session-Speicher | Sitzungen liegen zentral, z. B. Redis |
Rolling Update
Ein Rolling Update bedeutet, dass Systeme nacheinander aktualisiert werden.
Beispiel:
| Schritt | Aktion |
|---|---|
| 1 | WEB01 aus Load Balancer nehmen |
| 2 | WEB01 aktualisieren |
| 3 | WEB01 testen |
| 4 | WEB01 wieder aktivieren |
| 5 | WEB02 aktualisieren |
| 6 | WEB03 aktualisieren |
Vorteil:
Der Dienst bleibt während des Updates verfügbar.
Blue-Green-Deployment
Blue-Green-Deployment bedeutet, dass es zwei Umgebungen gibt.
| Umgebung | Zustand |
|---|---|
| Blue | Aktive Produktion |
| Green | Neue Version |
Ablauf:
| Schritt | Erklärung |
|---|---|
| 1 | Neue Version wird in Green bereitgestellt |
| 2 | Green wird getestet |
| 3 | Load Balancer schaltet auf Green |
| 4 | Blue bleibt als Rückfalloption |
Vorteil:
Schneller Rückwechsel möglich.
Canary Deployment
Beim Canary Deployment bekommt zuerst nur ein kleiner Teil der Benutzer die neue Version.
Beispiel:
| Anteil | Version |
|---|---|
| 95 % | Alte Version |
| 5 % | Neue Version |
Wenn keine Probleme auftreten, wird der Anteil erhöht.
Vorteil:
Fehler betreffen zunächst nur wenige Benutzer.
Autoscaling
Autoscaling bedeutet, dass Systeme automatisch hinzugefügt oder entfernt werden.
Beispiel:
| Last | Aktion |
|---|---|
| CPU hoch | Neue Instanz starten |
| Wenig Last | Instanz entfernen |
Autoscaling ist besonders in Cloud- und Containerumgebungen verbreitet.
In klassischen VM-Umgebungen ist es möglich, aber oft aufwendiger.
Container und Skalierung
Container lassen sich oft sehr gut horizontal skalieren.
Beispiel:
| Dienst | Instanzen |
|---|---|
| Web-App | 5 Container |
| API | 3 Container |
| Worker | 4 Container |
Container-Orchestrierungssysteme wie Kubernetes können Container automatisch verteilen, überwachen und neu starten.
Kubernetes als Beispiel
Kubernetes ist eine Plattform zur Verwaltung von Containern in Clustern.
Typische Funktionen:
| Funktion | Erklärung |
|---|---|
| Scheduling | Container auf Nodes verteilen |
| Self-Healing | Fehlerhafte Container neu starten |
| Scaling | Mehr Instanzen starten |
| Service Discovery | Dienste auffindbar machen |
| Rolling Updates | Schrittweise Updates |
| Load Balancing | Anfragen auf Pods verteilen |
Für die IHK reicht meistens das Grundverständnis:
Kubernetes verteilt und verwaltet Container auf mehreren Nodes.
Microservices
Microservices sind kleine, getrennte Dienste, die zusammen eine Anwendung bilden.
Beispiel:
| Microservice | Aufgabe |
|---|---|
| User-Service | Benutzerverwaltung |
| Payment-Service | Zahlung |
| Product-Service | Produktdaten |
| Order-Service | Bestellungen |
| Mail-Service | E-Mails |
Vorteil:
Einzelne Dienste können unabhängig skaliert werden.
Nachteil:
Die Gesamtarchitektur wird komplexer.
Monolithische Anwendung
Eine monolithische Anwendung enthält viele Funktionen in einem großen System.
Beispiel:
Eine Anwendung enthält Benutzerverwaltung, Bestellungen, Zahlung und E-Mail-Funktion in einem Paket.
| Vorteil | Nachteil |
|---|---|
| Einfacher zu verstehen | Schwerer einzeln zu skalieren |
| Weniger verteilte Komponenten | Änderungen können mehr Risiko haben |
| Einfacheres Deployment | Größere Abhängigkeiten |
Monolith vs. Microservices
| Merkmal | Monolith | Microservices |
|---|---|---|
| Aufbau | Eine große Anwendung | Viele kleine Dienste |
| Skalierung | Gesamte Anwendung skalieren | Einzelne Dienste skalieren |
| Komplexität | Anfangs einfacher | Betrieb komplexer |
| Deployment | Ein Paket | Viele Deployments |
| Fehlerauswirkung | Fehler kann große Teile betreffen | Fehler kann begrenzt sein |
Lastspitzen
Lastspitzen sind kurzzeitig hohe Belastungen.
Beispiele:
| Situation | Lastspitze |
|---|---|
| Viele Benutzer melden sich morgens an | Login-System belastet |
| Sonderangebot im Webshop | Viele Besucher |
| Backup startet | Storage und Netzwerk belastet |
| Monatsabschluss | Datenbank stark belastet |
| Softwareverteilung | Netzwerk stark belastet |
Skalierung und Load Balancing helfen, Lastspitzen besser abzufangen.
Bottleneck
Ein Bottleneck ist ein Engpass.
Beispiele:
| Engpass | Auswirkung |
|---|---|
| CPU | Anwendung rechnet langsam |
| RAM | System lagert aus |
| Storage | VMs reagieren träge |
| Netzwerk | Datenübertragung langsam |
| Datenbank | Webanwendung langsam |
| einzelner Server | Dienst überlastet |
Merksatz:
Ein System ist oft nur so schnell wie sein größter Engpass.
Kapazitätsplanung
Kapazitätsplanung bedeutet, Ressourcen rechtzeitig zu planen.
Wichtige Fragen:
| Frage | Bedeutung |
|---|---|
| Wie viele Benutzer nutzen den Dienst? | Last abschätzen |
| Wann treten Lastspitzen auf? | Spitzen einplanen |
| Welche Ressource ist kritisch? | CPU, RAM, Storage, Netzwerk |
| Wie schnell wächst die Nutzung? | Zukunft planen |
| Welche Verfügbarkeit wird benötigt? | HA und Redundanz planen |
| Wie wird skaliert? | Scale-Up oder Scale-Out |
Monitoring für Skalierung
Um richtig zu skalieren, braucht man Monitoring.
Wichtige Werte:
| Bereich | Messwert |
|---|---|
| CPU | Auslastung, Load |
| RAM | Nutzung, Swapping |
| Storage | IOPS, Latenz, freier Speicher |
| Netzwerk | Bandbreite, Paketverlust |
| Webserver | Anfragen pro Sekunde |
| Anwendung | Antwortzeit, Fehlerquote |
| Datenbank | Abfragen, Locks, Replikationsverzögerung |
| Load Balancer | aktive Verbindungen, fehlerhafte Backends |
Antwortzeit
Antwortzeit beschreibt, wie lange ein Dienst braucht, um auf eine Anfrage zu reagieren.
Beispiel:
| Antwortzeit | Bewertung |
|---|---|
| 100 ms | Sehr schnell |
| 500 ms | Gut |
| 2 Sekunden | Spürbar langsam |
| 10 Sekunden | Kritisch |
Hohe Antwortzeiten können durch CPU, RAM, Storage, Netzwerk oder Datenbankprobleme entstehen.
Throughput
Throughput bedeutet Durchsatz.
Je nach Dienst kann das unterschiedlich gemessen werden.
Beispiele:
| Dienst | Throughput |
|---|---|
| Webserver | Anfragen pro Sekunde |
| Netzwerk | Mbit/s oder Gbit/s |
| Storage | MB/s oder IOPS |
| Datenbank | Abfragen pro Sekunde |
| Backup | GB pro Stunde |
Fehlerquote
Die Fehlerquote zeigt, wie viele Anfragen fehlschlagen.
Beispiele:
| Fehler | Bedeutung |
|---|---|
| HTTP 500 | Serverfehler |
| HTTP 502 | Bad Gateway |
| HTTP 503 | Dienst nicht verfügbar |
| Timeout | Antwort dauert zu lange |
| Verbindungsfehler | Backend nicht erreichbar |
Eine steigende Fehlerquote kann auf Überlastung oder Ausfälle hinweisen.
Load Balancer Monitoring
Beim Load Balancer sollten besonders diese Werte überwacht werden:
| Wert | Bedeutung |
|---|---|
| Aktive Verbindungen | Aktuelle Last |
| Backend-Status | Server online oder offline |
| Antwortzeiten | Geschwindigkeit der Backends |
| Fehlercodes | Probleme bei Anwendungen |
| Verbindungsabbrüche | Netzwerk- oder Serverprobleme |
| Traffic | Datenmenge |
| Health-Check-Fehler | Backend-Probleme |
Sicherheit beim Load Balancing
Ein Load Balancer oder Reverse Proxy ist oft ein zentraler Einstiegspunkt.
Daher ist Sicherheit wichtig.
Maßnahmen:
| Maßnahme | Erklärung |
|---|---|
| TLS sauber konfigurieren | Sichere HTTPS-Verbindungen |
| Zugriff beschränken | Nur notwendige Ports öffnen |
| Backend-Netz schützen | Backends nicht direkt öffentlich machen |
| Logging aktivieren | Anfragen nachvollziehen |
| Updates installieren | Sicherheitslücken schließen |
| Rate Limiting | Schutz vor zu vielen Anfragen |
| WAF nutzen | Schutz vor Webangriffen |
| Adminzugriff absichern | Management nicht öffentlich |
Rate Limiting
Rate Limiting begrenzt die Anzahl von Anfragen.
Beispiel:
Ein Client darf maximal 100 Anfragen pro Minute stellen.
Ziel:
| Ziel | Erklärung |
|---|---|
| Schutz vor Missbrauch | Zu viele Anfragen blockieren |
| Schutz vor Überlastung | Dienst stabil halten |
| Schutz vor Brute Force | Loginversuche begrenzen |
| Fairness | Ressourcen gleichmäßiger verteilen |
WAF
WAF steht für Web Application Firewall.
Eine WAF schützt Webanwendungen vor bestimmten Angriffen.
Beispiele:
| Angriff | Erklärung |
|---|---|
| SQL Injection | Manipulation von Datenbankabfragen |
| Cross-Site Scripting | Einschleusen von Skripten |
| Path Traversal | Zugriff auf unerlaubte Dateien |
| Brute Force | Viele Loginversuche |
| Exploit-Versuche | Ausnutzen bekannter Schwachstellen |
Eine WAF ersetzt keine sichere Anwendung, kann aber zusätzlichen Schutz bieten.
Load Balancing in der DMZ
Öffentlich erreichbare Dienste stehen oft in einer DMZ.
Beispiel:
| Zone | Systeme |
|---|---|
| Internet | Benutzer |
| DMZ | Load Balancer, Reverse Proxy |
| Internes Netz | Anwendung, Datenbank |
Vorteil:
Interne Server sind nicht direkt aus dem Internet erreichbar.
Typische Webserver-Architektur
Beispiel:
| Ebene | Systeme |
|---|---|
| Internet | Benutzer |
| DMZ | Reverse Proxy / Load Balancer |
| Webebene | WEB01, WEB02 |
| Anwendungsebene | APP01, APP02 |
| Datenbankebene | DB01 |
| Backup | BKP01 |
Diese Trennung verbessert Sicherheit, Wartbarkeit und Skalierbarkeit.
Drei-Schichten-Architektur
Eine typische Anwendung kann aus drei Schichten bestehen.
| Schicht | Aufgabe |
|---|---|
| Präsentationsschicht | Weboberfläche |
| Anwendungsschicht | Logik und Verarbeitung |
| Datenschicht | Datenbank und Speicher |
Beispiel:
| Schicht | Beispiel |
|---|---|
| Präsentation | WEB01, WEB02 |
| Anwendung | APP01, APP02 |
| Daten | DB01, DB02 |
Warum Datenbanken oft nicht einfach load-balanced werden
Webserver können häufig einfach vervielfacht werden.
Datenbanken sind schwieriger.
Grund:
Datenbanken müssen konsistente Daten liefern.
Probleme:
| Problem | Erklärung |
|---|---|
| Schreibzugriffe | Änderungen dürfen nicht widersprüchlich sein |
| Transaktionen | Vorgänge müssen vollständig sein |
| Locks | Gleichzeitige Zugriffe müssen geregelt werden |
| Replikationsverzögerung | Kopien können kurzzeitig alt sein |
| Konflikte | Mehrere Schreibstellen sind schwierig |
Caching
Caching bedeutet Zwischenspeichern.
Ziel:
Häufig benötigte Daten schneller bereitstellen.
Beispiele:
| Cache | Beispiel |
|---|---|
| Browser-Cache | Bilder und CSS lokal speichern |
| Reverse-Proxy-Cache | Webseiten zwischenspeichern |
| Datenbank-Cache | Häufige Abfragen im RAM |
| Application-Cache | Ergebnisse zwischenspeichern |
| CDN | Inhalte weltweit verteilen |
Caching kann Last reduzieren, ersetzt aber keine saubere Skalierung.
CDN
CDN steht für Content Delivery Network.
Ein CDN verteilt Inhalte über viele Standorte.
Typische Inhalte:
| Inhalt | Beispiel |
|---|---|
| Bilder | Produktbilder |
| Videos | Streaming-Inhalte |
| JavaScript | Webdateien |
| CSS | Stylesheets |
| Downloads | Dateien |
Vorteile:
| Vorteil | Erklärung |
|---|---|
| Schnellere Auslieferung | Nähe zum Benutzer |
| Weniger Last auf Ursprungsserver | CDN liefert Inhalte aus |
| Schutz bei Lastspitzen | Mehr Verteilung |
| Teilweise DDoS-Schutz | Je nach Anbieter |
DDoS und Last
DDoS steht für Distributed Denial of Service.
Dabei wird ein Dienst mit sehr vielen Anfragen überlastet.
Load Balancing kann helfen, ist aber allein kein vollständiger DDoS-Schutz.
Maßnahmen:
| Maßnahme | Erklärung |
|---|---|
| Rate Limiting | Anfragen begrenzen |
| CDN | Last verteilen |
| WAF | Webangriffe filtern |
| DDoS-Schutzdienst | Angriffstraffic abwehren |
| Monitoring | Angriff erkennen |
| Netzwerkfilter | Unerwünschten Traffic blockieren |
Typische Fehler beim Load Balancing
| Fehler | Auswirkung |
|---|---|
| Kein Health Check | Anfragen gehen an defekte Server |
| Load Balancer nicht redundant | Load Balancer wird Single Point of Failure |
| Sticky Sessions falsch geplant | Ungleichmäßige Last |
| Backends direkt öffentlich erreichbar | Sicherheitsrisiko |
| Keine gemeinsamen Sessions | Benutzer verlieren Sitzungen |
| TLS falsch konfiguriert | Sicherheitsproblem |
| Keine Logs | Fehler schwer nachvollziehbar |
| Keine Ressourcenreserve | Ausfall eines Backends überlastet andere |
| Datenbank als Engpass vergessen | Webserver skalieren, aber DB bleibt langsam |
| Kein Monitoring | Überlastung wird zu spät erkannt |
Gute Praxis
| Empfehlung | Grund |
|---|---|
| Health Checks einrichten | Defekte Backends erkennen |
| Load Balancer redundant betreiben | Kein Single Point of Failure |
| Backends nicht direkt öffentlich machen | Sicherheit erhöhen |
| TLS sauber konfigurieren | Sichere Kommunikation |
| Sessions zentral speichern | Besser skalierbar |
| Stateless-Anwendungen bevorzugen | Einfachere Lastverteilung |
| Monitoring einrichten | Last und Fehler erkennen |
| Ressourcenreserven einplanen | Ausfälle abfangen |
| Rolling Updates nutzen | Wartung ohne Komplettausfall |
| Datenbanklast beachten | Engpässe vermeiden |
| Dokumentation pflegen | Betrieb nachvollziehbar machen |
Prüfungsnahes Beispiel 1
Aufgabe:
Eine Webseite läuft auf einem einzelnen Webserver. Bei vielen Zugriffen wird die Webseite langsam.
Frage:
Welche Maßnahme kann helfen?
Mögliche Antwort:
Es können mehrere Webserver betrieben und über einen Load Balancer angesprochen werden. Der Load Balancer verteilt die Anfragen auf die Webserver. Dadurch wird die Last verteilt und die Verfügbarkeit verbessert.
Prüfungsnahes Beispiel 2
Aufgabe:
Ein Unternehmen betreibt drei Webserver hinter einem Load Balancer. Einer der Webserver fällt aus.
Frage:
Was sollte der Load Balancer tun?
Mögliche Antwort:
Der Load Balancer sollte den Ausfall über Health Checks erkennen und keine neuen Anfragen mehr an den defekten Webserver senden. Die Anfragen werden auf die verbleibenden funktionierenden Webserver verteilt.
Prüfungsnahes Beispiel 3
Aufgabe:
Ein Webshop speichert Warenkörbe lokal auf dem Webserver. Benutzer verlieren manchmal ihren Warenkorb, wenn mehrere Webserver genutzt werden.
Frage:
Was ist vermutlich das Problem?
Mögliche Antwort:
Die Anwendung ist stateful und speichert Sitzungsdaten lokal. Wenn der Benutzer bei einer späteren Anfrage auf einem anderen Webserver landet, kennt dieser den Warenkorb nicht. Lösungen sind Sticky Sessions oder ein zentraler Session-Speicher.
Prüfungsnahes Beispiel 4
Aufgabe:
Ein Administrator sagt: „Wir skalieren unsere Datenbank einfach wie unsere Webserver, indem wir mehrere Datenbankserver parallel hinter einen Load Balancer hängen.“
Frage:
Warum ist das problematisch?
Mögliche Antwort:
Datenbanken müssen Daten konsistent halten. Schreibzugriffe, Transaktionen und gleichzeitige Änderungen sind komplex. Datenbanken benötigen spezielle Replikations-, Cluster- oder Failover-Konzepte und können nicht immer wie einfache Webserver horizontal skaliert werden.
Prüfungsnahes Beispiel 5
Aufgabe:
Ein Unternehmen hat zwei Load Balancer, aber nur einer besitzt die aktive virtuelle IP-Adresse. Fällt dieser aus, übernimmt der zweite.
Frage:
Welches Prinzip wird genutzt?
Mögliche Antwort:
Es wird ein redundanter Load-Balancer-Aufbau mit virtueller IP-Adresse genutzt. Häufig wird dafür ein Verfahren wie VRRP eingesetzt. Der zweite Load Balancer übernimmt bei Ausfall die VIP.
Typische Prüfungsfrage: Was ist Load Balancing?
Mögliche Antwort:
Load Balancing bedeutet Lastverteilung. Ein Load Balancer verteilt eingehende Anfragen auf mehrere Backend-Server, damit die Last besser verteilt und die Verfügbarkeit erhöht wird.
Typische Prüfungsfrage: Warum sind Health Checks wichtig?
Mögliche Antwort:
Health Checks prüfen, ob Backend-Server erreichbar und funktionsfähig sind. Wenn ein Server ausfällt, kann der Load Balancer ihn aus der Verteilung nehmen und Anfragen nur noch an funktionierende Server senden.
Typische Prüfungsfrage: Unterschied Failover und Load Balancing
| Failover | Load Balancing |
|---|---|
| Übernahme bei Ausfall | Verteilung von Anfragen |
| Häufig eine aktive Ressource | Mehrere aktive Server |
| Ziel: Ausfallsicherheit | Ziel: Lastverteilung und Verfügbarkeit |
| Beispiel: VM startet auf anderem Host | Beispiel: Webanfragen auf mehrere Webserver |
Typische Prüfungsfrage: Was ist Scale-Up?
Mögliche Antwort:
Scale-Up bedeutet vertikale Skalierung. Dabei wird ein einzelnes System leistungsfähiger gemacht, zum Beispiel durch mehr CPU, mehr RAM, schnelleren Storage oder eine größere VM.
Typische Prüfungsfrage: Was ist Scale-Out?
Mögliche Antwort:
Scale-Out bedeutet horizontale Skalierung. Dabei werden weitere Systeme hinzugefügt, zum Beispiel mehrere Webserver hinter einem Load Balancer.
Typische Prüfungsfrage: Unterschied Scale-Up und Scale-Out
| Scale-Up | Scale-Out |
|---|---|
| Einzelnes System stärker machen | Mehr Systeme hinzufügen |
| Mehr RAM, CPU, Storage | Weitere Server oder Instanzen |
| Einfacher, aber begrenzt | Skalierbarer, aber komplexer |
| Single Point of Failure bleibt möglich | Kann Verfügbarkeit verbessern |
Typische Prüfungsfrage: Was bedeutet Sticky Session?
Mögliche Antwort:
Sticky Session bedeutet, dass ein Benutzer während einer Sitzung immer wieder demselben Backend-Server zugeordnet wird. Das ist nötig, wenn eine Anwendung Sitzungsdaten lokal auf dem Server speichert.
Typische Prüfungsfrage: Was bedeutet stateless?
Mögliche Antwort:
Stateless bedeutet, dass ein Server keinen wichtigen Sitzungszustand lokal speichert. Dadurch können Anfragen einfacher auf verschiedene Server verteilt werden, was Load Balancing und Skalierung erleichtert.
Typische Prüfungsfrage: Warum ist ein einzelner Load Balancer problematisch?
Mögliche Antwort:
Ein einzelner Load Balancer kann selbst ein Single Point of Failure sein. Wenn er ausfällt, ist der Dienst trotz mehrerer Backend-Server nicht erreichbar. Deshalb sollten Load Balancer redundant aufgebaut werden.
Typische Prüfungsfrage: Was ist ein Reverse Proxy?
Mögliche Antwort:
Ein Reverse Proxy nimmt Anfragen von Clients entgegen und leitet sie an interne Server weiter. Er kann zusätzlich TLS-Terminierung, Logging, Zugriffskontrolle und Load Balancing übernehmen.
Typische Prüfungsfrage: Was ist TLS-Terminierung?
Mögliche Antwort:
TLS-Terminierung bedeutet, dass der Load Balancer oder Reverse Proxy die HTTPS-Verbindung des Clients entgegennimmt und entschlüsselt. Danach leitet er die Anfrage intern an Backend-Server weiter.
Typische Prüfungsfrage: Warum sind Datenbanken schwieriger zu skalieren als Webserver?
Mögliche Antwort:
Datenbanken müssen Daten konsistent halten. Schreibzugriffe, Transaktionen und gleichzeitige Änderungen dürfen keine Widersprüche erzeugen. Deshalb benötigen Datenbanken spezielle Replikations- oder Clusterkonzepte.
Wichtige Begriffe
| Begriff | Kurz erklärt |
|---|---|
| Load Balancing | Lastverteilung auf mehrere Server |
| Load Balancer | System, das Anfragen verteilt |
| Backend | Zielserver hinter dem Load Balancer |
| Frontend | Adresse oder Dienst, den Clients ansprechen |
| VIP | Virtuelle IP-Adresse |
| Health Check | Prüfung eines Backends |
| Round Robin | Verteilung der Reihe nach |
| Least Connections | Server mit wenigsten Verbindungen wird bevorzugt |
| Weighted Round Robin | Gewichtete Verteilung |
| IP Hash | Zielserver anhand Client-IP |
| Sticky Session | Benutzer bleibt auf gleichem Backend |
| Session Affinity | Sitzung wird Backend zugeordnet |
| Stateless | Zustandslos |
| Stateful | Zustandsbehaftet |
| Scale-Up | Einzelnes System stärker machen |
| Scale-Out | Weitere Systeme hinzufügen |
| Reverse Proxy | Vermittler zwischen Client und internen Servern |
| TLS-Terminierung | HTTPS wird am Proxy/Load Balancer beendet |
| VRRP | Virtuelle IP für Redundanz |
| Keepalived | Linux-Software für VRRP |
| Rolling Update | Systeme nacheinander aktualisieren |
| Blue-Green-Deployment | Umschaltung zwischen zwei Umgebungen |
| Canary Deployment | Neue Version zuerst für wenige Benutzer |
| Autoscaling | Automatische Skalierung |
| Bottleneck | Engpass |
| Throughput | Durchsatz |
| Antwortzeit | Zeit bis zur Antwort |
| WAF | Web Application Firewall |
| CDN | Content Delivery Network |
Wichtige Merksätze
Load Balancing verteilt Anfragen auf mehrere Server.
Load Balancing verbessert Lastverteilung und kann die Verfügbarkeit erhöhen.
Ein Load Balancer braucht Health Checks, damit defekte Backends erkannt werden.
Ein einzelner Load Balancer kann selbst ein Single Point of Failure sein.
Scale-Up bedeutet: ein System stärker machen.
Scale-Out bedeutet: mehrere Systeme hinzufügen.
Webserver lassen sich oft leichter horizontal skalieren als Datenbanken.
Stateless-Anwendungen sind einfacher zu skalieren als stateful Anwendungen.
Sticky Sessions können nötig sein, verschlechtern aber manchmal die Lastverteilung.
Ein Reverse Proxy kann auch als Load Balancer arbeiten.
Monitoring ist notwendig, um Engpässe und Überlastung zu erkennen.
Kurzzusammenfassung
Load Balancing und Skalierung helfen dabei, Dienste leistungsfähiger und besser verfügbar zu machen.
Ein Load Balancer verteilt Anfragen auf mehrere Backend-Server.
Wichtige Ziele sind:
| Ziel | Bedeutung |
|---|---|
| Lastverteilung | Arbeit auf mehrere Server verteilen |
| Verfügbarkeit | Defekte Server aus der Verteilung nehmen |
| Skalierbarkeit | Weitere Server hinzufügen |
| Wartbarkeit | Server einzeln warten |
| Performance | Antwortzeiten verbessern |
Skalierung gibt es in zwei Grundformen:
| Art | Bedeutung |
|---|---|
| Scale-Up | Einzelnes System stärker machen |
| Scale-Out | Mehr Systeme hinzufügen |
Für die IHK ist besonders wichtig:
| Prüfungsrelevanter Punkt | Bedeutung |
|---|---|
| Load Balancing erklären | Anfragen werden verteilt |
| Health Checks verstehen | Defekte Backends erkennen |
| Failover vs. Load Balancing unterscheiden | Übernahme vs. Verteilung |
| Scale-Up vs. Scale-Out unterscheiden | Stärker machen vs. mehr Systeme |
| Stateful vs. Stateless verstehen | Sitzungszustand wichtig für Skalierung |
| Sticky Sessions kennen | Benutzer bleibt auf gleichem Server |
| Load Balancer als SPOF erkennen | Redundanz nötig |
| Datenbank-Skalierung einordnen | Komplexer als Webserver |
Der nächste logische Schritt ist:
Prüfungszusammenfassung – Virtualisierung und Cluster