APM - Begriffe

 Mehr Rechner, Relativ günstig, flexibel, Muss App an verteiltes Setting anpassen, Prinzipiell immer machbar, aber nicht jede App ist parallelisier bar

Last muss auf mehrere Server verteilt werden! Eigentliche Server-Requests werden auf mehrere Server verteilt -> Load Balancer, Separate Maschine, Einstiegspunkt des Dienstes, Verteilt eingehende Requests dynamisch, Hardware- oder Software basiert

 LB ändert Frame, schickt Request an Server weiter, Server antwortet direkt an Client, Vorteil: Auf IP-Level (Layer 3+) muss nichts am Request geändert werden

LB trenn Client von Server, welche in privatem Subnet sind, wenn LB Request erhält, übersetzt er einfach Ziel-IP. Vorteil: Einfachere Konfiguration, Möglichkeit für Traffic Inspection, Nachteil: Server hat andere IP als Client sieht, App muss evt. Angepasst weden

 Trennung wie bei NAT, aber Requests werden auf Application Layer dekodiert, Beispiel: Client baut HTTP-Verbindung mit LB auf, LB mit Server, Vorteile: Balancing-Entscheidung basierend auf App- Informationen (z.B. Cookies) möglich, LB kann TLS und Caching übernehmen, Nachteil: RessourenVerbrauch

 Damit LB weiss welche Server verfügbar sind, führt er regelmässige Health Checks durch, Pings, TCP Verbindungsaufbau, http Requests

 LB sollte sicherstellen, dass Client immer auf gleichm Server landet. LB muss client-server Verhältnis lernen IP-Level: LB erstellt Tabelle mit Zuordnung Client-IP -> Server,Einfach, aber keine Lösung für Clients mit wechselnder IP! Cookie Learning (HTTP-Level): LB inspiziert HTTP-Request (Session-Cookie), erstellt Tabelle mit Zuordnung Session-ID -> Server, Probleme: 1) Endlicher Speicher, 2) Ausfall von Master-LB Cookie Insertion (HTTP-Level): LB fügt eigenes Cookie in HTTP-Messages ein, Löst beide Probleme, aber ist rechenintensiver
 

Mehrere vernetze Rechner, die zusammenarbeiten, und die man als ein System ansehen kann. Normalerweise nahe beieinander, Über privates Netz verbunden (interconnect), zentralisiert verwaltet