Von 10^3 nach 10^7: Wachstumsschmerzen mit Linux

isotopp image Kristian Köhntopp -
June 23, 2004
a featured image

Warum Wachstum weh tut

  • “Systemadministration”
    • Eine Aufgabe, die in sehr unterschiedlichen Größenordnungen kommt
    • Ein mögliches Maß: Anzahl der betroffenen Benutzer
      • 10^1 - für sich selbst und seinen Partner oder für eine WG
      • 10^3 - für einen kleinen Verein (“Toppoint e.V”, “INKA”)
      • 10^5 - für ein kleines Internet Unternehmen
      • 10^7 - für ein großes Internet Unternehmen
    • Die Aufgabe verändert sich nicht, aber die möglichen Lösungen und die daran hängenden Strukturen

  • Wachstum ist eine Folge von Erfolg
    • Ich muß mit meinem Erfolg wachsen. Ich kann nicht planen.
  • Beispiele:
    • Stark schwankende Dienstenutzung (“Grußkarten”)
    • Strukturveränderung in Diensten (“POP3 vs. IMAP”, “SSL”)
    • Dienste mit unbekannter Akzeptanz (“Videomail”)
    • Dienstwachstum erfordert strukturelle Veränderung (“Freemail”)

Limits

Limits in Hardware und Software

  • Hardwaregrenzen
    • Intel-Hardware: 4 CPU, x GB RAM, 60 MB/sec Random I/O
  • Softwaregrenzen
    • Die verwendete Datenbank fällt bei bestimmten Daten- und Lastgrößenordnungen schlicht auseinander oder degradiert über die Zeit.
  • Hotspots
    • Ein stark belasteter Block bremst die Gesamtperformance eines RAID-Systems

Reaktionen auf Wachstum

  • Wachstum erfolgt aus dem Betrieb
    • “Jetzt wachsen” => “mehr Kisten”
  • Kurzfristige und längerfristige Lösungen gleichzeitig verfolgen
    • Das ist nicht immer schön
  • Lastverteilung:
    • DNS RR
    • Loadbalancer Appliance
    • Linux Virtual Server
    • Applikation verteilt (login, hashes)
  • Schreibrate beeinflußt die Architektur
    • Livebetrieb auf Snapshots und Kopien
    • Zentrale Datenhaltung bildet Flaschenhälse
    • Anwendungen verteilbar realisieren

Erfahrungen

  • Hardware ist billiger als Software

  • Software ist billiger als Leute

  • Hardware ist schneller als Software

  • Software ist schneller als Leute

  • Der Preis ist nie das Problem.

  • Lösbarkeit in Zeit ist das Problem

Zentrale und dezentrale Systeme

  • Historisches Wechselspiel
    • Hosts
    • PCs
      • Zentraler Storage, zentrales drucken
    • Workstation Cluster
      • Zentrale Administration
    • Webanwendungen
      • Zentrale Anwendungsinstallation, zentrale Datenhaltung
      • Webanwendungen können im RZ verteilt werden -> Cluster
      • Webanwendungen können dezentral ablaufen -> Applets, Thin Clients
  • Einflußfaktoren:
    • Netzbandbreite und Latenz vs. zentrale Rechenleistung

  • Dezentralisierung funktioniert.
  • Limits in der verfügbaren Hard- und Software erzwingen dezentrale Systeme
    • Zentrale Systeme haben immer ein wachstumsbegrenzendes Limit.
  • Verteilung:
    • Zustand bremst. Zustandslos verteilen!
    • Writes bremsen. Dezentral schreiben!
    • Synchronisation bremst. Asynchrone Strukturen bauen!

“Berg der Verzweiflung”

Architektur

  • Freemail:
    • Plugin im Webserver (eine Art PHP/FI)
      • Alle Funktionen des Dienstes in einer Schicht als Teil des Webservers
    • Differenzierung
      • Funktionstrennung
    • Multi-Tier Architektur für zwei Dutzend Teildienste
  • Folgen:
    • Abhängigkeiten-Netze
    • Debug-Komplexität
    • Update-Komplexität

