Nach dem BDA CAS Abschluss an der HSLU im Frühling 2017 können wir neben den Praxis-Erfahrungen auch theoretisches Grundwissen im BDA (Big Data Analytics) Umfeld vorweisen.

Hadoop HDFS Backup und Desaster Revocery

Obwohl wir im Hadoop HDFS Umfeld immer von Cluster Plattformen (Datenverteilung auf mehrere Server- und Disk-Knoten) ausgehen, darf das Thema Datensicherung nicht als unnötig abgestempelt werden. Sobald geschäftskritische Daten im HDFS gespeichert bzw. Geschäftsprozesse abhängig sind von auf HDFS gespeicherten Daten und Funktionen, muss auch ein HDFS Cluster-System in die firmenweite Backuppolicy integriert und entsprechend gesichert werden, wobei der Fokus auf Restore und Recovery / Wiederherstellung zu setzen ist. 

Weitere Treiber sind das neue Bundesgesetz über den Datenschutz (im 2017 noch nicht in Kraft) und die neue EU-Datenschutz-Grundverordnung (GDPR), also der Zusatzfokus auf Compliance und Datenschutz.

Was macht HDFS anders?

Betrachtet man die Speicherschicht fällt auf, dass man via HDFS die verteilten Aufgaben mit minimaler Latenzzeit ausführen möchte, was mit der Ausführung von Map-Verarbeitung auf Knoten erreicht wird, die die Daten speichern (Data Locality Concept). HDFS-Implementierungen benutzen meistens direkt mit dem Clusterknoten verbundene SATA-Festplatten, um neben der Latenz- auch eine Kosten-minimierung zu erreichen.

HDFS Grundlagen in Bezug auf Sicherheit:

  • Blockreplikation
  • Datenknoten

HDFS-Instanzen bestehen aus den zwei Komponenten NameNode und DataNodes. Der NameNode enthält Metadaten die den physikalischen Aufenthaltsort der Daten innerhalb der Hadoop -Instanz Adressieren. Die eigentlichen Daten werden auf den DataNodes gespeichert.

Hadoop ist in Bezug auf Backup nicht viel anders als sonstige Business-Applikationen, ausser der sehr grossen Datenmengen (Terabytes bis Petabytes), der verwendeten Commodity Hardware, der verteilten Architektur (Cluster) und der vielen unterschiedlichen Dienste bzw. Services.

Was muss gesichert werden?

Bei einer typischen Hadoop HDFS Cluster Implementierung werden die Datenblöcke aus Sicherheits- aber auch aus Performancegründen mindestens dreifach auf verschiedenen Nodes gespeichert. In grossen HDFS-Clustern werden früher oder später Komponenten (z.B. Harddisks) oder komplette Server ausfallen, daher ist die Duplizierung der Daten über die Server verteilt das Schlüssel-Design von HDFS. Trotzdem sollte der Datensicherungsfokus auf Datensätze (HDFS Daten sowie Metadaten, z.B. Hive Metadaten), Systemapplikationen wie JT, NN, Region Server und Userapplikationen sowie Konfigurationsfiles und Einstellungen gelegt werden.

Problemklassen für die Backupplanung

Es sollten die Fragen „Was passiert bei einem RZ Ausfall?“ oder "Wie kann ein konsistenter Da-tenbestand garantiert werden beim Ausfall einzelner Komponenten bzw. bei dessen Wiederherstel-lung?“ oder „Können bzw. dürfen im HDFS-Cluster gespeicherte Daten überhaupt verloren gehen?" gestellt werden. Dabei sind die Problemklassen Hardwarefehler, User- / Applikationsfehler und Standort- / RZ-Ausfall zu analysieren. Bei Hardwarefehlern meinen wir korrupte Daten auf Disk, Disk- oder gar Node-Ausfälle und Rack-Fehler. Mit User- / Applikationsfehler werden z.B. fehlerhaftes oder absichtliches Löschen von Daten oder Datenfehler beim Speichern (corrupted data writes) z.B. durch Applikationsfehler adressiert. Standort- / RZ-Ausfälle können temporäre Ausfälle z.B. Netzwerk- oder Stromunterbruch sein oder gar permanente Ausfälle von Lokationen sein, z.B. verursacht durch Feuer, Wasser oder Erdbeben.

Die Geschäftsziele dienen als Treiber der Lösung

Ergänzend zur Einhaltung der RPO und RTO SLA’s sollte über die zu schützenden Daten nachgedacht werden und die entscheidende Frage „Wie viel sind die Daten wert?“ beantwortet werden. Dabei macht eine Gegenüberstellung der Attribute Fehler, Risiko und Kosten Sinn.

Fehler / Gefahr

Risiko

Kosten

Diskfehler

hoch

klein

Knotenfehler

hoch

klein

Rackausfall

mittel

mittel

fehlerhaftes Löschen

mittel

mittel

RZ Verlust

Klein

hoch

