DLm und MDL Disk Library Mainframe - Mainframe Data Library. VTL Lösungen für Mainframes

Transkript

1 Müssen Tapes immer ½ Zoll breit und 1 Km lang sein? DLm und MDL Disk Library Mainframe - Mainframe Data Library VTL Lösungen für Mainframes z/os Guide-Tagung Lahnstein bis

2 Agenda History Bandverarbeitungsszenarien DLm/MDL Vorstellung - Übersicht und Funktionsweise DLm/MDL Produktfamilie Technische Aspekte Einsatz-Szenarien und Kundenkonfigurationen Fragenkatalog Unsere Projektvorgehensweise 11. Oktober 2012 Seite 2

3 Oktober VTL Lösung gesucht 1. Kapazitätsbedarf < 10 TB nach Kompression % Virtualisierung 3. z/vm, z/vse und Linux for System z muss unterstützt sein, optional z/os 4. Keine JCL Änderungen, keine organisatorischen Änderungen 5. Keine Softwarelösung mit Abhängigkeiten zu Releasewechseln im Betriebssystem 6. Integration in eine Drittsicherung auf reales Tape 7. 2 Standort Konzept alle Daten sind doppelt zu halten 8. Übertragung zum Sekundärstandort muss TCP/IP sein kein ESCON oder FICON vorhanden 9. Geringer Ressourcenbedarf (Platz, Energie, Kühlung) 10. Kostengünstiger als VTS, VSM, CentricStor 11. Oktober 2012 Seite 3

4 Über mainstorconcept IT Systemhaus für Betriebssystem und Infrastruktur Technologien System Management Services für Mainframe- und Storage-Systeme 15 Mitarbeiter mit Focus auf Mainframe Kunden und Storagelösungen Aufbau des Bus-Tech MAS/MDL Marktes in D-A-CH von Null an Seit 2006 mit Bus-Tech Produkten (Schwerpunkt MDL) erfolgreich im Markt mit jährlicher Steigerung Alles aus einer Hand: Presales, Sales, Consulting, Projektierung, Integration und Support Mehr als 70 Systeme verkauft, installiert und aktuell in Wartung Bus-Tech Center of Excellence in Europa (einziges CoE weltweit) Kunden aus dem z/vm, z/vse, z/os und Linux for System z Umfeld Umfangreiche Eigenentwicklungen (Software und Appliances) für MDL und DLm sowie andere Softwarelösungen für System z Internationale Projekterfahrungen in: Schweden, Slowakei, Frankreich, Belgien, Italien, Spanien, Schweiz, Österreich, Bosnien-Herzegowina 11. Oktober 2012 Seite 4

5 Historie DLm/MDL bei EMC Zusammenarbeit zwischen EMC und Bus-Tech begann 2005, EMC verkauft Bus-Tech Nodes mit Centera oder Celerra Zusammenarbeit zwischen Bus-Tech und mainstorconcept ab Ende 2006 EMC kündigt in 2007 die DLm 4080 an EMC übernimmt DataDomain Anfang 2010 und verstärkt damit die Aktivitäten im Bereich Backup und Deduplikation EMC übernimmt Bus-Tech im November 2010 EMC BRS beginnt im Januar 2011 März 2011: Integration DLm/MDL mit DataDomain Backend Deduplizierungsspeicher Ankündigung DLm6000 im September 2011 Ankündigung DLm2000 im Februar 2012 Ankündigung DLm1000 im April 2012 Ankündigung DLm8000 im September 2012 DLm2000/DLm6000/DLm Oktober 2012 Seite 5

