Der CMS betreibt einen Backupservice auf Basis des Tivoli Storage Managers. Die Infrastruktur wurde im Jahr 2009 erneuert und wird im Folgenden vorgestellt

Döbler, Jens

edoc Publication server

Backup über das Netzwerk – neue Systeme

Dokumenten-Publikationsserver der Humboldt-Universität zu Berlin

29Backup über das Netzwerk – neue SystemeDer CMS betreibt einen Backupservice auf Basis des Tivoli Storage Managers. Die Infrastruktur wurde im Jahr 2009 erneuert und wird im Folgenden vorgestellt.Backup über das Netzwerk – neue SystemeDr. Jens Döbler | jd@cms.hu-berlin.deIm CMS wird ein zentraler Backupservice betrieben, durch den Daten von Servern gesichert werden. Die Datensicherung hat auch heute noch eine hohe Bedeu-tung, obwohl vielfach redundante und  zuverlässige Systeme verwendet werden.  Datensicherung bleibt trotzdem unver-zichtbar, einerseits da kein System eine Zuverlässigkeit von 100% erreichen kann.  Andererseits ist eine der häufigsten Ur-sachen für Datenverlust ein Nutzerfehler – z. B. durch versehentliches Löschen oder Überschreiben von Dateien – vor dem keine Systemzuverlässigkeit schüt-zen kann. Zur Zeit werden ca. 350 Serversys-teme gesichert. Das Gesamtvolumen der gesicherten Daten beträgt 120 Terabyte in 300 Millionen Dateien, bei einem täg-lichen Datenvolumen von durchschnitt-lich 3,5 Terabyte. Um eine effiziente Ver- arbeitung dieser Datenmenge sicher- zustellen, wurde die Infrastruktur des Backupservice seit Mitte 2008 schritt- weise erneuert. SpeichersystemeFür die Speicherung der Backupdaten wurden zwei Anlagen vom Typ Quantum  Scalar i2000 angeschafft, die im Erwin Schrödinger-Zentrum und im Jacob-und-Wilhelm-Grimm-Zentrum aufgestellt wurden. Die Systeme sind automatisierte  Bandspeichersysteme, in denen sich Mag- netbänder und Bandlaufwerke befinden. Die Bandkassetten werden durch einen Greifarm innerhalb der Anlage bewegt.Als Speichertechnik kommt LTO4 (Linear Tape Option – 4. Generation) zum Einsatz. Hierbei handelt es sich um eine herstellerübergreifende Magnetband- Technologie, die äußerst zuverlässig ist.  Auf einer Bandkassette lassen sich 800 GB Daten speichern. Die Daten werden hier- bei in mehreren parallelen Spuren auf das Magnetband geschrieben. Bei der Herstellung der Magnetbänder werden sogenannte Servospuren aufgebracht, die von den Laufwerken für die Positi-onierung der Magnetköpfe verwendet werden. Hierdurch ist stets die korrekte Spurlage sichergestellt und Spurfehler durch falsche Positionierung der Köpfe sind ausgeschlossen. Die LTO-Technolo-gie verwendet Fehlerkorrekturalgorith-men, ähnlich wie bei CD oder DVD, so dass die Daten auch bei einer begrenzten Anzahl an Bitfehlern lesbar sind. Zusätz-lich werden geschriebene Daten immer von einem zweiten Kopf zurückgelesen. Wenn die Daten bei dieser Überprüfung nach der Fehlerkorrektur nicht identisch sind, wird der betroffene Block automa-tisch erneut geschrieben. Auf diese Weise  ist immer sichergestellt, dass die ge- schriebenen Daten lesbar sind. Das Auf- treten dieser Art von Fehlern („soft error“) wird in einer Statistik festgehalten, so dass Laufwerksprobleme durch eine erhöhte Anzahl von soft errors frühzeitig erkennbar sind.Die Speichersysteme sind mit 9 Lauf- werken und 1300 Bändern (Adlershof) bzw. 12 Laufwerken und 1600 Bändern (Mitte) ausgestattet. Sie sind modular  aufgebaut, so dass sich bei Bedarf sowohl  weitere Laufwerke als auch Stellplätze für Bandkassetten nachrüsten lassen.Abb.1 : Innenansicht einer Scalar i200030 cms-journal 33 / Juni 2010BackupsoftwareBei einer klassischen Backupstrategie wird zwischen einem vollständigen Backup und inkrementellen Backups unterschieden. Bei letzteren werden aus-gehend von einem vorherigen Backup nur geänderte Daten gesichert, um das Backupvolumen zu reduzieren. Da die inkrementellen Backups aufeinander aufbauen, nimmt der Aufwand einer  Rücksicherung stetig zu, da nacheinan-der zunächst das vollständige und an-schließend die inkrementellen Backups eingespielt werden müssen. Daher wer-den normalerweise regelmäßige (z. B. wöchentlich) vollständige Sicherungen durchgeführt.Ein solches Konzept ist bei dem vor- liegenden Umfang von ca. 120 TB nicht  praktikabel. Eine Alternative stellt der Tivoli Storage Manager (TSM) des Her- stellers IBM dar. TSM verwendet ein vollinkrementelles Verfahren, das mit einer SQL Datenbank realisiert ist. Die Datenbank speichert die Metadaten der  gesicherten Dateien (Dateiname, Zu-griffsrechte, Erstellungsdatum, Datei-größe, usw.), der eigentliche Dateiinhalt wird auf einem Speichermedium abge- legt und mit einem Index verknüpft. Dieser Index dient als Verweis auf den Dateiinhalt und ist gemeinsam mit den Metadaten in der Datenbank gespeichert. Bei einer Erstsicherung erfolgt zunächst eine Sicherung aller Dateien. Bei darauf folgenden Sicherungen werden dann die Metadaten des bisherigen Datenbe-standes aus der Datenbank an den Kli-enten übertragen. Dieser prüft nun an-hand der Informationen, ob sich Dateien geändert haben, überträgt diese sowie neue Dateien zum Server und meldet gelöschte Dateien an den Server. Bei ge-änderten oder gelöschten Dateien wird dann auf dem Server der Datenbankein-trag der Datei als inaktiv markiert. Hier-durch ist zu jeder Zeit eine Rücksiche-rung des aktuellen Datenbestandes in einem Schritt möglich, indem aus der Datenbank die aktiven Dateien abgefragt werden. Ältere Dateiversionen bleiben ebenfalls eine Zeitlang gespeichert; in der jetzigen Konfiguration sind maximal 4 Versionen einer Datei vorhanden (zu-sätzlich zur aktuellen Version verbleiben maximal drei vorherige Versionen für  30 Tage). Gelöschte Dateien sind 60 Tage  verfügbar. Durch dieses Sicherungssche-ma beträgt das tägliche Datenvolumen nur etwa 3,5 TB. Die Datenbank ist für die Funktion  des Servers erforderlich und die Leistungs- fähigkeit der Datenbank ist von entschei-dender Bedeutung für den ordnungsge-mäßen Betrieb des Servers. Dies stellte für die bis Anfang 2009 verfügbaren TSM- Versionen ein Problem dar, da die inte-grierte Datenbank bei mehr als 150 Mio. gesicherten Dateien Performanceschwä- chen zeigte. Dieses Problem wird durch die im März 2009 veröffentlichte Ver- sion TSM 6.1 behoben, in der die Daten-bankfunktionalität nicht mehr im TSM integriert ist, sondern auf eine externe DB2 Datenbank umgestellt wurde. Die  Version 6.1 ist im CMS seit Oktober 2009  im Einsatz und hat sich als zuverlässig und performant herausgestellt.BackupkonzeptSeit Oktober 2009 werden insgesamt vier TSM-Server betrieben. Es befinden  sich jeweils zwei Server im Erwin Schrö- dinger-Zentrum und im Jacob-und-Wil- helm-Grimm-Zentrum. An beiden Stand- orten wird ein Server mit der Version 5.5 und der zweite mit Version 6.1 betrieben.  Es handelt sich um Server vom Typ IBM p520, die mit 10 Gigabit-Ethernet an das HU-Netz angebunden sind. Die Backups erfolgen normalerweise zwischen 18:00  und 4:00 Uhr. Die zu sichernden Systeme übertragen die Daten per Netzwerk an den jeweiligen Server, dort werden die Backups zunächst auf Festplattensys-teme zwischengespeichert. Die Daten werden hierbei auf zwei getrennte Fest- plattensysteme gespiegelt, um die Sicher- heit der Daten auch bei Ausfall eines Plattensystems garantieren zu können. Ab 5:00 Uhr werden die Daten dann an beiden Standorten auf Band kopiert. Von allen Daten sind immer zwei Kopien vorhanden, um sicherzustellen, dass die Daten verfügbar sind, auch wenn eine Kopie der Daten nicht lesbar oder zerstört ist. Das zweistufige Konzept der Datenspeicherung (erst auf Disk, dann auf Band) erlaubt es, dass die Bandlauf-werke kontinuierlich Daten schreiben. Die verwendete LTO4-Technik schreibt mit maximal 120 MB/s auf Band und verringert die Geschwindigkeit dyna-misch, um einen Start-Stopp-Betrieb zu verhindern. Hierzu muss jedoch eine Datenrate von 30 MB/s erreicht werden. Diese Schwelle wird bei der Übertragung der Daten über das Netzwerk oftmals nicht erreicht; die Zwischenspeicherung auf Disk erlaubt es, die Daten effizienter auf die Bandmedien zu transferieren. Da TSM alle Metadaten in der Da- tenbank speichert und diese auch die Zu- ordnung von Dateien zu Backupmedien enthält, ist ohne sie eine Wiederher-stellung von gesicherten Daten unmög-lich. Daher wird auch die Datenbank täglich – an beiden Standorten – auf Band gesichert. Neben dieser Sicherung werden im TSM alle Änderungen nach dem letzten Datenbankbackup in einem sogenannten Log gespeichert. Bei einer Beschädigung der Datenbank ist es nor-malerweise möglich, den aktuellen Stand aus einem Datenbankbackup und den Logs wiederherzustellen. Im Notfall ist auch eine Wiederherstellung ohne Logs möglich, in diesem Fall gehen jedoch die Änderungen in der Datenbank seit dem Datenbankbackup verloren. Da die Da-tenbankbackups nach dem Sicherungs-fenster, in dem die Klienten sichern, angefertigt werden, ist der Datenverlust auch in diesem ungünstigsten Fall mini-mal. Durch die Verteilung der Daten und der Server auf die zwei Standorte ist eine weitreichende Datensicherheit gewähr-leistet, selbst wenn die Daten an einem Standort (z. B. durch Feuer) vernichtet werden. Die Details für eine Teilnahme am Backupservice sind unter http://www.cms.hu-berlin.de/dl/systemservice/ fileservice/tsm_1_1_html aufgeführt.  Das TSM-Team ist unter der E-Mail  tsm@cms.hu-berlin.de zu erreichen.

https://edoc.hu-berlin.de/bitstream/18452/7250/1/doebler.pdf

Backup über das Netzwerk – neue Systeme

Abstract

Similar works

Full text

Available Versions

edoc Publication server

Dokumenten-Publikationsserver der Humboldt-Universität zu Berlin