Inhaltsbereich

Das ITSC als IT-Dienstleister der MUW stellt den Berechtigten das Backup/Archivsystem TSM zur Verfügung, mit dem Dateien zentral gesichert und/oder archiviert werden.

TSM ist das Akronym für Tivoli Storage Manager, einer Client-/Serversoftware von IBM Tivoli, mit der Dateien von einem Client (TSM-Node), der auf einem realen oder virtuellen System installiert ist, nach definierten Regeln auf einen Server (TSM-Server) kopiert bzw. von diesem abgerufen werden können.

TSM-Nodename ist die systemweit eindeutige Bezeichnung, mit der ein TSM-Node (TSM-Knoten) auf einem TSM-Server registriert ist.

Kontaktperson ist eine physische oder juristische Person, die für den jeweiligen TSM-Node verantwortlich ist. In der Regel sind es BenutzerInnen und/oder BetreuerInnen des jeweiligen Systems.

Das Ansuchen für die Teilnahmeberechtigung erfolgt über einen Antrag in der jeweils geltenden Fassung.

Jede Kontaktperson erhält nach genehmigtem Antrag die Zugangsberechtigung mit TSM-Nodenamen und TSM-Passwort.

Falls eine Kontaktperson eines TSM-Nodes das Passwort vergessen hat, wird das Passwort vom ITSC neu gesetzt und allen Kontaktpersonen dieses TSM-Nodes per Email mitgeteilt

Berechtigungen

• Teilnahmeberechtigt ist jedes reale und virtuelle System im Datennetz der MUW.
• Weiters teilnahmeberechtigt sind alle Systeme in Organisationen, für die Sondervereinbarungen gelten.
• Die 1.Kontaktperson (BenutzerIn) muss eine gültige MUW-User-ID haben.

Verantwortliche

• Als Verantwortliche gelten die Kontaktperson(en) sowie alle den Antrag unterzeichnenden Personen.

1. Die Teilnahmeberechtigung gilt ausschließlich für das im Antrag angegebene System. Eine Mitnahme auf ein anderes System ist ohne neuen Antrag nicht zulässig.
2. Das Passwort ist geheim zu halten.
3. Dem ITSC ist rechtzeitig mitzuteilen:
   • jede Änderung der Kontaktpersonen
   • jeder Wechsel der Betriebssystemplattform,
     bzw. des DNS Namens
   • die Unterbrechung der Teilnahme z.B. durch Karenz, Geräteabbau u.dgl.
   • die Beendigung der Teilnahme am Backup-Service.
4. Die Kontaktperson ist weiters verantwortlich
   • für die korrekte Installation, die Wartung und die Aktualisierung der TSM-Client-Software
   • für die Einrichtung und Aktualisierung der Konfigurationsdateien (dsm.opt, dsm.sys)
   • für einen regelmäßigen Ablauf des Backupvorganges
   • für die Kontrolle der TSM-Logdateien auf Seite des Clients.

1. Das ITSC betreibt die Infrastruktur des TSM Service (TSM Server, SAN, Bandroboter) inklusive Wartung und Aktualisierung der relevanten Software und Hardware.
2. Das ITSC ist für die ordnungsgemäße Datenhaltung der von den TSM Clients gelieferten Daten im Rahmen der getroffenen Vereinbarungen verantwortlich.

Das ITSC ist nicht verantwortlich für Verluste, die durch Fehler in der Server- und/oder Clientsoftware, Fehler in der verwendeten Hardware sowie fehlerhafte oder defekte Medien entstehen.

Jede Verwendung, die gegen diese Regelung verstößt, ist unzulässig.

In allen nicht angeführten Fällen und in Streitfällen liegt die Entscheidung über die Teilnahmeberechtigung beim ITSC bzw. beim Rektorat.

Das ITSC kann für einen bestimmten Bereich oder Zweck mit einem Benutzer besondere Vereinbarungen treffen. Diese bedürfen der Schriftform. Eine solche Vereinbarung leitet keinen Rechtsanspruch für andere Benutzer ab.

