4.3 Betrieb

Inbetriebnahme

• die Art der Inbetriebnahme (service rollout) ist ähnlich bedeutend wie die Planungs-/Implementationsphase
• Ziel: erster Eindruck muss positiv sein
  Kunden, die man am Anfang verliert, sind später nur schwer wieder zu gewinnen
• Prinzip one, some, many

  one: beginnen mit einem "Probanden" (Maschine, Kunde - oft Entwickler selbst), Verfahren ggf. solange verbessern bis es funktioniert

  some: weitere SysAdmins, ggf. erste Kunden einbeziehen, feedback verarbeiten

  many: alle Kunden einbeziehen, feedback verarbeiten
  

  Kunden müssen Inbetriebnahme-Prozess unterbrechen können

• Dokumentation muss vollständig sein
• Help-Desk muss mit neuem Dienst vertraut sein
• Beratung und Unterstützung muss gewährleistet sein
• Mechanismen zum Installieren/Konfigurieren von Client-Software
  Idealfall: keine spezielle Client-Software erforderlich: Web-Browser benutzen

Aufstellung/Umgebungsbedingungen

• Kundenanspruch: Verfügbarkeit
• sämtliche Hardware für einen Dienst im Serverraum (data center) aufstellen
  Infrastruktur des Serverraums: UPS, leistungsstarke Netzanbindung, Klimatisierung, etc.
• Server-Maschinen mit hoher Netz-Bandbreite, ggf. mehrere (dedizierte) Netzanschlüsse vorsehen
• Service-Komponenten dürfen nur von Server-Systemen abhängig sein
• Serverraum nicht missbrauchen: "Labor", Installationen von Arbeitsplatz-Maschinen, ...

Zugang

• Restriktionen erhöhen Stabilität
• Kunden sollten sich nie an Server-Maschinen anmelden müssen/können
• SysAdmins melden sich nur für administrative Arbeiten an
• Techniken

  • Pluggable Authentication Modules (PAM)
  • Graphical Identification and Authentication Interface (GINA)

• Kundensicht: ein zuverlässiges System funktioniert erwartungsgemäß, wenn man es benutzen will
• SysAdmin-Sicht: ein zuverlässiges System umfaßt in angemessenem Umfang Mechanismen der

  • Redundanz (redundancy)
  • Wiederholbarkeit (repeatability)
  • Reparierbarkeit (repairability)

  so dass die Dienste des Systems gemessen an ihrer Bedeutung korrekt funktionieren
• einfachstes, effektivstes Verfahren: KISS-Prinzip

Redundanz

• Ziel: single point of failure (SPOF) vermeiden
• durch mehrfaches Vorhandensein von Komponenten Ausfall/Fehlverhalten einzelner Komponenten tolerieren
• hardwarebezogene Redundanz

  • RAID-Systeme, ECC-RAM, redundante Netzteile, ...
  • redundante Komponenten effektiv einsetzen

    • redundante Netzteile eines Gerätes: verschiedene Stromquellen (USV)
    • redundante Maschinen: verschiedene Stromquellen, verschiedene Switches
    • Geräte zur Sicherung der Fehlertoleranz müssen selbst fehlertolerant und servicefreundlich sein

      • USV - Batteriewechsel während des Betriebs
      • RAID - Austausch von Komponenten während des Betriebs (Platten, Netzteile, ...)

    • ggf. an verschiedenen Orten aufstellen

  • Komponenten eines Dienstes eng aneinander binden

    • alle Geräte einer Maschine: eine Stromquelle
    • alle Maschinen, die gemeinsam einen Dienst erbringen: eine Stromquelle

• softwarebezogene Redundanz: Replikation (replication)

  • vollständige, redundante Kopie
  • Master-Slave- oder Peer-to-Peer-Prinzip
  • (halb-)automatisch/zeitabhängig gepflegt:

    • NIS/NIS+ - Slave Server
    • Windows NT - Backup Domain Controller
    • BIND - Secondary Name Server
    • OpenLDAP - Standalone LDAP Update Replication Daemon
    • Kerberos 5 - Database propagation (kprop/hprop)
    • Active Directory Replication (W2K)

  • automatisch/zeitnah/transaktionsorientiert gepflegt:

    • Heimdal Kerberos 5 - incremental propagation (iprop)
    • AFS - Ubik: Replicating AFS Administrative Databases (einschließlich automatischer Master-Wahl)

  • Bewertungsmaßstab

    • serverseitig: Wie wird Ausfall einzelner Server (Slave/Master) verkraftet? Wie erfolgt die Re-Synchronisation?
    • clientseitig: Wie erfolgt das Umschalten auf einen anderen Server?

Wiederholbarkeit

• Installation, Konfiguration und Pflege eines Systems muss zuverlässig und konsistent wiederholbar (reproduzierbar) sein
• Techniken: vollständige Automatisierung

Reparierbarkeit

• schnelles und effizientes Identifizieren, Reparieren bzw. Austauschen fehlerhafter Komponenten oder Systeme

Performance

