Impressum & Organisatorisches

Transkript

1 Impressum & Organisatorisches Vorlesung Basierend auf: Blueprints for High Availability von Evan Markus und Hal Stern Evan Markus -> Veritas Hal Stern -> Sun - ziemlich umfassend Script & Vorlesung von: Tomas Pospisek tpospise@hsz-t.ch Script und Unterlagen unter: 1

2 Impressum & Organisatorisches Lesung -> Fragen -> Diskussion -> Pause Übung -> Diskussion -> Papier -> Compi? Kursverlauf je nach Interesse Knoff-Hoff des Dozenten vs. der Teilnehmer -> Diskussion, Beiträge 2

3 Impressum & Organisatorisches Danke für Beiträge - Luas Valle, SAN KnowHow, Diagram 3

4 1: Intro Redundanzmöglichkeiten? Fehler? Fallback Szenarien? Was sollen diese Vorlagen? Was ist das Zielpublikum? Was weiss es schon? -> HA!!! :-) HA = High Availability = Hohe Verfügbarkeit 4

5 1: Intro Was ist unser Ziel: einen Dienst (Service) anzubieten und zwar so zuverlässig wie möglich. Messkriterium für unseren Erfolg ist die Verfügbarkeit (Availability) des Dienstes in % (100% == immer verfügbar, 50% == Hälfte der Zeit) 100% in der Praxis unerreichbar gut wären 99% oder 99.9% oder 99.99%... wie viele 9en hätten Sie den gern? 5

6 1: Intro HA ist keine Lösung die man einfach einkaufen und installieren kann bevor man HA macht: - Dienst so implementieren, dass HA gar nicht erst nötig ist! - Ausfallszeit (downtime) bewerten: was kostet es, wenn der Dienst nicht verfügbar ist? - was geht verloren? - wieviel kann man sich leisten für den Schutz vor Dienstausfall auszugeben? HA ist ein fortlaufender Prozess! Testen!!! 6

7 1: Intro Verfügbarkeits-Index 1 Basic System: es hat Backups aber keinen HA Plan und nix 2 Redundant Data: RAID5 o.ä. 3 System Failover: Redundante Server 4 Disaster Recovery: Komplette Infrastruktur Spiegelung 7

8 1: Intro Überblick Kapitel 2 Kapitel 3 Kapitel 4 Kapitel 5 Kapitel 6 Kapitel 7 Kapitel 8 Kapitel 9 Kapitel 10 Kapitel 11 Kapitel 12 Kapitel 13 Kapitel 14 Kapitel 15 Kapitel 16 Kapitel 17 Kapitel 18 Kapitel 19 (Kapitel 20 Was ist Verfügbarkeit? Fehler-Ebenen Kosten von HA TODO: Politics of HA Designprinzipien für HA (und allgemein) Systeme - Backups Daten-Speichern SAN, NAS & Virtualisierung Netzwerke Datenzenter & Umgebung Menschen & Prozesse - Klienten & Konsumenten - Anwendungs-Zuverlässigkeit Daten & Web Services - Lokales Clustern & Failover - Failover Verwaltung & Probleme - Failover Konfiguration - Daten Replizierung - Virtuelle Maschinen & Ressourcen Verwaltung - Disaster Recovery) 8

9 2: Was ist Verfügbarkeit Wie misst man Verfügbarkeit? Arten/Ebenen von Fehlern Resiliency (Strapazierfähigkeit, Zähigkeit, Belastbarkeit) Resilient System: - mögliche Fehlerzustände bekannt - Lösungen bekannt - Ausfallszeiten quantifizierbar 9

10 2: Verfügbarkeit Messen 10

11 2: Verfügbarkeit Messen Strato AG 99% Verfügbarkeit garantiert Marktführer? Mio Domains 3 TB EMC SAN 2 Wochen Ausfall live Reparatur und Tests in Produktion kein Backup (?) 7'000 Sites verloren 60% der Kunden geben an, sie wollen der ISP wechseln Kaputter SCSI Kontroller? 11

12 2: Verfügbarkeit Messen sind 99% Verfügbarkeit OK? 99% entspricht 1:41h Ausfall/Woche - kommt darauf an wann & wie verteilt! - Anforderungsdefinition! mit Failover: 2 Server à 99% ( primo, secondo ) -> theoretisch ist secondo während dem 1% Ausfallszeit von primo 99% verfügbar -> Totale Verfügbarkeit = (0.1 * 0.99) = 99.99% - in der Praxis? 12

13 2: Verfügbarkeit Messen jede Stufe in der vorhergehenden Tabelle bedeutet Kosten von 5-10 Mal der vorhergehenden Stufe, wobei der Faktor von Stufe zu Stufe wächst Wie wird Downtime definiert? Benutzer kann seine Arbeit nicht zeitig erledigen 13

14 2: Verfügbarkeit Messen Ursachen von Downtime 14

15 2: Verfügbarkeit Messen Ursachen von Downtime Best in class MVS applications running on Parallel Sysplex had application availability levels between 99.9 percent and percent. Best in class distributed client/server applications running across a Unix environment (and sometimes across MVS as well) had availability levels of 99.6 percent. Best in class application availability in an NT environment was around 99 percent Gartner Group,

16 2: Verfügbarkeit Messen Ursachen von Downtime bei Web Applikationen aus Causes of Failure in Web Applications, Soila Pertet und Priya Narasimhan, Dez. 2005, 16

17 2: Verfügbarkeit Messen Statistiken zeigen z.t. sehr unterschiedliche Resultate, bzw. Gewichtungen der einzelnen Ursachen Kosten von Ausfällen nicht eindeutig: - entgangene Einnahmen? - Produktivitätseinbusse? - direkte Kosten: Haftung für Service Qualität - Ruf/Image? -... bei welchen all dieser Ursachen ist es effektiv/effizient diese abzudecken? welche sind sinnvoll abzudecken? ist es möglich diese abzudecken? wieviel bringt's? 17

18 2: Verfügbarkeit Messen Ursachen von Downtime Geplanter Ausfall - SW Upgrade Lösungmöglichkeit mit Failover Rolle wechseln, upgraden. Effizient? - HW Erweiterung oft pluggable Menschen: - Fehler! Ausbildung, KISS, klare Prozesse HW: - beinhaltet auch Stromausfall SW:

19 2: Verfügbarkeit Messen Was ist Verfügbarkeit? MTBF A = (in %) (MTBF + MTTR) MTBF = Mean Time Between Failures MTTR = Mean Time To Repair MTBF bezogen auf service life (3-5J für HDs) 19

20 2: Verfügbarkeit Messen Was bedeutet z.b %? SCSI Laufwerke (2004): ~ 1'200'000 h ~ 160 Jahre! Garantie jedoch nur 5 Jahre! SATA IDE Laufwerke (2004): ~ 600'000-1'200'000 h 1'200'000 = 0.99'9999 -> MTTR = 1.2h! 1'200'00 + MTTR guter CPU Lüfter: 50'000 h ~ 6 Jahre -> MTTR = 3 min Quelle: erste Seite Google: SCSI Fan MTTR 20

21 2: Verfügbarkeit Messen M is for Mean Schnitt, jedoch Standardabweichung, Verteilung? - Lebensdauer: 1, 1, 1, 1, 46 ergibt Mittel von Erwartungen der Benutzer entsprechend setzen: - wenn effektiv 20 min für eine Reparatur nötig sind, ist es besser den Beutzern 1h anzugeben anstatt 10 min. Ruf bei Kunden/Öffentlichkeit kann auch bei objektiv sehr guter Verfügbarkeit einen grossen Schaden nehmen, wenn der Ausfall in einem schlechten Moment passiert 21

22 2: Ausfallsmodi Hardware v.a. bewegliche oder komplexe Teile, Teile mit engen Toleranzen, hohe Geschwindigkeiten: - HDs - Bänder - Lüfter Stromversorgung: - fällt abrupt aus oder - fällt unmerklich, langsam, graduell aus 22

23 2: Ausfallsmodi Hardware (ff) sowohl schlecht funktionierende Lüfter als auch sich graduell verschlechternde Stromversorgungen können sehr ekelhaft sein -> bewirken kuriose, nicht nachvollziehbare oder sehr unregelmässig auftretende Ausfälle - beide haben die tiefsten MTBF auf Computersystemen - sind deswegen oft doppelt oder mehrfach ausgelegt - haben z.t. call home Funktionalität 23

24 2: Ausfallsmodi Umgebungs- und physikalische Ausfallursachen System-externe Faktoren oft unterbewertet teilweise Standby System nutzlos, da ganze Umgebung betroffen ist Stromausfälle, Brownouts Kühlung/Luftaufbereitung Feuerlöschsystem Feuer etc. 24

25 2: Ausfallsmodi Netzwerk-Ausfälle sehr viele Komponenten beteiligt die meisten nicht unter eigener Kontrolle - Netzwerk-Administration oft von System Administration getrennt - Upstream etc. DOS / Eindringlinge Viren 25

26 2: Ausfallsmodi DB-System Ausfälle DBs komplex bestehend aus diversen internen Subsystemen DB stürzt ab DB hängt Ressourcen gehen aus DB Index korrupt SW Fehler 26

27 2: Ausfallsmodi Web-Server Ausfälle rel. junge Software schnelle Entwicklung komplex Benutzer wechselt zu anderem Anbieter File & Printserver Ausfälle Basis vieler SW 27

28 2: Vertauenswürdigkeit der Messungen Erneuerbarkeit oft nach Reparatur höhere Wahrscheinlichkeit eines weiteren Ausfalls wenn dem nicht so ist, sind berechnete MTBF's vertrauenswürdiger periodische Reboots versuchen MTBF zu reduzieren 28

29 3: Der Wert von Verfügbarkeit Direkte Kosten von Downtime verlorene Benutzerproduktivität verlorene Aussenstellen-, Berateraufträge überzogene Termine keine Auslieferung möglich entgangene Aufträge SLAs 29