Bei Nichteinhaltung dieser Regelung kann das ITSC unverzüglich und ohne vorherige Warnung des Benutzers die zur Aufrechterhaltung des ordentlichen Betriebs notwendigen Maßnahmen setzen. Die Entscheidung über Art und Umfang der Maßnahme trifft das ITSC. Der/die Verantwortliche wird über die getroffenen Maßnahmen und eventuelle weitere Folgen vom ITSC benachrichtigt.

Die TSM Knoten werden – auch aus lizenzrechtlichen Gründen – wie folgt unterschieden:

• Desktop Systeme sind Einzelplatzrechner, die keine Services für andere Rechner/Systeme anbieten.
• Mobile Systeme (Notebooks, Laptops)
• Server sind physische oder virtuelle Systeme, die Services für andere Rechner/Systeme anbieten

 

Regeln für alle TSM Knoten

1. Zulässig ist nur die Sicherung jenes Systems, das bei der Registrierung des Knotens angegeben wurde.
2. Beantragte und registrierte TSM Knoten, die nicht innerhalb von 3 Monaten eingerichtet und eine Erstsicherung durchgeführt haben, werden automatisch ohne Benachrichtigung entfernt.
3. Externe Netzwerkressourcen bedürfen eines gesonderten TSM Knotens für Server (gilt als Dateiserver). Registrierung, Einrichtung und Konfiguration NUR nach Rücksprache mit der Backupadministration. Die Sicherung kann nach Rücksprache mit der Backupadministration über das NDMP-Protokoll bzw. durch einen Desktopknoten durchgeführt werden.
4. Dateisysteme (Filespaces), die sechs Monate nicht erfolgreich gesichert wurden (Backup), werden nach rechtzeitiger Benachrichtigung der Kontaktperson(en) per Email entfernt. Aus diesen Dateisystemen archivierte Dateien sind davon nicht betroffen. Es gilt das Backupdatum aus dem Befehl ‚dsmc query filespace’
   Achtung: Dieses Backupdatum wird nur und ausschließlich beim erfolgreichen incremental Backup gesetzt!
5. TSM Knoten, die länger als 6 Monate nicht mehr auf den TSM Server zugegriffen haben, werden inaktiviert und nach rechtzeitiger Benachrichtigung der Kontaktperson(en) per Email vom Server entfernt. Davon ausgenommen sind TSM Knoten, für die rechtzeitig eine längere Bewahrfrist vereinbart wurde (Karenz, Archiv etc.).

… für Desktop Rechner

1. Es laufen keine Dienste im Sinne eines Servers (Fileserver, Webserver, etc.)
2. Es werden ausschließlich lokale Ressourcen gesichert (eingebaute Festplatten, keine Netzlaufwerke, keine CDs/DVDs, keine Time-Machine Laufwerke o.Ä.)
3. Sicherungen, die diesen beiden Kriterien nicht entsprechen werden entfernt. Kriterium ist der Filespacename z.B.: \\HOSTNAME\c$ und der Dateisystemtyp (keine CDFS o.Ä. bzw. Filespaces mit der IP-Adresse im Filespacenamen)

… für mobile Rechner

1. Für Laptops gelten die gleichen Regeln wie für Desktops, mit dem Unterschied, dass für mobile Rechner keine automatische (scheduled) Sicherung vorgesehen ist, da diese Rechner nicht zwingend mit dem Datennetz der MUW verbunden sind.
2. Regelmäßige Sicherungen müssen anderwärtig gewährleistet werden (manuell, Shutdown Skipts, etc.).

… für Server

1. Vor der Registrierung eines Servers ist mit dem ITSC Kontakt aufzunehmen, um ein an die Bedürfnisse des Benutzers angepasstes Backupkonzept festzulegen zu können. Hierzu sind Informationen bezüglich der maximalen Werte für tägliches Sicherungsvolumen, maximale Anzahl an zu sichernden Dateien und deren Speichervolumen notwendig.
2. Aus lizenzrechtlichen Gründen ist am Antrag die Hardwareausstattung des Rechners hinsichtlich CPU bekanntzugeben. Diesbezügliche Änderungen (Hardwarewechsel bzw. –tausch) sind der Backupadministration mitzuteilen oder über ein Softwareprogramm (ILMT Agent) an einen zentralen Server zu übermitteln.
3. Sicherungen für Server sind generell servergesteuert (scheduled) durchzuführen, um einen reibungslosen Ablauf der notwendigen administrativen Serverprozesse gewährleisten zu können.

