Docstoc

P1 - PowerPoint Presentation

Document Sample
P1 - PowerPoint Presentation Powered By Docstoc
					  Seminar: Self-Management and Reliability (Artur Andrzejak)




 Probleme in großen Systemen
Am Beispiel von drei großen Internet Services




      Vortrag: Martin Herzog am 04.05.2007
         Gliederung (1)
   Self-Management
   Große Systeme (Eigenschaften, Anforderungen)
   Beispiel: Internet Services (3 Fallstudien)
    Architektur:
       Grundaufbau
       Load Balancing
       Front-end
       Back-end
         Gliederung (2)
       Ausfall von Internet Services
       Fehler und Fehlerursachen
       Erkenntnisse


   Google File System
       Ausfallsicherheit


   Quellen
       Self-Management
   Computersysteme steuern sich selbst
    (kein Eingriff durch Menschen)
   Selbst-Konfiguration
   Selbst-Heilung
   Selbst-Optimierung
   Selbst-Schutz
       Große Systeme
   Sehr viele (unterschiedliche) Komponenten
   Schwierige Verwaltung
   Hoher Wartungsaufwand

   Extrem hohe Verfügbarkeit
   Maximale Zuverlässigkeit
   Ausfallsicherheit
   Hohe Performance
   Skalierbarkeit
   Wartbarkeit / Instandhaltbarkeit
          Internet Services
   Anforderungen

   Arten von Diensten
       World Wide Web
       Email
       FTP
       VoIP…
         Internet Services




Angaben in Mio UU und Prozent für einen durchschnittlichen Monat im
Untersuchungzeitraum Juli - September 2006
          Grundaufbau (Verfügbarkeit)

   Cluster bestehend aus sehr vielen billigen PCs
       Nicht ausfallsicher (keine teure Absicherung)
       Häufig:
        Neukonfiguration, Erweiterungen, Funktionsänderungen in
        Software und Hardware
       Sind abhängig von wieder anderen billigen PCs im Netzwerk-
        Cluster


   Müssen ständig verfügbar sein
         Grundaufbau (Verfügbarkeit)
   Vorteile dieser Struktur:
       Viel billige Hardware lässt viel Redundanz zu
       Kontrollierbare Umgebungsbedingungen und
        geographische Verteilung verhindert große Katastrophen
   Wartbarkeit
       Problematisch, da große Menge an PCs nur sehr
        aufwendig verwaltbar. Viele menschliche Eingriffe nötig
       Tools für Konfiguration, Partitionierung und Bewegung
        ständiger Daten, Fehler –Erkennung, Analyse und
        Behebung meist unzureichend und ad hoc.
Architektur
Fallstudien von drei Internet Services

   Online             (Internet Portal)
   Content            (Hosting)
   ReadMostly         (Streaming z.B.)
Schlüsseleigenschaften
        Architektur
Gemeinsamkeiten:
   Werden in verteilten Rechenzentren gehostet
   Bestehen aus weitverbreiteter Hardware aber speziell
    angefertigter Software
   Verwenden mehrere Level der Redundanz und
    Lastenverteilung (Load Balancing)

   Enthalten eine Load-balancing Schicht, eine
    zustandslose front-end Schicht und eine
    zustandsbehaftete back-end Schicht
       Architektur
Unterschiede:

   Verhältnis zwischen Lesen und Schreiben
    Benutzung von normalem web browser oder
    spezieller Software auf der Client-Seite
       Geographische Serververteilung
    Server sind bei Online, Content und ReadMostly
auf unterschiedliche Rechenzentren verteilt.

   Um die Verfügbarkeit zu gewährleisten

   Online und ReadMostly, um Performance zu
    verbessern durch Verteilung der
    Benutzeranfragen
       Geographische Serververteilung

   Ziel: Lastenverteilung auf mehrere Datenzentren

   User-Zugriff auf Seite wird je nach Auslastung und
    Verfügbarkeit ausgewählt (Online und ReadMostly)

   Content: Serverauswahl wird an den Client
    weitergegeben
       Single-site Architektur

   Besteht aus 3 Schichten:

   Load Balancing, Front-end Server, Back-end
    Server
Online
Content
ReadMostly
        Load balancing
   Verteilung von User Anfragen auf Front-end-server, die am
    wenigsten ausgelastet sind

   Content und ReadMostly: Layer 4 Load Balancing bei Front-
    end und Back-end (z.B. Web Cache und Content Portal)

   Online benutzt zusätzliches Verfahren bei
    (zustandsbehafteten) stateful Parts des Services
    (z.B. e-Mail)

   Load Balancing auf mehreren Ebenen gängig
        Front end
   Ausgewählter Front-end Server (Load Balancing) antwortet
    der User-Anfrage.

   Beschafft sich notwendige Daten vom Back-end Server und
    liefert sie dem User zurück. (Online)

   Client kann Daten auch direkt von Back-end Server erhalten
    (Content, ReadMostly)

   Bei Content und ReadMostly haben alle Front-end Server
    Zugriff auf Daten von allen Back-end Servern
         Front end
   Online partitioniert außerdem Front-end Server
    nach Funktionalität
       Front-ends für stateful services    (z.B. E-mail)
       Front-ends für stateless services   (z.B. News)
       Web Proxy Caches

   In allen drei Fällen sind die Front-end Server preiswerte PCs
    oder Workstations
   Alle drei benutzen speziell angefertigte Front-end Software
    (statt serienmäßiger Webserver) für bessere Performance
    und Funktionalität