6 Bandverarbeitungsszenarien IT-Shops mit klassischer Drive-Technologie 3480, 3490, 3590 oder 3592/TS1120/TS1130 Drives, mit und ohne Auto-Loader Daten werden direkt auf Band geschrieben Manuelles Handling je Tape bzw. je Autoloader IT-Shops mit Multi-Drive-Technologie und Library (3494, STK Powderhorn) 3490, 3590 oder 3592/TS1120/TS1130 Drives, mit Library und Gripper Daten werden direkt auf Band geschrieben Maschinelles Handling je Tape, für Desaster Recovery entweder redundante Systeme oder manuelles Handling IT-Shops mit Virtueller Drive-Technologie (VTS, TS7700, VSM, CentricStor, Luminex) 3590 oder 3592 Drives, mit Disk-Cache, angeschlossener Library und Gripper Daten werden temporär auf Plattencache geschrieben, danach optimiert auf reale Kassetten geschrieben Maschinelles Handling je Tape, eventuell Spiegelung für Desaster Recovery (synchron oder asynchron) 11. Oktober 2012 Seite 6

7 Typische Situationen beim Tape-Processing Viele Kassetten sind nicht optimal genutzt, z.b.: - 65% der Kassetten sind nur zu maximal 40% beschrieben - 15% der Kassetten sind nur zu maximal 99% beschrieben - 20% der Kassetten sind voll beschrieben und Multivolume Files In Spitzenzeiten sind zu wenig Drives vorhanden, Jobs warten auf freie Drives, daraus resultiert eine verzögerte Batch-Abwicklung und ein zu geringes Batch-Fenster Technologiewechsel auf 3592/TS1120/TS1130 organisatorisch schlecht abzubilden und teuer bei Drives und Medien (Füllgrad) Manuelles Handling erforderlich, Kassetten müssen vorgerichtet und nach der Verarbeitung wieder archiviert werden, wenn keine Library vorhanden ist. Automatische Batchabläufe sind nur eingeschränkt möglich. Duplizierung oder doppelte Sicherung bei Desaster-Recovery Auslagerung erforderlich In Time-Replikation an einen 2. Standort für Gesamtmenge oder Untermenge der Datensicherungen sehr kostenintensiv Recall Wartezeiten wenn virtuelle Tapes nicht im Cache vorhanden sind Teure Wartungskosten der mechanischen Library und der Drives, großer Bedarf an Stellflächen Anbindung noch teilweise über ESCON-Kanäle, schlechte Performance bei gleichzeitiger Nutzung mehrerer Drives 11. Oktober 2012 Seite 7

8 DLm/MDL im z/os Umfeld Virtuelle Tape Library für System z, zseries und S/390 Systeme FICON SAN NAS/NFS Backend Storage DeDup Node Konzept, 1 bis 8 Nodes Emuliert 32 bzw. 256 virtuelle Tape Drives je Node Verhält sich 1:1 transparent wie 3480, 3490 oder 3590 Anschließbar an jeden beliebigen Mainframe über FICON Kanäle Schreibt alle Tapes direkt 1:1 ohne Caching oder Backend Stacking Unterstützt HSM und SMS, sowie RMM, CA-1 und andere TMS Unterstützt z/os, OS/390, MVS und andere wie z.b. z/vm, z/vse und Linux Unterstützt LPAR Unterstützt FICON Direktoren und Switches 11. Oktober 2012 Seite 8

9 DLm/MDL Backend Speicher 100% Tapeless Lösung Flexibel in der Nutzung von Backend-Speicher Externe Fiber Channel RAID Arrays NAS/NFS Filer Virtualisierungslösungen wir z.b. SVC Speichersysteme mit Deduplizierung, Storage Tiering OpenSystem Reale Tape Libraries Integrierte Gesamtlösungen DLm2000, DLm6000, DLm Oktober 2012 Seite 9

10 DLm/MDL Funktionsweise z/os Anstatt auf eine Kassette oder auf einen Cache-Speicher schreibt die MDL Daten direkt auf Backend Storage Systeme Jede virtuelle Kassette entspricht einer Datei auf dem Filesystem Jede Datei (virtuelle Kassette) kann bis zu 256GB bei 3490 und bis zu 2TB bei 3590 groß sein, EOV wird damit fast immer vermieden Nur der effektiv benötigte Platz wird belegt Alle Volumes sind permanent online Jeder Mount wird in wenigen Millisekunden durchgeführt sowie beim Schreiben als auch beim Lesen Benötigt keine Bandverwaltung, um automatische Mounts durchzuführen Arbeitet ohne Änderungen mit den gängigen Bandverwaltungssystemen zusammen. Keine Exit-Programmierung erforderlich Stand-alone IPL möglich Keine Softwareinstallation auf dem Mainframe erforderlich 11. Oktober 2012 Seite 10

