Originale RAID level: Übersicht

Transkript

1 Originale RAID level: Übersicht RAID level 0: Verteilung der Datenblöcke über mehrere Festplatten (striping), keine Redundanz RAID level 1: Spiegeln der gesamten Platte auf eine Zweite (Gegenteil von RAID 0) RAID level 2 bis 4: striping mit fehlerkorrigierendem Hamming-Code (parity bits auf separater Platte) RAID level 5: striping, jedoch auch der parity-informationen 42

2 RAID level 0: non-redundant striping keine Datenredundanz, daher eigentlich kein RAID disk striping = folds multiple disk address spaces into a single unified space seen by the host Verteilung der Daten streifenweise auf alle Laufwerke Beispiel für N=2: 43

3 Striping-Varianten fine-grain striping (feine Verteilung): Streifen (strip): 1 Byte bis zu 1 Sektor bei N Platten enthält jede Platte 1/N alle Datenblöcke Vorteile: Datentransferrate erhöht sich um Faktor N (paralleles Lesen und Schreiben) Last auf den Platten ist gleichverteilt Nachteil: ein einziger Plattenfehler ist katastrophal MTTF reduziert sich um Faktor 1/N coarse-grain striping (grobe Verteilung): Datenblöcke werden im Round-Robin-Verfahren vergeben für grosse Dateien: Transferrate erhöhen (durch paralleles Lesen/Schreiben unterschiedlicher Teile derselben Datei) automatische Lastverteilung für kleine Dateien: paralleles Lesen/Schreiben mehrerer kleiner Dateien einziger Plattenfehler betrifft nur noch viele Dateien hoher manueller Aufwand bei Wiederherstellung 44

4 RAID level 1: Mirrored Disks Einzelne Platte wird jeweils gespiegelt Beispiel: eine Systemplatte plus ein Spiegel Schreiben: immer auf beide Platten Lesen: von der schnellsten Platte Allgemein: D-fache Spiegelung D-facher Aufwand beim Schreiben D-schnellste Antwortzeit nutzen D-1 Festplattenausfälle können toleriert werden 45

5 RAID level 2: striping mit Hamming Code striping wie RAID 0, aber mit strip size von einem 1 Bit...we can mimic the DRAM solution by bit-interleaving the data across disks of a group and then add enough check disks to detect and correct a single error. (Patterson et al., p. 112) Parity-Information auf separaten Platten 46

6 RAID 2: Bemerkungen besser als RAID 1: bei Verwendung des Hamming Codes für d Datenplatten benötigt man nur log 2 d + 1 parity-platten Beispiele: 4 Arbeitsplatten, 3 parity-platten 10 Arbeitsplatten, 4 parity-platten Problem: bei bitweisem striping sind parallele Zugriffe so gut wie unmöglich Hamming Code verschwendet Redundanz, um die fehlerhafte Platte herauszubekommen Idee: Vergrößerung des strip size und einfachere Fehlererkennung 47

7 RAID level 3: singe check disk benutzen den Disk-Controller, um fehlerhafte Platte herauszubekommen striping mit mehr Bits even oder odd parity auf einer einzigen separaten parity- Platte Beispiel: drei Platten, eine parity-platte, even parity: 48

8 RAID level 3: Bemerkungen Schreibzugriff: Daten schreiben, parity berechnen, parity schreiben Lesezugriff: Daten lesen, Controller abfragen alle Platten okay? Ja: fertig Nein: lese parity-platte, um Fehler zu korrigieren Vorteile: nur noch eine parity-platte Performance-Gewinn durch größere strips 49

9 RAID level 4: independent read/write wie RAID 3, strip size ist gleich einem Block Vorteile des coarse grain striping: paralleles Lesen/Schreiben grosser Dateien paralleles Lesen/Schreiben mehrerer kleiner Dateien Nachteil: parity-platte wird zum Flaschenhals Idee: parity verteilen 50

10 RAID level 5: no single check disk parity-informationen sind nun auch verteilt guter Kompromiss aus Redundanz und Performanz viele Implementierungen in der Praxis... RAID 2 bis 4 führen nur zu RAID 5 hin, waren nie ernst gemeinte Alternativen 51

11 weitere RAID level Im Artikel von Chen et al. wird ein weiteres RAID level 6 vorgeschlagen: wie RAID 5 (verteilte parity-informationen) Verwendung von Reed-Salomon parity codes und einer zusätzliche Platte kann den Ausfall von bis zu zwei Festplatten tolerieren einige Kombinationen von RAID levels möglich: RAID level 10 = level 1 + level 0 striping (für Performanz) und mirroring (für Ausfallsicherheit) RAID level 50 = level 5 + level 0 (?) RAID level 51 = level 5 + level 1 Verwirrende Vielfalt an Begriffen...also jeweils Vorsicht RAID level 0-5 sind minimaler Konsens 52

