13. Juni >SAMFS bei Lufthansa Systems Inodebegrenzung und Applikationsgesteuerte Datenverschiebung zwischen SAM- Filesystemen

Transkript

1 13. Juni 2013 >SAMFS bei Lufthansa Systems Inodebegrenzung und Applikationsgesteuerte Datenverschiebung zwischen SAM- Filesystemen

2 >Agenda SAMFS bei Lufthansa Systems in Hamburg edoc eine Applikation mit Herausforderungen Datenverteilung auf mehrere SAM-Filesysteme, aber wie? Folie 2

3 >SAMFS bei Lufthansa Sytems in Hamburg Applikationsserver Angeschlossen Applikationsserver Angeschlossen per NFS LHT-Group LRS Filesysteme: Veritas Volumes gespiegelt m. Veritas-Vm über 2 Gebäude EOD Prod T2000 Cluster VOD Kons T2000 Pro d T2000 Filesysteme: SDS-Volumes ungespiegelt Archivspeicher: ungespiegelt verschiedene SAN-Baureihen 2 Diskkopien per FS Bandkopie auf C4-Lib (nur Prod) G112 VOD G115 VOD G465 VOD G115 G112 Archivspeicher: ungespiegelt Bandkopie auf SL 500 Folie 3

4 >Applikationen auf den SAMFS-Systemen LHT - Cluster - System edoc m/archive l/archive ELO FileNet LTL - System Sirax-File-Archiv SAP-Datenarchiv Folie 4

5 >Agenda SAMFS bei Lufthansa Systems in Hamburg edoc eine Applikation mit Herausforderungen Datenverteilung auf mehrere SAM-Filesysteme, aber wie? Folie 5

6 >Das System edoc Lufthansa Technik`s System für technische Dokumente Wiedergabe dieser Folie mit freundlicher Genehmigung der Lufthansa Technik Folie 6

7 >Das System edoc Vorteile durch den Einsatz von edoc Wiedergabe dieser Folie mit freundlicher Genehmigung der Lufthansa Technik Folie 7

8 >Das System edoc edoc im Laufe der Zeit Wiedergabe dieser Folie mit freundlicher Genehmigung der Lufthansa Technik Folie 8

9 >Das System edoc Zahlen, Daten, Fakten Wiedergabe dieser Folie mit freundlicher Genehmigung der Lufthansa Technik Folie 9

10 >edoc Lesesystem Die Suche nach Dokumenten Wiedergabe dieser Folie mit freundlicher Genehmigung der Lufthansa Technik Folie 10

11 >edoc Lesesystem Viele Formate, eine Dokumentenanzeige Wiedergabe dieser Folie mit freundlicher Genehmigung der Lufthansa Technik Folie 11

12 >Agenda SAMFS bei Lufthansa Systems in Hamburg edoc eine Applikation mit Herausforderungen Datenverteilung auf mehrere SAM-Filesysteme, aber wie? Folie 12

13 >Ursprüngliches Design für edoc im SAMFS Applikationsserver Oracle- DB NFS Im August 2011: Ein SAM-Filesystem 65 Mio. Inodes FiberChannel Eine Archivdisk G115 (Mehrere LUN) Eine Archivdisk G465 (Mehrere LUN) Tape Kopie G112 LTO-3 Je 2,8 TB Daten (ca. 44 KB/Datei) Folie 13

14 >Grenzen des ersten Designs Zu viele Inodes führen zu: Zu lange dump/restore-zeiten (20 Stunden bei 70 Mio Inodes) Zu lange damage/undamage-zeiten. Konvention: maximal 10 Mio Inodes per SAM-Filesystem Erweitern der Archivdisks führt zu Risiken: Je mehr LUNs zu einem FS gehören, umso größer die Wahrscheinlichkeit eines Verlustes Verlust einer einzigen LUN führt zum Komplettverlust der Archivkopie Bei etwa 2,6 TB Daten dauerte das Recovery zu lange (6 Wochen) Konvention: Eine Archiv-Disk-VSN ist maximal 500 GB gross Je Archiv-Disk-VSN wird genau eine LUN verwendet 13. Juni 2013 Folie 14 Inode-begrenzung und -verschiebung Dipl. Ing. Dirk Busche

15 >1. Ansatz: Alle 10 Mio ein neues Filesystem Applikationsserver NFS Je 10 Mio Inodes 1 SAM-Filesystem Oracle- DB Prinzip: Vorhandenes FS in mehrere FS je 10 Mio Inodes zerlegen. Alle 10 Mio Inodes kommt ein neues FS dazu Die neuesten Daten kommen in das neueste FS Disk-Pool Gebäude-115 (eine LUN/Volume) FiberChannel Disk-Pool Gebäude-465 (eine LUN/Volume) Tape Kopie G112 LTO-3 Nachteile: Alte Caches bleiben unnötig gross oder müssen per dump/restore (=dowtime) verkleinert werden. Folie 15

16 >2. Ansatz: Cachepools mit gemeinsamen Archiv-Pools NewData-FS (400GB-Cache, schnell) Disk-Pool Gebäude-115 (eine LUN/Volume) Applikationsserver NFS FiberChannel Disk-Pool Gebäude-465 (eine LUN/Volume) Oracle- DB OldData-FS (25GB-Cache, günstig) Tape Kopie Gebäude 112 LTO-3 Prinzip: Vorhandenes FS in mehrere FS je 10 Mio Inodes zerlegen. Es gibt zwei Klassen von FS: Aktuelle und in Redaktion befindliche Versionen in FS mit grossen, schnellen Caches. Ältere Versionen in FS mit kleinen, preisgünstigen Caches. Gemeinsamer Archivpool über alle Filesysteme Verschiebung veralteter Daten aus NewData-FS zu OldData-FS ohne Staging/Rearchivierung möglich Folie 16

17 >Inodes in ein anderes Filesystem kopieren Quell-FS sls -D./edoc/BMD_8/ /AA/documents/arec.xml./edoc/BMD_8/ /AA/documents/arec.xml: mode: -rw-r--r-- links: 1 owner: 1025 group: 2201 length: 470 admin id: 0 inode: offline; copy 1: Dec c8e1f dk edocp01_1_03 d3/f50 copy 2: Dec d6.a1e5b dk edocp01_2_03 d2/f214 copy 3: Dec ec9b6 li SFS017 access: Dec 19 20:14 modification: Dec changed: Dec attributes: Dec creation: Dec residence: Dec 20 05:00 cd /original/parentdirectory samfsdump u f /tmp/transfer.dump document_dir Dumpfile (/tmp/transfer.dump) Ziel-FS cd /complete/other/parentdirectory samfsrestore /tmp/transfer.dump Folie 17

18 >Die Applikation steuert den Transfer Applikationserver edoc Agent (Tomcat) 2 1 Skripte 4 5 SAMFS-Server 3 Oracle- DB Quell-FS Ziel-FS 1. Die Applikation fordert eine Kopie per HTTP-Request beim Agenten an. 2. Der Agent übersetzt den Request für Shell-Skripte 3. Shell-Skripte führen die Kopie der Inodes mit samfsdump und samfsrestore durch 4. Die Applikation prüft ob die Kopie vollständig und erfolgreich war (normaler NFS-Zugriff) 5. Die Applikation löscht die Daten auf der Quellseite (normaler NFS-Zugriff) Während des ganzen Vorgangs werden die Daten auf den Archivmedien nicht angefasst, sind aber trotzdem im Ziel- FS lesbar! Folie 18

19 13. Juni 2013 >Ihre Fragen?