VTS et Robotique Mornay

Informatique
Groupe Mornay
VTS TS7700
JAGUARS et
RESTRUCTURATION
TSM 2007
Configuration VTS PtP AGME
SAPHIR A
SAPHIR B
2 FICON
2 FICON
4 FICON
4 FICON
IP
TS 7700
(VTS)
3592 F05
3592 C06
D23
6000 GO
Non compressés
3953 F05
3592 E05
Ajout
3584-L23
TS7700
(VTS)
3592 F05
3953 F05
3584-L23
140 K7 500 Go
Lecteurs natifs Lecteurs VTS
Service Production
3592 E05
3592 C06
existantes
140 K7 500 Go
Lecteurs VTS
2
D23
Sortie
Vue z/OS de l’architecture robotique TS7700 en
Grid
❐
Composée de 2 robotiques : images de 128 lecteurs
virtuels
- chaque site a 128 lecteurs virtuels (LCU 0-7)
SCDS(Host A)
Libname
HYDRA
❐
❐
Chaque host voit une librairie composite, et 2 librairies
distribuées.
La librairie composite peut avoir jusqu’à 500 000
volumes logiques.
SCDS(Host B)
Composite Library
Sequence#
3584C
Libname
HYDRA
Library Composite
Sequence#
3584C
TCDB(Host B)
Volume Range
Libname
B00000-B99999 HYDRA
TCDB (Host A)
Volume Range
Libname
A00000-A99999 HYDRA
UCBs 0x20000x207F
UCBs 0x10000x107F
Host A
Cluster0
Distributed
Sequence
#A1111
Cluster1
Distributed
Sequence
#B2222
Host B
LCU 0-7
LIBPORT 41-48
LCU 0-7
LIBPORT 01-08
Hydra Domain
Composite Library Sequence
#3584C
Volume Range
A00000-A99999, B00000-B99999,
Note: Each cluster sees all logical volumes
under its own sequence number
Service Production
3
Sortie
Migration B10 >>> TS7700
❐
Préparation de consolidation de fichiers sur K7
• Débuté 2 semaines avant la migration
• Réduction du nombre de k7 virtuelles (beaucoup de 1
fichier/1 bande résultant de batch)
• ( dans certains cas nous avons mis l’équivalent de
plusieurs centaines de k7 sur une seule)
❐
❐
1338 jobs pour 8 tera NON HSM répartis sur 7430 k7
logiques ( utilisation de idcams repro)
4 téras TSM répartis en 8 millions de fichiers sur 2700
k7 logiques ( movedata en batch et mise en collocation)
❐
20 téras HSM ( migration recall )
❐
Toutes les K7 virtuelles en 4 GB ( au lieu de 2 GB)
❐
Migration terminée en 10 jours ( prévu 22 )
Service Production
4
Sortie
Mainframe perf
❐
Sauvegarde totale applicative DB2I ( GED de 4 tera 5 )
• Avec B10
: 20 heures
• Avec TS7700 :
❐
5 heures
Sauvegarde applicative DB2X ( prod de 850 Gb)
• Avec B10
: 90 minutes
• Avec TS7700 : 20 minutes
❐
TSM
• recycle en 2 heures au lieu de 11 ( 2 fois par semaine)
❐
HSM
• Autobackup/autodump : temps elapse divisé par 2
Service Production
5
Sortie
Spécifiques hardware (VTS)
❐
1600 volumes présents dans le cache
• Moyenne de 650 heures de résidence
• Environ 3 semaine et demi
❐
5 teras de cache utilisé
❐
Fast ready mount
• Temps moyen de 1 seconde
❐
Non fast ready mount
• Temps moyen entre 150 et 190 secondes
Service Production
6
Sortie
Spécifiques hardware (NATIF)
❐
❐
❐
❐
Service Production
6 jaguars en natif
•
4 canaux Ficon 4 Gb ( sur 2 x Z9 ( 2 +2))
•
K7 de 500 Gb
Un lecteur atteint 95 MB/sec ( débit réel avec EXHPDM,
impossible à atteindre avec data mover classique)
Les 6 lecteurs atteignent 248 MB/sec par canal avec 2 canaux
( limité par le CPU qui est 1 Z9 503 ) ( on a alors 120jobs de
dump concurrents et on sature le CPU mais pas le robot )
Sauvegarde totale de la baie DS8100 ( secondaire du PPRC
suspendu donc attention le cache disque est inopérant )
•
EXHPDM sur 6 lecteurs = 10,4 tera en 4 heures sur 12 K7
•
Recupération de fichier = 5 minutes elapse ( peu importe ou se
trouve le fichier
7
Sortie
TSM Introduction:
❐
Backup serveurs distribués
❐
Plateformes Intel ( Windows + Linux)
❐
Plateformes AIX
❐
SAN ( FC et SATA)
❐
Problématiques de temps de restauration ( répartition)
❐
Problématique d’espace bureautique :HSM
❐
Service Production
CBMR ( Christie Bare Metal Restore) sets rejoignent les
sauvegardes incrémentales
8
Sortie
Etat existant
❐
BACKUP
•
Incrémentaux Journaliers
• Sur VTS direct ( P2P)
• Sans collocation
• Journaliers Journalisés sur bureautique
• Non journalisés le week end sur bureautique
• 1 x Full pour Messagerie Domino uniquement le weekend
• Nouveaux besoins ?
❐
Jobs techniques
• Expiration DB
• Backup full DB le weekend
• Backup incrémental DB journalier
• Vidage des pools par chgt de Treshold
Service Production
9
Sortie
Evolution Hardware
❐
❐
❐
❐
Service Production
Au départ – Pool disque primaire avec cassettes 3494 en
secondaire ( 2000)
K7 Physiques de 20 gigaoctets
VTS direct sur K7 de 800 Megaoctets ( primaire)
K7 Physiques de 20 gigaoctets ( 2004 )
VTS direct sur K7 de 2 Gigaoctets ( primaire )
K7 physiques de 40 Gigaoctets (2005)
VTS direct sur K7 de 4 Gigaoctets ( primaire )
K7 physiques de 500 Gigaoctets (2007)
10
Sortie
Evolution Hardware
7000 K7 virtuelles sur 140 K7 physiques
Ratio Virtuel/Physique 50/1 (2004)
•
3000 K7 virtuelles sur 140 K7 physiques
Ratio Virtuel/Physique 22/1 (2005)
•
1500 K7 virtuelles sur 20 K7 physiques ?
Ratio Virtuel/Physique 75/1 ?(2007)
•
Service Production
11
Sortie
Evolution Hardware
7 500 000 fichiers
3,5 téras compressés
150 serveurs (ça bouge souvent ☺)
Service Production
12
Sortie
Evolution by recall ( la K7 revient entière)
❐
7 500 000 sur 7000 K7 Virtuelles
• 1070 fichiers / recall
❐
7 500 000 sur 3000 K7 virtuelles
• 2500 fichiers / recall
❐
7 500 000 sur 1500 K7 virtuelles
• 5000 fichiers / recall
❐
30000 fichiers /1 physique
❐
54000 fichiers / 1 physique
❐
375000 fichiers / 1 physique
Service Production
13
Sortie
Hardware :ce que ça change
❐
Nombre de mounts divisé par 7
❐
Durée d’un mount divisé par 2 ( 5 minutes/2.30 minutes)
❐
Taille de K7 virtuelles multiplié par 2
❐
Taille de k7 physiques multiplié par 12
❐
Taille du cache multiplié par 12
❐
❐
Service Production
Cela rend la collocation intéressante puisque les chances
que les données dont on a besoin soient en ligne
augmentent
Le HSM devient possible ( libération espace disque
possible)
14
Sortie
Collocation
❐
❐
(1)
C’est le fait de grouper les sauvegardes de fichiers d’un
client sur le (les) même média afin de diminuer le
nombre de mount lors de la restauration
La collocation se décline en 3 possiblilités
• Par Node ( les fichiers d’un node sont regroupés sur
la/les même K7)
• Par groupe de Nodes ( les fichiers de certains nodes sont
regroupés sur la/les même K7)
• Par File système ( les file système sont regroupés sur les
même K7 )
❐
Le facteur de groupage doit être étudié en fonction :
• Du nombre de fichier des serveurs
• De la taille des serveurs
• Du nombre de serveurs
Service Production
15
Sortie
HSM ( Hierarchical Storage Migration)(1)
❐
Qu’est ce que c’est ?
•
•
❐
–
–
Libérer de la place sur le stockage rapide ( disque )
Economiser en utilisant un système de stockage plus lent mais moins
cher
Comment ça marche
•
•
•
Service Production
C’est une organisation de stockage de façon hiérarchique (du
media le plus rapide vers le média le plus lent )
Le but :
Le serveur possède un pool d’archivage bandes .
Le client possède un agent de migration qui remplace les fichiers
réels par des raccourcis ( stub files)
Les critères de migration se font en fonction de :
–
–
–
–
–
–
–
Taille de fichier
Date de création
Date de modification
Date de référence
Type de fichiers
Emplacement sur répertoire
Etc …..
16
Sortie
HSM ( Hierarchical Storage Migration)(2)
❐
❐
❐
❐
Service Production
Chaque fichier peu importe sa taille est remplacé par un
stub file de 4k octets ( taille d’un cluster NTFS )
L’icône est remplacée pour montrer que le fichier n’est
pas sur le disque
Chaque fichier est rappelé implicitement ( il suffit de
cliquer comme un raccourci normal et TSM remet le
fichier sur son emplacement original)
Il est possible de faire du rappel massif grace à des
listes et l’interface GUI
17
Sortie
Collocation quelques chiffres
❐
❐
❐
13 serveurs ( clients) au dessus de 100 000 fichiers
(donc 1 serveur = 1 groupe )
8 serveurs (clients) au dessus de 70 Gigaoctets de
sauvegarde (donc 1 serveur = 1 groupe )
Quelques catégories possibles (plusieurs nodes dans un
seul groupe )
• Serveurs de Prod = 1 groupe
• Serveurs de Prex = 1 groupe
• Serveurs de Test = 1 groupe
• Postes de test ( Pxxxxx) = 1 groupe
• Serveurs AIX = 1 groupe ??????
Service Production
18
Sortie