Aufbewahrungsfristen

Die Verweilzeiten der gesicherten bzw. archivierten Dateien auf dem jeweiligen TSM Server werden in Managementklassen festgelegt. Es gibt Standard-Managementklassen und speziell vereinbarte Klassen, falls der Standard nicht ausreichend ist.

Diese Vereinbarungen sind vor Inbetriebnahme des TSM Knotens mit dem ITSC abzuklären. Die gültige(n) Defaultklasse(n) sind auf der Webseite einzusehen.

Das ITSC behält sich vor, diese Standards im Bedarfsfall nach entsprechender Ankündigung zu ändern.

Das TSM Service steht im Normalfall 7x24h zur Verfügung. Wartungsarbeiten werden in den Wartungsfenstern des ITSC durchgeführt. Arbeiten, die nicht in der angegebenen Zeit abgeschlossen werden können oder wegen schwerwiegender Gründe zu einem anderen Zeitpunkt durchgeführt werden müssen, werden so weit möglich rechtzeitig angekündigt.

• Nach erfolgter Registrierung des TSM Knotens werden die Zugangsdaten per Email verschickt.
• Bei Änderungen der Definitionen für den TSM Knoten.
• Bei Löschung des TSM Knotens.
• Bei auffälligem Verhalten der clientseitigen TSM-Prozesse.
• Bei Servern mit Scheduled Services werden die Kontaktpersonen standardmäßig automatisch nach fehlerhafter oder fehlender Durchführung des Service per Email verständigt, bei Desktop Clients nur in Ausnahmefällen.
• In speziellen Fällen ist täglicher Report für eine Gruppe von Clients per Email möglich.
• In regelmäßigen Abständen werden die TSM Knoten und deren Dateisysteme auf Inaktivität überprüft. Werden im Zuge dieser Überprüfung Abweichungen von den Regelungen festgestellt, werden die betroffenen Clientadministratoren ebenfalls benachrichtigt.
• Wichtige Informationen werden über eine Mailing Liste an alle Kontaktpersonen verschickt.

• TSM ist lizenzpflichtige Software.
• Derzeit werden die Lizenz- und Wartungskosten für die TSM-Clients vom ITSC getragen. Das ITSC behält sich vor, diese Kosten oder Teile der Kosten an die TSM Client Benutzer weiterzugeben. Für Serversysteme ist dieser Betrag in jedem Falle zu entrichten.
• Das ITSC behält sich vor, für Installationen mit großen Datenmengen Beiträge für Bandmedien zu berechnen.

Kontaktadresse am ITSC: backup-admin@meduniwien.ac.at

Nach oben

Bei der Registrierung eines TSM-Knotens wird ihm je nach Art des Clientrechners eine TSM Serverinstanz und eine Policy Domain zugewiesen. Die Zugehörigkeit zu einer Policy Domain legt für den TSM Knoten fest, mit welchen Managementklassen er seine Daten sichern kann, zu welchen Zeiten automatische Sicherungen durchgeführt werden (Schedules) sowie welche Wege die Sicherungsdaten in der Speicherhierarchie nehmen. Neben den serverinternen Definitionen gelten für die verschiedenen Policy Domains auch organisatorische Regelungen.

Im Wesentlichen werden dabei die Clienttypen

• Desktop-Rechner,
• Laptops
• Interne Server
• und Klinik-/Institutsserver

unterschieden.

Jede Policy Domain bietet dem Benutzer eine Anzahl von Managementklassen, welche festlegen, wie der Server mit zu sichernden bzw. den bereits gesicherten Daten verfährt.

• Es gibt getrennte Managementklassen für die Funktionen BACKUP und ARCHIVE.
• Für die Funktion BACKUP ist eine Default Managementklasse definiert, welche herangezogen wird wenn keine gesonderte Vereinbarung vorliegt.
• Für die Funktion ARCHIVE ist die anzuwendende Managementklasse jedesmal anzugeben.