12 RAID in der Praxis RAID level 2 bis 4 sind nicht in freier Wildbahn anzutreffen RAID kann in Software (Betriebssystem) oder Hardware (Controller) implementiert werden Software RAID: Windows 2000 und XP unterstützen RAID level 0 und 1 siehe: RAID Without Additional Hardware: Do it Yourself with Windows Aus Tom's Hardware Guide, online: Linux (ab Kernel 2.4) unterstützt RAID levels 0, 1, 4 und 5 zusätzlich: linear mode, zusammenfügen mehrerer Platten zu einer einzigen großen Platte siehe: The Software-RAID HOWTO von Jakob Østergaard und Emilio Bueso (letzte Version 1.1 vom Juni 2004) 53

13 Messungen RAID 0: Transferraten Windows 2000 aus Tom's Hardware Guide (siehe vorherige Folie) IBM DTLA Platte channel = IDE channel 4x RAID 0 fast 4mal besser als einfache Platte Motto von RAID 0: increased performance at no costs 54

14 Messungen RAID 0: Transferraten normale Transfer Rate (oben) mit 4 Platten, 3 IDE-Kanälen und RAID 0 (unten, Skala beachten) 55

15 Hardware RAID RAID-Controller teilweise schon auf Mainboards vorhanden, dann aber oft nur RAID 0, 1 oder 10 dezidierte SCSI-basierte Disk-Controller für RAID 0, 1, 5 Adaptec 2200S U320 RAID (SCSI) RAID level 0, 1, 10, 5, 50 ca. 650 EUR Promise FastTrak SX4000 (IDE) RAID level 0, 1, 10, 5 bis zu 4 Platten anschliessbar ca. 200 EUR 56

16 Mittelgroße Systeme Promise UltraTrak SX4000: RAID level 0, 1, 3, 5, 10, 30, 50 maximal 4 Festplatten IDE kann RAID level on-the-fly ändern hot-swap fähig Datendurchsatz 80 MB/s ca EUR 57

17 Große Systeme Symmetrix-Systeme (Fujitsu-Siemens bzw. EMC) höchste RAB EDAP-Stufe DTDS+ (Disaster-tolerant Disk System) maximal 84 TB Kapazität GB Cache Laufwerke mehrere Schränke auch über s Netz zusammenschaltbar 58

18 Zusammenfassung und Ausblick RAID-Systeme schützen gegen Festplattenausfälle, halten dabei Daten verfügbar verschiedene RAID level wesentlich: level 0, 1, 5 RAID ist der de-facto-standard für Speicherlösungen bei Servern sowohl in Software als auch in Hardware implementierbar hochverfügbare Festplatte! Wie macht man die Berechnung hochverfügbar? Transparentes Backup, heisse/kalte Reserve basiert oft auf RAID als Speicherlösung 59

19 Übersicht Backups RAID Anforderungen von Hochverfügbarkeit Aktive Redundanz (Space Shuttle PASS) HP Himalaya/NonStop Server IP-Failover 60

20 Anforderungen Beginn der Betrachtungen: Fehlerannahme Typisch: Ein-Fehler-Annahme Aus einer Menge von Komponenten fällt nur eine gleichzeitig aus Gefordert: Mindestverfügbarkeit "five nines" (99,999% uptime per year) bei zeitlich begrenzten Missionen: Versagenswahrscheinlichkeit pro Missionsstunde Beispiel: zivile Luftfahrt 10-9 h -1 Verfügbarkeit prinzipiell ausrechenbar aus MTTF, MTTR Konkrete Werte für MTTF, MTTR schwer zu schätzen Hilfskonstrukt: Vergleich der Fehlerannahmen Ein System, was eine Zwei-Fehler-Annahme toleriert, ist besser als ein System für die Ein-Fehler-Annahme Berechnung/Vergleich der coverage 61

21 Prinzipien Gebräuchlichstes Prinzip: Doppel-Redundanz: primary/backup Fehlererkennung Einspringen des "hot standby" bei einem Fehler In der Regel: Selbstabschaltung der als fehlerhaft erkannten Komponente 62