Knotenaufbau (Front-end)
         Back end
   Back-end Server versorgen Services mit Daten, die
    gebraucht werden um ein Request zu verarbeiten.
   Speichern dauerhafte Daten (Content und ReadMostly: files,
    Online: e-Mail, user preferences)
   Back end ist sehr variabel in seiner Knotenstruktur
   Verwendung von billigen PCs bei Content und ReadMostly
   Spezielle Filesever für hohe Verfügbarkeit bei Online
   Dateisysteme:
       Online:       Write Anywhere File Layout
       Content:      spezifisches Filesystem
       ReadMostly:   Unix Filesystem
        Back end
   Aufteilung von Daten ist Schlüsel für Skalierbarkeit des
    Services, Verfügbarkeit und Wartbarkeit
   Online: 65.000 User pro Service Group, die zu einem
    Network Appliance Filer gehört

   Content: verteilt Daten auf mehrere Back-end Server und
    repliziert jeden Storage-Server in zweiten Rechenzentrum

   ReadMostly: verteilt Daten auf einzelne Knoten (Server) im
    Cluster und repliziert Cluster in verteilten Rechenzentren
    Load Balancing auf allen redundanten Knoten.
        Networking

   Netzwerk des Rechenzentrums ist verbunden mit
    First-Level Switch des Services

   First-Level Switch ist durch Gigabit Ethernet mit mit
    kleineren Second-level Switches verbunden

   Second-level Switches sind dann zu einzelnen
    Knoten durch 100Mbps Ethernet verbunden
       Service Anwendungen
   Ständige Entwicklung, Einsatz und Upgrades von
    neuen Services
   Sehr wenig Zeit für Tests und im Gegenzug
   Anstieg der Frequenz und Größe beim Einsatz neuer
    Services
    Service Anwendungen werden wichtiger
    (Monitoring, Problemdiagnose, Reparatur, Konfigura
    tion, Rekonfiguration, leichte Handhabung für
    Bediener)
         Test und Einsatz
   Tests auf einzelnen Knoten und kleinen Clustern
    ähnlich dem großen Cluster
   Teams zur Qualitätskontrolle
   Vorabversionen für eine kleine Benutzergruppe

   Selbstentwickelte Tools zur effizienten und korrekten
    Übertragung der Software auf das Cluster
   Alte und neue Version auf jedem Server installiert 
    Rückkehr zu alter Version dauert 5 Minuten (Online)
       Täglicher Betrieb
   Softwareänderung und Konfiguration
   Ausbau des Clusters
   Back-end Daten Verteilung
   Probleme suchen
   Hardware einrichten
   Netzwerkprobleme beheben
      Ausfall von Internet Services
   Hohe Hardware und Software Redundanz
   Operation Centers mit viel Personal rund um
    die Uhr zur Bewachung und Behebung von
    Problemen

   Trotzdem: Relativ häufige Ausfälle von
    Internet Services
   WARUM ???
        Komponentenfehler

   Irgendeine Komponente des Services
    handelt nicht so wie erwartet z.B.
       Festplatte, die sich nicht mehr dreht
       Software stürzt ab
       Arbeiter konfiguriert eine Network switch falsch
        Servicefehler

   Komponentenfehler verursacht einen
    Servicefehler, wenn dadurch
       Ein User keinen Zugriff mehr auf den Service
        oder einen Teilservice hat
       Eine für den User spürbare Verschlechterung der
        Performance auftritt
        Auswertung der Daten
   Servicefehler wird dem ersten Komponentenfehler in der
    Fehlerkette zugewiesen, die zum Servicefehler geführt hat

   Charakterisierung nach Ort der Fehlerursache (front end,
    back end, network, unknown) und Typ (Server Hardware,
    Server Software, Netzwerk Hardware, Netzwerk Software,
    Operator, Umgebung, Überlastung, unknown)
        Abschließende Beobachtungen
   Menschliche Fehler sind der häufigste Grund für Fehler bei
    Content und der zweithäufigste bei ReadMostly

   Treten bei Änderungen am System auf (Austausch und
    Erweiterung von Hardware, Konfiguration und Upgrade von
    Software)

   Sehr gute Abdeckung von Hardware –und Softwarefehlern
    durch Redundante Datenspeicherung (Content, ReadMostly)

   Netzwerkprobleme sind erstaunlich häufig Fehlerursache
    bilden oftmals einen „Single Point of Failure“
         Abschließende Beobachtungen
   Enorme Schwierigkeiten durch Zusammenwirken
    mehrerer administrativer Gruppen
       Netzwerk Administratoren
       Software Entwickler
       Mitarbeiter im Rechenzentrum
       Netzwerk Provider
       User selbst


   Tools werden immer nur von entsprechender
    Gruppe eingesetzt, aber es gibt keine Service-Tools
       Google File System

   Einteilung von Daten in Blöcke bestimmter Größe
    (Chunks)
   GFS Cluster besteht aus Masterserver und
    mehreren Chunk-Servern
   Chunks werden auf lokalen Festplatten wie Linux
    Files gespeichert
   Jeder Chunk ist auf unterschiedlichen Chunk -
    Servern mindestens dreimal repliziert.
       Google File System
   Master kontrolliert zugehörige Chunk-Server durch
    Heartbeat Messages

   Einmischung von Master sehr gering. Fast alle
    Operationen auf Chunk-Servern

   Neue Daten werden auf nächstgelegene Chunk-
    Server repliziert
           Quellen
   David Oppenheimer, David A. Patterson: Architecture,
    operation, and dependability of large-scale Internet services:
    three case studies (2002)

   Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung:
    The Google File System

   AGOF e.V. / internet facts 2006-III
    Arbeitsgemeinschaft Online-Forschung e.V

   http://en.wikipedia.org/wiki/Load_balancing_%28computing%29
   http://en.wikipedia.org/wiki/RAID
   http://en.wikipedia.org/wiki/File_System
Vielen Dank für eure Aufmerksamkeit

				
DOCUMENT INFO