• "veränderliches" Ziel: geprägt von Erwartungen und Erfahrungen
• neue Dienste: werden Performance-Erwartungen nicht erfüllt, wird der Dienst nicht genutzt
• Voraussetzung: fundiertes Wissen: Wie funktioniert der Dienst?
• Kapazitätsplanung entsprechend Anforderungen der ausgewählten Software

  • I/O-intensiv? Platte/Filesystem?
  • Lese-/Schreibzugriffe?
  • Netzbandbreite/Latenzzeit?
  • durchschnittliche Datenmenge während einer I/O-Operation
  • Anzahl von I/O-Operationen pro Zeiteinheit
  • RAM-Bedarf?
  • Rechenleistung?

• Messungen/Maßstäße

  • frei wählbar, dem Dienst angemessen
  • Netzwerk, I/O-Leistung: MB/s
  • Datenbanken: TPS (Transaktionen pro Sekunde)
  • Webhits pro Minute
  • Anzahl der beantworteten Nutzeranfragen, durchschnittliche Dauer
  • Einige Standard-Benchmarks (SPEC)

• Grundregeln

  • Systeme nicht überlasten, Reserven vorsehen
  • Erfahrungen auswerten, Logs sammeln

• Einflußfaktoren

  • RAM
    

    • ausreichend RAM beschleunigt I/O-Vorgänge und vermeidet swapping/paging

  • Benutzungsart

    • fehlerhafte Nutzung durch Kunden
      zuviele Jobs, falsche Programmierung, ...
    • fehlerhafte Konfiguration
      unnötige Serverprozesse, ...

  • Load Balancing

    • bestimmte Dienste lassen sich gut auf mehrere Maschinen verteilen (WWW, FTP, ...)
    • Einsatz spezieller Load Balancing Techniken (Level 4 switching)

  • Disk/Filesystem-I/O
    

    • Einsatz von

      • RAID-Systemen mit geeignetem RAID-Level
      • dedizierten Storage-Systemen (SAN-Techniken)

  • Netzbandbreite
    

    • Einsatz von breitbandigen Technologien
    • evtl. mehrere Netzanschlüsse, geeignetes Routing

  • andere Dienste

    • Abhängigkeiten von Dritten
    • Kommunikationsprobleme
    • Firewall/Paketfiler-Konfigurationen

  • Kern-Konfiguration

    • Einstellen bestimmter Kernel-Parameter (Tabellengrößen, Konstanten, nicht benötigte Treiber entfernen, ...)
    • Empfehlungen von Applikationsherstellern berücksichtigen

    Der Einfluß von Kernel-Parametern wird im allgemeinen überschätzt. In den meisten Fällen wird durch Eingriffe die Situation eher verschlechtert.

• Erfahrung: für viele Dienste ist CPU-Leistung ein untergeordnetes Problem

Monitoring

• Monitoring ist unabdingbar
• Erreichbarkeit, Funktionstüchtigkeit, Performance
• automatisches Alarmieren, Einbeziehung Help-Desk
• vorausschauend Probleme feststellen

  • Ausfall redundanter Komponenten
  • Kapazitätsprobleme, Ressourcenplanung
  Netzwerkbandbreite, Storage-Kapazitäten (Wachstumsraten), Lizenzen, ...

Frage 4.3.1: Welche RAID-Verfahren gibt es und für welche Einsatzzwecke sind diese jeweils geeignet?

Frage 4.3.2: Welche Replikationstechniken kennen Sie? Wie funktionieren diese und welche Schwachstellen haben sie?

Diskussion 4.3.3: Warum werden im URZ weder NIS/NIS+ noch LDAP oder ähnliche Verfahren zur Verwaltung der Account-Informationen eingesetzt?

Sellens, J.:
System and Network Administration for Higher Reliability
Usenix Assoc., 2001, ISBN 1-880446-08-1
http://sageweb.sage.org/resources/publications/7_reliability/

Forrester, J.E.; Miller, B.P.:
An Empirical Study of the Robustness of Windows NT Applications Using Random Testing
in Proceedings of th 4th USENIX Windows Systems Symposium, Usenix Assoc., 2000, ISBN 1-880446-20-0
http://www.usenix.org/publications/library/proceedings/usenix-win2000/forrester.html

Miller, B.P.; Fredriksen, L.; So, B.:
An Empirical Study of the Reliability of UNIX Utilities
in Communications of the ACM, 33(12):33-44, December 1990
ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf

Miller, B.P.;Koski, D.;Pheow Lee, C.;Maganty, V.;Murthy, R.;Natarajan, A.;Steidl, J.:
Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services
ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz-revisited.pdf

Patterson, D.A.; Gibson, G.; Katz, R.H.:
A Case for Redundant Arrays of Inexpensive Disks (RAID)
http://www.cs.cmu.edu/~garth/RAIDpaper/Patterson88.pdf

Active Directory: An Overview
[http://www.windowsitlibrary.com/Content/155/07/toc.html]

Replicating the AFS Administrative Databases
[http://www.openafs.org/pages/doc/AdminGuide/auagd008.htm#IDX6061]

Nemeth, E.; Snyder, G.; Seebass, S.; Hein, T.R.:
Unix System Administration Handbook, Third Edition, pp. 754-768
Prentice-Hall, 2001, ISBN 0-13-020601-6

Bourke, T.:
Server Load Balancing
O'Reilly, 2001, ISBN 0-59-600050-2

Kopparapu, C.:
Load Balancing Servers, Firewalls, and Caches
John Wiley & Sons, 2002, ISBN 0-471-41550-2

Standard Performance Evaluation Corporation
[http://www.spec.org/]