APM - Begriffe

Schrittweises Erhöhen der Last, bis System instabil wird oder ganz ausfällt,

Ziel: Verstehen des Systems unter extrem hoher Last Fragen:

• Wie ändert sich Antwortzeit-Verhalten?

• Wie gross ist maximale Last, ohne dass System unzuverlässig wird?

• Zeigt System unerwartetes Verhalten?

• Kommt es zu Dateninkonsistenzen?

 Welche Effekte können auftreten?

• Einzelne Aussetzer

• Totalausfall

• Datenverlust/-Inkonsistenz

• Failover Wie kann man Verhalten analysieren? 

• Visualisieren von Messresultaten

 Spezielle Form von Caching, d.h. Zwischenspeichern von berechneten Resultate

Paper: Automatische Analyse findet Orte in Java-Code, wo Caches sinnvoll sein könnten

Schneller Puffer-Speicher, der wiederholte Zugriffe auf ein langsames Hintergrundmedium oder aufwändige Neuberechnungen zu vermeiden hilft. Bereits geladene/generierte Daten bleiben in Cache, damit sie bei Bedarf schneller abrufbar sind.

Wichtig: Werte in Cache müssen schnell abgelegt und gefunden werden

• ... eine limitierte Grösse hat

• ... Datenobjekte desselben Typs speichert

• ... die Leistung eines Systems optimiert

Buffer: Reduziert Transfers zu Medium durch Zusammenfassung (“Schreib-Cache”), Zwischenspeicher für Komponenten, die nicht direkt kommunizieren können

Cache: Speichert Daten, die in Zukunft wertvoll sein können (“Lese-Cache”)

Lese-Zugriff auf Cache-Speicher

Cache Hit (Cache Miss): Element wurde (nicht) gefunden

Hit Ratio (Miss Ratio): Anteil der Zugriffe, die zu einem Cache Hit (Miss) führten

• Hohe Hit Ratio: Cache ist “hot”, sonst “cold”

Füllstand: Anteil des verwendeten Platz gegenüber Gesamtplatz im Cache

• Hotness und Füllstand grundsätzlich unabhängig!

• Locality by time: wenn ein Objekt verwendet wird, wird es mit grosser Wahrsch. bald wieder verwendet

• Locality by space: ebenso “benachbarte” Objekte

 Entfernt immer das Element, welches in der Zukunft am längsten nicht benötigt wird.

Entfernt Element, das sich am längsten im Cache befindet

• Einfache Heuristik für Locality by time

• Effiziente Implementation mit Ringbuffer: Braucht nur einen Zeiger auf ältestes Element

 Entfernt Element, das am längsten nicht gelesen wurde, Echte Locality by time (was aber selbst auch nur Heuristik ist!) Muss aber für jedes CacheElement Zusatz-Info speichern (was Cache-Grösse reduziert)

Entfernt Element, das als letztes gelesen wurde

• In gewissen Situation gilt temporal locality nicht! (Dafür vielleicht spatial locality)

• Beispiel: Mehrmaliges Iterieren über Datensatz, der knapp nicht in Cache passt

• LRU würde keinen einzigen Cache Hit landen, MRU viele!

Least Frequently Used Entfernt Element, das am wenigsten oft gelesen wurde

Allgemeine Heuristik: Vergangenheit ist aussagekräftig für Zukunft, Braucht Zusatz-Info pro Element, wie LRU und MRU

 Random Replacement: Entfernt ein zufälliges Element • Super-effizient und einfache Implementation ohne jeglichen Zusatz-Speicher

• Wahrscheinlichkeit, dass “wichtigstes” Element entfernt wird ist klein, unabhängig von ZugriffMuster! Wurde wegen Einfachheit in ARM-Prozessoren verwendet Verteilte Caches: Mehrere, durch hohe Latenz getrennte Caches optimieren Zugriff auf das selbe Medium -> CPU-Caches Cache-Koheränz: Ein System von Caches liefert konsistente Daten an alle verarbeitenden Einheiten

• Temporäre Inkonsistenz ok, solange nicht gelesen wird

Daten werden vorerst im Cache gehalten und erst später (...) auf Medium geschrieben

• Inkonsistenz wird mit zusätzlichen Mechanismen behandelt

• Z.B. MESI-Protokoll in Intel CPUs

Monitoring von Performance-Metriken -> Berechnen von Performance- Indikatoren (PI/KPI) -> Vergleich mit Policies (Schwellwerte, u.a.) -> Massnahmen: (De-) Provisionierung

Können einfache Metriken sein

• Speicherverbrauch, CPU-Load, Antwortzeit (In-Server), ... Oder higher-level Indikatoren

• Kombinination mehrerer Metriken oder externe Metrike

• Aggregierung über definierten Zeitraum (Ø, Median, ...)

• Beispiele: EUAntwortzeit, aktive Users, Kosten, ...

 Periodische, automatische Erfassung möglich | Kleine Verzögerungszeit | Kleine Volatilität | Aussagekraft für Massnahmen Verständlichkeit (für Policy-Definitionen)

1. Deployment der Basis-VM/des Containers