Für eine definitive Risikobetrachtung möchten wir die wichtigsten HW Fehlermöglichkeiten etwas tiefer betrachten und dabei die standardmässig vorhandenen HDFS Funktionen analysieren.

Diskfehler können Datenkorruptionen verursachen, welche jedoch durch HDFS Automatismen wie Datenblock Metadaten Checksummenspeicherung als Datei ausserhalb des HDFS abgefangen wer-den können. Stimmt eine Checksumme nicht, verwirft der NameNode diesen Block und ersetzt ihn durch eine neue Kopie. NameNodes können mehrere Kopien der Metadaten auf unterschiedlichen Filesystemen speichern sowie Backups erstellen, um Sicherheit zu gewähren.

Disk- bzw. Knoten-Ausfälle werden durch synchrones Replizieren vor Datenverlust geschützt, indem die ersten beiden Replikate jeweils auf zwei unterschiedlichen Hosts abgelegt werden. Hardwarefehler werden im Falle eines Heartbeat Verlustes sofort bemerkt. Mit der NameNode Hochverfügbarkeits-Funktion (HA) werden Metadaten geschützt. HDFS Re-Repliziert Blöcke mit zu wenig Replikas automatisch mittels periodischen Prozessen.

Fallen mehrere Nodes aus (z.B. Rack-Ausfall), wird das dritte Replikat, welches in einem separaten Rack gespeichert ist, zum kritischen Pfad, während dem Zeitfenster vom Rack-Ausfall bis zum HW Wiederaufbau mit nachfolgendem Re-Replizieren der Datenblöcke. Durch das zur Verfügung halten von Rack-Informationen durch Nutzung von Features wie topolo-gy.node.switch.mapping.impl oder topology.script.file.name ist ein identischer Wiederaufbau der ausgefallenen Nodes rasch realisierbar, sofern die MetaDaten (z.B. Hive Sicherungen durch SQL-Backups) noch vollumfänglich verfügbar sind. Hive Metadaten, ein wiederkehrendes Thema be-züglich Daten und Metadaten Sicherung, sollten idealerweise zusammen mit den Daten gesichert werden, um die Konsistenz zwischen Daten und Metadaten gewährleisten zu können.

Die obigen Punkte und Features gewähren uns nun eigentlich die Kontrolle über die Hardware-Basis, aber die erwähnten Featrues müssen entsprechend implementiert und überwacht (Monito-ring) sein. Das Untersuchen bzw. Analysieren der Node Block-Scanner Reporte ist unerlässlich. Im Problemfall aber auch als periodische Präventive-Massnahme ist die Ausführung des HDFS fsck (File System Check Utility) zwingend. Die gängigen Hadoop Distributionen bieten Tools, z.B. der Cloudera Manager mit dessen „Heath Check“ Funktionen.

Weitere zu beachtende Problempunkte sind HDFS Upgrades, die vorsichtig zu behandeln sind, denn schon Disklayout Änderungen bergen grössere Risiken. NameNode Metadaten sollten extern aufbewahrt werden, während Upgrades auf einer Test-Cluster Umgebung ausführlich durchgespielt werden sollten bevor der HDFS-Cluster angefasst wird. Datenlayout Upgrades bieten Rollback-Mechanismen, die vorsichtig zu Nutzen sind (kenne ich die Mechanismen wirklich? Funktionieren diese Rollback-Features in jedem Fall?). Die Erstellung eines Backups aller oder zumindest wichti-ger Daten an eine externe Lokation vor einem Upgrade sollte als zwingend nötig betrachtet werden.

Applikations- oder Benutzer-Fehler als letzte zu fokussierenden Punkte beim Design einer Daten-verfügbarkeitslösung im HDFS Umfeld, wo Regeln wie die Anwendung des Prinzips „minimalste Privilegien“ angewendet werden sollten. Dabei soll der Berechtigungsumfang so eingeschränkt werden, dass Benutzer nur auf jene Daten Zugriff haben, welche sie zwingend benötigen. Mittels Quoten-Management sollten die Anzahl Files pro Verzeichnis limitiert (Beziehungsquoten) sowie der Speicherplatz pro Verzeichnis (Platzquoten) begrenzt werden. Das Schützen vor ungewolltem Löschen kann durch Aktivierung des HDFS Trash-Server (Papierkorb für gelöschte Dateien) und mittels regelmässigen SQL Backups (Metadatensicherung) realisiert werden.

