Noon2Noon Protecting Big Data Dr. Jürgen Arnold Empalis Consulting GmbH Nürnberg, 25.11.2014 Protecting Big Data using Node Replication
2 Agenda Einführung Aufgabenstellung Herangehensweise Stand Zusammenfassung
3 Agenda Einführung Aufgabenstellung Herangehensweise Stand Zusammenfassung
4 Einführung So gut wie alle Unternehmen am Markt haben mit folgenden Herausforderungen zu kämpfen: Steigende Abhängigkeit von EDV-Daten Steigende Verfügbarkeitsansprüche Steigende Datenmenge Strengere gesetzliche Vorgaben -> (teilweise) Desasterstandort mit aktuellen Daten
5 Einführung TSM bietet seit 2012 in Version 6.3 die Möglichkeit der Node Replication Sicherungsdaten ausgewählter Nodes werden zwischen TSM-Servern repliziert Sämtliche notwendigen Metadaten werden mitrepliziert Es wird das incrementel forever Konzept verfolgt Deduplication kann mit verwendet werden -> ist einen Blick wert
6 Agenda Einführung Aufgabenstellung Herangehensweise Stand Zusammenfassung
7 Aufgabenstellung Aufgrund gesetzlicher Bestimmungen muss ein Kunde seine Sicherungsdaten auslagern. Die bisher verwendeten 2 Rechenzentren erfüllen nicht alle Anforderungen Verwendete Infrastruktur Mehrere TSM-Server 6.3 2 TS3500 Libraries mit Jaguar Laufwerken Ein Librarymanager Gesamtsicherungsvolumen ca 1 PB (2*800 Bänder) Tägliche Sicherungsmenge 15-30 TB
8 Aufgabenstellung Strategie des Konzerns: Verbringung der Sicherungsdaten in einer direkt verwendbaren Form täglich in die Konzernzentrale in einem anderen europäischen Land Projektstart Anfang 2014 Projektende Ende 2014 Kein gravierender Eingriff in den Produktionsbetrieb Minimale Investition, also weiterverwenden vorhandener Infrastruktur
9 Aufgabenstellung Nachdem Node Replication seit Anfang 2013 verfügbar war wurde nach kurzen Diskussionen diese Technik als Basis für die Datenübertragung gewählt, da dies auch eine gute Voraussetzung für eventuell folgende Schritte wie active-active Sites bietet Kickoff Januar 2014
10 Agenda Einführung Aufgabenstellung Herangehensweise Stand Zusammenfassung
11 Herangehensweise Rahmenbedingungen und Annahmen Alle Daten liegen auf 3592-Bändern; also keine Dedup-pools vorhanden, es werden normale Daten repliziert Nach Informationen der IBM (Siehe Symposium) immer neuste Version verwenden, gestartet wurde mit 6.3.4.300 Erwartete Steigerung des Bedarfs CPU und Memory 50% Kalkulierte Bandbreite zur Konzernzentrale: 30GBit
12 Herangehensweise Als erstes vertraut machen mit den Prinzipien der Node Replikation Aufbau eines leeren TSM-Servers Einrichten Server2Server Verbindung Einrichtung Replication (set REPLSERVER) Definition einer Node als Test (Replstate enable) Als Test alle Daten replizieren (default) Testen mit: Replizieren der Daten, löschen, wieder replizieren
13 Herangehensweise Erste aha-erlebnisse (1/2) Servername bei Server2server muss gesetztem Servernamen entsprechen! Beim Aufräumen (remove replnode ) zeigen immer nur das Paar die kompletten Informationen (q replnode zeigt nichts, trotzdem ist remove replnode notwendig) Replication läuft mit High Priority -> killt schon mal backup Jobs Replication und Expiration behindern sich massiv
14 Herangehensweise Erste aha-erlebnisse (2/2) Die angezeigten Mengen bei den Replicate Prozessen sind schwer zu interpretieren Während der Replication zeit q sess Details, am Ende gibt es keine verwertbare Statistik Es können mit Maxsessions 1-99 Sessions pro Prozess definiert werden (10=default), die im Prinzip gut skalieren Pro filespace ist eine Session zuständig
15 Herangehensweise Erste echte Replication, node mit 15GB und 170k files Verwendet Bänder : 73 Summe mounts : 455 -> durchschnittliche Mountzahl / Band : 6,23 Laufzeit : ca 7 Stunden Durchsatz : 2GB/h Verbindung der beiden Server : 10GBit
16 Herangehensweise Vergleich mit vorherigem Move Nodedata Verwendet Bänder : 63 Summe mounts : 63 -> durchschnittliche Mountzahl / Band : 1 Laufzeit : ca 50 min Durchsatz : 2GB/h Danach replicate Node mit Daten auf Platte Laufzeit : ca 1,5 min Verbindung der beiden Server : 10GBit
17 Herangehensweise Konsequenzen: Initiale Befüllungvon Band benötigt ca. 200.000 Tape mounts;-} -> nicht wirklich eine Option Performance / Skalierbarkeit extra Thema Generell Replication robust und stabil: Hier ein Beispiel wie die Konfiguration resettet wird um eine node testweise erneut zu übertragen: tsmsrc: remove replnode testnode tsmdst: remove replnode testnode tsmdst: delete filespace testnode * tsmdst: remove node testnode tsmsrc : update node testnode replstate=enable tsmsrc: repl node testnode
18 Herangehensweise Ansatz gegen Mount-orgie Aufsetzen des Zielserver wie für eine DR-Site mit TSM DB-Backup und Tapes aus zusätzlichem Copy-Pool -> Füllen der Datenbänder pro Band und nicht pro Node oder gar pro Filespace Aussage IBM: Es funktioniert!
19 Herangehensweise Nach Einspielen des DB-Backups auf dem Zielsystem sind alle Node dort vorhanden. Dann tsmsrc: remove replnode testnode # falls noch Reste existieren tsmdst: remove replnode testnode # falls noch Reste existieren tsmdst: update node testnode replstate=enable replmode=syncrec tsmsrc : update node testnode replstate=enable replmode=syncsend tsmsrc: repl node testnode
20 Herangehensweise Nächster Punkt: Latenzen und Packet loss SLA des Providers für den Link waren 30 msec Latenz 0,01% packet-loss Durchsatz, einfache Abschätzung: TCPWindowsize = 2MB (Maximum von TSM) Jumboframes -> 1 Window = 250 Frames 10GBit -> 2MB=2msec 30msec -> 30 Windows pro Sekunde = 60MB/sec Eine Session belegt max 7% der Leitung
21 Herangehensweise Packet loss 0,01% bedeutet, dass mehrmals pro Sekunde Frames verloren gehen und dadurch das TCP Window wieder verkleinert wird. Messergebnisse mit einem WAN-Emulator (10GBit 2MB TCPWindow):
22 Herangehensweise Die gute Nachricht Die Lücken zwischen den Frames können durch zusätzliche Sessions ausgefüllt werden. Der Gesamtdurchsatz skaliert mit der Anzahl der Sessions nahezu linear Aber Eine einzelne Session ist massiv betroffen, im Speziellen Daten die von Tape kopiert werden. Kleinste Datenrate mit Tape sind 38MB = 300MBit, sonst bricht der Durchsatz wegen start/stop ein
23 Agenda Einführung Aufgabenstellung Herangehensweise Stand Zusammenfassung
24 Stand Aktueller Stand: Die Verfahren und Prinzipien sind getestet Alle Systeme sind auf dem neusten TSM-Stand (mit vielen Problemen) Die Hardware im Zielrechenzentrum ist aufgebaut Der 30GBit Link ist seit 3 Wochen in Betrieb Als initial Load wird das Einspielen eines DB-Backup verwendet Die entsprechenden copy-pools sind seit Juli am Füllen und inzwischen aktuell
25 Stand Aktueller Stand: Die Verfahren wurden für die Replication erweitert Die ersten Server wurden aufgebaut und bereits in die Replikation genommen Die initial Sync phase ist erfreulich schnell durchgelaufen mit Abgleich von 100.000 Files pro Minute Die Daten fließen im Moment wie erwartet
26 Agenda Einführung Aufgabenstellung Herangehensweise Stand Zusammenfassung
27 Zusammenfassung Die Performance-zuwächse seit den ersten Tests mit 6.3.4 sind spürbar Ein initial Load mit DR-Verfahren funktioniert Der Zuwachs an Load ist bisher niedriger als erwartet Die Replizierung an sich läuft robust und stabil Latenzen müssen sehr genau berücksichtigt werden (WAN-Beschleuniger in der pipeline) Node replication ist erwachsen geworden Auch wenn es noch einige Themen gibt wie Client type Server
28 Dr. Jürgen Arnold Senior Consultant Empalis GmbH Wankelstraße 14 70563 Stuttgart Tel. +49 711 469282 60 Fax. +49 711 469282 39 Cel. +49 172 4033254 juergen.arnold@empalis.com www.empalis.com