30 3: Der Wert von Verfügbarkeit Indirekte Kosten von Downtime Kundenzufriedenheit schlechter Ruf, PR,.. Aktienpreis Haftung Mitarbeiterzufriedenheit 30

31 3: Der Wert von Verfügbarkeit TODO Wert von Verfügbarkeit S = R n Rv S = Ersparnis Rn = Ausfalls-Risiko (Kosten) nach Verbesserung Rv = Ausfalls-Risiko (Kosten) vor Verbesserung ROI = S/Kv ROI = Return On Investment Kv = Kosten der Verbesserung 31

32 3: Kosten/Risiko Abwägung Stufen der Verfügbarkeit 1. Stufe: reguläre Verfügbarkeit Probleme lösen sobald sie auftauchen 2. Stufe: erhöhte Verfügbarkeit Datenschutz -> Datenspiegelung, RAID etc. 32

33 3: Kosten/Risiko Abwägung Stufen der Verfügbarkeit (ff.) 3. High Availabililty Redundante Server -> Cluster womöglich alles doppelt 99.98% und mehr erreichbar Netzwerkdesign Support Systeme System & Netzwerkadministration einbezogen Audit, um sicher zu stellen, dass alle Eventualitäten berücksichtigt wurden (-) Komplexität (-) Flexibilität (-) Verwaltung wird schwieriger (-) Kosten 33

34 3: Kosten/Risiko Abwägung Stufen der Verfügbarkeit (ff.) 4. Disaster Recovery Infrastruktur an mehreren Orten gespiegelt Prozeduren für Umzug Wer macht was Verantwortlichkeiten und Stellvertreter SA & NA an mehreren Orten etc. 34

35 3: Kosten/Risiko Abwägung Stufen der Verfügbarkeit (ff.) Fehlertollerante Systeme System selbst ist komplett redundant oder mehrfach aufgebaut Fehler werden mittels Mehrheitsentscheidungen erruiert fehlerhafte Komponenten vom System isoliert theoretisch kein Hardware bedingter Ausfall möglich sehr teuer basieren oft auf bewährten Komponenten 35

36 3: Kosten/Risiko Abwägung Abwägen von Risiken und Chancen Komponenten schützen, die: am häufigsten ausfallen am schwersten zu ersetzen sind: - sowohl bzgl. Marktverfügbarkeit - als auch praktisch -> am besten Komponenten verbauen, welche lange halten und einfach zu ersetzen sind! bei Ausfall den grössten Einfluss haben - intelligente Komponenten verwenden, welche auf Ausfälle reagieren können: - Ventilator fällt aus -> System fährt runter Daten zuerst schützen, Zugang zu Daten als nächstes 36

37 3: Kosten/Risiko Abwägung Die wichtigsten Punkte: Komponenten können ausfallen. Dies sollte entsprechend berücksichtigt und geplant werden Vorsicht vor Durchschnittswerten, Maximalwerte sind besser: - längste Ausfallsdauer, die man verkraften kann - worst-case Zeit um ein Problem zu beheben Sowohl Schutz als auch Downtime kosten Geld -> abwägen 37

38 4: Politics of Availability TODO 38

39 4: Politics of Availability Problematik dem Management nahebringen Kosten (direkt/indirekt) berechnen verschiedene Stufen von Verfügbarkeit erklären Bild umfassend anschauen, komplette Szenarios planen Vorschläge für Problembehebung Risiken evaluieren, welche man eingehen sollte: - effektivste Risikoverminderungen - am wahrscheinlichsten eintreffend Empfehlungen machen und begründen/belegen aufzeigen, dass es eine schlechte Idee ist erst aus Erfahrungen zu lernen 39

40 5: 20 grundlegende Design-Prinzipien #20: Geld ausgeben, aber nicht blindlings Qualität kostet Prioritäten setzen Return on Investment #19: Nichts voraussetzen keine out of the box HA! Situationen definieren und austesten sicherstellen, dass alle Beteiligten Problematik überblicken -> Ausbilden 40

41 5: 20 grundlegende Design-Prinzipien #18: Single Point Of Failure entfernen schwächstes Glied der Kette Iteration #17: Streng auf auf Sicherheit achten Datenkorruption verhindern #16: Server Kosolidieren weniger Teile jedoch: Isolation? 41

42 5: 20 grundlegende Design-Prinzipien #15: Häufige Aufgaben automatisieren weniger Fehler #14: Änderungs-Kontrolle Einhalten alle relevanten Gruppen sollten Änderung & Zeitplan absegnen Risiken angeben, Rückzugsstrategie 42

43 5: 20 grundlegende Design-Prinzipien #13: Alles Dokumentieren Audit Trails Guides Dokumentieren für: - SA selbst: was, warum, wie? - Nachfolger/Mitarbeiter - Management schlechte Doku ist schlimmer als keine - während Stresssituation wird Doku blindlings gefolgt Book of Evan : Tradition, dass abgehende Mitarbeiter letzte 2 Wochen alles für Nachwelt dokumentieren Offline speichern 43

44 5: 20 grundlegende Design-Prinzipien #12: Service Level Agreements welche Verfügbarkeitsstufen? Verfügbarkeits-Zeiträume: welche kritisch? wo, wie verfügbar? Prioritäten (wer, wo zuerst im Fall der Fälle) Eskalations-Reihenfolge #11: Vorausplanen Ausnahmezustände und Krisen vorausplanen Unbekannte Situation planen: Zuständigkeiten - Alternative ist alles sofort jetzt flicken wenn's brennt -> Chaos offline dokumentieren 44

45 5: 20 grundlegende Design-Prinzipien #10: Alles Testen Krisen Pläne Applikationen OS HW alle Änderungen: HW/SW/Prozeduren Tests in so Produktions-ähnlichen Umgebungen wie möglich wenn möglich von Usern auf allen Ebenen testen, Ende-zu-Ende Tests regelmässig wiederholen 45

46 5: 20 grundlegende Design-Prinzipien #9: Separate Umgebungen unterhalten Netze Computer User 1. Produktion Änderungen nur unter kontrollierten Bedingungen alles muss zu jeder Zeit funktionieren wenn etwas nicht funktioniert muss es einen Weg geben zu einer Version zurückzukehren, die funktionierte Änderungen müssen reibungslos, ohne Unterbrechung durchgeführt werden 46

47 5: 20 grundlegende Design-Prinzipien #9: Separate Umgebungen unterhalten (ff) 2. Produktions-Spiegel Kopie der Produktion für Rollback Spiegel wird erst upgedated, wenn bewiesen ist, dass die Produktion korrekt funktioniert (Regressions-Tests?) 47

48 5: 20 grundlegende Design-Prinzipien #9: Separate Umgebungen unterhalten (ff) 3. Quality Assurance Testumgebung für Applikationen welche als produktionsreif angesehen werden kontrollierte Änderungen 4. Entwicklung kann fehlerhaft sein 5. Labor Freestyle, Spielwiese 6. Disaster Recover Räumlich weit von den anderen entfernt 48

49 5: 20 grundlegende Design-Prinzipien #8: Geschichte des Systems überwachen Aufzeichnungen behalten MTTR notieren wie verbessern? was war Ursache des Ausfalls? häufige Probleme zuerst angehen 80/20 Faustregel: - 80 % der Probleme aufgrund von 20% der Ursachen 49

50 5: 20 grundlegende Design-Prinzipien #7: Wachstum einplanen Gesetz von Boyle-Mariotte : Gas dehnt sich aus bis es den ganzen Raum auffüllt entsprechend planen 50

51 5: 20 grundlegende Design-Prinzipien #6: ausgereifte SW einsetzen Know How Benutzerbasis Support jedoch Open Source: - grosse Benutzerbasis - viele Entwickler - einfach zu erhalten - einfach Fehler zu beheben #5: zuverlässige und einfach wartbare HW einsetzen Ersatzteile verwalten alternative Zulieferer haben 51

52 5: 20 grundlegende Design-Prinzipien #4: Konfigurationen wiederverwenden 3 oder 4 Konfigurationen (klein, gross, mittel) einfacherer Support: - weniger HW/SW Permutationen - weniger zu lernen - weniger kann kaputt gehen vorgetestete Konfigurationen: - mehr Vertrauen - zuverlässiger - Einsatz neuer Maschine kann einfacher gerechtfertigt werden - nur Unterschiede müssen getestet werden Einkaufen in grossen Mengen weniger Ersatzteile 52

53 5: 20 grundlegende Design-Prinzipien #3: externe Ressourcen nutzen jemand hat (fast) jedes Problem schon gelöst - Skripts - Google... Berater unabhängige aber v.a. Hersteller - sicherstellen dass Know-How Transfer stattfindet! Trainingsangebote (der Hersteller) nutzen #2: ein Problem -> eine Lösung Werkzeuge nicht in etwas reinmurksen #1: KISS Mehrdeutigkeit aus System entfernen 53

54 6: Backup und Restore grundlegende Regeln für Backups die wichtigste Aufgabe für HA Spiegelung ersetzt Backups nicht (Datei gelöscht...) die häufigste Verwendung von Restores ist nicht nach einer Katastrophe regelmässig Restores versuchen Laufwerksköpfe sauber halten MTBF von Bändern beachten: - gute Backup Software wird Anzahl Zugriffe berücksichtigen und dem Benutzer Nachricht geben, wenn er neue Bänder kaufen soll Qualität der Bänder sinkt mit der Zeit zwei Kopien von kritischen Bändern machen off-site lagern 54

55 6: Backup und Restore Kommerzielle SW 100% HW Ausnutzung Hot Backups: - DBs, FSs offenes Band-Format: - Bänder auch ohne SW lesen - keine Lizenz-Schlüssel nötig um Bänder zu lesen Geschwindigkeit zentralisierte Verwaltung Zuverlässigkeit: kein SPOF schnelle Disaster Recovery: - kein Neuerstellen der Indices HW Unterstützung & Flexibilität - existierende HW wird unterstützt 55

