====== 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