Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:services:storage_services:backup:tsm:allgemeines [2015/09/18 10:09] – [FUNKTIONSWEISE TSM-CLIENT: „FILE-(LEVEL-)BACKUP“] bnachtw
+++ de:services:storage_services:backup:tsm:allgemeines [2024/04/15 11:38] (aktuell) – [FUSSNOTEN UND REFERENZEN] jbruene
@@ Zeile 1: / Zeile 1: @@
+====== Beschreibung TSM ======
+Der Überblick zur Arbeitsweise von TSM wurde bereits in den GWDG-Nachrichten 11/2014 veröffentlicht:
+<WRAP round box 60%>
+Im Gespräch sowohl mit Kunden wie Kollegen, die TSM nutzen aber nicht administrieren,
+fällt es immer wieder auf: Das Prinzip, wie eine Sicherung („Backup“)
+und eine Wiederherstellung („Restore“) funktionieren, ist bekannt, die Umsetzung,
+sprich das Konzept und die Arbeitsweise des von der GWDG genutzten
+Programmpaketes „IBM Tivoli Storage Manager (TSM)“, jedoch nicht oder nur
+rudimentär. Statt hier auf die umfangreiche IBM-Dokumentation zu verweisen
+[1], soll dieser Artikel diese zusammenfassen und einen Überblick geben, der
+sich auf das Wesentliche konzentriert. Für Details verweisen wir wieder auf die
+Original-IBM-Dokumentation. Wir konnten Herrn Wolfgang Hitzler vom IBM
+TSM Pre Sales als Co-Autor und Lektor für diesen Artikel gewinnen.
+</WRAP>
+Wie nahezu alle Backup-Lösungen folgt auch der IBM Tivoli
+Storage Manager (TSM) dem „Client-Server-Prinzip“. Der BackupClient
+wird auf dem zu sichernden Rechner (nachfolgend werden
+die Backup-Client-Software und der zu sichernde Rechner synonym
+als „Client“ bezeichnet) installiert und übergibt die zu sichernden
+Daten dem Backup-Server, der diese wiederum auf ein sicheres
+und kostengünstiges Medium überträgt – je nach Anforderung
+können dies Magnetbänder oder auch Disk-Systeme sein. Hiermit
+enden aber auch schon die Gemeinsamkeiten aller Backup-Lösungen:
+Wie der Client die zu übertragenden Daten ermittelt, diese
+überträgt und was der Server aus den übertragenen Daten macht,
+variiert zwischen den einzelnen Produkten teilweise erheblich. An
+dieser Stelle soll nun kein umfassender Vergleich stattfinden, sondern
+nur auf die bei der GWDG eingesetzte Lösung „Tivoli Storage
+Manager (TSM)“ fokussiert die Funktionsweise beschrieben
+werden.
+===== FUNKTIONSWEISE TSM-CLIENT: „FILE-(LEVEL-)BACKUP“ =====
+Der TSM-Client sichert die Daten partitionsweise (im TSM-Kontext wird die englische Bezeichnung „Filespaces“ verwendet,
+die deutsche Übersetzung ist vollkommen unüblich). Hierzu fragt er zunächst beim TSM-Server eine Liste aller gesicherten Dateien
+und deren Attribute („Metadaten“) ab. Aus dieser Liste wird ein Abbild der Verzeichnisstruktur („virtueller Verzeichnisbaum“)
+im Hauptspeicher des Clients aufgebaut, der anschließend mit den tatsächlichen Dateien und Ordnern der zu sichernden Partitionen
+anhand der zuvor genannten Datei- und Verzeichnisattribute verglichen wird. Dateien oder Verzeichnisse, bei denen es Abweichungen
+gibt, werden zum Server übertragen. TSM vollführt hierbei ein „inkrementelles Backup“ [2], da nur die geänderten Dateien und Metadaten übertragen werden. TSM-Sicherungen sehen keine Vollsicherungen vor, weshalb die IBM das Sicherungsprinzip „incremental forever“ nennt.
+Das Durchsuchen der lokalen Festplatten bzw. Partitionen nimmt meist sehr viel mehr Zeit in Anspruch als die reine Datenübertragung. Je nach Umfang der Daten variiert dies stark, wobei für das Durchsuchen weniger das Volumen in (Giga-)Byte als vielmehr
+die Anzahl der Dateien und Ordner (TSM-Wortwahl „Objekte“)
+von Interesse ist. In der folgenden Logdatei des Clients kann
+man dies sehr schön in der abschließenden Zusammenfassung
+sehen (Auszug aus einer Logdatei eines mittelgroßen Clients (4,6
+Mio. Objekte, 8,6 TByte, davon 513 MByte neue Daten):
+<WRAP center round box 60%>
+<code>
+Total number of objects inspected:         4,629,154
+Total number of objects backed up:             2,134
+Total number of objects updated:                 414
+Total number of objects rebound:                   0
+Total number of objects deleted:                   0
+Total number of objects expired:                 454
+Total number of objects failed:                   10
+Total number of bytes inspected:             8.64 TB
+Total number of bytes transferred:         513.64 MB
+Data transfer time:                        13.06 sec
+Network data transfer rate:         40,269.79 KB/sec
+Aggregate data transfer rate:          107.49 KB/sec
+Objects compressed by:                           0 %
+Total data reduction ratio:                 100.00 %
+Elapsed processing time:                    01:21:33
+</code>
+</WRAP>
+Während die reine Übertragung in wenigen Sekunden (13,06 sec) erfolgte, dauerte der gesamte Sicherungslauf hingegen nahezu
+½ Stunden (01:21:33): Fast die gesamte Zeit verbrachte der Client mit der Identifikation der geänderte Dateien. Die gleiche
+Diskrepanz findet man auch bei den Übertragungsraten: Nahezu 40 MByte/sec für die reine Datenübertragung (Network data
+transfer rate), aber nur knapp 107 KByte/sec gemittelte Bandbreite (Gesamtvolumen/Gesamtlaufzeit).
+Während die IBM in der Vergangenheit vorrangig das Problem der geringen Bandbreite lösen wollte (Stichworte „Kompression“,
+Daten-Deduplikation [4]), rückt seit Client-Version 6.3 die Suchzeit (typischerweise als „Seek Time“ oder „Lookup Time“
+bezeichnet) in den Fokus. Für Windows- und Linux-Systeme wurde eine Funktion (Journal-Daemon/Dienst) hinzugefügt, die Änderungen
+im lokalen Filesystem überwacht und somit dem TSM-Client adhoc eine fertige Liste aller seit dem letzten Backup geänderten
+Dateien bereitstellen kann. Mit Hilfe dieser Liste vollführt der TSM-Client dann nur eine Sicherung genau dieser Dateien, ohne die aufwändige Ermittlung der geänderten, also zu sichernden Dateien.
+Leider steht diese Funktion nur für lokale Dateisysteme zur Verfügung. Für Netzwerkfreigaben (z. B. Linux: NFS, Windows und
+Mac: SMB, CIFS) ist dies nicht möglich, da verschiedene Rechner auf die Freigaben zugreifen können und der Journal-Daemon/
+Dienst ebenso wie ein Nutzer Änderungen durch einen anderen Rechner an einer Datei erst beim Zugriff bemerken würde. Eine
+regelmäßige Überprüfung aller Dateien auf Änderungen wäre mindestens so aufwändig wie ein normales inkrementelles TSM-Backup.
+Für verschiedenen NAS-Filer (z. B. NetApp FAS-Serie ab dem Betriebssystem ONTAP 7.3, IBM SONAS) gibt es die Möglichkeit,
+die Liste geänderten Dateien auf diesem zu ermitteln und für TSM zur Verfügung zu stellen. IBMs Filesystem GPFS beherrscht diese
+Funktion sowieso. EMC Isilon-Systeme können zwar geänderte Dateien ermitteln, die Auswertung der Dateiliste ist aber bedingt
+durch unterschiedliche Zeichencodierungen aufwändig und fehlerträchtig. Günstige Arbeitsgruppen-NAS-Systeme stellen eine vergleichbare Funktion derzeit nicht zur Verfügung.
+Neben dem File-Backup können auch vollständige Partitionen übertragen werden. Diese „image backups“ entsprechen in
+gewisser Weise Vollsicherungen; es wird tatsächlich die gesamte Partition übertragen. Problematisch ist der Zugriff auf in Benutzung
+befindliche Partitionen, da durch das Betriebssystem bzw. den Dienst, der die Plattenbereiche bereitstellt, eine Möglichkeit
+zum Einfrieren oder Kopieren vollständiger Partitionen unterstützt werden muss.
+===== FUNKTIONSWEISE TSM-CLIENT: „API-BACKUP“ =====
+TSM bietet neben dem Backup von Dateien („File-Level-Backup“) auch die Möglichkeit, eine Applikations-API (SQL, Exchange)
+zu benutzen. Für verschiedene Produkte gibt es daher spezielle Backup-Clients, die diese API nutzen, z. B.:
+  * TSM for Databases (für Oracle-Datenbanken inkl. RAC, Microsoft SQL Server)
+  * TSM DataProtection Client / DB2 (für DB2-Datenbanken, Lizenz in DB2-Lizenz enthalten)
+  * TSM for Virtual Environments (Plugin im VMware VCenter, nutzt dort die VADP-Schnittstelle)
+  * TSM for Mail (Programm zur Sicherung von MS Exchange und Domino)
+Grundsätzlich funktionieren diese alle ähnlich: Der API-Client ermittelt die zu sichernden Daten, stellt diese zusammen und übergibt
+sie dem TSM-Server. Im Prinzip ist hierbei auch eine inkrementelle Datenübertragung möglich, inwieweit diese genutzt wird,
+hängt von der Implementierung des API-Clients ab.
+===== DATENAUSTAUSCH ZWISCHEN SERVER UND CLIENT =====
+Der Datenaustausch zwischen TSM-Client und -Server erfolgt über ein proprietäres, TSM-eigenes Protokoll auf Basis von TCP/IP.
+Grundsätzlich werden die Daten im Klartext übertragen. Zur Absicherung bietet die IBM zwei Möglichkeiten, die auch kombiniert
+werden können:
+  - **Transportverschlüsselung per SSL** Im TSM-Server wird (ähnlich den Webservern) ein SSLZertifikat [5] hinterlegt, mit dem sich dieser beim Client autorisiert. Für die eigentliche Datenübertragung vereinbaren Client und Server ein Verschlüsselungstoken. Nach der Übertragung werden die Daten wieder unverschlüsselt auf dem TSM-Server abgelegt und weiterverarbeitet (z. B. auf Band geschrieben). Die GWDG bietet für die TSM-Server keine SSL-Verschlüsselung an, da diese zwar einen Sicherheitsgewinn bedeutet, der aber nur auf dem Übertragungsweg wirkt und der Aufwand für Client und besonders die Server erheblich und nicht zu unterschätzen ist.
+  -**Vollständige Datenverschlüsselung** Die Daten werden vor der Übertragung auf dem Client verschlüsselt und anschließend zum Server übertragen. Dieser verarbeitet diese wie „normale, unverschlüsselte“ Daten. Für den Server hat die Verschlüsselung nahezu keine Auswirkungen, lediglich die Kompression in den LTOLaufwerken ist geringfügig geringer.
+Die GWDG empfiehlt die Nutzung der Datenverschlüsselung, weil diese neben dem Transportweg auch die auf den Servern/
+Bandrobotern befindlichen Daten vor dem Zugriff durch Unberechtigte schützt.
+===== FUNKTIONSWEISE SERVER: VERWALTUNG DER DATEN =====
+Im TSM-Server kommen verschiedene Ansätze zur Optimierung der Datenhaltung zum Einsatz. Nachfolgend sind die wichtigsten
+beschrieben:
+==== Managementklassen, Policy Sets und Copygroups ====
+Über diese Parameter werden (vereinfacht zusammengefasst) im TSM-Server verschiedene Einstellungen zu Speicherort, Aufbewahrungsdauer und Anzahl der Versionen festgelegt. Neben der „Default-Management class“ kann client-seitig über „Include/Exclude“-Regeln explizit die Nutzung einer abweichenden Management-Klasse mit anderen Aufbewahrungsfristen erfolgen. Bitte sprechen Sie uns an, welche Aufbewahrungsfristen Sie für Ihre Sicherung benötigen!
+==== Speicherbereiche ====
+TSM speichert die von den Clients übergebenen Daten in „Storage Pool“ genannten Speicherbereichen. Diesen sind in der Regel keine einzelnen Medien (Platten, Magnetbänder) konkret zugeordnet, sondern sie sind nur eine abstrahierte Beschreibung: Bei Bedarf fordert der TSM-Server für einen Storage Pool Bänder bei der Bandbibliothek oder Container-Files beim Betriebssystem an. Storage Pools bestehen immer aus Medien mit gleichen Eigenschaften, können aber Daten mit unterschiedlichen Anforderungen aufnehmen.
+==== Zwischenspeicherbereiche („Staging Pools“) ====
+Lediglich bei einem konstanten Strom vieler neuer Daten über eine 10-GE-Netzwerkverbindung können Daten unterbrechungsfrei
+direkt auf Band geschrieben werden. In der Praxis treffen aber mehrere Aussagen des letzten Satzes nicht zu: Die Datenübertragung
+erfolgt partitionsweise, jeweils von den Suchzeiten unterbrochen. Die wenigsten Clients sind mit 10-GE-LAN angeschlossen.
+Außerdem sind die Datenmengen pro Client relativ gering (in Relation zur Datenmenge, die täglich insgesamt gesichert wird). Da die aktuellen Bandlaufwerke [6] mit hohem Durchsatz schreiben, bedeutet ein direktes Schreiben auf Bandmedien dann ein regelmäßiges Stop-and-go der Bandlaufwerke, immer dann, wenn der Laufwerks-Cache geleert ist. Hierdurch sinkt zum einen die Leistungsfähigkeit, zum anderen belastet das ständige Spulen das Bandmaterial.
+TSM optimiert die Laufwerksnutzung durch das Sammeln der eingehenden Daten in an den TSM-Server angeschlossenen,
+schnellen Festplattenbereichen („Staging Pools“), von denen dann viele zusammen zu speichernden Daten „in einem Rutsch“ auf
+Band geschrieben werden. Im Rahmen des Neuaufbaus der TSMUmgebung bei der GWDG (siehe auch die GWDG-Nachrichten
+/2014) ist geplant, diese Zwischenspeicherbereiche so großzügig zu bemessen, dass im Staging Pool auch bei Wartungsarbeiten an den Bandrobotern die Daten für längere Zeiten aufgenommen werden können. Fehlermeldungen der Art „ANS…. Server out of space“ sollten dann damit der Vergangenheit angehören. Solange Daten im Zwischenspeicherbereich vorliegen, ist auch der Restore wesentlich schneller, da die Zeiten für das Einlegen und Spulen der Bandmedien, die sogenannten „Tape-Mounts“, entfallen.
+==== Speicherbereiche für aktive Daten („Active Data Pools“) ====
+„Aktive Daten“ bezeichnet im TSM-Sprachgebrauch alle Daten, die den Zustand des Clients beim letzten Backup repräsentieren. Durch den „incremental forever“-Ansatz von TSM werden aber sich nicht oder nur selten ändernde Daten nur einmal bzw. sehr selten zum Server übertragen. Hieraus folgt, dass die aktiven Daten sehr wahrscheinlich auf unterschiedlichen Bändern liegen. Beim Restore müssen also zahlreiche Tape-Mounts erfolgen, die zum einen viel Zeit beanspruchen, zum anderen durch den Vorrang von Restores vor Backups andere interne Prozesse verzögern.
+Durch spezielle „Active Data Pools“ kann für ganze Clients oder auch nur einzelne „Filespaces“ neben den klassischen (Band-) Speicherbereichen ein zusätzliches Aufbewahrungsziel definiert werden, das jeweils nur Kopien der aktuellen Daten enthält und somit einen wesentlich schnelleren Restore erlaubt. Da diese Pools meist auf Festplattensystemen liegen, ist die Ressourcennutzung wesentlich höher und damit sind auch die Kosten deutlich höher.
+Bisher hat die GWDG vor dem Kosten- und Ressourcenhintergrund keine Active Data Pools angeboten; wir möchten aber gern mit unseren Kunden die Anforderungen besprechen, da durch Active Data Pools lokale Spiegelungen zumindest teilweise unwirtschaftlich werden können.
+==== Virtuelle Vollsicherungen ====
+TSM verfolgt wie zuvor ausgeführt den Ansatz des „incremental forever“; Vollsicherungen finden nicht statt. Dennoch kann der TSM-Server aus den bisherigen Client-Backups die Daten für einen beliebigen Zeitpunkt [7] zusammenstellen, als wenn zu diesem Zeitpunkt eine Vollsicherung erfolgt wäre. Diese virtuellen Vollsicherungen können auch tatsächlich als sogenanntes „BackupSet“ zusammen gespeichert werden, sowohl innerhalb des TSM als auch auf andere Datenträger wie z. B. USB-Festplatten. Für die BackupSets können abweichende Aufbewahrungsfristen vereinbart werden. So ist das von anderen Backup-Produkten bekannte GFS-Prinzip [8] abbildbar, ohne regelmäßige Vollsicherungen durchzuführen.
+Bisher hat die GWDG die Möglichkeit, BackupSets zusätzlich zu den normalen Aufbewahrungsfristen zu definieren, nicht angeboten,
+da für das Erstellen der virtuellen Vollsicherungen teilweisesehr umfangreiche Bandzugriffe für die schon vor längerer Zeit gesicherten Daten nötig sind. Diese konkurrieren mit den übrigen Zugriffen für Restore und Datenverschiebung auf Band. Die Erstellung von BackupSets kann daher sehr zeitaufwändig werden (teilweise mehrere Tage). Im Zusammenspiel mit „Active Data Pools“ können BackupSets mit geringem Aufwand erstellt werden. Sprechen Sie uns bei Interesse einfach an!
+==== Löschen von Daten auf Bandmedien ====
+Sowohl Festplatten wie Bandmedien werden in der Regel nur indirekt gelöscht. Zu löschende Daten werden als „löschbar“ markiert, verbleiben aber physikalisch auf dem Datenträger. Im Gegensatz zur Festplatte werden diese so freigegebenen Bereiche aber nicht wieder überschrieben, vielmehr nimmt der Füllgrad eines Bandes mit der steigenden Menge „gelöschter“ Daten ab, analog die genutzte Kapazität. Beim Erreichen eines minimalen Füllgrades erfolgt ein Umkopieren der verbliebenen gültigen Daten auf ein bisher unbenutztes Band, um die zuvor nur teilweise gefüllten Bänder wieder freizugeben. Üblicherweise wird der Grenzwert für diese Nachverdichtung (TSM-Fachbegriff „Reclamation“) so niedrig gewählt, dass die Daten mehrerer Bänder auf ein neues Band passen.
+Solange die durch die Reclamation freigegebenen Bänder nicht wieder überschrieben werden, sind die zuvor geschriebenen Daten im Prinzip weiter lesbar. Der Aufwand, diese mit Hilfe von TSM auszulesen, ist aber sehr hoch, da hierzu der TSM-Server selbst auf einen früheren Zeitpunkt, zu dem die betreffenden Daten noch auf den Bändern vorhanden waren, per Restore zurückgesetzt werden muss.
+===== FUNKTIONSWEISE „RESTORE“ =====
+Beim Restore arbeiten Client und Server eng miteinander zusammen, so dass keine getrennte Beschreibung des Vorgangs erfolgt. Grundsätzlich sind mehrere Restaurationsszenarien möglich:
+  - Der Benutzer wählt über die Client-Kommandozeile oder die GUI die zu restaurierenden Daten einzeln aus, der Client überträgt diese Anforderungen an den Server und liest diese Dateien von seinen Speicherbereichen, um sie an den Client zu übertragen.
+  - Der Benutzer wählt ganze Ordner oder Partitionen zur Restauration aus. Bedingt durch den „Incremental Forever“-Ansatz sind die dort enthaltenen Dateien zu verschiedenen Zeitpunkten gesichert worden, so dass der TSM-Server die zu restaurierenden Daten an  verschiedenen Stellen lesen muss.
+  - Die Wiederherstellung von Dateien, Ordnern oder ganzen Partitionen kann auch für einen beliebigen Zeitpunkt [9] in der Vergangenheit erfolgen. Auch hierfür müssen die Daten von verschiedenen Stellen zusammengesucht werden.
+Bei allen Restore-Operationen können erhebliche Wartezeiten auftreten, wenn verschiedene Magnetbänder gelesen werden müssen. Häufig entfällt auch viel Zeit auf das Spulen zu den richtigen Stellen auf den Bändern. Falls die zu restaurierenden Daten noch im Disk-Cache des Servers liegen, entfallen natürlich die Zeiten für das Laden und Spulen der Magnetbänder, und die angeforderten Daten können sofort übertragen werden. Active Data Pools beschleunigen den Restore der letzten gesicherten Version nochmals erheblich, da diese Daten dann auf Festplatten vorliegen und keinerlei Tape-Mounts erfolgen müssen. Das Wiederherstellen älterer Versionen ist auch mit Active Data Pools zeitaufwändig, da diese nicht im Active Data Pool liegen und dementsprechend von Band gelesen werden müssen.
+Analog zur Sicherung fasst der TSM-Server bei der Wiederherstellung Daten zu größeren Paketen zusammen, um sie schneller, also mit höherer Bandbreite, zu übertragen.
+Restore-Prozesse haben gegenüber allen anderen Prozessen Vorrang, dennoch kann infolge der zuvor genannten Zeiten für Tape-Mounts und Spulzeiten ein Restore subjektiv sehr lange dauern. Meist ist jedoch die Zeit bis zum Zurückschreiben der ersten Daten erheblich länger als die Zeit für das eigentliche Zurückschreiben.
+e===== FUSSNOTEN UND REFERENZEN =====
+  - Dokumentation zu den IBM Spectrum Protect Clients für [[https://www.ibm.com/docs/de/SSEQVQ_8.1.22/pdf/b_ba_guide_unx_lnx.pdf|Linux / UNIX]] und [[https://www.ibm.com/docs/de/SSEQVQ_8.1.22/pdf/b_ba_guide_win.pdf|Windows]]
+  - Zu den Unterschieden verschiedener Backup-Strategien siehe [[http://de.wikipedia.org/wiki/Datensicherung]]
+  - Natürlich gibt es hiervon auch Ausnahmen. Mit der Option [[https://www.ibm.com/docs/de/storage-protect/8.1.22?topic=reference-absolute|„ABSOLUTE“]] kann man eine Vollsicherung erzwingen. Wir raten hiervon aber ausdrücklich ab, da Vollsicherungen eigentlich nur erheblichen Aufwand bedeuten und TSM virtuelle Vollsicherungen erstellen kann (siehe hierzu weiter unten).
+  - //Deduplikation// ermittelt gleiche Dateien oder Teile davon und ersetzt diese durch Verweise auf das erste Vorkommen, vgl. [[http://de.wikipedia.org/wiki/Deduplikation]]
+  -  SSL=SecureSocketLayer, vgl. http://de.wikipedia.org/Transport_Layer_Security
+  - LTO-8, LTO9 mit bis zu 300 - 400 MB/sec, vgl. [[https://de.wikipedia.org/wiki/Linear_Tape_Open]]
+  - Da Dateiversionen gemäß den Aufbewahrungsfristen verfallen, sind virtuellen Vollsicherungen nur innerhalb der vereinbarten Aufbewahrungsfristen möglich.
+  - Grandfather-Father-Son-Prinzip; unterschiedliche Aufbewahrungsfristen für bestimmte Backups z. B. zum Wochenende, Monatsende, Jahresendbackup, [[http://de.wikipedia.org/wiki/Generationenprinzip]]
+  - Natürlich nur, sofern dieser Zeitpunkt innerhalb der Aufbewahrungsfristen liegt.