====== VSC-3 ======
* 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)
====== Derzeitiges Off-Site Backup ======
* 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
====== Derzeitiges Off-Site Backup (2) ======
{{.:vsc_network.png}}
====== Struktur der Daten ======
{{.:vsc3_files.png}}
====== Struktur der Daten (2) ======
{{.:vsc2_files.png}}
====== Struktur der Daten (3) ======
{{.:vsc3_space.png}}
====== Struktur der Daten (4) ======
{{.:vsc2_space.png}}
====== Backup-Maschine ======
* 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
====== Filesystem ======
* 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
====== Backup Sofware ======
* 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
====== Backup Software (2) ======
* 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
====== Bash/Rsync Magic (1) ======
* 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
====== Bash/Rsync Magic (2) ======
* 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?
====== Bash/Rsync Magic (3) ======
* 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
====== Bash/Rsync Magic (4) ======
# 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
====== Bash/Rsync Magic (5) ======
* 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
====== Bash/Rsync Magic (6) ======
{{.:vsc_backup.png}}
====== Bash/Rsync Magic (7) ======
* 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
====== Bash/Rsync Probleme ======
* 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
====== Ausblick ======
* 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
====== Ausblick (2) ======
* 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)
====== Ende ======
* Danke für die Aufmerksamkeit