11 Speicherung im Backend Alle Informationen über den Aufbau der virtuellen Kassette sind innerhalb der virtuellen Datei gespeichert. Diese wird in einem modifizierten IBM AWSTAPE Format geschrieben. Die MDL benötigt daher keine Datenbank und keine Verwaltungs- oder Reorg-Zyklen (kein Back-End stacked Tape) Alle Files sind permanent verfügbar, es entfällt immer der physische Tape Mount und der bei virtuellen Libraries oft obligatorische Restore der physischen Kassette auf den Plattencache 11. Oktober 2012 Seite 11

12 DLm/MDL Features IDRC Komprimierung ist ein Standard-Feature der MDL. Die Speicherung im Backend erfolgt im Open Source zlib Algorithmus. Konfigurierbar je Drive oder durch Overwrite-Parameter. Verschlüsselung nach AES-256 ist ebenfalls ein Standard-Feature und kann je Drive konfiguriert werden. Die Verschlüsselung benötigt keine CPU- Zyklen, da die Verschlüsselung auf der MDL vor dem Schreiben auf den Backend-Storage erfolgt. Replikation virtueller Tapes über TCP/IP je nach Systemauslegung über integrierte Funktion oder Replikationsmodul Der optionale Back-End Tape Support ermöglicht den direkten Anschluss von Tape Drives über Fiber Channel an die MDL. Entweder als DIRECT TAPE oder alternativ als Tape IMPORT/EXPORT. Das Tape Drive ist im Betriebssystem direkt ansprechbar. 11. Oktober 2012 Seite 12

13 DLm/MDL Produktfamilie Non De-Dupe Storage Enterprise De-Dupe Storage Enterprise Kombiniert De-Dupe und Non De-Dupe Storage Enterprise DLm6000 mit DD890 DLm6000 mit VNX7500 und DD890 DLm6000 mit VNX7500 DLm8000 mit VMAX Small und Medium DLm2000 Small und Medium Small und Medium DLm1000 mit DD6xx/8xx DLm1000 / MDL-2000 mit VNXe oder VNX und DD6xx/8xx MDL-2000 mit VNXe oder VNX oder anderem Speicher 11. Oktober 2012 Seite 13

14 Produktfamilie MDL-2000 DLm1000 DLm2000 DLm6000 DLm8000 2U Racksystem 2U Racksystem Integriertes Racksystem Integriertes Racksystem Integriertes Racksystem 1 Emulation Node 1 Emulation Node 1-2 Emulation Nodes 2-6 Emulation Nodes 2-6 Emulation Nodes 256 virtuelle Drives 2 FICON Adapter max. 200 MB/s 1 Dual Gbit Ethernet 1 Dual Port FC-SAN Adapter (optional) FC Tape (optional) Externes Modem oder VPN virtuelle Drives 1-2 FICON Adapter max. 200 MB/s 2 Dual Port Gbit Ethernet Backend DataDomain Externes Modem oder VPN virtuelle Drives 1 - ACP Management Node 2-4 FICON Adapter max. 400 MB/s TB Kapazität FC Tape (optional) Internes Modem oder VPN virtuelle Drives 2 - ACP Management Nodes 4-12 FICON Adapter Max 2 GB/s bis 4,8 PB Kapazität VNX bis 5,7 PB Kapazität DD bis 5,4 PB Kapazität mixed FC Tape (optional) Internes Modem/VPN virtuelle Drives 2 - ACP Management Nodes 4-12 FICON Adapter Max 2 GB/s bis 4,8 PB Kapazität VNX bis 5,7 PB Kapazität DD bis 5,4 PB Kapazität mixed FC Tape (optional) Internes Modem/VPN 11. Oktober 2012 Seite 14

