Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit

Transkript

1 Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit

2 Agenda Motivation Hardware-Fehlertoleranz Checkpointing and Rollback Recovery Systemverfügbarkeit VM-basierte Systeme Remus Architektur Sicherung Wiederherstellung Evaluation Zusammenfassung 2

3 Motivation - Frankfurter Allgemeine (Wirtschaft) Hohe Anforderungen an Verfügbarkeit von Servern mit Dienstangebot Können durch Hardware-Fehler gefährdet sein Häufig Einsatz in virtuellen Maschinen Hardware-Fehlertoleranz auf VM-Basis nötig 3

4 Hardware-Fehlertoleranz Hardware-Fehler Transiente Diskontinuierliche Permanente Anforderungen Fehlerdetektion Wiederherstellung Konsistenz des Zustands (bei verteilten Systemen) Minimale zeitliche Unterbrechung 4

5 Hardware-Fehlertoleranz Vorwärtsfehlerbehebung Vor dem Auftreten von Fehlern bereits für fehlerfreies System garantieren Z.B. dreifache Modulredundanz Modul-Instanz A Eingabe Modul-Instanz B Mehrheitsentscheid Ergebnis Modul-Instanz C Rückwärtsfehlerbehebung Entfernung von Fehlern nach ihrem Auftreten Z.B. Checkpointing and Rollback Recovery Abbildung nach Quelle 2 5

6 Checkpointing and Rollback Recovery Regelmäßige Absicherung des Systemzustands als Checkpoint Fehler Wiederherstellung eines Checkpoints und erneute Berechnung Inhalt eines Checkpoints Speicherinhalt Prozessorzustand (Register) Änderungen am Festplattenzustand Zustand der externen Kommunikation 6

7 Checkpointing and Rollback Recovery CP 1 CP 2 CP 3 Fehler Gleiche Hardware: Behebt nur transiente Fehler Getrennte Hardware: Behebt auch permanente und diskontinuierliche Fehler Rollback Recovery CP 4 Berechnungen abgeschlossen 7

8 Incremental Checkpointing Problem: Große Speichermengen in Checkpoints Vollständiger CP Inkrement Seite 0-3 store Seite 1... Seite Dirty 0 false 1 false true 2 false 3 false Starke Reduktion der Zeit für Auslesen des Speicherzustands Durch Hardwareunterstützung minimaler Aufwand für Erkennung von Schreibvorgängen Seitengranularität relativ grob (Meist 4KiB pro Seite) Inkremente können in gesicherten Checkpoint eingepflegt werden 8

9 Systemverfügbarkeit Anforderung an Systeme Zeit der Verfügbarkeit des Dienstes maximieren Hochverfügbarkeit (99,999% fünf Minuten Ausfall pro Jahr) wird von Dienstanbietern in sogenannten Service-Level-Agreements garantiert Durch Hardware-Fehler reduziert Fehlertoleranz wirkt entgegen Dienstausführung Dienstunterbrechung Fehlerdetektion Behebung Abbildung nach Quelle 3 9

10 VM-basierte Fehlertoleranz Vorteile Transparenz Sicherung d. Gesamtsystems inkl. BS möglich Nachteile Auch Sicherung ungenutzter Teile Keine lokale Begrenzung der Sicherung möglich Z.B. vmware vsphere Fault Tolerance-System Zu sichernder Host wird mit Backup Host exakt synchron gehalten Im Fehlerfall kann unmittelbar korrekter Zustand angenommen Sehr hoher Aufwand für Synchronisation und hoher Hardwareaufwand 10

11 Agenda Motivation Hardware-Fehlertoleranz Checkpointing and Rollback Recovery Systemverfügbarkeit VM-basierte Systeme Remus Architektur Sicherung Wiederherstellung Evaluation Zusammenfassung 11

12 Remus Fehlertoleranz auf VM-Basis Für Xen implementiert In Xen aufgenommen (ab Version 4.0) Zustand der virtuellen Maschine wird hochfrequent auf Backup Host übertragen Hardware-Fehler Sicherung wird ausgeführt Vorteile VM-basierter Fehlertoleranz ohne hohen Sicherungsaufwand Sicherung mehrere Hosts auf einem Backup Host 12

13 Architektur Active Host (Weitere) Active Hosts Backup Host Protected VM Replication Engine Replication Server Backup VM's Heartbeat Heartbeat Speicher Speicher Externe Geräte Festspeicher Hypervisor Hypervisor Externes Netzwerk Abbildung nach Quelle 1 13

14 Sicherung Sicherung von......gesamtem Speicherbereich...Prozessorzustand...Schreibzugriffen auf Festplatte Incremental Checkpointing mittels Zugriff auf Seitentabelle Minimaler Mehraufwand der Erkennung von Schreibzugriffen Starke Reduktion der zu übertragenden Daten Hochfrequente Erzeugung (bis zu 40 Checkpoints pro Sekunde) Konsistenzsicherung durch Pufferung des ausgehenden Netzwerkverkehrs und schreibender Dateizugriffe 14

15 Sicherung Konsistenz im verteilten System CP n Server Fehler Client Verlorene Pakete Problem wird auf Netzwerk-Ebene gelöst Noch nicht versandte Pakete Führen zu inkonsistentem Gesamtzustand Lösungsansatz: Netzwerkpuffer 15

16 Sicherung - Netzwerkpuffer Backup Host empfängt konsistenten Checkpoint Bestätigung an Active Host Inkonsistenz durch Wiederherstellung kann nicht mehr auftreten Client Active Host Puffer VM Freigabe Netzwerkpuffer wird freigegeben, sobald ACK erhalten wurde CP ACK Backup Host Abbildung nach Quelle 1 Zeit 16