2. (Evtl. Patchen von Software und OS)

3. Node-spezifische Konfiguration

4. SoftwareClustering(z.B.ReplizierenvonDaten)

5. Starten aller Services auf der Node

6. Aufnahme der Node in externe Services

7. Testen der Funktionsfähigkeit

8. Integration in den Cluster(z.B.AnpassenvonLB-Konfig)

1. Entfernen der Node aus dem Cluster

2. Entfernen aus externen Services

3. Shutdown der Services auf der Node

4. Entfernen des Software-Clusterings

5. Deprovisionierung der Ressource

Warum? Kosten sparen!

• Energieverbrauch. Wartungsaufwand. Verschleiss?

Ansätze:

Stromsparmodus

• Sleep-Modus

• Herunterfahren

• (Verkaufen?) Schwierigkeit: Was führt wirklich zur grössten Kostenersparnis?

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

 Rechenpower für High-Performance Computing, Applikationen werden explizit parallelisiert

Verteilen von “gleichartigen” Requests, Wie unsere Tomcats

Wenn ein Knoten ausfällt, übernimmt ein anderer (“failover”), Wie unsere Load Balancers

 Festplatten, die direkt an Host angeschlossen sind, Schnittstellen: SCSI, SATA, eSATA, USB, Block-basierte Schnittstelle, Supereinfach, Direkter Zugriff nur von einem Host möglich, Zugriff von anderen Hosts: Protokolle wie FTP, Netzwerk-Dateisysteme wie NFS oder SMB

Dedizierter File-Server in LAN, Zugriff von allen anderen Hosts möglich, Zugriff normalerweise über NFS oder SMB (d.h. über TCP/IP), Einfache Lösung, aber: Limitierte Bandbreite, belastet LAN

 Dediziertes Netzwerk für Speicher, Extra-Features: Automatisches Backup, Monitoring, Spezielle Protokolle: Fibre Channel, iSCSI, Infiniband, Darunter: Kupfer oder Glasfaser, für bis 10km-Leitungen, Höhere Bandbreite: z.Z. 50Gbit/s pro Link, mit 4x, 8x, 12x..., Zugriff ist block-basiert! (Wie bei direct-attached storage) D.h. Dateisystem wird von Host implementiert, Braucht spezielles “shared disk file system”, Zugreifende Hosts müssen Zugriff koordinieren! Nodes müssen genau wissen, welche anderen Nodes “alive” sind und ebenfalls auf Speicher zugreifen.

 SAN: Block-basierter Zugriff!, Auch ohne SAN ein Problem: Datenkonsistenz, “Split Brain”, Links zwischen zwei Knoten sind down, aber Anbindung an öffentliches Netz und an Speicher steht noch, Jeder Knoten meint, er sei der einzige und koordiniert nicht mehr!

Entwickler: Algorithmen, Ressourcenverbrauch, Administratoren: Skalierbarkeit, Auftraggeber: Hohe Zuverlässigkeit und Verfügbarkeit, Endbenutzer: Flüssige Bedienung, kurze Wartezeit Welche Metriken? Subjektivität mit objektiven Metriken entschärfen • Ressourcenverbrauch • Durchsatz (throughput) • Verfügbarkeit • Endbenutzer-Antwortzeit (response time) - Achtung: Jeweils nicht eine Zahl, sondern Verteilung, oder möglicherweise variabel im Verlauf der Zeit

 Auf System-Ebene: • CPU-Auslastung (in %) • CPU load (run queue length) siehe “load average” von top oder ähnlichen Tools • Speicherverbrauch: Virt. vs realer Speicher (Swap!) • Input/Output Speichermedien, Netzwerk Auf | Applikations-Ebene: • Thread-Pools • Datenbank-Verbindungen (JDBC connection pool) • Caches Optim. Grösse, Invalidierung • Messaging-Queues Synchron und asynchron, z.B. RMI und JMS

Definition: Anzahl durchgeführte Operationen/verarbeitete Requests pro Zeit (Einheit z.B. s–1)

 Wie lange muss eine Applikation während eines bestimmten Zeitintervalls zur Verfügung stehen? • Z.B. innerhalb eines Jahres während 99.9% der Zeit, Wird in Service Level Agreement (SLA) festgehalten, Zusätzliche Bedingungen können bestimmt werden: • Welcher Durchsatz muss während der Zeit garantiert sein? • Wie hoch darf die E.U.-Antwortzeit sein?

Zielsetzung, Umfang, konkrete Ziele, evtl. Einschränkungen, Budget

Test Items: Auflistung der Komponenten, die getestet werden

Features to be tested: Auflistung aller Eigenschaften und Funktionalität, die getestet werden, inkl. Referenzen zu Spezifikationen o.ä.

Approach: Wie werden die Features getestet? Detailierte Informationen über Test-Szenarios, Testfälle, Testdaten, Techniken, Prioritäten

Environmental needs: Voraussetzungen an Testumgebung, z.B. Hardware, Software, andere Voraussetzungen.

Für Performance-Tests zwei Seiten: Zu testende Infrastruktur und Testing-Seite