56 6: Backup und Restore Kommerzielle SW (ff) ausgereifte Produkte mit Referenzen Medien Verwaltung: - Labeling - Barcode Verwaltung - off/onsite Medien - Wechsler Backup Leistung langsamstes Glied besseres Netz, mehr Interface Karten etc. direkt an grosse HDs anschliessen mehrere Laufwerke 56

57 6: Backup und Restore Hot Backups (auch von DBs) optimal: keine Unterbrechung Konsistenz Zwischencache für Daten damit sich diese während Backup nicht ändern DB writelock Dateien bei NT sind gelockt, wenn diese offen sind Unix -> mehrere Durchgänge über FS FAM/inotify Weniger Daten, schnellere Backups, weniger Platzverbrauch hierarchische Speicher-Verwaltung nicht verwendete Daten in Archive auslagern 57

58 6: Backup und Restore Mehr HW verwenden off-host Backup : Disks direkt auf Tape Third-Mirror Breakoff Backup direkt auf Disk: jedoch Backup auf Tape schneller Fortgeschrittene SW Features Copy-On-Write Schnappschüsse Schnappschusszeit festlegen danach werden überschriebene Blöcke auf die Seite getan, damit man den festgehaltenen Zustand Backupen kann 58

59 6: Backup und Restore Gemultiplexte Backups mehrere Backups gleichzeitig auf ein Band Schnelle & Flash Backups dd if=/dev/hda of=/dev/st0 59

60 6: Backup und Restore Backup Bänder & Daten Verwalten physischen Zugang zu Bändern beschränken Bänder magnetisch löschen, bevor sie weggegeben werden Übermittlung von Backupdaten verschlüsseln keine unerlaubten Benutzer-Restores erlauben Bänder, welche Firma verlassen, schützen Bänder nicht offsite lagern (MTTR wird grösser) Sicherheit und schnellen Zugriff abwiegen jedes Band beschriften Barcodes verwenden 60

61 6: Backup und Restore Restores schnellerer Restore <-> langsamerer Backup schnellerer Restore: - weniger inkrementelle Backups - Bänder erreichbar halten -> MTTR - schnellsten Pfad verwenden (Disk->Band) - am besten gar nicht Restores machen (online Snapshots) Speicheranforderungen für Restores Achtung: Restores können mehr Daten als Speicherplatz enthalten (alte Dateien) gute SW wird gelöschte Dateien nicht wiederherstellen 61

62 6: Backup und Restore die wichtigsten Punkte Backups sind die letzte Verteidigungsline -> Priorität! zuverlässige SW Zeitfenster beachten (reicht Zeit zwischen Backups überhaupt aus?) HDs sind kein Ersatz für Bänder hat die SW die Features, die man braucht? 62

63 7: Hochverfügbare Datenverwaltung HDs sind die kritischsten Komponenten eines Computersystems? 63

64 7: Hochverfügbare Datenverwaltung HDs sind die kritischsten Komponenten eines Computersystems Fundamentale Wahrheiten 1. HDs sind die Komponenten welche am wahrscheinlichsten Ausfallen mehr Disks als andere Komponenten in Computersystemen Grobschätzung bei 100 Disks à 1'200'000h MTBF (2004): - 1'200'000 / 100 => mit 50% Wahrscheinlichkeit fällt nach 2 Jahren die erste aus - 200'000 (1996) 2. HDs enthalten Daten 3. Daten müssen geschützt werden 4. Datenzugang muss gesichert werden 64

65 7: Hochverfügbare Datenverwaltung Über MTBF von HDs MTBF von Hersteller via beschleunigte Alterung von rel. kleinen Populationen oder zurückgegebenen Geräten berechnet problematisch (Einsatz? Produktionslast?) MTBF basierend auf service life Disk Temperatur und Last kein eindeutiger Einfluss auf MTBF Ein-/Ausschalten sehr schwacher Einfluss Alterungsverhalten unterschiedlich zwischen Modellen wenn (SMART-)Fehler auftreten HD wechseln HDs fallen aber häufig (56%) ohne SMART Fehler aus Quellen: [Google Labs], [StorageReview.com] 65

66 7: Hochverfügbare Datenverwaltung Entscheidungsgrundlage für den Aufbau einer hochverfügbaren Lösung ist das folgende hierarchische Datenspeicher-Modell: 1. physische Festplatten 2. Hardware RAID - verfügt üblicherweise über ein Management Tool 3. Software RAID/Volume Management - läuft im oder sehr nahe am OS 4. Filesystem oder Raw Device - ist die Schicht, mit der die Applikation spricht 5. Applikation / DB 66

67 7: HD und Verbindungs-Terminologie SCSI Small Computer Systems Interface Bandbreiten 3MB/s-640MB/s 50 bzw. 68 pin Käbel max. Kabellängen 6-25m Busbreiten: - Narrow: 8 bit - Wide: 16 bit - Ultra: 32 bit Protokolle: single-ended, differential Generationen: SCSI-1, SCSI-2, SCSI-3 Heute: SCSI-3 (Ultra SCSI), v.a. differential - Wide-Ultra SCSI: 40MB/s - Ultra-2 SCSI: 40-80MB/s - Ultra-3/Ultra160: 160MB/s - Ultra320,640: 320,640MB/s 67

68 7: HD und Verbindungs-Terminologie SCSI Small Computer Systems Interface (ff) SCSI sollte während Gebrauch nicht ausgesteckt werden -> Datenverlust braucht Terminator auf beiden Seiten des Kabels/Busses - System terminiert per default eine Seite - einzelnes Gerät am Bus -> Terminierung hinzufügen - mehrere Geräte -> keine Terminierung Anzahl der Gültigen Geräte-Adressen auf einem Bus = Busbreite -1 Hostadapter auf SCSI Bus hat traditionel #7 zwei Arten von Geräten werden unterschieden: - Target - Initiator (Computersystem) mehrere Initiatoren auf einem Bus möglich 68

69 7: HD und Verbindungs-Terminologie Fibrechannel bis zu 2GB/s ca. 16Mio Geräte am FCAL Netz bis zu 80km Distanz Router, Hubs, Switches Geräte sind elektrisch unabhängig -> können ausgesteckt werden, ohne dass dies Einfluss auf andere Geräte am Bus hat benutzt SCSI Protokol SAS Serielles SCSI hotplug fähig point-to-point keine Terminatoren grosse Anzahl von Endgeräten (> 16384) bis zu 6GB/s momentane Entwicklungsrichtung 69

70 7: HD und Verbindungs-Terminologie iscsi über Ethernet TODO 70

71 7: HD und Verbindungs-Terminologie Multihosting Gerät an zwei Systemen angeschlossen typischerweise kann jedoch nur ein System schreiben Failover Multipathing 1 Host erreicht eine Disk oder ein Diskarray über verschiedene Pfade mehr Durchsatz JBOD Just a bunch of Disks ohne HW-Intelligenz zwischen den Disks 71

72 7: HD und Verbindungs-Terminologie Hot-pluggable/Hot-swappable Disks d.h. während regulärem Betrieb keine Downtime für Host oder andere Disks Warm-pluggable Disks d.h. bei angeschaltetem Gerät jedoch ohne Daten-Verkehr nur einige Disks sind von Wechsel betroffen Hot-spares sind als Reserve ans System angeschlossen sobald Disk ausfällt werden mittels HW oder SW die Daten auf dem Hot-spare rekonstruiert 72

73 7: HD und Verbindungs-Terminologie Write-Cache schneller ohne Batterie-Backup -> Datenkorruption bei ACID über mehrere Systeme problematisch -> Synchronization SAN Storage Area Network Speicherpool auf den verschiedene Hosts zugreifen können intern RAID Speicher kann zwischen verschiedenen Hosts aufgeteilt werden zentralisierte Allokation & Verwaltung eingebaute Belasbarkeit & Hochverfügbarkeit Multipath 73

74 7: HD und Verbindungs-Terminologie SAN Storage Area Network (ff) Infrastruktur kann verteilt werden: - dank 2km Limit müssen weder Disks noch Server am gleichen Standort sein intelligentes & effizientes Failover: - N:1, N:N, kaskadiert, Service-Level Failovers effizienter Ressourceneinsatz - z.b. teuere Bandlaufwerke für alle erreichbar Backups ohne LAN Belastung Heiliger Gral des Datenmanagements: - heterogener Datenzugriff möglich 74

75 7: HD und Verbindungs-Terminologie SCSI vs. Fibrechannel FC ist in komplexen Konfigurationen: billiger einfacher zuverlässiger 75

76 7: HD und Verbindungs-Terminologie RAID HW SW -> CPU Belastung RAID basiert auf verschiedenen Stufen von Datenredundanz RAID-0: Streifen (Striping) Speicherplatz wird in Streifen aufgeteilt und diese Streifen sequentiell auf Platten verteilt mehrere Disks, evtl. mehrere Kontroller höherer Durchsatz Verfügbarkeit sinkt! 76

77 7: HD und Verbindungs-Terminologie RAID-1: Spiegelung (Mirroring) nicht nur auf 2 Platten limitiert! - bei mehr als 2 können überzählige Platten als Produktions-Daten für Entwicklung oder QA oder Disaster Recovery verwendet werden oft keine Master/Slave Beziehung: - Lesen von beiden Platten prallel 77

78 7: HD und Verbindungs-Terminologie RAID-1: Spiegelung (Mirroring) (ff) Backup -> Schutz vor Benutzer-Fehler RAID -> Schutz vor Ausfall (+) Schutz (+) schneller (-) teuerer (keine Skaleneffekte, 100% teuerer) (-) Resynchronization teuer: - Zeit - Durchsatz leidet während Resynchronization (-) Schreibzugriff langsamer 78

