• Installation Sommer 2014 durch ClusterVision
• 2020 Nodes
  • 2x Intel Xeon E5-2650v2, 2.6 GHz, 8 Cores
  • 64 GB Ram
  • 2x Infiniband QDR (40 GBit/s)
  • Ölgekühlt
• 36 Storage Server
  • 10 Server für Home Filesysteme
  • 8 Server für paralleles Global/Scratch Filesystem
  • 16 Server für parallele Bioinformatik Filesysteme
  • 2 Server für GPFS (EODC)

• Prinzipiell nur fuer Disaster-Recovery
• /home Dateisysteme
  • 10 Fileserver VSC-3
  • 6 Fileserver VSC-2 (Archiv)
  • Fileserver Hadoop Cluster / Datalabs
  • Gesamt derzeit ca. 800 TB Brutto / 750 Mio. Dateien
  • Durchschnittliche Dateigroesse ~ 1 MB

• 1 Maschine
  • 2x Intel Xeon E-5620, 2.4 GHz, 4 Cores / 8 Threads
  • 128 GB Ram
  • 10 GBit/s zum Arsenal
  • 4x SAS3 HBA (LSI SAS3008)
  • 140 x 8 TB Seagate Archive (SMR) Disks
  • SAS2 JBODs

• ZFS
  • 3 Pools
    • VSC2/Hadoop
    • VSC3
    • VSC3_2
  • Mehrere VDEVs pro Pool
    • Alle Raidz-3
  • 1 Filesystem pro Fileserver
  • Keine Cache/Log Devices
  • Alle Pools gemeinsam 1050TB

• Selbst gebaut mit GNU tools
  • Bash, Rsync, Grep, Split, etc
• Snapshotting (ZFS)
  • pro Server
  • pro Backup-Zyklus
  • script zum loeschen von alten Snapshots (halbautomatisch)
• Konfigurations-File

# Configuration File for the backup script
# Server  Source            Destination    ProcessCount  ZFS Snapshot  Log-File
nfs01     /mntbackup/nfs01  /backup/nfs01  4             1             /backup/log/nfsbackup_nfs01
nfs02     /mntbackup/nfs02  /backup/nfs02  1             1             /backup/log/nfsbackup_nfs02
nfs03     /mntbackup/nfs03  /backup/nfs03  1             1             /backup/log/nfsbackup_nfs03

• Status Output

[root@fh100 ~]# /backup/bin/new/vsc_show_backupstate
+++++++++++++++++++++++++++++++++++++++++
+Current Backup-State of VSC-2 and VSC-3+
+++++++++++++++++++++++++++++++++++++++++
nfs01: Backup running since 2019-04-30.
nfs02: Backup running since 2019-04-30.
nfs03 completed at 2019-04-23 with a runtime of  58729 Seconds. Next Backup already queued on 2019-04-23
+++++++++++++++++++++++++++++++++++++++++
+       Backup-Pools Space Report       +
+++++++++++++++++++++++++++++++++++++++++
backup: 35.3T available
backup2: 49.7T available
tank7NG: 23.5T available

• Naiver Ansatz

rsync -avHAXS --delete src/ dest/

• Vorteile
  • Einfach
• Nachteile
  • Nur 1 Prozess
    • und der macht die halbe Zeit IOWait bei NFS ueber 10G
  • Funktioniert so nicht bei 750 Mio. Files

• Parallelisierung - Naiver Ansatz

for i in {1..10}
do 
    rsync -avHAXS --delete src/server${i}/ dest/server${i}/ & 
done

• Vorteile
  • Relativ Einfach
  • Mehrere rsync Prozesse laufen parallel
• Nachteile
  • Parallelisierung abhaengig von der Anzahl der Server
  • Alle Server muessen gebackuppt sein, bevor der Zyklus neu starten kann
  • Output / Monitoring der Rsync Jobs?

• Parallelisierung - Besser
  • Fuer jeden server
    • ZFS Snapshot erstellen
    • Parallel
      • Verzeichnisstruktur kopieren
      • Filelist erstellen
        • Sortieren
        • Splitten (Anzahl Prozesse)
      • Nicht mehr vorhandene Files loeschen
    • Neue / geaenderte files mit mehreren Prozessen synchronisieren

# Sync Directory Structure
rsync -avHAXS -f"+ */" -f"- */*" src/server/ dest/server/ &
# Create Filelists
( find src/server/ ! -type d > filelist.txt
sort -R filelist.txt > filelist2.txt
split -d -a6 -n r/$numProcesses filelist2.txt > filelist.scrambled.txt ) &
# Delete obsolete files
rsync -r --delete --existing --ignore-existing src/server/ dest/server/ &
wait
# Sync Files in Filelist
for ((i=0; i<$numProcesses; i++))
do 
  rsync -avHAXS --files-from=filelist.scrambled.txt.${i} src/server/ dest/server/ & 
done

• Backup mit n-prozessen pro server
• Backup Zyklus?
  • Backup-Server soll immer eine gewisse Load haben (Anzahl laufender rsync prozesse)
• Warteschlange / Queue
  • Backup laeuft pro Server.
  • Script checkt Server, die nicht gerade gebackuppt werden und fuegt sie in Warteschlange ein
    • 1x Taeglich
  • Zweites script checkt Anzahl der laufenden rsync Prozesse
    • Startet backup fuer naechsten Server in Queue
    • 1x Stuendlich

• Clustercopy.sh
  • Erweiterung des Backup-Scripts
  • Zum Kopieren von Files auf Clustern
  • Erwartet Liste von Nodes und Anzahl der Prozesse
    • rsync mit m Prozessen auf n Nodes
  • Speedup fuer parallele Dateisysteme

• Out of Memory (ZFS)
  • Directories mit vielen Files?
• Anzahl der Rsync-Prozesse
• Rebuild Zeit bei SMR Disks
• Hinzufuegen neuer Disks
• ZFS Troubles
• Bottlenecks
  • SAS
  • Netzwerk
  • CPU/Memory

• Backup auf Tapes mit IBM Spectrum Protect
  • Tape Library TU Wien Geodaesie
  • 9 TB / Tape unkomprimiert (LTO-7 M8)
  • 300 MB/s write speed per drive
  • 3 Drives
  • 100 Tapes
  • 1 Server
  • 2 Clients

• Spectrum Protect Server
  • 2x Intel Xeon E5-2697V4, 2.3 GHz, 18 Cores / 36 Threads
  • 512 GB Ram
  • 2 x 10 GBit/s zum Arsenal
  • 2 x 10 GBit/s zum Freihaus
  • 4 x 8 GBit/s Fibre Channel zur Tape Library (IBM TS4500)
  • 4 x 2 TB Intel DC P3600 fuer DB2 Datenbank (RAID10)
  • 6 x 500 GB SSD fuer Disk Pool (RAID5)

• Danke für die Aufmerksamkeit