Un-Architektur

  • Architektur vs. Betriebliche Erfordernisse
    • Manche Probleme löst man nur durch brachiale Gewalt
    • Das Resultat ist niemals ästhetisch.
      • Aber es macht die Kasse voll. :)
  • Problem: Dokumente liefern
    • Informatiker-Lösung:
      • Dokumentenserver in Corba-Dienst verpacken
      • Details wegabstrahieren
    • Folge:
      • Performance… läßt Wünsche offen
    • Lösung:
      • NFS, Datenbank liefert Dateinamen
      • Laufender Dialog mit der F&E

Denormalisierung

  • Problem:
    • Speicherung von Mail-Headerinformationen in Datenbanken
  • Informatiker-Lösung:
    • 3NF Datenspeicher
  • Folge:
    • Datenbank explodiert
  • Lösung:
    • Messen. Hotspots identifizieren. Denormalisierung.
    • Daraus folgend: Fehler → Fehlerbehandlung

Der ganz normale Wahnsinn

  • Problem:
    • “Ab morgen machen wir SSL”
  • Folgen?
    • Architektur (mod_gzip + mod_ssl?)
    • Infrastruktur
      • CPU?
      • CPU-Verteilung aka Balancing?
      • Rackspace?
    • Logistik
      • Installation?
      • Rollout?

Katalog vs. Reality

  • Hersteller nehmen den Mund gerne voll.
    • “4400 RSA-Operations pro Sekunde”
      • Resultat: Montag Mittag, 0% Idle, Totalstillstand
    • “SAN Storage Lösungen”, “sie sind eher einer unserer kleineren Kunden”
      • Resultat: Systemstillstand beim Erstellen von Snapshots, “mit so vielen kleinen Dateien haben wir nicht gerechnet”
    • “x tausend Firewall-Connections pro Sekunde”
    • Reiserfs, XFS

Erfahrungen

  • Normalisierung gut!

  • Denormalisierung besser!

  • Architektur gut!

  • Einfache Konzepte besser!

  • Trau keinem Katalog!

  • Alle Hersteller versagen in der Praxis.

  • “XP”: Architektur als Prozeß:

  • Tu’ nur was notwendig ist. Behalte die Vision im Hinterkopf.

    • Kritik: Was ist mit Projektkriterien?
    • Mache kurze, überschaubare Projekte (<3 Monate)
    • Sei bereit, Dinge wegzuwerfen.
  • Projekt <-> Prozeß

Serviceprozesse

Prozesse nach Außen

  • Testballon -> virtueller SLA
    • Auch wenn es kostenlos ist erwartet der Kunde, daß es funktioniert.
    • Ausbildung von Supportstrukturen
    • Steigerung der Abhängigkeiten -> Steigerung der Erwartungen
  • “Der User ist produktiv.”

Prozesse nach Innen

  • Differenzierung
    • Allroundqualifikation -> Spezialistenbildung
    • Kommunikationsbedarf
    • Dinge explizit machen
      • Dokumentation
      • Prozesse
      • Verantwortungen

Prozesstrennungen

  • ITIL (“The IT Infrastructure Library”)
    • ITIL Phasen in der F&E (“Funktionalität”)
    • ITIL Phasen in der IT (“Verfügbarkeit, Wachstum und Qualität”)
  • Was F&E macht, ist allgemein bekannt.
  • Was IT macht, können die meisten Leute nicht benennen.
    • Abgrenzung gegen F&E
    • Abgrenzung gegen Support
  • Trennung von IT und F&E wird oft nicht durchdacht.

Ausblick

  • Spannungsfelder
    • Zentral <-> Dezentral
    • Projekt <-> Prozeß
    • “Jetzt” <-> “Richtig”, “Ordentlich”
    • “F&E” <-> “IT” <-> “Support”
Share