79 7: HD und Verbindungs-Terminologie RAID-0-1, 1-0, und 0-1 sind nicht identisch! 1-0 oft auch als 10 bezeichnet jedoch Vorsicht! 10 könnte eine integrierte Lösung sein! wir gehen davon aus, dass jede RAID Stufe eine Abstraktion für die nächste Stufe bedeutet 79

80 7: HD und Verbindungs-Terminologie RAID 0-1 (gespiegelte Streifen) d.h. die RAID-0 Stufe stellt für den Spiegelungs-Mechanismus eine virtuelle Platte dar wenn eine Platte in einem RAID-0 ausfällt ist somit die gesammte, von der RAID-0 Stufe exportierte virtuelle Platte unbrauchbar das Wiederherstellen einer defekten Seite eines RAID-1 Spiegels erfordert also das Wiederherstellen aller Platten innerhalb des RAID-0 wenn eine Platte in der Kopie ausfallen sollte ist das gesamte System ausgefallen 80

81 7: HD und Verbindungs-Terminologie RAID 1-0 (gestreifte Spiegel) die RAID-1 Stufe exportiert 2 gespiegelte Platten als eine virtuelle der RAID-0 Mechanismus nimmt diese virtuelle Platte und verbindet sie mit weiteren virtuellen Platten, wodurch eine grosse, von der RAID-0 Stufe exportierte Platte entsteht wenn eine Platte ausfällt, sondert der RAID-1 Mechanismus, diese ab. Dadurch wird nicht mehr auf die Platte zugegriffen. Der Rest des Gesamtsystems ist davon nicht betroffen. sobald die defekte Platte ersetzt wird muss nur diese von der Kopie wiederhergestellt werden das System verkraftet einen weiteren Ausfall einer Platte, mit Ausnahme der einen verbleibenden Kopie Nachteil von 1-0 ist, dass man jeweils Paare von gleich grossen Platten haben muss. 81

82 7: HD und Verbindungs-Terminologie RAID-2: Hamming Encoding jedes Wort wird über mehrere Disks verteilt zusätzlich gibt es ECC Disks bei kleinen Worten -> viele ECC Disks nur so schnell wie die langsämste Disk grosse Bandbreite keine kommerzielle Implementation 82

83 7: HD und Verbindungs-Terminologie RAID-3, 4, 5: Parity RAID Daten werden in Blöcke unterteilt und diese Blöcke über die Disks gesteift eine Platte enthällt Block Parität (XOR aller Streifen eines Blocks) eine ausgefallene Platte kann neu errechnet werden jede Platte muss gleich gross sein Schreibvorgang ist langsam, da immer Parität aus allen Streifen errechnet werden muss Wiederherstellung einer Disk ist teuer 83

84 7: HD und Verbindungs-Terminologie RAID-3: Block in Streifen Ein zu schreibender Block wird in n Streifen aufgeteilt. Jeder Streifen wird auf die entsprechende Platte geschrieben. Letzte Platte enthällt Parität. jeder Diskzugriff berührt alle Platten kleine random-access Schreibzugriffe sind langsam HW Systeme haben Cache RAID-4: Paritätsblock auf dedizierter Platte ein Block pro Platte letzte Disk enthällt nur Parität entsprechend hat diese Platte den grössten Verschleiss Paritätsplatte ist bei Schreibzugriffen Flaschenhals HW Systeme haben Cache 84

85 7: HD und Verbindungs-Terminologie RAID-5: Parität verteilt über alle Platten kein Flaschenhals 85

86 7: HD und Verbindungs-Terminologie HW RAID beeinträchtig den Host nicht die virtuelle Disk sieht genau wie ein logical Unit (LUN) aus sowohl stand-alone als auch intern (+) Leistung (+) Disk Cache -> Leistung - readahead (+) advanced Features: - Wide Area Data Replication - Disks die zwischen mehreren Hosts geteilt werden können (-) beschränkt auf ein Diskarray (-) schwierig Array umzukonfigurieren oder Grösse zu verändern 86

87 7: HD und Verbindungs-Terminologie HW RAID (ff) (-) (-) (-) kein standard Management Interface evtl. Beschränkungen (Grösse des Arrays, Anzahl LUNs,...) Vendor Lock-In (-) SPOF - Trafo - Kühlung - Stromkabel - Sicherung - interne Disk Kontroller - Cache Batterie - Backplane - Stromschalter - Gehäuse 87

88 7: HD und Verbindungs-Terminologie Disk Arrays JBOD Schrank + Intelligenz (Oberbegriff von NAS und SAN) haben meist Cache fahren intern RAID weitere mögliche Features: Wide Area Data Replication - normal ist Remote read-only intelligente Busse - können automatisch Host isolieren parallele Busse - single Host via verschiedene Busse - höherer Durchsatz - Fallback 88

89 7: HD und Verbindungs-Terminologie Disk Arrays (ff) weitere mögliche Features (ff) Verbindung zu vielen Hosts auf einmal -> SAN hot pluggable Disks hot Spares read-ahead Buffer können intern Kopien von virtuellen Laufwerken machen -> gut für QA, Entwickler etc. komfortable Speicheradministration - einbindbar in Management Systeme phone home 89

90 7: HD und Verbindungs-Terminologie Software RAID (+) flexibel (-) bei Parity RAID -> CPU Belastung (+) Speicher Administration (+) keine HW Beschränkung (+) Kosten Volume Management online Rekonfiguration Betriebsystem-spezifische Limiten können überwunden werden möglicherweise mit System Management Tools integriert (Reporting von kaputten Disks, SNMP,...) Hot Sparing 90

91 7: HD und Verbindungs-Terminologie Welches ist die Patentlösung Integration von Ebenen: - HW RAID in Arrays - SW Striping zwischen Arrays - LVM für Verwaltung Komplexität? Kosten? 91

92 7: Festplattenplatz & Dateisysteme Boyle's Gesetz: Gas dehnt sich aus, bis es den ganzen Raum erfüllt Ressourcen, bzw. freien Festplattenplatz lassen volles FS -> Verfügbarkeit nicht gegeben besser auf optimale Leistung statt auf Kapazität zu optimieren 40% Reserve lassen 92

93 7: Festplattenplatz & Dateisysteme Weitere Punkte die zu berücksichtigen sind: hot-pluggable Disks physische Kapazität der Einzelteile: - Platz auf Disks - Stecker am RAID Controller - Steckplätze an Backplane - an den Käbeln - im Rack, bzw. im Disk Array, bzw. Disk-Slots - Bodenfläche im Datenzenter - ausreichend Kühlkapazität - genügend Strom-Leistung - Reserveplatz in Kabelleitungen Leistung: - wieviele Platten soll ich an einen Kontroller hängen alle Kosten in Wachstumsplan einrechnen 93

94 7: Festplattenplatz & Dateisysteme Was passiert, wenn ein LUN (z.b. Array) voll ist? vorausplanen! LVM hotplugging Disks Ansonsten: - User vom System nehmen - Backup machen - Maschine runterfahren - erweitern - Backup einspielen - testen - zurück in Produktion Alternativen: - Merge-Mount - FS in mehrere Mountpoints unterteilen 94

95 7: Festplattenplatz & Dateisysteme Disks und Volumes hochverfügbar halten: redundante Datenpfade & Kontroller redundante Disk-Array HW Racks - darauf achten, dass redundante HW nicht im gleicher Rack ist Kabel - verschiedene Pfade von Kabeln - Kabel anmachen Stromversorgung - verschiedene Stromquellen 95

96 7: Festplattenplatz & Dateisysteme Filesystem Wiederherstellung: moderne OS haben Cache -> OS/Maschinen Crash -> FS Korruption möglich FS Check geht lange: ~1min/GB kleine FS besser Journaling FS 96

97 7: Festplattenplatz & Dateisysteme snapshot.debian.net: alle je veröffentlichten Debian Pakete, auch Zwischenversionen Terrabytes an Daten Maschine hatte Absturz FS Check nach einem Monat FS Check 2. Absturz 3 Jahre Archivdaten verloren ( ) 97

98 7: Festplattenplatz & Dateisysteme Die wichtigsten Punkte: Festplatten enthalten Daten, das wichtigste Element der Informatik Daten prioritär schützen Backups machen Spiegeln (RAID-1) ist am besten Spiegeln zwischen Arrays 98

99 8: SAN, NAS & Virtualisierung SANs SAN exportiert virtuelle Disks typischerweise auf eigenem Netzwerk: FC Warum SANs? Zentralisierung & Konsolidierung - Komplexität der Speicherverwaltung wird reduziert - Speicherverwaltung wird flexibler Teilen von Daten - geclusterte Filesysteme - Failover tiefere Netzwerkbelastung effizientere Backups jedoch Kompatibilität zwischen Produkten? Firmware Upgrade SAN Treiber Upgrade Clients? 99

