Université Catholique de Louvain-La-Neuve Unité PCPM Jean

Université Catholique de Louvain-La-Neuve
Unité PCPM
Jean-Paul Minet
Place Croix du Sud, 1
B-1348 Louvain-La-Neuve
Votre lettre du
Vos références
Nos références
Date
B/O/152/A/02/SD
02/12/2002
Cher Monsieur Minet,
Veuillez trouver ci-joint notre proposition pour votre projet pilote de service de sauvegarde – UCL.
Les solutions sont basées sur les informations échangées lors des réunions et des notes techniques
préliminaires.
Les prix mentionnés sont à titre budgétaire.
Nous estimons avoir toutes les compétences requises afin de mener à bien les tâches imparties dans le
cadre de la solution que vous souhaitez. Un serveur ADSM est d’ailleurs déjà utilisé pour la gestion de
la migration de données SAP au SIA de l’UCL.
N’hésitez pas à nous contacter pour de plus amples informations.
Veuillez recevoir, cher Monsieur Minet, l’expression de nos sentiments distingués
Steven Decuypere
I.R.I.S. Storage & Systems
Account Manager
Olivier Thoelen
I.R.I.S. Storage & Systems
Directeur Technique
1.
Introduction
Tivoli Storage Manager
Tivoli Storage Manager est une application client/serveur qui permet de prendre les backups de manière
centralisée à travers un réseau.
Le serveur est la machine qui contrôle les devices (pool disques, pool K7, …) et qui va prendre en
charge les données que les différents clients vont lui envoyer. Il est construit autour d’une base de
données propriétaire (DB2) qui lui permet de gérer toutes les informations des clients. Le serveur est
disponible sur différentes plate-formes (AIX, NT, MVS, OS/400, VM, …) et supporte différents
protocoles de communication (TCP/IP, IPX, SNA, …).
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 2
Sur les autres systèmes, ceux dont on veut faire des sauvegardes on installe le code TIVOLI STORAGE
MANAGER client. Cette application a pour but de parcourir les données de la machine, d’établir la
communication avec le serveur, et d’envoyer les données à sauvegarder au serveur. Le client possède
différentes fonctionnalités que nous allons passer en revue:
Voici une liste non exhaustive des principaux avantages :
•
Utilisation d’une vraie base de données relationnelle
•
Mécanisme de backup progressif
•
Processus automatique de recyclage des cassettes, qui permet d’utiliser de manière beaucoup
plus efficace l’espace de stockage disponible
•
Gestion centralisée,
•
La fonction Enterprise management permet la gestion de plusieurs serveurs Tivoli Storage
Manager à partir d’un point central.
•
Utilisation d’un cache disque :les données d’un client peuvent indifféremment être dirigées vers
des disques,
une bandothèque, une librairie optique. Sauvegarder préalablement et
temporairement les données sur disques, permet de prendre en compte plusieurs clients
simultanément et créer ainsi plus de tâches de sauvegarde que le nombre de lecteurs disponibles
sans être obligé d’intercaler des données de clients différents dans le même flot. Par ailleurs,
faire transiter les données par une zone de cache, permet à Tivoli Storage Manager de les
réorganiser avant écriture sur bande de manière à permettre une restauration la plus performante
possible.
•
Plus grande fiabilité et disponibilité des données : Tivoli Storage Manager ne stripe pas les
données sur des cassettes différentes. Ce qui élimine la nécessité de disposer de plusieurs
lecteurs dans le cas d’une restauration. Le fait de disposer d’une zone de cache permet une
diminution du temps de restauration pour des fichiers individuels.
•
La possibilité de construire des scénarios de Disaster Recovery,
•
Des fonctionnalités comme l’Instant Archive ou le Rapid Recovery,
•
La prise en compte de l’informatique diffuse, avec la prise en compte par exemple des
utilisateurs mobiles.
•
La prise en compte des nouvelles technologies (SAN-enabled/Tape Pooling, Lan-Free, ServerFree, …)
•
Un Total Cost of Ownership (TCO) très bas avec :
o Une gestion plus efficace de l’espace de stockage d’une librairie (media reclamation,
bandes mieux remplies),
o Moins d’intervention des opérateurs (gestion automatique des bandes on-site et off-site),
o Un coût d’administration plus faible (les utilisateurs peuvent enclencher un processus de
restauration sans faire intervenir un administrateur),
o Un coût plus faible des médias (moins de bandes ou de cassettes),
o Un coût plus bas pour bâtir et maintenir des scénarios de Disaster Recovery.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 3
La fonctionnalité de “Sauvegarde et Restauration”
La fonctionnalité la plus importante du client est de pouvoir faire des sauvegardes et de la restauration.
La sauvegarde du client consiste à envoyer à travers le réseau les données. Ces données vont être
stockées sur le serveur et inventoriées dans la base de données du serveur. Elles vont dépendre de
paramètres qui détermineront leurs cycles de vie dans le serveur TIVOLI STORAGE MANAGER. La
sauvegarde peut se faire de trois manières différentes : soit de manière incrémentale (on ne sauvegarde
que les modifications), soit de manière sélective (on prend une sauvegarde de fichiers choisis), soit de
manière complète (on prend une image complète des données).
Pour les sauvegardes, le serveur TIVOLI STORAGE MANAGER gère entièrement les versions
multiples c’est à dire que pour une donnée on peut disposer de plusieurs versions différentes. Il va de
soit que l’on peut automatiser complètement tout le processus de sauvegarde.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 4
La fonctionnalité d’ “Archivage et Rappel”
Une autre fonctionnalité incluse dans le code client c’est l’archivage et le rappel. Le rôle de cette
fonctionnalité est de faire une sauvegarde à un moment donné et de la stocker pour du long terme. La
copie obtenue va dépendre uniquement d’une durée de rétention, il n’y a pas de gestion de version. Cette
fonctionnalité ne doit pas être utilisée pour de la sauvegarde journalière.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 5
La fonctionnalité de “Gestion d’espace de stockage”
Cette fonctionnalité permet de faire de la gestion de stockage. En fait c’est un mécanisme de contrôle de
structure de fichier, qui selon un algorithme que l’on définit (le plus ancien, le plus grand, le moins
accédé,…), va migrer automatiquement des fichiers pour libérer de l’espace sur la source. Ce
mécanisme est également responsable de la récupération transparente et automatique des données
migrées si on fait un accès à ces données.
La fonctionnalité de l’ “interface de programmation”
Une autre fonctionnalité client est l’interface de programmation TIVOLI STORAGE MANAGER. C’est
en fait une librairie de fonctions mise à disposition des développeurs qui contient tout ce qui est
nécessaire pour le développement d’applications TIVOLI STORAGE MANAGER. L’exploitation des
ces APIs est surtout faite par des « third-party vendor » qui mettent à disposition du grand public des
utilitaires qui permettent la prise de sauvegarde à chaud de base de données (Oracle, Sybase, Exchange,
SqlServer, … .). En effet, certaines applications nécessitent l’utilisation d’outils spécifiques pour
l’extraction des données qu’elles manipulent afin d’en garantir l’intégrité et la consistance. Par
conséquent on ne peut pas se satisfaire d’une simple copie du fichier contenant les données (Voir
annexes : outils de gestion des applications avec Tivoli Data Protection for ou SQL/BT).
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 6
L’interface client WEB
Une autre fonction fournie par le code client TIVOLI STORAGE MANAGER est l’interface WEB.
C’est une « applet java » qui tourne sur la machine dont on prend la sauvegarde et qui permet via un
Web-Browser de sauvegarder, restaurer, archiver et ce au travers d’une interface graphique et conviviale
au look windows explorer.
Le client Administratif
La dernière fonctionnalité fournie par le client est une interface d’administration du serveur. C’est en
fait un client particulier qui établi une connexion avec le serveur dans le but de faire de l’administration
et non de la sauvegarde. Cette fonctionnalité amène la possibilité de gérer le serveur à partir d’un autre
poste sur le réseau.
Le serveur Tivoli Storage Manager
Le serveur TIVOLI STORAGE MANAGER est une machine dédicacée qui accumule les données
envoyées sur le réseau par les clients TIVOLI STORAGE MANAGER. Il faut donc un serveur puissant
en I/O, car en effet, les données arrivent sur le réseau et sont stockées sur des devices que le serveur
pilote. Le cœur du serveur TIVOLI STORAGE MANAGER est une base de données relationnelles.
Afin de pouvoir faire la gestion du serveur il est impératif d’aborder quelques concepts qui permettront
de mieux comprendre la philosophie TIVOLI STORAGE MANAGER.
Techniques de sauvegarde
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 7
On dispose de plusieurs méthodes pour pouvoir faire des sauvegardes.
Sauvegarde complète (full backup): chaque jour on prend une image complète des données ce qui
veut dire qu’un grand nombre de données sont sauvegardées inutilement car elles sont inchangées.
Méthode consommatrice de temps, de ressources.
Sauvegarde incrémentale : la base de cette méthode est une sauvegarde complète suivie de sauvegarde
des modifications. Cette méthode raccourcit le temps de sauvegarde mais consomme plus de médias et
rend plus complexe la restauration. De plus c’est un jeu complet (full + incrément) qui correspond à une
situation propre.
Sauvegarde différentielle : cette méthode est en fait une évolution de la méthode incrémentale. Il s’agit
d’une concaténation de sauvegardes incrémentales. Le but est de diminuer le nombre de médias à
manipuler lors de restauration.
Sauvegarde incrémentale permanente : cette méthode consiste à prendre une seule fois une
sauvegarde complète et ne faire ensuite que des incrémentaux.
Il va de soit que TIVOLI STORAGE MANAGER privilégie cette dernière technique. Grâce à sa base de
données relationnelle, TIVOLI STORAGE MANAGER garde un historique complet des données
sauvegardées et permet l’accès direct à la donnée souhaitée.
Lexique TIVOLI STORAGE MANAGER
Beaucoup d’objets sont manipulés dans TIVOLI STORAGE MANAGER. Il est donc intéressant de
passer les principaux en revue :
Domain : Ensemble générique regroupant des administrateurs, clients TIVOLI STORAGE
MANAGER, et policy set. Par domaine il n’y a qu’une et une seule policy set active à la fois.
Policy Set : Ensemble regroupant les classes de gestion. Chaque policy set a sa classe de gestion par
défaut.
Management Class :Ensemble regroupant les caractéristiques définissant la manière de gérer les
sauvegardes. Chaque donnée d’un client TIVOLI STORAGE MANAGER va être assignée à une classe
de gestion.
Copy Group : Ensemble de caractéristiques définissant la politique de sauvegarde.
Storage Pool : Espace de stockage indépendant du hardware auquel il se réfère. C’est le récipient pour
les données sauvegardées.
Device Class : C’est le lien entre l’espace de stockage et le device lui-même. C’est par cet objet que
TIVOLI STORAGE MANAGER reconnaît quel device doit être manipulé.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 8
La gestion par règle
On définit dans TIVOLI STORAGE MANAGER la politique de sauvegarde sous forme de règles. Ces
règles vont être associées aux données lors des sauvegardes. Les règles de gestion sont composées de
caractéristiques qui vont définir comment le serveur doit gérer les données qui lui sont envoyées : « les
copy group ». Dans TIVOLI STORAGE MANAGER on peut faire de la sauvegarde, de l’archivage, et
de la gestion hiérarchique de données, donc il existe trois types de copy group. Pour des données on peut
donc à chaque fois définir trois types de caractéristiques que l’on regroupe dans une classe de gestion :
« la management class ». Les différentes caractéristiques sont reprises dans le schéma ci-dessus pour
chaque type : sauvegarde, archivage et hiérarchique.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 9
La base de données TIVOLI STORAGE MANAGER
TSM Server Database
Database
Client node information
Client file information
Policies
Schedules
Alternate 2
Alternate 1
Primary
DB
RLog
Space
Recovery Log
Describes changes to DB
High performance read
Mirrored for high availability
Automatic alternate volume switching
Dynamically expand/contract
Full or incremental backup
while server active
Le cœur de l’application TIVOLI STORAGE MANAGER est sa base de données. Cette base contient
les informations sur les clients, sur les fichiers des clients, sur les politiques de sauvegarde, sur les
procédures automatiques, etc. Toutes les modifications sont journalisées dans un recovery log. Compte
tenu de l’importance de cette base de données, TIVOLI STORAGE MANAGER fournit des
mécanismes de protection tels que :
•
le mirroring,
•
la sauvegarde (complète ou incrémentale),
•
le dump.
TIVOLI STORAGE MANAGER utilise une vraie base de données relationnelles avec un mécanisme de
« two phase commit ». Cette base de données est accessible uniquement au travers de l’interface
d’administration de TIVOLI STORAGE MANAGER.
Pour une plus grande flexibilité on dispose d’une interface SQL pour interroger la base et en extraire les
informations souhaitées. On dispose également des drivers ODBC afin d’importer les données dans
d’autres applications comme ACCESS, EXCELL,…
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 10
Les Storage Pools
TSM Storage Pools
Storage Pool Assignment
Storage Hierarchy Management
Reclamation
Collocation
Caching
Server Recovery
TIVOLI STORAGE MANAGER fait une représentation hiérarchique des devices. La destination des
données sauvegardées est un espace de stockage et non pas un device spécifique. TIVOLI STORAGE
MANAGER stocke les données sur disque magnétique, sur disque optique (un grand nombre de
librairies optiques sont supportées), sur bande magnétique (un grand nombre de dérouleurs de bandes
sont supportés), et sur un autre serveur TIVOLI STORAGE MANAGER. Cette représentation de
devices apporte une grande flexibilité de configurations et une certaine quantité de fonctionnalités.
La destination de données sauvegardées ou archivées ou bien encore migrées est une classe de gestion.
A chaque type de caractéristiques est associé un storage pool de destination. L’administrateur TIVOLI
STORAGE MANAGER va donc assigner ces différents storage pool aux différents copy group. Il y a
une hiérarchisation des devices ce qui veut dire que les devices peuvent être en cascade les uns avec les
autres. En général on représente les devices dans une pyramide avec au sommet les devices les plus
rapides et plus coûteux (disques) et en bas les moins rapides et les moins coûteux (dérouleur de bandes).
TIVOLI STORAGE MANAGER optimise l’utilisation des médias. Il est donc capable de remplir
complètement les médias. Un média va donc contenir des informations d’ancienneté différente, et de
provenance différente. TIVOLI STORAGE MANAGER fournit la possibilité de recycler les médias
lorsqu’un certain pourcentage de gaspillage est atteint. Quand des données expirent le média se vide et
une fois le seuil de tolérance de gaspillage atteint TIVOLI STORAGE MANAGER démarre le
recyclage.
Il est également possible de demander de regrouper par média les données des serveurs : La collocation.
Cette fonctionnalité améliore les temps de restauration vu qu’elle nécessite moins de montage de
médias.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 11
Quand on implémente une cascade de devices disques vers bandes, on dispose d’un mécanisme de
cache, c’est-à-dire que lorsque l’espace disque est rempli à un certain pourcentage, TIVOLI STORAGE
MANAGER démarre la migration des données mais sans récupération de l’espace.
TIVOLI STORAGE MANAGER libérera l’espace au fur et à mesure de ses besoins.
On peut via TIVOLI STORAGE MANAGER dupliquer des médias et les stocker sur un autre site. En
cas de problèmes sur le média primaire TIVOLI STORAGE MANAGER utilise automatiquement la
copie. Si un média est mis dans un autre site, TIVOLI STORAGE MANAGER continue à le gérer.
IBM Ultrium LTO Tape Library
LTO est une architecture ouverte de bandes magnétiques, développée par un consortium de 3
constructeurs de solution de stockage de renommée internationale. Ouvert signifie que cette technologie
est disponible pour de nombreux partenaires via une entité chargée de vérifier la conformité aux
standards LTO. Dans ce consortium, IBM se porte garant de la nouvelle technologie destinée à long
terme.
En effet, IBM a puisé dans sa longue expérience pour développer les nouveaux dérouleurs Ultrium :
•
multi-track recording
•
pistes servo servant à aligner correctement la bande sur les têtes
•
têtes d’écriture et de lecture magnéto-résistif (MR)
•
haute densité d’écriture
•
fonctions d’ECC (Error Correction Coding) qui permet d’appliquer une méthodologie RAID sur
bande afin de permettre une haute disponibilité des données.
Hautes capacités et performances
Les dérouleurs LTO ont une capacité de 100 GB en natif et jusqu’à 200 Gbytes avec un taux de
compression de 2:1 en utilisant l’algorithme de compression IBM.
Le troughput est de 15 MB/s en natif, ou 30 MB/s avec un taux de compression de 2:1, soit 100
Gbytes/heure.
20
15
MBs / Sec
15
11
10
5
6
5
0
DLT7000
B/O/152/A/02/SD
DLT8000
SDLT
UCL : Projet Pilote – Service de Sauvegarde
LTO
Page 12
Pérennité
Une roadmap de quatre générations a été définie.
Ultrium
Generation
1
Generation
2
Generation
3
Generation 4
100GB
200GB
400GB
800GB
Transfer Rate
(Native)
10-20MB/s
20-40MB/s
40-80MB/s
80-160MB/s
Media
Metal Particle
Metal Particle
Metal Particle
Thin Film
Capacity
(Native)
Current spec subject to change; product based on these specs may not become available.
Une gamme étendue
Best of Breed Technology
Automation Packages
Total Solutions Coverage
Medium - Large
Library
141 - 2400+
Cartridges
Small - Medium
Library
18 - 72 Cartridges
External Drive
100GB Native
15 MB/s
Autoloader
1 - 7 Cartridges
La librairie LTO 3584 se compose de 1 à 6 armoires, chacune pouvant contenir jusqu’à 12 dérouleurs
chacune et jusqu’à 440 emplacements cassettes. La capacité emplacements est fonction de différents
facteurs, dont le nombre de dérouleurs, et pour la première armoire, de la taille du magasin
d’entrée/sortie.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 13
Vous trouverez ci-après un tableau complet reprenant les capacités des différentes armoires composant
une librairie IBM LTO 3584.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 14
IBM eServer pSeries 610 – 7028-6C1
Le serveur à châssis vertical pSeries 610 Modèle 6E1 et le serveur en armoire rack pSeries 610 Modèle
6C1 (7028-6E1/6C1) vous offrent de nouveaux outils pour la gestion de l’ e-business, une plus grande
souplesse d’ application et une technologie innovante. Leur but est de vous aider à tirer parti de la
révolution de l’e-business. Le multiprocesseur symétrique (SMP) utilise un ou deux microprocesseurs
POWER3-II 64 bits sur cuivre à la pointe de la technologie, cadencés à 375 ou 450 MHz. Chaque
processeur à 375 MHz est associé à 4 Mo de cache de Niveau 2 (L2). Chaque processeur à 450 MHz est
associé à 8 Mo de cache L2. La capacité de base de 512 Mo de la mémoire principale est extensible à 8
GB, ce qui offre des performances plus élevées et l’ exploitation de l’ adressage 64 bits utilisé dans les
applications pour grandes bases de données.
Le Modèle 6E1 et le Modèle 6C1 comportent dix baies. Les six baies accessibles par l’avant et
remplaçables à chaud peuvent accueillir jusqu’à 880,8 GB de stockage sur disque. Les autres baies sont
utilisées pour un lecteur de disquette, un lecteur de CD ROM ou de DVD-RAM, un disque non
remplaçable à chaud en option, et un lecteur de média en option.
Pour aider les applications stratégiques à rester disponibles 24 heures sur 24 et 7 jours sur 7, le Modèle
6E1 et le Modèle 6C1 sont équipés d’un processeur de maintenance intégré qui surveille en permanence
les symptômes essentiels du système. En cas de dysfonctionnement, le processeur de maintenance IBM,
souvent avant que les utilisateurs ou les administrateurs du système ne remarquent de problème. Le
système de diagnostic par voyants est également intégré au Modèle 6E1 et au Modèle 6C1. Des témoins
lumineux (associés physiquement aux principaux composants du système) permettent de diagnostiquer
et résoudre rapidement les problèmes.
Les caractéristiques et les atouts du Modèle 6E1 et du Modèle 6C1 sont les suivants :
•
Un exceptionnel rapport qualité/prix
•
Un serveur d’e-business SMP puissant
•
Configuration à châssis vertical (Modèle
6E1) ou en armoire rack (Modèle 6C1)
•
Jusqu’à
deux
processeurs
IBM
POWER3-II 64 bits dernier cri
exploitant la technologie sur cuivre,
ultra-performants et fiables
•
Jusqu’à 8 GB de mémoire
•
Jusqu’à 954,2 GB d’espace disque
interne
•
Dix baies et cinq connecteurs PCI pour
l’ajout d’options
•
Système de diagnostic par voyants
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 15
2.
Spécifications Techniques
Le système déployé devra être conçu pour garantir les fonctions de sauvegarde ainsi que l'accès aux
données sauvegardées même en cas de défaillance d'un des composants du système (serveur,
connexion réseau, librairie de bande,...). Typiquement, on souhaite un système de type "cluster" où
le service de sauvegarde est assuré par deux machines "serveurs" distantes, avec les copies de
sauvegardes dupliquées en des endroit géographiques distants.
La solution proposée sera constituée de 2 environnements de backup distincts, géographiquement
distants. Chaque site aura un serveur de backup, une librairie, un accès à un réseau Ethernet 10/100
Mbps de production et à un réseau gigabit.
Chaque serveur aura 2 connexions vers le réseau de backup, 2 connexions vers la librairie.
Chaque serveur de backup prend en charge la sauvegarde d’un certain nombre de serveurs ou clients. Le
backup des serveurs et clients se fera par le réseau 10/100. Chaque serveur envoie de manière
asynchrone une copie des backups vers le second site par le réseau gigabit.
Cette opération d’import / export permet de manière simple de duplicier toutes ou certaines données
d’un site vers l’autre, et ainsi de les rendre disponibles si une défaillance devait apparaître sur un des
sites.
TSM fournit une fonction d’export-import qui permet de copier tout ou une partie d’un serveur vers un
removable media (export) et être transféré vers un autre serveur (import).
Ce qui a été exporté, peut aussi être ré-importé sur le même serveur.
Les administrateurs peuvent exporter ou importer les types de données TSM suivants :
•
Des information à propos du contrôle du Serveur, dont :
o Définition du serveur
o Définition des clients - noeuds
o Définitions les Policies et des schedules
•
Le fichier de données du serveur de stockage, dont les définitions des file space et règles
d’autorisation. Il est possible d’exporter ce fichier dans un des groupes suivants :
o Versions actives et inactives de fichiers backupés, copie archive de fichiers et space
managed files ;
o Versions actives de fichiers backupés, copie archive de fichiers et space managed files ;
o Versions actives et inactives de fichiers backupés ;
o Versions actives de fichiers backupés ;
o Copie archive de fichiers ;
o Space-managed files.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 16
Pour exporter des données, vous devez spécifier une classe de device qui supporte des medias
séquentiels et identifier les volumes qui seront utilisés pour stocker les données exportées. Vous pouvez
interroger les serveurs source et cible pour sélectionner une classe de device sur chaque serveur qui
supporte le même type de dispositif. Si vous ne trouvez pas une classe de device sur chaque serveur qui
supporte un type de device compatible, definissez une nouvelle classe de device pour un type de device
qui est disponible sur les deux serveurs.
Voici la configuration proposée pour chaque site :
IBM eServer pSeries 610 modèle 7028-6E1 avec les spécifications suivantes :
•
2-way @ 450 MHz
•
2 GB de mémoire
•
2 x 18,2 GB pour l’OS
•
5 x 73,4 GB pour le TSM Disk Storage Pool
•
2 connexions Ethernet 10/100
•
2 connexions Gigabit Ethernet
•
2 connexions FC
La configuration complète est la suivante :
Serveur de Base
7028-6E1
Deskside Server 1:PSERIES 610
1
3752
SERVICE PACKAGE
1
9300
LANG.GROUP SPEC.-US ENGLISH
1
450MHZ POWER3-II PROC.CARD
2
2X512 MB DIMMS,200-PIN
2
3102
18.2GB 10,000 RPM DISK DR
1
3263
18.2 GB DISK DR. ASSEMBLY
1
3265
73.4GB 10K RPM U3 SCSI DDR ASS
5
4248
SCSI CON.CABL.,REPEATER CARD
1
4249
3-DROP C.:BACKPLANE-MEDIA BAYS
1
6566
MOUNTING HW F.DISK,MEDIA BAY
1
6567
U3 SCSI BACKPLANE FOR H/S DISK
1
Processeurs
5309
Mémoire
4121
Capacité Interne
Connexion Réseau
2969
10/100 ETHERNET ADAPTER
2
GB ENET-SX PCI ADAPTER
2
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 17
Connexion FC
2456
LC-SC 50 MICRON FIBER CONV CAB
2
6228
GB FIBRE CHAN.ADAPT.64-BIT
2
Médias Internes
1.44MB DISKETTE DRIVE
2633
IDE CD-ROM DR.(BLACK BEZEL)
1
4246
IDE 2-DROP CONNECTOR C
1
6277
POWER SUPPLY,250 WATT AC
2
9820
POWER C.-BELG,FIN,France
1
Alimentation
Site 2
Site 1
TSM Client TSM Client TSM Client
d i gi ta l
d ig i t a l
d i gi t a l
TSM Client TSM Client TSM Client
d ig i t a l
d i gi t a l
d i gi ta l
Ethernet 10/100
Gigabit Ethernet
TSM Server
TSM Server
FC
FC
IBM
IBM
Tape Library
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Tape Library
Page 18
le système déployé devra supporter des clients HP-UX, SunOS, IRIX, Tru64, linux, Windows (toutes
versions) et MacOS. Dans le cas où le coût des licences clients est dégressif en fonction du nombre
de clients, les coûts d'un bundle de 20 licences clients et de 50 licences clients seront mentionnés
dans l'offre (en version LAN et SAN).
Le logiciel de backup TSM supporte les clients sous HP-UX, SUN Solaris, IRIX, Tru64, Linux,
Windows (95, 98, NT4, 2000, XP, …) et MacOS.
Le système proposé offrira une capacité de stockage de 4 TB au départ, avec des possibilités
d'évolution vers 10 TB.
Le système de stockage, dans sa configuration proposée par site, offre une capacité de stockage de 22,9
TB en natif, 45,8 TB en comprimé (2:1). Chaque librairie sera équipée de 4 dérouleurs connectés en
fibre au serveur de backup via un Switch Fibre Channel 8-ports. Cette librairie peut être équipée
d’armoires supplémentaires, composée de dérouleurs ou de slots cassettes.
3584-L32
ULTRASCALABLE TAPE LIBRARY
1
1456
LTO ULTRIUM FC-AL DRIVE SLED
4
1462
FIBRE CHANNEL PATCH PANEL
1
1653
CAPACITY EXPANSION – PLANT
1
1657
20 ADDITIONAL LTO I/O SLOTS
1
1662
STORWATCH SPECIALIST
1
2710
REMOTE SUPPORT FACILITY
1
5861
61 METER FIBRE CHANNEL CABLE
4
8750
ULTRIUM CLEANING CARTRIDGE
10
9600
ATTACHED TO RS/6000 SYSTEM
1
9660
10/100 ETHERNET SUPPORT
1
Nous proposons 120 cartouches labellisées par site :
3589-002
ULTRIUM TAPE CARTR. W/LABEL
1
2020
100GB ULTRIUM TAPE W/L 20-PAK
6
9003
ALPHA PREFIX BKGRD – RED
1
9022
LABEL BKGRD: COLOR/VIBRANT
1
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 19
Le système proposé supportera la restauration de systèmes opérationnels à partir des media de
sauvegarde (« bare metal restore »).
Via l’utilisation de ‘Bare Metal Restore (BMR)’, il est possible de restaurer un système sans devoir réinstaller le système d’exploitation ou de devoir reconfigurer le hardware.
Vos clients sont toujours sauvegardés par TSM comme auparavant, mais une procédure complémentaire
est automatiquement exécutée avant chaque sauvegarde prévue pour enregistrer l'état actuel de la
configuration de machine, incluant les dispositions de disque et la configuration de TCP/IP. Si les
changements sont faits à la configuration d'une machine, ces changements sont automatiquement
capturés et enregistrés à la sauvegarde suivante prévue sans n'importe quelle intervention d'utilisateur.
La restauration d'un serveur avec BMR est facile et automatisée. Le rétablissement commence quand
l'utilisateur donne la commande ‘prepare to restore’ via ligne de commande ou via une interface web.
BMR immédiatement récupère les données de configuration du client, emploie ces données pour créer
une procédure de restauration de ce client et ensuite, à travers le réseau, pointe vers les images boot et
les systèmes de fichiers appropriées.
Le client démarre alors d'un serveur boot initialisé et suit les procédures de démarrage suivantes :
•
Monte les systèmes de fichiers nécessaires à partir du ‘File Server’ ;
•
Configure des disques, des volumes logiques, des systèmes de fichiers, etc. ;
•
Envoie des commandes au serveur TSM pour reconstituer le système d'exploitation, les données
de configuration, les fichiers des utilisateurs et des applications.
Après que ces tâches sont terminées, le client configure le ‘boot record’ et les données de configuration,
se réamorce et redevient opérationnel.
IBM AIX est supporté en tant que serveur BMR et les clients supportés sont IBM AIX, HP-UX, Sun
Solaris or Microsoft Windows NT/Windows 2000
Le système permettra la gestion des copies d'archivage (à sortir des librairies et à conserver pour le
long terme).
L'intégration du système actuel de stockage de masse (HSM basé sur l'ancien UCFM de Unitree
(racheté par OTG puis par Legato)) sera évaluée.
Les utilisateurs TSM peuvent archiver des fichiers à long terme et chercher les fichiers archivés si
nécessaire. Archiver, c’est copier les données du client vers le serveur pour un stockage à longue terme.
Le serveur garde les archives en fonction de la police de temps de conservation implémentée.
Pour conserver des fichiers afin de les utiliser plus tard ou pour conservation des enregistrements, un
utilisateur avec un client backup - archive peut archiver des fichiers, subdirectories et directories sur les
medias contrôlés par le serveur. Quand des utilisateurs archivent des fichiers, ils peuvent choisir si le
client backup-archive efface les fichiers originaux de leurs station après que le client a archivé les
fichiers.
Quand un utilisateur recherche un fichier, le serveur envoie une copie du fichier au noeud du client. Le
fichier archivé reste dans le serveur storage.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 20
Les fichiers archivés sont, comme les fichiers backupés, enregistrés en groupes de volumes nommés
‘storage pools’. Les données sur ces ‘primary storage pools’ peuvent être backupé vers d’autres ‘copy
storage pools’ pour des raisons de disaster recovery.
Chaque client dans la configuration à la possiblilité d’exécuter un processus de recherche des archives,
des disques clonés ou exportés de n’importe quel serveur.
Les processus bachup/archive et leurs dispositifs cloning/export sont conçus pour travailler avec un
device automatisé. Pour des devices portables, nous recommendons d’utiliser soit le dispositif
backupset, soit le dispositif export/import.
‘Space Management’ ou HSM (pour AIX et Solaris) permet de migrer des fichiers d’un ‘primary storage
‘(hard disk drives) vers un autre type de médias ‘secondaire’ moins chers. Cette migration peut être
basée sur une politique de rétention, taille, attributs de fichier, type de fichier et ‘path name’.
Vous pouvez établir des règles de « Cleaning » afin de purger les données de fichier qui ont déjà été
déplacées vers d’autres médias afin de maintenir l’espace disponible sur l’ ‘extended drive’. Vous
pouvez aussi choisir quels ‘folders’ sur l’ ‘extended drive’ contiendront des fichiers DX et le type de
média utilisé pour garder les fichiers qui ont été déplacés sous un règle particulière.
Avec DiskXtender 2000 DX (pour Windows), cette migration, et recherche de fichier est transparente et
automatique.
L’utilisateur sauve et accède des fichiers du volume de NTFS, ignorant que ce volume a été étendu par
DX. Etant donné que les clients se connectent sur Windows NT/2000 plutôt que sur DX, la connectivité
étendue, offerte par Windows NT/2000 reste d’application. N’importe quel utilisateur qui se connecte
au serveur Windows NT/2000 peut accéder aux fichiers d’un ‘extended drive’.
OTG’s DiskXtender 2000 (DX2000) permet la migration des fichiers NTFS vers le serveur Tivoli
Storage Manager (TSM). Les utilisateurs de DX2000 ont la possibilité d’avoir leurs données contrôlées
et protégées par un serveur TSM central et les utilisateurs TSM la possibilité d’espacer les données des
plates-formes ‘Windows’.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 21
Les données de fichier d’un drive étendu par DX peuvent être déplacées vers un ‘média service’
(comme une librairie gérée par un ‘device management software’ – tel que TSM) sans influencer le ‘file
listing’ vu par l’utilisateur final.
L’ ‘extended drive’est un volume NTFS (disque dur) du quel DiskXtender fournis des services de
migration de fichiers, en déplaçant des fichiers vers un média et récupérant les fichiers du média en
rapport au paramètres que vous avez établis. Les fichiers utilisés régulièrement, seront gardés sur le
volume NTFS, pendant que les fichiers moins actifs seront déplacés vers le ‘storage media’ désiré. C’est
l’ajout et l’utilisation du ‘storage media’ par DX qui étend l’espace sur le volume NTFS en déplaçant
des fichiers vers le ‘storage media’ et purger les fichiers de données tout en laissant le fichier comme si
il était sur l’ ‘extended drive’.
Pour un client à la recherche de fichiers d’un ‘extended drive’ par DX, tous les fichiers, qu’il soit sur le
volume NTFS ou sur le storage media, sont apparemment présent sur le volume NTFS. Dans l’optique
de déplacer et purger les règles définies, DX déplace les fichiers vers le média déplaçable et après il
purge les fichiers de données de ‘extended drive’. Quand les fichiers de données sont purgés, DX laisse
un fichier ‘tag’ sur l’ ‘extended drive’contenant l’information du fichier, entre autre la taille et le temps
et la date de création ou de modification. Le fichier ‘tag’ contient également un attribut laissé par DX
qui indique la location de ce fichier sur le média de stockage. Quand le drive étendu est visualisé par
Windows Explorer, le fichier entier est toujours stocké sur le disque de l’ ‘extended drive’, même si ses
les fichiers de données ont été vraiment purgés.
Les différents aspects de la migration de fichier sont contrôlés de plusieurs façons dans DiskXtender:
- ‘Fetch requests’ sont automatiquement traités le plus vite possible ;
- ‘Prefetch requests’ sont configurés pour chaque ‘extended drive’ par sélection des fichiers
‘prefetched’. ‘Prefetch requests’ sont traitées en fonction le ‘Prefetch schedule’ ;
- les règles contrôlent le type de fichiers déplacés en fonction du média. Vous programmez les
‘automatic extended drive scans’. Les fichiers sont déplacés quand un ‘Move files to ‘media activity
schedule’ est actif.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 22
Les avantages de l'utilisation combinée d'un système à disque RAID pour une des deux localisations
seront discutés.
‘Tivoli Storage Manager’ vous permet de configurer des ‘storage pools’ pour offrir la meilleure
combinaison de performance en débit et permanence des données. Dans la plupart des cas, on exige de
garder les données du client sur bande. Toutefois, faire des backups directement sur bande ne donne pas
la meilleure performance, et spécialement quand il y a beaucoup de client à backuper en parallèle, et/ou
beaucoup de petits fichiers à backuper. Par conséquent, ‘Tivoli Storage Manager’ fournit une hiérarchie
de ‘storage pool’, où un client fait son backup vers un storage pool, principalement sur disque. Quand ce
‘Storage Pool’ se remplit, TSM déplace ou migre automatiquement des fichiers vers le prochain storage
pool dans la hiérarchie (en général sur bande) pendant que le client continue ses opérations de backup.
Il est préférable de disposer d’un espace de stockage disques qui constitueront le Disk Storage Pool. Une
grappe de 4 disques internes de 73,4 GB protégée par un algorithme RAID-5 équipe chacun des serveurs
proposés de TSM.
Chaque librairie est proposée avec 4 dérouleurs. De la sorte, 4 backups simultanés sont possibles. Cet
espace disque permet de prendre plus de 4 backups simultanés.
Une attention particulière sera portée sur la restauration des fichiers: un certain nombre d'hôtes
comportent des zones disques partagées (via samba, NFS ou autre) par un grand nombre
d'utilisateurs. Ces hôtes sont sous la responsabilité d'un administrateur qui en définit la stratégie de
sauvegarde et sa mise en oeuvre. Il est souhaitable que les utilisateurs de la zone partagée puisse
avoir accès à l'historique des sauvegardes, ainsi que les droits et les capacités fonctionnelles de
restaurer les fichiers qui leur appartiennent, sans toutefois avoir un accès quelconque aux fichiers
des autres utilisateurs. Un avantage supplémentaire résulterait de l'utilisation d'un interface
standard (p.ex. http) pour mettre en oeuvre cette restauration (ce qui rend inutile l'installation d'un
logiciel spécifique sur la machine d'un utilisateur final).
Vous pouvez faire en sorte que, seulement les administrateurs et les client autorisés communiquent avec
le serveur, en utilisant des mots de passe. Vous pouvez aussi mettre les conditions suivantes pour les
mots de passe :
•
Longueur du password
•
Expiration du Password
•
Une limite au nombre d’essais consécutifs erronés du mot de passe. Quand le client dépasse cette
limite, TSM empêche le client d’accéder le serveur.
Vous pouvez contrôler l’accès par les administrateurs au serveur. Une organisation peut nominer un seul
administrateur ou peut diviser le travail en plusieurs administrateurs et leurs accorder des différentes
autorités.
Vous pouvez empêcher un client d’accéder le serveur avec la commande LOCK NODE. Ceci
empêchera les clients d’exécuter des fonctions comme les backups et restores ou archive et retrive.
Avec l’introduction du ‘Web backup-archive client’, quand un client est registé avec un serveur TSM
3.7.0 ou au-dessus, un userID administratif identique est crée en même temps. Ce userID a ‘client owner
authority’ sur le noeud par défaut. Un ‘Enterprise logon’ permet à un utilisateur avec son propre
‘administrative user ID’ et son mot de passe d’accéder un ‘Web backup-archive’ client à partir d’un
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 23
‘Web browser’. Le code ‘Web backup-archive’ peut être utilisé par le client ou un userID avec l’autorité
exacte d’exécuter un backup, un archive, un restore, et retrieve sur n’importe quelle machine qui tourne
le code ‘Web backup-archive’. Vous pouvez établir l’accès à un client ‘Web backup-archive’ pour du
personnel ‘help desk’ qui n’ont pas les privilèges de système ou policy pour leurs donner l’autorité
d’accès aux nœuds qu’ils doivent gérer. Le personnel ‘Help desk’ peut exécuter des activités en lieu et
place du client comme des opérations backup et restore. Un client natif backup - archive peut se logger
sur TSM en utilisant le nom et le password du noeud, ou le userID et mot de passe administrateur. Le
mot de passe administratif du userID est géré indépendament du password qui est produit avec le
‘passwordaccess generate client option’. Le client doit avoir spécifié dans le fichier option
‘passwordaccess generate’ pour permettre l’utilisation le ‘Web backup-archive client’.
Pour utiliser le ‘Web backup-archive client’ depuis un ‘web browser’, specifier l’URL et le ‘port
number’ du client ‘TSM backup-archive’ qui tourne le ‘web client’.
Pendant l’enregistrement du noeud, vous avez la possibilité de donner l’autorité ‘client owner’ ou ‘client
access’ à un userID administratif existant. Vous pouvez aussi éviter que le serveur crée un userID
administratif lors de l’enregistrement.
L’accès à un ‘Web backup-archive client’ requiert soit l’autorité ‘client owner’, soit l’autorité ‘client
access’. Les administrateurs avec des privilèges de système ou policy sur le domaine du nœud client, ont
le ‘owner authority’ par défaut. Le userID administratif qui est automatiquement créé à l’enregistrement,
a le ‘client owner authority’ par défaut.Interface web pour utilisateurs pour restore.
Une des fonctionnalités fournies avec le code client TSM est le ‘WEB interface’. C’est un
“java applet”, qui tourne la machine qui est backupé et ce qui permet, via un ‘Web-Browser’, à
backuper, restorer, archiver et ceci, par une interface graphique et conviviale semblable à windows
explorer’.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 24
La proposition inclura une offre basée sur une architecture LAN, ainsi qu'une offre basée sur un
SAN. Les "upgrade path" d'une solution LAN vers une solution SAN seront identifiés et
budgétairement chiffrés.
La solution proposée se base sur une topologie de backup LAN. Pour un backup SAN, chaque serveur
devrait être équipé d’une connexion SAN supportée. Une topologie de sauvegarde par le SAN se justifie
pleinement pour de gros fichiers.
2 implémentations de backup SAN sont envisageables : LAN-Free ou Server-Free.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 25
La solution proposée inclura un système de distribution et d'installation du logiciel client qui
minimise les interventions des administrateurs sur les machines clients (« remote install »).
Pour un grand nombre d’installations, il est possible d’effectuer un ‘unattended’ ou ‘silent’ install. La
possibilité existe d’installer le code client TSM sur les serveurs via les lignes de commande. En utilisant
ces commandes dans un processus batch, il est possible d’installer rapidement un grand nombre de
clients identiques sur des stations Windows client workstations.
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 26
3.
Offre Financière
Les prix mentionnés sont à titre budgétaires, en EURO TVA non comprise.
Description
Prix Unitaire
Qté
€ HTVA
Librairie IBM LTO 3584 avec
Prix Total
€ HTVA
150.000,-
2
300.000,-
48.000,-
2
96.000,-
FC Switch 8-ports, 12 mois de garantie
15.000,-
2
30.000,-
Licences Tivoli Storage Manager
16.935,-
1
16.935,-
10.000,-
1
10.000,-
3.400,-
1
3.400,-
Licence TSM 1 proc client LAN
312,-
1
312,-
Licence HSM pour Unix, par processeur
749,-
1
749,-
2.950,-
1
2.950,-
599,-
1
599,-
599,-
1
599,-
4 dérouleurs FC
120 Cartouches
12 mois de garantie
IBM eServer pSeries 610 Serveur TSM
2-way @ 450 MHz, 2 GB mémoire
2 x 18,2 + 5 x 73,4 GB
2 x E 10/100 + 2 x E 1000 + 2 x FC
12 mois de garantie
2 serveurs TSM bi-pro
50 proc. TSM Clients
10 jours de services – implémentations
Option
20 cartouches LTO
Licence HSM pour Windows, par serveur
Licence TSM TDP for DB 1 processeur
On-line backup de Base de donées
Licence TSM TDP for Mail, 1 processeur
On-line backup de serveur Mail
B/O/152/A/02/SD
UCL : Projet Pilote – Service de Sauvegarde
Page 27