17 Sicherung - Festplatte Schreibende Zugriffe werden unmittelbar asynchron an Backup Host übertragen Backup Host puffert Daten Beim Eintreffen des nächsten Checkpoints wird Puffer auf Backup-Festplatte übertragen Festplattenzustand ist zu jedem Zeitpunkt konsistent mit aktuell vorliegendem Checkpoint Active Host Backup Host Puffer Abbildung nach Quelle 1 17

18 Sicherung - Ablauf Active Host Protected VM Replication Engine Freigabe Netzwerk-Puffer ACK Backup Host Replication Server Prüfung Checkpoint Freigabe Festplatten-Puffer Einpflegung Checkpoint 18

19 Wiederherstellung Fehlerdetektion Regelmäßige Kommunikation als Heartbeat-Nachrichten interpretiert Bleibt Heartbeat innerhalb eines Intervalls aus Annahme: Fehler auf anderem Host Ausführung Backup Zustandsabbilder der Active Hosts liegen im Speicher vor Innerhalb von etwa einer Sekunde nach Auftreten des Fehlers beginnt Ausführung der Replikation 19

20 Wiederherstellung Heartbeat Timeout Active Host 1 Replikation Backup Host n Heartbeat Timeout Active Host 2 Heartbeat Timeout... Active Host n 20

21 Evaluation Testsystem IBM eserver x306, 3.2 GHz Pentium 4 Prozessor mit aktiviertem Hyperthreading, 1 GB RAM, 3 Intel e1000 GbE Netzwerk-Schnittstellen und eine 80 GB SATA Festplatte Hypervisor: Xen Betriebssystem der virtuellen Maschinen: Linux Funktion: Backup-Host übernahm nach Fehlerinjektion immer den konsistenten Zustand des Active Host innerhalb einer Sekunde Performanz Mehraufwand bei unterschiedlicher Speichernutzung Drei Benchmarks mit unterschiedlicher Systembelastung und Untersuchungsschwerpunkt 21

22 Evaluation - Mehraufwand Zeitmessung von Blockierung und Übertragung bei unterschiedlicher Speichernutzung Checkpointing-Intervall von 25 ms (40 Checkpoints pro Sekunde) wird bereits früh überschritten Schlecht geeignet für Anwendungen mit hoher Speichernutzung Abbildung aus Quelle 1 22

23 Evaluation - Kompilierung Linux-Kernel Gleichmäßige Belastung von Prozessor, Speicher und Festplatte ohne Nutzung der Netzwerkschnittstelle Laufzeit-Mehraufwand zwischen 31% und 103% bei den gemessenen Frequenzen Tolerierbarer Mehraufwand Abbildung aus Quelle 1 23

24 Evaluation - SPECweb2005 Simulation eines Web-Servers mit besonderer Belastung von Speicher und Netzwerkschnittstelle Bei zehn Checkpoints pro Sekunde etwa ein Drittel der Original-Performanz Bei 40 Checkpoints pro Sekunde circa die Hälfte der Original-Performanz Schlecht geeignet für Web-Server Abbildung aus Quelle 1 24

25 Evaluation Postmark Ausschließlich Betrachtung der Festplatten-Performanz bei Replizierung Minimale Beeinträchtigung durch Remus Gut geeignet für Anwendungen mit vielen schreibenden Festplatten-Zugriffen Abbildung aus Quelle 1 25

26 Evaluation Abgleich Anforderungen Fehlerdetektion Lediglich Erkennung von durch Fehler verursachten Systemabstürzen Es werden nicht alle Fehler (unmittelbar) erkannt Wiederherstellung Sowohl transiente als auch diskontinierliche und permanente Fehler behoben Konsistenz Systemzustand zu jedem Zeitpunkt konsistent Minimale zeitliche Unterbrechung Mehraufwand mit bis zu ca. 100% tolerierbar Etwa eine Sekunde nach Fehlerdetektion wieder lauffähig 26

27 Evaluation - Bewertung Remus ist gut geeignet für Applikationen......mit gleichmäßiger Ausnutzung von Prozessor, Speicher und Festplatte...mit starker Festplatten-Nutzung Remus ist weniger gut geeignet für Applikationen......mit hohen Anforderungen an Netzwerk-Kommunikation...mit intensiver Speicher-Nutzung Daher für den Einsatz auf Servern mit Internet-Dienstangebot nicht ideal 27

28 Agenda Motivation Hardware-Fehlertoleranz Checkpointing and Rollback Recovery Systemverfügbarkeit VM-basierte Systeme Remus Architektur Sicherung Wiederherstellung Evaluation Zusammenfassung 28

29 Zusammenfassung Hochverfügbarkeit durch Hardware-Fehlertoleranz Hochfrequente Übertragung von Checkpoints Minimaler Rückschritt im Fehlerfall Minimale Einschränkung der Verfügbarkeit Transiente, permanente und diskontinuierliche Fehler behoben Konsistenz wird erhalten Fehlerdetektion nicht optimal Stark reduzierte Performanz auf Servern mit Internet-Dienstangebot 29

30 Referenzen 1. Cully, B., Lefebvre, G., Meyer, D., Feeley, M., Hutchinson, N., Warfield, A.: Remus: High availability via asynchronous virtual machine replication. In: NSDI, Koren, I., Krishna, C. M.: Fault-Tolerant Systems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, Gray, J., Siewiorek, D.P.: High-availability computer systems. In: Computer, vol.24, no.9, pp , Sept Vmware, Inc.: Handbuch zur Verfügbarkeit in vsphere, e-esxi-vcenter-server-501-availability-guide.pdf,