15 Backend File-System Mapping MDL/DLm Node Tape Drives Tape Drives NFS, SAN /tapelib /B0 /B1 /tapelib2 /C0 /C1 FS1 FS2 Filesystem 1 Filesystem 2 B00000 B ~B09999 B10000 ~B B19999 Filesystem 3 Filesystem 4 MDL/DLm kann eine oder mehrere virtuelle Tape Libraries emulieren Tape Volume Serial Numbers (VOLSER) sind 6 Stellen lang, jedes Tape wird als separate Datei geschrieben Scratch Tapes erkennt man an der Tilde Jederzeit erweiterbar durch einfaches Hinzufügen eines neuen Filesystems Mischung verschiedener Back-End Storage- Systeme ist möglich Einfache Migration auf neuere Backend Storage-Technologie 11. Oktober 2012 Seite 15

16 MDL/DLm Hochverfügbarkeitsoptionen 1. FICON Kanäle redundant 2. Redundante MDL/DLm Nodes (Cluster oder NFS), gleichzeitig auch Durchsatzmultiplikator 3. Mirroring auf Disk Subsystem Ebene 4. Replikationsmodul MDL/DLm oder Replikationsserver auf TCP/IP Basis bei lokal getrennten Standorten 5. Direct Tape Backup (mit Einschränkungen) auf 3590, 3592 oder LTO 6. Backup auf Kassetten (z.b. LTO, TS1130) über Standard B/R Server Applikation (TSM, Networker,Veritas, Atempo, Legato, usw.) MDL/DLm Storage System z Direct Tape 5 OpenSystem Backup Server System z FICON SAN oder NAS/NFS 6 OpenSystem Tape Library MDL Cluster MDL/DLm Storage 3 Mirror MDL/DLm Storage 11. Oktober 2012 Seite 18

17 MDL/DLm Performance M B y t e s / S e c BUFNO=10 3-to-1 Compression 3590 Emulation Tests: 1. 1 Drive, 32k 2. 1 Drive, 64k 3. 1 Drive, 256k Drives, 32k Drives, 64k Drives, 256k write read write read write read write read write read write read 1 Node 2 Nodes 3 Nodes 4 Nodes 5 Nodes 6 Node Oktober 2012 Seite 20

18 DLm/MDL Einsatzgebiete BACKUP HSM MIGRATION DATA ARCHIVE WORK TAPES 3390 DASD Volume Dumps Fixed size Volumes 3, 9, 27, and 54 GB z/os Backup Anwendungen CA Disk CA DSS IBM DB Backups. Migriert Daten zwischen verschiedenen Storage Klassen Soll den DASD Gebraucht erhalten Kann signifikante CPU Zyklen nutzen Fixierte Inhaltsdaten Check Images, etc. Variable Daten z/os führende Archiv-Anwendungen ASG-ViewDirect IBM ImagePlus Kurze Speicherung Temporäre Tapes Hohe Schreib-/Lese - Anforderungen Beispiel: Syncsort work files Transaction log files SMF data files 11. Oktober 2012 Seite 21

19 MDL Einsatzgebiete I Szenario: Der Kunde möchte alte Technologie (3480, 3490 oder 3590, ESCON Kanäle) ersetzen. Er möchte keine organisatorischen Änderungen in Abläufen. Er möchte das Batch-Fenster verkleinern und gleichzeitig das Operating entlasten. Lösung und Vorteile: Der Kunde erneuert seine Tape-Technologie auf der Basis von MDL. Er spart den Kauf neuer Hardwaretechnologie und teurer Tape-Medien. Er hat ab sofort 256 logische Laufwerke mit ausgezeichneter Performance zur Verfügung und kann dadurch Batch- Laufzeiten reduzieren. Die Systeme müssen nicht mehr im Operating stehen und können über FICON oder FC in einen anderen Brandabschnitt verlagert werden. Anmerkungen: Häufig kann ein solches Szenario sich schon aufgrund eingesparter Wartungskosten innerhalb kurzer Zeit rechnen. 11. Oktober 2012 Seite 22

20 MDL/DLm Einsatzgebiete I Mainframe Online Storage FICON/ESCON MDL FICON ESCON FC/ NAS VTAPES Backup- Storage 11. Oktober 2012 Seite 23