Welche Managementklassen zur Verfügung stehen, zeigt der Befehl ‚dsmc q mgmt’ sowie der Befehl ,View Policy Information’ im GUI, der zusätzlich noch die Parameter der einzelnen Managementklassen auflistet:

Bedeutung der Parameter:

Funktion	Parameter	Bezeichnung	Bedeutung
BACKUP	VDE	Versions Data Exists	max. Versionen, wenn die Datei am Client vorhanden
	VDD	Versions Data Deleted	max. Versionen, wenn die Datei am Client gelöscht
	REV	Retain Extra Versions	max. Verweildauer inaktiver Versionen in Tagen ab Sicherungsdatum
	ROV	Retain Only Version	max. Verweildauer der letzten Version in Tagen ab Sicherungsdatum, wenn die Datei auf dem Client gelöscht
ARCHIVE	RV	Retain Version	max. Verweildauer des Archives in Tagen

Copy Serialization

Legt fest, wie die Datei verarbeitet wird, wenn sie sich während des Backupvorganges verändert bzw. in Bearbeitung ist:

STATIC
Wenn sich das zu sichernde Objekt während des Sicherungsvorganges verändert oder in Bearbeitung ist, wird es nicht gesichert.

DYNAMIC
Wenn sich das zu sichernde Objekt während des Sicherungsvorganges verändert oder in Bearbeitung ist, wird bereits beim ersten Versuch der temporäre Zustand des Objektes gesichert.

CHANGINGRETRIES
Eine TSM Option, die festlegt, wie viele erneute Versuche unternommen werden, um eine Datei die zum Zeitpunkt der Sicherung in Bearbeitung (‚in use’) ist, nochmals zu sichern. Defaut: 4 Versuche

SHRSTATIC
Wenn das zu sichernde Objekt während des Sicherungsvorganges verändert wurde oder in Bearbeitung ist, werden die mit der Option CHANGINGRETRIES festgelegten erneuten Versuche unternommen, das Objekt zu sichern. Ist das Objekt beim letzten Versuch noch in Bearbeitung wird es nicht gesichert.

SHRDYAMIC
Wenn das zu sichernde Objekt während des Sicherungsvorganges verändert wurde, werden die mit der Option CHANGINGRETRIES festgelegten erneuten Versuche unternommen, das Objekt zu sichern. Ist das Objekt beim letzten Versuch noch in Bearbeitung, wird der temporäre Zustand des Objektes gesichert.

Anwendung bei der Sicherung von Logfiles u.Ä.

Beispiel:
Managementklasse DATA003DY
Versions Data Exist = 3
Versions Data Deleted = 1
Retain Extra Versions = 30
Retain Only Version =185
Serialisation = SHRDYNAMIC

Es werden maximal 3 Versionen am Backupserver gespeichert (1 aktiv, 2 inaktiv), solange die Datei am Clientrechner existiert. Die aktive Version verbleibt solange gesichert, wie sie auf dem Clientrechner existiert. Die inaktiven Versionen werden nach 30 Tagen ab Sicherungsdatum gelöscht. Wird die Datei auf dem Clientrechner gelöscht, so verbleibt eine inaktive Version ein halbes Jahr (185 Tage) ab Sicherungsdatum am Server und wird anschließend gelöscht.

Clienttyp	Klasse	VDE	VDD	REV	ROV	Serialization
Workstation	DATA001	1	1	0	31	SHRSTATIC
Server	DATA003	3	1	30	185	SHRSTATIC

Alle Änderungen, die den TSM Knoten betreffen, sind an die TSM Administration zu melden. Änderungsmitteilungen erfolgen per Formular (gleich mit dem Antragsformular -> Änderung)

Bei Änderung folgender Daten ist rechtzeitig die Backupadministration zu verständigen:

• Kontaktperson(en)
• TCP/IP Name der Datenstation
• Betriebsystemversion (Win2000, WinXP, WinVista, Win2003, PowerMAC, IntelMAC etc.)
• Betriebssystemplattform (z.b. Windows nach Mac)
• Art der Datenstation (Desktop -> Server) … (TSM Lizenz)
• Hardwaretausch (Neuinstallation)
• Für Serversysteme jede Änderung bzgl. Typ und Anzahl der CPU (Cores)
• Abmeldung vom Datennetz der MUW (-> Löschung des Knotens)

Nach oben

Nodenamen

Knotennamen (Nodenamen) werden standardmäßig aus dem IP-Namen gebildet:

IP-Name:	Hostname.Subdomain.meduniwien.ac.at
Node-Name :	Subdomain.Hostname

z.B. für den IP-Namen alpha.klinik.meduniwien.ac.at lautet der Nodename klinik.alpha

Sollten für einen IP-Namen mehrere Nodenamen benötigt werden, so entscheidet der Administrator.

Server (Adressen, Ports)

Jeder registrierte Knoten wird einer Serverinstanz zugeordnet. Da manche TSM Serverinstanzen auf demselben physischen Server liegen, wird der Zugriff durch Serveradresse und Port bestimmt. Die dem Knoten zugeordnete Kombination aus Adresse und Port wird in der Registrierungsmail mitgeteilt. Sollten sie keine speziellen Angaben finden, so gelten in der Regel die Werte für Desktop-Rechner.

Gerätetyp	TCPSERVERAddress	TCPPort
Desktop-Rechner	backup.meduniwien.ac.at	1500
Laptops
Verwaltungsrechner
Verwaltungsserver	tsm2.meduniwien.ac.at	1600
Klinik/Institutsserver	tsm3.meduniwien.ac.at	1700

Zwei physische Server (IBM p-Series unter AIX) beherbergen 5 TSM Serverinstanzen mit geteilten Aufgaben- bzw. Clientgruppen.

Physischer Server	TSM Instanzen	Aufgabe
IBM 9113-550 Zilli	TSM0, TSM1	Bandverwaltung, Client Access Desktopclients
IBM 9111-520 Zoe	TSM2,TSM3,TSM4	Client Access Interne und Klink-/Institutsserver

Aktuell ist der Server auf Softwarelevel 5.5.4
Ein Umstieg auf die neue Version 6.2 ist nicht vor dem zweiten Quartal 2011 vorgesehen.

Das TSM Service an der MUW ist auf zwei physischen Servern der Firma IBM unter dem Betriebssystem AIX implementiert. Der eine Server ist eine IBM 9113-550 mit 2 Prozessoren und 16 Gigabyte Hauptspeicher, der zweite eine IBM 9111-520 mit 4 Prozessoren und 32 Gigabyte Hauptspeicher. Beide Server sind mit Gigabit Ethernet Adaptern an das Datennetz der MUW angebunden.

Die Sicherungsdaten werden auf Festplattenbereichen im Speichernetzwerk der MUW zwischengespeichert. Die Plattenbereiche in der Größenordnung von etwa 5 Terrabyte für alle Serverinstanzen liegen auf Storage Arrays der Firma HDS, die mit einer Bandbreite von 4 Gbit/s im SAN (Storage Area Network) der MUW eingebunden sind.

Bei der Migration der Sicherungsdaten auf Bandspeicher werden die Daten auf zwei Bandrobotern des Typs IBM 3494 abgelegt. Der eine Roboter befindet sich im Serverraum der MUW im AKH-Kerngebäude. Er verfügt über 16 Bandlaufwerke des Typs IBM TS1120 (3592-E05) sowie 3250 Plätze für Bandkassetten mit einer unkomprimierten Kapazität von 500 Gigabyte je Kassette. Dies stellt ein theoretisches Fassungsvermögen von 1,625 Petabyte (unkomprimiert) dar. Der zweite Bandroboter im Bauteil 88 hat mit 4 Bandlaufwerken und 600 Kassettenplätzen des gleichen Typs eine umkomprimierte Kapazität von etwa 300 Terabyte. Dieses Bandsubsystem verwaltet Kopien aller unternehmenskritischen Sicherungsdaten für eine Wiederherstellung im Katastrophenfall.

Nach oben

Weiter zu: Antrag & Implementierung