23 Space Shuttle Entwicklung 1972 bis 1981 Space Shuttle war damals das computer-intensivste Flugzeug/Raumschiff, was je geplant bzw. gebaut wurde Volle digitale fly-by-wire-steuerung (d.h. keine mechanische Verbindungen mehr zwischen Steuerknüppel und Hydraulik) Regelung und Überwachung der lebenserhaltenden Systeme an Bord Anpassung an wechselnde Nutzlasten Wie bei Apollo und Gemini: Computergestützte Steuerung und Navigation. Avionik = aviation + Elektronik Computer überwachen alle Phasen der Mission: besonders kritisch: Start, Wiedereintritt, Landung Landung ohne Antrieb: nur ein Versuch! 64

24 Beispiel: Shuttle ALT (1977) Approach and Landing Tests Test der Machbarkeit der antriebslosen Landung Erster bemannter Test der Avionik Transport auf einer modifizierten 747 Absprengung und Abkoppeln in der Luft Landung mittels Computersteuerung Spektakuläres Ereignis Schaulustige an der Edwards AFB Sammlung wertvoller Messdaten für Simulationsmodelle Separation Landing 65

25 Anforderungen beim Shuttle Im Gegensatz zu Apollo und Gemini gibt es keine nichtdigitalen Backup-Vorkehrungen Insbesondere die Avionik ist mission-critical, muss ein hohes Maß an Zuverlässigkeit aufweisen. Shuttle ist inhärent instabiles Flugzeug, kann ohne Computer- Unterstützung gar nicht geflogen werden. Erreichen der Zuverlässigkeit durch Redundanz (bis zu vierfacher Redundanz von Komponenten) statt durch Achten auf Qualität. Auch im Gegensatz zu Apollo und Gemini: kein eigens entworfener Rechner sondern off-the-shelf-system. 66

26 Fail-Operational/Fail-Safe Neue Anforderungen: Fehler in der digitalen Avionik sollen die Fähigkeit nicht beeinträchtigen, eine Mission erfolgreich zu Ende zu führen. Im Lunar Module gab es auch zwei Computer: der Zweite (AGS) erlaubte aber nur einen "sicheren Abbruch", hatte nicht die volle Funktionalität des Ersten. Beim Shuttle müssen die Computer identisch aber unabhängig sein, jeder kann für den anderen Einspringen. Ansatz: ein Fehler soll die Mission nicht beeinträchtigen, ein zweiter Fehler soll noch eine sichere Landung erlauben Prinzip des fail-operational/fail-safe 67

27 Voting Wie stellt man Fehler fest? Selbstdiagnose vs. voting Voting verwendet mehrere identische Komponenten, die parallel identische Berechnungen ausführen. Voting industriell erprobt (TMR) Die Komponente mit "falschem" Wert wird von der weiteren Berechnung ausgeschlossen Zweifache Redundanz erlaubt nur Fehlererkennung, Fehlerkorrektur erst bei mindestens dreifacher Redundanz möglich Fail-operational/fail-safe verlangt nach mindestens vierfacher Redundanz Ein Fehler hinterlässt dreifache Redundanz Zweiter Fehler lässt sich bei verbleibender zweifacher Redundanz nicht isolieren Verwendung des Backup Flight System (fünfter Computer in hot standby) Unterschied zum SSME-Controller: es gibt keinen "sicheren'' Zustand, in den man herunterfahren könnte 68

28 Lehren aus Apollo Man wollte mehr in Software machen als bei Apollo Spezial-Hardware verursachte grosse Kosten und Verzögerungen im Zeitplan Möglichst off-the-shelf Bei mehrfacher Redundanz: statt eigener Verkabelung, neu aufkommende Bus- Technologien verwenden Schätzungen besagen, dass die Verwendung von Bussen das Shuttle um mehr als eine Tonne leichter gemacht hat Gesamtgewicht des Orbiters: ca. 100 T 69

29 Hardware Wahl fällt auf den IBM AP-101 in computergesteuerter Avionik bereits erprobt speziell gehärtete Version für die Raumfahrt 32-Bit Register 16-Bit Adressregister (schnell zu klein) Neben CPU noch speziellen IOP (Input/Output Processor) Regelt Zugriff auf redundante Busse Kann Daten vom Bus temporär puffern Hat eigene Software Hauptspeicher: Register/CPU auf Basis von ICs restlicher Hauptspeicher auf Basis von Magnetkernen 16 Bit Datenworte, 1 Bit parity, 1 Lese/Schreib-Bit Zusätzlich Bandlaufwerke, zum "einswappen" von Programmmodulen 70

