SAMFS bei Lufthansa Systems Inodebegrenzung und ...konferenz-nz.dlr.de/pages/samfs2013/present/1....

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

13. Juni 2013

>Agenda

Folie 2 13. Juni 2013 Inode-begrenzung und -verschiebung | Dipl. Ing. Dirk Busche

► SAMFS bei Lufthansa Systems in Hamburg

► eDoc – eine Applikation mit Herausforderungen

► Datenverteilung auf mehrere SAM-Filesysteme, aber wie?

>SAMFS bei Lufthansa Sytems in Hamburg


LHT-Group LRS Filesysteme:

• Veritas Volumes

• gespiegelt m. Veritas-Vm über 2 Gebäude

Filesysteme:

•SDS-Volumes

• ungespiegelt

Cluster

EOD Prod

VOD Kons

G112 VOD G115

VOD G115

G112 VOD G465

Archivspeicher: • ungespiegelt • verschiedene SAN-Baureihen • 2 Diskkopien per FS • Bandkopie auf C4-Lib (nur Prod)

Archivspeicher: • ungespiegelt • Bandkopie auf SL 500

Applikationsserver Angeschlossen

Applikationsserver Angeschlossen per NFS

T2000 T2000

Prod

T2000

>Applikationen auf den SAMFS-Systemen


LTL - System Sirax-File-Archiv SAP-Datenarchiv

LHT - Cluster - System eDoc m/archive l/archive ELO FileNet

>Agenda





>Das System eDoc Lufthansa Technik`s System für technische Dokumente


Wiedergabe dieser Folie mit freundlicher Genehmigung der Lufthansa Technik

>Das System eDoc Vorteile durch den Einsatz von eDoc



>Das System eDoc eDoc im Laufe der Zeit



>Das System eDoc Zahlen, Daten, Fakten



>eDoc Lesesystem Die Suche nach Dokumenten



>eDoc Lesesystem Viele Formate, eine Dokumentenanzeige



>Agenda





>Ursprüngliches Design für eDoc im SAMFS


Ein SAM-Filesystem

Applikationsserver

Eine Archivdisk

G115 (Mehrere

LUN)

Eine Archivdisk

G465 (Mehrere

LUN)

Tape Kopie G112 LTO-3

NFS

FiberChannel

Im August 2011:

65 Mio. Inodes

Je 2,8 TB Daten (ca. 44 KB/Datei)

Oracle-DB

Folie 14 13. Juni 2013

>Grenzen des ersten Designs

Inode-begrenzung und -verschiebung | Dipl. Ing. Dirk Busche

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

>1. Ansatz: Alle 10 Mio ein neues Filesystem


FiberChannel

Je 10 Mio Inodes 1 SAM-Filesystem

Applikationsserver

Disk-Pool Gebäude-465

(eine LUN/Volume)

Tape Kopie G112 LTO-3

NFS


(eine LUN/Volume)

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

Nachteile: Alte Caches bleiben unnötig

gross oder müssen per dump/restore (=dowtime) verkleinert werden.

Oracle-DB

>2. Ansatz: Cachepools mit gemeinsamen Archiv-Pools


FiberChannel

Applikationsserver


(eine LUN/Volume)

Tape Kopie

Gebäude 112

LTO-3

NFS


(eine LUN/Volume)

NewData-FS (400GB-Cache, schnell) OldData-FS

(25GB-Cache, günstig)

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

Oracle-DB

> Inodes in ein anderes Filesystem kopieren


Quell-FS

Ziel-FS

Dumpfile (/tmp/transfer.dump)

cd /original/parentdirectory samfsdump –u –f /tmp/transfer.dump document_dir

cd /complete/other/parentdirectory samfsrestore /tmp/transfer.dump

sls -D ./edoc/BMD_8/0000000000000000001607718/AA/documents/arec.xml ./edoc/BMD_8/0000000000000000001607718/AA/documents/arec.xml: mode: -rw-r--r-- links: 1 owner: 1025 group: 2201 length: 470 admin id: 0 inode: 98127.1 offline; copy 1: ----- Dec 29 2011 332.c8e1f dk edocp01_1_03 d3/f50 copy 2: ----- Dec 29 2011 2d6.a1e5b dk edocp01_2_03 d2/f214 copy 3: ----- Dec 29 2011 94225.4ec9b6 li SFS017 access: Dec 19 20:14 modification: Dec 12 2011 changed: Dec 12 2011 attributes: Dec 12 2011 creation: Dec 12 2011 residence: Dec 20 05:00

>Die Applikation steuert den Transfer


Applikationserver

eDoc

SAMFS-Server

Agent (Tomcat)

Skripte

Quell-FS

Ziel-FS

5 1

4

3

2

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!

Oracle-DB

> Ihre Fragen?

13. Juni 2013

SAMFS bei Lufthansa Systems Inodebegrenzung und ...konferenz-nz.dlr.de/pages/samfs2013/present/1....

Documents

Transcript of SAMFS bei Lufthansa Systems Inodebegrenzung und ...konferenz-nz.dlr.de/pages/samfs2013/present/1....