100 8: SAN, NAS & Virtualisierung Hitachi Universal Storag Platform USP1100 ( 100

101 8: SAN, NAS & Virtualisierung NAS NAS exportieren Filesysteme - NFS, CIFS, AppleTalk,... können auf Servern existieren (Samba...) oder auf Appliances - Appliance sehr einfach zu verwalten - performant 101

102 8: SAN, NAS & Virtualisierung SANs oder NAS SAN zentralisiert - Backups - Verwaltung SAN komplexer SAN immer noch in Entwicklung NAS über mehr Protokolle (NFS->TCP->IP->Ethernet): - tiefere Leistung? SAN macht Mirroring etc. einfacher SAN grössere Distanzen 102

103 8: SAN, NAS & Virtualisierung Speicher Virtualisierung virtuelle oder logische Disks Virtualisierung -> flexibler: - Management - Verfügbarkeit (Mirroring, Parität) - keine Grössenlimiten (Aggregation) - Performance (Striping) Virtualisierungs-Ebenen Filesystem: - FS sieht aus, als ob es lokal laufen würde (NFS, CIFS,...) Block: - virtuelle oder logische Disk/Volume können aus verschiedenen physischen Disks zusammengesetzt sein 103

104 8: SAN, NAS & Virtualisierung Block Virtualisierung im Disk Array RAID fortgeschrittene Systeme erlauben Zugriff von diversen Hosts aus - Fallover - Partitionierung Virtualisierungs im Applikations-Server nur Server selbst kann von Virtualisierung profitieren 104

105 8: SAN, NAS & Virtualisierung Virtualisierungs im Speicher-Netz (SAN) In-band Virtualisierung: - alle Anfragen gehen durch eine Box (PC), welche Anfragen an entsprechende Disks weiterleitet - SPOF, Bandbreite Out-of-band Virtualisierung: - die meiste Arbeit geschieht im Treiber des Clients - komplexer, da spezial-sw überall installiert sein muss - ein Fehler im Client und alles ist futsch Virtualisierung und QoS Admin kann verschiedene QoS anbieten: - mehrfache Spiegelung - RAID

106 9: Netzwerke wie fallen Netzwerke aus? wie findet man heraus, ob eine Situation korrigierbar ist? was kann man tun? Netzwerkprobleme schwer mit Sicherheit bestimmbar: - vorübergehende Netzüberlastung - IP ist selbstheilend/routet um Probleme herum 106

107 9: Herausforderungen für Zuverlässigkeit von Netzwerken Bisher: alles unter Kontrolle Netzwerk: verteilt, teils keine SPOFs, unterliegt Kräften von aussen Netzwerkunterbrüche kommen und gehen Überlastung in Wellen -> messen im falschen Moment... Schwierig zu definieren wo Netz ist was wird gemessen? verschiedene Teile von verschiedenen Entitäten kontrolliert Latenz trägt zu wahrgenommenen Ausfällen bei 107

108 9: Herausforderungen für Zuverlässigkeit von Netzwerken DOS sind real Nonsens Anfragen kaputte Geräte Last-Verteilung ist eine Frage von Skalierung und nicht von Zuverlässigkeit Netzwerkzugang ist nicht so sicher wie er sein sollte freie Netzstecker & Fremde mit Laptops falsch konfigurierte Geräte falsche Netzwerkkäbel 108

109 9: Arten von Netzwerkausfällen lokales Netzwerk-Interface Verkabelung: - physikalische Probleme - Ein/Ausstecken - Zug-Kräfte - Abnutzung Netzwerk Infrastruktur - Überlast Router & Routing Information - Konfiguration - Interoperabilität - Redundanz erhöht Last auf Router -> Ausfall zentrale Netzwerk-Dienste: - DNS, DHCP, NIS, LDAP, Sicherheitsdienste... - NFS, DCE/DFS, Windows SMB Latenz Varianz 109

110 9: Erkennung & Behebung Ausfall von physischen Geräten netstat -i -> keine Erhöhung der Paketzählung -> Fehler-zähler -> Input Zähler zentrale Maschine (SA's?) pingen -> Wechsel auf redundantes Netz Ausfälle auf IP Ebene gleiche/falsche IP Adresse -> ARP Race falsche DNS Einträge -> Prozesse verbessern, damit dies nicht passiert 110

111 9: Erkennung & Behebung Ausfälle über Routing Informationen asymetrische Routen unvollständige oder nicht korrekte Routing Einträge -> traceroute Ausfälle durch Überlast kann auch DOS sein Paket-Drop übermässiger Point-to-Point Verkehr (Ethernet ausgelastet) Broadcast Pakete: - UDP: RIP, Cisco HELLO, DHCP, NIS das Server sucht,... - ARP - SMB/CIFS/NetBIOS - UpnP, Rendezvous/Zeroconf - Host hat Broadcast Adresse Multicast Verkehr 111

112 9: Erkennung & Behebung Design- & Betriebs-Richtlinien über Basiswissen verfügen: - wie findet man was heraus, wie funktionieren Protokolle, Dienste, etc. Werkzeuge kennen Router, Filter, Firewalls einsetzen Applikations-Level-Relays einsetzen: - Proxies etc. Bandbreite wird genutzt, wenn sie verfügbar ist! Grundsatz: Redundanz, damit Ausfälle vertragen werden 112

113 9: Erstellen von redundanten Netzen Virtuelle IPs private, administrative Adressen Round-Robin DNS IP Failover nur Dienste müssen mehrere IPs haben Redundante Netzwerk-Verbindungen mehrere Verbindungen an ein Netzwerk machen an mehr als ein Netzwerk anschliessen beides 113

114 9: Erstellen von redundanten Netzen Redundante Netzwerk-Anbindungen redundante Busse? entspricht assymetrischer HA Anbindung an mehrere Netze entspricht symetrischem HA im Prinzip beide Netzwerke nutzbar jedes Interface eigene IP -> Round-Robin DNS Load-Balancing über 2 IP Adressen: - problematisch für einzelnen Client (NFS) Applikation gebunden an IP 114

115 9: Erstellen von redundanten Netzen Interface trunking mehrere Interfaces zusammennehmen Switch muss dies unterstützen (+) Last-Verteilung (+) Schutz vor kaputten Kabeln 115

116 9: Erstellen von redundanten Netzen Konfiguration von mehreren Netzwerken Achtung: Last Problem bei Failover einzelne Netze werden auch Rails (Schienen) genannt asymmetrisch: hot-standby möglicherweise ist's notwendig sicherzustellen, dass alle Hosts gleichzeitig das Netz wechseln Router Konfiguration wird (mit oder ohne verschiedene IP Adressen) komplizierter Failover: Multihoming, DNS Problem, nur virtuelle IP Adresse/ Netz wechselt auf neues Netz bedingt auch Route-Failover von Client 116

117 9: Erstellen von redundanten Netzen IP Routing Redundanz RIP update: 30s TCP sind Routen egal: - jedoch Time-Out (2h) - Switch-Over während Verbindungsphase -> Fehler - temporär asymmetrische Routen Netzwerke mit nur einem Ausgang vermeiden mehr als eine default Route dynamische Umleitung (ICMP redirect) ist gut automatische Failovers mit Scripts: - Ausfall erkennen und Routen ändern redundante Router mit VRRP - Master/Slave Konfiguration von Routern - Failover übernimmt IP, wenn Master ausfällt 117

118 9: Erstellen von redundanten Netzen die Wahl des Failover Mechanismus automatisches Failover -> alle Hosts müssen gleichzeitig ins andere Netz wechseln teilweises Failover -> Chaos wenn Kontrolle an einem Punkt konzentriert ist -> automatisieren sobald viel koordiniert werden muss -> manuell MTTR? 24 * 7 SA

119 9: Load Balancing & Umleitung Round-Robin DNS Hostname/IP TTL klein behalten (+) skaliert gut (+) einfach (-) immer noch Failover Zeit (DNS timeout) (-) mehr DNS Verkehr (-) funktioniert nicht perfekt mit diversen Clients (DNS caching etc.) IP Redirection Zustandsinfo? Teilweise dienen Loadbalancer als TCP Proxies NAT/LB http 119

120 9: Netzwerk Zuverlässigkeit interessante Daten sind üblicherweise: - dynamisch (Aktienkurse etc.) - und/oder persistent (Lohndatenbank,...) normalerweise werden viele low-level Dienste verwendet: - DNS, Directory, RPC, NFS,... - eher Informations- als Transaktionsdienste - oft mit eingebauter Redundanz Netzwerk Dienst Abhängigkeiten login: - auth: /etc/passwd, LDAP, NIS,... - Session Schlüssel von Kerberos holen - NFS mount /home/user - Quota checken - init Script 120

121 9: Netzwerk Zuverlässigkeit Netzwerk Dienst Abhängigkeiten (ff) Abhängigkeits-Graph muss azyklisch sein ansonsten Deadly-Embrace Dienste an der Wurzel sollten repliziert & verfügbar sein sollten gut überwacht werden Ressourcen auf diese konzentrieren SPOF entfernen Überwachungs-Werkzeuge sollten stand-alone sein: - route -n 121

122 9: Netzwerk Zuverlässigkeit Zentrale Dienste härten nie nur einen Server haben (Master/Slave für DNS...) sollten nahe bei Clients stehen in /etc/resolv.conf mehrere Server eintragen Failover-Plan entwerfen: /etc/hosts im Falle einer Katastrophe verwenden Änderungs-Management und Prozesse Netz-Topologie Änderungen können Netzwerk spalten! 122

123 9: Netzwerk Zuverlässigkeit die wichtigen Punkte mehrere Verbindungen zum gleichen Netz oder zu verschiedenen Netzen asymmetrisch oder symmetrisch Kosten und Komplexität abwägen, da alle Systeme davon betroffen sind manueller Failover? fundamentale Netzwerk-Dienste müssen zuverlässig sein 123

124 10: Datenzenter & Lokale Umgebung Datenzenter zentralisierte Ressourcen: (+) Stromversorgung (+) USV (+) Sicherheit (+) erhöhte Böden (+) Klima (-) beschränkter Platz (-) SPOF (-) zu viel physische Sicherheit (-) Umbau->Problem (Staub,...) 124

125 10: Datenzenter & Lokale Umgebung Datenzenter Racks (+) sauber organisiert (+) Sicherheit (+) Strom zentral (+) Kühlung (+) effiziente Raumausnutzung (-) Umbau schwierig (-) Kabelsalat (zusammengebundene Käbel) (-) Rack kann zusammen/umfallen (-) andere SAs leihen sich Teile aus (-) Cola drüberleeren 125

126 10: Datenzenter & Lokale Umgebung Cluster in einem Rack Rack kaput Cluster kaput? Sicherheit & Zugang einfacher Zugang -> kurze MTTR -> jeder kann reinlaufen und... Hosting Outsourcen Sicherheit physisch/datentechnisch (Käbel) übergreifen von Problemen anderer (Feuer, Strom,...) weit entfernt -> MTTR? Infrastruktur OK (Kühlung, Strom,...) Firma macht zu? 126

127 10: Datenzenter & Lokale Umgebung Elektrizität SPOF USV dimensionieren: - geht auch aus: kontrollierter Shutdown Generatoren brauchen (Reserve-)Treibstoff Käbel beschriften Käbel anbinden -> MTTR geht runter -> Systeme können nicht verschoben werden -> Kabelbrüche Käbel entfernen, die nicht gebraucht werden verschiedene Kanäle für doppelte Leitungen 127

128 10: Datenzenter & Lokale Umgebung Kühlung und Umwelteinflüsse Temperaturüberwachung mit Eskalation Systeme sollten sich abschalten Backup Lüfter Wasser, Feuchtigkeit: Detektoren -> Eskalation Feuer... Namenswahl einfach zu behalten systematisch oder aus gleichem Zusammenhang einfach zu buchstabieren 128

129 10: Datenzenter & Lokale Umgebung die wichtigsten Punkte Datenzenter und Racks sind gut, aber kein Allheilmittel Käbel beschriften einfache Namen wählen Kühlung & Sicherheit können genau so wichtig sein wie Spiegelung 129

130 10: Datenzenter & Lokale Umgebung Heisser Sommer 2003 Uni-Fr Server fingen an quer durch Datenzenter auszusteigen ausgelegt für erwartete Temperaturen für Typ von Server-Hardware 130

131 11: Menschen & Prozesse weichere Bereiche: - Prozesse - Menschen Unterhalt (Änderungen!) sollte kleinst möglichen Einfluss auf System haben 131

132 11: Menschen & Prozesse Unterhaltspläne und Prozesse Unterhalt mit Hilfe von Failover durchführen HA macht alles komplizierter: - SCSI Kette darf nicht unterbrochen werden immer: - schlimmsten Fall einplanen - nie Änderung durchführen ohne Plan für Wiederherstellung des alten Zustandes zu haben - evtl. zweites System haben, aus dem man Teile entleihen könnten, im Falle, dass was kaput geht - Peer Review - Folgen auf Umgebung bedenken 132

133 11: Menschen & Prozesse System-Änderungen Unordnung steigt Änderung ist eine Konstante alle Änderungen dokumentieren: - wer, wann, was, warum eine Änderung auf's Mal Verteilung von Dateien automatisieren Änderungs-Management Änderungen des FS im Auge behalten (Tripwire) Alles Testen SW Patches vorsichtig, Schritt nach Schritt nur wenn nötig zuerst rumhören 133

134 11: Menschen & Prozesse Ersatzteil Regelung Teile die am häufigsten ausfallen auf Lager halten: - HDs, Lüfter, Netzteile Teile die am schwersten zu beschaffen sind auf Lager halten Ersatzteile testen, sobald sie ankommen Inventar rotieren Einfacher Zugriff vs Sicherheit Anzahl der Hersteller und Modelle beschränken merherere Zulieferer 134

135 11: Menschen & Prozesse Präventiver Unterhalt HW wird krank bevor sie stirbt: - Logs, Fehlermeldungen VERITAS Lookout für Sun, NT,... Zulieferer gutes Verhältnis mit Zulieferer: haben viel Know How Training und Beratung nutzen! 135

136 11: Menschen & Prozesse wichtige Zulieferer wählen Wettbewerb zwischen Zulieferern fördern: - fair bleiben Rumhören, was Leute sagen - mit Referenzen reden Support austesten: - kommen die Informationen zu einem oder muss man bohren breite Produktepalette mit wem arbeitet Zulieferer zusammen? in Zukunft schauen Cross-Platform Unterstützung bei Zulieferer bleiben Anzahl Zulieferer beschränken 136

137 11: Menschen & Prozesse Zulieferer und Systemwiederherstellung HW: - vor Ort Service - Ersatzteile - Ursachenanalyse SW: - Bug Fixes - Zeit um Probleme zu beheben - Integration Eskalation Management des Kundendienstes kennen Eskalationsprozess kennen 137

138 11: Menschen & Prozesse Verkäufer Integration unterstützen Zulieferer die existierende/geplante Konfiguration? wen zuerst anrufen? 138

139 11: Menschen & Prozesse Sicherheit Leute gut behandeln FW Verschlüsselung starke Passwörter Passörter schützen, nicht an Dritte geben Administrativen Zugang beschränken kein root Login Auditing ermöglichen kritische Passwörter an mehreren Orten (Hirnen) lagern ist der Ort selbst sicher? 139

140 11: Menschen & Prozesse Dokumentation Einarbeiten von neuen Leuten Details, Konzepte SA: Rechtfertigung Doku: - bei Krise - wie, was, wo: Applikationen, Services - Standards, Abhängigkeiten, Anforderungen - wie neue Server, Services, Clients - Monitoring - Netzlayout - Geschichte Sicherheit: Doku ist nicht für jeden 140

141 11: Menschen & Prozesse Funktionen von SA Backup Ingenieur Evaluation von HW/SW HW Ingenieur SW Entwickler Helpdesk muss Benutzer verstehen Sicherheitsexperte Technischer Author Q & A Ingenieur Technischer Trainer Kommunikation mit Benutzer (schlechte Neuigkeiten) Komm. mit Management flexibel 141

142 11: Menschen & Prozesse Funktionen von SA (ff) SAs zufriedenstellen -> Freiheiten Verantwortung geben kein Micromanagement 142

143 11: Menschen & Prozesse Interne Eskalation 24*7 Vertreter entfernter Zugriff Schlüssel und Zugangstokens... Trouble Tickets die wichtigsten Punkte schlechte Doku, Ausbildung, Tests sind mindestens so schlimm wie schlechte Technologie Verhältnis zu Zulieferern SAs sind wichtig Sicherheit 143

144 12: Klienten & Konsumenten Clients sitzen zwischen Datenzenter & Applikation keine Clients -> keine Verfügbarkeit Arbeitsannahme, dass Applikationen nicht selbst HA sind, sich aus der Sicht des Benutzer bestmöglich verhalten sollen 144

145 12: Klienten & Konsumenten Härten von Clients zwei Arten von Clients: - in eigenem Netz (kontrollierte) - öffentliche/internet (nicht kontrollierte) Elimination von Clients als SPOF Wiederherstellung eines Clients 145

146 12: Klienten & Konsumenten Client Backup PCs mit grossen Disks sind zum grössten SPOF für Verlust von Daten geworden Lösungen: - über Netzwerk-Verzeichnis synchronizieren - Netzwerk-Verzeichnis als default-verzeichnis konfigurieren - Box für wichtige Dokumente (sammt Restore) - öffentliche Docking Stationen mit Backup Laufwerken - automatische Backups bei Wiederanschluss - intelligent, kopieren nicht alles 146

147 12: Klienten & Konsumenten Client Herstellung im Falle, dass ein Client ausfällt sollte Ersatz da sein Ausfälle: - HW - Virus - Benutzer konfiguriert seinen Client um -... automatische Herstellung von Clients: - wichtige Apps - System - wichtige Configs, Bookmarks etc. Thin Clients können sehr effizient sein Server muss redundant sein Applikationen müssen Failover überstehen 147

148 12: Klienten & Konsumenten Tolerieren von Daten-Service Ausfällen für einen Client sieht ein Failover wie ein Reboot aus meiste DB Applikationen verbinden neu, Rollforward File Server Client Wiederherstellung: NFS Soft Mounts per default: hard -> nochmals versuchen Daten-Integrität sollte Vorrang haben soft mount gibt Null-Daten zurück wenn App nicht sorgfältig programmiert! kann korrumpierte Daten zur Folge haben 148

149 12: Klienten & Konsumenten Automounter Tricks automounter kann über mehrere Server Lastausgleich machen (nur Sun?) wenn Server abstürzt, während ein Client ein FS gemounted hat -> blockiert Windows File Sharing ähnelt NFS Soft mounts 149

150 12: Klienten & Konsumenten Datenbank Applikations-Wiederherstellung Transaktionen einfacher als NFS Wiederverbinden (Transaktionen überprüfen, Authentifizierung) Fehler überprüfen! Timeouts/Dead-Man Timer Suchpfade (IPs) für Client 150

151 12: Klienten & Konsumenten Web Client Wiederherstellung stop, reload Formulare -> Browser fragt, ob er Seite nochmal senden sollte -> Zustand in DB SSL reconnect oder Frontend SSL Loadbalancing Server 151

152 12: Klienten & Konsumenten die wichtigsten Punkte sicherstellen, dass es Client Maschinen hat, wenn gebraucht PCs können schnell, lokale, wichtige Daten verlieren -> Backup Client Systems sollten von Server Failover womöglich nicht betroffen sein 152

153 13: Applikations-Wiederherstellung was macht die Applikation, wenn ein darunterliegender Dienst versagt? welche sonstigen Sachen können innerhalb einer Applikation schief gehen? Übersicht Applikations-Wiederherstellung Applikationen können durch Failover verwirrt werden für einen Client sieht ein Failover wie ein Reboot aus: - neu verbinden - Operationen, welche in der Ausführung waren wiederholen - weitermachen 153

154 13: Applikations-Wiederherstellung Arten von Applikations-Ausfällen Server-Neustart wird nicht korrekt verarbeitet nicht-fatale oder externe Fehler - kann Server nicht finden - nicht genügend Speicher - Schreibvorgang misslingt - kann auch bei Failover passieren! Interne Speicher & Zustandsverwaltung - C bugs -> andere Sprachen verwenden -> Java etc. 154

155 13: Applikations-Wiederherstellung Arten von Applikations-Ausfällen logische Fehler - Loops - App hängt sich auf - Deadlock - unerwarteter Input - unerwartete Antworten Leute aus allen Sparten zusammenbringen und auf Ziel % Verfügbarkeit ausrichten 155

156 13: Applikations-Wiederherstellung Techniken für Applikations-Wiederherstellung frühzeitige Erkennung beugt Schaden vor wie reagieren? Kosten-Zeit-Gewinn abwägen Erkennen & Wiederversuchen -> Promt Abort, Retry, Fail sanftes Herunterfahren: - Daten in konsistentem Zustand hinterlassen - den Benutzer darüber informieren: - was passiert ist - wie weiter crash, burn, restart von checkpoint starten an nächste Instanz eskalieren -> menschliche Interaktion 156

157 13: Applikations-Wiederherstellung sanftere Ausfälle Problem automatisch an Helpdesk melden versuchen alles konsistent zu verlassen und aufzuräumen nützliche Fehlermeldung ausgeben 157

158 13: Applikations-Wiederherstellung Applikations-Wiederherstellung nach FS Ausfall z.b. volle Disk, etc. Kein Virtueller Speicher mehr mallocs überprüfen aber auch: - keine neuen Prozesse erstellen möglich - keine neuen Sockets/Files können geöffnet werden - Systemaufrufe schlagen fehl (EAGAIN) problematischen Prozess killen neustarten (Forkbomben) 158

159 13: Applikations-Wiederherstellung E/A Fehler normalerweise von RAID abgefangen asynchrones Schreiben -> sync durchführen evtl. sanft runterfahren kein Checkpoint? 159

160 13: Applikations-Wiederherstellung Wiederverbinden mit der DB eine gute Applikation wird neu verbinden Transaktion wiederholen - evtl. Überprüfen, ob Transaktion angekommen ist -> Benutzer Interaktion! Probleme: - Client crasht, wenn keine Verbindung mehr da ist - Benutzer muss neu einloggen - komisches Schweigen der Applikation -> Feedback! 160

161 13: Applikations-Wiederherstellung Netzwerk Probleme Netzwerkprobleme sollten kurzlebig sein: -> warten und nochmals probieren Netzwerk Dienste neustarten SO_REUSEADDR: - späterer Prozess kann Socket wiederverwenden, wenn App gecrasht ist TCP Timeouts tunen: - close wait per default 2h - keepalive 161

162 13: Applikations-Wiederherstellung Interne Applikationsfehler Array Index Overflow Null Pointer nicht initializierte Pointer Buffer Overflow Speicherlecks Speicherzugriffsfehler -> Logischer Fehler -> Speicherleck -> Korrupte Daten 162

163 13: Applikations-Wiederherstellung Speicher Korruption und Wiederherstellung SIGSEGV verarbeiten: - Zustand rausschreiben - bei Checkpoint neustarten interne Checks: -> extreme Programming, Peer Review -> Java, Constraints etc. Hängende Prozesse Loop Deadlock Heartbeat auf Applikationsebene mit Failover verschiedene Locking Mechanismen nicht mischen 163

164 13: Applikations-Wiederherstellung Entwickler Hygiene Rückgabewerte überprüfen: - Schreibzugriffe sind gebuffert -> Fehler kommt erst nach nächstem Schreibzugriff - close gibt letzten Fehler zurück Grenzbedingungen prüfen: - Eingaben prüfen - Test-Werkzeuge verwenden - Test-Fälle logische Wert-Prüfung - Busines Logic 164

165 13: Applikations-Wiederherstellung Entwickler Hygiene (ff) Logging Unterstützung - Logs klar verständlich machen (durch Menschen lesbar) - Zeitstempel - nicht zu viele Logs 165

166 13: Applikations-Wiederherstellung: Prozesse Redundante Dienst-Prozesse Multi-Prozess bzw. -Thread Server -> mehr Redundanz so wenig Zustand wie möglich ansonsten Zustand in DB Multicast von Prozess Status nützlich, wenn Applikation Transaktions-Zustand im Hauptspeicher behalten muss Übermittlungs-Semantik: - mindestens einmal: Applikation muss mit Duplikaten zurechtkommen - höchstens einmal - genau einmal wie sieht's mit Latenz aus bei Last? 166

167 13: Applikations-Wiederherstellung: Prozesse Checkpoints nützlich, wenn Prozesse lange laufen (Simulationen,...), damit diese neu starten können auf Applikations-Ebene core-dumps -> sollten auch Informationen über Position in Datei, Locks etc. enthalten Aufwand/Frequenz von Checkpoint abwägen Nichts annehmen, alles behandeln vorsicht vor schnellen Hacks 167

168 13: Applikations-Wiederherstellung die wichtigsten Punkte Applikation müssen Ausfälle von Daten-Diensten überstehen. Warten, wieder versuchen externe Bedingungen müssen verstanden, und man muss mit diesen auskommen können Prozessreplikation & Checkpointing hilf bei lange laufenden Apps sorgfältige Entwicklung 168

169 14: Daten-Dienst Zuverlässigkeit was passiert mit DB, HTTP, NFS, wenn der Server abstürzt? Network File Services für Client sehen Server- oder Netzunterbruch gleich aus: -> schickt Anfrage noch Mal RPC - rpc.mountd - FS einbinden - nfsd - Daten liefern, oft innerhalb des OS - rpc.lockd - Locking Dienst - rpcbind/portmap - Dienst auf Portnummer Abbildung 169

170 14: Daten-Dienst Zuverlässigkeit: NFS NFS Tests nullproc rpcinfo -p host - macht nichts (entspricht NOP) - zeigt registrierte Services an ping an Service bekannte Datei lesen/schreiben - achtung Cache - Locking schaltet Cache aus! - aufpassen, dass Testprozedur FMS nicht blockiert 170

171 14: Daten-Dienst Zuverlässigkeit: NFS NFS Server Einschränkungen Client wird an Fallover wieder-anbinden, falls gleiche IP/hostname/FS-Nummer NFS Failover IP/Hostnamen/Disks übernehmen Clients während Failover: - hängen (im Kernel -> kann nicht gekillt werden) - wiederholen Anfragen 5 Mal mit steigender Pause nachdem Failover da ist: alles i.o. (bedingt hard-mount!) 171

172 14: Daten-Dienst Zuverlässigkeit: NFS NFS Wiederherstellung optimieren auf Server ausschliesslich NFS laufen lassen kein Cross-mount journaled FS (fsck bei Failover) 172

173 14: Daten-Dienst Zuverlässigkeit: NFS Datei-Locking NFS & Locking vertragen sich nicht allzu gut: stateful vs stateless stateless besser, da kein Zustand wiederhergestellt werden muss NFS unterstützt nur Gentleman's Locking ( advisory ) ansonsten Client Crasht -> kein Zugang NLM: network lock manager: - Client und Server monitoren sich gegenseitig rpc.statd: - befreit Locks bei Crash einer der beiden Seiten - Client Crash -> Server löst Lock auf - Server Crash -> nach Reboot hat Client Zeitfenster um Lock neu zu setzen 173

174 14: Daten-Dienst Zuverlässigkeit: NFS Datei-Locking (ff) sicherstellen, dass Status-Information von lockd/statd auch auf geteilten Disks liegt! -> jedoch trotzdem Probleme: Benutzer entfernt gelockte Datei... nicht alle Applikationen sind Gentlemen nicht mehr gültige Datei-Handles NFS Datei Handle: - Server IP, FS ID, Inode, Inode Generationsnummer Datei entfernen, neue erstellen -> gleiche Inode Nummer! -> Applikation denkt immer noch, dass es sich um gleiche Datei 174

175 14: Daten-Dienst Zuverlässigkeit: DB DB Server ACID: - Atomic (entweder ganz oder gar nicht) - Consistent - Independent (Transaktionen beeinflussen sich nicht) - Durable (auch nach Absturz OK) Wiederherstellungszeit im Griff haben was passiert bei Failover? 175

176 14: Daten-Dienst Zuverlässigkeit: DB Datenbank Überwachung sicherstellen, dass es sich um Ausfall und nicht Verzögerung handelt (aufwändige OP im Gang) SQL Anfragen Caching... Datenbank Neustarts 1. Disks rübernehmen 2. evtl. FS checken (raw/cooked) 3. DB neustarten bei Log-basierten FS wird 2 Mal gecheckt (FS, DB Log) was passiert, wenn Diskplatz aufgebraucht wird (z.b. durch core-dump der Applikation) 176

177 14: Daten-Dienst Zuverlässigkeit: DB Sicherheit und Geschwindigkeit Log-Grösse vs Geschwindigkeit vs DB-replay Grösse von Transaktionen und Checkpoints grosse vs kleine Transaktionen: - klein -> Zustand in Client -> Client crasht? Checkpoints -> Logs in DB schreiben 177

178 14: Daten-Dienst Zuverlässigkeit: DB Parallele Datenbanken mehrere DB Engines auf geteilten Disks oder auf shared nothing verteilter Lock Manager: - koordiniert Inserts etc. DB muss Logreplay machen auf gecrashter DB -> log ist weg // DBs schreiben langsamer 178

179 14: Daten-Dienst Zuverlässigkeit Redundanz und Verfügbarkeit Mehrere unabhängige Server-Instanzen ohne gemeinsame Zustandsinformation: - Haufen von Maschinen Mehrere Instanzen mit wenig gemeinsamem Zustand - Kopieren von Zustand von Speicher zu Speicher Disk-basierter gemeinsamer Zustand - klassische Cluster Tief oder Breit? hohe Leistung & HA: - auf grosser Maschine oder auf vielen kleinen Boxen 179

180 14: Daten-Dienst Zuverlässigkeit: Web Grosse Code-Pfad-Verhältnis Regel Userspace vs Kernelspace 1. ist Zustandsinformation involviert? -> speichern auf einer Instanz -> grosse Maschine: Zustand ist schwer zu verteilen 2. sind Clients Server-agnostisch? -> breit 3. Code Pfad-Verhältnis nahe bei 0? - d.h. Ausführungspfad ist fast nur im OS (Kernel) -> OS ist Flaschenhals -> mehr Maschinen (breit) 180

181 14: Daten-Dienst Zuverlässigkeit: Web Web Server: Bedingungen für HA sollte einziger Service auf Maschine sein CGIs, welche mit DBs reden sind Clients CGI muss im Stande sein neuzustarten nach einem Ausfall Web Server Farmen NFS Fileserver Backend Load balancing oder TCP Reverse-Proxies die auf gesunden Webserver umschalten Failover Zeit shared nothing Zustand kann z.b. in URL gespeichert werden 181

182 14: Daten-Dienst Zuverlässigkeit: Web Applikations-Server Zustand kann gespeichert werden in: - URL - Cookie - Backend-DB - kann zwischen Servern ausgetauscht werden Weitere Stufen Verzeichnis Server DB Backends Web Services 182

183 14: Daten-Dienst Zuverlässigkeit: Web die wichtigsten Punkte darauf achten wie sich Applikationen während der Wiederherstellung verhalten: - einige Daten-Dienste (DB) beeinträchtigen die Applikation bei Failover - einige brauchen konsistente Konfigurations-Infotmationen (NFS) Zuverläsigkeit heisst nicht immer Cluster: - je nach zu erhaltenden Zustandsinformationen -> andere Architekturen 183

184 15: Lokales Clustering und Failover zweiter Server als Backup/Fallback 184

185 15: Über Server Fehler & Failover manchmal geht es sehr lange bis Fehler diagnostiziert wird (Stunden, Tage...) HW ersetzen, Datenkonsistenz wiederherstellen, neustarten dazwischen Failover: Migration von Diensten von einer Maschine auf eine andere 185

186 15: Über Server Fehler & Failover Failover (Migration von Diensten von einer Maschine auf eine andere) muss folgende Kriterien erfüllen: Transparent - Failover sollte für Client nicht schwerwiegender als Server Reboot sein - erneutes Login möglich aber nur bei Diensten, die's verlangen (z.b. DBs, aber nicht unbedingt Fileserver) Schnell - ideal nicht länger als 5 min, besser 2 min - idealerweise Übernahme-Server schon gebootet - cold boot Failover lohnenswert? -> u.u. muss FS gecheckt werden

187 15: Über Server Fehler & Failover Kriterien für Failover (ff): Garantierter Datenzugriff - Failover sollte gleiche Daten sehen wie Original - Datenreplikation fügt eine Komplexitätsstufe hinzu Systeme in einer Failover Konfiguration sollten miteinander dauernd in Kontakt stehen, damit jedes den Zustand des anderen kennt -> Heartbeat 187

188 15: Über Server Fehler & Failover Bei einem Failover müssen drei kritische Elemente vom nicht mehr funktionierenden Server zum Takeover Server hinüberwechseln: 1. Netzwerk Identität: - IPs - evtl. MAC Adressen 2. Zugriff auf geteilte Festplatten - OSe & FSe erlauben nicht, dass mehrere Server gleichzeitig auf geteilte Festplatten zuzugreifen - logischer Zugriff muss auf einen Server beschränkt bleiben - bei Failover muss die Rolle der Server vertauscht werden 188

189 15: Über Server Fehler & Failover 3. Dienst-Prozesse - sobald Disks zum Failover Server gewechselt haben müssen alle Prozesse, die auf die Daten zugreifen neugestartet werden. Datenkonsistenz aus der Perspektive der Applikation muss sichergestellt werden. Diese 3 Elemente zusammen werden als Service Group bezeichnet. Wenn auf einem Server mehrere Service Groups existieren müssen diese vollständig unabhängig voneinander sein, damit sie auf einer beliebigen Maschine im Cluster weiterexistieren können. 189

190 15: Logische, Applikations-zentrierte Denkweise andere Herangehensweise an IT die tiefste Ebene der IT Stacks ist nicht mehr der Server, sondern die Applikation Applikationen sind mit Netzwerkidentitäten, persistentem Speicher und Rechenressourcen assoziiert Cluster dienen als Black Boxes, die einen bestimmten Dienst zur Verfügung stellen 190

191 15: Bedingungen an Failover-Lösungen Server soweit als möglich identische Konfiguration Netzwerke ein (besser: ein Paar unabhängige) Heartbeat Netzwerk(e) ein Dienst-Netzwerk ( public Network ) ein Administrations-Netzwerk 191

192 15: Bedingungen an Failover-Lösungen Festplatten interne Disks -> OS etc. geteilte Disks mit Applikationsdaten - migrieren zwischen Haupt- und Fallback Server hin und her - erreichbar von beiden Servern aus, Zugriff jedoch nur von einem Server aus - werden auch public Disks genannt manchmal shared nothing -> Replikation -> komplexer - OK für WAN Failover - NOK für lokales Failover Applikationsportabilität 192

193 15: Bedingungen an Server sollten gleich oder ähnliche sein (HW, SW,...) + bringt viele Vorteile mit sich + achtung: kleine Unterschiede (andere CPU, RAM...) Failover zwischen inkompatiblen Servern Failover Management System (FMS) muss kompatibel sein Applikation und Datenformate müssen kompatibel sein Netzanbindung kompatibel Disks kompatibel (low-level bis FS) Administration sehr erschwert: identische Konfiguration auf beiden Servern Support erschwert (der andere ist schuld) 193

194 15: Bedingungen an Netzwerke Heartbeat ping, jedoch auch komplexer über beliebiges Medium serielle Verbindung aufgrund von hohen Latenzen nicht empfohlen (?) 194

195 15: Bedingungen an Netzwerke wenn Heartbeat unterbricht: Primärer Server ist unten Heartbeat NIC ist kaput -> Fallback NIC/Netz - Achtung: NIC mit zwei Ausgängen... Heartbeat Kabel kaput Hearbeat Netzüberlast -> anzahl Server auf Hearbeat Netz beschränken Hub kaputt Heartbeat Prozess kaputt -> Heartbeat überwachen und neustarten anderer Server überlastet/zu langsam - Δt gross genug wählen 195

196 15: Bedingungen an Netzwerke low-level Problem - Dienst ohne Netz == kein Dienst - es droht Datenkorruption! - FMS sollte im Stande sein anderen Server vom Netz zu nehmen (Stom abschalten) letztinstantlicher Schutz gegen falsche Positive ist der Mensch! Disk-basierte Hearbeats möglich - Kommunikation über Medium auf dem Daten sind was passiert, wenn Hearbeat unterbricht? annehmen das Gegenüber unten ist oder menschliche Intervention verlangen Problem: Split Brain - beide Server denken sie wären der Primäre Server -> Datenkorruption - Server der keinerlei Netzverbindung mehr hat sollte sich abschalten, da er keinen Dienst mehr erbringen kann 196

197 15: Bedingungen an Netzwerke Netzwerk Identität transferieren sobald Failover passiert müssen öffentliche IP und logischer Host Namen zum Takeover Server migrieren Problem: MAC-IP (ARP) Cache auf Clients Lösungsansätze: gratuitous ARP (unaufgefordertes ARP) - Server sendet unaufgefordert ein ARP Antwort Paket in dem seine IP der neuen MAC Adresse zugeordnet wird -> alle Clients die dieses Paket sehen sollten Ihre MAC-IP Tabelle anpassen MAC Adresse transferieren: - achtung: Switches: MAC-Port Mapping kann Spanning Tree Algorithmus auslösen -> Netzwerksplit

198 15: Bedingungen an Netzwerke Netzwerk Identität transferieren (ff) warten - ARP Cache Zeit tief stellen, damit Clients ASAP ein ARP für die neue MAC Adresse machen - häufiges Default 2Min! - ARP Cache 30s -> MTTR ~= 30s 198

199 15: Bedingungen an Netzwerke IP Adressen und Namen ideal wenn man IP Adressen und Namen nach Funktion auftrennt private Namen/IDs (evtl. intern in /etc/hosts) -> eigene Identität öffentliche ( public ) Namen -> assoziiert mit Dienst administrative Namen -> für Netz-/Sysadmin - kann mit privatem Namen identisch sein - jede NIC eigene Adresse 199

200 15: Bedingungen an Netzwerke Administratives Netzwerk Maschine sollte erreichbar sein -> eigene Adresse/Namen! Adresse/Namen des Servers im adm. Netzwerk sollte nicht öffentlich sein muss nicht HA sein 200

201 15: Bedingungen an Festplatten zwei Arten von Platten: private Platten,welche zu einem Server gehören geteilte Platten, welche zu einem Dienst gehören Private Platten: sollten intern gespiegelt sein können extern sein, damit MTTR kleiner ist auf beiden Servern in gleichem Zustand -> automatisierte Replikation 201

202 15: Bedingungen an Festplatten Geteilte Platten: beide Systeme brauchen physischen Zugang, doch nur eines darf die Platte nutzen RAID5 oder RAID-*1* Multipath gut Vorsicht: Caching von Daten im RAM - Schreibzugriffe - Cache ohne Batterie inakzeptabel - Cache auf Kontroller (im Gegesatz zu Arrays) ist für Failover nicht akzeptabel! 202

203 15: Bedingungen an Festplatten Geteilte Platten (ff): Dual Hosting Zugriff ist durch externe Software auf Servern geregelt spezielle HW nötig, welche dies unterstützt - nicht alle Lösungen mit allen Plattformen kompatibel Shared Nothing Datenreplikation komplizierter braucht funktionierendes Netz und funktionierenden Takeover Host jeder Schreibzugriff muss erfolgreich sein! 203

204 15: Bedingungen an Festplatten Wo kommen kritische Applikationen hin? auf geteilter Disk: + Änderung nur an einem Platz nötig - kein Rollback nach Upgrade möglich 204

205 15: Bedingungen an Festplatten Die wichtigsten Punkte alles geht Mal kaputt wichtigste Komponenten müssen zweifach vorhanden sein um Applikations-Verfügbarkeit zu maximieren muss ein zweites System für Fallback vorhanden sein sicherstellen/testen, dass es auch wirklich funktioniert IP- und Namensverteilung planen 205

206 16: Failover Management? 206