30 Betriebssystem priority-interrupt-driven (IBM) Flight Computer Operating System (FCOS) vollständig in Assembler geschrieben Multitasking (time sharing) Echtzeitbetriebssystem basierend auf Prioritäten Dennoch Zyklen: Minor Cycle (etwa 40 Millisekunden): für Steuerung Major Cycle (etwa 960 Millisekunden): z.b. für Navigation Steuerungssoftware in Hochsprache geschrieben Spezielsprache HAL/S Schätzungen: nur 10% Effizienzverlust gegenüber Codierung in Assembler komplexe Anforderungen (die sich dauern änderten) trotzdem "nur" Verzehnfachung der Kosten für die Software (200 Millionen statt 20 Millionen USD) 71

31 Bus-Architektur IOPs sind über ein Netz von 24 redundanten Bussen verbunden 8 sind flight critical 5 sind für intercomputer communication In jedem IOP sitzen 24 Bus-Controller Bus Control Element (BCE) können auf Speicher der CPUs zugreifen Master Sequence Controller (innerhalb jedes IOP) regelt den globalen IO-Datenfluss zwischen den BCEs 72

32 Bus-Architektur 73

33 Details Busse sind seriell mit Datenrate von 1 Mhz Konvertierung von internem parallelen 18 bit-bus in IOP/CPU auf seriellen Bus mittels Multiplexer Jeder Bus ist einem Computer (bus host) zugeteilt (Zuteilung kann wechseln) Nur host kann auf den Bus senden, alle anderen hören zu Alle Computer sehen alles Typische Zuteilung von Bussen pro CPU 2 flight-critical, 1 intercomputer, 1 display, etc. 74

34 Synchronisation Computer sollen zur selben Zeit das gleiche Berechnen (voting) Es muss sichergestellt sein, dass alle ungefähr dieselben Operationen durchführen schwer bei Befehlen pro Sekunde (AP-101) Problem: Interrupts können zu leicht unterschiedlichen Zeitpunkten kommen Beispiel: Rechner A wird vor einer Zuweisung unterbrochen, Rechner B danach Resultate stimmen nicht mehr überein 75

35 Redundant Set Synchronization Synchronisationspunkte jeweils bei Input, Output oder Verzweigungen Bei jedem Synchronisationspunkt: Senden eines 3 bit-signals auf dem Intercomputer Communication Bus Warte maximal 4 Millisekunden auf ähnliche Signale auf den anderen Bussen Abweichender (oder fehlender) Code wird als Versagen des Computer behandelt Computer wird daraufhin ignoriert und muss von der Besatzung abgeschaltet werden Erzeugt eng gekoppelte Gruppe von Rechnern 76

36 Sumword Synchronization Synchronisation der Rechenergebnisse 6,25 Mal pro Sekunde wird ein sumword ausgetauscht Sumword ist ein 64 Bit-Wert, normalerweise die Summe der niederwertigsten Bits aller Ausgaben zur Peripherie Drei unmittelbar aufeinanderfolgende Unstimmigkeiten führen zum Ausschluss aus dem redundant set Während unkritischer Missionsphasen werden Computer rekonfiguriert nur Rechner im redundant set synchronisieren sich mittels 3 Bit-Codes Alle anderen tauschen nur sumwords aus (common set) 77

37 Redundant Set vs. Common Set 78

38 Backup Flight System Hardware-Redundanz hilft nicht gegen Software-Fehler Fünfter Computer enthält Backup-Software unabhängig entwickelt von Rockwell enthält nur Software für Aufstieg und Wiedereintritt/Landung benutzt time-slicing Betriebssystem Backup muss sofort übernehmen können Rockwells Bestehen auf time slicing führte dazu, dass FCOS stärker als ursprünglich geplant synchronisiert werden musste Verwendung des 5. Computers wurde später kritisiert Suspenders and belts approach Nahm angeblich zuviel Druck von den IBM-Entwicklern, weil verantwortung für das Leben der Besatzung nicht mehr vollständig bei ihnen lag Bei den ersten Flügen war auch noch ein sechster Computer an Bord (cold standby) 79

39 Voting in den Aktoren Vier CPUs senden vier Signale an die Aktoren (z.b. Hydraulik in den Leitwerken) Hydraulik ebenfalls vierfach redundant Bei falschem Output überstimmen die drei richtigen ein falsches Resultat mittels Kraft vereinfacht die Architektur 80

40 Neuere Entwicklungen und Quellen Daten beziehen sich auf ursprüngliche erste Shuttle- Konfiguration (Stand der Technik 1970) sind jedoch pardigmatisch für die Methodik Heute sehr viel stärkere Integration der Bauelemente SSME-Controller 1985 ersetzt durch Rechner auf Basis (Motorola) Software geschrieben in C AP-101 ersetyt durch AP-101F Verdopplung der Rechenkapazität Weitere Quellen: James E. Tomayko: Computers in Spaceflight. The NASA Experience. NASA Contracor Report , Online: T. Heppenheimer: History of the Space Shuttle. 2 Bände (beide im Handapparat der Fallstudienvorlesung) 81