Zusätzlichen Schutz bieten kontrolliert verwendete HDFS SnapShots, was jedoch eine entspre-chende Konzipierung (Frequenz, Retention, benötigter Platz, Performance-Einbussen, Konsistenz, Restore-Zeit, etc.) bedingt. Vorteile und somit Anwendungsmöglichkeiten von HDFS SnapShots sind die Behandlung von User- und Applikations-Korruptionen, das Vorbeugen von unbeabsichtig-tem Löschen sowie die Nutzung von SnapShots zu Test- und Entwicklungszwecken. Auch Apache HBase bietet SnapShot Möglichkeiten, welche ähnlich wie HDFS SnapShots funktionie-ren, jedoch COW Methode (copy-on-write) im Gegensatz zur PIT Methode (read-only point-in-time copies) bei HDFS SnapShots verwenden. Die Verwaltung von SnapShots muss Überlegungen wie „Wie viel % des Cluster Diskplatzes sind für SnapShots frei zu halten?“, was neben den effek-tiven Datenblockupdates während der SnapShot-Dauer auch durch die Anzahl SnapShots sowie dessen Aufbewahrungszeiten beeinflusst wird. Ein automatisches Diskplatz Monitoring mit Alert-ing ist in diesem Zusammenhang unverzichtbar. Das Backup- bzw. SnapShotscheduling hat also Zeitgesteuert und/oder Workflowbasiert und somit vollumfänglich beaufsichtigt zu erfolgen.

Disaster Recovery

Big Data Plattformen sind vielfältig, skalieren und beherbergen oft Petabytes an unstrukturierten (z.B. HDFS mit Files, Videos, Images), halbstrukturierten (semi-structured, z.B. HBase, Casandra Couchbase, mongoDB) oder strukturierten (z.B. Hive, Impala, TEZ, Vertica, Pivotal) Daten. Diese Daten sollten analog der übrigen Business-Daten wenn möglich über mehrere Standorte verteilt und in Clusters redundant abgelegt werden, um Datenverlust im DR Fall zu verhindern.

Im HDFS Umfeld spricht man von den beiden Varianten Cluster Splitten (teeing) versus Kopieren / Replizieren:

Cluster Splitten (teeing)

Kopieren (copying)

Doppeltes Datenspeichern beim Laden (ingestion) im primären und sekundären Cluster

Daten werden in den primären Cluster geladen und nach dem Prozessieren / Aufbereiten als separate Task zum sekundären Cluster repliziert

Minimale Zeitverzögerung zwischen den Clustern, aber entsprechende Bandbreite nötig

Datenkonsistenz zwischen beiden Seiten, aber nur ein Prozessieren / Aufbereiten (Ressourceneinsparungen)

Bedingt ein Daten-Wiederaufbereiten auf beiden Seiten, somit keine Konsistenz zwischen den beiden Lokationen

Höhere Wartezeit für RPO Ziele , da inkrementelle Kopien nötig sind, was entsprechende Bandbreiten voraussetzt

Hadoop HDFS Replikation für DR kann mittels der zwei unterschiedlichen Methoden Y-Replikation (Teeing) oder L-Replikation (Copying) betrieben werden. Beim Y-Replizieren werden die Daten beim Laden (Ingestion) auf den primären sowie auf den sekundären HDFS-Cluster ge-speichert. Für ein solches Doppel-Laden (double ingestion) eignet sich NiFi. Die Rohdaten sind sofort auf beiden Cluster verfügbar, das Prozessieren / Verarbeiten hat entsprechend auf beiden Cluster zu erfolgen. Bei der L-Replikation erfolgt das Datenladen nur zum primären Cluster wäh-rend das Replizieren während / nach dem Prozessieren z.B. mit Tools Distcp oder Falcon erfolgt. Der sekundäre Cluster hinkt also jeweils dem primären Cluster hinterher, was beim Workflow zu berücksichtigen ist, und entsprechende Vor- wie auch Nachteile mit sich bringt.

Für diese HDFS Replikationsproblematik existieren verschiedenste Tools wie WANDisco Fusion, Oozie DiskCP, Apache Falcon DR oder Kafka MirrorMaker , die meisten kostenpflichtig, daher macht es Sinn, die DR Anforderungen aufzulisten und zu priorisieren sowie in „muss“ und „kann“-Kriterien einzuteilen, um dann eine Tool-Evaluation durchzuführen als Grundlange für die Entscheidung der Replikations-Methode.

Zu berücksichtigen sind bei der DR Methoden und Tool Auswahl auch erweiterte Kriterien wie die Möglichkeit unterschiedlicher Cluster- bzw. HDFS-Versionen, einheitlicher oder getrennter Ker-beros Realm (Authentifizierungsdienst zur Erhöhung der HDFS Sicherheit), Datenreplikationsfak-tor innerhalb des Clusters, vorhandene und nötige LAN Kapazitäten und Anforderungen (z.B. WAN Verschlüsselung, Latenz-Zeiten etc.) zwischen den Cluster (zwischen den Rechenzentrums-lokationen), SnapShot Aufbewahrungszeiten und somit dessen erweiterten Diskplatz-Anforderungen, IP-Adressen und Hostnamen Anforderungen (z.B. selbe Hostnamen nötig im DR-Cluster aus applikatorischen Gründen) um ein paar wichtige Bedingungen zu nennen.

Neben DR Tools sind auch Gesamtlösungen - sogenannte Data Availability Management Solutions wie jene von Talena - verfügbar. Schlussendlich werden die Betriebsressourcen- und Kosten-Aufwände die Entscheidung ebenfalls beeinflussen.

 

Zum Seitenanfang