TSM : Petite mise en bouche

08/04/10

Tivoli Storage Manager, de son petit nom TSM, compte parmi les plus puissantes architectures dédiées aux sauvegardes / stockage / restauration de données. Seulement voilà, non content d’être une technologie propriétaire, c’est en plus un gros morceau à gérer… Enfin du moins au début.
Ce billet a donc pour vocation de découvrir les premiers concepts qui se cachent sous TSM et de vous lancer dans l’apprivoisement de ce géant bourru.

Fonctionnement général

TSM fonctionne sur un mode Client/Serveur, c’est-à-dire que le serveur TSM se tient à la disposition des Clients, nos nodes, afin que les sauvegardes soient faites. Selon la manière dont la sauvegarde est effectuée, les rôles varient.
En effet, sur une sauvegarde faite manuellement, le node sollicite le serveur TSM et lui demande d’effectuer une tâche bien précise (sauvegarde ou restauration).
Lorsque la sauvegarde est automatisée, c’est le serveur TSM qui sollicite le node -via un scheduler- et qui va lui demander les données à sauvegarder. Le node endosse ainsi la fonction de serveur (en perpétuelle écoute de requête en provenance du serveur TSM).

Au sein de l’architecture TSM, un node se définit par rapport à d’autres entités, qui permettent notamment d’organiser et de paramétrer au plus fin les détails liés aux sauvegardes à faire. Logiquement, on a :

• Policy
  • Domain
    • CLOptSet (jeu d’options pour le domaine (INCLEXCL), optionnel)
      • Schedule (planification des sauvegarde)
        • Node (noeud à sauvegarder)

Les mains dans le cambouillis

Sur de l’opérationnel

L’appel du terminal se fait par dsmadmc, qui, par défaut, ouvre une interface de commande avec le serveur TSM. Il est également possible de stipuler la commande sur la même ligne que dsmadm. Ainsi, dsmadm exécutera la commande, fermera l’invite de commande tsm et rendra le terminal à l’utilisateur.
Dans un système qui fonctionne, on peut interroger l’existant grâce à la commande QUERY -abrégée en q-
QUERY sert à rapporter un état précis du système, par exemple, l’état des processes qui tournent et s’il y en a (q proc), les associations existantes (q association)…

tsm: TSMSERVER>q policy

Policy        Policy        Default       Description
Domain        Set Name      Mgmt
Name                        Class
Name
---------     ---------     ---------     ------------------------
NDMP          ACTIVE        STANDARD
[...]

tsm: TSMSERVER>q domain

Policy        Activated     Activated      Number of     Description
Domain        Policy        Default       Registered
Name          Set           Mgmt               Nodes
Class
---------     ---------     ---------     ----------     ------------------------
NIX          STANDARD      STANDARD             205     serveurs UNIX
[...]
tsm: TSMSERVER>q sched
Domain           *     Schedule Name        Action     Start Date/Time          Duration     Period     Day
--
NIX                   Schedbux             Inc Bk     27-05-2008 00:00:00          8 H        1 D      Any
[...]

Ce qui revient à dire que, lorsque l’on arrive sur un système TSM tout frais, prêt à être installé, il faut donc créer et paramétrer tout le système.

Sur du tout neuf

Et bien, allons-y, recréons tout ça !
L’invite dsmadmc lancée, vous pouvez d’ores et déjà vous essayer à créer tout ce bazard. Et si vous bloquez sur une option, il existe une commande help qui, invoquée seule, vous énumérera l’ensemble des catégories qu’elle détient, et sinon, si vous savez sur quelle commande vous bloquez, il suffit de lancer help <commande> pour avoir accès à tout le descriptif, illustré d’exemple, de ladite commande. Alors pas de panique !

Petit aperçu de comment faire…

1. Créer un domaine, avec ou non son set d’option :

define domain domainname [...]
define cloptset cloptsetname [...]
define clientopt cloptsetname inclexcl "exclude.dir /tmp*"
[...]

2. Définir une policyset :

define policyset domainname policysetname [...]

3. Définir sa mgmtclass ou utiliser celle par défaut (STANDARD)

define mgmtclass domainname policysetname classname [...]

4. Assigner la mgmtclass définie (on peut utiliser celle par défaut en mentionnant STANDARD en lieu et place de classname) :

assign defmgmtclass domainname policysetname classname [...]

5. Valider la policyset (il n’existe qu’une et une seule policyset activée à un instant donné) :

validate policyset policysetname [...]
activate policyset policysetname [...]

6. Créer un schedule et fixer le schedule et les paramètres de sauvegarde pour le node :

define sched domainname schedname nodename action=Incremental|[...voir help define sched] desc=\\\"description\\\" type=client scheds=classic startDate=11/25/2005 startTime=20:00:00 period=1 perunits=days priority=1 duration=8 durUnits=hours

7. Enregistrer le node dans le domaine, ainsi que ses paramètres de connexion au service :

register node nodename nodepasswd passexp=0 contact=contact\@bux.fr domain=domainname cloptset=optionsetname forcepwreset=no url=http://nodename:1581

8. Définir l’association entre le domain, le schedule et le node :

define association domainname schedulename nodename

9. Customiser le node :

update node nodename [...]

Et lorsqu’on veut supprimer des nodes…

D’abord supprimer ses data :

delete filespace nodename *

Et enfin supprimer le node :

remove node nodename

En cas, supprimer le schedule, si on lui a attribué un schedule rien que pour lui :

delete schedule domainname schedulename

Et oui, ce n’est pas de tout repos…