42 Geschichtliches Tandem Computers wird 1974 in Cupertino, CA, von James G. Treybig und drei früheren HP-Ingenieuren gegründet Produkt: NonStop-Technologie Vision: Eine Rechenmaschine bauen, die den einzelnen Verlust jeder ihrer Komponenten toleriert Ein-Fehler-Annahme: aus einer Menge von n gleichen Komponenten geht jeweils nur eine gleichzeitig kaputt Anwendungsdomäne: online business transactions 1976: erste NonStop-Server werden an Citibank verkauft 1979: Target (grosser US-amerikanischer Einzelhändler) steigt um auf NonStop, US-Finanzministerium auch 1981: Nasdaq verwendet NonStop-Server in der Folgezeit steigen immer mehr Banken und Telekommunikationsunternehmen auf NonStop um 83

43 Geschichtliches (Forts.) 1989: Die NonStop-Server von Pacific Bell überleben das San Francisco Bay Area Loma Prieta Erdbeben, Telefonnetz bleibt intakt 1997: Tandem Computers wird von Compaq aufgekauft (zum Preis von 3 Milliarden USD) 2002: Compaq und HP fusionieren NonStop-Technologie wird von HP weitergeführt 84

44 Erfolge (Quelle: HP) NonStop-Technologie ist ein de facto-standard im Hochverfügbarkeitsbereich Mehr als 135 Telekommunikationsunternehmen verwenden NonStop-Technologie, um das Telefonnetz verfügbar zu halten Mehr als die Hälfte aller 911-Notrufe in den USA werden durch NonStop-Server vermittelt 80% aller ATM-Transaktionen und 66% aller PoS- Transaktionen werden mit NonStop-Technologie abgewickelt NonStop-Technologie wird verwendet in 75% der 100 weltgrößten Finanzdienstleistern und in 106 von 120 Aktienbörse 85

45 (alte) Tandem-Architektur 86

46 Tandem-Architektur (Details) Zwei Datenbusse (Dynabus-Technologie): X-Bus und Y- Bus, zur Kommunikation der Prozessoren untereinander Jeder Bus hat getrennten Bus-Controller Ein Bus ist Primary, der zweite ist Backup (übernimmt bei Ausfall des Busses oder des Bus-Controllers) Prozessoren sind in Modulen zusammengefasst Ein Modul kann zwischen 2 und 16 Prozessoren enthalten Arbeiten im lock-step Modus Enthält Hauptspeicher (geschützt mit 1-Bit-ECC) Selbsttests: falls interner Fehler festgestellt wird, Selbstabschaltung IPU: Instruction Processing Unit IPB: Interprocessor Bus Interface I/O-Channel Controller: Zugriff auf Peripherie unabhängige Stromversorgung und Backup-Batterien Peripherie: Platten gespiegelt, mit zwei unabhängigen Controllern 87

47 Software-Architektur physische Verteilung wird in einem Nachrichtensystem versteckt (ähnlich CORBA) Common Message System Geographisch verteilte Prozessoren genau gleich angesprochen wie lokal angebundene Fehlererkennung mittels timeouts: CPUs senden sich selbst und allen anderen "I am alive"- Nachrichten (heartbeats) Werden zwei aufeinanderfolgende heartbeats nicht empfangen, vergleichen die Prozessoren ihre Informationen und schliessen den fehlerhaften Prozessor vom System aus 88

48 Fehlertoleranz in Software Prinzip der Prozess-Paare (process pairs): Jeder Prozess läuft als Prozess-Paar Primary/backup with hot standby Primary sendet regelmäßig checkpoint-nachrichten an Backup-Prozess Bei Ausfall des primary (gemeldet durch die Hardware) übernimmt der backup-prozess vom letzten bekannten Checkpoint Checkpoints werden sehr oft gesetzt (z.b. vor jeder I/O- Operation) 89

49 Neue NonStop-Architektur Prozess-Paare machen jetzt load sharing (performance wird wichtiger) ServerNet II Technologie I/O-Technologie: ultra SCSI Kann bis zu 4080 Prozessoren zu einem Cluster zusammenschließen Einstiegsmodell: S76 Server 2 Prozessoren (MIPS R14000 Prozessor) "S-Klasse": S86000 Server bis 16 Prozessoren, 1 bis 16 GB Hauptspeicher Man kann klein einsteigen und später aufrüsten (lock in) Mehr Infos: Technologie komplett proprietär: Produkt inklusive teurer Wartungsverträge 90