21 MDL/DLm Einsatzgebiete II Szenario: Der Kunde muss eine Desaster Recovery Lösung einführen, die feste Vorgaben durch ein Service Level Agreement (SLA) erfüllen muss. RTO (Recovery Time Objective) und RPO (Recovery Point Objective) für sämtliche Mainframe-Daten sind vorgegeben. Lösung und Vorteile: Da MDL den Einsatz aller gängigen Back-End Storage-Systeme ermöglicht, steht dem Kunden eine Vielzahl von Replikations- und Mirroringtechnologien aus der OpenSystem Welt zur Verfügung. Alle Anforderung, Hot, Warm und Cold Desaster Recovery sind möglich. Da die replizierten Daten auch alle File-Informationen enthalten, ist ein Desaster Recovery der virtuellen Files sofort möglich. Alternativ zur Hardware-basierten Replikation kann eine Software-Replikation mit dem optionalen Replikationsmodul erfolgen. Anmerkungen: Fast alle physikalischen und virtuellen Mainframe Tape-Technologien erfordern eine Duplizierung der Ressourcen, wenn Desaster-Recovery erforderlich ist. 11. Oktober 2012 Seite 24

22 MDL/DLm Einsatzgebiete II Mainframe Online Storage FICON/ESCON MDL FICON FC/ NAS LAN WAN VTAPES 11. Oktober 2012 Seite 25

23 MDL/DLm Einsatzgebiete IV Szenario: Der Kunde hat keine Bandverwaltung und auch keine Tape-Library. Bei Batchprozessen ist für die Datensicherung Operatorhandling notwendig. Die Sicherungsabläufe sollen künftig automatisiert und operatorlos durchgeführt werden. Lösung und Vorteile: Der Kunde erneuert seine Tape-Technologie auf der Basis von MDL. Durch geringfügige Anpassungen an seinen Abläufen kann jedes Tape nun als virtuelles Tape innerhalb seiner Abläufe montiert werden. Unabhängig ob Lesen oder Schreiben erforderlich ist. Anmerkungen: Gleichzeitig integriert der Kunde seine virtuellen Tapes aus dem Mainframe-Umfeld in seine unternehmensweite Datensicherung und kann so die Sicherung über alle Serverplattformen vereinheitlichen. Einheitliche Policies sind nun möglich. Alle Funktionen einer OpenSystem Datensicherung können nun auch für Mainframe-Daten genutzt werden. Kostengünstige Drives mit hohen Sicherungskapazitäten sind in der OpenSystem Welt vielfach bereits vorhanden und können nun auch für Mainframe- Datensicherungen mit verwendet werden. 11. Oktober 2012 Seite 28

24 MDL/DLm Einsatzgebiete IV Mainframe Online Storage FICON/ESCON MDL FICON FC VTAPES ESCON Backup- Storage 11. Oktober 2012 Seite 29

25 MDL/DLm Einsatzgebiete V Szenario: Der Kunde muss für seine Sicherungsprozesse eine einfache und granulare Verschlüsselung implementieren. Daten, die das DataCenter verlassen, müssen verschlüsselt sein. Unabhängig davon, auf welchem Wege (Netzwerk, Removable Media, Tape-Kassetten) die Daten erzeugt werden. Lösung und Vorteile: Der Kunde klassifiziert seine Datensicherungen auf der MDL. Er definiert zwei Libraries und implementiert die AES-256 Verschlüsselung für alle Laufwerke in einer separaten Library, die dann entweder über seine unternehmensweite Datensicherung gesichert wird oder mit gängigen Replikationslösungen an einen zweiten Desaster Recovery Standort übertragen werden. Anmerkungen: Die Verschlüsselung der MDL ist ein kostenfreies Feature. Bis zu 5 unterschiedliche Schlüssel können je MDL Node definiert werden. 11. Oktober 2012 Seite 30

26 MDL/DLm Einsatzgebiete V Mainframe Online Storage FICON/ESCON MDL FICON FC VTAPES 11. Oktober 2012 Seite 31

27 MDL/DLm Einsatzgebiete oder eine beliebige Kombination der zuvor beschriebenen Lösungsszenarien oder eine schrittweise Einführung der genannten Szenarien über eine phasenweise Projektlaufzeit 11. Oktober 2012 Seite 32

28 MDL/DLm Kundenszenarien Replikation 11. Oktober 2012 Seite 33

29 MDL/DLm Kundenszenarien Replikation Auslagerung / 11. Oktober 2012 Seite 34

30 MDL/DLm Kundenszenarien Replikation 11. Oktober 2012 Seite 35

31 MDL/DLm Kundenszenarien Replikation Datenträgeraustausch 11. Oktober 2012 Seite 36

32 MDL/DLm ist für Sie die richtige Lösung, wenn Sie in Ihrem Unternehmen täglich manuelles Tape Handling durchführen Ihre Tape Drives immer älter werden und eine Anschaffung neuer Technologien zu kostenintensiv ist Sie sich mit einer virtuellen Tape Library für den Mainframe bereits beschäftigt haben und diese Lösung für Ihr Unternehmen zu teuer war Sie eine einheitliche unternehmensweite Datensicherung (z.b. LTO5- basierend) nutzen und Sie bisher Ihre Mainframe-Daten nicht integrieren konnten Sie öfter einen Engpass an Tape Drives haben und Prozesse beschleunigen könnten, wenn Ihnen mehr Drives und schnellere I/O Kapazitäten zur Verfügung stehen würden 11. Oktober 2012 Seite 37

33 MDL/DLm ist für Sie die richtige Lösung, wenn Ihr Desaster Recovery Konzept den regelmäßigen Transport von Datenträgern außer Haus vorsieht Ihre unternehmensweite Security Policy vorsieht, dass Daten (-träger) die außer Haus gehen, verschlüsselt sein müssen Ihr Unternehmen in Technologien investieren möchte, die nicht nur auf das Mainframe-Umfeld beschränkt sind und diese ebenfalls von heterogenen Plattformen genutzt werden können Sie teilweise Tapes während der Batch-Verarbeitung nutzen Sie Bänder für Langzeitarchivierung verwenden 11. Oktober 2012 Seite 38

34 VTFX VTFX (Virtual Tapelibrary Function Extension) ist eine Appliance und eine Gruppe von Software-Modulen zur funktionellen Erweiterung einer MDL oder DLm VTL. Diese Module sind: Query and Reporting Facility (QR) Semi-Automatic Library (SAL) und Statistics (S) 11. Oktober 2012 Seite 39

35 VTFX (QR) 11. Oktober 2012 Seite 40

36 VTFX (S) Statistiken sind verfügbar für: I/O Daten, FICON/ESCON Channel Belegung, Mounts pro Stunde, Kompressionsrate, Durchsatz, Temperatur, Filesystem-Belegung und Anzahl der Mounts pro Zeitintervall für ein bestimmtes Tape Für jeden Statistiktyp gibt es eine andere Grafik, die für verschiedene Zeiträume definiert werden können von 1 Stunde bis zu 1 Jahr. 11. Oktober 2012 Seite 41

37 VTFX (S) 11. Oktober 2012 Seite 42

38 VTFX (S) 11. Oktober 2012 Seite 43

39 Kundenreferenzen 11. Oktober 2012 Seite 44

40 Kundenreferenzen 11. Oktober 2012 Seite 45

41 Projektvorgehensweise Erarbeitung eines Lösungsszenarios im Workshop Calls oder Meetings mit unseren technischen Lösungsspezialisten Angebot für die gewünschten Lösungsalternativen Evaluierung im Kundenumfeld Erarbeitung eines verbindlichen finalen Angebotes Entscheidung Installation Gegebenenfalls Proof of Concept an Stelle der Evaluierung Inbetriebnahme, Migration Altdatenbestände Service und Support 11. Oktober 2012 Seite 46

42 Peter Freund Vertrieb mainstorconcept GmbH Fiduciastr Karlsruhe Telefon Mobil info@mainstorconcept.de 11. Oktober 2012 Seite 48