Présentation des technologies mainframe EMC

Transcription

Présentation des
technologies mainframe EMC
Version 2.0
• Bonnes pratiques et performances
• Produits et solutions
• Logiciels et services
Tony Negro
Paul Pendle
mftbv20.book Page 2 Monday, June 24, 2013 9:26 AM
Copyright © 2010, 2013 EMC Corporation. Tous droits réservés.
EMC estime que les informations figurant dans ce document sont exactes à la date de publication. Ces
informations sont modifiables sans préavis.
LES INFORMATIONS CONTENUES DANS CETTE PUBLICATION SONT FOURNIES « EN L’ÉTAT ». EMC
CORPORATION NE FOURNIT AUCUNE DÉCLARATION OU GARANTIE D’AUCUNE SORTE
CONCERNANT LES INFORMATIONS CONTENUES DANS CETTE PUBLICATION ET REJETTE PLUS
SPÉCIALEMENT TOUTE GARANTIE IMPLICITE DE QUALITÉ COMMERCIALE OU D’ADÉQUATION À
UNE UTILISATION PARTICULIÈRE.
L’utilisation, la copie et la distribution de tout logiciel EMC décrit dans cette publication exigent une licence
logicielle en cours de validité.
Pour obtenir les informations légales les plus récentes concernant votre famille de produits, consultez la
rubrique Documentations et conseils techniques du site Web du Support en ligne EMC.
Pour obtenir la liste actualisée des noms de produits, consultez la rubrique des marques EMC via le lien
Législation, sur http://france.emc.com.
Toutes les autres marques citées dans le présent document sont la propriété de leurs détenteurs respectifs.
Référence H6109.5
2
Présentation des technologies mainframe EMC version 2.0
Sommaire
Titre
Page
Préface
Chapitre 1
Introduction
Présentation des produits mainframe EMC..................................
Compatibilité garantie .....................................................................
Technologies clés...............................................................................
Initiatives EMC innovantes .............................................................
Chapitre 2
22
23
24
25
Matériel mainframe
Matériel Symmetrix et Enginuity .................................................... 28
Système d’exploitation Enginuity ............................................ 28
Présentation ................................................................................. 31
Détails de l’architecture ............................................................. 32
Modèles disponibles................................................................... 34
Technologies de disque disponibles ........................................ 36
Data at Rest Encryption ............................................................. 40
Instant VTOC (iVTOC) pour CKD ........................................... 43
Adressage des LCU (unités de contrôle logique) dans
Enginuity 5876............................................................................. 44
Gestion électronique des licences............................................. 45
Reporting d’erreurs à l’hôte mainframe.................................. 47
Reporting de gravité SIM (Service Information Message) ... 49
Messages opérateur .................................................................... 56
Fonctions mainframe prises en charge .......................................... 59
Logiciels et solutions connexes.................................................66
Conditions préalables ................................................................ 66
Octroi de licences ........................................................................ 66
Remarque concernant le numéro de série alpha de VMAX ........ 67
3
Sommaire
Affichage des numéros de série numériques et alpha de
VMAX........................................................................................... 68
Matériel EMC Centera ..................................................................... 69
Avantages et exemples d’utilisation........................................ 70
Logiciels et solutions connexes................................................. 72
Conditions préalables ................................................................ 72
Octroi de licences........................................................................ 72
Mainframe Data Library .................................................................. 73
Mainframe Data Library : 1000 et 2000 ................................... 74
Mainframe Data Library : 4000 et 6000 ................................... 74
Mainframe Data Library : 100V................................................ 74
Chapitre 3
Virtual Provisioning
Introduction....................................................................................... 76
Terminologie...................................................................................... 78
Virtual Provisioning : présentation de la mise en œuvre............ 80
Performances ..................................................................................... 81
Virtual Provisioning : instructions de configuration ................... 82
Dimensionnement des ressources pour les
périphériques thin ...................................................................... 83
Conditions supplémentaires requises par le cache ............... 84
Conditions relatives à l’organisation du thin pool ................ 84
Ajout de capacité à un thin pool............................................... 86
Rééquilibrage de thin pool ........................................................ 86
Compression des périphériques thin....................................... 87
Remarques concernant la migration thick-to-thin................. 89
Réplication en local et à distance et Virtual Provisioning........... 90
Virtual Provisioning avec Mainframe Enablers (MFE) ............... 91
Exemples d’utilisation de GPM
(General Pool Maintenance)...................................................... 93
Création et affichage de thin pools .......................................... 93
Augmentation de la capacité et
rééquilibrage d’un thin pool ..................................................... 96
Compression des périphériques thin..................................... 100
Clonage thick-to-thin TimeFinder/Clone avec fonction
automatique de lien/suppression de lien............................. 105
Mobilité des périphériques avec Virtual Provisioning.............. 108
Surveillance des pools Virtual Provisioning................................ 111
Récupération d’espace dans un thin pool ................................... 112
Fonction de récupération SRDF thick R1 .............................. 114
4
Sommaire
Chapitre 4
Hiérarchisation du stockage
Introduction ..................................................................................... 118
Avantages de FAST VP ............................................................119
Concepts fondamentaux de FAST VP .......................................... 119
Périodes FAST VP ........................................................................... 121
Périodes de collecte des données............................................121
Périodes de déplacement des données ..................................121
FAST VP et SMS (System Managed Storage) .............................. 122
System Managed Storage.........................................................122
FAST VP améliore les fonctions de SMS ...............................123
Implémenter FAST VP avec SMS ...........................................124
Méthode de tolérance ...............................................................125
Méthode d’exploitation............................................................126
FAST VP et HSM ............................................................................. 127
Gestion de l’espace par HSM ..................................................127
Gestion de la disponibilité par HSM......................................129
Limitations de HSM..................................................................130
Comparaison entre FAST VP et HSM ....................................130
Avantages de FAST VP ............................................................132
Recommandations ....................................................................132
Gestion FAST VP ............................................................................. 133
Tier Advisor ..................................................................................... 133
Chapitre 5
Gestion du stockage
EMC z/OS Storage Manager......................................................... 136
Surveiller le stockage Symmetrix ...........................................136
Effectuer des opérations SRDF et TimeFinder......................138
Effectuer des opérations GNS (Group Name Services).......140
Principaux avantages ...............................................................140
Symmetrix Management Console................................................. 141
Fonctions ....................................................................................141
Avantages...................................................................................142
Logiciels et solutions associés .................................................142
Licences ......................................................................................143
Symmetrix Performance Analyzer (SPA) .................................... 143
Vue Temps réel..........................................................................144
Vue Diagnostic ..........................................................................144
Snapshot .....................................................................................144
Tendances...................................................................................145
Unisphere for VMAX...................................................................... 146
Fonctions ....................................................................................146
Avantages...................................................................................147
5
Sommaire
Documentation et solutions .................................................... 147
Licences ...................................................................................... 148
Chapitre 6
Protection des informations
Introduction..................................................................................... 150
Mainframe Enablers ....................................................................... 151
Composants de Mainframe Enablers .................................... 151
Autres fonctions........................................................................ 153
ResourcePak Base for z/OS........................................................... 154
Autres utilitaires ....................................................................... 157
Avantages et exemples d’utilisation...................................... 157
Logiciels et solutions associés................................................. 158
Conditions préalables .............................................................. 158
Famille de produits SRDF pour z/OS ......................................... 159
SRDF Host Component for z/OS........................................... 160
Fonctions mainframe de SRDF ............................................... 161
SRDF/Synchronous ................................................................. 162
SRDF/Asynchronous............................................................... 162
SRDF/Data Mobility................................................................ 163
Concurrent SRDF et SRDF/Star ............................................. 163
Concurrent SRDF/Asynchronous ......................................... 165
Multi-Session Consistency ...................................................... 166
SRDF/Cascaded ....................................................................... 166
SRDF/Extended Distance Protection (EDP)......................... 167
SRDF/Star ................................................................................. 167
SRDF/Consistency Groups..................................................... 168
SRDF/AR (réplication automatisée)...................................... 168
TimeFinder/Snap off an SRDF/A R2.................................... 169
Compression logicielle SRDF.................................................. 170
Compression matérielle pour la carte
réseau distante Fibre Channel ................................................ 171
Prise en charge de FAST VP par SRDF ................................. 171
SRDF en mode mixte................................................................ 172
Licences ...................................................................................... 173
Famille de produits EMC TimeFinder pour z/OS..................... 174
TimeFinder/Clone for z/OS................................................... 174
TimeFinder/Snap for z/OS .................................................... 175
TimeFinder/Mirror for z/OS ................................................. 176
TimeFinder/CG ........................................................................ 177
Consistent Dataset Snap .......................................................... 178
6
Sommaire
Duplicate Snap ..........................................................................179
Simultaneous TimeFinder/Clone...........................................181
Conditions préalables...............................................................184
Licences ......................................................................................184
AutoSwap......................................................................................... 185
Caractéristiques d’AutoSwap .................................................185
Avantages et exemples d’utilisation ......................................186
Licences ......................................................................................187
EMC GDDR...................................................................................... 187
Configurations de continuité d’activité prises en charge....188
SRDF/S avec ConGroup ..........................................................189
SRDF/S avec AutoSwap ..........................................................190
SRDF/A......................................................................................192
SRDF/Star ..................................................................................193
SRDF/Star avec AutoSwap .....................................................196
Licences ......................................................................................201
Chapitre 7
Migration et mobilité des données
Introduction ..................................................................................... 204
InfoMover......................................................................................... 205
IFT (InfoMover File Transfer) .................................................205
IFS (InfoMover File System) ....................................................205
Licences ......................................................................................208
z/OS Migrator ................................................................................. 208
Technologie de migration ........................................................209
Licences ......................................................................................210
Chapitre 8
Sauvegarde et archivage
Introduction ..................................................................................... 212
EMC Disk Library for Mainframe (DLm).................................... 213
DLm1000 ....................................................................................214
DLm2000 ....................................................................................214
DLm6000 ....................................................................................215
7
Sommaire
EMC Centera Mainframe HSM Migrator.................................... 216
Avantages .................................................................................. 218
Caractéristiques ........................................................................ 219
Migration différée..................................................................... 221
Configuration système............................................................. 221
Partenaires Centera .................................................................. 221
Produits associés à Centera..................................................... 223
Licences ...................................................................................... 223
SDK EMC Centera Mainframe (kit d’outils API)....................... 223
Produits associés....................................................................... 224
Licences ...................................................................................... 224
Chapitre 9
Compatibilité mainframe
Introduction..................................................................................... 226
Prise en charge de JES .................................................................... 227
Présentation des produits EMC Compatible .............................. 228
Compatible Flash for z/OS ........................................................... 229
Licences ...................................................................................... 231
Compatible Native Flash for Mainframe .................................... 231
Licences ...................................................................................... 234
Limitations et restrictions........................................................ 234
Compatible Extended..................................................................... 236
Licences ...................................................................................... 237
Compatible Peer.............................................................................. 238
Licences ...................................................................................... 239
Extended Remote Copy Enhanced Multiple Reader................. 240
8
Sommaire
PPRC/XRC Incremental Resync ................................................... 244
Chapitre 10
Considérations relatives aux performances
Introduction ..................................................................................... 248
Parallel Access Volumes (PAV)...................................................... 249
Gérer le problème des temps de mise en file
d’attente des E/S (IOSQ) .........................................................249
PAV statiques ............................................................................250
PAV dynamiques ......................................................................250
HyperPAV..................................................................................251
Multiple Allegiance......................................................................... 254
Modified Indirect Data Address Word (MIDAW)...................... 255
Avantages...................................................................................255
Exigences ....................................................................................256
FICON............................................................................................... 256
FICON 8 Gbit/s ............................................................................... 258
Exigences ....................................................................................260
High Performance FICON (zHPF)................................................ 260
Configuration requise pour zHPF ..........................................263
Contrôle de zHPF sur les baies VMAX..................................264
Multitrack High Performance FICON (zHPF multitrack) ........ 265
Configuration requise pour zHPF multitrack ......................266
Extended Address Volumes (EAV) ............................................... 266
Avantages des EAV ..................................................................267
Volumes EAV et performances...............................................268
Persistent IU Pacing (Extended Distance FICON) ..................... 269
QoS Dynamic Cache Partitioning ................................................. 270
Exemple de JCL .........................................................................271
QoS Symmetrix Priority Control (SPC)........................................ 272
Paramètres de priorité..............................................................273
Copy QoS.......................................................................................... 275
Disques Flash EMC ......................................................................... 276
z/OS et les disques Flash.........................................................277
Chapitre 11
Autres plates-formes
Prise en charge de TPF (Transaction Processing Facility) ......... 280
SRDF Controls for TPF .............................................................281
TimeFinder Controls for TPF ..................................................281
9
Sommaire
ResourcePak for TPF ................................................................ 282
Linux on System z .......................................................................... 284
Consolidation ............................................................................ 284
Systèmes d’exploitation Linux pris en charge...................... 285
Linux on System z - Options de connectivité ....................... 286
Linux on System z - Options de disque ................................ 286
Exemple de connectivité FCP ................................................. 287
Exemple de connectivité ECKD ............................................. 290
DASDFMT sous z/VM ............................................................ 292
Multipathing ............................................................................. 293
EMC Solutions Enabler............................................................ 294
Chapitre 12
Offres du programme de partenariat pour les systèmes
mainframe
Programme EMC Select ................................................................. 296
CentricStor : Fujitsu Siemens Corporation (FSC)....................... 297
Extension de distance pour la famille EMC SRDF..................... 298
Ciena CN 2000........................................................................... 298
Ciena CN 4200........................................................................... 298
Brocade UltraNet Edge 3000................................................... 299
Chapitre 13
Offres de services professionnels pour les systèmes
mainframe
Introduction..................................................................................... 302
EMC Mainframe Professional Services ....................................... 303
Implementation for Mainframe Storage Replication................. 303
Conditions d’application......................................................... 303
Positionnement du service ...................................................... 304
Data Migration for Mainframe. .................................................... 305
Design and Implementation for Mainframe Connectivity ....... 306
Assessment for Mainframe Tape Environments ........................ 308
Data Migration for Disk Library for Mainframe........................ 310
10
Sommaire
Conditions d’application .........................................................310
Positionnement du service.......................................................311
Implementation for Disk Library for Mainframe ....................... 312
Conditions d’application .........................................................312
Positionnement du service.......................................................313
Annexe A
Outils de productivité transférés à Rocket Software
Catalog Solution .............................................................................. 316
Caractéristiques.........................................................................317
Licences ......................................................................................319
Performance Essential .................................................................... 319
Licences ......................................................................................321
TeraSAM ........................................................................................... 322
Licences ......................................................................................323
VSAM Assist .................................................................................... 324
Licences ......................................................................................326
VSAM Quick Index ......................................................................... 326
Licences ......................................................................................328
Glossaire
Index
11
Sommaire
12
Figures
Titre
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Page
Relations entre Enginuity et la plate-forme de stockage .......................... 28
Architecture de la gamme EMC VMAX ..................................................... 32
Sous-système EMC VMAX SE (configuration minimale/maximale) .... 35
Sous-système EMC VMAX (configuration minimale/maximale) .......... 36
Configuration de boucles de disques standard du Symmetrix VMAX.. 38
Configuration d'EMC VMAX avec boucles de disques étendues........... 38
Architecture Data Encryption du VMAX ................................................... 41
Écran affichant le statut de DARE ............................................................... 42
Écran de gestion électronique des licences................................................. 46
Format des messages d’erreur de type alerte de service IEA480E
dans z/OS (coupure d’alimentation CA) ................................................... 57
dans z/OS (volume miroir-1 à l’état Not Ready ) ..................................... 57
dans z/OS (resynchronisation du volume miroir-2) ................................ 58
dans z/OS (resynchronisation du volume miroir-1) ................................ 58
Commande opérateur z/OS d’affichage du numéro de série alpha ...... 67
Utilisation d’EMC Centera sur un mainframe........................................... 70
Fonctionnement du provisionnement standard
(Thick Provisioning) dans les baies Symmetrix ......................................... 76
Virtual Provisioning avec baie Symmetrix VMAX ................................... 77
Thin pool non équilibré ................................................................................. 98
Thin pool rééquilibré ..................................................................................... 99
Provisionnement virtuel et FAST VP ........................................................ 120
FAST et SMS - Méthode de tolérance ........................................................ 125
FAST VP et SMS - Méthode d’exploitation .............................................. 126
Chevauchements fonctionnels entre HSM et FAST VP.......................... 131
Modèle de Tier Advisor .............................................................................. 134
Menu principal d’EzSM .............................................................................. 137
13
Figures
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
14
Options de gestion des groupes SRDF......................................................
SPA - Vue Snapshot affichant plusieurs relations...................................
Architecture SymmAPI de z/OS ...............................................................
Famille SRDF pour z/OS ............................................................................
Configuration classique de prise en charge SRDF/Star.........................
Diagramme des blocs SRDF/EDP .............................................................
Famille de produits TimeFinder pour z/OS ............................................
Duplicate Snap..............................................................................................
Environnement SRDF/S sans Parallel Clone...........................................
Environnement SRDF/S avec Parallel Clone...........................................
Configuration SRDF/S avec ConGroup sur deux sites..........................
Configuration GDDR avec SRDF/S et AutoSwap sur deux sites.........
Configuration SRDF/A sur deux sites......................................................
GDDR dans un environnement Concurrent SRDF/Star........................
GDDR avec Cascaded SRDF/Star .............................................................
GDDR dans un environnement Concurrent SRDF/Star
avec AutoSwap .............................................................................................
GDDR dans un environnement Cascaded SRDF/Star
avec AutoSwap .............................................................................................
Centera Mainframe HSM Migrator ...........................................................
Topologie XRC avec lecteur unique ..........................................................
Topologie XRC avec lecteurs multiples ....................................................
Environnement Incremental Resync .........................................................
PAV statiques, PAV dynamiques et HyperPav ......................................
Un nœud haute disponibilité (HA) unique dans un
contrôleur VMAX .........................................................................................
Séquences de commandes et de données FICON ...................................
Séquences de commandes et de données zHPF ......................................
Nouvel affichage et ancien affichage de la commande QOSGET.........
Invités Linux utilisant des périphériques FBA ........................................
Linux on System z - Relations avec les chemins de
périphériques FBA .......................................................................................
Machines virtuelles Linux invitées utilisant des
périphériques ECKD. ...................................................................................
Linux on System z - Relations avec les chemins de
périphériques ECKD ....................................................................................
Structure des catalogues .............................................................................
Performance Essential .................................................................................
Segmentation des Datasets avec TeraSAM ..............................................
Avantages de VSAM Assist........................................................................
138
145
155
160
164
167
174
180
182
182
189
191
192
194
195
197
198
217
240
242
244
250
257
262
262
276
288
290
291
292
316
320
322
325
Tableaux
Titre
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Page
Modèles VMAX ............................................................................................... 34
Capacités et disques pris en charge sur le VMAX 40K.............................. 36
Nombre de disques minimal et maximal du VMAX et
du VMAX 20K .................................................................................................. 39
Nombre de disques minimal et maximal du VMAX 40K ......................... 39
Nb maximal de LPAR pris en charge par port rattaché ............................ 45
Niveaux de gravité des alertes SIM .............................................................. 49
Erreurs d’environnement signalées sous forme de messages SIM
(5874, 5875) ....................................................................................................... 50
Erreurs d’environnement signalées sous forme de
messages SIM (5876) ....................................................................................... 54
Fonctions mainframe prises en charge par le sous-système
EMC Symmetrix VMAX ................................................................................. 59
Terminologie relative à Virtual Provisioning ............................................. 78
Pistes de métadonnées réservées en fonction de la taille
du périphérique de données .......................................................................... 83
Protection recommandée par catégorie de disque : ................................... 85
Matrice d’exemples de migration thick-to-thin .......................................... 89
Commandes centrées sur le pool .................................................................. 91
Commandes centrées sur le périphérique ................................................... 92
Partenaires utilisant l’API EMC Centera pour intégrer
leurs solutions ................................................................................................ 223
Compatibilité JES3......................................................................................... 227
Produits EMC Compatible........................................................................... 228
Paramètres de bit du directeur Symmetrix pour Linux on System z .... 289
15
Tableaux
16
Préface
Afin d’améliorer et de développer les performances et les
fonctionnalités de ses gammes de produits, EMC publie
régulièrement des révisions de ses matériels et logiciels. C’est
pourquoi certaines des fonctions décrites dans ce document peuvent
ne pas être prises en charge par toutes les versions des produits
matériels ou logiciels actuellement utilisés. Pour obtenir les
informations les plus récentes sur les fonctions de votre produit,
consultez ses notes de mise à jour.
Ce document fournit une description complète du matériel, des
logiciels et des solutions EMC pour les utilisateurs mainframe.
Audience
Ce document fait partie de la documentation Symmetrix. Il a été
conçu pour les programmeurs système, les administrateurs de
stockage ou toute personne responsable de la gestion des
environnements mainframe utilisant les technologies EMC.
Les lecteurs de ce document doivent avoir une bonne connaissance
des thèmes suivants :
◆
◆
Organisation
système d’exploitation z/OS ;
principes de base de Symmetrix.
Ce TechBook est divisé en treize chapitres et une annexe présentés
ci-dessous :
Le Chapitre 1, « Introduction » offre un aperçu général des produits
EMC pouvant améliorer une configuration mainframe.
Le Chapitre 2, « Matériel mainframe » fournit des informations
détaillées sur les solutions matérielles EMC pour les environnements
mainframe.
Préface
17
Préface
Le Chapitre 3, « Virtual Provisioning » est une introduction à Virtual
Provisioning et son utilisation dans z/OS.
Le Chapitre 4, « Hiérarchisation du stockage » fournit des
informations sur FAST VP et son interaction avec l’environnement
d’exploitation z/OS.
Le Chapitre 6, « Protection des informations » décrit les produits
EMC prenant en charge la protection, la réplication et la cohérence
des données.
Le Chapitre 5, « Gestion du stockage » décrit les outils logiciels
fournis par EMC pour gérer un sous-système Symmetrix dans un
environnement mainframe.
Le Chapitre 7, « Migration et mobilité des données » décrit les
produits capables de déplacer les données vers et en dehors d’une
configuration mainframe à des fins de migration, de réorganisation
ou de partage des données.
Le Chapitre 8, « Sauvegarde et archivage » fournit des informations
sur les solutions matérielles et logicielles de sauvegarde et
d’archivage.
Le Chapitre 9, « Compatibilité mainframe » explique comment EMC
garantit la compatibilité entre IBM et la gamme de produits
Symmetrix.
Le Chapitre 10, « Considérations relatives aux performances » décrit
les fonctions de performance et les bonnes pratiques en matière de
performance pour les environnements mainframe déployés avec des
sous-systèmes Symmetrix.
Le Chapitre 11, « Autres plates-formes » fournit des informations sur
les systèmes d’exploitation autres que z/OS pris en charge lors de la
connexion à un CPC z/Series.
Le Chapitre 12, « Offres du programme de partenariat pour les
systèmes mainframe » fournit des informations générales sur les
offres de tiers qui améliorent l’environnement mainframe Symmetrix.
Il présente également les offres pouvant être achetées via le
programme d’acquisition EMC Select.
Le Chapitre 13, « Offres de services professionnels pour les systèmes
mainframe » présente les offres EMC Professional Services
disponibles pour les clients mainframe EMC.
18
Préface
L’Annexe 14, « Outils de productivité transférés à Rocket Software »
décrit la suite de logiciels de productivité qui appartenait à EMC mais
est désormais la propriété de Rocket Software.
Conventions utilisées
dans ce document
EMC utilise les conventions suivantes pour les notes spéciales.
Remarque : Une remarque donne une information importante, mais non
vitale.
Un avertissement donne des informations essentielles afin d’éviter
toute perte de données ou d’endommager le système ou les
équipements.
Conventions
typographiques
EMC utilise les conventions typographiques suivantes dans le
présent document :
Normal
Dans le texte courant (autre que les procédures) pour :
• noms des éléments d’interface (tels que les noms des fenêtres, boîtes de dialogue,
boutons, champs et menus) ;
• noms de ressources, attributs, pools, expressions booléennes, boutons,
déclarations DQL, mots-clés, clauses, variables d’environnement, fonctions,
utilitaires ;
• URL, noms de chemins, noms de fichiers, noms de répertoires, noms
d’ordinateurs, noms de fichiers, liens, groupes, clés de services, systèmes de
fichiers, notifications.
Gras
Dans le texte courant (autre que les procédures) pour :
• noms de commandes, démons, options, programmes, processus, services,
applications, utilitaires, noyaux, notifications, appels système, pages man.
Utilisé dans les procédures pour :
• noms des éléments d’interface (tels que les noms des fenêtres, boîtes de dialogue,
boutons, champs et menus) ;
• élément que l’utilisateur sélectionne ou qu’il saisit, ou sur lequel il clique ou appuie.
Italique
Utilisé dans tout le texte (y compris les procédures) pour :
• les titres complets de publications citées dans le texte,
• mise en évidence (d’un nouveau terme par exemple) ;
• les variables.
Courier
Utilisé pour :
• les données de sortie du système, telles que les messages d’erreur ou les scripts ;
• les URL, les chemins d’accès complets, les noms de fichiers, les invites et la
syntaxe ne faisant pas partie du texte courant.
19
Préface
Courier Gras
Utilisé pour :
• entrée spécifique de l’utilisateur (comme les commandes).
Courier Italique
Utilisé dans les procédures pour :
• variables de la ligne de commande ;
• les variables entrées par l’utilisateur.
<>
Les chevrons simples entourent les valeurs de paramètres ou de variables indiquées
par l’utilisateur.
[]
Les crochets entourent les valeurs facultatives.
|
Une barre verticale indique les sélections alternatives (la barre signifie « ou »).
{}
Les accolades indiquent du contenu que l’utilisateur doit spécifier, c’est-à-dire x ou y
ou z.
…
Les points de suspension indiquent des informations non essentielles omises dans
l’exemple.
Équipe de rédaction du présent TechBook
Ce TechBook a été rédigé par une équipe de l’entité Symmetrix
Business Operations Unit basée à Hopkinton dans le Massachusetts.
Paul Pendle travaille depuis 35 ans dans le domaine de la
programmation des systèmes mainframe, des bases de données et
des applications, comme client et comme fournisseur. Il est
actuellement Senior Consulting Corporate Systems Integration
Engineer au siège d’EMC, à Hopkinton (Mass., États-Unis). Paul a
rejoint EMC en 1998 en tant que Spécialiste Software. Au fil des ans,
Paul s’est spécialisé dans les bases de données et la performance. Il
intervient régulièrement dans les manifestations IOD, IDUG et
SHARE, ainsi que dans les conférences professionnelles d’EMC. Paul
est un IBM Information Champion reconnu sur IBM.com.
Tony Negro est Senior Consulting Corporate Systems Engineer. Il
travaille chez EMC depuis 16 ans. Il a plus de 35 ans d’expérience des
systèmes mainframe et est spécialisé dans la continuité d’activité et la
reprise après sinistre/le redémarrage des grandes entreprises.
Vos commentaires sont les bienvenus !
Nous apprécions à leur juste valeur vos commentaires sur nos
TechBooks. Nous voulons que nos livres soient aussi utiles et
pertinents que possible. Vous pouvez nous y aider en nous envoyant
vos commentaires, vos avis et vos réflexions sur ce TechBook ou un
autre à l’adresse suivante :
[email protected]
20
1
Introduction
Ce chapitre présente les produits, les solutions et les initiatives
continues proposées par EMC dans le cadre de son offre actuelle de
technologies mainframe variées.
◆
◆
◆
◆
Présentation des produits mainframe EMC...................................
Compatibilité garantie.......................................................................
Technologies clés ................................................................................
Initiatives EMC innovantes ..............................................................
Introduction
22
23
24
25
21
Introduction
Présentation des produits mainframe EMC
Le présent guide fournit des informations visant à familiariser
l’utilisateur avec les fonctions actuellement disponibles sur les
logiciels et les matériels EMC pour un environnement mainframe
dédié ou un environnement d’entreprise (combinant systèmes
mainframe et ouverts).
Sur le plan matériel, EMC Corporation fournit des technologies de
disque révolutionnaires dédiées aux environnements mainframe
depuis 1990, date à laquelle a été lancée sa toute première gamme de
baies de disques avec cache intégré EMC® Symmetrix®. EMC fut la
première entreprise à cerner les avantages implicites d’un
sous-système de stockage constitué de nombreux disques durs
indépendants intégrés dans une baie (baie redondante de disques
indépendants ou RAID) par rapport à la technologie de disque
standard de l’époque, parfois appelée SLED (Single Large Expensive
Disk). Au cours des deux dernières décennies, l’industrie du stockage
dans son ensemble a peu à peu intégré la vision du sous-système telle
qu’elle était présentée par EMC. Le sous-système Symmetrix VMAX™,
successeur du DMX™ (Direct Matrix), adopte une architecture de
type Virtual Matrix™ capable d’évoluer au-delà des limites physiques
d’un système unique ; capacité non négligeable en raison de la
croissance des taux d’E/S et des fonctions de la plupart des
environnements informatiques actuels. Le moteur Symmetrix VMAX
est au cœur de l’architecture Virtual Matrix. Il intègre un cache, une
connectivité front-end et une connectivité back-end qui constituent le
module du sous-système Symmetrix VMAX. Virtual Matrix peut
recevoir jusqu’à huit moteurs VMAX dans un seul sous-système avec
ressources de connectivité, de traitement et de capacité entièrement
partagées. La conception révolutionnaire de cette nouvelle
plate-forme matérielle repose sur l’expérience acquise avec la gamme
de sous-systèmes Symmetrix DMX robustes.
Sur le plan logiciel, EMC continue à valoriser les atouts des logiciels
de stockage en proposant notamment des solutions de réplication en
local et à distance, ainsi que d’autres fonctionnalités traitées dans
d’autres chapitres. C’est d’ailleurs en raison de son offre variée de
fonctions logicielles qu’EMC profite d’une telle présence au sein des
infrastructures informatiques des entreprises leaders à travers le monde.
22
Introduction
La section suivante présente les nombreuses offres logicielles pour
l’environnement mainframe. EMC continue à développer et à
améliorer les fonctions destinées aux environnements mainframe de
ses clients.
Compatibilité garantie
EMC garantit la compatibilité des fonctions avec les offres IBM
comparables via un accord complet de licence technologique et une
procédure étendue de test de ces fonctions. L’accord technologique
avec IBM améliore en outre la capacité d’EMC à fournir des logiciels
de gestion du stockage hétérogène.
À mesure qu’IBM enrichit les fonctions des environnements
mainframe, EMC reste en phase et propose des capacités innovantes
et une compatibilité sans faille. Pour illustrer cet engagement, EMC a
conçu un laboratoire GDPS (Geographically Dispersed Parallel
Sysplex) complet qui permet de tester et de développer des
fonctionnalités dans les environnements GDPS. Ainsi, la robustesse
des fonctionnalités des matériels et des logiciels dans les
environnements GDPS des clients est garantie dès le premier jour.
Les sous-systèmes Symmetrix VMAX et DMX-3/4 sont compatibles
avec les modes des unités de contrôle IBM 2105 ou 2107 lorsqu’ils
sont configurés dans un environnement d’exploitation z/OS actuel. Il
est facile de configurer les sous-systèmes Symmetrix VMAX et
DMX-3/4 de cette manière en vérifiant d’abord les conditions
préalables requises par les logiciels et autres installations contenus
dans le bucket IBM PSP (Preventive Service Planning), puis en
suivant les procédures indiquées dans la documentation IBM
appropriée pour HCD (Hardware Configuration Definition) et son
interface utilisateur HCM (Hardware Configuration Manager). HCD
est le point de contrôle unique de toutes les données matérielles et
logicielles pour z/OS, et ses sorties sont stockées dans le fichier IODF
(I/O Definition File), qui est utilisé comme entrée du processus de
création IOCDS.
Les exigences procédurales de HCD, IOCDS, IODF et autres sont
définies par IBM. Elles déterminent l’application des modifications
requises par le modèle de processeur en cours ou par d’autres
exigences spécifiques de LPAR.
Compatibilité garantie
23
Introduction
Par ailleurs, le sous-système Symmetrix obéit et répond de manière
appropriée à toutes les commandes d’opérateur DASD et z/OS telles
que spécifiées dans le Guide des commandes d’opérateur IBM z/OS et la
documentation IBM associée, en produisant la sortie d’affichage
attendue et appropriée (pour les commandes d’opérateur et de
statut), ainsi que la sortie des données et les résultats des commandes
associées aux données (c’est-à-dire, les CCW ou Command Channel
Word) émises par le superviseur IOS (Input Output) de z/OS et du
sous-système de canal. Les baies de la gamme Symmetrix VMAX et
les sous-systèmes DMX-3/4 sont donc entièrement compatibles du
point de vue de la configuration, du fonctionnement et des
fonctionnalités.
Technologies clés
EMC accorde des licences pour les technologies IBM clés suivantes,
garantissant ainsi la compatibilité totale de ses infrastructures de
stockage performantes avec les principales technologies mainframe :
24
◆
PAV statiques
◆
PAV dynamiques
◆
HyperPAV
◆
Extended Address Volume (EAV)
◆
Extended Distance FICON
◆
High Performance FICON (zHPF)
◆
Multi-track High Performance FICON (zHPF multi-track)
◆
MIDAW
◆
IBM Metro Mirror (PPRC)
◆
PPRC/XRC Incremental Resync
◆
IBM z/OS Global Mirror (XRC)
◆
Extended Remote Copy (XRC) Enhanced Multiple Reader
◆
HyperSwap
◆
FlashCopy
◆
Geographically Dispersed Parallel Sysplex (GDPS)
Introduction
Initiatives EMC innovantes
Outre la prise en charge des solutions de réplication en local et à
distance compatibles IBM, EMC propose des solutions de réplication
en local et à distance ultraperformantes telles que EMC TimeFinder®
et SRDF®, respectivement. Ces deux solutions sont étroitement
intégrées dans les environnements mainframe grâce aux EMC
Mainframe Enablers dont les utilitaires s’intègrent en toute
transparence dans le mainframe.
Par ailleurs, les fonctions axées sur les performances telles que Fully
Automated Storage Tiering for Virtual Pools (FAST™ VP), Dynamic
Cache Partitioning (DCP) et Symmetrix Priority Controls (SPC),
fournissent un niveau de contrôle complet et précis des E/S liées aux
différentes charges de travail inhérentes à z/OS. Ces fonctions
complètent d’autres fonctions de performance basées sur z/OS
fonctionnant au sein ou en dehors du périmètre de z/OS Workload
Manager (WLM). Ces fonctions ne sont que quelques exemples des
innovations réelles proposées par EMC pour résoudre les problèmes
globaux de performance de la charge de travail de z/OS, souvent
complexes et divergents.
L’équipe de recherche et de développement d’EMC faisant
constamment évoluer les fonctionnalités des produits, les capacités
décrites dans le présent document sont régulièrement modifiées et
améliorées. Ce document est mis à jour à mesure que de nouvelles
fonctions sont créées et validées dans les environnements des clients.
Remarque : Pour plus d’informations sur l’ensemble des produits et
fonctions présentés dans ce document, consultez le site Web de Support en
ligne EMC : http://support.EMC.com.
Initiatives EMC innovantes
25
Introduction
26
2
Matériel mainframe
Ce chapitre présente les produits matériels utilisés dans une
configuration mainframe.
◆
◆
◆
◆
◆
Matériel Symmetrix et Enginuity ....................................................
Fonctions mainframe prises en charge ...........................................
Remarque concernant le numéro de série alpha de VMAX ........
Matériel EMC Centera.......................................................................
Mainframe Data Library ...................................................................
Matériel mainframe
28
59
67
69
73
27
Matériel mainframe
Matériel Symmetrix et Enginuity
La gamme EMC Symmetrix VMAX, l’architecture matérielle
Symmetrix DMX et Enginuity™ Operating Environment constituent
la base de la plate-forme de stockage Symmetrix.
Un environnement Symmetrix comprend les composants suivants :
◆
Matériel Symmetrix (gamme VMAX ou DMX)
◆
Fonctions d’exploitation Enginuity
◆
API Symmetrix pour environnement mainframe
◆
Applications Symmetrix
◆
Applications Symmetrix basées sur l’hôte
◆
applications d’éditeurs indépendants
La Figure 1 de la page 28 présente la relation entre ces couches
logicielles et le matériel Symmetrix.
Symmetrix applications
Host-based Symmetrix applications
Independent Software Vendor applications
EMC Mainframe Enabler applications program interface (API)
Enginuity operating environment functions
Symmetrix hardware
ICO-IMG-000746
Figure 1
Relations entre Enginuity et la plate-forme de stockage
Système d’exploitation Enginuity
L’environnement d’exploitation du stockage Enginuity est l’élément
névralgique qui commande l’ensemble des composants du
sous-système de stockage EMC Symmetrix.
28
..
Matériel mainframe
Cet environnement d’exploitation du stockage intelligent, multitâche
et préemptif contrôle le flux des données de stockage. Il est entièrement
dédié aux opérations de stockage et optimisé pour les niveaux de
service exigés dans les environnements haut de gamme. En dépit de
nombreux points communs avec les systèmes d’exploitation des
serveurs hôtes de grande taille généralement utilisés, il est davantage
spécialisé dans des fonctions de stockage et spécifiquement optimisé
pour ces dernières. Il est piloté par des événements en temps réel
relatifs à l’entrée et à la sortie des données. Grâce à ses capacités
d’auto-optimisation, il assure le niveau élevé de performances, de
disponibilité et d’intégrité des données que l’on attend d’une
plate-forme dotée de fonctions de stockage avancées. Indispensable
aux structures informatiques complexes, exigeantes et intolérantes au
risque, la combinaison Enginuity/Symmetrix constitue le fondement
technologique incontournable de services de stockage haut de
gamme avancés et économiques.
L’environnement d’exploitation du stockage éprouvé Enginuity
apporte à chaque nouvelle génération de plate-forme Symmetrix
l’ensemble de ses développements étendus et systématiques, ce qui
constitue un avantage majeur pour les utilisateurs en termes
opérationnels et de protection de l’investissement. En clair, toutes les
fonctions de fiabilité, de disponibilité et de maintenance, toute
l’interopérabilité et la compatibilité des systèmes d’exploitation
d’hôtes et toutes les capacités logicielles applicatives développées par
EMC et ses partenaires s’exécutent de manière transparente et
performante, même après actualisation de la technologie
sous-jacente. Ces fonctionnalités et ces capacités sont entièrement
opérationnelles dès le premier jour sur chaque version de Symmetrix.
Enginuity remplit les fonctions suivantes :
◆
Il gère les ressources système afin d’optimiser intelligemment les
performances d’un large éventail de besoins d’E/S.
◆
Il assure la disponibilité du système grâce à ses fonctions
avancées de surveillance, de détection et de correction des
défaillances, et fournit des capacités simultanées de maintenance
et de facilité de service.
◆
Il établit les bases requises pour les fonctionnalités logicielles
spécifiques des logiciels EMC de reprise après sinistre, de
continuité d’activité et de gestion du stockage.
◆
Il fournit les services fonctionnels nécessaires au fonctionnement
de Symmetrix et aux nombreux logiciels applicatifs de stockage
EMC.
29
Matériel mainframe
◆
Il définit la priorité de chaque tâche, notamment la maintenance
de base du système, le traitement des E/S et le traitement des
applications.
◆
Il assure un accès uniforme aux appels internes grâce à ses API et
fournit une interface externe permettant l’intégration avec
d’autres éditeurs de logiciels indépendants.
◆
Il fournit la fonction Data at Rest Encryption pour tout ou partie
des disques du sous-système VMAX. Cette fonction s’accompagne
de services de gestion des clés sur le processeur de service.
Enginuity permet aux sous-systèmes Symmetrix de se connecter à
des centaines de types de serveur, à plusieurs dizaines de systèmes
d’exploitation et de logiciels de stockage, ainsi qu’aux d’éléments de
connectivité réseau et autres périphériques les plus utilisés, des
adaptateurs HBA aux pilotes en passant par les switches et les
sous-systèmes à bande.
À partir de la gamme Symmetrix VMAX, une licence Enginuity est
requise. La licence Enginuity est octroyée en fonction de la capacité
brute du système et doit être achetée pour chaque nouveau
sous-système Symmetrix VMAX et chaque mise à niveau. Sur le
sous-système Symmetrix VMAX, les licences de systèmes
d’exploitation et de gestionnaires d’éléments sont ainsi accordées
selon les normes du secteur.
Gamme Symmetrix VMAX
Le Symmetrix VMAX avec environnement d’exploitation Enginuity
est le premier sous-système haut de gamme spécifiquement dédié au
datacenter virtuel. Les baies Symmetrix VMAX, qui sont basées sur la
technologie Virtual Matrix Architecture, permettent de faire évoluer
les performances et la capacité vers des niveaux sans précédent et
garantissent un fonctionnement sans interruption de service. En
outre, elles simplifient et automatisent considérablement la gestion et
la protection des informations. La hiérarchisation avancée fournie par
FAST VP à l’aide des disques Flash, Fibre Channel et SATA permet
aux utilisateurs de s’assurer que les données adéquates sont placées
sur le niveau de stockage approprié au bon moment, optimisant ainsi
les performances et les coûts.
30
Matériel mainframe
La technologie Virtual Matrix Architecture est au cœur du
sous-système Symmetrix VMAX. Elle est conçue pour supprimer les
frontières physiques des architectures de stockage à backplane fixe.
Ce système évolutif peut atteindre plusieurs dizaines de pétaoctets,
prendre en charge des milliers de serveurs virtuels, exécuter des
millions d’E/S par seconde et fournir une disponibilité quasiment
continue.
Les avantages de cette architecture scale-out unique, de même que les
nouvelles fonctions d’Enginuity Operating Environment, sont
essentiels pour faciliter la transition des clients vers une
infrastructure de datacenter virtuel. Capacité d’évolution
dynamique, simplification et automatisation des tâches
opérationnelles sont autant d’atouts qui répondent aux besoins d'une
infrastructure exigeante et contribuent à réduire le coût des
déploiements virtuels et physiques.
Présentation
La conception du Symmetrix VMAX repose sur un moteur VMAX
haute disponibilité intégrant un CPU redondant, doté d’une mémoire
et proposant des connexions sur deux directeurs afin d’optimiser la
tolérance aux pannes. Les moteurs Symmetrix VMAX se connectent
et s’étendent de façon linéaire à travers l’architecture Virtual Matrix
Architecture pour le partage des ressources dans et entre les moteurs
Symmetrix VMAX. Des moteurs supplémentaires peuvent être
ajoutés sans interruption de service pour une évolutivité efficace et
dynamique de la capacité et des performances, afin de servir à la
demande toutes les applications.
Le sous-système Symmetrix VMAX est la seule plate-forme haut de
gamme avec des processeurs multicœur qui se caractérisent par une
efficacité énergétique et des performances maximales dans chaque
moteur VMAX. Les configurations Symmetrix VMAX d’entrée de
gamme affichent ainsi des performances bien supérieures avec un
encombrement plus réduit que toute autre sous-système de stockage.
La figure Figure 2 de la page 32 présente l’architecture point à point
et l’interconnexion des principaux composants du sous-système
Symmetrix VMAX.
31
Matériel mainframe
ICO-IMG-000752
Figure 2
Architecture de la gamme EMC VMAX
Détails de l’architecture
Chaque moteur Symmetrix VMAX comprend deux directeurs dotés
d’une grande puissance de traitement, d’une mémoire cache globale
et d’une interface Virtual Matrix pour les communications
interdirecteurs.
Les moteurs Symmetrix VMAX peuvent être configurés de manière à
obtenir une connectivité hôte maximale flexible et des boucles de
disques physiques back-end. Les ports front-end sont configurés
pour des connexions hôtes de type Fibre Channel, iSCSI et FICON.
Pour la réplication à distance, ils utilisent des connexions de type
Fibre Channel et Gigabit Ethernet. Selon les types de connexion, il est
possible d’accroître la vitesse d’autonégociation de un, quatre ou huit
Gbit/s.
32
Matériel mainframe
La communication à large bande passante, à faible latence et non
bloquante autorise le fonctionnement simultané de plusieurs cartes
directrices et de plusieurs instances au sein d’un seul système.
L’interconnexion Virtual Matrix de Symmetrix VMAX est implémentée
à l’aide du protocole RIO (Rapid IO) standard via deux éléments de
commutation redondants. Sur la carte directrice physique, l’interface
Virtual Matrix convertit deux jeux distincts de huit lignes PCI-Express
au protocole RIO. Le boîtier Matrix Interface Board (MIBE) contient
deux switches de matrice indépendants qui assurent les
communications point à point entre les directeurs. Cette matrice
redondante est utilisée pour les écritures mises en miroir à travers les
directeurs, ainsi que pour d’autres signalisations et communications
interdirecteurs.
La gamme Symmetrix VMAX fournit une architecture distribuée
capable d’une grande évolutivité sur un seul sous-système facile à
gérer. En exploitant l’interconnectivité haut débit de nombreux
nœuds, la baie Symmetrix VMAX fournit les éléments constitutifs des
sous-systèmes EMC hautes performances. Cette capacité a
transformé l’espace de stockage d’entreprise et constituera sans
aucun doute la référence pour évaluer les sous-systèmes de stockage
actuels et futurs.
Bien que les avantages de la transition vers une architecture
distribuée soient nombreux et bien compris, il faut également
admettre que la gestion des sous-systèmes distribués est souvent très
complexe. L’environnement d’exploitation Enginuity est le principal
atout de l’architecture distribuée du contrôleur Symmetrix VMAX
utilisé comme sous-système d’exploitation unique.
33
Matériel mainframe
Modèles disponibles
Les contrôleurs de stockage de la gamme VMAX présentent
différentes fonctions, qui ne prennent pas toutes en charge le
mainframe. Le Tableau 1 ci-dessous présente la gamme VMAX, les
niveaux minimaux de microcode de chaque modèle et leur
compatibilité ou non avec FICON.
Tableau 1
Modèles VMAX
Nom du modèle
Microcode Enginuity
minimum
Compatible FICON
VMAXe
5874
Non
VMAX
5874
Oui
VMAX SP
5876
Non
VMAX SE
5874
Oui
VMAX 10K
5876
Non
VMAX 20K
5876
Oui
VMAX 40K
5876
Oui
Le Symmetrix VMAX SE est un sous-système de stockage à moteur
unique comprenant une baie système avec des disques et une logique
système, ainsi qu’une baie de stockage distincte en option. Ce
sous-système intègre un seul moteur VMAX et prend en charge
48 à 360 disques. Il est destiné aux clients qui souhaitent profiter des
performances et des options de réplication d’une baie Symmetrix
sans l’évolutivité ni les fonctions d’entreprise. Le sous-système
Symmetrix VMAX SE ne peut donc pas être mis à niveau vers un
sous-système Symmetrix VMAX avec plusieurs moteurs.
34
Matériel mainframe
Le VMAX, le VMAX 20K et le VMAX 40K sont des sous-systèmes de
stockage haut de gamme capables d’évoluer d’une configuration à un
seul moteur avec armoire système dédiée et baie de stockage unique
vers une configuration plus étendue à huit moteurs utilisant la même
baie système et jusqu’à dix baies de stockage. Ces dernières peuvent
contenir jusqu’à 2 400 disques physiques sur le VMAX et le
VMAX 20K, et jusqu’à 3 200 disques sur le VMAX 40K en
configuration haute densité, pour une capacité de stockage optimale
de 3,8 pétaoctets sur le sous-système. Les clients peuvent faire
évoluer le nombre de connexions hôtes, la capacité du système ou ses
performances en ajoutant simplement des moteurs ou des baies de
disques en fonction de leurs besoins. Chaque ajout de moteur permet
d’accroître de 128 Go supplémentaires la capacité du cache. Avec une
configuration complète à huit moteurs, il est donc possible de
cumuler jusqu’à deux téraoctets de cache système.
Le VMAX 40K permet de séparer ou de répartir les armoires. Les
clients qui sont limités par le nombre de dalles physiques contiguës
peuvent ainsi déployer des armoires espacées physiquement. Deux
baies système peuvent être séparées de 25 mètres. Il n’est pas non
plus nécessaire que les baies de disques reliées en cascade soient
physiquement proches, ce qui accroît la flexibilité du placement et
remédie au problème de limitation de la charge au sol dans le
datacenter du client.
Les figures suivantes présentent le sous-système VMAX SE et le
sous-système VMAX évolutif.
ICO-IMG-000735
Figure 3
Sous-système EMC VMAX SE (configuration minimale/maximale)
35
Matériel mainframe
ICO-IMG-000736a
Figure 4
Sous-système EMC VMAX (configuration minimale/maximale)
Technologies de disque disponibles
Le sous-système Symmetrix VMAX intègre les dernières technologies
de disque combinant de manière optimale capacité, performances et
coût réduit. Pour chaque nouvelle plate-forme matérielle, il est
possible de changer les technologies de disque prises en charge.
Le Tableau 2 présente les disques d’une capacité de 8 Gbit/s pris en
charge sur le contrôleur Symmetrix VMAX 40K.
Tableau 2
36
Capacités et disques pris en charge sur le VMAX 40K
Type de disque
Taille de
disque
Vitesse de
rotation (t/min)
Capacité formatée
(MF)
Fibre Channel 300 Go
3,5 pouces
15 000
279,77 Go
3,5 pouces
15 000
559,54 Go
3,5 pouces
10 000
279,77 Go
3,5 pouces
10 000
559,54 Go
SAS 1 To
2,5 pouces
7 200
956 Go
SAS 2 To
3,5 pouces
7 200
1 827,67 Go
SAS 3 To
3,5 pouces
7 200
2 868 Go
SAS 300 Go
3,5 pouces
10 000
279,77 Go
SAS 600 Go
3,5 pouces
10 000
559,54 Go
SAS 300 Go
2,5 pouces
10 000
279,77 Go
SAS 600 Go
2,5 pouces
10 000
559,54 Go
Matériel mainframe
Tableau 2
Capacités et disques pris en charge sur le VMAX 40K
Type de disque
Taille de
disque
Vitesse de
rotation (t/min)
Capacité formatée
(MF)
SAS 146 Go
2,5 pouces
15 000
139,3 Go
SAS 300 Go
2,5 pouces
15 000
279,7 Go
Flash 100 Go
3,5 pouces
Non disponible
95,61 Go
Flash 200 Go
3,5 pouces
Non disponible
191,21 Go
Flash 400 Go
3,5 pouces
Non disponible
382,33 Go
Flash 200 Go
2,5 pouces
Non disponible
191,21 Go
Flash 400 Go
2,5 pouces
Non disponible
382,33 Go
Pour consulter la documentation des autres contrôleurs Symmetrix,
visitez le site de support en ligne EMC.
Configurations de boucles de disques
Les environnements mainframe hébergent le plus souvent de gros
volumes de données en ligne dont la fréquence d’accès varie
considérablement. La fréquence d’accès fait référence au nombre
d’accès par seconde et par gigaoctet. C’est une mesure des
performances statiques communément acceptée dans le secteur. Le
sous-système Symmetrix VMAX propose deux configurations de
boucles de disques offrant suffisamment de flexibilité pour satisfaire
les exigences de performances et de capacité des clients.
En configuration standard, ces sous-systèmes intègrent jusqu’à huit
moteurs prenant en charge un maximum de quatre baies de stockage
à connexion directe. Les moteurs un à quatre prennent en charge
jusqu’à 30 disques par boucle, tandis que les moteurs cinq à huit
prennent en charge jusqu’à 45 disques par boucle. Cette
configuration standard est fortement recommandée pour combiner
de manière équilibrée performances et capacités.
37
Matériel mainframe
Front view
System Bay
Storage bays
Storage bays
8 DA PAIR
45 drive loops
30 drive loops
30 drive loops
45 drive loops
45 drive loops
30 drive loops
30 drive loops
45 drive loops
Daisy full
2A
Direct full
1B
Daisy full
3C
Daisy full
2C
Direct full
1C
Direct full
1A
Daisy full
2B
Direct full
1D
Daisy full
2D
Daisy full
3D
ICO-IMG-000817
Figure 5
Configuration de boucles de disques standard du Symmetrix VMAX
Les configurations des sous-systèmes à boucles de disques étendues
comprennent deux à quatre moteurs prenant en charge jusqu’à deux
baies de stockage direct et jusqu’à quatre niveaux de baies de disques
reliées en cascade. Il est ainsi possible de prendre en charge des
boucles englobant jusqu’à 75 disques. Ces configurations sont
parfaitement adaptées aux données dont la densité d’accès est
moindre.
Front view
system bay
Storage bays
Storage bays
75 drive loops
75 drive loops
75 drive loops
75 drive loops
Daisy full
4A
Daisy full
3A
Daisy full
2A
Direct full
1A
Direct full
1B
Daisy full
2B
Daisy full
3B
Daisy full
4B
Daisy full
5B
ICO-IMG-000818
Figure 6
38
Configuration d'EMC VMAX avec boucles de disques étendues
Matériel mainframe
Le Tableau 3 présente le nombre de disques minimal et maximal du
VMAX et du VMAX 20K avec des configurations à boucles de
disques étendues.
Tableau 3
Tableau 4
Nombre de disques minimal et maximal du VMAX et du VMAX 20K
Configuration
Nombre de
disques minimal
Nombre de
disques maximal
(configuration
standard)
Nombre de
disques maximal
(configuration à
boucle étendue)
VMAX SE
48
360
Non disponible
VMAX (un moteur)
48
240
600
VMAX (deux moteurs)
88
480
1 200
VMAX (trois moteurs)
128
720
1 800
VMAX (quatre moteurs)
168
1 200
2 400
VMAX (cinq moteurs)
272
1 320
Non disponible
VMAX (six moteurs)
312
1 680
Non disponible
VMAX (sept moteurs)
416
2 040
Non disponible
VMAX (huit moteurs)
456
2 400
Non disponible
Nombre de disques minimal et maximal du VMAX 40K
Configuration
Nombre de
disques minimal
Nombre de
disques maximal
(configuration
standard)
Nombre de
disques maximal
(configuration
dense)
VMAX (un moteur)
48
240
400
VMAX (deux moteurs)
88
480
800
VMAX (trois moteurs)
128
720
1 200
VMAX (quatre moteurs)
168
960
1 600
VMAX (cinq moteurs)
272
1 320
2 000
39
Matériel mainframe
Tableau 4
Nombre de disques minimal et maximal du VMAX 40K
Configuration
Nombre de
disques minimal
Nombre de
disques maximal
(configuration
standard)
Nombre de
disques maximal
(configuration
dense)
VMAX (six moteurs)
312
1 680
2 400
VMAX (sept moteurs)
418
2 040
2 800
VMAX (huit moteurs)
458
2 400
3 200
Data at Rest Encryption
L’environnement d’exploitation Enginuity 5875 et ultérieur prend en
charge Symmetrix Data at Rest Encryption (DARE) sur tous les types
de disques acceptés par le système Symmetrix VMAX. La fonction
Data Encryption n’est pas proposée en tant qu’option de mise à
niveau avec les sous-systèmes VMAX existants (installés avant la
disponibilité d’Enginuity 5875). Elle n’est pas non plus disponible via
le processus de RPQ, car elle utilise des fonctions matérielles
spéciales sur la carte du périphérique. Cette fonction de chiffrement
des disques contrôlé par le directeur au niveau de la carte du
périphérique constitue toutefois un avantage concurrentiel, car les
autres sous-systèmes d’entreprise nécessitent l’utilisation de disques
spéciaux pour le chiffrement.
Remarque : Il n’existe aucun contrôle utilisateur pour activer ou désactiver
Data Encryption dans une baie VMAX.
DARE ajoute la fonction de chiffrement des données au back-end du
contrôleur VMAX, et des services de gestion de clés de chiffrement au
processeur de service. La gestion des clés est fournie par RSA® Data
Protection Manager Lite, qui peut être installé sur le processeur de
service VMAX par le programme d’installation d’Enginuity. Cette
nouvelle fonctionnalité du processeur de service comprend le client
RKM et le logiciel serveur embarqué de RSA. Cette configuration est
illustrée dans la Figure 7.
40
Matériel mainframe
Host
Storage
configuration
management
SAN
IP
RKM client
Director
IO
module
Director
IO
IO
module module
RSA Key
Manager
Key server
IO
module
Key server
Unencrypted data
Encrypted data
Management traffic
Unique key per physical disk
Figure 7
ICO-IMG-000957
Architecture Data Encryption du VMAX
La gestion du cycle de vie des clés Data Encryption repose sur
différents concepts visant à simplifier l’infrastructure de gestion des
clés tout en préservant sa robustesse. Toutes les clés utilisées dans un
sous-système sont propres à un disque individuel ou à ce
sous-système uniquement. La clé de chiffrement de la baie est
générée durant l’installation du sous-système. De nouvelles clés Data
Encryption sont générées chaque fois que des disques sont ajoutés ou
remplacés. Lorsque des disques sont remplacés, les anciennes clés
sont détruites dans la configuration du sous-système et dans le
gestionnaire de clés. Symmetrix Audit Log enregistre tous les
événements de gestion des clés.
41
Matériel mainframe
Les nouvelles interfaces utilisateur fournies avec la fonction Data at
Rest Encryption incluent : des commandes en ligne (dans Symmwin)
permettant de connaître ou mettre à jour l’état du chiffrement au
niveau du matériel, des structures d’E/S et des zones de
configuration du système ; des messages de suivi des erreurs et des
nouveaux événements (spécifiques de Data at Rest Encryption) ; de
nouvelles entrées Audit Log destinées à capturer les événements de
gestion des clés ; et des outils de débogage Symmwin pour connaître
ou mettre à jour les états des clés dans la base de données RKM.
Il est possible de vérifier facilement le statut de DARE en utilisant la
commande DEVICE DISPLAY SUMMARY ou DEVICE DISPLAY
CNTRL (nnnnnnn-nnnnn) qui indique que DARE est activé (ON) ou
désactivé (OFF), comme illustré dans la Figure 8.
ICO-IMG-000960
Figure 8
42
Écran affichant le statut de DARE
Matériel mainframe
Instant VTOC (iVTOC) pour CKD
Pour les programmateurs système et les gestionnaires du stockage
utilisant z/OS, la VTOC (Volume Table of Contents, ou table des
matières du volume) est une structure de données physique sur un
volume de disque, composée de sept types de blocs de contrôle du
Dataset (DSCB, Dataset Control Block). La VTOC décrit les Datasets
qui résident sur un volume donné. Elle décrit également l’espace libre
disponible sur ce volume. La VTOC est généralement écrite durant
l’initialisation du volume par l’utilitaire système IBM ICKDSF.
Chaque volume doit contenir une VTOC pour que z/OS puisse
l’utiliser.
Les spécialistes du Support Clients EMC utilisent quant à eux le
terme VTOC comme un verbe qui signifie « effacer » ou « initialiser »
un sous-système Symmetrix. Cette opération VTOC (parfois appelée
VTOC héritée) place une VTOC élémentaire sur les volumes CKD,
suffisante pour permettre leur modification en ligne, mais
insuffisante par rapport aux attentes des clients. Elle formate
également tous les volumes en écrivant des zéros sur chaque piste. Ce
processus peut prendre du temps sur un contrôleur Symmetrix
volumineux. Pour résoudre ce problème et accélérer l’installation des
périphériques et le transfert vers l’hôte, EMC a développé l’iVTOC.
L’iVTOC (VTOC instantanée) présente l’avantage de fournir un accès
plus précoce au contrôleur de stockage installé pour la première fois,
par rapport à la VTOC héritée. Elle est également utile dans les zones
concernées par des changements de configuration dynamiques en
ligne, comme l’ajout de périphériques, en particulier lorsque les
nouveaux périphériques sont très volumineux, à l’instar des EAV
(Extended Address Volumes).
L’iVTOC implique de marquer les tables comme étant en attente de
destaging (déchargement du cache), tout en autorisant le report du
destaging. Le formatage des pistes peut ainsi être effectué de manière
asynchrone, en arrière-plan. Avec l’iVTOC, si l’hôte écrit sur la piste
(dans le cache) avant que celle-ci soit formatée, la table du cache est
reformatée pour accepter l’écriture. Notez que le formatage des pistes
en arrière-plan est un processus qui sollicite la carte de périphérique
de manière intensive et peut diminuer les performances.
Dans les sous-systèmes comportant des relations SRDF, les mises en
miroir SRDF ne sont pas invalidées car elles sont considérées comme
relevant de la responsabilité de l’opérateur de la VTOC des deux
côtés de la relation SRDF.
43
Matériel mainframe
Remarque : Il est important de noter que les sous-systèmes VMAX qui se
caractérisent par un cache réduit et un grand nombre de périphériques
optent par défaut pour la VTOC héritée (Legacy VTOC, ou LVTOC) sur la
plupart des périphériques.
Adressage des LCU (unités de contrôle logique) dans Enginuity 5876
Dans les versions antérieures à Enginuity 5876, le sous-système
Symmetrix prend en charge un maximum de 64 images de LCU (de
256 périphériques chacune) sur un port FICON, atteignant un
nombre maximal de 16 384 périphériques adressables par port.
Lorsqu’un sous-système Symmetrix comporte plus de
16 384 périphériques adressables par l’hôte, il doit être fractionné de
telle sorte qu’un sous-ensemble de ports FICON adresse un
sous-ensemble de périphériques hôtes définis. Dans la baie
Symmetrix, chaque fractionnement présente à l’hôte mainframe un
numéro de série d’unité de contrôle unique. L’architecture Symmetrix
autorise un maximum de 16 fractionnements.
Même si la prise en charge de la configuration actuelle permet aux
utilisateurs de connecter de nombreux LPAR, acceptant 8 192 chemins
logiques par port FICON, elle comporte néanmoins une contrainte
relative au nombre de LCU par port et oblige à fractionner les
sous-systèmes Symmetrix comportant plus de 16 000 périphériques.
Les utilisateurs d’EMC Compatible Native Flash peuvent en pâtir,
puisque FlashCopy est pris en charge au sein d’une seule unité de
contrôle. Or, l’hôte identifie les fractionnements comme des unités de
contrôle distinctes. Par conséquent, FlashCopy ne peut pas être utilisé
entre les périphériques d’une même unité de contrôle physique s’ils
sont présents dans différents fractionnements.
En outre, cela diminue la flexibilité de gestion de la configuration, car
les modifications doivent tenir compte du fractionnement de la
configuration Symmetrix et ne peuvent pas être effectuées uniquement
au niveau de l’hôte.
À partir d’Enginuity 5876, il est possible de définir une option de
configuration dans le sous-système Symmetrix pour autoriser jusqu’à
255 LCU par fractionnement. Un seul fractionnement peut ainsi
accepter jusqu’à 64 000 périphériques adressables. Toutefois, la
configuration maximale reste inchangée, avec 16 fractionnements et
255 LCU par trame.
44
Matériel mainframe
Cet accroissement du nombre de périphériques adressables réduit à
la fois la nécessité de fractionner le sous-système Symmetrix et la
probabilité de conflit FlashCopy entre les fractionnements. Il accroît
par ailleurs la flexibilité, puisque la plupart des modifications
apportées à la configuration concernent la définition de l’hôte.
Les LCU définies par port pouvant être plus nombreuses, il est possible
de diminuer le nombre de chemins logiques et le nombre de LPAR
pris en charge par port en fonction de leur quantité. La règle ci-dessous
limite le nombre total maximal de chemins logiques à 2 048 :
Nb unités de contrôle x Nb LPAR = 2 048 chemins logiques constants
Le nombre maximal de LPAR par port rattaché pris en charge est
ainsi basé sur le nombre de LCU, comme illustré dans le Tableau 5.
Tableau 5
Nb maximal de LPAR pris en charge par port rattaché
Nb de LCU avec
chemins actifs par
port
Nb maximal de
périphériques pris en
charge par port
Nb maximal de LPAR par
port dans les baies VMAX
16
4 000
128
32
8 000
128
64
16 000
128
128
32 000
16
255
64 000
8
Gestion électronique des licences
La gestion électronique des licences repose sur la table de gestion des
licences des fonctions Symmetrix introduite avec Enginuity 5874. Le
rôle de cette table est d’indiquer chaque licence activée et de suivre le
nombre d’autorisations. Actuellement, l’interface KFI (Key Feature
Interface) est invoquée pour vérifier l’état d’activation de la fonction
et enregistrer le nombre d’autorisations. Cependant, les demandes
d’utilisation de fonctions désactivées ne sont pas rejetées.
45
Matériel mainframe
Avec Enginuity 5875 et ultérieur (et Mainframe Enablers V7.2 et
ultérieur), les fonctions désactivées sont rejetées et l’accès à la
fonction est basé sur les autorisations spécifiées dans le fichier
d’activation sur la baie Symmetrix ou dans les paramètres SCF.
Toutes les informations pertinentes sont stockées dans la table de
gestion des licences des fonctions Symmetrix mentionnée
précédemment. EzSM affiche les rapports d'utilisation générés
quotidiennement ou à la demande sur la baie Symmetrix. La Figure 9,
page 46 présente des exemples de fonctions et leurs propriétés ELM
pertinentes.
ICO-IMG-000961
Figure 9
Écran de gestion électronique des licences
Les systèmes DMX sont toujours fournis avec des clés d’hôte. À partir
d’Enginuity 5875, les habilitations remplacent les clés d’hôte
spécifiques. Par ailleurs, les nouvelles versions de SE, MFE, TPF
ignorent la plupart des clés d’hôte. Ces informations sont précisées
dans les spécifications SRS et SE. Certaines clés d’hôte spécialisées
ont toutefois été conservées, comme la clé de mappage des
périphériques non protégés.
46
Matériel mainframe
Lors de l’installation des licences avec eLicensing, obtenez les fichiers
de licence auprès du support en ligne EMC, copiez-les vers un hôte
Unisphere®, Solutions Enabler ou Symmetrix Management Console
(SMC) et transférez-les aux sous-systèmes Symmetrix. Chaque fichier
de licence définit intégralement toutes les autorisations pour un
système spécifique, y compris le type de licence (permanente ou
d’évaluation), la capacité sous licence et la date de création de la
licence. Si vous souhaitez ajouter un titre de produit ou accroître la
capacité sous licence d’une autorisation, vous devez obtenir une
nouvelle licence auprès du support en ligne EMC et la transférer au
sous-système Symmetrix.
Remarque : Si aucun hôte de système ouvert n’est rattaché au sous-système
Symmetrix, contactez votre spécialiste du support technique EMC pour
l’installation et l’activation de la licence.
Reporting d’erreurs à l’hôte mainframe
Symmetrix Enginuity Operating Environment détecte les types
d’erreur ci-dessous dans les systèmes de stockage Symmetrix :
◆
Vérification des données : Enginuity a détecté une erreur dans le
profil binaire lu à partir du disque. Les vérifications de données
sont associées à des problèmes matériels découlant de l’écriture
ou de la lecture de données, à des supports défectueux ou à des
événements aléatoires.
◆
Vérification du système ou du programme : Enginuity a rejeté la
commande. Ce type d’erreur est indiqué au processeur et
toujours retourné au programme à l’origine de la requête.
◆
Surcharge : Enginuity ne peut pas recevoir les données au débit
auquel elles sont transmises à partir de l’hôte. Cette erreur
indique un problème de temps. Le redémarrage de l’opération
d’E/S permet généralement de résoudre ce problème.
◆
Vérification de l’équipement : Enginuity a détecté une erreur
lors du fonctionnement du matériel.
47
Matériel mainframe
◆
Environnement : un test interne d’Enginuity a détecté une erreur
liée à l’environnement. Les tests internes relatifs à l’environnement
permettent de surveiller le système et de signaler les pannes liées
aux composants logiciels critiques. Ces tests se déroulent au
moment de la mise sous tension initiale du système, après chaque
événement de réinitialisation logicielle et au moins toutes les
24 heures pendant un fonctionnement normal.
Si un test sur l’environnement détecte une erreur, il génère un
indicateur pour la signaler et présente un état de vérification de
l’unité à l’hôte au cours de l’opération d’E/S suivante. Le test
ayant permis de détecter l’erreur est alors programmé pour une
exécution plus fréquente. Si un problème est détecté au niveau
d’un périphérique, il est signalé sur tous les chemins logiques
menant à ce périphérique. Les défaillances suivantes de ce
périphérique ne sont pas signalées tant que le problème en cours
n’est pas résolu.
Si une deuxième défaillance est détectée sur un périphérique déjà
associé à une erreur, Enginuity signale l’erreur existante sur
l’opération d’E/S suivante, avant d’indiquer la deuxième erreur.
Enginuity signale les erreurs à l’hôte et au Centre de support clients
d’EMC. Lors du signalement à l’hôte, Enginuity présente un état de
vérification de l’unité dans l’octet d’état du canal chaque fois qu’il
détecte une erreur telle qu’une vérification de données, une
commande rejetée, une surcharge, une vérification d’équipement ou
une erreur d’environnement.
Lorsqu’il reçoit l’état de vérification de l’unité, l’hôte récupère les
données de détection du sous-système Symmetrix et, si une action de
consignation a été demandée, les place dans le Dataset
d’enregistrement des erreurs (Error Recording Data Set, ERDS). Le
programme EREP (Environment Recording, Editing, and Printing)
imprime les informations d’erreur. Les données de détection
identifient l’origine de l’erreur et indiquent le type d’erreur et sa
cause. Le format des données de détection dépend du système
d’exploitation du mainframe. Pour les émulations de
contrôleurs 2105, 2107 ou 3990, les données de détection sont
retournées au format SIM.
48
Matériel mainframe
Reporting de gravité SIM (Service Information Message)
Enginuity prend en charge le reporting de gravité SIM (Service
Information Message), qui vous permet de filtrer les alertes de gravité
SIM signalées à la console MVS. Les paramètres par défaut du
reporting de gravité SIM sont les suivants :
Tableau 6
◆
les alertes Acute, Serious et Moderate sont signalées par défaut à
la console MVS. Le Tableau 6 fournit les définitions des niveaux
de gravité SIM.
◆
Toutes les alertes de gravité SIM sont signalées par défaut au
programme EREP.
Niveaux de gravité des alertes SIM
Gravité
Description
SERVICE
Aucune dégradation des performances du système ou de l’application n’est
attendue. Aucune panne du système ou de l’application ne s’est produite.
MODERATE
Une dégradation des performances est possible dans un environnement
très chargé. Aucune panne du système ou de l’application ne s’est
produite.
SERIOUS
Une ressource principale du sous-système d’E/S est désactivée. Une
dégradation importante des performances est possible. Une panne du
système ou de l’application s’est peut-être produite.
ACUTE
Une ressource essentielle du sous-système d’E/S est désactivée ou le
produit est peut-être endommagé. Les performances peuvent être
gravement dégradées. Une panne du système ou de l’application s’est
peut-être produite.
REMOTE
SERVICE
Le Centre de support clients d’EMC est en train d’effectuer des opérations
de service/maintenance sur le système.
REMOTE FAILED
Le processeur de service ne peut pas communiquer avec le Centre de
support clients d’EMC.
49
Matériel mainframe
Les versions 5874 et 5875 d’Enginuity signalent les erreurs
d’environnement présentées dans le Tableau 7, page 50 en utilisant le
format SIM.
Tableau 7
Code
hexadécimal
(5874, 5875)
Description
MODERATE
Envoie une alerte SIM pour le code d’erreur 052F
(une erreur d’écriture SRDF sync s’est produite).
Remarque : Epack requis pour la version 5874
uniquement : correctif 58335 et correctif
20011029.
E42F
MODERATE
Un groupe de cohérence SRDF a été interrompu.
E43E
042F
043E
Remarque : Le niveau
de gravité peut être
modifié via SymmWin.
SERVICE
E454
SRDF est passé au mode en attente d’écriture
Copie évolutive en raison de nombreuses
chaînes d’interruption ou d’arrêt.
Cette erreur survient dans les configurations
SRDF lorsque Enginuity détecte des E/S de
pagination de mémoire de mainframe vers les
appareils SRDF. Elle déclenche un appel à
distance vers le Centre de support clients d’EMC.
SERVICE
Le M2 est resynchronisé avec le périphérique
M1. Cet événement se produit lorsque le
périphérique M2 retrouve l’état Ready (Prêt).
PRÉCONISATION : laisser désactivé
E461
SERVICE
E462
SERIOUS
L’un des directeurs back-end est défaillant avec
l’état IMPL Monitor.
2463
SERVICE
Le processus de resynchronisation des
périphériques a commencé.
E465
0454
0461
0462
0463
0465
50
Code de référence
SIM
Niveau de gravité
Matériel mainframe
Tableau 7
Code
hexadécimal
0467
(5874, 5875) (suite)
Description
MODERATE
Le sous-système Symmetrix distant a signalé
une erreur SRDF sur les liaisons SRDF.
E467
SERVICE
L’utilitaire de suivi des événements est exécuté
depuis plus de 30 jours.
E46B
MODERATE
Un groupe SRDF est perdu. Cet événement
survient, par exemple, lorsque toutes les liaisons
SRDF sont défaillantes.
E46D
Un groupe SRDF est actif et opérationnel.
E46E
SERIOUS
Le périphérique DSE, DATA ou SAVE est trop
petit ou la session est trop longue.
2471
SERIOUS
Un test d’environnement périodique (env_test9)
a détecté que le périphérique en miroir présente
l’état Not Ready (Non prêt).
E473
l’état Write Disabled (WD, Écriture désactivée).
E474
046B
046D
SERVICE
046E
0471
0473
SERIOUS
0474
Code de référence
SIM
Niveau de gravité
51
Matériel mainframe
Tableau 7
Code
hexadécimal
0475
0476
(5874, 5875) (suite)
Description
SERIOUS
Un miroir distant R1 SRDF présente l’état Not
Ready (Non prêt).
E475
SERVICE
Le processeur de service a été réinitialisé.
2476
REMOTE FAILED
Le processeur de service n’a pas pu appeler le
Centre de support clients d’EMC (échec de la
fonction d’appel à distance) en raison de
problèmes de communication.
1477
MODERATE
Vérifier si le verrouillage de programmation
FLASH est maintenu.
2478
ACUTE
Un périphérique SAVE comportant des données
utilisateur présente l’état Not Ready (Non prêt).
247C
MODERATE
Le groupe SRDF a perdu une liaison SRDF ou le
groupe SRDF est perdu localement.
E47D
Une liaison SRDF a été restaurée. La liaison
SRDF est opérationnelle.
E47E
REMOTE SERVICE
Le processeur de service est parvenu à appeler
le Centre de support clients d’EMC (appel à
distance) pour signaler une erreur.
147F
SERVICE
L’espace disque disponible sur le processeur de
service est faible.
2492
Remarque : Le
niveau de gravité
peut être modifié via
SymmWin.
0477
0478
047C
047D
Remarque : Le
niveau de gravité
SymmWin.
SERVICE
047E
Remarque : Le
niveau de gravité
SymmWin.
047F
0492
52
Code de référence
SIM
Niveau de gravité
Matériel mainframe
Tableau 7
Code
hexadécimal
(5874, 5875) (suite)
Code de référence
SIM
Niveau de gravité
Description
ACUTE
Problème lié à l’alimentation du moteur VMAX ou
au module d’alimentation de secours du moteur
VMAX.
24BA
MODERATE
Une session SRDF/A a été interrompue en
raison d’une demande ne provenant pas d’un
utilisateur.
Les raisons possibles sont les erreurs fatales, la
perte de liaisons SRDF ou la fin d’un délai de
réponse d’hôte SRDF/A.
E4CA
REMOTE SERVICE
Connexion distante établie ou commande à
distance connectée.
14D1
REMOTE SERVICE
Connexion distante établie.
Commande à distance connectée.
14D1
REMOTE SERVICE
Connexion distante fermée. Commande à
distance rejetée.
14D2
SERVICE
Problèmes de filtres flex.
24D3
REMOTE SERVICE
Connexion distante fermée.
Commande à distance déconnectée.
14D4
04DA
SERVICE
Problèmes liés à une tâche ou des threads.
24DA
04DB
SERVICE
Le script SYMPL a généré une erreur.
24DB
04DC
SERVICE
Problèmes liés au processeur de service.
24DC
04E0
REMOTE FAILED
Problèmes de communications.
14E0
04E1
SERVICE
Problèmes liés au rappel des erreurs.
24E1
04F9
MODERATE
Un groupe de cohérence SRDF a été interrompu. E4F9
01BA
02BA
03BA
04BA
04CA
Remarque : Le
niveau de gravité
SymmWin.
04D1
04D1
04D2
04D3
04D4
Le Tableau 8, page 54 répertorie les erreurs d’environnement
d’Enginuity 5876 ou ultérieur au format SIM.
Remarque : Tous les niveaux de gravité indiqués peuvent être modifiés via
SymmWin.
53
Matériel mainframe
Enginuity 5876 signale les erreurs d’environnement présentées dans
le Tableau 7, page 50 en utilisant le format SIM.
Tableau 8
messages SIM (5876)
Code
hexadécimal Niveau de gravité
54
Description
Code de référence
SIM
042F
NONE
Envoie une alerte SIM pour le code d’erreur 052F
(une erreur d’écriture SRDF sync s’est produite).
PRÉCONISATION : aucune
E42F
043E
MODERATE
E43E
0454
SERVICE
SRDF est passé au mode en attente d’écriture
Copie évolutive en raison de nombreuses
chaînes d’interruption ou d’arrêt.
Cette erreur survient dans les configurations
SRDF lorsque Enginuity détecte des E/S de
pagination de mémoire de mainframe vers les
appareils SRDF. Elle déclenche un appel à
distance vers le Centre de support clients d’EMC.
E454
0461
NONE
E461
0462
NONE
E462
0463
SERIOUS
L’un des directeurs back-end est défaillant avec
l’état IMPL Monitor.
2463
0465
NONE
Le processus de resynchronisation des
périphériques a commencé.
E465
0467
MODERATE
Le sous-système Symmetrix distant a signalé
une erreur SRDF sur les liaisons SRDF.
E467
046B
SERVICE
L’utilitaire de suivi des événements est exécuté
depuis plus de 30 jours.
E46B
046D
MODERATE
Un groupe SRDF est perdu. Cet événement
survient, par exemple, lorsque toutes les liaisons
SRDF sont défaillantes.
E46D
Matériel mainframe
Tableau 8
messages SIM (5876) (suite)
Code
Code de référence
SIM
Description
046E
SERVICE
Un groupe SRDF est actif et opérationnel.
E46E
0470
ACUTE
Condition OverTemp basée sur la température
du module DIMM.
2470
0471
SERIOUS
Le périphérique DSE, DATA ou SAVE est trop
petit ou la session est trop longue.
2471
Remarque : Le
niveau de gravité
passe de SERIOUS
à ACUTE à 98 % de
la capacité.
0473
SERIOUS
l’état Not Ready (Non prêt).
E473
0474
SERIOUS
l’état Write Disabled (WD, Écriture désactivée).
E474
0475
SERIOUS
Un miroir distant R1 SRDF présente l’état Not
Ready (Non prêt).
E475
0476
SERVICE
Le processeur de service a été réinitialisé.
2476
0477
REMOTE FAILED
Le processeur de service n’a pas pu appeler le
Centre de support clients d’EMC (échec de la
fonction d’appel à distance) en raison de
problèmes de communication.
1477
047A
ACUTE
Alimentation CA perdue dans la zone
d’alimentation A ou B.
247A
01BA
02BA
03BA
04BA
ACUTE
Problème lié à l’alimentation du moteur VMAX ou
au module d’alimentation de secours du moteur
VMAX.
24BA
047C
ACUTE
Un périphérique SAVE comportant des données
utilisateur présente l’état Not Ready (Non prêt).
247C
047D
MODERATE
Le groupe SRDF a perdu une liaison SRDF ou le
groupe SRDF est perdu localement.
E47D
55
Matériel mainframe
Tableau 8
messages SIM (5876) (suite)
Code
Description
Code de référence
SIM
047E
SERVICE
Une liaison SRDF a été restaurée. La liaison
SRDF est opérationnelle.
E47E
047F
REMOTE SERVICE
Le processeur de service est parvenu à appeler
le Centre de support clients d’EMC (appel à
distance) pour signaler une erreur.
147F
0492
SERVICE
L’espace disque disponible sur le processeur de
service est faible.
2492
04CA
MODERATE
Une session SRDF/A a été interrompue en
raison d’une demande ne provenant pas d’un
utilisateur.
Les raisons possibles sont les erreurs fatales, la
perte de liaisons SRDF ou la fin d’un délai de
réponse d’hôte SRDF/A.
E4CA
04D1
REMOTE SERVICE
Connexion distante établie.
Commande à distance connectée.
14D1
04D2
REMOTE SERVICE
Connexion à distance fermée. Commande à
distance rejetée.
14D2
04D3
SERVICE
Problèmes de filtres flex.
24D3
04D4
REMOTE SERVICE
Connexion à distance fermée.
Commande à distance déconnectée.
14D4
04DA
SERVICE
Problèmes liés à une tâche ou des threads.
24DA
04DB
SERVICE
Le script SYMPL a généré une erreur.
24DB
04DC
SERVICE
Problèmes liés au processeur de service.
24DC
04E0
REMOTE FAILED
Problèmes de communications.
14E0
04E1
SERVICE
Problèmes liés au rappel des erreurs.
24E1
04F9
MODERATE
E4F9
Messages opérateur
Dans z/OS, les messages SIM sont affichés en tant que messages
d’erreur de type alerte de service IEA480E. Leur format est représenté
à la Figure 10, page 57 et à la Figure 11, page 57.
56
Matériel mainframe
*IEA480E 1903,SCU,ACUTE ALERT,MT=2105,SER=0507-00025,
REFCODE=247A-0000-0000
247A = AC line failure or interruption
Figure 10
SYM-001083
Format des messages d’erreur de type alerte de service IEA480E dans
z/OS (coupure d’alimentation CA)
*IEA480E 1900,DASD,SERIOUS ALERT,MT=2105,SER=0507-00025,
REFCODE=E473-0000-7B01,VOLSER=LSJ13B,ID=01
Channel address = 7B
Number of errors = 01
Note: E473 = Mirror-1 volume in “Not Ready” state
Channel address of the “Not Ready” device
Figure 11
SYM-001084
z/OS (volume miroir-1 à l’état Not Ready )
Remarque : Tous les chemins de canal hôte vers ce périphérique (volume
cible) signalent ce message d’erreur. Par conséquent, ce message peut
apparaître plusieurs fois.
Le sous-système Symmetrix signale également les événements à
l’hôte et au processeur de service. Ces événements sont les suivants :
◆
Le volume miroir-2 est synchronisé avec le volume source.
◆
Le volume miroir-1 est synchronisé avec le volume cible.
◆
Le processus de resynchronisation a commencé.
Dans z/OS, ces événements sont affichés sous la forme de messages
d’erreur de type alerte de service IEA480E. Leur format est représenté
à la Figure 12, page 58 et à la Figure 13, page 58.
57
Matériel mainframe
*IEA480E 0D03,SCU,SERVICE ALERT,MT=3990-3,SER=,
REFCODE=E461-0000-6200
Channel address of the synchronized device
E461 = Mirror-2 volume resynchronized with Mirror-1 volume
Figure 12
z/OS (resynchronisation du volume miroir-2)
*IEA480E 0D03,SCU,SERVICE ALERT,MT=3990-3,SER=,
REFCODE=E462-0000-6200
Channel address of the synchronized device
E462 = Mirror-1 volume resynchronized with Mirror-2 volume
Figure 13
58
z/OS (resynchronisation du volume miroir-1)
Matériel mainframe
Fonctions mainframe prises en charge
Le Tableau 9 liste les fonctions mainframe prises en charge par les
sous-systèmes EMC Symmetrix VMAX. Il fournit également des
remarques sur la configuration de chaque fonction. Les fonctions qui
sont également présentées dans d’autres chapitres ou sections sont
signalées.
Tableau 9
EMC Symmetrix VMAX
Fonction prise en charge
Description de la fonction
Remarques sur la configuration
Dynamic Channel
Management (DCM)
La fonction DCM (gestion dynamique des
canaux) du directeur Intelligent Resource
intégré dans les processeurs des systèmes
mainframe IBM zSeries permet la
reconfiguration dynamique des canaux entre
les unités de contrôle sur instruction du
composant Workload Manager de z/OS.
La prise en charge de la fonction DCM requiert
l’installation du module IOSTEMC. IOSTEMC
est une table de modèles d’unités de contrôle
dédiée aux systèmes EMC Symmetrix. Elle
assure la compatibilité avec la fonction IBM
Dynamic Channel Management. Cette table
non exécutable doit être placée dans
SYS1.LINKLIB ou un autre Dataset Linklist. Elle
est disponible sur le site FTP EMC suivant :
ftp://ftp.EMC.com/pub/MVSsoft/DCM-IOSTEMC
Concurrent Copy
La fonction Concurrent Copy d’IBM réduit la
période d’indisponibilité des données du
sous-système de stockage durant les
opérations de sauvegarde.
• Symmetrix Differential Data Facility (SDDF)
doit être activé.
Compatible Native Flash
La fonction Compatible Native Flash for
Mainframe assure la prise en charge d’IBM
FlashCopy afin de satisfaire les exigences
de réplication spécifiques d’IBM. Elle active
également les copies de données de
volumes complets à un point dans le temps,
et rend immédiatement ces copies
disponibles pour l’accès en lecture ou en
écriture. Ces copies peuvent être utilisées
avec les outils de sauvegarde standard.
• La fonction de prise en charge de
FlashCopy fait l’objet d’une licence distincte.
Elle est facturée en fonction de la capacité
du sous-système.
• Pour obtenir des informations spécifiques
concernant les tarifs de cette fonction,
contactez un responsable de compte EMC.
59
Matériel mainframe
Tableau 9
EMC Symmetrix VMAX (suite)
Multi-Path Lock
Facility/Concurrent Access
(MPLF/CA)
La fonction Multi-Path Lock Facility
Concurrent Access (MPLF/CA) autorise les
requêtes d’E/S simultanées multiples vers
une même unité logique à partir de plusieurs
mainframes TPF.
Le sous-système Symmetrix gère les noms
et les statuts des verrouillages logiques en
cours d’utilisation et répond aux requêtes
visant à obtenir ou à libérer un verrouillage.
Ainsi, plusieurs hôtes peuvent partager
DASD via plusieurs chemins dans un
environnement OLTP (OnLine Transaction
Processing) actif tout en préservant
l’intégrité des données.
MPLF/CA améliore et remplace la fonction
ELLF (Extended Limited Lock Facility) et la
fonction LLF (Limited Lock Facility).
• Les sous-systèmes Symmetrix doivent
émuler le contrôle de stockage 2107.
• La version d’Enginuity doit prendre en
charge la fonction MPLF/CA.
MultiSubsystem Imaging
Les sous-systèmes Symmetrix prennent en
charge plusieurs environnements z/OS en
fournissant une connectivité maximale grâce
à l’utilisation des modes d’émulation 2107 et
de la fonction d’extension d’hypervolume.
charge jusqu’à 250 identifiants de
sous-système (SSID, SubSystem IDentifier),
avec un maximum de 256 périphériques par
SSID.
Sequential Data Striping
Répartition séquentielle des données. Cette
fonction accélère l’exécution par lot sur les
requêtes de traitement séquentiel des E/S
volumineuses en autorisant la gestion
parallèle des opérations d’E/S sur pas moins
de 16 périphériques.
Remarque : Pour obtenir des informations
spécifiques concernant la prise en charge de la
fonction MPLF/CA par votre sous-système
Symmetrix, contactez un responsable de
compte EMC.
• La répartition séquentielle des données est
disponible uniquement dans z/OS avec les
environnements DFSMS.
• Tous les niveaux d’Enginuity pris en charge
sur une baie VMAX prennent en charge
cette fonction.
• Les volumes gérés par SMS doivent résider
sur le sous-système Symmetrix.
fonction de répartition séquentielle des données
par votre sous-système Symmetrix, contactez
un responsable de compte EMC.
60
Matériel mainframe
Tableau 9
Partitioned Dataset Assist
(PDS)
La fonction Partitioned Dataset Assist (PDS)
améliore les performances sur les Datasets
partitionnés volumineux utilisés de façon
intensive en modifiant le processus de
recherche d’annuaire. PDS Assist est
automatiquement invoqué avec le niveau
approprié de DFSMS et la version
d’Enginuity prenant en charge cette fonction.
charge la fonction Partitioned Dataset (PDS)
Search Assist d’IBM pour le contrôle de
stockage z/OS et 2107 avec plate-forme
étendue.
Multiple Allegiance (MA)
Multiple Allegiance (MA) est une fonction de
z/OS qui améliore le débit à travers un
environnement de stockage partagé. MA
permet à différents hôtes d’accéder
simultanément au même périphérique
(d’avoir des allégeances simultanées
implicites), dans la mesure où les E/S
correspondant à ces accès n’entrent pas en
conflit les unes avec les autres à aucun
niveau.
• Les sous-systèmes Symmetrix prennent en
charge MA en tant qu’unité de contrôle 2107
si la fonction COM-PAV est activée sur le
système Symmetrix.
Parallel Access Volumes
Parallel Access Volumes est une fonction
IBM qui améliore le temps de réponse en
réduisant les conflits d’accès au
périphérique, accroissant ainsi les
performances et le débit. Ce point est
abordé plus en détail dans le Chapitre 9 Considérations relatives aux performances.
• Pour activer la fonction Parallel Access
Volumes, une licence EMC COM-PAV/MA
est requise.
• Les sous-systèmes Symmetrix doivent être
définis sur l’hôte en tant qu’unité de
contrôle 2107.
HyperPAV
Compatible HyperPAV améliore
considérablement la fonction Parallel Access
Volumes (PAV) en optimisant les
performances et les réponses aux pics de
charge de travail par rapport à la fonction
PAV d’origine, tout en utilisant moins de
ressources z/OS. Ce point est abordé plus
en détail dans le Chapitre 10,
« Considérations relatives aux
performances ».
• La prise en charge de la fonction HyperPAV
fait l’objet d’une licence distincte.
• COM-PAV/MA, qui permet la prise en charge
des fonctions PAV d’IBM, est indispensable
pour Compatible HyperPAV.
• HyperPAV est fortement recommandé dans
tous les principaux environnements z/OS.
• Pour obtenir des informations spécifiques
concernant les tarifs de cette fonction,
61
Matériel mainframe
Tableau 9
Dynamic Parallel Access
Volumes/Multiple Allegiance
(PAV/MA)
Parallel Access Volumes/Multiple Allegiance
(PAV/MA) est une fonction exclusive des
systèmes mainframe. Elle remédie à la
limitation de z/OS qui n’autorise qu’une
seule opération d’E/S en attente vers un
périphérique. La fonction COM-PAV/MA
d’EMC améliore considérablement les
performances des sous-systèmes
Symmetrix lorsque les files d’attente pour
l’accès aux périphériques sont très longues
(délai IOSQ élevé).
Enginuity ajoute la prise en charge
dynamique à l’implémentation PAV d’EMC.
Ainsi, la fonction Workload Manager de MVS
(en mode Goal) ou l’utilitaire de gestion PAV
d’EMC peut réattribuer à la volée des UCB
alias à un UCB base. En outre,
COM-PAV/MA autorise désormais
l’association d’un maximum de 127 alias à
un périphérique de base, améliorant
l’opportunité d’opérations d’E/S parallèles.
Enginuity prend également en charge l’ajout
et la suppression en ligne des fonctions base
et alias de PAV pour les canaux FICON.
COM-PAV/MA fait l’objet d’une licence distincte.
Peer-to-Peer Remote Copy
(PPRC)
Peer-to-Peer Remote Copy (PPRC) est la
solution de copie à distance disponible avec
les systèmes de stockage IBM. Les
sous-systèmes Symmetrix prennent en
charge les commandes IBM MetroMirror
PPRC (Peer-to-Peer Remote Copy) natives
via une fonction appelée Compatible Peer.
Enginuity prend en charge la fonctionnalité
CGROUP FREEZE/RUN d’architecture de
niveau 2 de PPRC version 1.
La prise en charge de la fonction Hyper-Swap
d’architecture de niveau 3 et 4 de PPRC
version 1 a été ajoutée dans Enginuity 5771,
notamment la fonctionnalité de basculement sur
incident/retour arrière. Ainsi, les sous-systèmes
Symmetrix prennent en charge ces fonctions
dans la solution GDPS (Geographically
Dispersed Parallel Sysplex) d’IBM. Compatible
Peer est disponible sur les sous-systèmes
Symmetrix avec des connexions aux hôtes
FICON.
fonction Compatible Peer par votre
sous-système Symmetrix, contactez un
responsable de compte EMC.
62
Matériel mainframe
Tableau 9
Extended Address Volumes
(EAV)
Les EAV sont de grands volumes dont la
capacité peut atteindre 223 Go (262 668
cylindres). Ils sont configurés en tant que
3390 Model A. Les EAV simplifient la gestion
du stockage dans l’environnement z/OS en
consolidant les petits volumes sur de grands
volumes moins nombreux. Les EAV sont
traités plus en détail dans le Chapitre 10,
performances ».
Requiert z/OS 1.10 ou ultérieur.
Baies Symmetrix VMAX exécutant
Enginuity 5874 ou ultérieur.
Configuration des volumes
CKD
Enginuity prend en charge le mappage et
l’annulation du mappage des volumes CKD.
Cette fonction est nécessaire, car la
suppression de capacité des systèmes
mainframe est impossible lorsque le
mappage des volumes ne peut pas être
annulé à partir d’un port front-end.
z/OS Global Mirror
z/OS Global Mirror (anciennement XRC) est
une solution de reprise après sinistre et de
migration de la charge de travail basée sur
l’hôte qui assure la copie asynchrone des
données des systèmes zSeries vers un
datacenter distant.
Modified Indirect Data
Address Word (MIDAW)
La fonction MIDAW a été introduite dans le
processeur IBM z9 pour améliorer les
performances FICON en fournissant une
nouvelle méthode d’adressage des
emplacements de stockage non contigus
durant les opérations de lecture et d’écriture.
Les performances du canal FICON sont
accrues en raison de la diminution du
nombre de trames et de séquences qui le
traversent. La fonction MIDAW est traitée
plus en détail dans le Chapitre 10,
performances ».
Enginuity prend en charge la fonctionnalité
XRC de niveau 3 d’IBM.
Remarque : Enginuity 5772 et ultérieur prend
en charge la fonctionnalité Global Mirror de
z/OS. Pour obtenir des informations spécifiques
concernant la prise en charge de la fonction
XRC par votre sous-système Symmetrix,
• IBM System z9 ou ultérieur et IBM z/OS 1.7
(ou APAR OA10984 avec version 1.6) ou
ultérieur.
• Contrôleurs Symmetrix DMX-4 ou VMAX
avec niveaux d’Enginuity actuellement pris
en charge.
63
Matériel mainframe
Tableau 9
64
High Performance FICON
(z HPF)
Compatible zHPF est une extension de
l’architecture FICON. Elle est conçue pour
améliorer l’exécution des requêtes d’E/S de
petit bloc. zHPF rationalise l’architecture
FICON et réduit le temps système sur les
processeurs du canal, les ports des unités
de contrôle, les ports des switches et les
liaisons, en améliorant la manière dont les
programmes du canal sont écrits et traités.
zHPF est traité plus en détail dans le
Chapitre 10, « Considérations relatives aux
performances ».
zHPF est disponible avec la version de service
du 4e trimestre d’Enginuity 5874 et ultérieur.
Multitrack High Performance
FICON (zHPF multitrack)
Multitrack High Performance FICON
améliore considérablement les
performances FICON. Cette fonction est
destinée aux environnements FICON
générant un trafic élevé, qui combinent
intelligemment différentes méthodes d’accès.
Elle n’est qu’une simple extension de la
version déjà disponible de High Performance
FICON (zHPF). zHPF multitrack étend le
nombre de pistes à traiter par E/S zHPF de
un à 255. zHPF multitrack est traité plus en
détail dans le Chapitre 10, « Considérations
relatives aux performances ».
zHPF multitrack est disponible avec
Enginuity 5875 ou ultérieur.
Persistent IU Pacing
(Extended Distance FICON)
Persistent IU Pacing modifie les
spécifications FICON (FC-SB-3) et décrit
une méthode autorisant le canal FICON à
conserver un même débit utilisable au début
de l’exécution du programme du canal. Le
canal peut alors envoyer un plus grand
nombre d’IU vers l’unité de contrôle, ce qui
améliore les performances des longs
programmes d’E/S aux vitesses de liaison
plus élevées sur de longues distances et
élimine le délai d’attente de réponse à la
première commande. Persistent IU Pacing
est traité plus en détail dans le Chapitre 10,
performances ».
Persistent IU Pacing est disponible avec la
version de service du 4e trimestre
d’Enginuity 5874 ou ultérieur, et requiert donc
une configuration VMAX.
Cette fonction est exclusivement prise en
charge par l’hôte sur les processeurs des
systèmes z196 et sur les processeurs des
systèmes IBM z10 exécutant Driver 73 avec
MCL F85898.003 ou Driver 76 MCL
N10948.001. Extended Distance FICON est
utilisé de manière transparente par le système
d’exploitation z/OS et s’applique à toutes les
fonctionnalités FICON Express2 et
FICON Express4 transportant du trafic FICON
natif (CHPID type FC).
Matériel mainframe
Tableau 9
Multiple Subchannel Sets
(MSS)
MSS (Multiple Subchannel Sets, ensembles
de plusieurs sous-canaux) est une nouvelle
option de configuration disponible depuis le
processeur z9. Elle facilite la croissance des
périphériques, et donc l’augmentation de la
capacité et des E/S dans l’environnement
System z évolutif.
L’exploitation de MSS a commencé avec
z/OS V1R7 et aucune capacité de
restauration de
cette fonction n’est fournie. Le niveau le plus
bas de prise en charge IOCP est
ICP IOCP V1R3.
Avant le z9, il n’existait qu’un seul ensemble
de sous-canaux qui limitait les utilisateurs à
64 512 (63 000) adresses. Cela constituait
un véritable problème dans la plupart des
grandes installations concernées par la
prolifération du nombre de périphériques et
l’utilisation intensive de fonctions telles que
SRDF, Global Mirror, Metro Mirror,
GDPS-Hyperswap, Flashcopy, Timefinder et
Parallel Access Volumes (PAV).
Le z9 autorise 2 MSS, l’ensemble de
sous-canaux 0 et l’ensemble de
sous-canaux 1, fournissant chacun
64 000 sous-canaux. Le premier ensemble
de sous-canaux, l’ensemble 0, comporte
256 adresses réservées à l’usage d’IBM, les
autres étant à la disposition de l’utilisateur.
Le second ensemble de sous-canaux,
l’ensemble 1, met l’ensemble des
64 000 périphériques à la disposition de
l’utilisateur pour l’adressage.
Le z196 autorise 3 MSS.
Les restrictions actuelles de z/OS limitent
l’ensemble de sous-canaux 1 aux alias de
disques uniquement, tandis que l’ensemble
de sous-canaux 0 peut être utilisé pour les
adresses de base et d’alias. Le simple fait de
déplacer les périphériques alias vers le
second sous-ensemble de canaux autorise
une croissance considérable du nombre de
périphériques dans le premier ensemble de
sous-canaux. Cela permet d’ajouter ou de
supprimer simplement des alias et/ou des
périphériques à une configuration sans
réaligner les plages d’adresses.
Cette fonction requiert :
un processeur z9, z10 ou z196 ;
z/OS v1.7 ou supérieur ;
IOCP V1R3 ou ultérieur.
La fonction Multiple Subchannel Sets est prise
en charge sur les sous-systèmes Symmetrix
DMX-3 à partir du niveau de code
Enginuity 5773, DMX-4 et VMAX.
Une planification attentive est recommandée
pour l’utilisation correcte de cette fonction.
Si les adresses et les alias de périphérique sont
réalignés parmi les MSS, aucune modification
n’est requise dans le fichier BIN Symmetrix car
le sous-système Symmetrix n’a pas besoin de
savoir de quel MSS provient le SSCH ; il se
contente de répondre.
Il est nécessaire de modifier HCD/IOCDS pour
mettre en œuvre les changements suivants :
• passer d’un seul ensemble de sous-canaux
à plusieurs ensembles de sous-canaux ;
• réaligner les bases et les alias de
l’ensemble 0 sur les bases uniquement dans
l’ensemble 0, et les alias dans l’ensemble 1.
De même, la migration vers l’ensemble de
sous-canaux 1 est prise en charge par le biais
d’une action de modification de groupe dans la
liste des périphériques d’E/S de l’HCD en
utilisant le nouveau code d’action m.
Lors de la modification des attributions d’alias
sur une LCU ou un ensemble de LCU, les LCU
modifiées doivent être mises hors ligne avant
d’être remises en ligne pour garantir
l’enregistrement correct des alias dans les
LPAR rattachés au moment de la définition du
pool d’alias. Ceci est particulièrement important
dans les environnements HyperPAV.
65
Matériel mainframe
Logiciels et solutions connexes
La plupart des fonctions du sous-système Symmetrix sont
compatibles avec les versions précédentes du matériel Symmetrix.
Cette capacité fait l’objet d’une documentation explicite
accompagnant chaque version d’Enginuity utilisée sur le matériel
Symmetrix concerné. Les fonctionnalités les plus récentes du dernier
code Enginuity peuvent parfois être récupérées dans les versions
antérieures d’Enginuity, permettant ainsi à d’anciens matériels
Symmetrix d’être technologiquement à jour. Cela est particulièrement
intéressant pour les clients qui souhaitent étendre la durée de vie
technologique de leurs anciens sous-systèmes. Un logiciel hôte peut
être requis pour certaines fonctions. Il existe des offres de services
professionnels pour aider les clients à réaliser des mises en œuvre
complexes sur le plan opérationnel, ou requérant une main-d’œuvre
particulièrement qualifiée. Chapitre 13, « Offres de services
professionnels pour les systèmes mainframe » apporte des
informations supplémentaires.
Conditions préalables
Certaines fonctions requièrent un niveau minimal de système
d’exploitation et de sous-système associé (JES2, JES3, etc.). Par
ailleurs, des dépendances fonctionnelles peuvent exister au niveau
du logiciel de l’hôte. Ces dépendances et les autres conditions
préalables font l’objet d’une documentation exhaustive dans
différentes notes techniques et autres publications similaires.
Octroi de licences
Pour la plupart de ces fonctions, les licences sont octroyées par
plate-forme Symmetrix. Leur tarif peut varier en fonction du niveau
des tiers MSU du processeur, ou en fonction de la capacité du
sous-système de stockage. Un code de fonction sous licence peut
également être requis.
66
Matériel mainframe
Remarque concernant le numéro de série alpha de VMAX
La prise en charge de l’unité de contrôle 2107 permet d’utiliser un
numéro de série entièrement alphabétique, entièrement numérique
ou combinant des caractères alphabétiques et numériques. Certaines
règles s’appliquent. La différence avec l’unité de contrôle 2105 est
importante, cette dernière autorisant uniquement un numéro de série
numérique.
Actuellement, le numéro de série Symmetrix comprend 12 chiffres
ASCII, les cinq chiffres à droite étant uniques. Cependant, avec la
prise en charge de l’unité de contrôle 2107 sur le sous-système
Symmetrix VMAX, le nouveau numéro de série converti est
entièrement composé de caractères alphabétiques précédés de zéros.
Sur un directeur FICON, la commande Symmwin Inline E7,CF affiche
le numéro de série d’origine et le numéro de série 2107 traduit. La
commande DEVSERV de z/OS et les autres commandes D M=DEV
affichent également le nouveau numéro de série. Cette configuration
est illustrée dans la Figure 14.
ICO-IMG-000959
Figure 14
Commande opérateur z/OS d’affichage du numéro de série alpha
Remarque concernant le numéro de série alpha de VMAX
67
Matériel mainframe
Affichage des numéros de série numériques et alpha de VMAX
Les clients qui exécutent SCF peuvent afficher les numéros de série
numériques et alpha à l’aide de la commande Device Display
Summary :
/F EMCSCF,DEV,DIS,SUM
Cette commande affiche un résultat similaire au suivant :
SCF0403I
SCF0403I
SCF0401I
SCF0341I
SCF0421I
SCF0428I
SCF0402I
SCF0419I
SCF0421I
SCF0428I
SCF0402I
SCF0356I
CONTROLLER 0001926-01715 DISCOVERED
CONTROLLER 0001926-01700 DISCOVERED
DEVICE LIST HAS BEEN PROCESSED
DEV DIS SUM
CNTRL NAME=
Emulating 2107 - 00000000AFTM.
SER# 0001926-01700, SSID 0103 HAS 10 DEVICES IN SPLIT 1
SSID 0104 HAS 10 DEVICES IN SPLIT 1
CNTRL NAME=
Emulating 2107 - 00000000AFVG.
SER# 0001926-01715, SSID 4002 HAS 24 DEVICES IN SPLIT 1
DEVICE DISPLAY SUMMARY COMMAND COMPLETED.
(BAFTM)
(BAFTM)
(BAFVG)
En remplaçant SUM par CNTRL(ssss) dans la même commande
Display, on obtient des informations supplémentaires :
SCF0341I
SCF0421I
SCF0428I
SCF0360I
SCF0345I
SCF4011I
SCF0361I
SCF0357I
SCF0359I
SCF0358I
SCF0358I
SCF0356I
68
DEV DIS CNTRL(1700)
CNTRL NAME=
Emulating 2107 - 00000000AFTM.
CONTROLLER 0001926-01700 HAS 2 SUBSYSTEMS AND IS AT MCLEVEL 5874.240
- 0103 0104
CONTROLLER 0001926-01700 is currently using CCUU B90B as its SCF gateke
Gate Keeper Devices B90B
CONTROLLER 0001926-01700 HAS 2 PATHS TO OTHER CONTROLLERS
MHOP RMT CNTRL
MC
63FF 000192601715 5874,240
C7FF 000192601715 5874,240
DEVICE DISPLAY CNTRL COMMAND COMPLETED.
Matériel mainframe
Matériel EMC Centera
Première solution de stockage dédié aux contenus fixes (CAS) au
monde, EMC Centera® garantit un accès en ligne simple et rapide
aux contenus, l’authenticité des données et une évolutivité jusqu’à
plusieurs pétaoctets. EMC Centera est une solution de stockage
simple, évolutive et sécurisée pour la rétention, la protection et la
destruction d’un large éventail de contenus fixes : radiographies,
archives vocales, documents électroniques, archives d’e-mails,
images numériques de chèques et projets CFAO.
EMC Centera repose sur une architecture RAIN (Redundant Array of
Independent Nodes) sans point unitaire de panne et déployée dans
une ou plusieurs armoires standard 19 pouces NEMA de six pieds.
L’architecture RAIN d’EMC Centera associée à un environnement
d’exploitation intelligent permet une évolution capacitaire allant de
plusieurs téraoctets (To) à plusieurs pétaoctets (Po) sans interruption,
l’autogestion, l’autoréparation et l’auto-reconfiguration. Elle garantit
également l’authenticité de tous les objets à contenu fixe.
Chaque armoire peut être configurée avec une capacité de stockage
brute de 16 à 128 To (de 7,7 à 61,6 To pour la mise en miroir ou de
26,4 à 105,7 To pour la protection par parité) sur la base d’une taille de
fichier moyenne de 250 Ko. Il est possible de lier les armoires entre
elles pour une évolutivité continue. La capacité est augmentée par
incréments de deux nœuds, configurés en tant que nœuds de
stockage ou d’accès. Chaque nœud de stockage offre une puissance
de traitement, une capacité de stockage brute de 4,0 To (jusqu’à
1,92 To pour la mise en miroir ou jusqu’à 3,3 To pour la protection de
parité), ainsi qu’une interconnexion avec tous les autres nœuds du
cluster via un réseau local (LAN) privé. Chaque nœud exécute sa
propre instance de l’environnement d’exploitation CentraStar®. Les
nœuds d’accès sont configurés par paires : chacun d’eux offre une
connexion Ethernet 1 Go/s. Les besoins de l’application en termes de
débit et de capacité déterminent la configuration la mieux
appropriée.
L’environnement d’exploitation logiciel utilisé par CentraStar est un
système d’adressage de contenu innovant qui simplifie la gestion du
contenu, garantit sa conservation en une instance unique et offre
l’évolutivité nécessaire pour passer de capacités mesurées en
téraoctets à des capacités en pétaoctets. Le système EMC Centera
assure ces différentes fonctions tout en réduisant de manière
considérable les coûts de gestion.
69
Matériel mainframe
Les performances exceptionnelles, l’intégration transparente et la
fiabilité d’EMC Centera en font la solution incontournable en matière
d’archivage d’entreprise en ligne pour tout type d’application ou de
données. EMC Centera diminue le coût total de possession du
stockage mainframe en réduisant les coûts de maintenance, de
personnel et de fonctionnement. La Figure 15 illustre l’utilisation
d’EMC Centera sur un mainframe.
Mainframe
Centera
Emulation
Gateway
ESCON
or
FICON
DFSMS-HSM
z/OS nativelyintegrated
applications
IP
OSA
MF-000002
Figure 15
Utilisation d’EMC Centera sur un mainframe
Avantages et exemples d’utilisation
Les contenus fixes sont de nature très différente, depuis les
documents confidentiels, juridiques et de référence, aux
radiographies, pièces jointes d’e-mails, images de chèques et
contenus de diffusion, en passant par les images satellites, entre
autres. Contrairement aux bases de données ou aux fichiers qui sont
sans cesse modifiés et mis à jour, la valeur d’un contenu fixe repose
sur la combinaison des attributs suivants : authenticité, vie prolongée
et accessibilité. Les architectures de stockage existantes ne sont pas
optimisées pour ces nouvelles exigences.
70
Matériel mainframe
Relégué autrefois dans les archives de stockage ou dans les armoires
de rangement de fichiers, le contenu fixe apparaît de plus en plus en
ligne, en réponse aux exigences réglementaires et de la numérisation
dans la quasi-totalité des secteurs d’activité, et au désir de valoriser
ce contenu sous forme de nouveaux services et flux de revenus. De
même que la croissance des applications, dans la CAO par exemple,
et l’explosion du Web ont conduit à l’émergence du NAS pour le
partage des fichiers, le besoin de gérer et d’accéder à d’importantes
quantités de contenus fixes a donné naissance à une nouvelle
catégorie de stockage en réseau : la technologie CAS, ou stockage
dédié aux contenus fixes.
La technologie CAS constitue une nouvelle approche inédite pour
gérer les informations, qui est parfaitement adaptée aux contraintes
des contenus fixes. L’adressage de contenu rend inutiles la maîtrise et
la gestion par les applications de l’emplacement physique des
informations sur les supports de stockage. En effet, les adresses sont
calculées à partir du contenu lui-même et font office de clés de retrait
uniques que les applications peuvent utiliser pour retrouver et
extraire les objets stockés. Non seulement ces clés de retrait
simplifient la gestion d’un très grand nombre d’objets, mais elles
constituent également une empreinte numérique du contenu, en
garantissant ainsi l’authenticité absolue.
Gestion simple : la technologie EMC Centera simplifie la
planification du système et la gestion de plusieurs centaines de
téraoctets de stockage dédié aux contenus fixes. En l’absence de types
RAID à choisir, de LUN à lier ou de systèmes de fichiers à créer, les
applications n’ont plus à gérer ni à pallier la complexité des
topologies de stockage traditionnelles.
Authentification du contenu : tout objet présenté au système est
stocké de façon à ne pas pouvoir être modifié et est automatiquement
authentifié en toute transparence pour l’application de l’utilisateur.
Cette caractéristique est particulièrement importante dans la mesure
où les organisations gouvernementales ou autres exigent de plus en
plus de surveillance.
Impossibilité d’effacer : les objets de données ne peuvent pas être
supprimés avant l’expiration de leur période de rétention.
71
Matériel mainframe
Réplication efficace : EMC Centera utilise une adresse unique
dérivée du contenu pour garantir qu’une seule copie du contenu est
stockée (plus un réplica pour la fiabilité), quel que soit le nombre de
fois où elle est utilisée. La quantité d’informations stockées est ainsi
considérablement réduite, ce qui est indispensable pour diminuer le
coût total de possession lié au stockage du contenu.
Évolutivité sans reconfiguration : l’architecture d’EMC Centera est
conçue pour être extrêmement évolutive (capacité pouvant évoluer
de plusieurs téraoctets à plusieurs pétaoctets de contenus).
Installation et mise à niveau aisées : les systèmes peuvent être
installés ou mis à niveau en une heure maximum.
Logiciels et solutions connexes
Aucun produit EMC supplémentaire n’est requis pour EMC Centera.
Pour l’utilisation du mainframe EMC Centera, deux méthodes
d’implémentation sont possibles :
◆
une API basée sur IP prenant en charge n’importe quelle version
de z/OS actuellement proposée par IBM ;
◆
une passerelle de périphérique virtuel mainframe fournissant la
flexibilité de connexion d’ESCON et/ou de FICON.
EMC Centera Mainframe HSM Migrator est exécuté sur DFSMShsm.
Octroi de licences
EMC Centera est un produit de stockage matériel. Aucun code de
fonction sous licence n’est requis pour le logiciel mainframe (API).
72
Matériel mainframe
Mainframe Data Library
Mainframe Data Library (MDL) est le nom de la famille de
contrôleurs de stockage sur bande virtuelle hautes performances qui
utilise les plates-formes de stockage EMC pour stocker et extraire des
données. Chaque modèle fournit une solution évolutive qui réduit les
risques et les coûts associés aux bandes mainframe, tout en
protégeant les investissements réalisés par le client dans les
applications sur bandes.
Les modèles MDL 1000 et 2000 doivent être rattachés aux canaux
FICON/ESCON du mainframe zSeries. Ils utilisent une connexion
Gigabit Ethernet IP/Fibre Channel standard pour le rattachement
aux baies de stockage.
Les modèles MDL 4000 et 6000 fournissent les mêmes fonctionnalités
et avantages que les modèles 1000 et 2000, tout en simplifiant
l’acquisition et le déploiement d’une solution sur bandes complète.
La conception se compose d’un rack 24U de 19 pouces dont la
configuration minimale/maximale comprend deux à six nœuds
MAS.
Avec le MDL, les datacenters d’entreprise peuvent :
◆
réduire les coûts informatiques ;
◆
améliorer les niveaux de service à l’utilisateur ;
◆
optimiser les procédures de reprise après sinistre ;
◆
disposer d’un stockage conforme dans des environnements de
stockage sur bandes.
Tous les modèles prennent en charge les principaux systèmes
d’exploitation IBM, notamment z/OS, OS/390, VSE, VM, TPF et
UNISYS OS220.
Suite à un rebranding, les versions les plus récentes de MDL ont été
intégrées à la gamme de produits DLm. Ces versions sont décrites
dans la section « EMC Disk Library for Mainframe (DLm) »,
page 213.
Mainframe Data Library
73
Matériel mainframe
Mainframe Data Library : 1000 et 2000
Auparavant nommés Mainframe Appliances for Storage (MAS), les
MDL 1000 et 2000 sont des périphériques de connectivité qui se
connectent directement aux canaux d’entrée/sortie FICON ou
ESCON du mainframe zSeries et sont rattachés aux baies de stockage
via une connexion Gigabit Ethernet IP (Celerra®/EMC Centera) ou
Fibre Channel (CLARiiON®). Le MDL 1000 est une unité d’entrée de
gamme fournie en standard avec une interface de canal FICON 4
unique et deux ports GigE.
Mainframe Data Library : 4000 et 6000
La conception des modèles MDL 4000 et 6000 se compose d’un rack
24U de 19 pouces standard, dont la configuration minimale
comprend deux ou trois nœuds MDL, évolutifs jusqu’à quatre ou six
nœuds, respectivement. Les modèles MDL 4000 et 6000 répondent
aux besoins des datacenters mainframe des entreprises en fournissant
des solutions d’émulation de bande mainframe évolutives et haute
disponibilité. Le MDL 6000 est conçu pour les environnements dont
les exigences de capacité de traitement actuelles et futures dépassent
1 Go/s.
Mainframe Data Library : 100V
Disponible avec une connectivité FICON ou ESCON, le MDL-100V
traite les données des bandes mainframe sur les plates-formes VTL
des systèmes distribués standard. Il est capable de converger les
sauvegardes des systèmes mainframe et distribués sur les VTL des
systèmes distribués et peut réduire la quantité de données stockées
en utilisant les fonctions de déduplication intégrées dans les moteurs
des VTL.
74
3
Ce chapitre présente le provisionnement du stockage pour les
environnements mainframe à l’aide de la fonction Virtual
Provisioning.
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Introduction ........................................................................................ 76
Terminologie ....................................................................................... 78
Virtual Provisioning : présentation de la mise en œuvre ............. 80
Performances ...................................................................................... 81
Virtual Provisioning : instructions de configuration .................... 82
Réplication en local et à distance et Virtual Provisioning ............ 90
Virtual Provisioning avec Mainframe Enablers (MFE)................. 91
Mobilité des périphériques avec Virtual Provisioning ............... 108
Surveillance des pools Virtual Provisioning ................................. 111
Récupération d’espace dans un thin pool .................................... 112
75
Introduction
La fonction Virtual Provisioning™ constitue une nouvelle méthode
de provisionnement des volumes CKD au sein des baies de la famille
Symmetrix VMAX. Elle est prise en charge pour l’émulation du
périphérique 3390 et est disponible avec les niveaux Enginuity 5876
et supérieurs.
Le provisionnement standard, aussi appelé Thick Provisioning,
consiste soit à créer un miroir de l’intégralité d’un volume 3390 sur
des hypervolumes Symmetrix (RAID1), soit à répartir le volume sur
les disques d’un niveau RAID unique (composé d’hypervolumes
résidant sur des disques physiques de la baie Symmetrix) en
incréments de deux ou quatre pistes. Cette configuration est illustrée
à la Figure 16.
Host
Volume
Image
(3390)
Physical
Disks
RAID 5 (3+1)
RAID 1
RAID 6 (6+2)
VMAX
Figure 16
Fonctionnement du provisionnement standard (Thick Provisioning) dans
les baies Symmetrix
Un volume provisionné de manière virtuelle (volume thin) répartit
l’image d’un volume 3390 sur une multitude de périphériques
physiques avec protection RAID en utilisant des unités de petite taille
(12 pistes) nommées groupes de pistes. Ces périphériques bénéficient
de la même protection RAID que les périphériques thick standard et
sont organisés en pools virtuels (thin pools) prenant charge une
configuration donnée en termes de géométrie de disque (CKD3390
ou FBA), de technologie de disque, de vitesse de disque et de type de
protection RAID.
Les périphériques thin sont associés à des pools virtuels au moment
de leur création par le biais d’un processus nommé « lien », et
peuvent être soit intégralement préalloués dans le pool, soit alloués à
la demande lorsqu’une écriture sur le volume a lieu.
76
La Figure 17 présente le schéma conceptuel d’une configuration de
type Virtual Provisioning.
Thin
devices
(3390)
Thin
device
pool
Physical
Disks
VMAX
Figure 17
Virtual Provisioning avec baie Symmetrix VMAX
C’est cette dispersion des groupes de pistes sur les disques d’un pool
qui justifie l’emploi du terme de provisionnement virtuel : au lieu
d’être rattaché à un niveau RAID unique, le volume existe sur de
multiples niveaux RAID au sein du pool virtuel.
Le fait de mapper l’image du périphérique sur un pool virtuel par le
biais de la couche d’abstraction des groupes de pistes donne
naissance au concept de Thin Provisioning, qui permet à un
utilisateur de choisir de ne pas préallouer l’intégralité de l’image d’un
volume au sein du pool afin de présenter, par le biais des volumes
thin, davantage de capacité de stockage qu’il n’y en a en réalité dans
le thin pool. On appelle surprovisionnement le fait de présenter plus
de capacité sur le canal qu’il n’y en a en réalité dans le pool, et
over-subscription le rapport entre le stockage présenté sur le canal et
le stockage réellement disponible dans le pool.
Virtual Provisioning offre les principaux avantages suivants :
◆
Les données font l’objet d’une répartition large entre tous les
disques du pool, éliminant efficacement les points sensibles et
améliorant les performances globales de la baie.
◆
Grâce à FAST VP, la baie permet la gestion active des
performances à la fois au niveau des sous-volumes et des
sous-Datasets.
Introduction
77
Terminologie
Virtual Provisioning pour les périphériques CKD fait appel à de
nouveaux termes qui ne sont pas forcément connus des utilisateurs
mainframe. Le tableau suivant décrit ces nouveaux termes, largement
utilisés dans ce chapitre.
Tableau 10
78
Terminologie relative à Virtual Provisioning
Terme
Description
Périphérique
Unité logique de stockage définie dans une baie
Symmetrix.
Capacité du périphérique
Capacité de stockage réelle d’un périphérique.
Groupe de pistes (extension
de périphérique)
Taille de la plus petite zone contiguë d’un
périphérique permettant le mappage d’extensions.
Périphérique accessible par
l’hôte
Périphérique présenté sur un canal FICON pour
permettre son utilisation par un hôte.
Périphérique interne
Périphérique servant au fonctionnement interne de
la baie.
Pool de stockage
Ensemble de périphériques internes servant des
objectifs spécifiques.
Périphérique thin
Périphérique accessible par l’hôte et auquel aucun
stockage n'est directement associé.
Périphérique de données
Périphérique interne fournissant une capacité de
stockage utilisable par un périphérique thin.
Mappage des extensions
Indique la relation qui lie un périphérique thin et les
extensions d’un périphérique de données. La taille
des extensions entre un périphérique thin et un
périphérique de données ne doit pas
nécessairement être la même.
Thin pool (pool virtuel)
Ensemble de périphériques de données fournissant
une capacité de stockage utilisable par les
périphériques thin.
Capacité du thin pool
Somme des capacités des périphériques de
données membres.
Lien
Processus associant un ou plusieurs périphériques
thin à un thin pool.
Tableau 10
Terminologie relative à Virtual Provisioning (suite)
Terme
Description
Supprimer le lien
Processus séparant un périphérique thin d’un thin
pool auquel il était associé. Toutes les allocations
d’extension précédentes des périphériques de
données sont alors effacées et peuvent être
redistribuées.
activé
Périphérique de données appartenant à un thin pool,
sur lequel des extensions peuvent être allouées aux
périphériques thin liés à ce pool.
désactivé
Périphérique de données appartenant à un thin pool
et dont la capacité ne peut pas être allouée aux
périphériques thin. Cet état est contrôlé par
l’utilisateur. Si un périphérique de données est lié à
des extensions, il doit faire l'objet d'une opération
DRAIN afin que les extensions soient déplacées vers
d’autres périphériques de données activés du thin
pool possédant de l’espace disponible.
Capacité activée du thin pool
Somme des capacités des périphériques de
données activés appartenant à un thin pool.
Capacité allouée du thin pool
Sous-ensemble de la capacité activée du thin pool,
allouée pour une utilisation exclusive par tous les
périphériques thin liés à ce thin pool.
Capacité préallouée du thin
pool
Capacité initiale allouée à un périphérique thin
lorsqu’il est lié à un thin pool. Ce paramètre est
contrôlé par l’utilisateur.
Capacité minimale préallouée
du périphérique thin
Capacité minimale préallouée à un périphérique thin
lorsqu’il est lié à un thin pool. Ce paramètre n’est pas
contrôlé par l’utilisateur.
Capacité écrite du
périphérique thin
Capacité d’un périphérique thin ayant fait l’objet
d’écritures par un hôte. Dans la plupart des
implémentations, il s’agit d’un sous-ensemble de la
capacité allouée au périphérique thin.
Capacité allouée du
périphérique thin
Capacité totale qu’un périphérique thin est autorisé à
retirer d’un thin pool, et qui peut être inférieure ou
égale à la capacité de ce périphérique thin.
Limite d’allocation du
périphérique thin
Capacité maximale qu’un périphérique thin est
autorisé à retirer d’un thin pool, et qui peut être
inférieure ou égale à la capacité allouée de ce
périphérique thin.
Terminologie
79
Virtual Provisioning : présentation de la mise en œuvre
Symmetrix Virtual Provisioning introduit un nouveau type de
périphérique accessible par l’hôte, appelé périphérique thin, dont
l’utilisation est similaire à celle des périphériques Symmetrix
traditionnels accessibles par l’hôte. Toutefois, contrairement aux
périphériques Symmetrix classiques, il n’est pas nécessaire d’allouer
intégralement le stockage physique des périphériques thin lors de
leur création et de leur présentation à un hôte. Le stockage physique à
partir duquel est fourni l’espace disque aux périphériques thin est
issu d’un pool de stockage partagé, le thin pool (ou pool virtuel).
Ce thin pool est composé de périphériques, appelés périphériques de
données, qui fournissent le stockage physique réel pour la prise en
charge des allocations des périphériques thin. Lorsqu’un
périphérique thin est créé, il n’est pas associé à un thin pool. Pour
qu’un périphérique thin dispose d’une VTOC ou d’une VTOC
indexée (VTOCIX) et qu’il soit disponible pour toutes les opérations
de données, il doit être lié au thin pool au moyen d'une opération dite
de lien. Les thin pools prennent en charge des architectures
(CKD3390 ou FBA), technologies (Flash, FC ou SATA) et vitesses de
disque ainsi que des types de protection RAID spécifiques.
Lors d’une écriture sur une partie du périphérique thin, le
sous-système Symmetrix alloue un espace de stockage physique
minimal à partir du thin pool et mappe cet espace à une zone du
périphérique thin qui comprend l’emplacement cible de l’écriture.
Les opérations d’allocation du stockage sont effectuées à l’aide de
petites unités de stockage appelées groupes de pistes (ou extensions
de périphériques). Un mécanisme de permutation circulaire permet
de répartir le groupe de pistes entre tous les périphériques de
données activés du pool qui disposent d’espace disponible. La taille
d’un groupe de pistes correspond à 12 pistes. Ainsi, le lien initial d’un
périphérique thin à un pool entraîne la création de groupes de pistes
à allouer au périphérique thin et dont le nombre dépend de la taille
de celui-ci.
80
Lors d’une lecture sur un périphérique thin, les données lues sont
récupérées à partir du périphérique de données correspondant dans
le pool de stockage lié au périphérique thin. Les lectures visant une
zone non mappée du périphérique thin n’entraînent aucune
opération d’allocation. La lecture d’une piste non mappée entraîne le
renvoi d’une piste vide (sans enregistrement utilisateur,
enregistrement zéro standard uniquement). Si davantage d’espace de
stockage est nécessaire à l’exploitation des périphériques thin actuels
et à venir, il est possible d’ajouter des périphériques de données aux
thin pools de stockage existants. Il est également possible de créer des
périphériques thin et de les associer aux thin pools existants.
Si le périphérique thin possède l’attribut PREALLOCATE, le
sous-système Symmetrix garantit que l’espace physique de la piste
est préalloué au périphérique. Si le périphérique thin possède
l’attribut PERSIST (qui implique et nécessite l’attribut
PREALLOCATE), le sous-système Symmetrix garantit que l’espace
physique de la piste n’est pas récupéré.
Comme indiqué sur le schéma, un périphérique thin peut également
être présenté pour une utilisation par l’hôte avant que toute la
capacité signalée du périphérique ait été allouée. La somme des
capacités signalées des périphériques thin utilisant un pool donné
peut également dépasser la capacité de stockage disponible du pool.
On dit qu’une telle configuration est en over-subscription ou qu’elle
est surprovisionnée. L’utilisateur peut choisir d’autoriser ou non le
surprovisionnement d’un thin pool à l’aide de différentes options.
Performances
L’impact de Virtual Provisioning sur les performances dépend de la
nature de la charge de travail et de l’état du périphérique thin. Dans
toute mise en œuvre de périphérique thin, la première écriture sur
une zone non allouée d’un périphérique thin prolonge le temps de
réponse et ralentit le débit. Dans l’implémentation de Symmetrix, ces
contraintes sont réduites et passent même inaperçues dans la plupart
des cas. Elles concernent principalement la première écriture sur une
extension de périphérique thin et disparaissent complètement une
fois que la partie active d’un périphérique thin a fait l’objet d’une
écriture.
Performances
81
Le principe clé à comprendre à propos des performances des
périphériques thin est la façon dont ils sont répartis sur le back-end
de la baie Symmetrix. Comme indiqué précédemment, les groupes de
pistes des périphériques thin sont distribués (répartition large) sur le
back-end et englobent généralement un nombre de disques bien plus
important qu’un périphérique classique. Ainsi, les périphériques thin
permettent d’éviter plus facilement tout déséquilibre de la charge de
travail du back-end. Il en résulte des performances améliorées pour la
plupart des charges de travail d’E/S.
Virtual Provisioning : instructions de configuration
Pour créer un environnement Virtual Provisioning offrant des
performances et une disponibilité élevées, il convient de respecter
certaines règles de configuration.
Lorsque vous planifiez une configuration faisant appel à des
périphériques thin, la première étape consiste à déterminer le nombre
de thin pools nécessaires et la composition de chacun d’eux.
Généralement, cette étape nécessite l’organisation globale du
stockage sur disque en différentes classes, divisées chacune en
sous-classes, le cas échéant, pour permettre l’isolation des ressources
du back-end (disques et adaptateurs de disque) utilisés par les pools.
Selon les différentes applications à placer sur les périphériques thin, il
est souvent nécessaire de créer plusieurs thin pools. Toutefois,
l’utilisation d’un nombre minimal de pools assure l’utilisation la plus
efficace des ressources.
Un thin pool doit être conçu pour être utilisé par une application
spécifique ou un ensemble d’applications liées correspondant à un
certain groupe fonctionnel de l’entreprise. Les applications
partageant un thin pool se disputent les ressources du back-end, y
compris la capacité de stockage du thin pool. Vous devez donc éviter
que des applications partagent le même pool si cela ne convient pas.
Les périphériques composant un thin pool ont les mêmes propriétés
de performance et de protection, donc les applications partageant un
thin pool doivent avoir les mêmes exigences dans ces domaines.
Lorsque vous avez conçu un ensemble de thin pools, vous pouvez
planifier l’organisation du back-end des futures demandes de
provisionnement du stockage en tenant simplement compte de la
classe de stockage requise et du groupe fonctionnel requérant le
stockage (si cette classe fait l’objet d’une subdivision).
82
Dimensionnement des ressources pour les périphériques thin
La capacité de stockage initiale d’un thin pool doit être suffisante
pour répondre aux besoins de stockage initiaux des applications
utilisant les pools. Ces besoins doivent être déterminés précisément et
les périphériques thin doivent toujours disposer de suffisamment
d’espace physique pour répondre à ceux-ci.
Outre la capacité de stockage des périphériques thin, d’autres
processus réservent des capacités dans les thin pools. Par exemple, si
la compression de périphériques thin liés est activée sur un thin pool,
un espace de stockage est réservé dans le pool qui servira à
décompresser temporairement les données.
Si un thin pool est ensuite défini comme faisant partie d’un niveau de
stockage FAST, cette technologie garantit qu’un pourcentage de la
capacité du pool, défini par l’utilisateur, n’est pas alloué (capacité
réservée du pool) avant que FAST effectue tout déplacement de
données vers le pool.
Chaque périphérique de données d’un thin pool contient des pistes
réservées aux métadonnées d’allocation. Chacun de ces
périphériques contient au moins 12 pistes réservées. Les 12 pistes de
métadonnées contiennent des plans d’allocation de 76 800 cylindres
(maximum) d’un périphérique de données. Les périphériques de
données composés de plus de 76 800 cylindres nécessitent un espace
de métadonnées supérieur. Actuellement, le périphérique de données
le plus volumineux pouvant être configuré pour un thin pool se
compose de 256 000 cylindres. Le tableau suivant indique les pistes
de métadonnées réservées en fonction de la taille des périphériques
de données (nombre de cylindres).
Tableau 11
Pistes de métadonnées réservées en fonction de la taille du périphérique
de données
Taille du périphérique de données (TDAT) exprimée
en nombre de cylindres
Minimum
Maximum
Pistes de métadonnées
réservées
48
76 800
12
76 801
153 600
24
153 601
230 400
36
230 401
256 000
48
83
Si vous employez une approche de préallocation complète, les
périphériques de données doivent être dimensionnés de sorte à
représenter la capacité totale du périphérique thin, ainsi que l’espace
potentiellement réservé et les métadonnées du pool.
Si vous utilisez un pool en over-subscription pour bénéficier d’un
préprovisionnement à moindre coût, la capacité supplémentaire doit
être suffisante pour garantir que l’administrateur de stockage a le
temps d’ajouter davantage de capacité au pool lorsque celui-ci risque
d’atteindre rapidement son maximum.
Les périphériques de données composant un thin pool doivent être
répartis sur une configuration matérielle back-end disposant de
performances suffisantes pour gérer la charge de travail d’E/S selon
les besoins à court et long termes. Lorsque vous avez déterminé la
configuration des disques et adaptateurs de disque dans
l’organisation initiale du thin pool, vous pourrez facilement ajouter
ultérieurement de la capacité de stockage au pool. En revanche, si le
pool initial n’était pas réparti sur suffisamment de disques et
d’adaptateurs de disque pour faire face à la charge de travail sur les
zones initialement mappées des périphériques thin, l’ajout de
périphériques de données au pool ne règle pas forcément le
problème, même s’ils se trouvent sur des disques physiques distincts.
Conditions supplémentaires requises par le cache
Les périphériques thin étant des périphériques de cache, quelques
conditions supplémentaires requises par le cache s’appliquent. Bien
qu’elles soient minimes, ces exigences doivent être prises en compte
lors de la configuration d’un périphérique thin. L’outil commercial
EMC Direct Express doit être utilisé pour déterminer les exigences
supplémentaires du cache.
Conditions relatives à l’organisation du thin pool
La plupart des conditions relatives à la conception d’autres types de
pools Symmetrix s’appliquent également à celle de thin pools. Les
périphériques composant un thin pool doivent respecter toutes les
conditions suivantes :
◆
84
Seuls des périphériques de données peuvent être placés dans un
thin pool.
◆
Les périphériques de données doivent tous disposer de la même
émulation.
◆
Les périphériques de données doivent tous bénéficier du même
type de protection, qui ne peut pas être RAID 10.
◆
Nous vous recommandons de placer tous les périphériques de
données d’un même pool sur des disques présentant la même
vitesse de rotation. FAST VP applique cette restriction si le pool
est ajouté à un niveau FAST VP.
◆
Les périphériques de données du pool doivent en principe être
répartis entre autant de disques et d’adaptateurs de disque d’une
vitesse donnée que possible. La répartition large assurée par
Virtual Provisioning distribue les groupes de pistes des
périphériques thin de manière uniforme entre les périphériques
de données. Toutefois, lorsque vous ajoutez des périphériques de
données à un pool, ils doivent être répartis uniformément sur le
back-end.
◆
Nous vous recommandons de placer des périphériques de
données de même taille dans un pool. L’utilisation de
périphériques de tailles différentes pourrait entraîner une
distribution irrégulière des données.
◆
Leur taille doit être la plus grande possible afin de réduire le
nombre de périphériques nécessaires pour atteindre la capacité
de pool totale souhaitée.
Pour la plupart des tailles et des types de protection des disques, il
convient de dimensionner les périphériques de données de sorte qu’il
existe huit hypervolumes par disque physique afin que la longueur
de la file d’attente des disques reste raisonnable et pour éviter les
recherches excessives.
Le Tableau 12 montre les types de protection recommandés pour les
différentes catégories de disque :
Tableau 12
Protection recommandée par catégorie de disque :
Catégorie de disque
Type de protection
Disques Flash
RAID 5 (3+1)
FC/SAS
RAID 1
SATA
RAID 6 (6+2)
85
S’il existe des relations SRDF pour tous les périphériques thin liés, la
protection RAID 5 (3+1) est viable pour le thin pool.
Ajout de capacité à un thin pool
Lorsqu’un thin pool en over-subscription commence à manquer
d’espace, des périphériques de données doivent lui être ajoutés avant
qu’il ne soit plein. À défaut, une application écrivant sur une portion
précédemment non mappée d’un périphérique thin risque de
rencontrer une erreur relative au manque d’espace. L’ajout de
périphériques de données à un thin pool peut se faire sans
interruption. Tous les périphériques de données à ajouter au thin
pool existant doivent répondre aux conditions suivantes :
◆
Les périphériques doivent bénéficier du même type de protection
que ceux déjà placés dans le thin pool cible.
◆
Les périphériques doivent disposer de la même émulation que
ceux déjà placés dans le thin pool cible.
◆
Les périphériques doivent résider sur des disques présentant la
même vitesse de rotation.
◆
Les différents périphériques de données doivent être
uniformément répartis sur un ensemble de disques et
d’adaptateurs de disque.
Nous vous recommandons de placer des périphériques de données
de même taille dans un pool. L’utilisation de périphériques de tailles
différentes pourrait entraîner une distribution irrégulière des
données.
Rééquilibrage de thin pool
Le rééquilibrage d’un thin pool permet à l’utilisateur de rétablir
l’équilibre des charges de travail sans provoquer d’interruption, afin
d’étendre la capacité du thin pool par petits incréments, en fonction
des besoins. Cette opération vous permet d’optimiser les
performances et de réduire le coût total de possession (TCO). Les
utilisateurs peuvent exécuter sur le thin pool une commande
assurant le rééquilibrage des groupes de pistes alloués sur tous les
périphériques de données activés du pool. Ils bénéficient ainsi d’une
extension du pool avec peu de périphériques de données sans mettre
en péril la répartition large.
86
Compression des périphériques thin
Enginuity 5876 (version de service Q4-2012) et Mainframe Enablers
(MFE) version 7.5 permettent la compression des périphériques de
données afin d’économiser l’espace, ainsi que leur décompression en
fonction des besoins. MFE permet désormais aux utilisateurs de
compresser et décompresser manuellement les extensions de
périphériques thin. Il propose par ailleurs des fonctions de gestion de
la configuration et de reporting sur l’état de compression de ces
périphériques.
La compression est réservée aux périphériques thin dont les données
sont inactives. Il est conseillé de ne pas exécuter de charges de travail
moyennes ou importantes sur les périphériques compressés. Bien que
ceux-ci prennent en charge la lecture et l’écriture, ces opérations
peuvent avoir une incidence sur l’ensemble du sous-système. La
compression automatique (en gardant les volumes compressés) ne
peut être obtenue que par le biais de l’automatisation FAST VP. Seule
la compression manuelle est prise en charge par MFE.
Suggestions d’utilisation de la compression manuelle des
périphériques thin (sans FAST) :
◆
Archivage d’anciens fichiers utilisateur
◆
Opérations de décompression/utilisation/recompression en fin
de trimestre
Utilisation déconseillée de la compression manuelle :
◆
Données actives à moindre coût/performances faibles
Enginuity permet la lecture et l’écriture des données compressées.
Pour ce faire, Enginuity décompresse les données selon les besoins
dans un espace réservé au sein du thin pool aux allocations de
périphériques thin compressés. Pour que cet espace soit réservé et
pour permettre la compression des allocations d’un pool, celle-ci doit
préalablement avoir été activée sur le pool. Si vous ne souhaitez plus
permettre la compression des allocations dans un pool, la fonction de
compression d’un pool peut être désactivée.
La lecture d’une piste compressée entraîne la décompression
temporaire de celle-ci dans le stockage temporaire du pool. L’espace
de ce stockage est contrôlé par un algorithme de type LRU (Least
Rencently Used) garantissant que les pistes peuvent toujours être
décompressées et que celles utilisées en dernier restent disponibles
sous leur forme décompressée.
87
Lors des opérations d’écriture, les allocations décompressées sont
toujours écrites sur le périphérique thin. Le périphérique peut être
compressé manuellement à tout moment. La décompression
s’effectue à la demande de l’utilisateur ou lors de l’écriture de
données. Aucune recompression automatique n’a lieu après
l’écriture.
Lorsqu’un utilisateur choisit de compresser un périphérique, seules
les allocations qui ont fait l’objet d’une écriture sont compressées.
Toutes les allocations créées lors du processus de lien ou d’allocation
et n’ayant fait l’objet d’aucune opération d’écriture seront récupérées
lors de la compression. Remarque : le processus de récupération de
tout l’espace de stockage inutilisé, qui est exécuté lors de la
compression, supprime l’allocation des pistes contenant un
enregistrement zéro standard, mais ne remplace pas les Datasets
supprimés qui ne contiennent pas encore de telles pistes. Pour
récupérer ces pistes et éviter de compresser les Datasets supprimés,
exécutez l’utilitaire TRU (Thin Reclaim Utility) sur le périphérique
thin avant de le compresser.
Le fait que les allocations sans écritures puissent être récupérées
implique que les allocations persistantes ne peuvent pas être
compressées, puisque leur récupération automatique n’est pas
autorisée. Pour pouvoir compresser un périphérique thin comportant
des allocations persistantes (ce qui rend possible la récupération des
allocations sans écriture), vous devez d’abord supprimer l’attribut
persistant afin de permettre la compression et la récupération.
La compression des allocations d’un périphérique thin est une tâche
d’arrière-plan. Après l’acceptation de la demande de compression, le
périphérique thin se voit affecter une tâche d’arrière-plan qui effectue
sa compression.
Si un périphérique thin contenant des allocations dans plusieurs
pools est compressé, la fonction de compression de MFE déplace
toutes les allocations du périphérique vers le pool auquel le
périphérique est actuellement lié avant de les compresser. Par
conséquent, lorsqu’un périphérique thin est compressé, toutes ses
allocations résident dans le pool lié.
88
Remarques concernant la migration thick-to-thin
Une planification précoce est la clé du succès de toute migration de
données. C’est également le cas pour les migrations thick-to-thin.
Lorsque vous décidez d’utiliser des périphériques thin, vous pouvez
opter pour des méthodes de copie basées sur l’hôte ou pour des
technologies de réplication basées sur la baie. En fin de compte, le
choix des méthodes de copie se limite souvent à trouver la méthode
qui ne perturbe pas l’application accédant aux données.
◆
Les données peuvent être migrées depuis des périphériques
existants vers des périphériques thin en over-subscription plus
volumineux à l’aide de méthodes de migration basées sur la baie
ou sur l’hôte.
◆
Vous pouvez faire appel à un mécanisme de copie au niveau de
l’hôte pour copier les données depuis des volumes sources
standard vers des volumes cibles thin.
Le tableau Tableau 13 présente des exemples de choix de migration
accompagnés de remarques utiles.
Tableau 13
Matrice d’exemples de migration thick-to-thin
Méthodologie de
copie
Perturbation de
l’application
(l’accès doit être
interrompu)
Remarques
DFDSS, FDRDSF,
autres utilitaires
OUI
Propose la consolidation des
extensions des Datasets.
Réallocation DFSMS
OUI
La redéfinition des Datasets
par lot entraîne la migration
vers un nouveau groupe de
stockage de périphériques thin
géré par le système avec des
modifications de la sélection
des volumes dans les
routines ACS.
EMC z/OS Migrator
NON
Niveau du volume et du
Dataset dans un seul produit ;
réalisation de REFVTOC
depuis un petit volume vers un
grand volume.
89
Tableau 13
Matrice d’exemples de migration thick-to-thin (suite)
Méthodologie de
copie
Perturbation de
l’application
(l’accès doit être
interrompu)
TDMF (ZDMF)
NON
réalisation de REFVTOC de
petit volume vers un grand.
FDRPAS (FDRMOVE)
NON
réalisation de REFVTOC de
petit volume vers un grand.
EMC SRDF/Data
Mobility (copie
évolutive)
OUI
Consultez la matrice de
support EMC pour connaître
les niveaux de code Enginuity
pris en charge.
Reportez-vous également à la
fonction de récupération SRDF
thick R1.
EMC TimeFinder®/
Clone (SNAP
VOLUME)
OUI
EMC TimeFinder/Clone
(SNAP DATASET)
OUI
Remarques
Réplication en local et à distance et Virtual Provisioning
Les systèmes de réplication EMC TimeFinder et EMC SRDF sont
compatibles avec les périphériques thin CKD. Pour la réplication en
local, un périphérique thin peut être la source et/ou la cible d’une
action TimeFinder/Clone et la source d’une action TimeFinder/Snap
(un périphérique virtuel (VDEV) de snapshot cible doit être mappé
sur le pool SAVE). Pour la réplication à distance, les périphériques
thin sont pris en charge dans les modes SRDF/S, SRDF/A et
SRDF/DM. Cependant, pour les périphériques CKD, seule la
réplication thin-to-thin (volume R2) est prise en charge actuellement.
90
Pour la réplication à distance, les périphériques thin sont pris en
charge dans les modes SRDF/S, SRDF/A et SRDF/DM, dans toutes
les topologies SRDF (simultanées et en cascade). La récupération sur
les périphériques thick R1 associés à des périphériques thin R2 est
prise en charge par Mainframe Enablers (MFE) version 7.5.
L’utilitaire TRU (Thin Reclaim Utility) de SCF (Symmetrix Control
Facility) inclus dans cette version est décrit ultérieurement à la
section Section « Récupération d’espace dans un thin pool »,
page 112.
Les périphériques de données ne sont pas adressables par l’hôte et ne
peuvent servir ni de source ni de cible aux opérations TimeFinder ou
SRDF.
Virtual Provisioning avec Mainframe Enablers (MFE)
Les versions 7.4 et ultérieures de Mainframe Enablers (MFE)
proposent une fonction améliorée de gestion des pools qui facilite
l’administration des pools virtuels et des pools SAVE pour les
périphériques virtuels TimeFinder/Snap et les pools DSE pour
l’extension SRDF/A Delta Set Extension.
Pour utiliser cette fonction, vous devez implémenter un nouvel
environnement SCF (Symmetrix Control Facility) appelé GPM
(General Pool Maintenance). Vous disposerez alors d’une interface de
commande MODIFY z/OS, d’une interface de l’utilitaire de
traitement par lot et d’une interface de commande MODIFY z/OS
également capable d’utiliser la CPF (Command Prefix Facility) de
SCF (reportez-vous au paramètre d’initialisation SCF.INI.CPFX).
L’environnement GPM permet au client d’utiliser à la fois des
fonctions centrées sur le pool virtuel et des fonctions centrées sur le
périphérique thin, comme indiqué dans les deux tableaux suivants.
Tableau 14
Commandes centrées sur le pool
Commande
Description
CREATE
Créer un pool de périphériques thin, DSE ou de
snapshots
DELETE
Supprimer un pool de périphériques vide
DISPLAY
Afficher les informations relatives à un thin pool
91
Tableau 14
Tableau 15
92
Commandes centrées sur le pool
Commande
Description
POOLATTR
Spécifier les attributs au niveau du pool
REBALANCE
Lancer l’équilibrage des pistes allouées au sein d’un
pool
RENAME
Modifier le nom d’un thin pool
Commandes centrées sur le périphérique
Commande
Description
ADD
Ajouter un ou plusieurs périphériques back-end à un
thin pool
ALLOCATE
Allouer toutes les pistes d’un périphérique thin à des
périphériques de données
BIND
Lier un ou plusieurs périphériques back-end à un
thin pool
COMPRESS
Compresser les données pour des périphériques
thin (MFE version 7.5 et Enginuity 5876 version de
service Q4-2012)
DECOMPRESS
Décompresser les données pour des périphériques
thin (MFE version 7.5 et Enginuity 5876 version de
service Q4-2012)
DISABLE
Faire passer l’état d’un ou de plusieurs périphériques
d’un pool d’actif à inactif
DRAIN
Réattribuer les pistes allouées à d’autres
périphériques d’un pool
ENABLE
Faire passer l’état d’un ou de plusieurs périphériques
d’un pool d’inactif à actif
HDRAIN
Interrompre la réattribution des pistes des
périphériques d’un pool
QUERY
Afficher les informations relatives aux entités des
périphériques avec allocation dynamique (Thin
Provisioning)
MOVE
Déplacer les pistes allouées entre le pool
précédemment lié et le pool actuel
REBIND
Changer le pool auquel est lié un périphérique thin
Tableau 15
Commandes centrées sur le périphérique (suite)
Commande
Description
REMOVE
Supprimer un périphérique inactif d’un pool de
périphériques
UNBIND
Supprimer le lien entre un ou plusieurs périphériques
thin et un pool de périphériques thin
USR_NRDY
Faire passer l’état de l’unité de contrôle d’un
périphérique à user-not-ready (utilisateur non prêt)
USR_RDY
Faire passer l’état de l’unité de contrôle d’un
périphérique à user-ready (utilisateur prêt)
Exemples d’utilisation de GPM (General Pool Maintenance)
Vous trouverez ci-après des exemples de la marche à suivre pour
configurer, mettre à jour et surveiller un environnement Symmetrix
Virtual Provisioning à l’aide des commandes GPM et du dispositif de
surveillance de thin pool implémenté dans Symmetrix Control
Facility. Les exemples utilisés dans le TechBook ont été créés à des
fins d’illustration et ne correspondent pas à un environnement
Virtual Provisioning configuré pour des charges de travail de
production.
Création et affichage de thin pools
La création de thin pools et leur association à des périphériques thin
se résument en quelques étapes :
1. Créer un pool (commande CREATE)
2. Exécuter la commande QUERY DATADEV pour rechercher les
périphériques disponibles
3. Ajouter des périphériques de données au pool (commande ADD)
4. Exécuter la commande QUERY THINDEV pour rechercher les
périphériques thin disponibles
5. Lier des périphériques thin au pool (commande BIND)
6. Afficher le pool (commande DISPLAY)
7. Exécuter la commande QUERY pour rechercher les périphériques
thin et de données
93
Les périphériques thin sont désormais prêts pour
l’initialisation ICKDSF (commande ICKDSF INIT) et peuvent être
utilisés. Les exemples ci-après fournissent davantage de détails sur
chaque étape de la procédure.
Les thin pools sont créés à l’aide de la commande CREATE. Leur
création ne nécessite pas l’ajout de périphériques de données, ils
peuvent donc être terminés ultérieurement. Dans cet exemple, un
pool nommé ZOS_FC_2M est créé :
CREATE LCL(UNIT(1000)) POOL(ZOS_FC_2M) TYPE(THINPOOL)
Exemple de réponse :
Lorsqu’un pool est créé, vous pouvez y ajouter des périphériques de
données et les activer. Vous pouvez exécuter une requête pour
connaître les périphériques de données disponibles (à partir du pool
par défaut DF_DDEV_POOL ou .NOPOOL.) pouvant être ajoutés à
des pools, à l’aide de la commande suivante :
QUERY DATADEV LCL(UNIT(1000))
Des périphériques d’un thin pool peuvent être désactivés. Dans ce
cas, ils ne sont pas disponibles pour les attributions de groupes de
pistes. Vous pouvez également utiliser la commande ADD pour
ajouter des périphériques de données à un pool existant et les activer
en une seule action :
ADD LCL(UNIT(1000)) POOL(FC_2M) DEV(28C-28D) ACTIVE
94
Lorsque des périphériques de données actifs ont été ajoutés au thin
pool, vous pouvez lier ce dernier à des périphériques thin. La
commande QUERY vous permet de rechercher les périphériques
disponibles (non liés) pour les lier aux thin pools. Utilisez le format
de commande suivant pour exécuter la requête :
QUERY THINDEV LCL(UNIT(1000))
Exemple de réponse à la requête :
À présent, pour lier les périphériques thin à un thin pool, utilisez la
commande GPM suivante :
BIND LCL(UNIT(1000)) POOL(ZOS_FC_2M) DEV(160)
95
Les commandes DISPLAY (affichage) et QUERY (requête) vous
permettent d’interroger l’environnement de Virtual Provisioning
comme suit :
DISPLAY LCL(UNIT(1000)) POOL(FC_2M)
QUERY THINDEV LCL(UNIT(1000)) DEV(160)
Augmentation de la capacité et rééquilibrage d’un thin pool
Un environnement EMC à provisionnement virtuel offre des
fonctions de gestion améliorées, notamment le rééquilibrage d’un
thin pool suite à l’augmentation de sa capacité.
L’extension et le rééquilibrage d’un thin pool se résument en deux
étapes :
1. Ajouter des périphériques de données au thin pool et les activer
2. Démarrer le processus de rééquilibrage sur le thin pool
Cet exemple d’utilisation repose sur un scénario dans lequel un thin
pool a atteint une capacité utilisée d’environ 29 % et où des
périphériques de données sont ajoutés au thin pool sans provoquer
d’interruption. La commande suivante vous permet d’afficher une
vue détaillée du thin pool concerné :
DISPLAY LCL(UNIT(1000)) POOL(ZOS_FC_2M)
96
Pour étendre un thin pool, il suffit d’ajouter de nouveaux
périphériques de données au pool et de les activer.
Dans cet exemple, seuls deux nouveaux périphériques sont ajoutés,
mais il est en réalité fortement recommandé de disposer d’un nombre
de périphériques correspondant à un multiple du nombre
d’adaptateurs de disque.
Pour ajouter des périphériques de données à un pool et les activer,
utilisez la commande suivante :
ADD LCL(UNIT(1000)) POOL(ZOS_FC_2M) DEV(290-291) ACTIVE
L’ajout de nouveaux périphériques déséquilibre le pool. La Figure 18
illustre l’espace disponible (représenté en blanc) dans un pool de six
disques. L’espace disponible n’est pas réparti de manière uniforme
entre les disques.
97
Figure 18
Thin pool non équilibré
La commande suivante vous permet d’afficher une vue détaillée du
thin pool concerné :
Pour rééquilibrer les pistes utilisées entre tous les périphériques de
données du thin pool, utilisez le format de commande GPM suivant :
REBALANCE LCL(UNIT(1000)) POOL(ZOS_FC_2M)
L’opération de rééquilibrage répartit à nouveau les données entre les
périphériques de données activés du thin pool.
98
L’algorithme d’équilibrage calcule les valeurs minimale, maximale et
moyenne de la capacité utilisée sur les périphériques de données du
thin pool. Le sous-système Symmetrix déplace ensuite les extensions
de périphérique thin qui résident sur les périphériques de données
présentant les taux de capacité utilisée les plus élevés vers ceux dont
les taux sont les plus faibles, jusqu’à ce que le pool soit équilibré.
Enginuity attribue une priorité plus élevée aux opérations d’E/S de
l’hôte qu’aux opérations de rééquilibrage. Toutefois, le rééquilibrage
peut être interrompu, quelle qu’en soit la raison, notamment
lorsqu’une période de forte activité des E/S de l’hôte ou une
opération entraînant de nombreuses tâches de copie interne
s’annonce. Le rééquilibrage peut être poursuivi ultérieurement. Il
reprend alors là où il s’était arrêté.
Lorsque l’opération est terminée, le pool est équilibré. La Figure 19
illustre l’espace disponible (représenté en blanc) dans un pool de six
disques. L’espace disponible est à présent réparti uniformément entre
les disques, optimisant l’efficacité de la répartition large définie.
Figure 19
Thin pool rééquilibré
thin pool concerné :
99
Procédez avec prudence lorsque vous migrez des périphériques
applicatifs dont l’organisation back-end a déjà été réglée avec
précision. Cette consigne est particulièrement de mise si le réglage
comprenait l’isolation des ressources back-end utilisées par certaines
parties de la charge de travail et que les besoins de l’application en
matière de débit et de temps de réponse sont stricts. Dans ce cas, la
simple migration de tous les périphériques vers un seul thin pool
volumineux partagé avec d’autres applications pourrait dégrader les
performances.
Compression des périphériques thin
Enginuity 5876 (version de service Q4-2012) et Mainframe Enablers
(MFE) version 7.5 permettent la compression des périphériques de
données afin d’économiser l’espace, ainsi que leur décompression en
fonction des besoins.
La compression des périphériques thin se résume en deux étapes :
1. Modifier un attribut du thin pool pour activer la compression
2. Lancer le processus de compression (commande COMPRESS) sur
les périphériques thin souhaités
La commande DISPLAY vous permet d’interroger l’attribut d’un thin
pool comme suit :
DISPLAY LCL(UNIT(3A00))
Remarque : sur le pool MFCKD1, la compression est désactivée et le
pourcentage d’utilisation du pool est de 31 %.
100
La colonne Com affichée dans le résultat de la commande Query Thin
Devices indique qu’aucun des périphériques du pool n’est
actuellement compressé. La commande Query Thin Devices est
illustrée ci-après :
QUERY THIND LCL UNIT 3A00 POOL MFCKD1
Une requête des périphériques de données du pool indique le
nombre de pistes utilisées par périphérique et le pourcentage total
utilisé. La commande Query Data Devices est illustrée ci-après :
QUERY DATADEV LCL UNIT 3A00 POOL MFCKD1
101
La compression est désactivée par défaut. Pour pouvoir compresser
les périphériques thin liés à ce pool, vous devez l’activer en exécutant
la commande POOLATTR avec le paramètre
COMPRESSION(ENABLE). La séquence de commandes suivante
active la compression et affiche l’attribut de compression :
POOLATTR LCL UNIT 3A00 COMPRESS(ENABLE) POOL MFCKD1
DISPLAY LCL 3A00
102
Exemple de commande permettant de démarrer la compression de
groupes de pistes de périphériques thin :
COMPRESS LCL UNIT 3A00 POOL MFCKD1 DEV E30 E3F
À présent, lorsque vous émettez une requête sur les périphériques
thin comme illustré ci-après, ceux-ci sont signalés comme présentant
des allocations compressées :
QUERY THIND UNIT 3A00 POOL MFCKD1
103
104
Clonage thick-to-thin TimeFinder/Clone avec fonction automatique de
lien/suppression de lien
TimeFinder/Clone vous permet de créer et de gérer des copies
ponctuelles au sein de la baie VMAX. Dans le cas du stockage à
provisionnement virtuel, la cible d’une opération de clonage peut être
un périphérique thin bénéficiant d’avantages supplémentaires en
matière de taux d’utilisation et de performance des allocations, grâce
à la répartition large. Une nouvelle fonction de lien et de suppression
de lien automatique confère la simplicité d’utilisation et la flexibilité
du stockage hiérarchisé à l’opération de clonage. Prenons l’exemple
d’un scénario dans lequel la copie ponctuelle d’une charge de travail
privilégierait une copie sur des disques SATA économiques lors de la
sauvegarde et une autre copie sur des disques Flash à haut débit pour
le reporting rapide à la demande. La possibilité de lier
automatiquement le clone cible au niveau de stockage approprié, au
moment opportun, puis de supprimer le lien et supprimer
automatiquement l’espace alloué au clone à la fin de la copie
ponctuelle permet une utilisation plus rapide et plus efficace des
ressources de stockage.
L’exemple suivant illustre la procédure à suivre pour utiliser la
fonction automatique de lien/suppression de lien de TimeFinder.
Reportez-vous au document EMC Mainframe Enablers
TimeFinder/Clone Snap Facility Version Product Guide pour en
savoir plus sur les opérations TimeFinder.
La commande suivante permet d’interroger les périphériques thin
pour rechercher les périphériques disponibles (non liés) pouvant être
liés à des pools :
QUERY THINDEV LCL(UNIT(3800))
105
Pour créer et activer une session de clonage entre un périphérique
standard (thick) et un périphérique thin non lié, utilisez le format de
tâche TimeFinder suivant :
//jobname JOB
(EMC),pgmmrname,CLASS=A,MSGCLASS=X
//CLONEJOB EXEC PGM=EMCSNAP,REGION=0k
//STEPLIB DD
DISP=SHR,DSN=ds-prefix.LINKLIB
//SCF$nnnn DD
DUMMY
//SYSPRINT DD
SYSOUT=*
//QCOUTPUT DD
SYSOUT=*
//QCINPUT DD
*
SNAP VOLUME ( SOURCE (UNIT(13C5)) TARGET (UNIT(3E75))
NEWVOLID(CK3E75) POOL(SATA_R6) AUTO_BIND_TDEV(YES) )
/*
Exemple de sortie :
Pour interroger le périphérique thin servant de cible de clonage,
exécutez la commande suivante :
QUERY THINDEV LCL(UNIT(13C0)) DEV(165)
106
thin pool :
QUERY THINDEV LCL(UNIT(13C0)) POOL(SATA_R6)
Vous pouvez interrompre la session de clonage (commande STOP
SNAP) avec suppression de lien automatique en utilisant le format de
commande suivant :
STOP SNAP TO VOLUME ( TARGET(UNIT(3E75))
AUTO_UNBIND_TDEV(YES) )
Exemple de sortie de la commande STOP SNAP :
107
Si vous affichez le thin pool après l’exécution de la commande STOP
SNAP avec l’option AUTO_BIND activée, vous remarquerez que
l’espace a été automatiquement supprimé :
DISPLAY LCL(UNIT(13C0)) POOL(SATA_R6)
Exemple de sortie :
Mobilité des périphériques avec Virtual Provisioning
EMC Virtual Provisioning offre la technologie Enginuity (VLUN VP)
permettant le déplacement des périphériques thin Symmetrix entre
les thin pools sans provoquer d’interruption des applications
utilisateur et avec un impact minimal sur les E/S de l’hôte. Les
utilisateurs peuvent déplacer les périphériques thin entre les thin
pools pour modifier le type de disque, la protection RAID ou le
niveau de performance. VLUN VP est également la technologie à
l’origine de FAST VP, qui permet le déplacement de parties d’un
périphérique thin (sous-volume) entre des pools. La fonction VLUN
VP peut être exploitée à l’aide de la commande GPM centrée sur le
périphérique MOVE.
La commande MOVE déplace les allocations de groupes de pistes
existants à partir d’un thin pool auquel les périphériques thin étaient
précédemment liés (comme indiqué par le paramètre SRCPOOL) vers
le pool auquel les périphériques thin sont actuellement liés (comme
indiqué par le paramètre POOL), sans entraîner de perte de données.
108
Les groupes de pistes attribués aux périphériques du pool source
sont déplacés vers le pool auquel les périphériques sont actuellement
liés.
Si le paramètre REBIND a été spécifié, les périphériques thin sont
d’abord liés à nouveau au pool cible (indiqué par le paramètre
POOL) et les pistes allouées aux périphériques du pool source sont
déplacées vers le pool cible auquel les périphériques sont liés.
Pour illustrer l’utilisation de la commande MOVE, prenons le
scénario précédent, dans lequel le clonage thick-to-thin de
TimeFinder avec lien automatique était employé pour réaliser une
copie ponctuelle de volumes d’une base de données vers un thin pool
SATA économique. Le pool SATA permet de répondre aux exigences
en termes d’E/S d’une charge de travail hautement séquentielle et à
taux élevé d’accès en lecture. Toutefois, si un utilisateur devait
également utiliser périodiquement la copie ponctuelle de la base de
données pour une charge de travail de requêtes aléatoires à haute
priorité d’échec en lecture, le pool de stockage EFD serait plus
approprié. La commande GPM MOVE peut être utilisée pour réaliser
la tâche de mobilité des données.
En affichant le thin pool sur disque Flash, vous pouvez consulter les
pistes utilisées et disponibles, comme illustré dans la commande
suivante :
DISPLAY LCL(UNIT(1000)) POOL(ZOS_EFD_R5)
Vous pouvez exécuter la commande MOVE (avec REBIND) pour
relier et déplacer les groupes de pistes des périphériques thin qui
étaient la cible de la commande SNAP VOLUME de
TimeFinder/Clone avec lien automatique, sans provoquer
d’interruption. Voici un exemple de la commande GPM MOVE :
MOVE LCL(UNIT(100)) DEV(165) POOL(ZOS_EFD_R5) SOURCEPOOL(ZOS_SATA_R6) REBIND
Mobilité des périphériques avec Virtual Provisioning
109
Vous pouvez à nouveau afficher le thin pool sur disque Flash et
observer les pistes utilisées et disponibles dans le résultat :
DISPLAY LCL(UNIT(1000)) POOL(ZOS_EFD_R5)
La copie ponctuelle de la base de données pour la charge de travail de
requêtes aléatoires à haute priorité d’échec en lecture peut être
effectuée dès la fin de la tâche MOVE/REBIND.
110
Surveillance des pools Virtual Provisioning
Symmetrix Control Facility prend actuellement en charge les
dispositifs de surveillance persistants pour les pools de périphériques
SAVE utilisés par TimeFinder/Snap et le pool DSE utilisé par la
fonction SRDF/A Delta Set Extension. MFE version 7.4 étend cette
fonction de surveillance à la capacité du pool virtuel pour le compte
de Virtual Provisioning. Les commandes du dispositif de surveillance
des périphériques thin sont identiques à celles des dispositifs SAVE et
DSE, et sont indiquées par THN dans la syntaxe du relevé de contrôle
du dispositif de surveillance SCF. Les valeurs utilisées pour les alertes
et les actions peuvent être définies au niveau global, du contrôleur ou
de chaque pool. Voici un exemple de paramètre global pour le
dispositif de surveillance des périphériques thin :
Voici des exemples de messages de la console z/OS générés en
fonction des paramètres de surveillance du pool THN :
Les paramètres ACTION peuvent également servir à nommer un
module de sortie utilisateur invoqué à des seuils définis. Par
exemple, la sortie peut servir à demander à l’utilitaire TRU de réaliser
une tâche SCAN/RECLAIM sur tous les périphériques d’un pool.
Surveillance des pools Virtual Provisioning
111
Récupération d’espace dans un thin pool
Le deuxième composant majeur de la prise en charge de la fonction
Virtual Provisioning par MFE est un nouvel environnement
Symmetrix Control Facility, l’utilitaire TRU (Thin Reclaim Utility).
Le processus TRU comporte quatre étapes qui se déroulent dans
l’ordre suivant :
1. EMCSCF découvre et surveille les périphériques thin non liés
dotés de l’attribut PERSIST.
2. La sortie z/OS EMC SCRATCH (ou l’utilitaire SCAN) identifie et
marque les pistes pouvant être récupérées.
3. EMCSCF met à jour périodiquement (via l’utilitaire RECLAIM)
les listes de pistes vides (cette opération peut aussi être exécutée
par le biais d’un traitement par lot).
4. La tâche d’arrière-plan de récupération de tout l’espace inutilisé
d’Enginuity récupère les pistes sans enregistrements utilisateur
(uniquement les enregistrements zéro standard).
Remarque : cette fonction ne s’applique qu’aux volumes qui ont été
surprovisionnés au niveau du contrôleur Symmetrix. Les volumes
intégralement préalloués et marqués comme persistants ne peuvent
pas faire l’objet d’une récupération.
La récupération de l’espace nécessite que le volume soit rattaché
localement. Il est recommandé que le volume ait une VTOC indexée.
L’utilitaire TRU surveille uniquement les périphériques répertoriés
dans le relevé SCF.TRU.DEV.INCLUDE.LIST. Voici un exemple de
configuration des paramètres d’initialisation SCF de TRU :
SCF.TRU.DEV.INCLUDE.LIST=3E00-3E80 devices for monitoring
SCF.TRU.RECLAIM.SCRATCH.WAIT=100 1 sec wait
SCF.TRU.RECLAIM.STCNAME=EMCTRCLM
SCF.TRU.RECLAIM.TASK.LIMIT=5
SCF.TRU.RECLAIM.METHOD=3
L’exemple suivant illustre un périphérique thin (MF3E80) doté de
sept Datasets et d’une VTOC indexée.
112
La commande suivante vous permet d’afficher le thin pool et de
connaître le nombre de pistes utilisées et disponibles :
Si vous remplacez trois des Datasets du volume de périphériques
thin MF3E80, la liste des Datasets répertorie uniquement quatre
Datasets et la VTOC indexée.
Pour démarrer la récupération de l’espace à la demande des Datasets
supprimés, exécutez l’utilitaire afin d’effectuer la tâche RECLAIM
par lot.
113
L’utilitaire RECLAIM analyse l’espace disponible du volume et les
informations de session SDDF, puis met à jour les pistes vides. La
fonction Enginuity de récupération totale de l’espace démarre
ensuite. Elle détecte les pistes présentant un enregistrement zéro
standard (et aucun autre enregistrement) et renvoie ces pistes vers la
partie disponible du thin pool. Toute piste de cette partie ne présente
aucun enregistrement. Si un hôte essaie de lire une piste de
périphérique thin qui n’est pas attribuée à du stockage physique, une
image de piste factice ressemblant à une piste est créée. Elle est dotée
d’une adresse source et d’un enregistrement zéro.
Pour voir les résultats du processus de récupération de l’espace, vous
pouvez afficher le thin pool et observer les modifications apportées
au nombre de pistes utilisées et disponibles en utilisant la commande
suivante :
Remarque : lorsque vous utilisez ICKDSF pour effacer un volume
thin, la sortie SCRATCH SCF n’est pas invoquée et n’identifie donc
pas la libération de l’espace. Dans ce cas, exécutez l’utilitaire de
traitement par lot pour récupérer l’ensemble de l’espace du volume.
Fonction de récupération SRDF thick R1
Avec Enginuity 5876 (version de service Q4-2012) et Mainframe
Enablers (MFE) version 7.5, un nouveau processus de
récupération SRDF R1 s’ajoute à l’utilitaire TRU pour analyser tous
les périphériques CKD R1 et déterminer si le côté R2 (ou tout
périphérique SRDF en cascade) est un périphérique thin. Si un R1 est
connecté à un R2 thin, le R1 est surveillé et traité, même s’il s’agit
d’un périphérique thick. En outre, le démarrage de la tâche de
récupération totale de l’espace est transmis à tous les périphériques
thin en cascade.
Pour activer cette fonction, vous devez coder un nouveau paramètre
d’initialisation SCF comme suit :
SCF.TRU.THICKR1=YES (DEFAULT=YES)
114
Vous bénéficierez ainsi de la prise en charge des volumes R2 en aval,
même s’ils sont en cascade d’un volume R21. Les volumes R1 thin et
thick seront ainsi pris en charge. Les topologies SRDF multisite, en
cascade et simultanées sont toutes prises en charge. Tout
périphérique de ces topologies peut faire l’objet de récupérations
d’espace. En outre, les volumes R1 thick associés à des volumes
thin R2 en cascade prennent désormais en charge ces derniers.
Lors de l’analyse des périphériques thin, l’attribut PERSIST est
vérifié. Les périphériques PERSIST ne font pas l’objet d’un suivi et la
tâche de récupération totale de l’espace ne s’applique pas à eux. Si
tous les périphériques thin en aval sont dotés de l’attribut PERSIST et
que le volume R1 en local est un périphérique thick, celui-ci ne fait
l’objet d’aucune surveillance.
115
116
4
Hiérarchisation du
stockage
Ce chapitre présente la hiérarchisation du stockage dans les
environnements mainframe réalisée à l’aide des deux produits de
hiérarchisation du stockage des baies VMAX, FAST et FAST VP.
◆
◆
◆
◆
◆
◆
Introduction ......................................................................................
Concepts fondamentaux de FAST VP ...........................................
FAST VP et SMS (System Managed Storage) ...............................
FAST VP et HSM ..............................................................................
Gestion FAST VP ..............................................................................
Tier Advisor ......................................................................................
118
119
122
127
133
133
117
Introduction
Du fait que les volumes de données augmentent et que les disques
durs traditionnels offrent moins d’IOPS par Go, les entreprises se
voient contraintes d'utiliser un certain nombre de disques Flash pour
parvenir à respecter les contrats de niveau de service exigeants des
différentes entités qui les composent. Le défi consiste à optimiser la
hiérarchisation et l’utilisation des disques Flash en veillant à ce qu’ils
contiennent les données les plus actives. De plus, il est judicieux d’un
point de vue financier de stocker les données peu actives sur des
disques SATA, car ceux-ci permettent de réduire le coût total de
possession (TCO). La gestion manuelle de contrôleurs de stockage
dotés de différents types de disque est à la fois complexe et
chronophage. Un produit automatisant la hiérarchisation est
nécessaire pour qu’une telle configuration puisse fonctionner.
En 2009, EMC a commercialisé la première solution de
hiérarchisation du stockage, nommée FAST (Fully Automated
Storage Tiering) FAST permettait de déplacer des volumes
Symmetrix entiers entre différents niveaux afin d’équilibrer les
charges de travail et de tirer le meilleur parti du sous-système de
stockage. FAST constituait la première étape vers une solution plus
complète, commercialisée en mai 2012 pour les périphériques CKD,
permettant de déplacer les données en utilisant une granularité de
plus petite taille. Cette nouvelle solution s’appelle FAST VP (Fully
Automated Storage Tiering for Virtual Pools). Elle a été introduite
pour les périphériques CKD dotés d’Enginuity 5876 et a été proposée
pour les environnements de systèmes ouverts pendant 18 mois avant
d’être introduite sur le marché mainframe.
FAST VP est un produit de hiérarchisation automatisée qui gère les
niveaux de stockage au sein d’une baie Symmetrix. Son objectif est de
veiller à ce que les données les plus exigeantes et les plus consultées
soient stockées sur les unités de disque offrant les meilleures
performances, et de déplacer les données moins consultées vers des
médias plus économiques.
Concrètement, FAST VP place les bonnes données au bon endroit et
au bon moment en déplaçant automatiquement et sans interruption
des ensembles de 10 groupes de pistes (6,8 Mo) entre les différents
niveaux de stockage au niveau du sous-volume, pour répondre aux
fluctuations des charges de travail. Il repose sur le provisionnement
virtuel des volumes de la baie VMAX et en dépend.
118
Le reste de ce chapitre est consacré à FAST VP, le successeur de FAST,
produit sorti en 2009 et basé sur les volumes entiers.
Avantages de FAST VP
FAST VP comble un manque dont souffrait la gestion du stockage
mainframe depuis des décennies : une solution capable de gérer les
performances des données de façon proactive et automatique.
FAST VP atteint cet objectif de manière efficace en déplaçant les
données par petites unités en fonction de la charge de travail et en
optimisant l’utilisation des ressources des unités de contrôle.
Un tel niveau d’efficacité dans la gestion des performances des
sous-volumes et, plus important encore, des sous-Datasets, n’avait
jamais été atteint auparavant. Cela constitue une véritable révolution
en fournissant la première solution de gestion du stockage vraiment
autonome.
FAST VP aide également les utilisateurs à réduire les coûts liés à leurs
périphériques DASD en leur permettant d’exploiter des disques
SATA de très grande capacité pour les données rarement utilisées,
sans nécessiter une gestion intensive des performances de la part des
administrateurs de stockage.
Le plus impressionnant, c’est que FAST VP offre tous ces avantages
sans utiliser aucune des ressources de l’hôte.
Concepts fondamentaux de FAST VP
Trois nouveaux concepts sont à la base de FAST VP :
Niveau FAST
Un niveau FAST est un groupe pouvant inclure jusqu'à quatre pools
virtuels dotés de la même technologie de disque et de la même
protection RAID. Au plus, trois niveaux CKD sont autorisés par baie.
Groupe de stockage FAST
Un groupe de stockage FAST est un ensemble de volumes thin
représentant une application ou une charge de travail. Ils doivent
reposer sur les définitions des groupes de stockage SMS dans un
environnement z/OS.
Concepts fondamentaux de FAST VP
119
Règles FAST
Les règles FAST définissent la capacité d’un groupe de stockage (en
pourcentage) qui peut être déplacée vers chaque niveau. Les
pourcentages définis par ces règles doivent totaliser au moins 100 %
mais peuvent dépasser cette valeur. Chaque groupe de stockage
FAST est associé à une définition de règles FAST spécifique.
La Figure 20 décrit les relations entre les fonctions VP et FAST VP au
sein de la baie VMAX.
Optimization
R53_EFD_200GB
100%
200 GB EFD
RAID 5 (3+1)
100%
VP_ProdApp1
100%
R1_FC_450GB
Custom
450 GB 15K FC
RAID 1
10%
20%
70%
VP_ProdApp2
Storage groups
Figure 20
FAST policies
R614_SATA_1TB
1 TB SATA
RAID 6 (14+2)
FAST tiers
Provisionnement virtuel et FAST VP
Les périphériques thin sont regroupés dans des groupes de stockage.
D’ordinaire, chaque groupe de stockage est mappé sur une ou
plusieurs applications ayant des caractéristiques de performances
similaires. Des règles sont ensuite attribuées au groupe de stockage
afin de déterminer la quantité de chaque niveau de stockage que
l’application est autorisée à utiliser.La Figure 20 montre deux
applications, VP_ProdApp1 et VP_ProdApp2, soumises chacune à
des règles différentes :
VP_ProdApp1
Cette application est dotée d'une règle nommée Optimisation, qui
permet à son stockage d’occuper jusqu’à 100 % des trois niveaux
attribués. Autrement dit, l’emplacement du stockage de
VP_ProdApp1 n’est soumis à aucune restriction.
VP_ProdApp2
Cette application est dotée d'une règle nommée Personnalisée, qui
impose une quantité de stockage précise à chaque niveau. Il s'agit de
la règle la plus restrictive. La somme totale des attributions autorisées
doit atteindre 100 %.
120
Périodes FAST VP
FAST VP collecte des statistiques sur l’activité des périphériques afin
de déterminer où les données doivent être déplacées. Deux types de
périodes sont utilisés pour déterminer quand les statistiques sont
collectées et quand les données sont déplacées d’un niveau à un
autre.
Périodes de collecte des données
Les données de performances pour FAST VP ne doivent être
collectées que lorsque la charge de travail présente des
caractéristiques normales. Vous pouvez spécifier les périodes de
collecte des données ainsi que des périodes pendant lesquelles les
données ne doivent pas être collectées. Par exemple, si vous exécutez
tous les soirs des traitements par lot sur vos données et que vous ne
voulez pas que ces opérations influencent les décisions prises par
FAST, ne collectez pas les statistiques à ce moment.
Périodes de déplacement des données
Vous devez définir les périodes au cours desquelles les données
peuvent être déplacées entre les niveaux. Le déplacement des
données peut reposer sur les performances ou sur des règles. Dans
tous les cas, il exerce une charge supplémentaire sur la baie VMAX. Il
doit donc être effectué à des moments où l’application n’est pas trop
sollicitée. Notez que les périodes de déplacement s’appliquent à
l’ensemble de la baie VMAX. Vous devez donc les coordonner avec
les autres applications placées sous le contrôle de FAST VP.
Périodes FAST VP
121
FAST VP et SMS (System Managed Storage)
Cette section aborde le positionnement et les interactions de FAST VP
dans un environnement z/OS exécutant l’application IBM de
stockage géré par le système (SMS). Elle présente brièvement SMS
(également appelé DFSMS) et décrit en quoi les services SMS et
FAST VP sont complémentaires, offrant des niveaux supérieurs de
gestion automatisée du stockage et des performances de stockage
accrues dans l’environnement d’exploitation z/OS.
System Managed Storage
IBM a introduit System Managed Storage à la fin des années 1980
dans l’environnement MVS afin d’offrir aux utilisateurs des fonctions
de contrôle automatisé de la gestion du stockage. Il vise à améliorer
l’utilisation et la gestion du cycle de vie des données sur toute la
hiérarchie des types de périphérique de stockage externe (DASD, sur
bande, optiques) rattachés au mainframe. SMS est utilisé pour
hiérarchiser les données en classes et déterminer leur
positionnement. En se basant sur les classifications attribuées par
SMS au moment de l’allocation des Datasets, le composant HSM
(Hierarchical Storage Manager) est utilisé pour gérer les données une
fois qu’elles ont été attribuées à un DASD (c.-à-d. placées dessus).
SMS utilise quatre concepts de base pour hiérarchiser les données et
déterminer leur positionnement. Ces concepts sont les suivants :
Classe de données
Définit un modèle de caractéristiques d’allocation des Datasets,
notamment l’espace requis, la structure logique et la date
d’expiration.
Classe de gestion
Définit les exigences en matière de sauvegarde, de migration et de
rétention des Datasets. Les actions effectuées par HSM sont
contrôlées par la classe de gestion attribuée.
Classe de stockage
Définit les exigences en matière de performances et de disponibilité
des Datasets. L’attribution d’une classe de stockage définit un Dataset
comme étant géré par SMS.
122
Groupe de stockage
Définit un groupe logique de volumes à gérer en tant qu’entité
unique, par exemple selon le type d’application ou les
caractéristiques du périphérique. SMS sélectionne un groupe de
stockage qui servira d’emplacement pour allouer un nouveau
Dataset.
Ces classes sont attribuées lors de l’allocation initiale du Dataset (ou
au moment du rappel suivant la migration vers un autre niveau dans
la hiérarchie de stockage) par une fonction de DFSM appelée routines
ACS (Automatic Class Selection).
DFSMS, associé à son composant de gestion hiérarchique du stockage
(DFSMShsm), veille à l’utilisation efficace de l’espace disque via des
paramètres intégrés à la classe de gestion et au groupe de stockage
qui contrôlent le positionnement des Datasets, l’âge des migrations et
les seuils d’utilisation de l’espace. Le principal avantage de SMS
réside dans sa gestion active des ressources des disques et des bandes
de l’environnement.
Si SMS a toujours fait preuve d’une grande efficacité en matière de
gestion de l’espace, il n’assure aucune gestion active des
performances. Les besoins en performances d’un Dataset peuvent
être définis par sa classe de données, mais ces informations ne sont
utilisées qu’au moment de l’allocation pour déterminer sur quels
volumes le Dataset doit être placé. Une fois qu’il a été alloué, SMS
n'effectue aucune gestion des performances au niveau du Dataset ou
du volume. Le problème de cette approche réside dans le fait que les
besoins en performances des Datasets ne sont pas figés. Les besoins
réels en performances varient, car le Dataset passe par différentes
étapes : allocation initiale, formatage, activités de lecture et d’écriture,
et enfin déclin puis inactivité.
FAST VP améliore les fonctions de SMS
FAST VP étend les capacités de SMS en ajoutant la gestion des
performances à un niveau très granulaire. Les données étant
déplacées en petites unités non soumises aux limites des Datasets, les
zones très actives ou peu actives d’un volume peuvent être promues
ou dégradées entre les niveaux, selon les schémas d'utilisation réels
d’une charge de travail.
123
Cela signifie que les clients peuvent utiliser plus efficacement les
disques Flash et intégrer la technologie SATA dans leur hiérarchie de
stockage mainframe, sans craindre de pénaliser les performances ou
de surcharger leurs administrateurs de stockage en leur confiant la
surveillance et le positionnement manuels des données.
Implémenter FAST VP avec SMS
FAST VP peut être intégré dans un environnement SMS existant de
deux manières : en adoptant une méthode de tolérance passive ou
une méthode d’exploitation active.
La première étape dans l’intégration de FAST VP est de définir les
groupes de stockage FAST selon les définitions des groupes de
stockage SMS.
Cette opération peut être effectuée en utilisant EMC z/OS Storage
Manager (EzSM), qui obtient les définitions de groupes de stockage
SMS par le numéro de périphérique Symmetrix en utilisant ses
interfaces avec Symmetrix Control Facility et SMS. Unisphere utilise
ensuite les informations renvoyées par EzSM pour définir les groupes
de stockage FAST dans le contrôleur Symmetrix.
Notez que la connexion entre Unisphere et le contrôleur Symmetrix
peut s’effectuer de trois façons :
1. En direct via le SAN Fibre Channel
2. En interne au sous-système Symmetrix, en exécutant Unisphere
sur le processeur de service Symmetrix
3. Par IP à un hôte z/OS exécutant EMC Solutions Enabler sous
UNIX System Services et rattaché au sous-système Symmetrix via
FICON
124
Méthode de tolérance
Cette méthode repose sur le mappage direct des groupes de stockage
FAST avec des niveaux FAST contenant des pools Virtual
Provisioning (VP) dans lesquels les données existent actuellement
dans la configuration préalable à la mise en œuvre de FAST VP. Il
s’agit de l’approche la plus prudente, dans laquelle les objectifs en
termes de gestion des performances par FAST VP sont atteints
progressivement au fil du temps en imposant le déplacement des
données par le biais de règles FAST VP personnalisées. Un exemple
de cette méthode est illustré dans la Figure 21. Avec les règles
initiales, FAST n’effectue aucun déplacement des données, ce qui est
similaire au concept d’espace garanti de SMS. Les règles FAST VP
personnalisées peuvent ensuite être modifiées de façon prudente au
fil du temps pour permettre un déplacement des données plus
important afin d’atteindre les objectifs de performances souhaités.
Par exemple, s’il existe un groupe SMS contenant tous les disques
Flash, ce groupe peut être mappé avec un groupe de stockage FAST
doté de règles FAST appliquées uniquement aux disques Flash. Cette
situation est illustrée dans la Figure 21 par VP_ProdApp1.
Notez que, dans le cas des disques Flash, cette méthode devrait
obligatoirement être employée pour diriger les allocations vers ces
disques, car les périphériques thin ne signalent pas qu’ils sont
mappés avec des disques Flash. C’était également le cas avec les
périphériques thick dans les anciens modèles de baie Symmetrix.
Optimization
R53_EFD_200GB
100%
200 GB EFD
RAID 5 (3+1)
0%
VP_ProdApp1
0%
R1_FC_450GB
Custom
450 GB 15K FC
RAID 1
0%
R614_SATA_1TB
100%
VP_ProdApp2
Storage groups
Figure 21
1 TB SATA
RAID 6 (14+2)
0%
FAST policies
FAST tiers
FAST et SMS - Méthode de tolérance
125
Méthode d’exploitation
Cette méthode permet d’exploiter pleinement FAST VP en activant
des règles d’optimisation pour tous les groupes de stockage FAST VP,
comme cela est illustré dans la Figure 22. Avec cette méthode, les
allocations ne sont pas dirigées spécifiquement vers les disques Flash
en utilisant SMS comme c’était le cas dans l’exemple de la Figure 21.
Les données exigeant les performances des disques Flash sont
déplacées vers le niveau Flash par FAST VP, sans tenir compte de leur
positionnement initial par SMS. Les données présentant des besoins
en performances inférieurs sont déplacées vers les niveaux FC ou
SATA.
Optimization
R53_EFD_200GB
100%
200 GB EFD
RAID 5 (3+1)
100%
VP_ProdApp1
100%
R1_FC_450GB
Optimization
450 GB 15K FC
RAID 1
100%
100%
100%
VP_ProdApp2
Storage groups
Figure 22
FAST policies
R614_SATA_1TB
1 TB SATA
RAID 6 (14+2)
FAST tiers
FAST VP et SMS - Méthode d’exploitation
Le point de départ de la méthode d’exploitation consiste en un
alignement des volumes de chaque groupe de stockage SMS sur des
périphériques thin situés à la limite d’un pool virtuel. Par exemple,
un groupe de stockage SMS créé pour une application DB2 hautes
performances serait implémenté en utilisant uniquement des
volumes thin rattachés à un pool EFD. De la même façon, les
utilisateurs mapperaient leurs autres groupes de stockage SMS avec
des périphériques thin rattachés à des pools virtuels FC ou SATA en
fonction de leur appréciation des besoins métiers. Les groupes de
stockage FAST sont ensuite créés selon ces définitions des groupes
SMS.
L’association de ces groupes de stockage FAST aux niveaux de
stockage FAST via des règles d’optimisation (comme dans la
Figure 22) permet à FAST d’exploiter le stockage de tous les niveaux
pour satisfaire les besoins en capacité de chaque groupe de stockage
FAST. Ensuite, FAST VP déplace les données de façon optimale vers
le niveau adéquat en fonction des besoins en performances.
126
FAST VP et HSM
HSM est le gestionnaire de stockage hiérarchique utilisé sous z/OS,
OS/390, MVS, etc. Il existe depuis près de trente ans et dispose d’une
grande base de clientèle. HSM gère la sauvegarde et la migration des
Datasets en se basant sur des règles et de manière totalement
transparente pour l’utilisateur. Son objectif global est de gérer de
nombreuses technologies de stockage de manière aussi économique
que possible.
HSM est chargé de gérer le déplacement des données pour les
opérations de sauvegarde, d’archivage et de récupération des
Datasets en utilisant les différentes couches de médias à sa
disposition. Lors des déploiements initiaux de HSM, les Datasets
étaient déplacés entre des disques haute vitesse et des périphériques
plus lents (disques optiques et bandes) pour essayer de réduire le
nombre de disques haute vitesse nécessaires dans un environnement
donné. Les utilisateurs étaient confrontés à des temps de réponse plus
longs lorsque les données étaient récupérées à partir des médias les
plus lents. De façon conceptuelle, HSM peut être considéré comme le
premier gestionnaire de stockage hiérarchisé automatisé, car il
assurait la gestion du cycle de vie des données dans l’entreprise.
Globalement, les fonctionnalités de HSM se répartissent entre la
gestion de l’espace et la gestion de la disponibilité. Ces
fonctionnalités sont décrites dans les sections suivantes.
Gestion de l’espace par HSM
HSM gère l’espace disque en accomplissant les opérations suivantes :
◆
Il fait migrer les Datasets non référencés (ceux qui n’ont pas été
ouverts pendant un laps de temps défini) des volumes primaires
vers les volumes ML1, où ils sont compressés. En cas d’accès aux
données migrées, HSM intercepte la demande et la place en
attente, le temps de rappeler les données migrées à partir des
volumes ML1 et de les replacer sur les volumes primaires.
Simultanément, HSM décompresse les données migrées. Ce
processus est nommé RECALL et peut être très long pour les
Datasets de grande taille. Les Datasets compressés qui ne sont
pas rappelés et résident sur les volumes ML1 finiront par être
migrés vers les volumes ML2, généralement un type quelconque
de stockage sur bande. Dans certaines installations, ML1 est
entièrement contourné et HSM déplace les données directement
des volumes primaires vers ML2. C’est souvent le cas lorsque
ML2 se trouve sur une bande virtuelle (bande sur disque).
FAST VP et HSM
127
◆
Il supprime les Datasets arrivés à expiration.
◆
Il supprime les Datasets temporaires.
◆
Il libère l’espace alloué mais non utilisé dans les Datasets.
La gestion de l’espace primaire est habituellement effectuée
quotidiennement pour maintenir le taux d’occupation en dessous
d’un seuil prédéfini relativement bas, mais elle peut également être
exécutée toutes les heures pour des volumes ou des groupes de
stockage spécifiques. Les valeurs contrôlant la gestion de l’espace
sont définies par la classe de gestion et le groupe de stockage pour les
environnements gérés par SMS.
HSM effectue également une gestion de l’espace secondaire sur ML1
et ML2 de façon quotidienne pour déplacer les données de ML1 vers
ML2 et supprimer les Datasets migrés qui sont arrivés à expiration.
Il est important de noter que HSM gère deux domaines d’espace. Le
premier domaine correspond à l’espace sur le stockage primaire, qui
fait l’objet d’un suivi au niveau de la VTOC de chaque volume. Le
second domaine se trouve sur le stockage secondaire et fait l’objet
d’un suivi via les Datasets de contrôle de HSM.
HSM interroge la VTOC des volumes qu’il gère, et cherche les
Datasets qui n’ont pas été référencés pendant un laps de temps défini.
Le programmeur du système détermine pendant combien de temps
les données peuvent rester non référencées avant d’être migrées vers
ML1 puis vers ML2. La date de référence de la VTOC est mise à jour
lorsqu’un Dataset est ouvert, même si aucune donnée n’est lue
dedans. Les caractéristiques de performances et d’accès du Dataset
ne sont pas pertinentes pour HSM, car il s’occupe uniquement de la
gestion de la capacité.
Les bases de données de production DB2 et IMS ont rarement leurs
Datasets sous le contrôle de HSM, car le délai de rappel d’un Dataset
est prohibitive lorsque OLTP (Online Transaction Processing) est
utilisé. Ainsi, les données de production contrôlées par des systèmes
DBMS ne sont en réalité pas gérées par HSM. En revanche, les bases
de données de test et d’assurance qualité sont souvent contrôlées par
HSM.
128
Gestion de la disponibilité par HSM
L’objectif principal de la gestion de la disponibilité assurée par HSM
est de veiller à ce qu’une copie récente d’un Dataset soit disponible
au cas où la version actuelle ne le serait pas. Pour garantir cela, la
gestion de la disponibilité assurée par HSM exécute
automatiquement et régulièrement des opérations qui (1) copient
tous les Datasets situés sur des volumes DASD vers des volumes de
bande et (2) copient les Datasets modifiés situés sur des volumes
DASD soit vers d’autres volumes DASD, soit des volumes de bande.
En copiant les Datasets, DFSMShsm réduit l’espace qu’ils occupent
sur le volume de sauvegarde. La gestion de la disponibilité assurée
par HSM effectue les fonctions suivantes :
◆
Regroupement de la sauvegarde et de la restauration
◆
Vidage physique automatique du volume complet
◆
Sauvegarde incrémentielle automatique
◆
Sauvegarde automatique des Datasets de contrôle
◆
Vidage et sauvegarde des commandes
◆
Restauration des commandes
◆
Sauvegarde pour reprise après sinistre
◆
Expiration des versions de sauvegarde
◆
Sauvegarde et restauration rapides par réplication
Les paramètres de la fonction de gestion de la disponibilité sont
définis dans les classes de gestion et de groupe de stockage de
l’environnement SMS.
HSM peut également effectuer des sauvegardes de DB2. Depuis
DB2 V8 et DFSMS 1.5, il fait partie intégrante du système de
restauration à un point dans le temps pour DB2. Dans ce cadre, il
effectue des copies de volumes complets (en utilisant FlashCopy)
pour le compte de DB2 et inscrit ces copies dans le BCDS (Backup
Control dataset). Les versions 9 et 10 de DB2 peuvent indiquer à
HSM de prendre ces copies de volumes et de les vider sur bande.
FAST VP et HSM
129
Limitations de HSM
Les objectifs de HSM n’ont jamais été d’optimiser les performances
mais uniquement de réduire la consommation d’espace et les coûts,
de garantir la disponibilité, et d’essayer de libérer l’espace disque le
plus coûteux en déplaçant les données vers des médias plus
économiques. Cela fonctionne bien pour les données de test et de
développement, qui peuvent rester inactives pendant de longues
périodes et pour lesquelles le temps de réponse n’est pas un aspect
critique. En revanche, cela fonctionne mal dans les environnements
OLTP pour lesquels les temps de réponse doivent répondre à des
exigences de niveau de service spécifiques. Le processus RECALL
peut être très lent, et les utilisateurs en ligne ne veulent pas être
confrontés à ce genre de délais.
La granularité de HSM se situe au niveau du Dataset et il est
incapable de déplacer les parties inactives d’un Dataset vers un
niveau de stockage plus économique. Pour HSM, tous les blocs d’un
Dataset sont équivalents du point de vue de la gestion de l’espace.
Lorsqu’un RECALL est nécessaire, HSM doit rappeler l’ensemble du
Dataset au moment de son ouverture, même si l’utilisateur n’a besoin
de lire qu’un octet de données. Plus le Dataset est gros, plus le
processus RECALL est long.
Comparaison entre FAST VP et HSM
Comme HSM, FAST VP a pour objectif de réduire les coûts liés au
stockage sur disque, mais il est important de comprendre que
FAST VP peut être utilisé pour gérer toutes les données utilisées (et
non utilisées) par l’hôte z/OS. Ainsi, il peut avoir un impact positif
sur les performances et les coûts opérationnels à l’échelle du système
entier. Du fait que FAST VP peut déplacer les données peu utilisées
vers des disques SATA et les données très utilisées vers des disques
Flash, ses fonctionnalités et celles de HSM se chevauchent
partiellement. FAST VP gère les performances des données au sein
d’une baie, alors que HSM gère la consommation de données sur le
stockage primaire, leur disponibilité et le coût du stockage.
De plus, les déplacements des données entre les niveaux, qui sont
déterminés par les performances, sont effectués par la baie VMAX en
n’utilisant aucun cycle CPU et sans accroître les E/S hôtes. FAST VP
peut être considéré comme une solution de remplacement partielle
pour la fonctionnalité de hiérarchisation de HSM, avec une approche
130
plus rapide et plus robuste, et des fonctionnalités supérieures à celles
qu’offre HSM en matière de gestion de l’espace. La différence, c’est
que FAST VP implémente la hiérarchisation au sein du stockage
primaire.
FAST VP permet aux utilisateurs d’implémenter des volumes
primaires de plus grande taille avec des VTOC de plus grande taille,
ce qui peut réduire la fréquence des opérations de gestion de l’espace
effectuées par HSM ainsi que sa consommation CPU liée au
déplacement des données. Cela se traduit par une amélioration des
performances et une baisse des ressources consommées par HSM.
La Figure 23 décrit la nature des chevauchements fonctionnels entre
FAST VP et HSM.
FAST VP
Performance
management
Figure 23
HSM
Space
management
Availability
management
Chevauchements fonctionnels entre HSM et FAST VP
Comme les fonctionnalités de FAST VP et celles de HSM ne se
chevauchent que partiellement, ce dernier ne peut être intégralement
remplacé par FAST VP. Il reste nécessaire de déplacer de manière
silencieuse les données peu utilisées situées sur les volumes
primaires vers des bandes (ML2), même si les Datasets résident (en
totalité ou en partie) sur des disques SATA. L’espace SATA peut
ensuite être utilisé pour d’autres données peu utilisées. En fait, ce
type d’implémentation est structurellement comparable au fait
d’augmenter l’espace du volume primaire, normalement réservé aux
disques SATA les plus rapides, et de laisser FAST VP choisir sur
quelle technologie de disque les données du volume primaire doivent
résider. HSM peut toujours être utilisé pour gérer cette couche de
volumes primaires étendus, comme il l’a toujours fait. Il s’agit d’une
synergie naturelle entre les deux produits.
FAST VP et HSM
131
Avantages de FAST VP
Comme FAST VP déplace les données au niveau des sous-volumes, et
surtout au niveau des sous-Datasets, on peut l’utiliser pour les
données actives en cours d’utilisation par des applications en ligne. Il
n’a pas besoin d’attendre que le Dataset complet ne soit pas référencé
pendant une durée spécifique. Ainsi, il peut offrir une utilisation
optimale de chaque niveau en veillant ce que les données les plus
exigeantes se trouvent sur le niveau offrant le meilleur niveau de
service. De plus, FAST VP migre les données d’un niveau à l’autre au
sein même de la baie, et n’utilise donc pas de coûteux cycles de CPU
et ne génère pas d’E/S sur les canaux qui pourraient concurrencer
d’autres E/S de production.
Recommandations
Lors du déploiement des solutions FAST VP for CKD dans les
environnements où HSM est utilisé, EMC propose les
recommandations suivantes :
◆
Augmentez la taille de l’espace sur le volume primaire en
augmentant la capacité utilisée pour prendre en charge cet espace
avec des disques SATA. Les VTOC et les index VTOC doivent
être correctement dimensionnés pour les adapter à la taille
supérieure du volume primaire.
◆
Utilisez des règles de migration HSM moins agressives et
autorisez FAST VP à gérer la hiérarchisation des données au sein
de la baie.
Les recommandations EMC offrent les avantages suivants :
132
◆
Une utilisation plus efficace de chaque niveau grâce à une
approche plus granulaire de la hiérarchisation
◆
Un meilleur temps de réponse sur les disques SATA lorsqu’on y
accède depuis cet emplacement plutôt qu’en exécutant une
opération RECALL
◆
Plus besoin de déplacer les données des disques SATA lorsqu’on
y accède depuis cet emplacement
◆
Moins de consommation en termes de CPU et d’E/S grâce à la
réduction du nombre de déplacements et d’opérations RECALL
Gestion FAST VP
La gestion des configurations FAST VP sur mainframe et sur
systèmes ouverts s’effectue par le biais d’une interface utilisateur
unique appelée Unisphere for VMAX. Unisphere est utilisé pour :
◆
Définir les niveaux FAST VP
◆
Définir les règles
◆
Définir les périodes
◆
Activer FAST VP
L’utilisation de Unisphere pour exploiter ces fonctions est décrite
dans la documentation consacrée à Unisphere et dépasse le cadre de
ce TechBook.
Remarque : Mainframe Enablers peut être utilisé pour configurer les thin
pools afin qu’ils soient gérés par FAST VP.
Tier Advisor
Tier Advisor est un outil conçu pour évaluer les performances et les
coûts générés utilisant différentes technologies de disque au sein
d’un sous-système Symmetrix. Il vise à faciliter les prises de décision
en matière d’ajout de stockage, de mise à niveau du stockage et de
remplacement du stockage existant pour optimiser les performances
et les coûts dans un environnement de stockage donné. Il est
particulièrement utile pour anticiper la configuration d’une
implémentation quelconque de FAST ou de FAST VP. Il est
programmé de manière à estimer les performances obtenues en
positionnant correctement les bonnes données sur le bon niveau et au
bon moment. Les entrées et les sorties de Tier Advisor sont illustrées
dans la Figure 24.
Gestion FAST VP
133
Workload
characteristics
Capacity
User defined
Storage Policies
Tier Advisor Algorithms
Performance Measures
(response time, throughput,
cost, power consumption)
ICO-IMG-000958
Figure 24
Modèle de Tier Advisor
Une fois la configuration souhaitée terminée, l’utilitaire EMC
SymmMerge peut être utilisé pour élaborer une planification de
configuration détaillée qui attribue les périphériques logiques aux
disques physiques afin d’anticiper les processus de migration.
Attribuer des technologies de disque similaires à un niveau donné
permet sans aucun doute d’optimiser la définition des différents
niveaux pour FAST. Par conséquent, les niveaux peuvent être
configurés en tant que disques SATA, Fibre Channel (FC) et Flash ,
tous au sein du même sous-système Symmetrix.
134
5
Gestion du stockage
Ce chapitre présente les solutions EMC de gestion du stockage
mainframe.
◆
◆
◆
◆
EMC z/OS Storage Manager..........................................................
Symmetrix Management Console .................................................
Symmetrix Performance Analyzer (SPA) .....................................
Unisphere for VMAX.......................................................................
Gestion du stockage
136
141
143
146
135
Gestion du stockage
EMC z/OS Storage Manager
Les entreprises qui utilisent le mainframe sont souvent dotées
d’environnements de stockage complexes couvrant plusieurs unités
de contrôle du stockage et plusieurs sites géographiques. Les
environnements de stockage étant de plus en plus complexes, les
équipes gérant le stockage ne sont plus uniquement préoccupées par
le positionnement des données ou le débit d’E/S. Elles s’intéressent
également au suivi, à la gestion et à surveillance de leur
environnement de stockage. Bénéficier d’un suivi des changements
qui interviennent au sein de l’environnement peut souvent
contribuer à résoudre les problèmes.
EMC z/OS Storage Manager (EzSM) simplifie la gestion des
ressources.
EzSM peut effectuer les opérations suivantes :
◆
Surveiller le stockage mainframe des systèmes Symmetrix et
générer des rapports
◆
Effectuer des opérations SRDF, TimeFinder/Mirror et
TimeFinder/Snap
◆
Effectuer des opérations GNS (Group Name Services).
Surveiller le stockage Symmetrix
EzSM effectue la surveillance et le reporting du stockage mainframe
des systèmes Symmetrix et des produits logiciels associés dans la
perspective du système d’exploitation z/OS. EzSM offre aux
responsables du stockage mainframe et aux équipes opérationnelles
une représentation du stockage flexible et orientée z/OS qui leur
permet de visualiser les informations relatives au système Symmetrix
ainsi que les données de gestion du stockage z/OS dans une interface
unifiée et conviviale.La Figure 25, page 137 illustre l’écran du menu
principal d’EzSM.
136
Gestion du stockage
Figure 25
Menu principal d’EzSM
Avec EzSM, vous pouvez découvrir et surveiller les volumes présents
dans les sous-systèmes de stockage Symmetrix, configurer des alertes
pour les volumes, obtenir un résumé des informations de
configuration Symmetrix, etc. EzSM utilise la messagerie z/OS
standard (ce qui permet d’utiliser les outils d’automatisation des
clients pour filtrer les messages EzSM), utilise l’outil SMP/E pour
l’installation et enregistre les activités des utilisateurs. Comme il
s’exécute sur l’hôte mainframe, vous pouvez facilement tirer parti de
vos produits de sécurité mainframe standard (RACF, ACF2 ou
TopSecret) pour contrôler l’accès à EzSM.
EzSM vous permet de déterminer les éléments suivants :
◆
La répartition logique des volumes dans un sous-système de
stockage Symmetrix (hypervolumes)
◆
Le type de protection de chaque hypervolume Symmetrix (mise
en miroir, SRDF, RAID, etc.)
137
Gestion du stockage
◆
Les identifiants de groupes SRDF actuels d’un ou plusieurs
sous-systèmes de stockage Symmetrix
EzSM peut également vous être utile pour :
◆
DFSMS (Data Facility Storage Management Subsystem), appelé
SMS dans ce TechBook
◆
DFSMShsm (Data Facility Storage Management Subsystem
Hierarchical Storage Management), appelé HSM dans ce
TechBook
Effectuer des opérations SRDF et TimeFinder
EzSM peut servir à définir des groupes SRDF (en local et à distance),
à créer et supprimer des paires, à définir des attributs et à surveiller
l’état. Les options de gestion des groupes RDF sont illustrées à la
Figure 26.
Figure 26
138
Options de gestion des groupes SRDF
Gestion du stockage
EzSM exécute les fonctions TimeFinder/Mirror avec les volumes
standard et BCV (Business Continuance Volumes). Via l’interface
d’EzSM, vous pouvez effectuer des opérations TimeFinder/Mirror
standard comme :
◆
Émettre une requête
◆
Définir des paires
◆
Rétablir des paires
◆
Séparer des paires
Remarque : Le Guide produit de TimeFinder/Mirror pour z/OS fournit
davantage d’informations sur ces opérations.
Vous pouvez également surveiller les informations relatives à l’état
des périphériques SAVE, des périphériques virtuels et des Delta Set
Extensions dans les sous-systèmes de stockage Symmetrix.
Remarque : Le Guide produit d’EMC ResourcePak Base pour z/OS fournit
davantage d’informations sur les périphériques SAVE, les périphériques
virtuels et les Delta Set Extensions.
EzSM vous permet également d’effectuer des opérations
TimeFinder/Snap comme :
◆
Activate
◆
Clean up extent track
◆
Configure BCV devices
◆
Configure pool
◆
Define global parameters
◆
Define group
◆
Define source volume
◆
Delete group
◆
End group
◆
Query: Dataset, global, group, virtual device, volume
◆
Restore volume
◆
Snap dataset
◆
Snap volume
◆
Stop snap dataset
◆
Stop snap volume
139
Gestion du stockage
Effectuer des opérations GNS (Group Name Services).
GNS (Group Name Services) est le mécanisme Symmetrix de partage
de définition de groupe qui vous permet de définir un groupe de
périphériques une seule fois, à un endroit donné, puis d’utiliser cette
définition avec de multiples produits EMC sur différentes
plates-formes.
Remarque : Le Guide produit d’EMC ResourcePak Base pour z/OS fournit plus
d’informations sur GNS et ses fonctionnalités.
Avec EzSM, vous pouvez notamment effectuer les opérations GNS
suivantes :
◆
Définir de nouveaux groupes GNS
◆
Renommer des groupes GNS existants
◆
Supprimer des groupes GNS existants
◆
Afficher les périphériques appartenant à un groupe GNS
◆
Ajouter des périphériques à un groupe GNS
◆
Supprimer (retirer) des périphériques d’un groupe GNS
Principaux avantages
EzSM offre notamment les avantages suivants :
Gestion simplifiée des ressources : EzSM permet de gérer les
ressources de plusieurs LPAR et baies de stockage depuis un
emplacement unique.
Réduction du coût total de possession (TCO) : l’interface familière
d’EzSM permet d’utiliser les ressources de façon plus efficace.
Gestion proactive du stockage : EzSM intègre des outils et des alertes
permettant de planifier intelligemment les ressources de stockage. Il
est possible de définir des seuils pour l’espace alloué aux volumes de
stockage afin d’être averti en temps utile lorsque les volumes sont
presque saturés. Cela permet d’éviter les problèmes de saturation
avant qu’ils ne surviennent et d’éviter ainsi toute interruption de
service.
Internationalisation : EzSM fournit un code d’internationalisation et
est prêt à être localisé.
140
Gestion du stockage
Mise en œuvre de la sécurité : EzSM prend en charge la fonction
d’authentification SAF (System Authorization Facility) pour gérer
l’accès des utilisateurs aux installations et aux données système. Cela
permet d’implémenter les différents niveaux de sécurité attribués aux
utilisateurs dans le cadre de l’automatisation z/OS standard prise en
charge par EzSM. Les messages générés par les programmes peuvent
être interceptés et exploités par les modules d’automatisation
existants.
Symmetrix Management Console
Symmetrix Management Console (SMC) est une interface Web
intuitive qui permet de découvrir, surveiller, configurer et contrôler
les baies Symmetrix. SMC fournit une interface Web permettant
d’effectuer bon nombre d’opérations d’interface de ligne de
commande (CLI) de Solutions Enabler, notamment :
◆
Gestion des accès
◆
Gestion de la configuration
◆
Gestion de la réplication
◆
Surveillance
◆
Alertes
Une seule instance de SMC peut visualiser et gérer les sous-systèmes
Symmetrix visibles par l’instance d'EMC Solutions Enabler qu'utilise
SMC.
Fonctions
SMC peut être utilisé pour effectuer les opérations quotidiennes d’un
sous-système Symmetrix. Ces opérations sont notamment les
suivantes :
Découverte initiale du système : les demandes d’e-discovery
permettent d’identifier les éléments standard comme les baies, les
disques logiques Symmetrix et les disques physiques.
Symmetrix Management Console
141
Gestion du stockage
Configuration : création de périphérique, duplication de
périphérique avec des modèles simples, création de
métapériphérique, configuration de périphérique, mappage et
masquage (toutes ces opérations s’appliquent aux disques CKD et
FBA). Surveillance des alertes et gestion de la réplication des
solutions SRDF et TimeFinder.
Surveillance de la réplication : surveillance de l’état de SRDF/A, de
l’état des périphériques et de l’état des ressources par groupe de
périphériques. Les administrateurs peuvent surveiller les indicateurs
d’intégrité de la famille SRDF, comme l’utilisation du cache et la
durée des cycles selon des règles configurables, des intervalles de
rappel et des seuils d’alerte.
Sécurité : processus d’authentification et d’autorisation des
utilisateurs (en utilisant des rôles d’utilisateur personnalisés comme
administrateur de stockage, administrateur de la sécurité ou
surveillant), et gestion de Symmetrix Access Controls pour les
autorisations au niveau de l’hôte.
Avantages
Les avantages sont notamment les suivants :
◆
Accélération de la gestion des sous-systèmes Symmetrix par
rapport à la CLI
◆
Gestion et surveillance intuitives des logiciels à valeur ajoutée
◆
Surveillance en temps réel du système et des composants
◆
Gestion efficace des contrôles de sécurité
Logiciels et solutions associés
SMC peut être utilisé pour gérer des logiciels EMC tels que
TimeFinder et SRDF Host Component, et des options telles que
Symmetrix Priority Control et Dynamic Cache Partitioning.
Proposé gratuitement aux clients possédant EMC ControlCenter
Symmetrix Manager, SMC peut être utilisé le même système que
Symmetrix Manager, simultanément.
SMC peut être utilisé pour visualiser et gérer les périphériques CKD
au niveau du VOLSER si Solutions Enabler s’exécute sur la LPAR.
SMC ne nécessite aucune offre de services professionnels.
142
Gestion du stockage
Remarque : Disponible sur le site du support en ligne EMC, la
documentation consacrée à Symmetrix Manager Console décrit la
configuration requise au niveau du système et de l’environnement.
Licences
Pour les systèmes Symmetrix, SMC fait l’objet d’une licence par
sous-système.
Symmetrix Performance Analyzer (SPA)
Symmetrix Performance Analyzer (SPA) est une interface utilisateur
de type navigateur offrant un historique des tendances et une analyse
des données de performances de la baie Symmetrix. Elle est conçue
pour fonctionner avec SMC. À partir de SMC, l’interface SPA s’ouvre
dans sa propre fenêtre Web.
Symmetrix Performance Analyser offre une vue historique de tous les
principaux indicateurs de performances (KPI), une vue Diagnostic
permettant l’analyse des causes premières et une vue Temps réel
pour examiner en direct les points de données les plus fréquents. SPA
offre des représentations graphiques des données faciles d’utilisation
ainsi que des fonctions d’exportation et d’impression pour
enregistrer les données.
SPA collecte et stocke les données de performances, ce qui vous
permet de les analyser et de générer des rapports sur les charges de
travail et l’utilisation des ressources à des fins de la gestion des
niveaux de service, de diagnostic et de planification des capacités.
SPA permet d’effectuer les opérations suivantes :
◆
Analyse des causes premières
◆
Visualisation et création de graphiques représentant les
performances système en détail
◆
Recherche verticale dans les données pour analyser les problèmes
◆
Surveillance des performances au fil du temps
◆
Surveillance des performances d’une application
◆
Diagnostic des problèmes au niveau du périphérique
◆
Génération de cartes d’utilisation
143
Gestion du stockage
SPA fournit un certain nombre de vues permettant d’analyser les
données Symmetrix.
Vue Temps réel
La vue Temps réel assure une collecte à haute fréquence des données
et affiche les indicateurs sélectionnés au fur et à mesure de leur
disponibilité. Cette vue permet également d’enregistrer les données
sur une heure.
Les données sont collectées (pour un sous-ensemble de données) à
des intervalles de deux à cinq secondes. 1 000 indicateurs sont
générés en cinq minutes. Cette fonction est prise en charge par les
baies Symmetrix exécutant Enginuity 5773 ou une version
supérieure.
Vue Diagnostic
La vue Diagnostic peut être utilisée pour analyser des indicateurs de
haut niveau ou de bas niveau. Elle intègre un moteur d’analyse des
causes premières très intuitif permettant d’accéder à tous les
indicateurs disponibles ainsi que des tableaux comparatifs
composites des indicateurs associés. Elle offre également des vues au
niveau du périphérique, et se concentre généralement sur des
périodes relativement courtes, comme quelques heures.
Les données sont collectées par intervalles de cinq minutes (une
heure générera donc 12 points). Par défaut, les données collectées sur
une semaine sont enregistrées. La vue Diagnostic fournit également
une « voie rapide » permettant d’accéder instantanément aux goulots
d’étranglement critiques.
Snapshot
La vue Snapshot, illustrée dans la Figure 27, page 145, affiche un
calcul des données collectées au fil du temps et indique les relations
entre les éléments physiques (baie, disque et directeur) et logiques
(groupe de périphériques et application) présents dans la baie. Les
données sont collectées par intervalles de 15 minutes, fournissant
ainsi quatre points de données par heure. Ces données peuvent être
conservées pendant un an, permettant ainsi à l’utilisateur d’effectuer
des analyses approfondies des tendances ainsi que des corrélations
entre les nombreuses variables disponibles.
144
Gestion du stockage
Figure 27
SPA - Vue Snapshot affichant plusieurs relations
Tendances
La vue Tendances constitue le meilleur moyen de visualiser la
consommation des ressources au fil du temps. Cette vue prend
également en charge les lignes de projection linéaire, qui peuvent être
utilisées avec des seuils définis par l’utilisateur comme base pour
planifier les capacités.
Vous pouvez également personnaliser votre tableau de bord
personnel pour afficher une vue persistante à chaque fois que vous
vous connectez à SPA. Votre tableau de bord peut contenir des blocs
d’affichage basés sur les vues Diagnostic, Temps réel ou historiques
d’une baie Symmetrix.
Remarque : Disponible sur le site du support en ligne EMC, la
documentation consacrée à Symmetrix Performance Analyzer fournit des
informations sur la configuration requise au niveau de l’environnement
d’exploitation et du système pour garantir un fonctionnement optimal.
145
Gestion du stockage
Unisphere for VMAX
Disponible depuis mai 2012, EMC Unisphere for VMAX remplace
Symmetrix Management Console (SMC) et Symmetrix Performance
Analyzer (SPA). Avec Unisphere for VMAX, les clients peuvent
provisionner, gérer, surveiller et analyser des baies VMAX depuis
une console unique, réduisant ainsi considérablement le temps
consacré à l’administration du stockage.
Unisphere for VMAX offre une navigation basée sur des boutons de
grande taille et des opérations rationalisées pour simplifier la gestion
du stockage des datacenters et réduire le temps qui lui est consacré.
Unisphere for VMAX simplifie la gestion du stockage en la
rationalisant au sein d’un framework commun. Unisphere permet
d’effectuer les opérations suivantes :
◆
Effectuer des opérations de configuration
◆
Gérer les volumes
◆
Exécuter et surveiller les fonctions de réplication en local et à
distance
◆
Surveiller les alertes VMAX
◆
Gérer FAST et FAST VP
◆
Gérer les comptes utilisateur et leurs rôles
Fonctions
Unisphere for VMAX offre une interface unique permettant de
centraliser la gestion de l’ensemble de votre environnement de
stockage VMAX. Les opérations pouvant être effectuées sont
notamment les suivantes :
Configuration : création de volumes, définition des attributs de
volume et VMAX, définition des indicateurs de port, et création de
pools de volume SAVE. Vous pouvez ainsi modifier la configuration
d’un volume, définir son état et créer/dissoudre des métavolumes.
Performances : les données de performances précédemment
disponibles dans SPA sont à présent intégrées à Unisphere for
VMAX. Vous pouvez ainsi surveiller, analyser et gérer les paramètres
de performances comme les seuils, les alertes, les indicateurs et les
rapports.
146
Gestion du stockage
Surveillance de la réplication : permet de visualiser et de gérer les
sessions TimeFinder. Cela comprend les contrôles, les détails et les
modes des sessions. Vous pouvez également visualiser et gérer les
groupes et les pools SRDF.
Ergonomie : fournit une interface utilisateur simple et intuitive pour
la découverte des baies, la surveillance, la configuration et le contrôle
des sous-systèmes Symmetrix. Un seul écran permet de visualiser
l’ensemble des baies Symmetrix. À partir d’un tableau de bord
offrant une vue globale de l’environnement VMAX, vous pouvez
effectuer une recherche verticale jusqu’à celui d’une baie spécifique.
Le tableau de bord de la baie offre un récapitulatif de la capacité
physique et virtuelle de la baie. De plus, c’est aussi ici que les alertes
sont répertoriées et que l’utilisateur peut effectuer une recherche
verticale dans les alertes pour obtenir davantage d’informations.
Sécurité : Unisphere for VMAX prend en charge les types
d’authentification suivants : Windows, LDAP et utilisateurs
Unisphere locaux. Il est possible d’utiliser des processus
d’authentification des utilisateurs et de gestion des autorisations en
utilisant des rôles d’utilisateur personnalisés (administrateur de
stockage, auditeur, administrateur de la sécurité, surveillant, etc.).
Avantages
Les avantages sont notamment les suivants :
◆
Produit basé sur un navigateur fournissant une interface
utilisateur
◆
Écran unique pour surveiller et administrer les baies Symmetrix
◆
Intégration des fonctions de SMC et de SPA dans un produit
unique
◆
Tâches courantes disponibles dans toutes les fonctions
Documentation et solutions
Unisphere for VMAX ne nécessite aucune offre de services
professionnels.
Remarque : La documentation consacrée à Unisphere for VMAX est
disponible sur le site du support en ligne EMC. Elle fournit des informations
sur la configuration requise au niveau du système et de l’environnement.
Unisphere for VMAX
147
Gestion du stockage
Licences
Pour les systèmes Symmetrix, Unisphere for VMAX fait l’objet d’une
licence par sous-système.
148
6
Ce chapitre présente les logiciels mainframe EMC dédiés à la
protection des informations.
◆
◆
◆
◆
◆
◆
◆
Introduction ......................................................................................
Mainframe Enablers.........................................................................
ResourcePak Base for z/OS ............................................................
Famille de produits SRDF pour z/OS...........................................
Famille de produits EMC TimeFinder pour z/OS ......................
AutoSwap..........................................................................................
EMC GDDR.......................................................................................
150
151
154
159
174
185
187
149
Introduction
Les événements de ces dernières années (attaques terroristes,
catastrophes naturelles) et les besoins métiers de plus en plus stricts
(restauration instantanée de systèmes de bases de données massifs
corrompus) ont amené les responsables des datacenters et de la
continuité d’activité à rechercher des solutions plus performantes
pour garantir la disponibilité de leurs services informatiques. Les
solutions de protection des informations fournies par les logiciels et
les fonctionnalités EMC Symmetrix soutiennent cette stratégie visant
à améliorer la disponibilité, à faciliter la restauration rapide des
données et à automatiser les redémarrages système.
La protection et la restauration des informations dépendent de la
capacité à accéder à une copie séparée des données. Ces copies
peuvent être locales ou distantes : L’utilisateur a le choix entre
plusieurs objectifs de point de restauration (RPO)/objectifs de temps
de restauration (RTO) et différentes options de distance.
Ce chapitre présente les fonctions et les logiciels de protection des
informations des sous-systèmes Symmetrix qui gèrent ces copies
supplémentaires, permettant à l’utilisateur d’effectuer les opérations
suivantes avec un impact minimal sur les processus métiers
normaux :
150
◆
redémarrage après sinistre et reprise après sinistre de
l’entreprise ;
◆
test des nouvelles applications avec des données réelles dans des
environnements réels ;
◆
réduction des délais de sauvegarde et de restauration ;
◆
maintenance et mise à niveau sans interruption des matériels et
logiciels ;
◆
migration des données ;
◆
contrôle de cohérence des bases de données ;
◆
traitement parallèle ;
◆
fourniture de plusieurs points de contrôle pour la restauration.
Les sections suivantes présentent Mainframe Enablers, un package
permettant à lui seul de distribuer des logiciels destinés à surveiller et
à gérer les sous-systèmes Symmetrix. Elles décrivent ensuite
ResourcePak® Base, le mécanisme sous-jacent de l’API EMC
Symmetrix pour z/OS. Elles se poursuivent par un aperçu de la
famille de produits EMC SRDF et EMC TimeFinder pour z/OS. Les
deux dernières sections sont consacrées à EMC AutoSwap™ for
z/OS, qui fournit une protection haute disponibilité des
informations, et EMC Geographically Dispersed Disaster Restart, un
logiciel qui automatise le traitement des processus de reprise
d’activité afin de réduire la dépendance vis-à-vis du personnel pour
l’exécution des plans de priorités.
Mainframe Enablers
Mainframe Enablers est une suite de composants de surveillance et
de gestion du sous-système Symmetrix. Les composants indiqués à la
section suivante sont distribués et installés sous forme de package
unique qui simplifie l’installation et la maintenance tout en
garantissant la compatibilité des composants.
Composants de Mainframe Enablers
La suite Mainframe Enablers comprend les composants logiciels
suivants :
ResourcePak Base for z/OS
ResourcePak Base for z/OS améliore l’efficacité de la communication
entre les applications basées sur le mainframe (fournies par EMC ou
des éditeurs de logiciels indépendants) et un sous-système
Symmetrix.
SRDF Host Component for z/OS
SRDF Host Component surveille l’état de SRDF et contrôle les
processus de SRDF au moyen de commandes exécutées à partir d’un
hôte. SRDF gère une copie des données en temps réel au niveau du
volume logique dans plusieurs sous-systèmes Symmetrix installés
sur un même site ou sur des sites distants.
Mainframe Enablers
151
TimeFinder/Clone Mainframe Snap Facility
◆
Le logiciel TimeFinder/Clone Mainframe Snap Facility fournit les
fonctions suivantes, qui sont détaillées plus loin dans ce chapitre.
Pour plus d’informations, reportez-vous à la section « Famille de
produits EMC TimeFinder pour z/OS », page 174.
◆
TimeFinder/Clone : crée des copies ponctuelles de volumes
entiers ou de Datasets individuels.
◆
TimeFinder/Snap : crée des copies des volumes logiques basées
sur des pointeurs. Seules les préimages des données modifiées
sont écrites dans une zone de sauvegarde.
◆
Consistent Dataset Snap : crée une image cohérente des écritures
dépendantes de plusieurs Datasets en utilisant la fonction SNAP
DATASET de TimeFinder/Clone Mainframe Snap Facility.
◆
Duplicate Snap : crée une copie ponctuelle d’un périphérique
virtuel activé précédemment ; cela permet la création de
plusieurs copies d’une copie ponctuelle.
◆
Simultaneous TimeFinder/Clone : crée des snapshots
indépendants simultanés des volumes R2 correspondants dans la
baie Symmetrix secondaire, à partir des fonctions SNAP
VOLUME ou SNAP DATASET exécutées sur les volumes
R1 SRDF/S correspondants dans la baie Symmetrix principale,
de sorte qu’aucune donnée n’est transmise à travers les liaisons
SRDF/S.
TimeFinder/Mirror for z/OS
TimeFinder/Mirror for z/OS permet de copier les données des
volumes sources sur des volumes de continuité d’activité (Business
Continuance Volume, BCV). Les BCV sont des volumes cibles
désignés pour TimeFinder/Mirror. Ils sont configurés de cette
manière dans le contrôleur Symmetrix. TimeFinder/Mirror utilise
une technique de mise en miroir du matériel pour copier les volumes
sources. Une fois synchronisé, le BCV peut être séparé du volume
source au moyen d'un processus appelé SPLIT. Le BCV devient alors
une copie indépendante des données. Sur les sous-systèmes
Symmetrix VMAX, TimeFinder/Mirror est émulé dans le
sous-système en utilisant le volume complet de TimeFinder/Clone.
152
TimeFinder/Consistency Group
TimeFinder/Consistency Group est une fonction sous licence qui
permet d’utiliser Enginuity Consistency Assist (ECA) lors de la copie
des volumes de données. L’utilisation d’ECA sur des volumes
activement mis à jour crée une copie cohérente des écritures
dépendantes sur les volumes cibles. Cette copie peut être utilisée
dans le cadre d’une stratégie de redémarrage après sinistre.
TimeFinder Utility for z/OS
TimeFinder Utility for z/OS (TFU) est utilisé pour le
conditionnement des volumes cibles créés par l’un des trois produits
de réplication TimeFinder. TFU peut réattribuer un libellé à un
volume (changer le libellé VOL1), renommer le VVDS et le VTOCIX,
et, si nécessaire, renommer et recataloguer des Datasets sur le
volume.
Consistency Groups for z/OS
Consistency Groups for z/OS est conçu pour assurer la cohérence des
données copiées à distance par la fonction Symmetrix SRDF en cas de
sinistre récursif.
Autres fonctions
Mainframe Enablers comprend également plusieurs autres fonctions
pouvant être utilisées par les principaux composants. Ces fonctions
sont les suivantes :
◆
Multi-Session Consistency ;
◆
EMC AutoSwap for z/OS ;
◆
EMC SRDF/AR.
Multi-Session Consistency (MSC) assure la cohérence à travers
plusieurs sous-systèmes Symmetrix pour les groupes SRDF/A. La
tâche MSC s’exécute dans l’espace d’adressage EMCSCF
(ResourcePak Base) sur l’hôte z/OS.
AutoSwap for z/OS peut déplacer (permuter) les charges de travail
des volumes d’un ensemble de sous-systèmes Symmetrix vers les
volumes d’autres sous-systèmes Symmetrix dans le cadre d’une
relation SRDF synchrone.
Mainframe Enablers
153
SRDF/AR utilise TimeFinder pour autoriser la réplication
automatisée des copies de données à travers les liaisons SRDF en vue
de fournir une image redémarrable des données sur un site distant en
cas de sinistre sur le site de production.
Les sections suivantes décrivent de manière plus détaillée les
composants Mainframe Enablers.
ResourcePak Base est un composant de Mainframe Enablers.
ResourcePak Base for z/OS est une application logicielle qui facilite
la communication entre les applications basées sur le mainframe
(fournies par EMC ou des éditeurs de logiciels indépendants) et un
sous-système de stockage Symmetrix. ResourcePak Base est conçu
pour améliorer les performances et la facilité d’utilisation des
applications Symmetrix basées sur le mainframe.
ResourcePak Base fournit la fonction EMC Symmetrix Control
Facility (EMCSCF) pour les mainframes IBM et compatibles IBM.
EMCSCF offre une interface uniforme pour les logiciels fournis par
EMC et des éditeurs indépendants. Ainsi, tous les produits utilisent
la même interface au même niveau de fonction. EMCSCF fournit un
espace d’adressage persistant sur l’hôte afin de faciliter la
communication entre l’hôte et le sous-système Symmetrix qui lui est
rattaché, ainsi que d’autres applications fournies par EMC et ses
partenaires.
EMCSCF, qui est au cœur de ResourcePak Base, offre les
fonctionnalités suivantes :
154
◆
Communication entre les systèmes
◆
Actualisations SymmAPI-MF sans interruption de service
◆
Save Device (disques de délestage) et DSE Monitors (utilitaires de
contrôle)
◆
SRDF/A Monitor (Processus de contrôle de SRDF/A)
◆
Nommage de contrôleur
◆
Prise en charge des services GNS (Group Name Services)
◆
Gestion des pools
◆
Gestion du provisionnement virtuel
◆
Résilience SRDF/AR
◆
Cohérence multisession SRDF/A
◆
Services SWAP
◆
Services de restauration
◆
Sécurité SAF
◆
Gestion des codes de fonction sous licence
EMCSCF gère également les codes de fonction sous licence (Licensed
Feature Code, LFC) pour activer les fonctions d’un logiciel EMC
facturables séparément. Ces fonctions requièrent la fourniture d’un
LFC pendant l’installation et la personnalisation d’EMCSCF.
Comme illustré à la Figure 28, EMCSCF et SymmAPI effectuent des
appels via I/O Supervisor (IOS) à l’environnement d’exploitation
Enginuity du sous-système Symmetrix.
EMC or ISV developed
products
Symmetrix
Control Facility
(e. g., TimeFinder, SRDF
Host Component)
(ResourcePak Base)
Program calls
EMCSAI
SNAPAPI
Automation:
SWAP
Metadata:
Config info
Device status
Event monitor
Symmetrix
devices
I
O
S
ICO-IMG-000104
Figure 28
Architecture SymmAPI de z/OS
ResourcePak Base est le mécanisme de distribution de l’API
Symmetrix (SymmAPI) pour z/OS. Il fournit un point de contrôle
central en attribuant au logiciel un espace d’adressage persistant sur
le mainframe dédié aux fonctions Symmetrix qui effectuent les tâches
suivantes :
155
156
◆
Maintenance d’un référentiel actif contenant des informations sur
les périphériques Symmetrix rattachés aux environnements z/OS
et mise à disposition des informations disponibles pour les autres
produits fournis par EMC ou des éditeurs de logiciels
indépendants.
◆
Exécution des fonctions d’automatisation.
◆
Communication entre les partitions logiques (LPAR) via le
sous-système de stockage Symmetrix.
◆
Séparation entre les applications hôte et les différences pouvant
survenir dans l’environnement Enginuity en fonction des
niveaux de version. Par exemple, le nombre de périphériques
logiques Symmetrix pris en charge peut varier entre un niveau
d’Enginuity et un autre. ResourcePak Base masque cette
différence de sorte que les applications hôtes n’aient pas à être
modifiées.
◆
Définition d’un groupe de périphériques avec le service GNS
(Group Name Service) de Symmetrix, puis utilisation de cette
définition unique pour plusieurs produits EMC sur plusieurs
plates-formes. Ainsi, vous pouvez utiliser un groupe de
périphériques défini via GNS avec les applications EMC basées
sur le mainframe et sur les systèmes ouverts. GNS vous permet
également de définir des noms de groupe pour les volumes qui
peuvent ensuite être exploités par d'autres commandes.
◆
Personnalisation de certaines priorités du sous-système
Symmetrix sur des volumes logiques de base au moyen de
l’utilitaire EMC Quality of Service (QoS). Deux fonctions QoS
sont disponibles : Symmetrix Priority Control (SPC) et Dynamic
Cache Partitioning (DCP). SPC peut déterminer quelles E/S d’un
périphérique doivent recevoir un service de priorité lorsque le
sous-système Symmetrix est très occupé. DCP peut définir et
gérer jusqu’à huit partitions de cache différentes et associer des
périphériques en tant que membres d’une partition particulière.
Les fonctions SPC et DCP sont présentées de manière plus
détaillée au Chapitre 10, « Considérations relatives aux
performances. »
Autres utilitaires
L’utilitaire EMC ChangeTracker vous permet de surveiller et de
mettre à jour l’activité sur les périphériques Symmetrix. Avec
ChangeTracker, vous pouvez déterminer le nombre de pistes utilisées
depuis la dernière inspection. Il est important de disposer de données
précises sur les pistes modifiées lorsque vous dimensionnez vos
exigences de connectivité SRDF. Vous avez besoin de connaître la
vitesse et le nombre de connexions télécom à recevoir de votre
fournisseur de services pour une implémentation SRDF performante.
ChangeTracker vous aide à déterminer ces données importantes. Il
est également important de disposer d’informations précises sur le
suivi des modifications pour déterminer les délais de
resynchronisation de TimeFinder. Le suivi des modifications peut
fournir des informations qui vous aideront à déterminer le délai
nécessaire pour diverses activités de synchronisation et de
resynchronisation.
L’utilitaire EMC Disk Compare vous permet de comparer les pistes
allouées sur des paires de volumes de disques logiques au niveau
physique. Il a été amélioré de façon à prendre en charge la
comparaison de périphériques situés à plusieurs hops de distance
dans une configuration SRDF. Disk Compare est implémenté en tant
que processus de traitement par lot. Il utilise le numéro de
périphérique z/OS des périphériques comparés, le nombre de paires
de périphériques à comparer, le nombre de cylindres à valider et une
option qui définit le nombre de cylindres à ignorer, plus un cylindre à
traiter.
◆
Garantit l’installation et l’utilisation normales d’autres produits
fournis par EMC et ses partenaires éditeurs de logiciels
indépendants.
◆
Facilite la communication interprogramme automatique.
◆
Interagit avec les outils disponibles dans le commerce, comme le
langage de script REXX.
◆
Condition préalable à l’utilisation d’EMC Stored Procedure
Executive, qui permet de personnaliser les tâches répétitives en
fonction du site.
157
◆
Passerelle vers la plupart des logiciels spécifiques des
plates-formes EMC, comme les produits SRDF et TimeFinder.
Ce produit prend en charge les fonctions logicielles qui activent et
gèrent les fonctionnalités Symmetrix. ResourcePak Base fournit les
fonctions de contrôle des logiciels tels que SRDF, TimeFinder, EMC
Consistency Group, AutoSwap et autres.
Les matériels/logiciels requis pour EMC ResourcePak Base sont les
suivants :
◆
Tous les sous-systèmes Symmetrix actuellement pris en charge
avec le niveau approprié de Symmetrix Enginuity. Consultez les
guides produits et les notes de mises à jour les plus récents pour
ResourcePak Base for z/OS.
◆
Toute version de système d’exploitation basé sur MVS
actuellement prise en charge par IBM (par exemple, z/OS).
Remarque : ResourcePak Base for z/OS est un préalable indispensable à
l’utilisation des applications mainframe EMC, telles que l’ensemble de
produits TimeFinder for z/OS ou SRDF Host Component for z/OS. Il est
inclus avec ces produits.
158
Famille de produits SRDF pour z/OS
Sur le plan conceptuel, SRDF met en miroir (RAID niveau 1) un
périphérique de disque logique (la source primaire/R1 au sein d’un
système de stockage Symmetrix primaire) sur un second
périphérique logique (la cible secondaire/R2, dans un système de
stockage Symmetrix secondaire séparé physiquement) via des
liaisons de communication haut débit ESCON, Fibre Channel ou
GigE. La distance séparant les deux systèmes de stockage Symmetrix
peut varier de quelques centimètres à des milliers de kilomètres.
SRDF est le premier logiciel pour système de stockage Symmetrix. La
mise en miroir des données à distance (données d’un autre système
de stockage Symmetrix) fournie par SRDF est une ressource précieuse
pour :
◆
protéger les données en ayant recours à la séparation
géographique ;
◆
attribuer aux applications un second emplacement à partir
duquel les données peuvent être récupérées en cas
d’indisponibilité de l’emplacement principal, quelle qu’en soit la
raison ;
◆
fournir un moyen de créer un ensemble de volumes dédiés à
l’exécution d’opérations parallèles, telles que les tests et la
modélisation.
SRDF a évolué pour fournir différents modes de fonctionnement
(synchrone, Copie-écriture en attente évolutive, Copie-disque
évolutive, mobilité des données et, plus récemment, asynchrone).
D’autres solutions plus avancées le complètent désormais, comme
SRDF/Automated Replication et SRDF/Star, Cascaded SRDF et
SRDF/EDP.
Malgré ces différents changements, les produits de la famille SRDF
restent contrôlés par l’application basée sur le mainframe SRDF Host
Component. SRDF Host Component est un mécanisme de contrôle
qui met à disposition de l’utilisateur mainframe toutes les
fonctionnalités SRDF. L’outil EMC Consistency Group for z/OS est
quant à lui utile pour gérer la cohérence des écritures dépendantes
sur les liaisons entre les systèmes Symmetrix et un ou plusieurs
mainframes rattachés.
159
SRDF/Star
SRDF Family for z/OS
SRDF/S
Synchronous for
zero data exposure
SRDF/A
Asynchronous for
extended distances
SRDF/DM
Efficient data mobility
between Symmetrix arrays
Multi-point
replication option
SRDF/CG
Consistency Group
option
SRDF/AR
Automated Replication
option
SRDF/EDP
Extended Distance
Protection
ICO-IMG-000745
Figure 29
Famille SRDF pour z/OS
La Figure 29 montre que les modules à droite viennent s’ajouter aux
modules au centre pour fournir une fonction supplémentaire. Par
exemple, SRDF Consistency Group est un complément logique pour
les clients qui exécutent SRDF en mode synchrone.
SRDF Host Component for z/OS
SRDF Host Component for z/OS, de même que ResourcePak Base for
z/OS (module de services API), est fourni lors de la commande d’un
composant de la famille de produits SRDF. Pour plus d’informations
sur la technologie SRDF en général, visitez le site :
http://france.emc.com/storage/symmetrix-vmax/srdf-40k.htm
160
Fonctions mainframe de SRDF
Voici les fonctions mainframe de SRDF :
◆
Capacité de déployer des solutions SRDF à travers l’entreprise :
SRDF Host Component peut gérer la mise en miroir à distance
pour les disques CKD et FBA. Dans ces déploiements, un
mainframe et un ou plusieurs hôtes système ouverts sont
rattachés au côté primaire de la relation SRDF. Les déploiements
SRDF d’entreprise peuvent être contrôlés par des hôtes
mainframe ou par des hôtes système ouverts, bien que les jeux
d’outils soient différents dans chaque environnement.
◆
Prise en charge des canaux hôtes ESCON ou FICON
indépendamment du protocole de liaison SRDF utilisé : SRDF est
un protocole déployé entre les systèmes Symmetrix qui met en
miroir les données des deux côtés d’une liaison de
communication. La connectivité entre l’hôte et le système de
stockage Symmetrix (ESCON ou FICON) est indépendante des
protocoles utilisés pour le déplacement des données entre les
liaisons SRDF. SRDF prend en charge l’ensemble des protocoles
de liaison standard : ESCON, Extended ESCON, Fibre Channel et
GigE.
◆
Prise en charge logicielle de la mise hors ligne d’une liaison
SRDF : SRDF Host Component comporte une commande
logicielle capable de mettre hors ligne une liaison SRDF, que le
volume cible soit également mis hors ligne ou non. Cette fonction
est utile s’il existe plusieurs liaisons dans la configuration et
qu’une seule d’entre elles rencontre des problèmes, par exemple
un trop grand nombre de pertes (pertes sporadiques de liaison)
ou de conditions d’erreur. Dans ce cas, il est inutile de mettre
toutes les liaisons hors ligne. La mise hors ligne de la liaison mise
en cause est en effet suffisante.
◆
Interfaces SRDF Host Component supplémentaires : Toutes les
fonctions de SRDF Host Component peuvent être utilisées via
l’interface de la console, mais également via le compilateur de
scripts REXX ou Stored Procedure Executive (SPE), un outil
puissant d’automatisation des processus répétitifs.
161
SRDF/Synchronous
Symmetrix Remote Data Facility/Synchronous (SRDF/S) est un
produit de réplication à distance qui assure la maintenance d’une
copie miroir (synchrone) des données en temps réel dans des
sous-systèmes Symmetrix séparés physiquement au sein d’une
configuration SRDF.
SRDF/Asynchronous
À partir d’EMC Enginuity version 5670, les sous-systèmes Symmetrix
prennent en charge le produit de réplication asynchrone
SRDF/Asynchronous (SRDF/A). SRDF/A est un logiciel de
réplication à distance qui vous permet de répliquer à tout moment les
données en mode asynchrone, tout en maintenant une copie
cohérente des écritures dépendantes des données sur les
périphériques secondaires (R2). La copie ponctuelle cohérente des
écritures dépendantes des données sur les périphériques secondaires
est généralement effectuée quelques secondes seulement après la
copie sur les systèmes primaires (R1). Les données d’une session
SRDF/A sont transférées vers le sous-système Symmetrix secondaire
par cycles (Delta Sets) en éliminant la redondance des multiples
modifications effectuées sur une même piste et transférées via les
liaisons SRDF, réduisant potentiellement les besoins en bande
passante réseau. SRDF/A fournit une solution de réplication longue
distance. Ce niveau de protection est adapté aux clients qui exigent
un impact minimal sur les applications hôtes et veulent disposer
d’une image redémarrable cohérente des écritures dépendantes de
leurs données sur un site secondaire. En cas de sinistre sur le site
primaire (R1), ou si les liaisons SRDF sont perdues durant le transfert
des données, il est possible d’éliminer un Dataset Delta partiel, en
préservant la cohérence des écritures dépendantes sur le site
secondaire sans dépasser deux cycles SRDF/A.
SRDF/A a toujours pris en charge la possibilité de resynchroniser les
volumes dans le contexte du processus de changement de cycle
SRDF/A en permettant la réalisation de copies au sein des cycles
SRDF/A. Pour cette fonction, la limite est de 30 000 pistes par cycle
(réparties entre tous les groupes SRDF/A).
162
Bien que ce processus soit capable de resynchroniser les volumes
SRDF/A, il n’exploite pas entièrement la bande passante disponible
lorsque la durée réelle du cycle SRDF/A est inférieure à la durée
minimale de cycle spécifiée par l’utilisateur.
Enginuity 5876 améliore les performances de copie des pistes lorsque
SRDF/A est actif en autorisant la copie directe des sites R1/R2, en
ignorant les cycles SRDF/A et en autorisant les copies
supplémentaires jusqu’à ce que la durée minimale de cycle ait été
atteinte. Ce comportement est automatique et est invoqué lorsque le
cycle en cours est vide et que le cycle précédent a atteint la durée
minimale de cycle.
SRDF/Data Mobility
SRDF/Data Mobility (SRDF/DM) est un produit SRDF destiné à une
exploitation en mode Copie évolutive SRDF. Il est conçu pour la
réplication ou la migration de données entre au moins deux systèmes
Symmetrix. Avec le mode Copie évolutive, les applications peuvent
éviter les délais de propagation pendant le transfert des données vers
le site distant. SRDF/DM transfère les données des volumes
primaires vers les volumes secondaires, ce qui permet le partage des
informations, la distribution des contenus et assure un accès local à
d’autres environnements de traitement. SRDF/DM prend en charge
tous les modèles de matériels Symmetrix et tous les niveaux
Enginuity reconnaissant SRDF, et peut être utilisé pour les transferts
locaux ou distants. SRDF/DM ne préserve pas la cohérence des
applications lors de la réplication.
Concurrent SRDF et SRDF/Star
SRDF/Star repose sur plusieurs technologies clés :
◆
Dynamic SRDF
◆
Concurrent SRDF
◆
◆
SRDF/Synchronous
◆
SRDF/Asynchronous
◆
Consistency Group
◆
Certaines fonctions d’Enginuity
163
SRDF/Star fournit une protection avancée de la continuité d’activité
multisite qui accroît les opérations SRDF et SRDF/A simultanées à
partir des volumes primaires en offrant la capacité de créer une
session SRDF/A incrémentielle entre les deux sites distants en cas de
panne du site primaire. Cette capacité est disponible uniquement via
le logiciel SRDF/Star.
SRDF/Star combine les logiciels hôtes mainframe et les
fonctionnalités Enginuity utilisées simultanément. La Figure 30
montre une configuration SRDF/Star classique sur trois sites.
Primary site (A)
(production)
Local site (B)
SRDF/Synchronous
R1
R2
SRDF/Asynchronous
Remote site (C)
BCV
Active
Inactive
R2
ICO-IMG-000105
Figure 30
Configuration classique de prise en charge SRDF/Star
L’option de configuration simultanée de SRDF/A fournit la capacité
de redémarrer un environnement sur de longues distances en
perdant un minimum de données, tout en fournissant simultanément
une fonction de redémarrage sans perte de données sur le site local.
Une telle configuration fournit une protection en cas de sinistre d’un
site ou régional, tout en minimisant l’impact sur les performances et
la perte de données.
164
Dans une configuration Concurrent SRDF/A dépourvue de la
fonction SRDF/Star, la perte du site A primaire implique
normalement l’arrêt de la réplication longue distance et de la
propagation des données vers le site C. Les données du site C
continuent à vieillir alors que la production a repris sur le site B. Le
rétablissement de la fonction SRDF/A entre les sites B et C nécessite
une resynchronisation complète pour réactiver la protection de
reprise après sinistre. Cela prend du temps, consomme des ressources
et prolonge la période durant laquelle aucune protection normale de
reprise après sinistre n’est fournie.
SRDF/Star assure le rétablissement rapide de la protection entre les
sites en cas de panne du site primaire (A). Au lieu de procéder à une
resynchronisation complète entre les sites B et C, SRDF/Star fournit
une synchronisation différentielle du site B vers le site C, réduisant
considérablement le délai nécessaire pour protéger à distance le
nouveau site de production. SRDF/Star fournit également un
mécanisme qui permet à l’utilisateur de déterminer quel site (B ou C)
abrite les données les plus actuelles, en cas de sinistre récursif sur le
site A. Dans tous les cas, le choix du site à utiliser en cas de panne est
laissé à la discrétion du client.
Concurrent SRDF/Asynchronous
Remarque : Concurrent SRDF/A est une nouvelle fonction disponible
avec Enginuity 5875.
Concurrent SRDF/A offre la capacité de répliquer en mode
asynchrone à partir d’un seul sous-système Symmetrix de production
vers deux sous-systèmes Symmetrix distants uniques. Plus
précisément, il permet aux deux tronçons d’un R11 (contrôleur
Symmetrix source/primaire) de participer à deux relations SRDF/A.
Le changement de cycle est exécuté indépendamment sur chaque
tronçon, bien que la fonction Multi-Session Consistency (MSC) puisse
être utilisée pour coordonner le changement entre les deux tronçons.
Par ailleurs, dans les implémentations sans fonction MSC, la durée
des cycles peut varier. Le site primaire doit exécuter Enginuity 5875.
165
Il a été démontré que cette approche minimise les impacts en termes
de performances sur les applications de production dans les
environnements SRDF multisite. Par ailleurs, elle offre aux
utilisateurs d’implémentations SRDF/S et SRDF/A simultanées
existantes la capacité de remplacer le mode synchrone par le mode
asynchrone durant les périodes les plus intenses de charge de travail,
de manière à minimiser l’impact du temps de réponse aller-retour de
SRDF/S aux applications. Cette capacité garantit que les applications
hôtes ne sont pas limitées par les performances synchrones des
sous-systèmes et du réseau. Le changement de mode peut être
effectué sur l’un des tronçons SRDF ou les deux. En raison de la
flexibilité de cette fonction, les utilisateurs peuvent désormais choisir
d’étendre la distance de l’un des tronçons SRDF/A pour profiter
d’une résilience de configuration supplémentaire.
Multi-Session Consistency
Dans les environnements SRDF/A, la cohérence à travers plusieurs
sous-systèmes Symmetrix pour les sessions SRDF/A est fournie par
la tâche Multi-Session Consistency (MSC) qui s’exécute dans l’espace
d’adressage EMCSCF. MSC assure la cohérence à travers pas moins
de 24 sessions SRDF/A et est activée par un code de fonctions sous
licence.
SRDF/Cascaded
Cascaded SRDF est une solution de mise en miroir et de restauration
des données qui fournit des fonctions améliorées de réplication,
optimise l’interopérabilité et facilite l’utilisation à plusieurs niveaux.
Avec Cascaded SRDF, les données du site primaire sont répliquées en
mode synchrone vers un site secondaire, puis répliquées en mode
asynchrone vers un site tertiaire.
Cascaded SRDF introduit le concept d’un volume R2/R1 jouant un
double rôle, appelé volume R21. Dans les versions antérieures à
Enginuity 5773, un périphérique SRDF pouvait être un volume
source (R1) ou un volume cible (R2), mais ne pouvait pas jouer les
deux rôles simultanément. Le volume R21 est à la fois un miroir R2 et
un miroir R1, utilisable uniquement dans les opérations SRDF en
cascade. Pour comprendre le concept du volume R21, il est plus
simple de le considérer comme un type de miroir, plutôt que comme
un périphérique. Les contrôles de ces périphériques sont basés sur les
relations.
166
SRDF/Extended Distance Protection (EDP)
SRDF/Extended Distance Protection (SRDF/EDP) vous permet de
rationaliser une liaison SRDF en cascade vers un site distant avec une
connexion plus directe (sans disque). Le modèle SRDF en cascade
sans disque autorise la réplication entre la source (site A) et la cible
distante (site C) sans avoir recours à des BCV SRDF ou à une
réplication sur le site intermédiaire. La Figure 31 illustre la
configuration sur trois sites de SRDF/EDP et les niveaux Enginuity
pris en charge sur chacun des trois sites. Les volumes R21 sans disque
sont dessinés en tant que disque dans la baie Symmetrix du site B.
Primary
site A
Enginuity 5773 or 5874
Secondary
site B
Enginuity 5874
Tertiary
site C
Enginuity 5773 or 5874
R1
R21
R2
ICO-IMG-000751
Figure 31
Diagramme des blocs SRDF/EDP
SRDF/Star
Disponible dans les versions Enginuity 5x71 et ultérieures,
SRDF/Star fournit une protection avancée de la continuité d’activité
multisite. SRDF/Star offre la capacité de répartir et protéger de
manière différentielle les données à travers les différents sites restants
dans une implémentation de reprise après sinistre multisite.
En cas de panne du site primaire, SRDF/Star permet aux sites
restants de rétablir rapidement les données, de les protéger en
utilisant la mise en miroir à distance, puis de restaurer tout aussi
rapidement le site primaire quand les conditions le permettent.
167
La solution SRDF/Star utilise différents modes de fonctionnement
(SRDF/A, SRDF/S) entre les sites participants. Avec SRDF/Star, les
entreprises peuvent resynchroniser rapidement les copies SRDF/S et
SRDF/A en répliquant uniquement les différences entre les sessions,
ce qui permet de redémarrer très rapidement les services protégés
après une panne du site primaire. SRDF/Star peut également être
utilisé avec des configurations de protection à distance en cascade et
étendues.
Remarque : L’automatisation des configurations SRDF/Star est fournie par
EMC GDDR. Les exemples de scripts de restauration SRDF/Star ne sont pas
fournis avec Mainframe Enablers version V7.0 et ultérieur.
SRDF/Consistency Groups
SRDF/Consistency Groups (CG) assure la cohérence des données
mises en miroir à distance par les opérations SRDF en cas de sinistre
récursif à travers plusieurs sous-systèmes Symmetrix et à travers
plusieurs périphériques au sein d’un sous-système Symmetrix.
Lorsque SRDF/CG détecte une écriture sur un volume qui ne peut
pas communiquer avec son miroir distant, SRDF/CG suspend la
mise en miroir à distance pour tous les volumes définis sur le groupe
de cohérence avant de terminer les E/S interceptées et de rendre le
contrôle à l’application. De cette manière, SRDF/CG évite aux E/S
dépendantes d’atteindre le miroir distant si les E/S précédentes n’ont
pas pu aller plus loin que le miroir local.
SRDF/AR (réplication automatisée)
SRDF/Automated Replication (SRDF/AR) est une solution
d’automatisation qui utilise SRDF et TimeFinder pour fournir une
réplication asynchrone périodique d’une image de données
redémarrable.
Comparées aux solutions de reprise après sinistre traditionnelles aux
délais de restauration longs, les solutions de redémarrage après
sinistre qui utilisent SRDF/AR fournissent un redémarrage à
distance avec un temps de restauration plus court. SRDF/AR offre
une protection des données avec cohérence des écritures dépendantes
à distance.
Remarque : Pour plus d’informations sur SRDF, consultez le Guide produit
Symmetrix Remote Data Facility .
168
TimeFinder/Snap off an SRDF/A R2
Remarque : TimeFinder/Snap off an SRDF/A R2 est une nouvelle fonction
disponible avec Enginuity 5875.
Dans les versions antérieures à Enginuity 5875, les sessions
TimeFinder/Snap et TimeFinder/Clone actives exécutant des R2
SRDF/A actifs pouvaient parfois provoquer l’abandon d’une session.
TimeFinder/Clone était pris en charge via l’utilisation de la fonction
Precopy. Cependant, la fonction TimeFinder/Snap off an SRDF/A R2
était bloquée par TimeFinder/Clone MSF. La nouvelle fonction
TimeFinder/Snap off SRDF/A R2 d’Enginuity 5875 élimine le
blocage de TimeFinder/Snap, et est désormais activée par une
nouvelle fonction d’adaptation du flux d’entrée par volume.
Cette fonction est utilisable uniquement sur les volumes R2 SRDF/A
exploitant TimeFinder. Elle détecte les sessions TimeFinder actives
sur les volumes R2 et reconnaît la vitesse de restauration de volume
la plus lente. Elle peut retarder les écritures de l’hôte au niveau du
volume pour éviter un débordement du cache et donc des abandons
de session SRDF/A. TimeFinder/Clone MSF vérifie que la fonction
d’adaptation du flux d’entrée par volume est activée avant
d’autoriser l’activation d’un VDEV. Enginuity 5875 est requis sur les
sous-systèmes Symmetrix primaire et secondaire (des deux côtés de
la liaison). La fonction Cascaded SRDF (R21 vers R2) n’est pas prise
en charge.
Les fonctions d’adaptation du flux d’entrée par volume et par groupe
peuvent coexister indépendamment et sont surveillées et déclenchées
en fonction de la satisfaction de certains critères. La fonction
d’adaptation du flux d’entrée par volume est déclenchée si la vitesse
de restauration des R2 est inférieure à la fréquence d’arrivée et que
TimeFinder est actif sur le volume. Seuls les volumes affectés font
l’objet d’une adaptation du flux d’entrée. La fonction d’adaptation du
flux d’entrée par groupe est déclenchée si le débit de liaison est
inférieur à la fréquence des E/S de l’hôte et que tous les volumes du
groupe font l'objet d'une adaptation du flux d'entrée. La nouvelle
fonction d’exemption d’adaptation du flux d’entrée, spécifiée via
l’option NOGPACE, s’applique à la fonction d’adaptation du flux
d’entrée par groupe. Elle permet d’exempter des volumes individuels
de cette fonction. SRDF Host Component spécifie de nouveaux
contrôles d’adaptation du flux d’entrée des écritures au niveau du
périphérique sur la commande SC SRDFA_WP.
169
Enginuity 5876 étend la fonctionnalité d’adaptation du flux d’entrée
des écritures par groupe en ajoutant une fonction d’adaptation du
flux d’entrée par volume basée sur les délais de restauration
SRDF/A. Si une opération de restauration se prolonge au-delà de la
durée minimale du cycle en raison de pistes en attente d’écriture sur
les périphériques R2, Enginuity peut mettre en œuvre une mesure
d'adaptation du flux d'entrée sur le volume R1 correspondant.
L’adaptation du flux d’entrée par volume peut atteindre le niveau du
groupe, mais dans ce cas il s’agit d’une approche plus granulaire
répondant à une condition côté R2 qui implique moins de volumes et
peut conduire à une insuffisance de cache. La nouvelle fonction
d’adaptation du flux d’entrée par volume est automatiquement
activée et désactivée dans le cadre de la fonction d’adaptation du flux
d’entrée des écritures par groupe. Elle est contrôlée par l’option
GPACE dans Mainframe Enablers.
Remarque : La fonction d’adaptation du flux d’entrée des écritures de
SRDF/A ne prend pas en charge la capacité d’exempter des volumes de la
fonction d’adaptation du flux d’entrée des écritures par groupe/volume.
Un dispositif pour les statistiques d’adaptation du flux d’entrée par
volume a été créé dans Mainframe Enablers V7.4.
Compression logicielle SRDF
Dans Enginuity 5875, une nouvelle fonction de compression logicielle
est disponible. Enginuity exécute pour cela un algorithme de
compression logicielle sur la carte réseau distante pour les E/S
SRDF/A. Cet algorithme est appliqué au niveau du groupe aux E/S
de type FC et GigE. Pour cette fonction, les baies Symmetrix R1 et R2
doivent toutes deux exécuter Enginuity 5874.207 ou une version
ultérieure. La compression logicielle est séparée (indépendante) de la
compression matérielle des données existante, introduite dans un
niveau antérieur d’Enginuity (cette compression matérielle des
données spécifique s’appliquait uniquement à SRDF sur GigE). Seuls
les paramètres de compression logicielle côté R1 sont actifs sur la
session SRDF. La nouvelle fonctionnalité est contrôlée par la nouvelle
commande SC SRDF_CMPR, qui fournit deux nouvelles actions de
commande (ACT pour activer et DEACT pour désactiver). La syntaxe
de commande est la suivante :
170
#SC SRDF_CMPR
,LCL(cuu,rdfgroup#)
,RMT(cuu,mhlist,rdfgroup#)
,action
,CQNAME=cqname
,CQNAME=(cqname,queue-option)
Compression matérielle pour la carte réseau distante Fibre Channel
Une fonction de compression matérielle a été ajoutée sur la carte
réseau distante Fibre Channel du VMAX 40K exécutant
Enginuity 5876. Auparavant, la compression matérielle pour SRDF
n'était disponible que sur les cartes réseau distantes GigE.
La prise en charge de la compression matérielle avec des cartes réseau
distantes Fibre Channel requiert l’activation d’un paramètre de
configuration dans le sous-système Symmetrix. Par ailleurs, les
VMAX 40K doivent exécuter Enginuity 5876 des deux côtés.
Prise en charge de FAST VP par SRDF
FAST VP, initialement introduit dans Enginuity 5875, fonctionne
indépendamment sur chaque sous-système Symmetrix dans une
relation SRDF. L’une des conséquences est que les décisions prises
concernant le positionnement des données sur les niveaux FAST VP
ne sont pas répercutées dans les baies des partenaires à travers une
liaison SRDF. Lors des opérations de reprise, les données peuvent se
trouver dans un autre niveau de la baie Symmetrix secondaire que
celui qu’elles occupaient dans la baie Symmetrix primaire. Si ce
comportement persistait dans Enginuity 5876, cela créerait un
problème dans les environnements AutoSwap mainframe lors de la
redirection dynamique des E/S vers le site secondaire, provoquant
potentiellement des temps de réponse inattendus suite à un
événement AutoSwap.
Ce problème a été résolu dans Enginuity 5876, grâce à l’ajout de la
prise en charge par SRDF du mécanisme de collecte de statistiques
FAST VP. Les statistiques FAST VP sont maintenant envoyées vers la
baie Symmetrix secondaire dans des configurations SRDF/S,
SRDF/A et Concurrent SRDF. Avec les statistiques issues de R1, le
moteur FAST VP sur la baie Symmetrix R2 peut prendre des
décisions plus éclairées concernant la promotion et la relégation, qui
tiennent compte de l’activité de charge de travail sur la baie
171
Symmetrix R1. Il peut également mieux positionner la baie
Symmetrix secondaire et ainsi fournir des performances similaires
pour la charge de travail.
SRDF en mode mixte
Les cartes réseau distantes Symmetrix SRDF étaient auparavant
limitées à la prise en charge de SRDF/A ou SRDF/S, mais jamais des
deux en même temps. Elles avaient en effet un impact sur les
performances de SRDF/S et limitaient par conséquent la flexibilité du
changement de mode SRDF, en plus d’accroître les coûts globaux, car
des cartes réseau distantes dédiées étaient requises pour chaque
mode.
Enginuity 5876 introduit la capacité de combiner les opérations de
copie SRDF/S, SRDF/A et SRDF sur la même carte réseau distante en
fournissant un mécanisme de hiérarchisation pour chaque type d’E/S
configurable par l’utilisateur sur les cartes de type Fibre Channel et
GigE.
Vous trouverez ci-dessous les paramètres par défaut du pourcentage
de CPU de la carte distante dédié au mode SRDF. Ceux-ci peuvent
être affichés et définis à l'aide des nouvelles commandes MRDFDIS et
MRDFSET de l’utilitaire Quality of Service de MFE.
Paramètres par défaut (% de CPU de la carte réseau distante) :
◆
SRDF/S : 70 %
◆
SRDF/A : 20 %
◆
Copies : 10 %
172
◆
Contrôle au niveau du mainframe des fonctions de la famille
SRDF du sous-système Symmetrix
◆
Protection contre les sinistres locaux et régionaux et les activités
de maintenance planifiées
◆
Protection contre les sinistres récursifs de plusieurs contrôleurs
DASD
◆
Capacité d’activer la cohérence des écritures dépendantes sur les
sous-systèmes Symmetrix distants (SRDF Consistency Group for
z/OS)
◆
Capacité d’utiliser SRDF/AR pour protéger automatiquement les
données à distance en utilisant des liaisons de communication à
moindre coût, tout en préservant la cohérence des écritures
dépendantes
◆
Protection simultanée multisite unique requérant un minimum
de transfert de données pour continuer les opérations
(SRDF/Star).
◆
Capacité d’utilisation combinée avec l’ensemble de produits
TimeFinder pour z/OS afin de disposer de solutions telles que
SRDF/AR, SRDF/A, SRDF/Star et GDDR.
ResourcePak Base doit être installé pour qu'il soit possible d'utiliser
les produits de la famille SRDF. Il est fourni sans frais
supplémentaires lors de la commande initiale.
Licences
Pour obtenir des informations sur le support, les produits et les
licences d’EMC, procédez comme suit.
Informations sur les produits : pour obtenir de la documentation, des
notes de mise à jour, des mises à jour logicielles ou des informations
sur les produits, licences et services EMC, consultez le site de support
en ligne EMC :
http://support.emc.com
173
Famille de produits EMC TimeFinder pour z/OS
Depuis des années, la famille de produits TimeFinder fournit des
capacités essentielles pour l’environnement mainframe. Bien
qu’ayant subi quelques modifications au fil du temps, TimeFinder
conserve les fonctions clés présentées à la Figure 32.
TimeFinder Family for z/OS
TimeFinder/Mirror
TimeFinder/Clone
Ultra-functional, highperformance copies
Classic highperformance option
TimeFinder/CG
Consistency Group
option
TimeFinder/Snap
Economical spacesaving copies
ICO-IMG-000108
Figure 32
Famille de produits TimeFinder pour z/OS
TimeFinder/Clone for z/OS
TimeFinder/Clone for z/OS est un composant de TimeFinder/Clone
Mainframe Snap Facility. Il fournit le code et la syntaxe associés à la
réalisation de snapshots de volumes entiers et de snapshots de
Datasets. Il réalise donc des copies occupant un espace équivalent.
TimeFinder/Clone n’occupe pas de position miroir et ne requiert
aucune balise BCV pour les cibles sur le système de stockage
Symmetrix. Certaines commandes TimeFinder/Mirror, comme
Protected BCV Establish, ne sont pas disponibles dans
TimeFinder/Clone Mainframe Snap Facility. Cette commande repose
sur une technologie de copie basée sur des pointeurs plutôt que sur
une technologie miroir.
Voici d'autres fonctions mainframe spécifiques de TimeFinder/Clone
for z/OS :
◆
174
Snapshots de Datasets.
◆
Snapshots différentiels de volumes entiers. Ceux-ci requièrent
uniquement de copier les données modifiées sur les snapshots
suivants.
◆
Prise en charge des opérations CONSISTENT SNAP. Ces
opérations préservent la cohérence des écritures dépendantes sur
la cible et requièrent le produit TimeFinder/Consistency Group.
◆
Jusqu’à 16 copies ponctuelles simultanées d’un volume primaire
individuel.
◆
Compatibilité avec STK Snapshot Copy et les produits de
snapshot IBM, notamment la réutilisation de la syntaxe
SIBBATCH.
◆
TimeFinder Utility for z/OS. Il conditionne le catalogue ICF en
réattribuant un libellé aux entrées et en les recataloguant afin
d’éviter les problèmes associés à la duplication des noms de
volume dans l’environnement mainframe. Cet utilitaire est
également fourni avec les produits TimeFinder/Mirror,
TimeFinder/Clone et TimeFinder/Snap.
◆
Compatibilité avec les mécanismes de sécurité mainframe tels
que RACF.
◆
Intégration avec de nombreux éditeurs de logiciels indépendants
spécialisés mainframe et leurs produits respectifs.
TimeFinder/Snap for z/OS
TimeFinder/Snap for z/OS utilise le code et la syntaxe de
TimeFinder/Clone, mais avec une différence importante. Les
snapshots réalisés avec ce produit sont des snapshots virtuels, ce qui
signifie qu’ils n’occupent qu’une partie de l’espace généralement
occupé par un snapshot de volume entier. Il est possible d’invoquer
cette fonction via le mot-clé VDEV (Virtual Device, périphérique
virtuel). Lorsque l’argument VDEV est utilisé, seuls la préimage mise
à jour des données modifiées et un pointeur sont conservés sur la
cible. Cette technique réduit considérablement l’utilisation de
l’espace disque sur la cible. Cette fonction fournit également un ou
plusieurs SNAPPOOL (pools de snapshots) pouvant être gérés
indépendamment.
Voici les fonctions mainframe spécifiques du produit
TimeFinder/Snap for z/OS :
175
◆
Code et syntaxe identiques à ceux utilisés dans
TimeFinder/Clone Mainframe Snap Facility (plus l’ajout de
l’argument VDEV).
◆
Les mêmes fonctions que TimeFinder/Clone Mainframe Snap
Facility, et donc, les mêmes avantages.
◆
Prise en charge des volumes entiers uniquement (les Datasets ne
sont pas pris en charge).
◆
Jusqu’à 128 snapshots ponctuels simultanés d’un volume
primaire individuel.
◆
Conditionnement du catalogue ICF avec TimeFinder Utility for
z/OS. Il renomme et recatalogue les entrées afin d’éviter les
problèmes associés à la duplication des noms de volume dans
l’environnement mainframe.
◆
que RACF.
◆
Intégration avec de nombreux éditeurs de logiciels indépendants
spécialisés mainframe et leurs produits respectifs.
TimeFinder/Mirror for z/OS
TimeFinder/Mirror for z/OS fournit des BCV et les moyens
nécessaires aux applications mainframe pour les manipuler. Les BCV
sont des volumes logiques aux balises spéciales manipulables via des
commandes TimeFinder/Mirror : ESTABLISH, SPLIT,
RE-ESTABLISH et RESTORE.
Voici les fonctions mainframe spécifiques du produit
TimeFinder/Mirror :
◆
TimeFinder Utility for z/OS, qui conditionne la VTOC, VTOCIX,
le VVDS et le catalogue ICF en réattribuant un libellé aux entrées
et en les recataloguant, évitant ainsi les problèmes associés à la
duplication des noms de volume et des noms de Dataset.
◆
Capacité de créer des BCV préservant la cohérence des écritures
dépendantes en local ou à distance (avec le plug-in TimeFinder/
Consistency Group) sans avoir à mettre en veille les tâches de
production.
Voici les opérations sur les BCV essentielles pour les départements
informatiques :
176
◆
Utilisation des BCV comme sources des opérations de
sauvegarde.
◆
Utilisation des BCV pour les LPAR test avec des données réelles.
La vitesse de reconstruction d’un BCV implique que plusieurs
cycles de test peuvent être exécutés rapidement et
séquentiellement. Il est possible de regrouper les applications à
l’aide des BCV avant de les valider pour le prochain cycle
d’actualisation des applications.
◆
Utilisation des BCV comme sources pour les applications
d’entrepôt décisionnel plutôt que les volumes de production. Les
BCV sont l’image miroir à un point dans le temps des données de
production. Ils peuvent donc être utilisés comme des copies de
référence des données devant être écrites et réécrites de façon
répétitive.
◆
Utilisation de SRDF/Automated Replication.
◆
Prise en charge des requêtes TimeFinder mainframe, notamment
l’utilisation de la correspondance des caractères génériques.
◆
que RACF.
◆
Intégration des utilitaires SGBD disponibles via les éditeurs de
logiciels indépendants et leurs produits.
◆
Intégration de nombreux éditeurs de logiciels indépendants
spécialisés mainframe et de leurs produits.
Sur la plate-forme Symmetrix VMAX, toutes les opérations
TimeFinder/Mirror sont émulées dans Enginuity et converties en
opérations TimeFinder/Clone de manière transparente.
TimeFinder/CG
TimeFinder/CG (Consistency Group) est un plug-in pour les
produits TimeFinder/Mirror, TimeFinder/Clone et
TimeFinder/Snap. TimeFinder/CG fournit la prise en charge de la
cohérence pour diverses commandes de la famille TimeFinder.
TimeFinder/CG fait l’objet d’une licence distincte et utilise un
modèle d’implémentation de code de fonction sous licence.
177
TimeFinder/CG permet d’utiliser le paramètre CONSISTENT(YES)
sur TimeFinder/Clone et TimeFinder/Snap, ainsi que le paramètre
CONS sur les instructions SPLIT de TimeFinder/Mirror. Ainsi,
TimeFinder peut créer une copie ponctuelle instantanée de tous les
volumes copiés. La copie ainsi créée est une copie cohérente des
écritures dépendantes, dont l’état est très similaire à celui créé durant
une panne d’alimentation. Lorsqu’un sous-système DB2 est copié de
cette manière, une image redémarrable est créée.
TimeFinder/CG invoque ECA (Enginuity Consistency Assist) pour
suspendre les E/S pendant que la copie est effectuée. Il y a peu ou pas
d’effet sur l’application hôte ou la base de données durant cette
période.
Consistent Dataset Snap
La fonction Consistent Dataset Snap permet à l’utilisateur d’obtenir
une image cohérente des écritures dépendantes de plusieurs Datasets
en utilisant la fonction SNAP DATASET de TimeFinder/Clone MF
Snap Facility.
Actuellement, la cohérence entre Datasets ne peut être obtenue qu’en
demandant une mise en file d’attente exclusive des Datasets sources,
ce qui est très peu réalisable dans les environnements de production.
Plus l’environnement de production est grand, moins il est pratique.
Par ailleurs, cette approche n’assure pas la cohérence entre les
Sysplex, fonction qui doit pourtant être prise en compte dans les très
grands environnements.
Les autres facteurs ayant empêché l’utilisation de cette fonction
jusqu’à présent étaient que la fonction SNAP DATASET ne pouvait
être appliquée qu’à un seul Dataset à la fois, et que l’exécution du
snapshot étendu Enginuity prenait trop de temps dans une fenêtre
Enginuity Consistency Assist (ECA). Il existait une complication
supplémentaire liée au fait que le snapshot étendu ne permettait pas
de séparer les phases de création et d’activation du snapshot d’un
Dataset (ce qui est autorisé pour un volume complet). Cette capacité
essentielle est désormais fournie.
La nouvelle fonction de snapshot étendu cohérent d’Enginuity 5875
permet en effet de séparer les phases de création et d’activation des
snapshots sur toute l’étendue, rendant possible le traitement des
snapshots de Datasets sur un groupe entier de Datasets en assurant la
cohérence des écritures dépendantes à travers le groupe de Datasets
cibles ainsi produit.
178
Une instruction ACTIVATE distincte peut désormais être ajoutée à la
suite des instructions SNAP DATASET. Par ailleurs,
CONSISTENT(YES) est à présent autorisé sur ACTIVATE, comme
illustré dans l’exemple suivant et expliqué dans le guide EMC
TimeFinder/Clone Mainframe Snap Facility Product Guide.
GLOBAL
MAXRC(4) PARALLEL(YES) HOSTCOPYMODE(NONE)
GLOBAL
DEBUG(EXTRA)
*
SNAP DATASET ( SOURCE ( WJWJ.X1F.DD0.MV5300 ) TARGET (WJMVS9.X1F.DD0.MV5320 ) VOLUME(MV5320 ) REPLACE(Y) REUSE(N))
SNAP DATASET ( SOURCE ( WJWJ.X1F.DD1.MV5301 ) TARGET (WJMVS9.X1F.DD1.MV5321 VOLUME(MV5321 ) REPLACE(Y) REUSE(N))
ACTIVATE (CONSISTENT(YES))
Remarque : Il faut savoir que la fonction Consistent Dataset Snap assure
uniquement la cohérence des écritures dépendantes entre les Datasets. La
cohérence intra-Dataset (métadonnées et données) n’est pas garantie pour le
moment. L’utilisateur doit s’assurer qu’aucune modification des
métadonnées, par exemple des étendues supplémentaires (extension du
Dataset), ne s’est produite durant le traitement Consistent Dataset Snap.
Par ailleurs, il faut prendre en compte le fait que le mécanisme ECA
est exécuté au niveau du volume et que l’accès aux autres Datasets
peut donc être affecté pendant cette fenêtre ECA.
Duplicate Snap
La fonction Duplicate Snap permet de créer une copie ponctuelle
d’un périphérique virtuel activé au préalable. Il est ainsi possible de
créer plusieurs copies d’une copie ponctuelle, comme illustré à la
Figure 33.
179
VDEV
LOG
SRC
Duplicate VDEV
ICO-IMG-000935
Figure 33
Duplicate Snap
Cette fonctionnalité est utile pour les utilisateurs qui veulent réaliser
des copies de leurs environnements de production et les réaffecter à
d’autres fins, par exemple pour des tests uniques ou itératifs, pour
l’assurance qualité ou pour d’autres formes d’extension et de
développement d’applications. Dans le cadre d’un test, les
utilisateurs peuvent avoir besoin de copies supplémentaires de leur
test qui reflètent le travail effectué jusqu’à un point donné. Cette
capacité est utile pour la sauvegarde ou pour la prise en charge
d’autres efforts de test. Son principal avantage est qu’elle évite de
répliquer le volume entier (c’est-à-dire, d’ajouter 100 % de stockage
en plus), réduisant ainsi sensiblement les coûts tout en fournissant
une grande flexibilité de test et de développement.
Le nombre maximal de copies de snapshots produites à partir d’un
ensemble de volumes donné est toujours 128. Les utilisateurs
peuvent réaliser des snapshots en double sans dépasser cette limite à
la condition qu’ils aient tous la même source d’origine. De nouveaux
paramètres ont été introduits dans la syntaxe de commande SNAP
VOLUME. Il s’agit de SOURCE_VDEV associé au nouvel alias
TARGET_VDEV pour le paramètre TARGET. Comme illustré dans
l’exemple suivant :
SNAP VOLUME (SOURCE_VDEV(srcvdev) TARGET_VDEV(tgtvdev)
180
Veuillez également noter que seuls deux VDEV en double par source
maximum peuvent avoir simultanément l’état « ESTABLISHED et
INACTIVE ». Après activation, il est possible d’en ajouter jusqu’à
deux de plus. Par ailleurs, l’arrêt ou le renouvellement d’un snapshot
de la session VDEV d’origine n’est pas autorisé alors que le VDEV en
double est inactif.
La restauration des copies de snapshots sur la source ou leur
promotion sur un volume de copie complète est prise en charge.
Cependant, la restauration d’une copie de snapshot sur le snapshot
source d’origine n’est pas prise en charge.
Remarque : Cette fonction requiert Mainframe Enablers V7.2 ou ultérieur, et
peut être gérée en utilisant Symmetrix Management Console V7.2 ou
ultérieur ou Unisphere.
Simultaneous TimeFinder/Clone
Simultaneous TimeFinder/Clone est utile dans les environnements
de continuité d’activité utilisant SRDF/S. Pour bien comprendre cette
fonction et son impact sur l’environnement SRDF/S, il est important
d’examiner d’abord l’environnement SRDF/S quand il en est
dépourvu.
Avant la disponibilité de la fonction Parallel Clone, les opérations
SNAP VOLUME ou SNAP DATASET appliquées aux volumes
R1 SRDF/S produisaient des copies (données) à travers la liaison
SRDF/S. Les frais en termes de bande passante de liaison pouvaient
être importants selon l’amplitude et la durée des copies. Par ailleurs,
les données hébergées sur la baie Symmetrix secondaire n’étaient pas
utilisables avant que la copie soit terminée à travers les liaisons. Cela
est illustré à la Figure 34, page 182.
181
Primary
Secondary
SRDF/S
SRC1
Volume
or
dataset
clone
SRC’1
SRDF/S
TGT1
TGT’1
Snapped Data
flows across link
Primary
Secondary
ICO-IMG-000933
Figure 34
Environnement SRDF/S sans Parallel Clone
Avec la fonction Simultaneous TimeFinder/Clone d’Enginuity 5875,
les opérations SNAP VOLUME ou SNAP DATASET appliquées aux
volumes R1 SRDF/S (baie Symmetrix primaire) produisent des
snapshots simultanés indépendants des volumes R2 correspondants
(baie Symmetrix secondaire), de sorte que les données sont
transmises à travers les liaisons SRDF/S puisque l’opération de
commande est dupliquée sur la baie Symmetrix secondaire. Cela est
illustré à la Figure 35.
Primary
Parallel
volume
or
dataset
clone
Secondary
SRDF/S
SRC1
SRDF/S
TGT1
SRC’2
Parallel
volume
or
dataset
clone
TGT’2
Snapped Data
flows across link
Figure 35
182
Primary
Secondary
R1
R2
Environnement SRDF/S avec Parallel Clone
ICO-IMG-000934
Surtout, la fonction Simultaneous TimeFinder/Clone permet de
s’assurer que l’état des données de R1 est toujours identique à celui
des données de R2, et que les données en cours sont disponibles à
tout moment des deux côtés.
Simultaneous TimeFinder/Clone est une fonction similaire à la
fonction IBM Remote Pair FlashCopy, parfois appelée Preserve
Mirror. Plus précisément, Preserve Mirror est la fonction logicielle de
z/OS qui utilise la fonction IBM Remote Pair FlashCopy. La fonction
Simultaneous TimeFinder/Clone n’est pas une implémentation
compatible avec IBM Remote Pair FlashCopy. L’objectif est de fournir
cette compatibilité dans les futures versions d’Enginuity.
La fonction Simultaneous TimeFinder/Clone est implémentée via
l’introduction du nouveau paramètre PARALLEL_CLONE (YES |
NO), qui peut être spécifié sur les commandes GLOBAL, SNAP
DATASET et SNAP VOLUME. PARALLEL_CLONE est également
disponible en tant qu’option de site.
L’exemple suivant illustre les spécifications des mots-clés mentionnés
ci-dessus :
//***************************************************
//*
SOURCE: 5420 - 542F R1
R2 - 8160 -816F
//*
TARGET: 5430 - 5430 R1
R2 - 8170 -817F
//***************************************************
*
GLOBAL MAXRC(4) CHKO(NO) DEBUG(EXTRA)
GLOBAL PARALLEL_CLONE(YES) CHECKBCVHOLDSTATUS(NO)
*
SNAP VOLUME (SOURCE (UNIT (5420-542F)) TARGET (UNIT ( 5430-543F)) COPYVOLID(NO) FREESPACE(YES) REPLACE (YES) CONDITIONVOLUME(ALL ) )
ACTIVATE(CONSISTENT(YES) MESSAGES(DISPLAY) )
Remarque : Pour utiliser Simultaneous TimeFinder/Clone, Enginuity 5875
doit être installé sur les sous-systèmes Symmetrix des deux côtés de la
liaison. Par ailleurs, les R2 des volumes de snapshot sources et cibles R1
doivent être présents sur le même sous-système Symmetrix (donc, pas de
déploiement SRDF).
183
Il ne faut pas confondre la spécification du paramètre
PARALLEL_CLONE avec le paramètre PARALLEL existant
(c’est-à-dire, PARALLEL | PAR(YES | NO)) sur l’instruction
GLOBAL qui permet d’activer ou de désactiver le traitement
multitâche. Ce paramètre diffère également de la fonction
PARALLEL SNAP existante, qui autorise l’exécution de deux
snapshots indépendants sur les mêmes sous-systèmes Symmetrix ou
sur des sous-systèmes distincts, initiés par deux commandes SNAP
DATASET indépendantes spécifiant le même nom de Dataset source,
mais des noms de Datasets cibles différents.
La fonction Simultaneous TimeFinder/Clone n’est pas prise en
charge sur les périphériques Cascaded SRDF. Certaines opérations
SRDF sont bloquées sur les périphériques équipés de la fonction
Simultaneous TimeFinder/Clone : Supprimer et Supprimer la moitié,
Permuter et Permuter la moitié, Déplacer le groupe et Déplacer la
moitié du groupe.
Les produits de la famille TimeFinder peuvent être utilisés avec
SRDF/Automated Replication for z/OS et SRDF/Star for z/OS.
ResourcePak Base doit être installé pour qu'il soit possible d'utiliser
les produits de la famille TimeFinder. Il est fourni sans frais
supplémentaires lors de la commande initiale. TimeFinder Utility for
z/OS, décrit en page 153, doit être utilisé en conjonction avec chacun
des autres membres de la famille TimeFinder pour conditionner les
volumes cibles TimeFinder.
Licences
Les codes de fonction sous licence suivants sont requis pour les
produits de la famille TimeFinder :
184
◆
TimeFinder/Mirror (utilisation des BCV) ;
◆
TimeFinder/Consistency Group (mot-clé CONSISTENT) ;
◆
TimeFinder/Clone et TimeFinder/Snap (mot-clé TARGET ou
TRG) ;
◆
TimeFinder/Snap (mot-clé VDEV).
AutoSwap
Bien qu’inclus avec ResourcePak Base, AutoSwap est principalement
utilisé avec EMC Consistency Group for z/OS (ConGroup).
ConGroup est un utilitaire conçu pour assurer la cohérence des
données mises en miroir à distance. ConGroup permet de déplacer
(permuter) la charge de travail des volumes d’un ensemble de
sous-systèmes Symmetrix vers les volumes d’autres sous-systèmes
Symmetrix de l’une des manières suivantes :
◆
manuellement par le biais d’une commande (permutations
planifiées) ;
◆
automatiquement en réponse à un problème (permutations non
planifiées).
AutoSwap gère les permutations automatiques de charge de travail
entre les sous-systèmes Symmetrix.
Remarque : Pour plus d’informations, consultez le Guide produit EMC
Consistency Group for z/OS.
Caractéristiques d’AutoSwap
AutoSwap fournit les fonctionnalités et avantages suivants :
◆
Tests sur les périphériques au sein de groupes de permutation
afin de vérifier la validité des conditions de changement
d’adresse. Cette fonction prend en charge le regroupement des
périphériques dans des groupes de permutation et traite chacun
de ces groupes comme une entité de permutation unique.
◆
Permutation cohérente. Les écritures vers le groupe sont
effectuées durant le processus de permutation, ce qui assure la
cohérence des écritures dépendantes et donc la protection des
données et la fourniture d’une capacité de redémarrage.
AutoSwap
185
◆
Coordination de la permutation à travers plusieurs images z/OS
dans un environnement de périphériques DASD partagé ou un
environnement Sysplex parallèle. Pendant la période de gel des
groupes de permutation et de mise en file d’attente des E/S,
AutoSwap reconfigure les paires de périphériques SRDF pour
autoriser les flux d’E/S des applications à partir des
périphériques SRDF secondaires. Le contenu des UCB étant
permuté, la redirection des E/S vers les applications est
transparente. Cette redirection continue jusqu’au prochain
événement IPL (chargement initial du programme).
Avec AutoSwap, les utilisateurs peuvent effectuer les opérations
suivantes :
◆
Procéder à une reconfiguration de la charge de travail dynamique
sans interruption de service des applications.
◆
Permuter simultanément un grand nombre de périphériques.
◆
Gérer les opérations des groupes de périphériques.
◆
Réaffecter des volumes logiques.
◆
Effectuer des permutations cohérentes.
◆
Mettre en œuvre les pannes planifiées de périphériques
individuels ou de sous-systèmes entiers.
◆
Réagir de manière appropriée aux sinistres imprévus en cas
d’événement non planifié.
◆
Protéger contre la perte de tous les canaux DASD ou d’un
sous-système de stockage entier. Ceci augmente la protection de
l’intégrité des données fournie par SRDF/CG en assurant une
disponibilité continue en cas de panne affectant la connectivité
d’un périphérique R1.
AutoSwap fournit des fonctions qui prennent en charge le produit
SRDF/S, EMC Consistency Group. AutoSwap requiert que les
périphériques soient configurés en tant que paires SRDF synchrones.
Le Guide produit AutoSwap fournit des informations concernant les
éléments à prendre en compte pour la prise en charge des
page-dataset.
186
Les matériels/logiciels requis pour AutoSwap sont les suivants :
◆
Toute version de z/OS prise en charge par IBM avec JES2
◆
RACF ou un produit de sécurité équivalent compatible SAF
◆
SRDF/Synchronous
◆
SRDF/Consistency Groups
◆
Licences
L’octroi de licences et les tarifs AutoSwap dépendent du niveau de
tier MSU du CPU. Deux codes de fonction sous licence (LFC) sont
requis, un pour la permutation planifiée, l’autre pour la permutation
non planifiée. Les deux clés sont fournies avec le produit.
EMC GDDR
EMC Geographically Dispersed Disaster Restart (EMC GDDR) est un
logiciel mainframe qui automatise la reprise d’activité suite à des
pannes planifiées et à des situations de sinistre, notamment la perte
totale d’un datacenter. Pour ce faire, EMC GDDR ajoute des fonctions
de surveillance, d’automatisation et de contrôle qualité à de
nombreux produits matériels et logiciels EMC et tiers requis pour le
redémarrage de l’activité.
EMC GDDR redémarre les systèmes de production suite à des
sinistres et ne réside donc pas sur les serveurs qu’il protège.
EMC GDDR réside sur les partitions logiques (LPAR) séparées des
serveurs hôtes qui exécutent les charges de travail de vos
applications.
EMC GDDR est installé sur une LPAR de contrôle dans chaque site.
Chaque nœud EMC GDDR est relié aux autres nœuds EMC GDDR
via des connexions réseau entre chaque site. Grâce à ce lien,
EMC GDDR peut :
◆
détecter les sinistres ;
◆
identifier les composants non sinistrés.
EMC GDDR
187
Pour réussir le redémarrage d’activité, la capacité d’automatisation
d’EMC GDDR s’étend bien au-delà du disque jusqu’au système
d’exploitation hôte. C’est à ce niveau que les contrôles et l’accès aux
logiciels et matériels tiers existants sont suffisants pour permettre à
EMC de fournir des fonctions de restauration automatisée.
Configurations de continuité d’activité prises en charge
EMC GDDR est disponible dans les configurations suivantes :
SRDF/S avec ConGroup : la configuration SRDF/S avec ConGroup
sur deux sites fournit des capacités de redémarrage après sinistre sur
le site DC2.
SRDF/S avec AutoSwap : la configuration SRDF/S avec AutoSwap
sur deux sites assure une disponibilité quasi continue via le
basculement sur incident des périphériques entre les sites DC1 et
DC2.
SRDF/A : la configuration SRDF/A sur deux sites fournit des
capacités de redémarrage après sinistre sur le site DC3.
SRDF/Star : la configuration SRDF/Star sur trois sites fournit des
capacités de redémarrage après sinistre sur le site DC2 ou DC3. La
prise en charge de Concurrent SRDF et Cascaded SRDF minimise
encore le temps de restauration sur le site DC3.
SRDF/Star avec AutoSwap : la configuration SRDF/Star avec
AutoSwap sur trois sites assure une disponibilité quasiment continue
via le basculement sur incident des périphériques entre les sites DC1
et DC2, ainsi que des capacités de redémarrage après sinistre sur le
site DC3. La prise en charge de Concurrent SRDF et Cascaded SRDF
minimise encore le temps de restauration sur le site DC3.
188
SRDF/S avec ConGroup
La configuration SRDF/S avec ConGroup sur deux sites fournit des
fonctions de redémarrage après sinistre sur le site DC2.
DC1
DC2
EMC
GDDR
EMC
GDDR
ConGroup
R1
ConGroup
SRDF/S
R2
GDDR heartbeat communication
Active Escon/Ficon channels
Standby Escon/Ficon channels
Active SRDF links
Figure 36
SYM-002226
Configuration SRDF/S avec ConGroup sur deux sites
Comme illustré à la Figure 36, la relation entre les sites DC1 et DC2
est maintenue via la réplication SRDF/S des images de disques
primaires sur les sites DC1 à DC2. Il est possible de répliquer les
images de disques des systèmes ouverts (FBA) comme les images de
disques des systèmes mainframe (CKD).
La Figure 36 montre également les deux systèmes C-System
EMC GDDR et leurs chemins de communication heartbeat, séparés
des sites de production hébergeant les disques et les ordinateurs. Le
logiciel EMC Consistency Group (ConGroup) est installé dans
chacune des LPAR z/OS de production des sites DC1 et DC2.
Dans cet environnement, EMC GDDR peut effectuer les opérations
suivantes :
◆
Gérer les permutations de site planifiées
EMC GDDR
189
◆
Redémarrer le traitement sur le site secondaire suite à des
événements non planifiés sur le site primaire
◆
Effectuer des tâches opérationnelles standard
• IPL, réinitialisation du système, activation, désactivation
• Déclencher le démarrage/l’arrêt des charges de travail métiers
◆
Surveiller activement les événements non planifiés/de panne
• Sites
• Systèmes
• Perte de SRDF/S
• Trajet ConGroup
• Panne de communication entre les sites
Remarque : Le Guide produit GDDR SRDF/S with ConGroup fournit des
informations supplémentaires sur cette configuration.
SRDF/S avec AutoSwap
La Figure 37, page 191 montre une configuration GDDR sur deux
sites avec AutoSwap.
Comme illustré, la relation entre les sites DC1 et DC2 est maintenue
via la réplication SRDF/S des images de disques primaires sur les
sites DC1 à DC2. Il est possible de répliquer les images de disques des
systèmes ouverts (FBA) comme les images de disques des systèmes
mainframe (CKD).
Cette figure montre également les deux systèmes C-System
des sites de production hébergeant les disques et les ordinateurs. Les
logiciels EMC AutoSwap et EMC Consistency Group (ConGroup)
sont installés dans chacune des LPAR z/OS de production des sites
DC1 et DC2.
190
DC1
DC2
AutoSwap
EMC
GDDR
EMC
GDDR
AutoSwap
R1
AutoSwap
SRDF/S
R2
Active SRDF links
Figure 37
SYM-002225
Configuration GDDR avec SRDF/S et AutoSwap sur deux sites
La configuration SRDF/S avec AutoSwap sur deux sites assure une
disponibilité quasiment continue via le basculement sur incident des
périphériques entre les sites DC1 et DC2.
suivantes :
◆
◆
Gérer la restauration après les permutations de site non planifiées
◆
Effectuer des tâches opérationnelles standard :
◆
• Sites
• Systèmes
• Perte de SRDF/S
• Trajet ConGroup
• Événements AutoSwap
EMC GDDR
191
◆
Configurer/reconfigurer
• Coupler des Datasets
◆
Gérer les installations de couplage
• Règles
SRDF/A
La Figure 38 illustre la configuration SRDF/A sur deux sites qui
fournit des capacités de redémarrage après sinistre sur le site DC3.
DC1
DC3
EMC
GDDR
EMC
GDDR
R1
SRDF/A
R2
Active SRDF links
Figure 38
SYM-002224
Configuration SRDF/A sur deux sites
Comme illustré, la relation entre les sites DC1 et DC3 est maintenue
via la réplication SRDF/A des images de disques primaires sur les
sites DC1 à DC3. Il est possible de répliquer les images de disques des
systèmes ouverts (FBA) comme les images de disques des systèmes
mainframe (CKD).
Cette figure montre également les deux systèmes C-System
des sites de production hébergeant les disques et les ordinateurs.
suivantes :
192
◆
◆
Redémarrer le traitement sur le site secondaire suite à des
événements non planifiés sur le site primaire
◆
◆
• Sites
• Systèmes
• Perte de SRDF/A
SRDF/Star
La configuration SRDF/Star sur trois sites fournit des capacités de
redémarrage après sinistre sur le site DC2 ou DC3. La prise en charge
de Concurrent SRDF et Cascaded SRDF minimise encore le temps de
restauration sur le site DC3.
La Figure 39, page 194 illustre le fonctionnement d’EMC GDDR dans
un environnement Concurrent SRDF/Star.
un environnement Cascaded SRDF/Star.
EMC GDDR
193
DC1
DC2
EMC
GDDR
EMC
GDDR
ConGroup
R1
ConGroup
R21
SRDF/S
SRDF/A
DC3
R2
EMC
GDDR
Active SRDF links
SRDF links in standby mode
SYM-002221
Figure 39
194
GDDR dans un environnement Concurrent SRDF/Star
DC1
DC2
EMC
GDDR
EMC
GDDR
ConGroup
R1
ConGroup
R2
SRDF/S
DC3
SRDF/A
R2
EMC
GDDR
Active SRDF links
SYM-002223
Figure 40
GDDR avec Cascaded SRDF/Star
Dans cet environnement, EMC GDDR peut effectuer les tâches
suivantes :
◆
◆
◆
Gérer la reconfiguration de l’environnement SRDF/Star entre les
topologies Concurrent et Cascaded
◆
Gérer la reconfiguration de l’environnement SRDF/Star d’une
topologie Cascaded vers une topologie Concurrent en déplaçant
le site de traitement primaire
◆
EMC GDDR
195
◆
Surveiller activement les événements non planifiés/de panne,
notamment :
• Sites
• Systèmes
• Trajet ConGroup
• Perte de SRDF/S
• Perte de SRDF/A
SRDF/Star avec AutoSwap
La configuration SRDF/Star avec AutoSwap sur trois sites assure une
disponibilité quasiment continue via le basculement sur incident des
périphériques entre les sites DC1 et DC2, ainsi que des capacités de
redémarrage après sinistre sur le site DC3. La prise en charge de
Concurrent SRDF et Cascaded SRDF minimise encore le temps de
restauration sur le site DC3.
un environnement Concurrent SRDF/Star avec AutoSwap.
un environnement Cascaded SRDF/Star avec AutoSwap.
196
DC1
DC2
AutoSwap
EMC
GDDR
EMC
GDDR
AutoSwap
R1
AutoSwap
R2
SRDF/S
DC3
SRDF/A
R2
EMC
GDDR
Active SRDF links
SYM-002228
Figure 41
GDDR dans un environnement Concurrent SRDF/Star avec AutoSwap
EMC GDDR
197
DC1
DC2
AutoSwap
EMC
GDDR
EMC
GDDR
AutoSwap
R1
AutoSwap
R21
SRDF/S
SRDF/A
DC3
R2
EMC
GDDR
Active SRDF links
SYM-002222
Figure 42
GDDR dans un environnement Cascaded SRDF/Star avec AutoSwap
Comme illustré à la Figure 41 et à la Figure 42, la relation entre les
sites DC1 et DC2 est maintenue via la réplication SRDF/Synchronous
des images de disques primaires sur les sites DC1 à DC2. Il est
possible de répliquer les images de disques des systèmes ouverts
(FBA) comme les images de disques des systèmes mainframe (CKD).
Ces illustrations montrent les trois systèmes C-System EMC GDDR et
leurs chemins de communication heartbeat indépendants, séparés
des sites de production hébergeant les disques et les ordinateurs.
EMC AutoSwap et EMC Consistency Group (ConGroup) sont
installés dans chacune des LPAR z/OS de production des sites DC1 et
DC2.
198
EMC GDDR ne doit pas obligatoirement geler les E/S pour obtenir
un point de cohérence. AutoSwap et ConGroup fournissent le
mécanisme. Au moment où EMC GDDR reçoit la notification de
l’événement, le point de cohérence est déjà atteint grâce à ces
technologies fondamentales.
Dans cet environnement, EMC GDDR peut effectuer les tâches
suivantes :
◆
◆
◆
Gérer la reconfiguration de l’environnement SRDF/Star entre les
topologies Concurrent et Cascaded
◆
Gérer la reconfiguration de l’environnement SRDF/Star d’une
topologie Cascaded vers une topologie Concurrent en déplaçant
le site de traitement primaire
◆
◆
Surveiller activement les événements non planifiés/de panne,
notamment :
• Sites
• Systèmes
• Trajet ConGroup
• Perte de SRDF/S
• Perte de SRDF/A
• Événements AutoSwap
◆
Configurer/reconfigurer
• Coupler des Datasets
◆
Gérer les installations de couplage
• Règles
EMC GDDR a été conçu pour être personnalisé en fonction de ces
configurations.
EMC GDDR
199
EMC GDDR possède les caractéristiques suivantes :
◆
Protection de l’environnement en cas d’événements planifiés ou
non
• EMC GDDR surveille et gère les tâches de réplication des
systèmes et du stockage. Lors de la détection de pannes
relatives aux systèmes et au stockage, EMC GDDR redémarre
vos systèmes et applications distants.
• EMC GDDR réduit le risque d’erreur humaine dans les scripts
et les opérations
◆
Simplicité de fonctionnement
• EMC GDDR masque la complexité des relations entre
systèmes, applications, stockage et réseaux.
• Le fait que le logiciel fonctionne à partir de paramètres permet
une modification simplifiée et accélérée des configurations : en
effet, il n’est pas nécessaire de réécrire les procédures ni de les
tester une deuxième fois
◆
Solution standardisée
• Une application et une implémentation cohérentes fournissent
des méthodologies de redémarrage après sinistre
indépendantes du site de déploiement du logiciel.
◆
Solution plus économique
• Le coût de possession est réduit par rapport aux solutions
nécessitant la rédaction de scripts personnalisés.
Pour exécuter EMC GDDR, vérifiez que les logiciels suivants sont
installés (au minimum) :
200
◆
Toute version de z/OS actuellement prise en charge par IBM
◆
API IBM Hardware Management Console (HMC)
◆
SRDF/Host Component for z/OS
◆
◆
Consistency Group for z/OS
◆
AutoSwap for z/OS
Consultez le site de support en ligne EMC pour connaître les niveaux
minimaux requis pour ces logiciels, ainsi que toute information
complémentaire concernant la maintenance.
Licences
Les licences GDDR sont octroyées par site et par LPAR mainframe
d’installation. Les clients doivent donc demander une validation
préalable de leurs sites, qui permettra de garantir qu’ils remplissent
les conditions d’installation requises. SRDF Star est uniquement pris
en charge avec GDDR.
EMC GDDR
201
202
7
Migration et mobilité des
données
Ce chapitre présente les solutions EMC de migration et de mobilité
des données mainframe.
◆
◆
◆
Introduction ...................................................................................... 204
InfoMover.......................................................................................... 205
z/OS Migrator .................................................................................. 208
203
Introduction
EMC conçoit des solutions destinées à déplacer et faire migrer les
informations tout en préservant leur accessibilité. Ces outils
optimisent le taux d’utilisation des ressources et facilitent le
déploiement, et n’ont aucun impact sur l’activité.
204
InfoMover
IFT (InfoMover File Transfer)
EMC InfoMover File Transfer (IFT) est un package logiciel qui
transfère des données entre des systèmes z/OS, UNIX et Windows.
Avec IFT, vous pouvez vous passer du réseau et emprunter les
canaux à grande vitesse d’un sous-système de stockage EMC
Symmetrix pour copier des Datasets ou des fichiers entre divers hôtes
mainframe IBM, UNIX ou Windows. IFT vous permet d’effectuer les
opérations suivantes :
◆
Accéder aux données situées dans les Datasets mainframe, les
fichiers UNIX, les canaux nommés UNIX et les fichiers Windows
par l’intermédiaire d’un sous-système Symmetrix
◆
Lire ou copier des données depuis un fichier source situé sur un
hôte vers un fichier cible situé sur un autre hôte
◆
Convertir des données d’un octet d’un format à un autre (par
exemple ASCII 1 vers EBCDIC 2 et EBCDIC vers ASCII)
◆
Bénéficier d’un environnement fonctionnant avec les contrôles de
sécurité qu’offrent les systèmes z/OS, UNIX et Windows
2000/Windows Server 2003/ Windows Server 2008
◆
Utiliser une interface de ligne de commande (CLI) semblable à
celle d’un FTP
◆
Économiser les ressources système et obtenir de meilleures
performances en exploitant les canaux Symmetrix plutôt que le
réseau
IFS (InfoMover File System)
IFS est une technologie de partage de fichiers. IFS fournit aux
utilisateurs de systèmes ouverts une interface de systèmes de fichiers
native et transparente permettant d’accéder aux catalogues et aux
Datasets des systèmes d’exploitation mainframe IBM. IFS est une
interface de systèmes de fichiers haute vitesse entre les systèmes
ouverts et les données mainframe.
InfoMover
205
IFS permet aux applications installées sur les hôtes UNIX ou
Windows de lire et d’écrire des données sur les Datasets z/OS stockés
sur les périphériques CKD d’un sous-système de stockage Symmetrix
adressé à la fois par le mainframe IBM et l’hôte UNIX ou Windows.
IFS permet aux applications situées sur des hôtes UNIX et Windows
de lire et d’écrire des données sur les Datasets z/OS qui sont :
◆
stockés sur des périphériques CKD d’un sous-système de
stockage Symmetrix adressé par le mainframe, mais pas par
l’hôte client ;
◆
stockés sur des volumes CKD non Symmetrix adressés par le
mainframe, mais pas par l’hôte client.
Dans IFS, les données mainframe IBM apparaissent comme s’il
s’agissait de fichiers et dossiers de systèmes ouverts ordinaires.
Comme IFT, IFS exploite les canaux haute vitesse des sous-systèmes
Symmetrix pour minimiser l’impact sur votre réseau.
Les composants IFS peuvent être présents sur les types d’hôte
suivants :
◆
Mainframe (z/OS)
◆
UNIX
◆
Windows
InfoMover peut effectuer les opérations suivantes :
206
◆
Accélérer l’acheminement des informations au sein du datacenter
◆
Réduire les délais d’actualisation dans les entrepôts décisionnels
◆
Alléger les contraintes de planification des tâches de traitement
par lot
◆
Assurer des transferts de fichiers inter plate-forme à haute vitesse
entre des systèmes mainframe, UNIX, Linux et Windows
◆
Permettre aux plates-formes ouvertes de lire et d’écrire sur des
Datasets mainframe en utilisant des transferts de données
réellement hétérogènes
◆
Fournir une connectivité switch fabric à la fois en local et à longue
distance par le biais d’un réseau de stockage d’entreprise EMC
◆
Accélérer le déplacement des informations et permettre l’accès
aux données nécessaires à l’activité de l’entreprise sans créer de
goulots d’étranglement
◆
Gérer les traductions EBCDIC/ASCII au sein des serveurs de
systèmes ouverts
◆
Prendre en charge les canaux nommés (UNIX) pour les entrées et
les sorties de données (les utilisateurs peuvent acheminer
directement des données jusqu’à une base de données ou une
application tierce)
◆
Assurer la sécurité physique et logique des données
• Canaux susceptibles de se trouver au sein de l’infrastructure
de l’entreprise
• Possibilité de contrôler l’accès physique aux serveurs et aux
hôtes
◆
S’interfacer avec SRDF pour déplacer des données InfoMover
Un système de stockage Symmetrix est requis pour héberger le
stockage et le cache utilisés par InfoMover. EMC Solutions Enabler
est fourni avec InfoMover.
InfoMover nécessite les éléments matériels et logiciels suivants :
◆
Une version de z/OS prise en charge par IBM
◆
Un système de stockage Symmetrix connecté aux hôtes/serveurs
utilisés avec InfoMover
◆
Des volumes de stockage Symmetrix utilisés en tant que volumes
de transfert pour IFT
◆
Des volumes CKD situés les sous-systèmes Symmetrix qui seront
utilisés avec IFS
◆
ResourcePak Base (requis pour les installations mainframe)
◆
PowerPath® (requis pour les hôtes de systèmes ouverts)
◆
SRDF (facultatif)
InfoMover
207
Licences
Une licence InfoMover est nécessaire pour chaque hôte de système
ouvert (une licence est nécessaire par serveur). Le prix de la licence
est déterminé par le niveau de traitement SMP du serveur. Aucun
code de fonction sous licence (LFC) n’est nécessaire.
Remarque : InfoMover File System (IFS) n’est plus commercialisé. Sa
notification de fin de support est intervenue le 30 avril 2010.
Remarque : InfoMover IFT n’est plus commercialisé et sa fin de support aura
lieu le 31 décembre 2013.
z/OS Migrator
EMC z/OS Migrator est une fonction de migration de données basée
sur l’hôte pour les environnements mainframe qui prend en charge le
stockage hétérogène (notamment EMC, IBM et HDS) et utilise une
interface de gestion 3270 classique.
z/OS Migrator vous permet d’effectuer des migrations de volume
classiques ainsi que des mises en miroir de volume basées sur l’hôte.
Ensemble, ces fonctionnalités constituent les fonctions Volume Mirror
et Volume Migrator de z/OS Migrator.
z/OS Migrator vous offre également la possibilité de migrer vos
Datasets mainframe actifs (Datasets en ligne recevant des E/S) entre
des volumes logiques, ce qui permet d’avoir des volumes sources et
cibles de tailles différentes. Cette fonctionnalité est appelée migration
logique.
Pendant la migration logique, les données présentes au niveau du
Dataset logique (extension) sont envoyées d’un ensemble de volumes
à un autre, le déplacement des données s’effectuant sans interruption
ni fermeture des applications actives.
La capacité de z/OS Migrator à effectuer des migrations sans
interruption accroît fortement la flexibilité de ces dernières. Par
exemple, les migrations ne sont plus limitées aux nuits et aux
week-ends, qui sont souvent les seules périodes pendant lesquelles
les interruptions de service sont possibles.
z/OS Migrator vous permet d’effectuer les opérations suivantes :
208
◆
Introduire de nouveaux sous-systèmes de stockage en minimisant
les interruptions de service
◆
Permettre aux utilisateurs de récupérer facilement des UCB z/OS
en simplifiant la migration des Datasets vers des volumes de plus
grande taille (en combinant les volumes)
◆
Permettre la migration des données pendant que les applications
continuent de s’exécuter, en bénéficiant d’un accès complet aux
données en cours de migration, ce qui élimine les interruptions
de service généralement inévitables dans ces situations
◆
Éliminer la nécessité de coordonner les interruptions de service à
l’échelle de l’entreprise ainsi que les coûts associés en termes
d’activité
◆
Améliorer les performances des applications en permettant le
déplacement des Datasets peu performants vers des
volumes/baies de stockage moins utilisés
◆
Veiller à ce que toutes les métadonnées du système d’exploitation
reflètent précisément et en permanence l’emplacement et l’état
des Datasets en cours de migration
Technologie de migration
Les fonctions de migration au niveau du volume déplacent les
volumes logiques dans leur intégralité. La migration de volume
effectuée par z/OS Migrator est réalisée piste pour piste, sans se
soucier du contenu logique des volumes impliqués. La migration de
volume se termine par une permutation des volumes, sans aucune
interruption pour les applications qui utilisent les données situées
dessus.
Toutefois, il est souvent préférable de déplacer les Datasets à un
niveau plus granulaire. Ainsi, en plus de la migration de volume,
z/OS Migrator permet la migration logique, c’est-à-dire la migration
de Datasets individuels. Contrairement aux fonctions de migration
de volume, z/OS Migrator effectue les migrations de Dataset en
connaissant le contenu du volume et les métadonnées du système
z/OS qui décrivent les Datasets présents sur le volume logique.
Remarque : Consultez le document z/OS Migrator Product Guide pour plus
d’informations.
z/OS Migrator
209
Licences
L’activation du logiciel z/OS Migrator s’effectue en saisissant un
code de fonction sous licence (LFC). Le LFC est un nombre à
16 chiffres figurant sur la clé de licence EMC que vous avez reçue en
même temps que z/OS Migrator. Saisissez ce LFC dans la table de
paramètres d’initialisation SCFINI de ResourcePak Base. Une fois le
LFC saisi, la fonction sera activée. La marche à suivre pour appliquer
les LFC est indiquée dans les documents d’expédition. Vous
trouverez également des informations sur l’installation des clés de
licence dans le Guide d’installation et de personnalisation d’EMC
Mainframe Enablers.
210
8
Ce chapitre présente les solutions EMC de sauvegarde et d’archivage
dans l’environnement mainframe.
◆
◆
◆
◆
Introduction ......................................................................................
EMC Disk Library for Mainframe (DLm).....................................
EMC Centera Mainframe HSM Migrator.....................................
SDK EMC Centera Mainframe (kit d’outils API) ........................
212
213
216
223
211
Introduction
Solutions d’archivage et de sauvegarde fournies par EMC ou une
sélection de ses partenaires :
212
◆
EMC Disk Library for mainframe (DLm) est une solution de
remplacement des bandes qui permet aux clients d’améliorer
leurs performances, d’augmenter la fiabilité et de réaliser des
économies significatives en conservant les informations des
bandes sur disque plutôt que sur bande physique.
◆
La solution EMC Centera HSM Migrator fonctionne avec IBM
DFSMS, ce qui permet au système Centera de s’intégrer dans un
environnement de stockage géré par le système, généralement en
remplacement des bandes ML2.
◆
En proposant l’intégration des API mainframe pour sa
plate-forme de stockage dédié aux contenus Centera, EMC
garantit à ses clients z/OS un archivage en ligne économique.
EMC Disk Library for Mainframe (DLm)
La famille de solutions EMC Disk Library for Mainframe permet aux
utilisateurs des solutions IBM System z de remplacer leurs systèmes
de bandes physiques, ainsi que leurs systèmes de virtualisation de
bandes traditionnels tels qu’IBM VTS et Oracle/STK VSM, par une
solution dynamique sur bandes virtuelles capable de mettre fin aux
problèmes liés aux traitements traditionnels sur bandes.
EMC DLm est la seule solution sur bandes virtuelles pour Mainframe
fournissant à la fois un stockage avec et sans déduplication. Cela
permet aux entreprises d’utiliser une seule plate-forme pour tous les
exemples d’utilisation courants liés aux bandes dans un
environnement mainframe, le tout avec une base de code et un
tableau de bord uniques.
La solution DLm :
◆
réduit ou élimine les bandes physiques du datacenter
mainframe ;
◆
supprime les limites liées à la gestion traditionnelle des bandes
(intervention manuelle, déplacement physique des cartouches de
bande) et élimine les points uniques de défaillance ;
◆
accélère les opérations de traitement par lot, de sauvegardes et
d’archivage (notamment HSM) en tirant parti de disques au lieu
de bandes ;
◆
Fonctionne en toute transparence avec des applications existantes
faisant appel à des processus de gestion des bandes pour
automatiser le traitement de ces dernières ;
◆
S'adapte facilement à l'augmentation des charges de travail sans
ajout de sous-systèmes, de librairies, de connexions réseau, etc.,
qui ne font qu'accroître la complexité ;
◆
peut être mise à niveau sans interruption pour répondre à
l’augmentation des besoins en matière de stockage ou de
performances ;
◆
utilise la technologie de disque ATA avec protection RAID 6
(12+2) ainsi que des disques de secours pour une fiabilité accrue.
La famille DLm est constituée des produits suivants :
◆
DLm1000 pour les PME implémentant la déduplication
◆
DLm2000 pour les PME
213
◆
DLm6000 pour les grandes entreprises
Notez que les trois offres sont dotées d’une connexion FICON.
Aucune prise en charge ESCON n’est proposée.
DLm1000
Le DLm1000 est un rebranding du Bus-Tech MDL, devenu la solution
de sauvegarde mainframe avec stockage Data Domain en mars 2011.
Le DLm1000 joue le rôle de passerelle entre le mainframe et le
système de stockage Data Domain rattaché, en offrant une flexibilité
optimale et de nombreuses options de configuration. Le DLm1000 est
disponible en deux modèles afin de répondre aux différentes
exigences des clients en matière de prix et de traitement des données :
le DLm1010 (qui remplace le MDL-1000), doté d’une connexion
FICON unique au mainframe, et le DLm1020 (qui remplace le
MDL-2000), doté de deux connexions FICON au mainframe.
Le DLm1000 peut se connecter aux systèmes de stockage
Data Domain suivants (à condition qu’ils soient dotés de DDOS
version 5.0 ou ultérieure) : DD630, DD640, DD670, DD860, DD880 ou
DD890.
Le système Data Domain permet la déduplication sur bande, les
données pouvant dans certains cas être compressées par un facteur
de 20.
Pour plus d’informations sur le DLm1000, consultez le livre blanc
suivant :
Disk Library for Mainframe – DLm1000
DLm2000
Le DLm2000 fait partie de la troisième génération de la famille
EMC Disk Library for mainframe, qui rassemble des solutions de
remplacement des bandes pour environnement mainframe destinées
aux PME/TPE et aux grandes entreprises. Il remplace le DLm120 et
offre les améliorations suivantes par rapport à son prédécesseur :
Des VTE (Virtual Tape Engines) basés sur Intel Server System SR2600
procurant une rapidité jusqu’à 40 % supérieure à celle des serveurs
de la génération précédente
◆
214
Le logiciel Virtuent 7 s’exécute sur chacun des VTE
◆
Jusqu’à 680 Mo/s de débit avec deux VTE, soit une vitesse
supérieure de 70 % à celle offerte par le DLm120
◆
Un stockage back-end EMC VNX5300 pour les données sur
bande
◆
Une capacité de stockage pouvant passer de 13 à 143 To,
c’est-à-dire 50 % plus importante que celle offerte par le DLm120
◆
Une conception, des fonctionnalités et des tarifs adaptés aux
besoins des PME dotées d’environnements sur bande mainframe
Le DLm2000 offre les mêmes fonctions que le DLm6000, mais dans
une configuration plus modeste, adaptée aux clients ayant des
besoins inférieurs. Le DLm2000 peut aisément gérer les charges de
travail d’archivage, de sauvegarde HSM et de traitement par lot dans
les environnements mainframe des PME et des TPE.
suivant :
EMC Disk Library for Mainframe – DLm2000
DLm6000
Le DLm6000 est l’offre phare d’EMC Disk Library for mainframe
troisième génération. Il remplace le DLm960 et permet de bénéficier
des améliorations suivantes par rapport à son prédécesseur :
◆
des VTE (Virtual Tape Engines) basés sur le système SR2600
d’Intel et procurant une rapidité jusqu’à 40 % supérieure à celle
des serveurs de la génération précédente ;
◆
le logiciel Virtuent 7.x exécuté sur chaque VTE ;
◆
un stockage back-end EMC VNX7500 des données sur bande non
dédupliquées ;
◆
un stockage back-end EMC Data Domain DD890 des données sur
bande lorsque la déduplication est souhaitée.
Qu’il s’agisse de plates-formes de stockage avec déduplication ou
non, toutes peuvent être configurées indépendamment ou ensemble.
EMC a supprimé la condition selon laquelle la plate-forme de
stockage VNX® devait être installée avant que l’ajout du stockage
avec déduplication soit possible.
215
Le DLm6000 offre aux comptes Enterprise disposant d’un
environnement mainframe une solution de remplacement complet
des bandes. La combinaison des fonctionnalités de stockage avec et
sans déduplication dans une offre unifiée permet de gérer toutes les
données des clients au sein d’un seul et même produit. Les clients
peuvent ainsi stocker leurs données sur différents niveaux de
stockage.
suivant :
Disk Library for Mainframe – DLm6000
EMC Centera Mainframe HSM Migrator
EMC Centera Mainframe HSM Migrator est un module logiciel qui
s’exécute sur mainframe z/OS. Il permet au système de stockage
EMC Centera de se connecter à DFSMShsm (Data Facility Storage
Management Subsystem) et d’utiliser des sorties utilisateur standard
pour archiver les données sur EMC Centera. EMC Centera
Mainframe HSM Migrator facilite le déplacement des données et
l’ILM en déplaçant automatiquement les données de
l’environnement mainframe IBM vers Centera.
Le logiciel s’exécute sur le mainframe et intègre un moteur de règles
pour déterminer quels fichiers mainframe doivent être archivés.
Essentiellement, il adapte la fonction de migration de DFSMShsm
Space Management pour utiliser Centera comme périphérique de
sortie. Il intercepte les demandes de migration et de rappel envoyées
vers ML1 et les redirige vers Centera. Ce processus n’implique aucun
DASD, ni aucune émulation de bande. En fait, le système Centera
n’est pas généré en tant que périphérique ; au lieu de cela, il est
rattaché à une IP et n'est pas reconnu comme périphérique rattaché à
un canal. Cela permet à Centera de remplacer à la fois le DASD ML1
et la bande ML2, et rend possible la migration Dataset par Dataset. Il
se comporte comme un DASD ML1 de taille illimitée et élimine
toutes les opérations de gestion de la bande ML2 telles que le
recyclage et la copie de reprise après sinistre. De plus, les utilisateurs
et les tâches ne sont absolument pas affectés.
216
Cette opération s’effectue en arrière-plan et de manière transparente
pour les administrateurs système et les utilisateurs. Le rappel est
totalement transparent pour l’utilisateur ou l’application. Le résultat
final permet à EMC Centera de devenir un élément transparent de
l’infrastructure DFSMShsm. Cette configuration est illustrée à la
Figure 43, page 217.
Symmetrix
DFSMShsm address space
Centera
HSM
HSM
MCDS
DFSMSdss Data Mover
DFSMShsm Exits
Centera
CDS
ARCMDEXT
(Migration)
ARCRPEXT
(Recall)
ARCINEXT
(Init & Setup)
Centera API
TCP/IP
ICO-IMG-000820
Figure 43
Centera Mainframe HSM Migrator
Ce produit a été conçu avec les sorties DFDSMhsm publiées, qui sont
prises en charge par IBM. EMC Centera Mainframe HSM Migrator
est commercialisé et pris en charge par EMC en tant qu’extension
spécialisée de DFSMShsm. Via l’archivage sur EMC Centera, les
utilisateurs bénéficient de ses fonctions d’autogestion pour un
stockage efficace des données et une authenticité garantie du
contenu. Le processus de stockage d’EMC Centera, basé sur les
objets, fournit une réponse adéquate aux problèmes de fiabilité et de
performances habituellement rencontrés avec les systèmes sur
bandes, et garantit un archivage consolidé et unifié.
La demande des clients pour des disques de capacité supérieure croît
à mesure que le volume de données augmente. Tous secteurs
confondus, les entreprises tendent parallèlement à réduire leurs
dépenses tout en recherchant une efficacité opérationnelle accrue et
en assurant un service plus performant auprès de la clientèle grâce à
un accès facilité aux données. EMC Centera s’intègre
particulièrement bien dans ce contexte. Basé sur l’archivage actif en
ligne, ce système est doté de fonctions d’autogestion,
d’autoréparation et d’autosurveillance.
217
EMC Centera Mainframe HSM Migrator est une solution destinée
aux entreprises et aux organisations qui possèdent une infrastructure
HSM de plusieurs téraoctets, comme les établissements financiers, les
industries et les services de santé. La gestion du stockage hiérarchisé
permet aux clients d’automatiser les processus critiques associés aux
supports destinés à recevoir les données et de limiter les coûts
inhérents aux supports et à la gestion. Le logiciel s’adresse également
aux entreprises procédant à la migration de grands volumes de
données faisant l’objet de suppressions régulières.
Les clients soumis à des règles de gouvernance internes ou à la
réglementation en vigueur peuvent utiliser EMC Centera pour
fournir des copies en lecture seule de leurs Datasets archivés. EMC
Centera constitue par ailleurs une solution pour les professionnels
recherchant un système économique de réplication de leurs Datasets
archivés, afin de garantir la continuité d’activité et la reprise après
sinistre.
Avantages
En supprimant les bandes comme support d’archivage pour les
données ML1, EMC Centera HSM Migrator améliore l’efficacité de
DFSMShsm à de nombreux égards :
Performances : les environnements de grande taille sont
particulièrement chronophages pour les opérations de rappel. EMC
Centera HSM Migrator supprime les opérations de montage et de
positionnement des bandes, rationalisant ainsi le processus de rappel.
Recyclage : le processus de recyclage nécessite de coûteuses
ressources mainframe (MIPS). EMC Centera résout ce problème en
fournissant une capacité de stockage ML1 quasi illimitée.
Reprise après sinistre et conformité : des problèmes de conformité
peuvent se présenter lorsque les données sont transférées d’une
bande à l’autre afin de mieux gérer la capacité des bandes. La
fonction de réplication d’EMC Centera garantit que les données
archivées sont accessibles en ligne, ce qui simplifie considérablement
les demandes d’extraction de données aux fins de gouvernance
d’entreprise ou de respect des exigences réglementaires et constitue
une solution idéale pour la reprise après sinistre.
218
Caractéristiques
Intégration de DFSMShsm
◆
Les fonctions MIGRATE et RECALL sont applicables à tous les
Datasets VSAM et NON-VSAM pris en charge.
◆
Les Datasets individuels peuvent être supprimés pour éliminer le
processus RECYCLE et réduire le nombre de MIPS utilisés.
Performances et utilisation des ressources
◆
Exécution simultanée de plusieurs processus : EMC Centera
Mainframe HSM Migrator n’impose aucune restriction à
l’exécution simultanée de plusieurs processus de migration et
prend intégralement en charge les processus MIGRATE et
RECALL de DFSMShsm.
◆
Les Datasets rappelés depuis EMC Centera ne sont pas soumis
aux limitations imposées au montage des bandes physiques.
◆
Simulation de commande de DFSMShsm : les commandes d’EMC
Centera Mainframe HSM Migrator ont été conçues pour simuler
plusieurs commandes HSM, réduisant ainsi considérablement le
temps nécessaire pour se familiariser avec le logiciel.
• Un administrateur peut rapidement déterminer où un
ensemble de données a été migré (ML1 ou EMC Centera) en
utilisant des commandes similaires aux commandes HSM.
• Un administrateur peut également émettre une commande
afin de migrer des Datasets directement vers EMC Centera
sans s’interfacer avec DFSMShsm. Les performances sont ainsi
améliorées puisque la migration ne s’exécute pas dans l’espace
d’adressage de DFSMS.
Haute disponibilité
◆
EMC Centera Mainframe HSM Migrator est totalement
compatible avec l’environnement Parallel Sysplex.
◆
Prise en charge des sauvegardes : EMC Centera HSM Migrator
peut facultativement être configuré pour migrer des données vers
EMC Centera, uniquement s’il existe une sauvegarde du Dataset.
◆
Restauration d’une banque de données de contrôle à partir des
métadonnées : lorsqu’une banque de données de contrôle est
perdue, elle peut être reconstruite à partir des contenus de
métadonnées stockées dans EMC Centera.
219
◆
Réplication à distance : en utilisant les fonctions de réplication à
distance d’EMC Centera, toutes les données archivées sur EMC
Centera peuvent être répliquées de manière asynchrone sur un
système EMC Centera secondaire situé sur un site de reprise
après sinistre distant où elles peuvent être immédiatement
accessibles.
Gestion du système
L’écran ISPF fournit un aperçu en temps réel du fonctionnement de
HSM Migrator. Il génère des rapports sur les Datasets en cours de
migration, en cours de rappel et en cours de suppression, ainsi que
sur les Datasets dans la file d’attente de rappel. Il fournit également
un état des commandes d’EMC Centera Mainframe HSM Migrator
qui ont été exécutées. Par ailleurs, il consigne toutes les actions
MIGRATE et RECALL, qu’elles aient abouti ou non.
Voici quelques exemples de rapports disponibles par le biais d’EMC
Centera Mainframe HSM Migrator :
◆
Rapport d’activité HSM Migrator
◆
Rapport des migrations différées
◆
Rapport des migrations actives
◆
Rapports de suppression
◆
Rapports d’extraction d’audit
◆
Rapports d’erreurs
De plus, une fonction d’extraction permet au système de s’interfacer
avec des outils de reporting externes, tels que MXG et SAS. La
fonction Extraction permet la création d’une image de fichier plat
contenant des informations sur tous les Datasets gérés par EMC
Centera. Cette fonction peut être employée pour surveiller la mise en
œuvre du système afin de s’assurer que les Datasets sont migrés
correctement, résumer les activités quotidiennes, étudier les modes
d’utilisation des Datasets et fournir des informations à des fins de
refacturation.
220
Migration différée
Cette fonction permet à une installation de laisser des Datasets
migrés sur le stockage de niveau 0 jusqu’à ce que les informations
migrées soient répliquées par EMC Centera. Il est possible d’écrire
des données sur le cluster EMC Centera principal. EMC Centera
copie ensuite de manière asynchrone ces informations sur un autre
EMC Centera. Cette fonction permet de différer la suppression du
contenu des Datasets de niveau 0 jusqu’à ce que HSM Migrator ait
vérifié que les Datasets correspondants sur le stockage EMC Centera
ont été répliqués sur un cluster EMC Centera distant. Cette fonction
est uniquement disponible pour les Datasets non VSAM.
Configuration système
La configuration système requise est la suivante :
◆
Mainframe série z ou compatible
◆
IBM z/OS version 1.6 ou supérieure
◆
DFSMShsm et DFSMSdss version 1.6 ou supérieure
◆
Accès TCP/IP depuis le mainframe vers un cluster EMC Centera
◆
EMC Centera avec EMC CentraStar® version 2.4 ou supérieure
◆
Périphérique DASD 100 Mo pour le support d’installation d’EMC
Centera Mainframe HSM Migrator
◆
Périphérique DASD pour la banque de données de contrôle
d’EMC Centera Mainframe HSM Migrator
◆
BMC Control-D : automatise et intègre tous les aspects de la
gestion des sorties à l’échelle de l’entreprise, élimine les erreurs
humaines, améliore le débit des informations et optimise
l’utilisation des ressources. Control-D : gère l’ensemble des
activités de gestion des sorties à l’échelle de l’entreprise tout en
rationalisant les coûts connexes.
◆
Mobius ViewDirectTCM : solution répondant à toutes les
exigences des entreprises en matière de stockage, d’accès et de
fourniture de contenus, quels que soient le format et la source des
données.
Partenaires Centera
221
◆
Systemware : solution logicielle d’intégration de contenus
d’entreprise prenant en charge la capture, la gestion, l’indexation,
l’archivage et la présentation de grands volumes d’informations
d’entreprise sur différentes plates-formes à partir d’un référentiel
virtuel centralisé et évolutif.
◆
Beta Systems : logiciel de gestion des sorties conçu pour traiter
des volumes d’impression conséquents et différents formats. Les
flux de données d’impression peuvent provenir de n’importe
quelle application, sur une plate-forme UNIX, Windows ou
mainframe.
◆
SI Software LDMS : stocke toutes les données de différentes
applications aussitôt qu’elles sont créées et les archive
automatiquement. Lorsqu’il est implémenté sur les systèmes
z/OS, LDMS permet à des milliers d’utilisateurs d’accéder
simultanément aux données archivées depuis différents
emplacements, même si elles proviennent du même document.
◆
Solutions RSD : garantissent un accès rapide et sécurisé aux
données critiques de l’entreprise grâce à la gestion de son
contenu. L’intégration transparente de RSD avec EMC Centera
fournit à l’utilisateur les avantages d’une extraction aisée de
toutes les informations nécessaires aux processus métiers via un
client léger Web RSD ou une application d’entreprise
personnalisée.
La fonction d’archivage de base de données permet d’archiver les
données actives avec les métadonnées associées.
222
◆
Princeton Softech Active Archive for DB2 : convertit de façon
sécurisée les données relationnelles structurées dans le format
non structuré et à contenu fixe qu’exige EMC Centera. Les
solutions Active Archive préservent l’intégrité des informations
de référence complexes d’intégrité et de métadonnées nécessaires
pour accéder facilement au contenu des bases de données.
◆
EMC BusTech Mainframe Appliance for Storage (MAS) :
automatise et gère intelligemment l’archivage des données d’un
mainframe IBM sur un système EMC Centera. Avec cette
puissante solution intégrée, EMC Centera fournit un stockage
d’archivage centralisé à la fois fiable et sécurisé qui permet aux
clients d’exploiter des ressources à contenu fixe accessibles à tout
moment et en tout lieu.
◆
Intercom Computer Systems GmbH : apporte la connectivité
mainframe via une émulation de disque optique et de lecteur de
bande pour solutions EMC.
Produits associés à Centera
Le chapitre « Matériel mainframe », page 27 fournit des informations
détaillées sur le matériel Centera.
Licences
La licence Centera Mainframe HSM Migrator fonctionne par
incréments de quatre nœuds EMC Centera.
SDK EMC Centera Mainframe (kit d’outils API)
L’API EMC Centera permet aux applications mainframe IBM z/OS
d’accéder directement au système Centera. Les applications intégrées
envoient directement leurs informations au système EMC Centera via
IP par le biais de l’adaptateur OSA (Open Systems Adapter) interne
au mainframe, sans nécessiter d’émulateur externe.
Les partenaires EMC Centera répertoriés dans le Tableau 16 ont
intégré leurs applications avec EMC Centera via l’API EMC Centera.
Tableau 16
Partenaires utilisant l’API EMC Centera pour intégrer leurs solutions
Partenaire
Version de l’application
(minimale)
Type d’application
BMC
Control-D V6.0.03
ECM
Beta Systems
ViDiDOC-Beta 93
ECM
Mobius
ViewDirectTCM 6.3
ECM
Princeton Softech
Active Archive V5.1
DB Archive
RSD
EOS/Folders 4.1
ECM
Systemware
Xptr V4.1
ECM
SDK EMC Centera Mainframe (kit d’outils API)
223
L’intégration native via l’API EMC Centera est la solution
d’archivage mainframe z/OS la plus riche en fonctionnalités. En
outre, elle élimine toute gestion des bandes et des unités optiques.
Produits associés
Le chapitre « Matériel mainframe », page 27 fournit des informations
détaillées sur le matériel Centera.
Licences
Aucune licence n’est nécessaire pour le SDK EMC Centera
Mainframe (API).
224
9
Ce chapitre présente les produits EMC assurant la compatibilité dans
un environnement mainframe :
◆
◆
◆
◆
◆
◆
◆
◆
◆
Introduction ......................................................................................
Prise en charge de JES .....................................................................
Présentation des produits EMC Compatible ...............................
Compatible Flash for z/OS.............................................................
Compatible Native Flash for Mainframe......................................
Compatible Extended ......................................................................
Compatible Peer ...............................................................................
Extended Remote Copy Enhanced Multiple Reader ..................
PPRC/XRC Incremental Resync....................................................
226
227
228
229
231
236
238
240
244
225
Introduction
La compatibilité mainframe des produits EMC est assurée par les
investissements financiers continus réalisés dans différentes licences
de technologies mainframe de premier plan, IBM représentant bon
nombre de fonctionnalités et de fonctions dans ce domaine. Ces
licences font l’objet de contrats pluriannuels renouvelables qui
permettent à EMC d’implémenter les différentes fonctions de façon
plus opportune et plus exhaustive, ce qui se traduit généralement par
des capacités nettement améliorées par rapport aux offres IBM
équivalentes. De plus, EMC poursuit ses investissements en
personnel et en matériel mainframe pour garantir une fourniture
opportune de toutes les caractéristiques et fonctions sous licence.
EMC dispose de licences pour les fonctions suivantes :
◆
Réplication IBM
• z/OS Global Mirror (anciennement XRC)
• Metro Mirror (anciennement PPRC)
• GDPS
• FlashCopy
• Extended Remote Copy (XRC) Enhanced Multiple Reader
• PPRC/XRC Incremental Resync
◆
Gestion des volumes IBM
• Parallel Access Volume (PAV)
• Dynamic Parallel Access Volume (DPAV)
• HyperPAV
• Multiple Allegiance (MA)
• Modified Indirect Data Address Word (MIDAW)
• Extended Address Volume (EAV)
◆
Autres technologies
• Priority I/O Queuing
• Nouveaux CCW 2107
• Concurrent Copy
• Control Unit Initiated Reconfiguration (CUIR)
• Sequential Data Striping
• Partitioned Dataset Search Assist
226
EMC a par ailleurs réalisé d’importants investissements dans des
installations comme le GDPS Lab. Ses offres de produits logiciels et
matériels y sont développées et testées au sein de l’environnement
GDPS, au moyen d'une approche régressive des technologies
actuelles et anticipées. Cela permet de tester l’exploitation des
fonctions et de garantir la satisfaction des clients une fois que la suite
de produits est déployée et intégrée à leurs différents
environnements.
Prise en charge de JES
JES2 et JES3 sont des sous-systèmes IBM de soumission de tâches. La
majorité des produits logiciels mainframe EMC, mais pas tous, sont
compatibles JES3.Le Tableau 17 indique les produits EMC
compatibles JES2 et JES3, et ceux qui sont uniquement compatibles
JES2.
Tableau 17 Compatibilité JES3
Compatible JES2 uniquement
Compatible JES2 et JES3
AutoSwap
TimeFinder/Clone Mainframe SNAP Facility
EMC z/OS Storage Manager (EzSM)
TimeFinder/Mirror
EMC GDDR
TimeFinder Utility
EMC Compatible Flash
Consistency Group
Symmetrix SRDF Host Component
ResourcePak Extended for z/OS
Prise en charge de JES
227
Présentation des produits EMC Compatible
EMC propose à ses clients des capacités de réplication mainframe
équivalentes à celles offertes par IBM, notamment Compatible Flash
et Compatible Native Flash pour les copies ponctuelles internes,
Compatible Peer pour la réplication à distance, et Compatible
Extended pour la réplication asynchrone des données mainframe.
Ces produits permettent aux clients mainframe de déployer la
technologie de réplication via le système EMC Symmetrix, qui est
compatible avec les fonctions spécifiques d'IBM fournies par
FlashCopy, Metro Mirror et z/OS Global Mirror.Le Tableau 18 décrit
les principales fonctions offertes par les produits EMC Compatible.
Tableau 18 Produits EMC Compatible
228
Produit EMC
Compatibilité avec (produit IBM) Fonction du produit
Compatible Flash
FlashCopy
Réplication en local
Compatible Native Flash
FlashCopy
Réplication en local
Compatible Extended
z/OS Global Mirror
Réplication à distance
Compatible Peer
Metro Mirror
Extended Remote Copy
(XRC)
Enhanced Multiple
Reader
z/OS Global Mirror Multiple
Reader
PPRC/XRC Incremental
Resync
z/OS Metro/Global Mirror
Incremental Resync (RMZ
Resync)
Compatible Flash for z/OS
Cette section et ses sous-sections décrivent Compatible Flash for
z/OS, disponible sur tous les sous-systèmes Symmetrix DMX
exécutant Enginuity 5772 ou une version antérieure. Il est inclus ici
par souci d’exhaustivité.
Remarque : Pour tous les sous-systèmes Symmetrix DMX-3 et DMX-4
exécutant Enginuity 5773 ou une version ultérieure, et pour tous les
sous-systèmes VMAX (le VMAX nécessite Enginuity 5873 ou une version
ultérieure), Compatible Native Flash for Mainframe est la seule option
compatible FlashCopy disponible. Compatible Native Flash for Mainframe
est abordé dans la section suivante.
Compatible Flash for z/OS permet aux commandes IBM FlashCopy
d’être exécutées en utilisant un système EMC Symmetrix. Compatible
Flash intercepte et interprète les instructions de canal IBM FlashCopy
sur l’hôte z/OS, puis émule l’exécution des commandes sur les
systèmes de stockage EMC Symmetrix.
Cela est rendu possible par les technologies EMC TimeFinder/Clone
Mainframe Snap Facility et EMC ResourcePak Base for z/OS.
Compatible Flash for z/OS s’exécute sous la forme d’un
environnement intégré dans EMC Symmetrix Control Facility
(EMCSCF), au sein d’EMC ResourcePak Base for z/OS, et s’active par
le biais d’un code de fonction sous licence (LFC).
Compatible Flash prend en charge les éléments suivants :
◆
Fonctionnalités d’IBM FlashCopy versions 1 et 2
• Copies au niveau du volume et du Dataset
• Source et cible sur des LSS identiques ou différents au sein
d’une baie de stockage EMC
• FlashCopy à relations multiples
• FlashCopy incrémentiel avec Reverse Restore, au niveau du
volume
• Persistent FlashCopy
• Groupes de cohérence FlashCopy
◆
Sous-systèmes Symmetrix et versions d’EMC Enginuity
• Systèmes Symmetrix 8xxx, avec Enginuity 5568 et versions
supérieures
Compatible Flash for z/OS
229
• Systèmes Symmetrix DMX, avec Enginuity 5670 et 5671
• Systèmes Symmetrix DMX 3, avec Enginuity 5771 et 5772
Les commandes Compatible Flash peuvent être émises uniquement à
destination de périphériques CKD (Count Key Data), et ne peuvent
pas être utilisées avec les périphériques FBA.
Remarque : Le document EMC Compatible Flash for z/OS User Guide fournit
des informations supplémentaires concernant les caractéristiques et les
limitations du produit.
Compatible Flash permet aux sites mainframe de continuer à utiliser
IBM FlashCopy sur les baies de stockage EMC. Cela constitue un
chemin de migration simple pour les clients passant des
sous-systèmes IBM DS8xxx aux baies Symmetrix.
Les fonctions Compatible Flash respectent les instructions d’IBM en
matière de technologies avec licences croisées.
EMC propose TimeFinder en tant que produit de réplication en local
(réplication au sein d’un même système Symmetrix) et SRDF en tant
qu’outil de réplication à distance (entre deux sous-systèmes
Symmetrix, généralement en utilisant SRDF/Synchronous pour les
courtes distances, SRDF/Asynchronous pour les longues distances et
SRDF/Data Mobility pour les transferts de données).
EMC fournit les logiciels associés avec TimeFinder ou SRDF.
Les produits EMC Compatible nécessitent les éléments logiciels et
matériels suivants :
230
◆
Une version de z/OS prise en charge par IBM avec JES2.
◆
Les produits de compatibilité doivent s’exécuter sur des
sous-systèmes Symmetrix dotés du niveau de code Enginuity
adéquat.
De plus, Compatible Flash nécessite EMC ResourcePak Base
version 5.6 ou supérieure et EMC TimeFinder /Clone Mainframe
Snap Facility version 5.6 ou supérieure. Ces deux produits doivent
être installés pour que Compatible Flash puisse être activé.
Licences
Pour les systèmes Symmetrix, Compatible Flash for z/OS fait l’objet
d’une licence par sous-système. Un code de fonction sous licence
(LFC) est requis pour activer Compatible Flash. Le LFC de
Compatible Flash for z/OS peut être installé via ResourcePak Base.
Compatible Native Flash for Mainframe
Compatible Native Flash for Mainframe est une implémentation
compatible de la fonction IBM FlashCopy disponible sur les
sous-systèmes Symmetrix VMAX. Cette solution est différente de
Compatible Flash for z/OS, comme cela est expliqué plus loin dans
les sous-sections « Logiciels et solutions associés » et « Conditions
préalables ». Cette fonction est fournie par EMC pour offrir à ses
clients un niveau de compatibilité équivalent à la fonctionnalité de
stockage mainframe spécifique à IBM.
Compatible Native Flash for Mainframe permet de réaliser jusqu’à
12 copies de chaque volume ou Dataset source en fonction des
besoins. Les instructions de canal FlashCopy peuvent être exécutées
depuis l’environnement z/OS en utilisant les interfaces
d’environnement fournies par :
◆
DFSMSdss
◆
DFSMShsm
◆
TSO
◆
ICKDSF
◆
ANTRQST
231
EMC Compatible Native Flash for Mainframe est une
implémentation compatible entièrement intégrée au sein d’Enginuity.
Elle prend en charge les commandes FlashCopy émises via les
interfaces ESCON et FICON définies par IBM pour l’environnement
System z. Compatible Native Flash for Mainframe simplifie et rend
transparente la coexistence des sous-systèmes Symmetrix VMAX
avec d’autres sous-systèmes concurrents offrant cette fonction,
comme les sous-systèmes IBM DS8000, Hitachi Tagmastore et HP
XP24000. Cette fonction était nécessaire du fait de son intégration
croissante dans les logiciels hôtes IBM, comme la prise en charge par
DFSMShsm des fonctions DB2 de restauration de copie ponctuelle du
système et de restauration au niveau de l’objet.
Les capacités de FlashCopy sont utilisées dans un large éventail
d’environnements opérationnels pour offrir des fonctionnalités telles
que :
◆
Sauvegarde de l’environnement de production
◆
Sauvegarde régulière des données
◆
Copie de données à des fins de data mining
◆
Utilisation de données dans les environnements de test
◆
Utilisation de données pour le test d’applications ou la gestion
des versions
FlashCopy permet d’accéder en quelques secondes aux
volumes/Datasets nouvellement copiés, réduisant ainsi la nécessité
d’attendre la fin de la copie comme c’était le cas avec les méthodes
précédentes. De plus, cette fonction élimine la copie des données
lorsque certaines parties de la source et de la copie sont identiques.
Voici un résumé des principaux avantages qu’offre Compatible
Native Flash :
232
◆
Il fait gagner du temps, réduit la consommation de ressources et
offre une meilleure intégration avec les systèmes z/OS.
◆
Il minimise le délai entre la demande de copie et la disponibilité
de la copie pour traitement ultérieur.
◆
Il élimine, lorsque c'est possible, la copie des données lorsque des
sous-ensembles de la source et de la copie sont identiques.
◆
Il réduit la charge au niveau du canal et du processeur en
déplaçant la charge de travail liée à la copie vers le sous-système
Symmetrix.
◆
Il améliore les performances pour les classes d’applications
faisant appel à des services de copie locaux.
◆
Il offre une meilleure intégration avec les logiciels qui exploitent
FlashCopy comme les utilitaires DB2, et DFSMSdss COPY et
DEFRAG.
◆
Il contribue à simplifier l’environnement opérationnel des clients
qui veulent absolument mettre en œuvre une politique de
stockage hétérogène et utilisent FlashCopy.
Compatible Native Flash for Mainframe est très similaire au logiciel
basé sur l’hôte Compatible Flash for z/OS. L’une des différences
majeures est que Compatible Native Flash prend en charge d’autres
systèmes d’exploitation mainframe que z/OS. Une autre différence
importante réside dans le fait que Compatible Native Flash n’exige
pas l’installation d’un logiciel basé sur l’hôte, car l’émulation
FlashCopy est entièrement exécutée dans EMC Enginuity.
Compatible Native Flash for Mainframe nécessite Enginuity 5773 ou
version supérieure sur les plates-formes DMX 3 et DMX 4, et
Enginuity 5873 ou version supérieure sur le VMAX. Il tire parti des
améliorations les plus récentes en matière de snapshot étendu et de
clonage de volume complet. Il s’agit d’une fonction de
compatibilité DS8000 qui nécessite un sous-système Symmetrix de
l’une des gammes susmentionnées rattaché à un processeur System z
exécutant z/OS version 1.6 ou supérieure. La prise en charge d’autres
logiciels IBM permet de rendre ces fonctions disponibles dans les
environnements z/VM, z/TPF et z/VSE.
Compatible Native Flash for Mainframe est disponible sous la forme
d’une option distincte sur les sous-systèmes Symmetrix DMX 3,
DMX 4 et VMAX. Son activation/désactivation est réalisée au sein du
sous-système Symmetrix par un membre du personnel du Support
Clients d’EMC, et sa gestion s’effectue via les fonctions standard de
z/OS. De plus, elle ne nécessite aucun logiciel EMC basé sur l’hôte
spécifique.
233
Licences
Compatible Native Flash for Mainframe est une fonction nécessitant
une licence. Son activation est réalisée sur la baie Symmetrix par un
membre du Support Clients d’EMC.
Limitations et restrictions
Voici les limitations et les restrictions actuelles de Compatible Native
Flash :
234
◆
Compatible Native Flash ne prend pas en charge les niveaux de
code antérieurs à Enginuity 5773.
◆
Les périphériques FBA ne sont pas pris en charge.
◆
La fonction FlashCopy ne peut pas coexister avec les snapshots
étendus Symmetrix au niveau du volume. Toutefois, EMCSNAP
fournit une option SITEOPTION pour indiquer à EMCSNAP
d’envoyer des commandes FlashCopy à la baie Symmetrix. Si
cette option est activée, toutes les nouvelles opérations de
snapshot seront présentées comme des commandes FlashCopy.
◆
Une prise en charge spéciale est fournie pour la transition vers
l’utilisation de FlashCopy. Pour les relations de snapshots
existantes, une fois que l’option SITEOPTION a été définie sur
FlashCopy, EMC fournit un processus de conversion pour les
snapshots existants. Une commande TimeFinder Clone
Mainframe Snap Facility (ou EMCSNAP) CLEANUP avec
FORCE COMPLETION est disponible pour forcer la finalisation
des snapshots existants et réaliser une mise en file d’attente à
l’échelle de l’ensemble du système sur le volume afin d’empêcher
la création de nouveaux snapshots. Cela retarde la création de
nouveaux snapshots, mais aucune interruption de service n’est
nécessaire. Les applications des clients n’ont pas besoin d’être
mises en veille, mais il y a un laps de temps pendant lequel de
nouveaux snapshots ne peuvent pas être créés (pendant qu’ils
attendent la mise en file d’attente). Dans un environnement non
sysplex, il s’agit d’une réserve au niveau du volume.
◆
En mode FlashCopy, toutes les fonctions de snapshot ne peuvent
pas être converties en fonctions FlashCopy pour offrir une prise
en charge complète (notamment les snapshots en cascade et les
snapshots entre périphériques sur des séparations DMX
différentes). Toutefois, si EMCSNAP est utilisé, il est possible de
poursuivre la création de snapshots en cascade même lorsque des
commandes FlashCopy sont envoyées.
◆
Les commandes FlashCopy conçues pour s’exécuter dans
l’environnement PPRC Asynchronous ne sont pas prises en
charge (parce qu’EMC ne prend actuellement pas en charge PPRC
Asynch).
◆
Compatible Native Flash prend en charge un plus petit nombre
d’extensions actives par volume qu’IBM, ce qui peut entraîner
des problèmes de performances dans les environnements
complexes.
◆
Les commandes FlashCopy à distance (commandes FlashCopy
envoyées via des liaisons Metro Mirror (anciennement PPRC),
anciennement In-Band FlashCopy) ne sont pas prises en charge.
◆
Lorsqu’une session FlashCopy NOCOPY est active, les lectures
destinées au côté cible entraînent la copie des données de la
source vers la cible, ce qui se traduit par une augmentation de la
charge et peut avoir un impact sur les performances.
◆
FlashCopy SE (Space Efficient) est émulé en utilisant FlashCopy
sur un périphérique thin avec l’option NOCOPY.
235
Compatible Extended
Compatible Extended est un produit EMC Compatible de réplication
à distance similaire au logiciel IBM z/OS Global Mirror. Il fait l’objet
d’une licence croisée entre EMC et IBM, et augmente la protection de
la gamme IBM System z, de z/OS et des environnements de stockage
EMC. SRDF est le logiciel EMC de référence en matière de réplication
à distance, et Compatible Extended vise à compléter l’offre SRDF afin
de proposer plus de choix à nos clients.
EMC permet aux utilisateurs de créer et de partager des copies
distantes basées sur le mainframe entre les plates-formes EMC, les
plates-formes de stockage Hitachi et les plates-formes de stockage
IBM compatibles. EMC propose la configuration de la réplication à
distance basée sur z/OS Global Mirror, la rédaction des scripts
d’automatisation, la formation et les services professionnels
d’implémentation requis pour fournir un environnement z/OS
Global Mirror optimisé.
IBM fournit le logiciel hôte nécessaire pour utiliser ce produit. Ce
produit ne requiert aucun logiciel EMC. Pour des informations
détaillées concernant les caractéristiques et l’utilisation de z/OS
Global Mirror, reportez-vous aux publications IBM applicables.
Voici certains des avantages et des exemples d’utilisation de
Compatible Extended :
236
◆
Un sous-système Symmetrix doté de Compatible Extended peut
fonctionner en tant qu’unité de contrôle du stockage source ou
cible (ou les deux) dans un environnement z/OS Global Mirror.
◆
Un sous-système Symmetrix doté de Compatible Extended est
entièrement compatible avec l’environnement GDPS.
◆
Les fonctions Compatible Extended respectent les instructions
d’IBM en matière de technologies avec licences croisées.
EMC fournit les logiciels hôtes associés avec TimeFinder ou SRDF.
Les produits Compatible Extended nécessitent les éléments logiciels
et matériels suivants :
◆
Une version de z/OS prise en charge par IBM, avec JES2 ou JES3.
◆
adéquat.
Licences
Pour les systèmes Symmetrix, Compatible Extended fait l’objet d’une
licence par sous-système. Aucun code de fonction sous licence (LFC)
n’est nécessaire.
Compatible Extended
237
Compatible Peer
Compatible Peer est un produit EMC Compatible de réplication à
distance similaire au logiciel IBM Metro Mirror (anciennement
PPRC). Il fait l’objet d’une licence croisée entre EMC et IBM, et
augmente la protection de la gamme IBM System z, de z/OS et des
environnements de stockage EMC. SRDF est le logiciel EMC de
référence en matière de réplication à distance, et Compatible Peer vise
à compléter l’offre SRDF afin de proposer plus de choix à nos clients.
Remarque : La section « Protection des informations », page 149 fournit de
plus amples informations sur la famille de produits SRDF.
Compatible Peer est compatible avec toutes les versions de z/OS
prises en charge. Il s’agit d’une solution matérielle offrant une copie à
distance efficace et en temps réel des volumes ainsi qu’une solution
de reprise après sinistre exploitant la mise en miroir synchrone entre
deux sous-systèmes Symmetrix. Les solutions IBM, Hitachi et EMC
compatibles avec Metro Mirror exigent que les unités source et cible
proviennent du même fournisseur.
IBM fournit tous les logiciels hôtes exigés pour utiliser ce logiciel. Ce
produit ne requiert aucun logiciel EMC. Pour des informations
détaillées concernant les caractéristiques et l’utilisation de Metro
Mirror, reportez-vous aux publications IBM applicables.
Compatible Peer :
238
◆
Un sous-système Symmetrix doté de Compatible Peer peut
fonctionner en tant qu’unité de contrôle du stockage source et/ou
cible dans un environnement Metro Mirror.
◆
Un sous-système Symmetrix doté de Compatible Peer est
entièrement compatible avec l’environnement GDPS.
◆
Les fonctions Compatible Peer respectent les instructions d’IBM
en matière de technologies avec licences croisées.
EMC fournit les logiciels hôtes associés avec TimeFinder ou SRDF.
Compatible Peer nécessite les éléments logiciels et matériels
suivants :
◆
Une version de z/OS prise en charge par IBM avec JES2 ou JES3.
◆
adéquat.
Licences
Pour les systèmes Symmetrix, Compatible Peer fait l’objet d’une
licence par sous-système. Le prix est déterminé par le niveau de
stockage du sous-système Symmetrix. Aucun code de fonction sous
licence (LFC) n’est nécessaire.
Compatible Peer
239
Extended Remote Copy Enhanced Multiple Reader
Compatible z/OS Global Mirror Multiple Reader (Multi Reader) est
une amélioration compatible IBM permettant aux mises à jour d’un
ensemble de volumes donné d’être réparties uniformément sur
plusieurs sidefiles du cache. Un lecteur hôte est fourni pour chaque
sidefile, permettant ainsi une plus grande efficacité dans le
déchargement parallèle des mises à jour vers l’ensemble de volumes
par le System Data Mover (SDM). Cette solution permet également
de décharger les enregistrements des sidefiles du cache en exploitant
la technologie PAV (Parallel Access Volume) La technologie PAV est
décrite en détail dans les livres blancs New Features in EMC Enginuity
5773 for Symmetrix Mainframe Environments et Exploiting HyperPAV in
EMC Symmetrix DMX Environments.
Primary side
Secondary side
z/OS
z/OS
z/OS
z/OS
z/OS
z/OS
z/OS
System Data Mover
Only 1 utility device to
read from sidefile
Writes
Vol 001
primary
BOTTLENECK
Session 1001 cache
sidefile:
V3,T0,R1
Vol 001
secondary
V2,T2,R2
Vol 002
primary
V3,T1,R6
V1,T4,R3
Vol 002
secondary
V2,T8,R5
Vol 003
primary
...
Vol 003
secondary
ICO-IMG-000956
Figure 44
240
Topologie XRC avec lecteur unique
La Figure 44, page 240 illustre la topologie de l’environnement avec
lecteur unique dans lequel un flux d’E/S unique est envoyé au Data
Mover (SDM) Les sidefiles consomment du cache et cette
consommation peut atteindre des niveaux élevés lorsque le débit de
lecture du SDM ne peut pas suivre le débit d’écriture du système de
production. Sans correction, cela peut entraîner un certain nombre
d’opérations d’adaptation du flux d’entrée, notamment l’adaptation
du flux d’entrée en lecture ou la suspension des sessions de
microcode XRC. Dans les cas les plus extrêmes, les systèmes de
production peuvent être affectés par des temps d’attente prolongée.
Les sessions avec lecteurs multiples sont semblables aux sessions
avec lecteur unique, à la différence que les périphériques peuvent
appartenir à chacune (ou l’ensemble) des sessions associées (et non à
une seule session XRC avec lecteur unique). L’implémentation des
lecteurs multiples par IBM permet d’associer 16 sessions entre elles,
une session primaire et jusqu’à 15 sessions auxiliaires. En général, les
périphériques appartiennent à toutes les sessions associées, même si
cela n’est pas obligatoirement le cas. L’implémentation
d’Enginuity 5875 prend en charge une session primaire et 13 sessions
auxiliaires.
241
Primary side
Secondary side
z/OS
z/OS
z/OS
z/OS
z/OS
z/OS
3 utility devices reading
from 3 sidefiles
(can be aliases)
Writes
Vol 001
primary
Vol 002
primary
Vol 003
primary
z/OS
System Data Mover
5001 SF
5002 SF
5003 SF
V3,T0,R1
V1,T3,R0
V3,T1,R1
V2,T2,R2
V2,T1,R4
V1,T3,R3
V3,T1,R6
V3,T5,R2
V2,T7,R5
V1,T6,R3
V1,T4,R5
V2,T2,R1
V2,T8,R5
V3,T6,R1
V1,T0,R0
...
...
...
Vol 001
secondary
Vol 002
secondary
Vol 003
secondary
ICO-IMG-000940
Figure 45
Topologie XRC avec lecteurs multiples
La Figure 45 illustre la topologie avec lecteurs multiples. Chaque
session avec lecteurs multiples possède son propre sidefile, doté de
son propre ensemble de numéros de séquence, tout comme dans une
session avec lecteur unique. Un périphérique doit appartenir à une
session avec lecteurs multiples spécifique pour avoir des entrées dans
le sidefile de cette session, comme pour une session avec lecteur
unique. Une session avec lecteur unique peut être convertie en
session primaire avec lecteurs multiples en réenregistrant l’identifiant
de session en tant que session avec lecteurs multiples. Les entrées
existantes du sidefile sont conservées. De même, une session primaire
avec lecteurs multiples peut être convertie en session avec lecteur
unique si aucune session auxiliaire n’est associée à la session
primaire. Cette opération peut être effectuée en réenregistrant
l’identifiant de session en tant que session avec lecteur unique. De
plus, une session auxiliaire avec lecteurs multiples peut être convertie
en session primaire en réenregistrant l’identifiant de session comme
session primaire.
242
Toute adresse logique du sous-système logique (LSS) peut à présent
être utilisée pour lire à partir des sidefiles de la session. La lecture
peut être effectuée depuis une adresse d’alias, notamment HyperPAV
(HPAV). Une seule lecture à la fois peut être exécutée depuis chaque
sidefile.
Du fait qu’il implémente de multiples flux d’E/S parallèles, Extended
Remote Copy (XRC) Enhanced Multiple Reader permet d’améliorer
de façon significative la capacité de l’environnement Global Mirror
en termes de débit d’E/S. C’est une option à prendre en compte dans
les environnements Global Mirror gérant un trafic d’E/S élevé.
Extended Remote Copy (XRC) Enhanced Multiple Reader respecte
les instructions d’IBM en matière de technologies avec licences
croisées.
SRDF/A exploite une technologie Delta Set, qui offre une alternative
bien plus robuste à Global Mirror (XRC).
Remarque : La section « Protection des informations », page 149 fournit plus
d’informations sur SRDF/A.
Exigences matérielles et logicielles pour Extended Remote Copy
(XRC)
Enhanced Multiple Reader nécessite les éléments matériels et
logiciels suivants :
◆
z/OS version 1.7 ou supérieure
◆
Un environnement Global Mirror
◆
Des sous-systèmes Symmetrix VMAX avec Enginuity 5875 ou
une version supérieure
243
PPRC/XRC Incremental Resync est une solution de réplication
asynchrone à longue distance et sans perte de données qui est
intégrée à l’offre de services GDPS MzGM d’IBM. GDPS MzGM est
requis pour cette fonction. Généralement, lorsque les clients utilisent
un produit de réplication asynchrone comme XRC, ils s’attendent à
perdre des données en cas de sinistre. C’est l’essence même de la
réplication asynchrone. En fusionnant la réplication synchrone
(PPRC) et la réplication asynchrone (XRC), tout risque de perte de
données est éliminé. Cette fonction exige la présence d’Enginuity
5875 sur les deux sous-systèmes PPRC Symmetrix.
La Figure 46 illustre la configuration nécessaire pour atteindre cet
objectif : un site A de production en local doté de volumes configurés
en tant que PPRC primaires répliqués sur un autre ensemble de
volumes (volumes secondaires) situés au niveau du site B (site
secondaire). De plus, les deux PPRC primaires du site A et les PPRC
secondaires du site B sont configurés en tant que XRC primaires pour
le même ensemble de XRC secondaires situés sur le site C. Enfin, la
session XRC du site A vers le site C est active, alors que la session
XRC du site B vers le site C est suspendue.
Site A
PPRC
XRC
Active
Site B
XRC
Suspended
Site C
ICO-IMG-000938
Figure 46
244
Environnement Incremental Resync
PPRC/XRC Incremental Resync est un composant important de la
solution haute disponibilité et de reprise après sinistre qui peut être
configurée pour diverses applications en fonction des besoins en
mettant en œuvre une automatisation totale ainsi qu’un basculement
sur incident et un retour arrière totalement transparents. Elle a pour
principal avantage de permettre le redémarrage rapide sur le site
distant en cas de défaillance du site primaire à un niveau quelconque.
PPRC/XRC Incremental Resync respecte les instructions d’IBM en
matière de technologies avec licences croisées.
L’offre GDDR d’EMC avec topologie sur deux ou trois sites peut offrir
des fonctions similaires ou supérieures en termes de préservation de
la disponibilité des applications ou du site.La section « Protection
des informations », page 149 fournit plus de détails sur l’offre GDDR.
PPRC/XRC Incremental Resync nécessite les éléments matériels et
logiciels suivants :
◆
z/OS version 1.7 ou supérieure.
◆
Un environnement GDPS MzGM
◆
Des sous-systèmes Symmetrix VMAX avec Enginuity 5875 ou
une version supérieure
Remarque : Seule la prise en charge des volumes CKD (z/OS) est disponible
avec Enginuity 5875. La prise en charge des volumes FBA (z/VM) est
actuellement envisagée pour une version future d’Enginuity.
245
246
10
Considérations relatives
aux performances
Ce chapitre présente les fonctions orientées performances qu’offre
EMC pour les environnements mainframe :
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
◆
Introduction ......................................................................................
Parallel Access Volumes (PAV) ......................................................
Multiple Allegiance .........................................................................
Modified Indirect Data Address Word (MIDAW).......................
FICON................................................................................................
FICON 8 Gbit/s................................................................................
High Performance FICON (zHPF) ................................................
Multitrack High Performance FICON (zHPF multitrack) .........
Extended Address Volumes (EAV)................................................
Persistent IU Pacing (Extended Distance FICON) ......................
QoS Dynamic Cache Partitioning ..................................................
QoS Symmetrix Priority Control (SPC).........................................
Copy QoS ..........................................................................................
Disques Flash EMC..........................................................................
248
249
254
255
256
258
260
265
266
269
270
272
275
276
247
Introduction
La famille Symmetrix possède un solide historique de performances
exceptionnellement élevées dans l’environnement z/OS. Ce chapitre
décrit bon nombre des fonctions de performances associées à z/OS et
aux sous-systèmes Symmetrix configurés pour cet environnement.
Une parfaite connaissance de ces fonctions permet au personnel
technique de réaliser des configurations d'E/S Symmetrix hautement
optimisées et d’obtenir ainsi un débit élevé pour leurs applications à
des coûts nettement réduits.
Les sous-systèmes Symmetrix offrent notamment des fonctions de
performances uniques comme Dynamic Cache Partitioning et
Symmetrix Priority Control (présentées en détail dans les sections
suivantes) qui, implémentées ensemble ou séparément, fournissent à
l’utilisateur un niveau élevé de précision en matière de contrôle des
performances. Ce degré de contrôle est destiné aux charges de travail
prioritaires ou problématiques que l’on rencontre souvent dans les
environnements consolidés de grande envergure.
La grande flexibilité qu’offre la famille Symmetrix en termes de
possibilités de configuration et de choix de technologies lui permet
de répondre aux exigences de performances et de coûts des clients les
plus exigeants. Cette flexibilité est rendue évidente par la possibilité
de faire évoluer le sous-système de façon parfaitement asymétrique
en ajoutant exactement les performances et la capacité nécessaires
pour faire face aux besoins de croissance, que celle-ci soit naturelle ou
inattendue.
À ce jour, la majorité des fonctions de performances pour z/OS (et les
plus importantes) ont été implémentées par EMC. Elles sont décrites
en détail dans le présent document pour familiariser l’utilisateur avec
les caractéristiques liées au matériel et à Enginuity.
◆
Parallel Access Volumes (PAV)
• PAV statique
• Dynamic Parallel Access Volume (DPAV)
• HyperPAV
248
◆
Multiple Allegiance (MA)
◆
Modified Indirect Data Address Word (MIDAW)
◆
FICON
◆
FICON 8 Gbit/s
◆
◆
Multitrack High Performance FICON (zHPF multitrack)
◆
Prise en charge des volumes de grande capacité (Extended
Address Volumes/3390 Model A)
◆
Persistent IU Pacing (Extended Distance FICON)
En plus de ce qui précède, EMC propose des fonctions qui améliorent
nettement les performances des charges de travail hétérogènes
consolidées :
◆
QoS Dynamic Cache Partitioning
◆
QoS Symmetrix Priority Control
◆
FAST
Gérer le problème des temps de mise en file d’attente des E/S (IOSQ)
L’architecture System z, comme bon nombre de celles qui l’ont
précédée, a été conçue pour permettre le traitement d’une seule E/S
active à la fois sur un volume logique. Une fois celle-ci terminée, une
autre E/S peut être traitée sur le volume. Cela s’est révélé très
contraignant, car les charges de travail ont évolué vers des profils
d’accès aux données plus intensifs, et les tentatives d’envoi d’une
autre E/S à un périphérique occupé se soldent par une mise en file
d’attente dans Input Output Supervisor (IOS) de z/OS, ce qui se
traduit par une accumulation des temps IOSQ. Des améliorations
étaient clairement nécessaires pour lutter contre ce problème de
temps IOSQ. Ces améliorations ont pris la forme d’alias. Il s'agit
d'une (ou plusieurs) adresses de périphérique vers lesquelles l’E/S
peut être dirigée lorsqu’un volume donné est adressé.
Remarque : S’attaquer au problème des temps IOSQ pour les ramener à zéro
ou les maintenir à un niveau bas est essentiel pour exploiter de gros volumes
de données. Cela définit une condition nécessaire mais non suffisante pour
l’exploitation des EAV, qui seront abordés ultérieurement.
249
Deux types d’alias pouvaient être définis : les alias statiques, qui
étaient liés à leur adresse de base de manière fixe et étaient appelés
PAV statiques (Parallel Access Volumes), et les alias dynamiques, qui
permettaient de définir un certain nombre d’alias sur une adresse de
base déterminée, ceux-ci pouvant être réattribués à une autre base en
fonction des besoins. Ces alias étaient appelés PAV dynamiques. Ils
sont illustrés à la Figure 47, page 250.
Static PAVs
Dynamic PAVs
HyperPAVs
Aliases
Aliases
Alias pool
Base volumes
Base volumes
Base volumes
ICO-IMG-000830
Figure 47
PAV statiques, PAV dynamiques et HyperPav
PAV statiques
Les PAV statiques offraient les fonctions élémentaires permettant de
rendre un volume accessible via son adresse de base ou via des
adresses d’alias attribuées à cette base. En raison de la nature
relativement dynamique des charges de travail, et donc des exigences
associées en termes d’E/S, les PAV statiques ont rapidement laissé
place aux PAV dynamiques, qui intégraient la possibilité de s’ajuster
de façon dynamique aux évolutions des modèles d’accès à un volume
donné.
PAV dynamiques
Comme les PAV statiques, les PAV dynamiques étaient associés à des
adresses d’alias liés à une adresse de base donnée, mais permettaient
d’attribuer et de réattribuer un alias à des adresses de base autres$
que celle à laquelle il avait été initialement attribué. Utilisés de cette
façon, les PAV dynamiques se comportaient comme des pools, mais
impliquaient un ajustement de la part du composant Workload
Manager (WLM) de z/OS pour affecter l’alias à une autre base.
250
Ce délai d’ajustement, et le temps global nécessaire pour effectuer le
changement, atteignaient généralement plusieurs minutes, ce qui a
suscité de nombreuses critiques du fait de la nature très dynamique
qui caractérise les charges de travail de production exigeantes
d’aujourd’hui.
L’utilisation intensive des PAV, et en particulier des PAV dynamiques,
a contribué à éliminer une bonne partie des conjectures répétitives
associées au positionnement des données, aussi bien au sein d’un
volume qu’entre plusieurs volumes. Cet aspect était particulièrement
important pour les administrateurs de bases de données, qui
devaient sans cesse effectuer la corvée que constitue le
positionnement méticuleux des données. Cette focalisation sur le
positionnement des données au niveau du volume (réglage du
volume) a été remplacée par le réglage au niveau du sous-système.
Cela s’est traduit par une forte réduction du temps jusqu’alors
consacré par le personnel à « régler finement » l’organisation des
bases de données et les paramètres associés. En fait, la majorité des
migrations agressives des volumes 3390 model-3 vers les volumes
3390 model-9 ou 3390 model-27 et même 3390 model-54 ont été
attribuables aux gains de performances et de parallélisme, rendus
possibles par les PAV dynamiques.
HyperPAV
HyperPAV constitue une amélioration majeure par rapport aux PAV
statiques et dynamiques, car il peut adapter les performances des E/S
à des charges de travail stables, croissantes et même décroissantes.
Cela conduit à penser que les PAV auraient dû être conçus de cette
manière dès l’origine.
HyperPAV est né de la nécessité de raccourcir le délai d’ajustement
rencontré avec les PAV dynamiques pour le rendre compatible avec
les charges de travail les plus exigeantes lorsqu’elles en ont le plus
besoin. Il a également été développé pour répondre à la diversité des
besoins en termes d’E/S pour la prise en charge des volumes de
grande capacité (au-delà des volumes 3390 model-54). De plus,
HyperPAV vise à régler bon nombre d’autres problèmes affectant de
nombreux environnements de production, notamment en matière
d’allégement des contraintes UCB, en plus d’un certain nombre
d’autres problèmes anticipés.
251
En se basant sur les PAV dynamiques, la première difficulté
rencontrée dans l’élaboration d’HyperPAV a été la nécessité de
prendre en charge davantage de réactivité et des niveaux supérieurs
de parallélisme des E/S. Cette nécessité découle entièrement de
l’augmentation massive de la puissance de traitement des
Mainframes et de l’accroissement de l’intensité des E/S des
applications associées qui s’en est suivi. En fait, ce besoin de
parallélisme des E/S est la conséquence naturelle d’un certain
nombre de facteurs convergents. Les deux facteurs principaux sont le
déploiement à grande échelle de la connectivité FICON et la
migration de plus en plus fréquente vers des volumes de plus grande
taille.
Remarque : Les PAV statiques et dynamiques ont constitué une étape
intermédiaire au début de l’exploitation de la connectivité FICON, et leur
successeur HyperPAV est devenu le principal mécanisme permettant de
réellement tirer parti de tous les atouts de FICON. Le contrôleur Symmetrix
VMAX prend en charge les volumes HyperPAV et la connectivité FICON.
HyperPAV améliore et étend les fonctions des PAV statiques et
dynamiques en réagissant de façon plus rapide et plus dynamique
aux changements des caractéristiques d’accès d’un volume de disque,
ce qui permet de faire face aux pics imprévus d’accès au volume tout
en maintenant des temps de service bas et stables. Cela permet de
répondre aux divers besoins en termes de performances des
applications dont les taux de transactions passent très rapidement de
niveaux très bas à des niveaux très élevés, que ce soit par
intermittence ou de façon continue. Ces applications sont par
exemple celles qui doivent faire face à l’explosion des transactions
liées aux échanges d’actions au moment de l’ouverture des marchés,
ou celles qui assurent les vérifications et les autorisations de carte de
crédit les jours de forte activité chez les commerçants.
Remarque : De manière générale, les applications et les charges de travail
montrant des pics importants par rapport au taux de transactions moyen
(supérieur à 1,6) constituent des candidates naturelles pour HyperPAV, car
cette caractéristique du trafic est généralement symptomatique d’un
clustering des E/S, et donc d’une présence persistante de temps IOSQ
importants.
Sa capacité à prendre en charge un très grand nombre d’opérations
d’E/S en parallèle rend HyperPAV indispensable pour gérer des
accès multiples à des périphériques de plus grande capacité, tant
aujourd’hui que demain.
252
HyperPAV intègre plusieurs améliorations liées aux PAV statiques et
dynamiques.
Tout d’abord, la gestion de l’attribution des alias aux adresses de base
est plus efficace, car elle est effectuée par Input Output Supervisor
(IOS) et non par Workload Manager (WLM), lequel nécessitait un
délai d’ajustement plus long.
Ensuite, les alias sont définis dans un pool unique par sous-système
logique (LSS). Chaque LSS représente un regroupement logique de
256 adresses (base et alias). Pour prendre en charge 65 536 adresses, le
nombre de LSS configurables serait de 256. Lors de l’initialisation des
LPAR individuelles, ou lors d’une « variation en ligne » du
sous-système vers une ou plusieurs LPAR, les alias au sein des LSS
respectifs du sous-système d’E/S sont à leur tour communiqués à la
LPAR respective, formant ainsi un pool d’alias au sein de chaque
LPAR de l’environnement Sysplex. Ce pool d’alias (ou pools d’alias
LCU) au sein d’une LPAR individuelle est utilisé par IOS en fonction
des besoins pour diriger les E/S vers un UCB déjà occupé. Pour
chaque E/S, un alias est prélevé dans ce pool de façon à répondre aux
besoins de toute base située dans son LSS respectif, puis est replacé
dans le pool une fois qu’il n’est plus nécessaire. Les E/S dotées d’une
priorité IORP attribuée par WLM (abordé ultérieurement) sont
prioritaires lors de la sélection des alias disponibles. Ce concept de
mise en pool offre des performances nettement accrues par rapport
aux PAV dynamiques, tout en mobilisant moins d’alias. Par
conséquent, la réutilisation des alias est optimisée et la quantité
d’adresses d’alias nécessaires nettement réduite.
Enfin, en fournissant à IOS, pour chaque LPAR, un pool d’alias
éligibles à partir duquel un alias peut être lié à une base pour la durée
de l’E/S, les ressources z/OS consommées, en plus du sous-système
DASD (Symmetrix), sont rendues nettement plus agiles, et donc plus
efficaces. Cette « latence de ciblage » quasiment nulle permet de
satisfaire les besoins en E/S des charges de travail les plus lourdes de
façon extrêmement efficace, et contribue à accroître significativement
les débits de transactions.
253
Multiple Allegiance
Avant la fonction Multiple Allegiance (MA), le sous-système de
stockage ne pouvait autoriser qu’un seul programme de canal à être
actif sur un volume de disque à un instant donné et pour un hôte
unique. Par conséquent, une fois que le sous-système avait accepté
une demande d’E/S pour une adresse de périphérique particulière,
cette dernière apparaissait comme occupée pour les demandes d’E/S
ultérieures, ce qui se traduisait par une mise en file d’attente de ces
dernières. Ce comportement est appelé « allégeance unique » et vise à
préserver l’intégrité des données en n’autorisant aucune action
susceptible d’altérer les données tant qu’une autre demande est en
cours.
Avec la fonction MA le sous-système de stockage est doté d’une
capacité d’allégeance multiple, c’est-à-dire qu’il peut autoriser
l’exécution simultanée de plusieurs demandes issues de plusieurs
hôtes à destination d’un même volume. Concrètement, le
sous-système de stockage met les demandes d’E/S en file d’attente et
exécute simultanément plusieurs demandes à destination de la même
adresse de périphérique tant qu’il n’y a pas de conflit au niveau des
extensions adressées. Par définition, un conflit peut se produire soit
en cas d’inclusion d’une demande RESERVE par un programme de
canal, soit en cas de demande WRITE sur une extension déjà en cours
d’utilisation.
Tous les sous-systèmes Symmetrix commercialisés depuis 2002
(Symmetrix 8000) prennent en charge la fonction MA. Cette prise en
charge se poursuit dans la famille Symmetrix VMAX.
254
Le mécanisme MIDAW est une fonction CCW qui a été ajoutée à
z/Architecture pour coexister avec l’ancien mécanisme IDAW
(Indirect Data Address Word). Il est conçu pour améliorer les
performances FICON sur System z en offrant un mécanisme plus
efficace pour le chaînage des données CCW dans les programmes de
canal. Plus spécifiquement, il permet aux canaux d’exécuter de
manière séquentielle une liste de commandes de stockage ou
d’extraction en utilisant un seul accès négocié à la mémoire
principale.
Le concept d’adressage indirect n’est pas nouveau. En fait, le
mécanisme IDAW, le prédécesseur de MIDAW, et qui est toujours
utilisé à l’heure actuelle, imposait un accès plus restrictif parce qu’il
pouvait pointer sur une adresse située n’importe où au sein d’une
page, et les commandes IDAW suivantes devaient adresser le
stockage avec des limites de page. Autre restriction, toutes les
commandes IDAW (dans une même liste), sauf la première et la
dernière, devaient transférer des blocs de données complets de 2 ou
4 Ko. Cela rend les commandes IDAW particulièrement inadaptées
au traitement de certains Datasets Extended Format (EF), car ceux-ci
contiennent à la fois des blocs de données et un descripteur de bloc
étendu de 32 octets pour chaque bloc de données. Inversement, les
commandes MIDAW peuvent transférer des données d’une longueur
quelconque vers et depuis n’importe quel emplacement mémoire.
MIDAW diminue la charge exercée au niveau du canal, du directeur
et de l’unité de contrôle en réduisant le nombre de CCW et de trames
à traiter. De plus, du fait qu’il n’est pas soumis aux restrictions qui
affectent IDAW en matière de limite de page et de longueur de
données, MIDAW peut être utilisé dans de nombreux exemples
d’utilisation où IDAW s’avère inutilisable.
Avantages
MIDAW accroît l’efficacité du canal FICON en augmentant le nombre
d’E/S pouvant être traitées par seconde, ce qui se traduit par une
augmentation de la quantité de données transférées.
Remarque : MIDAW est particulièrement efficace avec DB2, VSAM, PDSE
(Partitioned dataset Extended), HFS (Hierarchical File System), zFS (z/OS
File System) et les autres Datasets exploitant la répartition et la compression.
255
Exigences
MIDAW nécessite un système Symmetrix DMX-3 ou supérieur
exécutant un niveau de code Enginuity actuel. Il nécessite également
un processeur System z9 ou supérieur exécutant z/OS 1.6 ou
supérieur. System z9 intègre des améliorations significatives en
termes de performances d’E/S par rapport à son prédécesseur, le
z990. MIDAW peut être activé en définissant une option
(MIDAW=YES) dans le membre IECIOSxx de SYS1.PARMLIB.
D’un point de vue purement applicatif, aucune modification n’est
nécessaire au niveau des applications pour tirer parti des commandes
MIDAW. Elles sont simplement activées en procédant comme
expliqué ci-dessus, puis sont insérées dans le programme de canal
créé par le composant Media Manager de z/OS, à la seule condition
que les exigences indiquées soient remplies.
FICON
D’un point de vue fonctionnel et structurel, la prise en charge FICON
de la plate-forme Symmetrix VMAX est équivalente à celle de la
plate-forme Symmetrix DMX. Les fonctions sont réparties entre les
processus EMULATION et LINK, et il n’y a aucun changement au
niveau des relations et des responsabilités de ceux-ci. Toutefois, il est
important d’avoir à l’esprit le fait qu’un certain nombre de
changements de terminologie sont intervenus entre les baies
Symmetrix DMX et Symmetrix VMAX. Avec le DMX, les termes CPU
EMULATION et CPU LINK sont utilisés. Avec le Symmetrix VMAX,
les termes utilisés sont Instance EMULATION et Instance LINK.
Une tranche DMX, qui se compose d’un CPU EMULATION et d’un
CPU LINK, est appelée paire EMULATION/ LINK (instance) sur la
baie Symmetrix VMAX.
Enginuity 5874 avec une baie Symmetrix VMAX a introduit la prise
en charge de deux ports pour les instances FICON et fournit la prise
en charge d’un total de 64 canaux FICON. Chaque nœud haute
disponibilité (HA) d’une baie Symmetrix VMAX contient deux
directeurs. Comme le montre la Figure 48, page 257, chaque carte
directrice est dotée de huit cœurs de CPU (côté gauche du
diagramme), chacun d’eux prenant en charge une instance statique
de sorte que celle-ci est liée à son cœur respectif. Quatre de ces
instances statiques fournissent quatre émulations DA pour la
connectivité des périphériques. Lorsque le directeur est configuré
256
pour FICON, les quatre autres instances fournissent deux émulations
FICON (EF 7E et EF 7G, en prenant par exemple le directeur 7) par
directeur. Ces deux émulations FICON par directeur peuvent prendre
en charge deux ports FICON chacune. Par conséquent, quatre ports
FICON par directeur et huit ports FICON par nœud HA sont pris en
charge, comme le montre la partie droite du diagramme. Une baie
Symmetrix VMAX peut être configurée avec un nœud HA au
minimum et huit au maximum. Par conséquent, un sous-système
intégralement configuré pour FICON peut prendre en charge de 8 à
64 ports FICON indépendants entièrement provisionnés.
Inst 1
Core e
Inst 2
Core e
Inst 3
QUAD
CORE
CPU
Core
Global
Memory
Core
Inst 4
Core
Inst 5
Core
Memory
QUAD
CORE
CPU
Inst 6
Core
Inst 7
Inst 8
Local
mem (LM)
Core
IO
Module
EF-7G
EE
EE
EF
EF
EE
EE
EF-7E
DA-7D
EF
EF
DA
DA
EF-8E
DA-8D
DA-7C
DA
DA
DA-8C
DA-7B
DA
DA
DA-8B
DA-7A
DA
DA
DA-8A
Dir 7
IO
Module
IO
Module
IO
Module
EF-8G
Dir 8
HA NODE
ICO-IMG-000833
Figure 48
Un nœud haute disponibilité (HA) unique dans un contrôleur VMAX
Il s'agit de la première solution à plusieurs ports pour FICON à être
proposée sur l’ensemble des familles Symmetrix. De plus,
contrairement aux implémentations ESCON antérieures, ces deux
ports FICON sont des ports indépendants entièrement provisionnés
et fonctionnent en tant que tels. Chaque paire d’instances FICON
peut prendre en charge un ou deux ports, les deux ports physiques
étant gérés par l’instance LINK (tranche EE). Pour toute paire
d’instances FICON, l’un des ports ou les deux peuvent être câblés
physiquement. Le module d’E/S FICON Emulex est doté de deux
connecteurs SFP, un pour chaque port. Les noms de port universels
(WWPN) sont basés sur la tranche EF.
FICON
257
Remarque : Du point de vue des performances, la structure à deux ports de
l’interface FICON permet à chacun de ces deux ports d’offrir l’intégralité des
capacités de l’interface (IOPS ou Mbit/s). Cela est utile dans les situations
d’accès asymétrique par des LPAR, car chaque LPAR peut tirer parti de
l’intégralité des capacités de l’interface dans la mesure où celle-ci n’est pas
simultanément exploitée par l’autre LPAR.
Comme la baie Symmetrix VMAX ne peut être configurée qu’en tant
qu’unité de contrôle de type 2107, toutes les commandes de canal
définies dans les jeux de commandes et de fonctions 2107 sont prises
en charge. De plus, FICON prend en charge un jeu de commandes
basé sur le 3370, ce qui permet d’accéder aux périphériques FBA
(Fixed Block Architecture). Toutes les tailles de périphériques 3380 et
3390 standard sont prises en charge, en plus de diverses tailles
personnalisées.
FICON 8 Gbit/s
Annoncée par IBM en juillet 2009, la connectivité FICON sur la
plate-forme Symmetrix a été améliorée pour offrir la prise en charge
du FICON 8 Gbit/s. Cela permet de connecter la baie Symmetrix
VMAX aux processeurs System z10 Enterprise Class et Business Class
en utilisant un débit de données de 8 gigabits par seconde.
L’avantage le plus évident du FICON 8 Gbit/s est qu’il offre une
bande passante accrue, adaptée aux applications très gourmandes. Il
permet aussi aux clients d’intégrer facilement leurs sous-systèmes
Symmetrix VMAX dans les nouvelles générations d’infrastructures
réseau compatibles 8 Gbit/s dès qu’ils le souhaitent.
Resource Management Facility (RMF) a été amélioré pour prendre en
charge le FICON 8 Gbit/s, notamment au niveau des rapports
Channel Activity Report et FICON Director Activity Report. Le
rapport Channel Activity Report contient trois nouvelles valeurs
dans le sous-champ G (identifiant de génération) du champ PATH,
qui sont interprétés de la manière suivante :
258
◆
La valeur 7 correspond au FICON 8 Gbit/s fonctionnant en tant
que FICON 2 Gbit/s
◆
que FICON 4 Gbit/s
◆
que FICON 8 Gbit/s
La prise en charge de la nouvelle connectivité FICON 8 Gbit/s a été
mise en œuvre avec un minimum de changements au microcode
d’émulation dans Enginuity.
La connectivité FICON 8 Gbit/s offre une compatibilité descendante
complète et prend en charge l’autonégociation de la vitesse de liaison
vers des vitesses inférieures (2 ou 4 Gbit/s) si nécessaire pour
s’adapter aux infrastructures d’E/S et réseau existantes.
La connectivité FICON 8 Gbit/s est basée sur la puce Emulex
Saturn IOC540. Il s'agit d'un contrôleur Fibre Channel multiprotocole
à double port dérivé de la même famille LightPulse de contrôleurs FC
Emulex que le contrôleur Zephyr (4 Gbit/s) qui était implémenté
dans le Symmetrix VMAX au moment de son lancement. Le
Saturn IOC540 est une extension du produit précédent.
La nécessité d’offrir l’accélération matérielle et un tampon interne
pour maintenir des débits élevés avait conduit à doter le contrôleur
Saturn de moins de buffer credits que son prédécesseur Zephyr,
limitant ainsi la distance globale de la liaison à 10 kilomètres pour
8 Gbit/s ou à 20 kilomètres pour 4 Gbit/s. Le Zephyr prend en
charge des distances atteignant 100 kilomètres.
Remarque : Les baies Symmetrix VMAX équipées du contrôleur Saturn
n’offrent aucune prise en charge du FICON 1 Gbit/s. Toutefois, les modules
d’E/S 1/2/4 Gbit/s actuels (Zephyr) peuvent coexister avec les nouveaux
modules d’E/S 2/4/8 Gbit/s (Saturn). Cela constitue un point important
pour les clients souhaitant mettre à niveau leur infrastructure d’E/S en vue
d'offrir la prise en charge 8 Gbit/s tout en préservant la prise en
charge 1 Gbit/s.
Enginuity permet de mettre à niveau le microcode Emulex du
module d’E/S 8 Gbit/s (pour les deux ports) de manière cohérente
avec le script SymmWin Emulex Load pour les modules d’E/S
4 Gbit/s.
La connectivité FICON 8 Gbit/s est prise en charge dans les mêmes
combinaisons FICON, FC et GigE que le module d’E/S
FICON 4 Gbit/s dans les baies Symmetrix VMAX. Les modules
d’E/S FICON 8 Gbit/s peuvent être mélangés avec des modules
d’E/S 4 Gbit/s au sein d’un même boîtier. La connectivité
FICON 8 Gbit/s fonctionne en conjonction avec High Performance
FICON (zHPF) pour assurer des niveaux encore supérieurs de débit
d’E/S et de bande passante. zHPF est abordé à la section suivante.
FICON 8 Gbit/s
259
Exigences
Les exigences en termes de matériel et de système d’exploitation de la
connectivité FICON 8 Gbit/s sont les suivantes :
◆
FICON 8 est disponible exclusivement avec System z10 (codes de
fonction 3325, 3326) et System z196.
◆
z/OS version 1.8 ou supérieure (avec les PTF appropriés ;
consultez le compartiment DEVICE PSP 2097)
◆
z/OS version 1.7 avec IBM Lifecycle Extension for z/OS 1.7
(5637-A01) est nécessaire pour prendre en charge la fonction
FICON Express8 avec le serveur z10
◆
z/VM version 5.3 ou supérieure
◆
z/VSE version 4.1 ou supérieure
◆
z/TPF version 1.1 ou supérieure
◆
TPF version 4.1 avec PUT 16
◆
Linux on System z comme suit :
• Novell SUSE SLES 9, SLES 10 et SLES 11
• Red Hat RHEL 4 et RHEL 5
High Performance FICON (zHPF) est une version améliorée de
l’architecture de l’interface FICON visant à accroître
significativement les performances de traitement des charges de
travail OLTP. Enginuity 5874 prend uniquement en charge le zHPF
monopiste. La prise en charge du zHPF multipiste (zHPF multitrack)
a été introduite dans Enginuity 5875. zHPF est une fonction payante
nécessitant une licence distincte pour les sous-systèmes IBM.
Toutefois, il est inclus gratuitement dans le bundle Mainframe
Essentials pour les baies Symmetrix VMAX (pas pour Symmetrix
DMX).
260
Le protocole utilisé pour implémenter zHPF est FC-SB-4 (Fibre
Channel Single Byte Command Set–4). La spécification FC-SB-4
définit un nouveau protocole nommé Transport Mode (TM). Il s’agit
d’un protocole de commande à faible charge qui vient compléter le
protocole Command Mode existant (hérité) du FICON. Le protocole
Transport Mode introduit le concept de « mot de commande de
transport » (Transport Command Word - TCW). Le terme de
transport est utilisé parce que ce protocole est conçu pour déplacer de
grandes quantités de données (jusqu’à 4 Go par E/S) avec des
interactions limitées entre l’unité de contrôle et le canal. Les
programmes de canal Transport Mode sont incorporés à un CDB SCSI
modifié et suivent le protocole Fibre Channel de manière plus étroite.
Le pilote d’E/S (par exemple Media Manager) décide si l’E/S doit
être effectuée en utilisant les chaînes de « mots de commande de
canal » (Channel Command Words - CCW) hérités ou les nouveaux
programmes de canal Transport Mode. L’exécution via les CCW
hérités est qualifiée de Command Mode, alors que les opérations
d’E/S exécutées à l’aide de zHPF sont qualifiées de Transport Mode.
Les deux protocoles peuvent coexister sur les mêmes canaux et unités
de contrôle.
Un programme de canal FICON non-zHPF consiste en une série de
CCW formant une chaîne. Chacun de ces CCW nécessite un
traitement distinct par le canal FICON ainsi que l’envoi de
commandes distinctes du canal à l’unité de contrôle via la liaison.
L’architecture zHPF définit un bloc de commande unique en
remplacement d’une série de CCW hérités, et zHPF étend FICON en
fournissant un « mot de contrôle de transport » (Transport Control
Word - TCW) qui permet le traitement d’une demande d’E/S par le
canal et l’unité de contrôle. Le TCW permet que plusieurs
commandes de canal soient envoyées à l’unité de contrôle sous la
forme d’une entité unique au lieu qu’elles le soient sous la forme de
commandes distinctes, comme avec les CCW FICON décrits plus
haut.
La Figure 49 illustre les séquences de commandes et de données pour
une séquence READ de 4 x 4 Ko. La Figure 50, page 262 illustre les
séquences de commandes et de données comparables pour exécuter
la même opération à l’aide de zHPF. Comme le montrent clairement
ces diagrammes, zHPF utilise considérablement moins de séquences
de négociation (et globalement moins de séquences tout court), ce qui
contribue à le rendre plus efficace.
261
FICON
channel
Storage
subsystem
CMD Prefix +64
CMR
CCW1 READ 4K
CCW1
CCW2 READ 4K
CCW3 READ 4K
CCW4 READ 4K
CCW2
CCW3
CCW4
CE/DE
Device
CCW1
DATA 4K
CCW2
DATA 4K
CCW3
DATA 4K
CCW4
DATA 4K
STATUS
STATUS ACCEPT
ICO-IMG-000831
Figure 49
FICON
channel
Séquences de commandes et de données FICON
Storage
subsystem
Device
CMD Prefix +64
READ 4K, READ 4K,
READ 4K, READ 4K
CMD Block
DATA 16K
RESPONSE
ICO-IMG-000832
Figure 50
262
Séquences de commandes et de données zHPF
zHPF montre ainsi ses principaux avantages (réduire la charge et
accroître les performances) en diminuant le nombre d’unités
d’informations (IU) devant être traitées ainsi que le nombre de trames
par E/S devant être transférées en augmentant le nombre moyen
d’octets par trame. Ces avantages peuvent être obtenus avec bon
nombre de charges de travail OLTP utilisant des méthodes d’accès
telles que VSAM, DB2, PDSE, HFS, zFS, WMQ et Extended Format
SAM. En particulier, les documents de référence montrent une
amélioration du débit d’au moins 17 % pour WebSphere MQ. Le gain
de performances constaté a même doublé en réduisant le nombre de
canaux. De manière générale, la majorité des charges de travail z/OS
utilisant des blocs de petite taille bénéficieront d’un débit
considérablement amélioré avec zHPF.
Pour chaque demande d’E/S zHPF, z/OS a désormais la possibilité
d’interroger l’état de cette demande en attente, l’unité de contrôle
ayant pour responsabilité de renvoyer les informations demandées,
c’est-à-dire la raison du délai. z/OS intègre ensuite ces informations
dans les messages MIH (Missing Interrupt Handler) ainsi que dans
les enregistrements SYS1.LOGREC. Les E/S destinées à des
périphériques réservés ne sont ni interrompues, ni remises en file
d’attente par MIH.
Configuration requise pour zHPF
High Performance FICON for System z (zHPF) (type CHPID FC –
FICON natif) nécessite les niveaux suivants du système
d’exploitation z/OS :
◆
z/OS 1.8, 1.9 ou 1.10 avec les PTF (ou supérieur)
◆
z/OS 1.7 avec IBM Lifecycle Extension for z/OS 1.7 (5637-A01)
avec les PTF
◆
z/OS.e 1.8 avec les PTF
L’APAR OA21140 est nécessaire pour que la nouvelle fonction RMF
prenne en charge zHPF. Il est également nécessaire de vérifier que la
maintenance Media Manager est à jour.
263
zHPF n’est proposé sur les processeurs System z196 et System z10
(z10 EC et z10 BC) qu’au niveau de pilote 76. zHPF est pris en charge
sur les canaux FICON Express8 (FEx8), FICON Express4 (FEx4) et
FICON Express2 (FEx2) sans modification de la définition CHPID. Il
n’est pas pris en charge sur les canaux FICON Express. Les E/S
exécutées sur des groupes de chemins comportant un mélange de
canaux FICON Express et FICON Express2, FICON Express4 ou
FICON Express8 au sein d’un même groupe de chemins ne peuvent
pas être converties en zHPF. Pour zHPF, tous les canaux d’un même
groupe de chemins doivent tous être de type FEx8, FEx4 ou FEx2.
Du fait que les canaux et les périphériques compatibles avec zHPF
prennent en charge simultanément les protocoles FICON et zHPF,
c’est le composant DFSMS Media Manager qui est responsable de
détecter si chaque périphérique prend en charge zHPF ou pas, et qui
effectue la construction des programmes de canal appropriés. Media
Manager construit les nouveaux programmes de canal Transport
Mode de zHPF pour les méthodes d’accès identifiés plus haut.
Contrôle de zHPF sur les baies VMAX
L’activation de zHPF sur les baies VMAX est réalisée par un
spécialiste du Support Clients EMC qualifié en procédant comme
suit :
1. Il effectue le chargement en ligne du code Enginuity 5874.204.165
ou supérieur (qui prend en charge zHPF).
2. Une fois cette première opération menée à bien, il effectue une
modification de configuration en ligne, en s’assurant que la balise
Transport Mode Support est définie sur YES dans le champ de
paramètres IMPL INIT CKD du nouveau fichier bin.
3. Il vérifie que zHPF est activé sur l’hôte. Il existe un nouveau
paramètre dans le membre IECIOSxx de SYS1.PARMLIB
(ZHPF=YES/NO) et dans la commande SETIOS qui permet de
contrôler si zHPF est activé ou désactivé. La valeur par défaut est
ZHPF=NO.
4. Il vérifie que zHPF a été activé sur les périphériques en utilisant
les commandes display appropriées documentées plus haut.
La désactivation de zHPF sur les baies VMAX est réalisée par un
spécialiste du Support Clients EMC qualifié, qui effectue une
modification de configuration et définit le paramètre Transport Mode
sur « NO ».
264
Multitrack High Performance FICON constitue une amélioration
majeure des performances FICON pour les environnements FICON
présentant un trafic élevé et employant la combinaison appropriée de
méthodes d’accès. Il s’appuie sur la version déjà disponible de High
Performance FICON (zHPF), sous la forme d’une simple extension de
cette fonction de base. zHPF multitrack étend le nombre de pistes à
traiter par une E/S zHPF en le faisant passer d’une piste unique à un
maximum de 255. Aucune autre modification n’a été apportée à la
fonction zHPF, car la conception de l’implémentation initiale de
celle-ci intégrait déjà le framework de base pour le multipiste. zHPF
multitrack étend l’implémentation initiale de zHPF en permettant au
champ de décompte des paramètres LOCATE RECORD EXTENDED
des commandes PREFIX et PREFIX READ de contenir une valeur
comprise entre 1 et 255 (inclus).
Remarque : zHPF multitrack est conçu pour améliorer les performances des
applications qui utilisent Media Manager pour les E/S associées à des
transferts de données de grande taille, ainsi que de celles qui utilisent zFS,
HFS, PDSE et des Datasets Extended Format avec répartition.
zHPF multitrack est pris en charge sur toutes les plates-formes
Symmetrix VMAX prenant en charge la fonction zHPF de base. Il ne
nécessite aucune modification de la configuration physique ou
logique actuelle : la configuration utilisée pour prendre en charge
zHPF est capable de prendre en charge zHPF multitrack.
Le code nécessaire à la prise en charge de zHPF multitrack peut être
chargé en ligne. L’état TRANSPORT MODE/HPF sur l’unité de
contrôle au moment où le code zHPF multitrack est chargé détermine
si un hôte utilise les opérations multipiste. Deux états doivent être
pris en compte.
Le premier état correspond à la situation où zHPF n’est pas déjà
activé. Si le code de zHPF multitrack est chargé sur un système sur
lequel TRANSPORT MODE/HPF n’est pas activé (c’est-à-dire que la
balise IMPL est définie sur NO), aucune action ne sera effectuée du
fait que la prise en charge de zHPF multitrack nécessite que la prise
en charge zHPF de base soit activée. Toutefois, si le client active
TRANSPORT MODE/HPF ultérieurement, l’unité de contrôle
prendra en charge à la fois la fonction zHPF de base et zHPF
multitrack.
265
Le second état correspond à la situation où zHPF est déjà activé. Si le
code de zHPF multitrack est chargé sur un système sur lequel
TRANSPORT MODE/HPF est déjà activé, l’unité de contrôle
générera une interruption de changement d’état pour le périphérique
en ligne le plus bas de chaque unité de contrôle logique (LCU), ce qui
déclenchera la réémission par l’hôte des commandes d’interrogation,
y compris la commande Read Features Code. L’hôte détecte ensuite
que les opérations multipiste sont prises en charge et qu’il peut
émettre des demandes zHPF multitrack.
Configuration requise pour zHPF multitrack
zHPF multitrack nécessite les éléments suivants :
◆
z/OS V1.9 ou z/OS V1.10 avec les PTF pour les APAR OA26084
et OA29017 (ou supérieur)
◆
Une baie Symmetrix VMAX exécutant Enginuity 5875 ou une
version supérieure
Extended Address Volumes (EAV)
Enginuity 5874 a introduit la possibilité de créer et d’exploiter des
volumes logiques pouvant comporter jusqu’à 262 668 cylindres. Cette
grande taille de volume correspond à la capacité annoncée dans
z/OS 1.10 pour les EAV (Extended Address Volumes) 3390. Ces
volumes de grande capacité sont pris en charge en tant que format
IBM 3390 avec une capacité atteignant 223 Go et sont configurés en
tant que périphérique 3390 Model A. Remarque : un périphérique
3390 Model A peut être défini avec un nombre de cylindres compris
entre 1 et 262 688, mais IBM définit un EAV comme étant un volume
quelconque comportant plus de 65 520 cylindres. Par conséquent, un
EAV est un sous-ensemble d’un périphérique 3390 Model A. De plus,
bien qu’il soit actuellement limité à 262 668 cylindres, la limite
architecturale définie pour un EAV est de 268 434 453 cylindres.
Avec Enginuity 5874 (et supérieur), la configuration et l’utilisation
des volumes de grande capacité sont similaires à celles des
périphériques standard plus anciens avec lesquels les utilisateurs
sont déjà familiarisés. Bien que les volumes de grande capacité
puissent coexister avec les volumes plus anciens, des limitations à
leur utilisation sont imposées par certaines méthodes d’accès
(restrictions liées au système d’exploitation) et par les logiciels
d’autres fournisseurs indépendants.
266
L’espace situé au-dessus des 65 520 premiers cylindres est
collectivement dénommé espace d’adressage étendu (EAS), l’espace
situé en dessous étant qualifié d’espace d’adressage de base. À
l’heure actuelle, les portions EAS des EAV sont principalement
exploitées par les applications utilisant une forme quelconque de
Datasets VSAM (KSDS, RRDS, ESDS et linéaire). Cela couvre DB2,
IMS, CICS, zFS et NFS. z/OS 1.10 a quelques restrictions notables par
rapport aux Datasets VSAM non pris en charge dans l’EAS : il s’agit
des catalogues, des espaces de pagination, des VVDS et de ceux dotés
d’attributs KEYRANGE ou IMBED.
Avantages des EAV
Les EAV offrent la possibilité de consolider de nombreux petits
volumes dans un seul volume de grande taille, et donc une seule
adresse de périphérique. Cela joue un grand rôle pour résoudre les
problèmes liés aux configurations connaissant une prolifération des
périphériques, situations dans lesquelles les utilisateurs étaient
confrontés à la limite de 65 280 périphériques des partitions logiques
(LPAR). En fait, dans nombre d’environnements, les deux principaux
facteurs à l’origine de la prolifération des périphériques sont
l’utilisation excessive et prolongée de volumes de petite taille (3390-3,
3390-9, etc.), et les exigences élevées et croissantes en matière de
continuité d’activité qui accompagnent la multiplication des
applications métiers.
Les EAV constituent une composante importante de toute stratégie
de consolidation des périphériques. Ils sont également considérés
comme un aspect encore plus vital pour fournir les capacités
extrêmement élevées au niveau du sous-système z/OS qu’exigent les
nouvelles classées d’applications exploitant des processeurs toujours
plus puissants. En résumé, même avec un petit nombre d’adresses
configurées avec ces grandes capacités, le sous-système de stockage
peut fournir une capacité extrêmement importante à l’hôte.
L’un des objectifs explicites des volumes de grande capacité et de la
diminution du nombre d’adresses de périphériques nécessaires pour
les prendre en charge réside dans la simplification globale du
sous-système de stockage et, par voie de conséquence, la réduction
des coûts de gestion du stockage. Cela a un impact direct sur la
productivité du personnel en charge du stockage, et s’avère un
facteur décisif en faveur de l’adoption des EAV.
Extended Address Volumes (EAV)
267
Le dernier aspect, mais non le moindre, réside dans la réduction des
ressources processeur associées à l’utilisation et au traitement de
plusieurs volumes : les Datasets et les clusters peuvent désormais être
entièrement contenus dans des extensions uniques suffisamment
grandes, faisant ainsi des extensions multivolume (et des
inconvénients qu’elles présentent) une solution que les utilisateurs
peuvent choisir d’utiliser, mais plus une nécessité. La réduction de la
fréquence des traitements OPEN/CLOSE/End of Volume
contribuera à accélérer fortement les tâches de traitement par lot dont
l’exécution prend actuellement un temps interminable.
Volumes EAV et performances
Un EAV accessible par le biais d’une adresse de base unique (UCB)
connaîtra une dégradation de ses performances s’il n’est pas en
mesure de maintenir le niveau requis de parallélisme des E/S, que ce
soit de façon continue ou en cas de pic. Heureusement, l’utilisation de
la technologie HyperPAV, disponible sur le DMX depuis
Enginuity 5773 et prise en charge par les baies Symmetrix VMAX
avec Enginuity 5874 et supérieur, permet de fournir, de manière
dynamique, les niveaux de parallélisme des E/S requis pour
répondre aux besoins des opérations effectuées sur des volumes de
grande capacité. Concrètement, la combinaison de l’accès au canal
FICON et de HyperPAV assure un niveau élevé de parallélisme des
E/S pour n’importe lequel ou l’ensemble des volumes du
sous-système. Ce simple fait devrait faire beaucoup pour atténuer les
craintes soulevées par l’adoption des EAV dans les environnements
les plus exigeants.
La prise en charge des volumes EAV a été ajoutée aux commandes
SQ VOL et SQ MIRROR de SRDF Host Component for z/OS. Les
décomptes de pistes non valides car supérieurs à 9 999 sont affichés
en utilisant des unités K (milliers) jusqu’à 999 K, et les décomptes
supérieurs à 999 K sont affichés en utilisant des unités M (millions).
Les unités K et M sont utilisées de la manière suivante : 1 K = 1 024 et
1 M = 1 000*1 K.
Remarque : Pour en savoir plus, consultez le document EMC SRDF Host
Component for z/OS Product Guide.
268
Enginuity 5874 et supérieur fournit la prise en charge du mécanisme
d’adaptation persistante du flux d’entrée, connu sous le nom
Persistent IU Pacing, ou Extended Distance FICON.
Le mécanisme Persistent IU Pacing constitue une modification des
spécifications FICON, et décrit une méthode permettant à un canal
FICON de conserver un décompte de débit pouvant être utilisé au
début de l’exécution d’un programme de canal. Cela peut améliorer
les performances des programmes d’E/S de grande longueur à des
vitesses de liaison supérieures et à longue distance en permettant au
canal d’envoyer davantage d’IU à l’unité de contrôle, éliminant ainsi
le délai lié à l’attente de la réponse à la première commande.
La prise en charge hôte de cette fonction est disponible exclusivement
avec les processeurs System z196 ou avec les processeurs System z10
exécutant Driver 73 avec MCL F85898.003 ou Driver 76 avec
MCL N10948.001. Le mécanisme Extended Distance FICON est
transparent pour le système d’exploitation z/OS et s’applique à
toutes les fonctions the FICON Express2, Express4 et Express8
transportant du trafic FICON natif (type CHPID FC).
Pour tirer parti de cette fonction, l’unité de contrôle doit prendre en
charge le nouveau protocole d’adaptation du flux d’entrée d’unités
d’informations, qui est détecté durant la séquence ELP/LPE. Le canal
utilise par défaut les valeurs de débit actuelles lorsqu’il fonctionne
avec des unités de contrôle qui ne peuvent pas tirer parti d’Extended
Distance FICON.
Les configurations z/OS Global Mirror (anciennement XRC) utilisent
généralement des extensions de canal entre l’hôte distant et le
contrôleur principal. Ces extensions de canal utilisent normalement
une forme de « spoofing » pour analyser les chaînes de CCW, et les
modifient afin d’éviter le phénomène de « data droop », qui est causé
par les allers-retours supplémentaires qui sont nécessaires dans un
environnement longue distance. Persistent IU Pacing permet
d’obtenir les mêmes avantages en termes de fonctionnalités et de
performances sans le coût supplémentaire lié aux extensions de canal.
269
Dans les premières versions d’Enginuity, l’utilisation et le
comportement du sous-système de cache étaient contrôlés en
utilisant une méthode de type « élément utilisé le moins récemment »
(Least Recently Used - LRU). Il n’avait aucune connaissance préalable
des caractéristiques de la charge de travail ni des profils des E/S
futures. La fonction Dynamic Cache Partitioning permet désormais
de définir jusqu’à sept partitions de cache dynamiques (DCP) en plus
de la partition par défaut à laquelle tous les périphériques
appartiennent initialement.
Quand le partitionnement de cache est activé, l’utilisateur peut créer
des groupes de périphériques et allouer à chacun une portion donnée
du cache Symmetrix. Le sous-système de cache connaît les allocations
définies par l’utilisateur et veille à ce que les DCP ne consomment pas
davantage de cache que ce à quoi elles ont droit. Chaque partition est
assortie d’un pourcentage de cache cible, ainsi que d’un pourcentage
minimal et maximal. Le pourcentage minimal de cache de chaque
partition ne doit pas être inférieur à 10 % du cache disponible. Cette
fonction autorise aussi l’attribution des portions de cache inutilisées à
d’autres partitions, dès l’expiration d’un délai prédéfini.
La fonction Dynamic Cache Partitioning permet de consolider à
grande échelle des charges de travail multiples au sein d’un
sous-système Symmetrix unique par le biais de sa capacité à
configurer l’attribution du cache en se basant sur les exigences
connues (voire inconnues) des E/S. Cela peut s’avérer très utile pour
les environnements contenant des mélanges de charges de travail
hétérogènes. De plus, elle peut être utile aux fournisseurs de services
qui prennent en charge plusieurs clients ou applications nécessitant
des objectifs de niveau de service spécifiques et différents.
Remarque : La fonction Dynamic Cache Partitioning donne aux utilisateurs
un degré de contrôle élevé sur les ressources de cache. Pour cette raison, elle
doit être utilisée judicieusement et par des utilisateurs possédant une
connaissance approfondie de leurs modèles d’accès aux E/S et de leurs
besoins en débit.
270
Des foncti ons ont été ajoutées au programme de traitement par lot
EMCQOS (un certain nombre de commandes) de ResourcePak Base
pour permettre à l’utilisateur d’accomplir les opérations suivantes :
activer et désactiver le partitionnement du cache, créer, supprimer et
modifier des partitions de cache, ajouter des périphériques à des
partitions de cache et les en supprimer, ainsi que visualiser et
répertorier les partitions et les statistiques associées.
Remarque : Bien qu’il ne s’agisse pas d’une exigence explicite, il est
recommandé d’utiliser Unisphere comme interface de contrôle et de
surveillance de la fonction Dynamic Cache Partitioning.
Exemple de JCL
L’exemple de JCL suivant illustre l’utilisation du programme
EMCQOS de ResourcePak Base pour effectuer une fonction DCP :
//Jobname JOB (1000),CLASS=A
/*JOBPARM LINES=999999
//* EMCQOS must be in an authorized dataset.
//QOS EXEC PGM=EMCQOS
//STEPLIB DD DISP=SHR,DSN=Dataset.Where.EMCQOS.IS
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DUMMY
//SYSOUT DD SYSOUT=*
//*
//* Required for message and parsing output.
//SYSPRINT DD SYSOUT=*
//* Required for reporting
//QOSPRINT DD SYSOUT=*
//* Optional if DEBUG(SNAP) is used
//QOSSNAP DD SYSOUT=*
//*
//* Required for control statements
//QOSINPUT DD *
*Get the current QOS settings for a range of devices
SETCPADD
LCL(%cuu),ID(#),TCACHE(%)MINCACHE(%)MAXCACHE(%),AGE(sec)
,WP(%)CPNAME(name)
/*
271
QoS Symmetrix Priority Control (SPC)
La fonction I/O Request Priority (IORP) a été introduite dans OS/390
dans le but d’indiquer un niveau de priorité pour une E/S donnée, de
manière à ce qu’elle puisse se voir accorder des privilèges spéciaux en
termes d’acheminement et de traitement au sein du sous-système
d’E/S. Il s’agissait d’un mécanisme ajouté à Workload Manager
(WLM) pour permettre à celui-ci d’exercer une influence sur le
traitement des E/S et ainsi contribuer à accroître le débit de
transactions. En mode objectif, cette fonction était largement utilisée
par WLM pour venir en aide aux charges de travail dont les objectifs
risquaient de ne pas être atteints.
Dans un sous-système fonctionnant correctement, dans lequel il n’y a
que peu (ou pas du tout) de conflits d’accès aux ressources, on
pourrait considérer que ce mécanisme ne présente qu’un intérêt
limité. Effectivement, dans ces conditions, la fonction IORP ne serait
pas utilisée par WLM. Toutefois, dans les sous-systèmes d’E/S
surchargés dont les conditions de fonctionnement sont loin d’être
idéales, par exemple lorsqu’il existe de nombreuses situations où la
mise en file d’attente est utilisée au niveau du cache, des
périphériques ou d’autres bases de composants, la fonction IORP
entre en action en permettant aux E/S marquées comme prioritaires
de bénéficier d’un traitement prioritaire HOL (Head Of Line) non
préemptif.
Remarque : En lui-même, ce mécanisme de gestion de bout en bout du degré
de priorité des E/S est particulièrement important pour les charges de travail
critiques, et lorsqu’il est combiné à la fois au parallélisme qu’offre HyperPAV
et à la nature duplexée de FICON, l’efficacité de la fonction IORP s’accroît
fortement.
Dans les premières versions d’Enginuity, l’architecture de traitement
des E/S hôtes de Symmetrix était entièrement basée sur l’équité et
non sur la priorité. Ce fonctionnement reposait sur une méthode de
type « premier arrivé, premier servi » (First Come, First Served FCFS). La fonction QoS Symmetrix Priority Control (SPC)
d’Enginuity donne aux utilisateurs la flexibilité de pouvoir contrôler
la priorité des E/S des applications hôtes I/O en attribuant un niveau
de priorité aux périphériques auxquels les différentes applications
accèdent.
272
Paramètres de priorité
Les utilisateurs ont le choix entre 16 niveaux de priorité (de 0 à 15)
pour les E/S, 15 étant le plus élevé. À chaque niveau de priorité est
associé un délai maximal (déterminé par la configuration des niveaux
de priorité), un nombre d’E/S par seconde et des périphériques
(définis par l’utilisateur). Tous les périphériques pour lesquels aucun
niveau de priorité n’est défini sont considérés comme ayant la
priorité la plus basse (niveau de priorité 0).
Chaque paramètre numérique représente un délai au-delà duquel il y
a urgence : ainsi, plus le niveau de priorité est élevé, plus le délai
avant qu’il n’y ait urgence est court, et donc plus le traitement de
l’E/S de lecture est effectué rapidement. Par défaut, la priorité la plus
élevée est attribuée à tous les volumes.
En plus de pouvoir activer ou désactiver la fonction SPC, les
utilisateurs peuvent consulter des statistiques couvrant notamment le
temps de traitement moyen par niveau de priorité, le taux d’E/S et le
débit (Mo/s). Ces statistiques et d’autres informations liées aux
paramètres de priorité sont stockées dans les mémoires en local et
globale du système Symmetrix. Trois principaux groupes de
statistiques sont accessibles : les statistiques globales, les statistiques
sur les priorités et les statistiques sur les périphériques. La fonction
Symmetrix Priority Controls peut être contrôlée et gérée à l’aide
d’une interface graphique intuitive fournie par Unisphere ou à l’aide
de JCL de traitement par lot.
En principe, les volumes auxquels une priorité a été affectée se voient
accorder un traitement préférentiel pour l’exécution de leurs E/S
d’échec en lecture, et bénéficient ainsi effectivement d’un service
HOL non préemptif. Des données empiriques issues de diverses
expérimentations ont déjà montré que la fonction SPC est très efficace
pour accroître les performances des charges de travail critiques
présentant un nombre élevé d’échecs de lecture aléatoire. Ce
mécanisme peut également être utilisé pour répondre aux besoins de
la fonction IORP (décrite précédemment) déclenchée par WLM, tout
en offrant une infrastructure de gestion des priorités pour les E/S qui
ne sont pas affectées par le schéma de fonctionnement de WLM.
Lorsqu’une E/S désignée comme prioritaire est reçue de la part de
WLM, elle est exécutée avant les autres E/S destinées au même
volume, quel que soit le paramètre SPC pour ce volume.
QoS Symmetrix Priority Control (SPC)
273
La capacité de SPC à fournir des performances différenciées au
niveau du volume en fait un outil extrêmement puissant dans les
environnements dans lesquels un grand nombre de charges de travail
hétérogènes sont déployées au sein d’un même sous-système
Symmetrix. De plus, la fonction SPC n’est pas limitée aux
environnements z/OS et peut fonctionner efficacement dans tous les
autres environnements pris en charge par Symmetrix.
La différenciation des priorités des volumes, par exemple pour les
applications de production, par opposition aux applications de test et
aux autres activités non liées à la production, permet de s’assurer que
les objectifs de niveau de production seront toujours atteints et jamais
compromis. Un raisonnement similaire peut s’appliquer à la prise en
charge des périphériques de grande capacité, dans le cas où un
périphérique de grande capacité est fractionné en de nombreux
volumes logiques. SPC peut assurer des performances différenciées
sur une sélection de volumes appartenant au même périphérique
physique, HyperPAV jouant un rôle fondamental dans ce scénario. En
poussant ce raisonnement encore plus loin, on constate que la
hiérarchisation au niveau du périphérique réalisée au sein du
système Symmetrix qui est disponible depuis le code Enginuity 5772
sur le DMX-3, qui s’est poursuivie au niveau Enginuity du DMX-4 et
encore dans les baies VMAX, peut être mise en œuvre plus facilement
en tirant parti de cette capacité à faire varier les performances au
niveau du volume.
QoS Symmetrix Priority Control (SPC) n’est pas nécessaire lorsqu’un
système Symmetrix est dédié à une seule application, ou lorsqu’il y a
de multiples applications ayant des besoins en performances
identiques ou similaires.
Remarque : Bien qu’il ne s’agisse pas d’une exigence explicite, il est
recommandé d’utiliser Unisphere comme interface de contrôle et de
surveillance de la fonction QoS Symmetrix Priority Control (SPC).
Des fonctions ont été ajoutées au programme de traitement par lot
EMCQOS de ResourcePak Base pour fournir des commandes
permettant à l’utilisateur d’activer et de désactiver la fonction SPC,
ainsi que de définir, modifier, supprimer et interroger les
périphériques et les délais pour les 16 niveaux de priorité. QoS
Symmetrix Priority Control (SPC) respecte le paramètre de priorité
figurant dans le CCW DEFINE EXTENT de z/OS Workload Manager
( (WLM). L’implémentation utilisée dans les baies Symmetrix DMX et
274
VMAX fournit un niveau de flexibilité supplémentaire, car elle
permet à l’utilisateur de décider à quel volume donner la priorité et
pendant combien de temps.
Copy QoS
Enginuity 5875 a fourni des contrôles plus granulaires pour Copy
QoS, qui ont permis d’obtenir des améliorations remarquables par
rapport aux contrôles antérieurs. Essentiellement, il a été
réimplémenté pour fonctionner avec Request Based Copy ainsi que
pour répondre à d’autres exigences. Cela s’avère intéressant pour les
environnements qui mettent en œuvre de nombreuses opérations de
réplication en local et à distance.
À l’heure actuelle, les commandes QOSGET et QOSSET sont utilisés
pour visualiser et définir les priorités de copie de périphérique pour
les volumes logiques. L’amélioration apportée à Copy QoS permet
désormais de définir la priorité de copie pour chaque périphérique. Il
devient ainsi possible d’ajuster la priorité de copie pour les
périphériques dans les deux sens, c’est-à-dire d’accélérer ou de
ralentir le comportement par défaut en fonction des priorités de
l’utilisateur. Lorsqu’un périphérique à priorité de copie basse qui a
une valeur QoS élevée est configuré pour effectuer une copie,
l’ordonnanceur de copie augmente le débit de copie de manière
dynamique si le sous-système est relativement peu actif. Copy QoS
fonctionne de manière indépendante pour chaque copie, même
lorsque le même périphérique source est utilisé pour plusieurs copies
simultanées. De plus, Copy QoS offre la possibilité d’interrompre
temporairement une copie en cours d’exécution.
Les types de copie pris en charge sont RDFP(#), SERP(#), SNPP(#) et
VLUN(#), # étant un nombre indiquant une priorité comprise entre 0
et 16. Cette amélioration se traduit par un certain nombre de
changements en termes de compatibilité. Pour la commande
OSGET/QOSSET, les paramètres BCVP, SCRP, LRU et LRUNAME ne
sont pas pris en charge dans Enginuity 5875. De plus, pour la
commande QOSSET, les paramètres BCVP, SCRP et LRUNAME sont
désormais ignorés et génèrent un message. Le paramètre VLUN n’est
pas pris en charge et produira une erreur. La Figure 51 illustre le
nouveau format d’affichage de la commande QOSGET ainsi que
l’ancien.
Copy QoS
275
ICO-IMG-000937
Figure 51
Nouvel affichage et ancien affichage de la commande QOSGET
Disques Flash EMC
Les disques Flash sont considérablement plus rapides que les disques
durs utilisant des plateaux en rotation. Concrètement, les
caractéristiques définissant les disques Flash spécifient qu’ils sont
capables d’assurer des temps de réponse uniformément dix fois plus
courts que les technologies mentionnées ci-dessus. Au niveau du
disque, ils assurent environ 30 fois plus d’opérations d’E/S par
seconde. En termes d’alimentation, les technologies actuelles offrent
une consommation réduite d’environ 32 % par Go et 98 % par E/S.
Il a été dit que les sous-systèmes d’E/S avec mise en cache présentant
des pourcentages de succès en lecture modérés à élevés éliminent la
nécessité d’intégrer des disques Flash à l’environnement. Différentes
études montrent que, même lorsque le pourcentage de succès en
lecture augmente jusqu’à avoisiner 100 %, les disques Flash
continuent à présenter des avantages par rapport aux disques durs.
276
Les disques Flash peuvent être exploités de manière efficace pour
accélérer une portion d’une application en plaçant certains éléments
de données sur des disques de ce type pendant une période
prolongée ou seulement de manière intermittente. La plupart des
bases de données comportent généralement quelques tablespaces
faisant l’objet de très nombreux accès. En les positionnant sur des
disques Flash, il est possible d’obtenir une amélioration considérable
des performances, à tel point que cela peut même bénéficier aux
portions des bases de données qui ne se trouvant pas sur ces disques.
Les disques Flash conviennent idéalement aux applications à faible
latence, c’est-à-dire celles pour lesquelles les utilisateurs ont en
permanence besoin de faibles temps de réponse (inférieurs à deux
millisecondes), par exemple les applications de flux financiers, les
bases de données transactionnelles et les autres applications très
interactives. Les gains de performances seront évidents dans les
environnements comportant des charges de travail mixtes, les plus
importants étant constatés au niveau de celles qui présentent le plus
d’échecs en lecture à partir du cache. Globalement, c’est avec les
profils de charge de travail présentant beaucoup d’échecs en lecture
aléatoire (pourcentage de succès en lecture relativement bas) que les
disques Flash offriront les gains de performances les plus importants.
Les disques Flash ont naturellement leur place dans la hiérarchie
globale du stockage, du fait de leur capacité à maintenir des densités
d’accès substantiellement supérieures, lesquelles s’accompagnent de
l’accroissement correspondant en termes de débit. Concrètement, à
l’heure actuelle, le déploiement d’une infrastructure informatique de
grande envergure est de plus en plus souvent considéré comme
incomplet s’il ne comporte pas des disques Flash et une approche de
stockage hiérarchisé.
Pour optimiser l’utilisation des disques Flash, il est conseillé
d’implémenter également la technologie FAST VP, qui est décrite
dans le Chapitre 4.
z/OS et les disques Flash
Les versions 1.11 et supérieures de z/OS disposent des
fonctionnalités nécessaires pour déterminer si le support de stockage
d’un volume z/OS est un disque SSD (Solid State Drive) ou pas.
Lorsque le périphérique change, le système d’exploitation émet une
Disques Flash EMC
277
commande CCW de lecture des caractéristiques du périphérique
(Read Device Characteristics - RDC) qui définit un bit dans l’UCB s’il
s’avère que celui-ci est un disque Flash.
Avec les versions antérieures de z/OS (avant la version 1.11), il était
nécessaire d’appliquer des PTF pour activer cette fonction de
découverte de disque Flash.
La commande DEVSERV a été mise à jour pour prendre en charge
l’interrogation des attributs de périphérique :
DEVSERV QD,9502,ATTR
IEE459I 16.12.26 DEVSERV QDASD
UNIT VOLSER SCUTYPE DEVTYPE
CYL SSID SCU-SERIAL DEV-SERIAL EFC
ATTRIBUTE/FEATURE
YES/NO
ATTRIBUTE/FEATURE
YES/NO
09502 DBZ001 2107921 2107900
10017 9480 XX08-AADMK XX08-AADMK *OK
SOLID STATE DRIVES
Y
ENCRYPTION
N
****
1 DEVICE(S) MET THE SELECTION CRITERIA
****
0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING
Remarque : Même s’ils sont entièrement mis en œuvre sur des disques Flash,
les périphériques thin n’indiquent jamais qu’ils résident sur un disque SSD
du fait que, à un instant donné, un périphérique thin peut être en train
d’utiliser de plusieurs pools composés de périphériques présentant des
caractéristiques différentes.
278
11
Ce chapitre présente les systèmes d’exploitation pris en charge par les
sous-systèmes Symmetrix, en plus de z/OS :
◆
◆
Prise en charge de TPF (Transaction Processing Facility) .......... 280
Linux on System z............................................................................ 284
279
Prise en charge de TPF (Transaction Processing Facility)
TPF est un environnement d’exploitation fourni par IBM qui se
caractérise par le traitement rapide d’importants volumes de
transactions liées aux communications. Les plus gros utilisateurs
rapportent des temps de réponse allant de moins d’une seconde à
trois secondes avec des taux de traitement des transactions (pas
seulement les débits d’E/S) supérieurs à 5 000 par seconde.
EMC propose depuis longtemps des produits innovants destinés aux
environnements TPF et capables de répondre aux besoins en matière
de débit des fournisseurs promettant à leurs clients des taux de
transactions élevés et une qualité de service exceptionnelle.
Généralement, nos clients vendent des billets d’avion ou de train, des
places de spectacle, des chambres d’hôtel, etc., ou fournissent des
services comme les autorisations de carte bancaire, les approbations
d’avance de fonds, les transactions de règlement-livraison en salle de
marchés, etc. dans les secteurs très exigeants de la vente au détail, des
télécommunications, des transports et de l’hôtellerie.
Quel que soit le secteur concerné, ces utilisateurs ont des attentes
extrêmement élevées vis-à-vis de leurs fournisseurs et des produits
qu'ils proposent : vitesses aussi élevées que possible, redondance
pour assurer la sécurité des informations, mise en réseau avancée,
respect des normes de l’environnement d’exploitation, fiabilité
inconditionnelle et disponibilité permanente des systèmes, le tout de
manière aussi économique que possible.
Les graves conséquences que peuvent avoir des problèmes de
performances ou, pire encore, des interruptions de service dans ces
secteurs expliquent pourquoi les clients se tournent vers EMC pour
leurs solutions de stockage. EMC propose les produits suivants pour
le marché TPF :
280
◆
SRDF Controls for TPF
◆
TimeFinder Controls for TPF
◆
ResourcePak for TPF
SRDF Controls for TPF
EMC SRDF Controls for TPF est un package logiciel qui surveille
l’état SRDF et contrôle les processus SRDF à l’aide d’entrées
fonctionnelles introduites au niveau du CRAS (Computer Room
Agent Set) principal TPF.
La fonction SRDF (Symmetrix Remote Data Facility) conserve une
copie en temps réel des données au niveau du volume logique, dans
des sous-systèmes Symmetrix qui se trouvent sur des sites
physiquement distincts. Les sous-systèmes Symmetrix pris en charge
sont notamment tous ceux qui sont actuellement pris en charge pour
une utilisation mainframe.
La section « Protection des informations », page 149 fournit de plus
amples informations sur les opérations SRDF.
TimeFinder Controls for TPF
TimeFinder Controls for TPF est une application exécutée sur le
mainframe qui contrôle les fonctions TimeFinder à partir d’une
application native exécutée sous TPF par le client. Toutes les
fonctions TimeFinder sont disponibles, notamment l’établissement de
volumes de continuité d’activité (BCV) adressables séparément, la
subdivision des BCV à des fins de test, la mise en œuvre d’entrepôts
décisionnels, l’actualisation des BCV pour les volumes de
production, et la restauration des données des BCV sur les volumes
de production. TimeFinder Controls couvre l’ensemble de la base de
données TPF.
EMC TimeFinder Controls for TPF se compose de deux produits,
TimeFinder/Mirror et TimeFinder/Clone, qui créent des copies
ponctuelles de volumes complets. Ces copies des données peuvent
notamment être exploitées pour :
◆
capturer des copies ponctuelles ;
◆
fournir des points de restauration basés sur disque ;
◆
permettre l’aide à la décision ;
◆
effectuer des tests d’applications hors bande.
La section « Protection des informations », page 149 fournit de plus
amples informations sur le logiciel EMC TimeFinder et le processus
de continuité d’activité.
281
ResourcePak for TPF
ResourcePak for TPF regroupe des exemples de programmes, des
structures de données et une API avancée permettant aux clients de
créer des affichages personnalisés afin de disposer d’une vue TPF du
système de stockage Symmetrix situé sur leur site. ResourcePak for
TPF permet aux clients utilisant TPF d’accéder aux informations
Symmetrix par le biais de l’API Solutions Enabler SymmAPI for TPF.
Des échantillons de code sont inclus sous la forme d’utilitaires
montrant comment utiliser les macros SymmAPI.
ResourcePak intègre notamment les composants suivants :
◆
SymmAPI for TPF : API permettant aux utilisateurs de TPF
d’accéder aux informations de configuration et statistiques de
Symmetrix ainsi qu’aux données utilisateur présentes sur des
périphériques Symmetrix non accessibles sur le canal.
◆
ResourcePak for TPF : exemples de programmes TPF exploitant
SymmAPI for TPF, les structures de données et les fonctions
étendues pour SRDF Controls for TPF et TimeFinder Controls for
TPF.
Offline Module Access, une fonction de ResourcePak for TPF, permet
aux utilisateurs de TPF d’accéder directement aux enregistrements
situés sur des BCV séparés. En sachant spécifiquement quels
enregistrements sont corrompus, un programme utilisateur peut
ainsi demander que ceux-ci soient extraits du BCV séparé
correspondant afin de pouvoir y accéder et de les réparer rapidement
et de manière extrêmement précise, sans interrompre le
fonctionnement de l’ensemble de l’environnement TPF. Les
enregistrements réparés peuvent ensuite être réinsérés dans la base
de données de production pour continuer à être utilisés.
ResourcePak for TPF fournit également des contrôles de qualité de
service (QoS) utilisables avec SRDF Controls for TPF et TimeFinder
Controls for TPF. Ces contrôles permettent à l’utilisateur d’afficher et
de contrôler les valeurs QoS pour un groupe donné de volumes
logiques TPF. Les valeurs QoS peuvent être affichées et définies
lorsque les sorties utilisateur sont activées dans SRDF, TimeFinder
Scheduler et TimeFinder Monitor. Les paramètres QoS s’appliquent
de façon dynamique et prennent effet immédiatement. Ils persistent
après une réinitialisation du sous-système de stockage. ResourcePak
for TPF facilite la prise en charge de la connectivité FICON, en
supplément de la prise en charge déjà ancienne de la connectivité
ESCON des canaux. Les statistiques de cache FICON sont consignées
dans cet utilitaire.
282
Voici certains des avantages et exemples d’utilisation des produits
EMC de prise en charge TPF :
◆
Protection SRDF pour les bases de données TPF, avec prise en
charge de tous les modes de fonctionnement (Synchrone,
Semi-synchrone, Asynchrone, disque de Copie évolutive et Copie
évolutive avec attente d’écriture)
◆
Utilisation de BCV TimeFinder pour le chargement des entrepôts
décisionnels, la création d’environnements de test, les
sauvegardes et les autres opérations simultanées exécutées alors
que la base de données de production est active
◆
Adressabilité avec ResourcePak pour séparer des BCV, et
volumes distants (R1 et R2) pour afficher l’état
◆
Fonction Offline Module Access permettant d’accéder hors ligne
aux volumes alors que la base de données de production TPF
reste disponible, ce qui permet la réparation haute précision des
enregistrements corrompus
La famille de produits TPF d’EMC ne nécessite pas d’autres produits,
solutions ou services professionnels EMC.
En matière de configuration logicielle requise, la famille de produits
TPF d’EMC nécessite TPF version 4.1 ou supérieure.
283
Linux on System z
Alors que les datacenters cherchent en permanence à augmenter leur
capacité de charge de travail et leurs performances, tout en réduisant
les coûts liés à l’alimentation, au refroidissement et à l’espace au sol,
les technologies de virtualisation sont en train de devenir rapidement
un élément critique de la plupart des environnements de production.
L’environnement IBM System z offre la possibilité de consolider les
serveurs physiques dans des machines virtuelles, ce qui permet de
réduire les problèmes d’encombrement physique, d’alimentation et
de gestion qui sont associés au fait d’avoir de nombreux serveurs
physiques.
Linux on System z est un terme générique désignant l’ensemble des
versions de Linux conçues pour s’exécuter sur l’architecture System z
d’IBM. Le mainframe offre prévisibilité, fiabilité, normes et
cohérence, et Linux fournit flexibilité et innovation. Comme une baie
de stockage Symmetrix peut facilement prendre en charge les deux
environnements, il semble naturel de les faire converger pour obtenir
la meilleure solution de classe entreprise disponible.
Le système d’exploitation z/VM apporte les atouts d’une technologie
de virtualisation aboutie à l’informatique d’entreprise sur systèmes
ouverts. z/VM permet d’éliminer les limitations physiques des
serveurs individuels en utilisant des machines virtuelles, tout en
offrant la possibilité de gérer et de surveiller l’environnement de
façon centralisée. En associant sa cohérence au système d’exploitation
communautaire, Open Source et innovant qu’est Linux, on obtient la
combinaison idéale. Linux on System z réunit le meilleur des deux
mondes. Cette combinaison associe la stabilité, l’accès hautes
performances aux données, les performances système globales et
l’évolutivité de l’environnement mainframe à la flexibilité de Linux
on System z.
Consolidation
La consolidation est l’une des principales raisons pour lesquelles les
clients adoptent l’environnement Linux on System z. La démarche
écologique a eu un impact important sur de nombreux aspects du
datacenter. Aujourd’hui, tout est optimisé (alimentation, espace au
sol, ressources matérielles et humaines, etc.). Un taux d’utilisation
élevé constitue un facteur de réussite essentiel. Tout le monde
souhaite exploiter au mieux sa base de connaissances intrinsèque et
284
son personnel, et Linux on System z peut contribuer à atteindre cet
objectif. Le passage à Linux on System z aide les clients à réduire le
nombre de serveurs physiques, l’encombrement, la consommation
électrique, la climatisation et l’utilisation de leur ressource la plus
précieuse, leur personnel. L’infrastructure qu’offre z/VM pour la
planification, l’automatisation, le contrôle des performances et le
reporting des machines virtuelles exécutant Linux on System z ne
sont que quelques-uns des gains de productivité découlant de
l’exécution de machines virtuelles Linux sous z/VM.
Systèmes d’exploitation Linux pris en charge
Deux distributions Linux peuvent s’exécuter sous System z : Red Hat
et Novell SUSE. Red Hat et SUSE peuvent s’exécuter de façon
autonome (en natif) dans leur propre partition logique (LPAR), ou
dans une machine virtuelle sous z/VM en tant que système
d’exploitation invité.
Le déploiement en natif de Linux on System z est utilisé
principalement par les clients ayant des environnements applicatifs
intensifs de grande envergure. D’autres clients exécutent Linux on
System z en natif lorsque z/VM n’est pas déployé au sein de leur
environnement. Jusqu’à présent, l’environnement le plus courant
consiste à exécuter Linux on System z dans une machine virtuelle
(sous z/VM). Cette solution offre une flexibilité de configuration
maximale, une grande facilité d’extension, le partage des ressources
et la possibilité d’exécuter plusieurs instances de Linux en tant qu’OS
invité dans des machines virtuelles sous System z.
Toute configuration complexe s’accompagne d’un certain nombre de
difficultés. L’une des difficultés associées à ce type d’environnement
réside dans le fait de réunir les univers mainframe et Linux, chacun
ayant sa propre taxonomie (en matière de stockage). La terminologie
constitue une autre difficulté : le mainframe utilise un DASD pour les
périphériques ECKD/CKD ; les systèmes ouverts utilisent une unité
logique (LUN) ; Symmetrix utilise un périphérique (DEV), un
hypervolume ou une séparation Symmetrix ; les autres utilisent un
volume ou un volume logique. De plus, z/VM offre un autre type de
disque appelé minidisk (mdisk). Quelle que soit la nomenclature,
toutes constituent des abstractions du stockage, qu’il s’agisse de
périphériques physiques complets, partiels ou multiples.
Linux on System z
285
Linux on System z - Options de connectivité
Lorsque vous connectez une baie Symmetrix à un environnement
Linux on System z, vous devez choisir un type de canal et un type de
disque. Les deux choix possibles en matière de connectivité sont
FICON (Fibre Connectivity) et FCP (Fibre Channel Protocol). Le type
de canal, FICON ou FCP, détermine le type de disque, respectivement
ECKD ou FBA. FICON est une extension du protocole ESCON
prenant en charge les transferts de données en mode Full duplex, ce
qui accroît le débit. FCP permet d’accéder aux périphériques FBA
SCSI des systèmes ouverts et au réseau de stockage (SAN).
Pour prendre en charge FCP, un type CHPID (Channel Path
Identifier) est fourni pour être défini et utilisé sur l’adaptateur
FICON Express. FICON assure la connexion à un directeur FICON
Symmetrix (EF), et FCP assure la connexion à un directeur Fibre
Channel Symmetrix (FA).
Une fois le protocole de connexion choisi, vous devez définir
l’environnement z/VM dans le programme IOCP (Input/Output
Configuration Program). Pour ajouter les définitions nécessaires,
vous devez fournir le CHPID, les informations relatives aux unités de
contrôle (CNTLUNIT) et la plage d’adresses de périphériques
(IODEVICE). Ensemble, ces informations définissent les
périphériques d’E/S sous z/VM.
Linux on System z - Options de disque
Le choix de la connectivité de base (FICON ou CHPID FCP)
détermine les types de disque disponibles dans l’environnement Il
s’agit de périphériques ECKD pour FICON et de périphériques FBA
pour FCP. Il existe plusieurs façons de configurer les périphériques
ECKD ou FBA. Ils peuvent être configurés en tant que périphériques
dédiés ou en tant que minidisks :
286
◆
Périphériques dédiés à la machine virtuelle Linux invitée en tant
que ECKD ou FBA.
◆
Minidisks (allocation totale ou partielle du périphérique d’E/S
z/VM) en tant que ECKD ou FBA, qui sont définis auprès de la
machine virtuelle Linux invitée. Les périphériques FBA utilisent
spécifiquement un type de périphérique émulé z/VM (edev).
Différentes raisons incitent les clients à adopter une méthode plutôt
que l’autre. Certains environnements Linux utilisent les deux types
de périphérique sur les machines virtuelles Linux. ECKD est bien
connu des utilisateurs mainframe et couramment utilisé pour la
partie de l’environnement qui est liée au système d’exploitation
Linux. Les périphériques SAN FBA sont davantage associés aux
systèmes ouverts et utilisés pour les données utilisateur.
L’environnement Symmetrix prend en charge tous les types de
périphérique pris en charge par z/VM.
Comme le choix des types de disques offre une certaine flexibilité, ils
doivent être évalués au cas par cas en fonction de l’entreprise, de ses
règles et de son environnement applicatif. Certains types de disque
sont plus faciles à suivre et à gérer depuis z/VM, d’autres depuis
Linux, d’autres encore exigent un provisionnement du stockage plus
ou moins important. Quel que soit le type de disque choisi, EMC
recommande de créer des volumes système Symm (ou gatekeepers,
c’est-à-dire de petits périphériques Symmetrix utilisés comme des
chemins de communication jusqu’à la baie Symmetrix) qui serviront
de chemin de communication dédié entre la baie Symmetrix et un
hôte de gestion. Cela permet au logiciel de gestion Symmetrix de
récupérer les informations de configuration et d’état sans interférer
avec les E/S normales de la baie.
Exemple de connectivité FCP
La Figure 52, page 288 montre un exemple d’environnement de test
intégrant des périphériques FBA. La configuration consiste en une
baie Symmetrix, un LPAR System z exécutant z/VM 6.2 et deux
machines virtuelles Linux invitées utilisant toutes deux des
périphériques FCP. Il y a deux directeurs FC Symmetrix (6e:0 et
11e:0), chacun possédant son propre WWPN unique et étant rattaché
à un switch SAN. Il y a deux canaux System z définis comme FCP (8c
et 8d), également rattachés au switch SAN. Ces canaux sont
également dotés de WWPN uniques. Des hypervolumes Symmetrix
sont présentés aux deux directeurs sur chaque canal. Ensemble, ils
constituent un environnement Linux FBA SCSI.
Linux on System z
287
LN142195
Red Hat 6
FBA
LN142197
SLES 11
FBA
FCP
8c
SAN
Symmetrix Symmetrix
LUN
Volumes
FA Port
Address
z/VM
Address*
6e
Port 0
000-0c7
65806598
11e
020-0e7 Port 0
000-0c7
66806698
020-0e7
Switch
8d
z/VM 6.2 LPAR
6e0
6e0: WWPN
50000972081a9114
11e0: WWPN
50000972081a9128
11e:0
*Only one IODEVICE is required to address FCP LUNs
Linux
LVM and/or
filesystem
Linux
System z
Symmetrix VMAX
Linux
Device
/dev/sdX
Linux
LUN(s)
SAN
Linux
WWPN
Linux
Device
Address
z/VM
I/O Device
Address
FA
ports
(WWPN)
attached
SAN
VMAX LV
Assigned
LUN Address,
mapped
and
masked
FA Port
VMAX LV
w/Internal
Address
z/VM
CHPID
System z
adapter
(WWPN)
VMAX
Physical
disks
ICO-IMG-000976
Figure 52
288
Invités Linux utilisant des périphériques FBA
Exigences Symmetrix liées à FCP
Lorsque vous utilisez FCP, le rattachement de la baie Symmetrix à un
environnement z/VM et Linux est soumis à des exigences
spécifiques. Un certain nombre d’options du directeur front-end (FA)
doivent être configurées dans la baie Symmetrix pour FCP. Les
paramètres de bit du directeur répertoriés dans le Tableau 19 peuvent
être modifiés en utilisant EMC Unisphere, Solutions Enabler SYMCLI
ou Symmetrix Management Console (SMC). Ils peuvent aussi être
configurés au niveau de la baie Symmetrix par un spécialiste du
Support Clients EMC.
Tableau 19
Paramètres de bit du directeur Symmetrix pour Linux on System z
Bit du directeur
Description
PP
Point à point
SPC2
Primaire SCSI SPC2
EAN
Activer l’autonégociation
C
Numéro de série commun
SC3
Interface SCSI 3
UWN
Nom universel unique
Linux on System z - Relations avec les périphériques FBA
Plusieurs opérations sont nécessaires pour présenter des
périphériques FBA à une machine virtuelle Linux on System z.
Globalement, les opérations à réaliser sont les suivantes :
1. Création d’hypervolumes Symmetrix de la taille voulue : attribue
à chaque hypervolume un numéro de périphérique interne.
2. Mappage des hypervolumes avec un port FA : crée une adresse
de LUN.
3. Zonage du port FA sur le port de l’adaptateur System z dans le
SAN Fabric.
4. Masquage des hypervolumes sur le nom universel du port FA et
le nom universel du canal System z.
5. Configuration dans IOCP des paramètres IODEVICES et CHPID
pour l’adaptateur System z physique.
Linux on System z
289
6. Rattachement des périphériques FCP réels ou virtuels à la
machine virtuelle Linux invitée.
Une fois ces opérations effectuées, l’hôte Linux voit un chemin de
périphérique du type /dev/sd#. Ce périphérique peut être
partitionné et activé afin d’être utilisé dans le gestionnaire de
volumes logiques Linux (LVM). Des systèmes de fichiers peuvent
ensuite être créés. L’ensemble des relations avec les chemins sont
décrites dans la Figure 53.
Linux
LVM and/or
filesystem
Linux
System z
Symmetrix VMAX
Linux
Device
/dev/sdX
Linux
LUN(s)
SAN
Linux
WWPN
Linux
Device
Address
z/VM
I/O Device
Address
FA
ports
(WWPN)
attached
SAN
VMAX LV
Assigned
LUN Address,
mapped
and
masked
FA Port
VMAX LV
w/Internal
Address
z/VM
CHPID
System z
adapter
(WWPN)
VMAX
Physical
disks
ICO-IMG-000977
Figure 53
Linux on System z - Relations avec les chemins de périphériques FBA
Exemple de connectivité ECKD
La configuration de DASD ECKD dédiés ou de minidisks nécessite
moins d’opérations que pour l’environnement FCP, car elle
n’implique pas d’environnement SAN. Pour cette raison, certains
fournisseurs mainframe préfèrent les périphériques ECKD aux
périphériques FBA.
290
La Figure 54, page 291 montre un exemple d’environnement de test
intégrant des périphériques ECKD. La configuration consiste en une
baie Symmetrix, un LPAR System z exécutant z/VM 6.2 et deux
machines virtuelles Linux invitées utilisant toutes deux des
périphériques CKD. La baie Symmetrix fournit deux ports directeurs
FICON : 6g:0 et 11g:0. Il y a deux canaux définis comme FC (FICON),
8e et 8f, qui sont rattachés directement aux ports directeurs front-end
Symmetrix.
LN165015
Red Hat 6
CKD
LN165017
SLES 11
CKD
8E
8F
z/VM 6.2 LPAR
Summetrix
CKD
Volumes
VM
Address
Type
0e8-1aF
120012c7
3390-3
027a-283
284-297
Figure 54
12c812d1
12d212e5
6g:0
9g:0
3390-9
mod27
ICO-IMG-000978
Machines virtuelles Linux invitées utilisant des périphériques ECKD.
Linux on System z - Relations avec les périphériques ECKD
Plusieurs opérations sont nécessaires pour présenter des
périphériques ECKD à une machine virtuelle Linux on System z.
Globalement, les opérations à réaliser sont les suivantes :
1. Création d’hypervolumes Symmetrix de la taille voulue : attribue
à chaque hypervolume un numéro de périphérique interne et une
adresse d’accès hôte.
2. Mappage des hypervolumes avec un port directeur FICON ou
avec plusieurs ports directeurs FICON.
3. Configuration dans IOCP des paramètres IODEVICES et CHPID
pour l’adaptateur System z physique.
Linux on System z
291
4. Création d’un minidisk z/VM ou rattachement des périphériques
réels ou virtuels à la machine virtuelle Linux invitée
Une fois ces opérations effectuées, l’hôte Linux voit un chemin de
périphérique du type /dev/dasd#. Une fois ce périphérique formaté
avec l’utilitaire dasdfmt et partitionné avec fdasd, il peut être
utilisé dans le gestionnaire de volumes logiques Linux (LVM). Des
systèmes de fichiers peuvent ensuite être créés sur le volume logique
ou le périphérique brut. L’ensemble des relations avec les chemins
sont décrites dans la Figure 55.
Linux
System z
Symmetrix VMAX
Linux
LVM and/or
filesystem
Linux
Device
/dev/dasdX
Linux
IO device
VMAX LV
Assigned
device Address,
mapped
to
EF Port
Linux
Device
Address
VMAX LV
w/Internal
Identifier
z/VM
I/O Device
Address
z/VM
CHPID
System z
channel
VMAX
Physical
disks
ICO-IMG-000979
Figure 55
Linux on System z - Relations avec les chemins de périphériques ECKD
DASDFMT sous z/VM
DASDFMT est un utilitaire utilisé dans l’environnement Linux on
System z pour préparer un périphérique CKD à l’exploitation de
données. Pour les systèmes EMC Symmetrix utilisant des
périphériques RAID 5 ou RAID 6, il est conseillé d’appliquer les
APAR ci-dessous aux environnements z/VM et Linux on System z.
Ces environnements peuvent fonctionner sans ces APAR, mais leur
application améliore grandement les performances.
292
Pour SUSE : ce correctif est intégré dans le noyau publié le
22 mai 2009 pour SLES/SLED 10 SP2, car le noyau publié est la
version 2.6.16.60-0.39.3. Pour SLES 10 SP3, vérifiez que le noyau est
au minimum la version 2.6.16.60-0.47.1. Pour plus d’informations, les
clients peuvent consulter le document de référence Bugzilla SLES
450989.
Pour Red Hat : le correctif du noyau est intégré dans Red Hat
Enterprise Linux 5.4 (2.6.18-155.el5). Pour plus d’informations, les
clients peuvent consulter les documents de référence Bugzilla Red
Hat 474157 et 484836.
De plus, si vous exécutez Linux en tant qu’invité dans une VM, les
APAR IBM suivants sont également nécessaires. IBM a développé
l’APAR VM64602 pour le format CMS sous z/VM ainsi que l’APAR
VM64603 pour les invités sous z/VM afin de permettre à l’invité
d’utiliser la fonction d’accroissement des performances DASD. Ces
correctifs sont disponibles pour z/VM 5.3 et 5.4, et seront intégrés
dans les versions futures de z/VM. Pour les utilisateurs de z/VM 5.2,
l’APAR VM64603 est disponible pour alléger la charge des invités.
Multipathing
Le multipathing est disponible au niveau de System z ou implémenté
au niveau de Linux on System z. Quelle que soit l’option choisie,
aucune opération supplémentaire n’est nécessaire pour les
hypervolumes Symmetrix en dehors des opérations standard de
planification de la haute disponibilité. Veillez à ce que les
hypervolumes soient présentés au mainframe sur au moins deux
ports directeurs différents, de préférence sur deux canaux différents
pour qu’il y ait deux chemins uniques vers chaque périphérique. Si
un SAN et un double fabric sont utilisés, chaque chemin doit passer
par un fabric et un switch différents pour garantir la disponibilité la
plus élevée.
Si des périphériques DASD sont utilisés via ESCON ou FICON, le
multipathing est disponible au niveau de System z. Cela est
transparent au niveau de la machine virtuelle Linux. La configuration
est inhérente à la définition dans IOCP des périphériques ECKD en
utilisant deux canaux.
Linux on System z
293
Lorsqu’un disque SCSI est utilisé via des périphériques FCP
rattachés, le multipathing est géré au niveau de Linux on System z.
Cette prise en charge est disponible via DM-MPIO, la solution de
multipathing intégrée au noyau Linux v2.6.x. DM-MPIO nécessite les
packages device-mapper, udev, hotplug et device-mapper-multipath.
PowerPath n’est pas encore disponible pour Linux on System z.
EMC Solutions Enabler
Solutions Enabler (SE) peut être exécuté dans les environnements
Linux on System z, en plus d’autres hôtes de systèmes ouverts,
comme Windows et diverses versions d’UNIX. Dans l’environnement
Linux on System z, SE peut être utilisé pour configurer et surveiller le
système Symmetrix.
La liste suivante répertorie les différents niveaux de SE et les
systèmes d’exploitation Linux on System z pris en charge :
◆
SE version 7.2 ou supérieure
• Red Hat Enterprise Linux (RHEL) version 5.4 ou supérieure
• SUSE Linux Enterprise Server (SLES) version 10 SP2 ou
supérieure
Les informations les plus récentes concernant les niveaux de logiciels
et les systèmes d’exploitation pris en charge sont consultables sur le
site de support en ligne EMC.
Symmetrix Command Line Interface (SYMCLI) fournit à l’hôte un
ensemble exhaustif de commandes pour gérer l’environnement de
stockage Symmetrix. Celui-ci s’utilise depuis l’invite de commandes
de Linux on System z. Vous pouvez utiliser des commandes SYMCLI
dans des scripts, ce qui permet de renforcer l’intégration avec l’OS et
les applications.
L’installation de Solutions Enabler pour Linux on System z s’effectue
via un fichier rpm. Durant ce processus, décrit dans le guide Solutions
Enabler Installation Guide, un module de noyau s’installe via la
commande insmod. Vous devez choisir le module approprié selon
votre version de Linux. Consultez le guide Solutions Enabler
Installation Guide pour plus d’informations concernant l’installation.
294
12
Offres du programme de
partenariat pour les
systèmes mainframe
Ce chapitre décrit les offres du programme de partenariat disponibles
pour les produits mainframe.
◆
◆
◆
Programme EMC Select .................................................................. 296
CentricStor : Fujitsu Siemens Corporation (FSC) ........................ 297
Extension de distance pour la famille EMC SRDF ...................... 298
Offres du programme de partenariat pour les systèmes mainframe
295
Programme EMC Select
Le programme EMC Select permet d’acquérir les produits les plus
performants des partenaires EMC pour compléter la solution
d’infrastructure de stockage des clients et faciliter l’implémentation
de leur stratégie de gestion du cycle de vie des informations (ILM).
En achetant des produits via le programme EMC Select, les clients
bénéficient d’un point de contact unique, d’un accès pratique et d’un
niveau de confiance sans précédent.
EMC Select propose un large éventail de produits haute qualité
destinés à compléter les solutions EMC de stockage de bout en bout,
notamment des librairies de bandes, des options de connectivité pour
l’extension de distance SRDF, des produits de bandes virtuelles et
bien d’autres. Ce groupe restreint de fournisseurs haut de gamme
soigneusement sélectionnés fournit par ailleurs des services et un
support exceptionnels pour ces produits, et travaille en étroite
collaboration avec EMC pour satisfaire les besoins des clients.
La fin de ce chapitre est dédiée à la présentation des produits pour
environnements mainframe. Certains d’entre eux sont directement
disponibles auprès d’EMC via le programme EMC Select. Les
produits non disponibles via ce programme peuvent être achetés
directement auprès du partenaire.
296
CentricStor : Fujitsu Siemens Corporation (FSC)
CentricStor est une solution sur bandes virtuelles d’entreprise
destinée au marché des bandes virtuelles mainframe. Avec cette
solution, les applications de sauvegarde peuvent écrire sur le cache
du disque plutôt que sur la bande, ce qui permet aux clients de
respecter leurs fenêtres de sauvegarde. CentricStor migre ensuite les
données du volume virtuel du disque vers la bande en utilisant un
mécanisme piloté par des règles. CentricStor tire le meilleur parti des
librairies de bandes dans un environnement de restauration.
Outre les systèmes ouverts, CentricStor prend en charge les
plates-formes mainframe IBM VM/VSE, MVS/OS390 et z/OS ainsi
que BS2000/OSD.
CentricStor dissocie les serveurs individuels et leurs applications des
lecteurs de bandes physiques et de l’automatisation, permettant ainsi
aux mainframes et aux systèmes AS/400 (iSeries), UNIX, Linux et
Windows d’accéder simultanément aux ressources de bandes
virtuelles sur le réseau de stockage.
CentricStor n’exige que peu de modification des environnements de
sauvegarde des systèmes ouverts et utilise EMC CLARiiON pour le
stockage sur disque. CentricStor peut faire évoluer les connexions
hôtes front-end et les connexions de bandes physiques back-end.
Cette solution est donc parfaitement adaptée à la consolidation
d’environnements entiers regroupant plusieurs systèmes
d’exploitation et plusieurs formats de bande. CentricStor fournit
également une fonction de copie automatique des bandes en local et à
distance pour les environnements de reprise après sinistre.
Fujitsu Siemens Computers (FSC), l’un des leaders informatiques en
Europe, fournit des produits et des services aux grandes entreprises,
aux PME et au grand public sur tous les principaux marchés
d’Europe, du Moyen-Orient et d’Afrique. Partenaire stratégique à
long terme d’EMC, FSC est l’un des principaux revendeurs de
systèmes et logiciels de stockage en réseau EMC.
CentricStor : Fujitsu Siemens Corporation (FSC)
297
Extension de distance pour la famille EMC SRDF
EMC Select propose un portefeuille robuste de périphériques
d’extension de distance réseau optique qualifiés par E-Lab™ pour
l’interopérabilité avec la famille EMC SRDF de logiciels de réplication
à distance pour environnements Symmetrix. En proposant les
produits des principales entreprises spécialisées dans les réseaux,
EMC est capable de fournir directement des équipements d’extension
DWDM, SONET/SDH et IP répondant aux besoins des clients qui
déploient une solution complète de continuité d’activité. Les produits
disponibles sont les suivants :
◆
Ciena CN 2000
◆
Ciena CN 4200
◆
Brocade UltraNet Edge 3000
◆
Nortel Optical Metro 3500
Ciena CN 2000
La plate-forme d’extension de stockage Ciena CN 2000 est une
solution d’extension de distance multiprotocole économique et très
performante. Elle est dotée de capacités de compression matérielle
intégrées pour des solutions de continuité d’activité/reprise après
sinistre capables de prendre en charge en toute sécurité l’ensemble
des WAN via le réseau SONET/SDH, WDM ou Dark Fiber d’un
opérateur.
Ce périphérique peut être acheté via EMC Select.
Ciena CN 4200
La plate-forme de services avancés CN 4200 FlexSelect est une
solution de transport et d’agrégation multiservices nouvelle
génération capable de prendre en charge n’importe quel protocole de
transport (notamment TDM, Ethernet, les protocoles de stockage et
vidéo) sur tout port disponible, y compris sur la même carte de ligne.
Elle comporte des ports de ligne programmables que l’utilisateur
peut gérer et provisionner à distance.
La plate-forme CN 4200 fournit des options flexibles d’extension des
SAN, de mise en miroir des disques à distance et de sauvegarde à
distance dans les environnements CWDM/DWDM.
298
Brocade UltraNet Edge 3000
Pour les grandes ou les moyennes entreprises, le routeur UltraNet
Edge Storage (Edge 3000) fournit une fonction de mise en miroir des
disques à distance via les réseaux FC ou FICON et de connexion au
SAN via des réseaux IP, ATM ou SONET. La fonction de traitement en
pipeline du routeur UltraNet Edge Storage autorise la mise en
chambre forte des bandes sur de longues distances, éliminant
quasiment toute répercussion de la latence sur le débit durable de la
sauvegarde sur bande à distance.
Extension de distance pour la famille EMC SRDF
299
300
13
Offres de services
professionnels pour les
systèmes mainframe
Ce chapitre décrit les services EMC Professional Services disponibles
pour les produits mainframe. Il se compose des sections suivantes :
◆
◆
◆
◆
◆
◆
◆
◆
Introduction ......................................................................................
EMC Mainframe Professional Services.........................................
Implementation for Mainframe Storage Replication ..................
Data Migration for Mainframe.......................................................
Design and Implementation for Mainframe Connectivity ........
Assessment for Mainframe Tape Environments .........................
Data Migration for Disk Library for Mainframe .........................
Implementation for Disk Library for Mainframe........................
Offres de services professionnels pour les systèmes mainframe
302
303
303
305
306
308
310
312
301
Introduction
Les experts EMC spécialisés dans les mainframes mettent à profit
leurs dizaines d’années d’expérience pour optimiser rapidement
l’environnement de traitement mainframe des clients. Chaque
engagement de service EMC s’appuie sur l’expertise éprouvée et les
méthodologies de service documentées d’EMC.
Les systèmes mainframe exécutent les applications et les processus
métiers parmi les plus critiques. La gestion des informations dans
une infrastructure mainframe exige de la part du client :
◆
une optimisation constante de l’environnement mainframe ;
◆
une connaissance de l’impact des décisions prises concernant
l’infrastructure ;
◆
une gestion et une protection des informations critiques ;
◆
une optimisation des niveaux de service et des économies de
coût ;
◆
une satisfaction des attentes en matière de niveau de service ;
◆
une protection garantie des informations critiques.
EMC fournit des solutions de stockage évolutives, sécurisées et
économiques qui optimisent les environnements mainframe. Avec les
services mainframe EMC, le client peut :
302
◆
obtenir une vue complète de son infrastructure de données ;
◆
concevoir et planifier en utilisant les bonnes pratiques ;
◆
consolider les données pour réaliser des économies substantielles
et améliorer les performances ;
◆
migrer les données et implémenter les solutions efficacement ;
◆
préserver et améliorer la disponibilité ;
◆
assurer la réplication en local et la reprise après sinistre à
distance ;
◆
réduire les fenêtres de traitement par lot des sauvegardes sur
bande ;
◆
améliorer la productivité des équipes ;
◆
récupérer de l’espace au sol dans son datacenter ;
◆
assurer l’archivage des données mainframe.
Ainsi, les informations mainframe critiques sont facilement
accessibles chaque fois que c'est nécessaire.
EMC Mainframe Professional Services
L’équipe EMC Mainframe Professional Services se consacre à la
conception, à la construction et à la gestion des infrastructures
d’informations de ses clients mainframe. EMC a conclu des
partenariats avec les principaux experts et a développé des services
spécifiques, qui se positionnent exclusivement sur le marché
mainframe.
Les sections suivantes fournissent une description générale de
certains services proposés aux clients.
Implementation for Mainframe Storage Replication
Le service EMC Implementation for Mainframe Storage Replication
s’appuie sur les besoins métiers des clients exprimés sous la forme de
stratégies de datacenter et de facteurs décisionnels clés dans le but de
mettre en œuvre une solution de réplication du stockage
personnalisée.
Le service EMC Implementation for Mainframe Storage Replication
relève du service EMC Business Continuance Framework. Ce service
framework couvre tous les aspects des engagements
SRDF/TimeFinder vis-à-vis du client Il inclut notamment la
conception, la mise en œuvre dans différents environnements ainsi
que la Présentation finale du produit au client.
Conditions d’application
Ce service vise notamment :
◆
les clients disposant d’un environnement mainframe ou
combinant mainframes et systèmes ouverts ;
◆
les clients à la recherche de meilleures performances en matière
de protection des données et de reprise après sinistre, notamment
ceux disposant de plusieurs stratégies de datacenter ;
EMC Mainframe Professional Services
303
◆
les clients de baies EMC Symmetrix souhaitant installer et mettre
en œuvre des stratégies complexes de protection des données et
de reprise après sinistre, désormais possibles grâce aux solutions
EMC SRDF et TimeFinder ;
◆
les clients ne disposant pas de l’expertise interne indispensable à
la mise en œuvre d’une conception SRDF et TimeFinder ;
◆
les clients « à haut risque » dont les délais de mise en œuvre de
SRDF et/ou de TimeFinder sont très courts ;
◆
les clients souhaitant procéder à une migration des données entre
différentes baies Symmetrix ou entre des baies de stockage tierces
et des baies de stockage EMC.
Cette offre de service se limite actuellement aux configurations
suivantes :
◆
baies Symmetrix pouvant exécuter des niveaux pris en charge du
microcode Enginuity ;
◆
environnement de système d’exploitation z/OS.
Positionnement du service
Les services de mise en œuvre sont fournis par tous les fournisseurs
de matériel du secteur de la réplication, sous la forme de modules
complémentaires de leurs produits. En outre, de nombreux
fournisseurs de consulting et de services indépendants proposent ces
services pour une grande variété de matériels et de logiciels. Par le
biais de ces services, EMC offre l’expertise issue d’une relation directe
avec les ressources d’ingénierie d’une entreprise reconnue pour son
innovation et son approche compétitive dans le domaine des
technologies de réplication.
En faisant appel aux services de mise en œuvre pour les solutions de
continuité d’activité d’EMC, vous bénéficiez des services de notre
personnel qualifié et expérimenté, lequel valorise notre longue
expérience en matière d’installations réussies, utilise les techniques
d’ingénierie les plus récentes et suit les recommandations des bonnes
pratiques. Grâce au lien étroit que partagent les ressources de
consulting et les ingénieurs de grand talent d’EMC, nous offrons
également des opportunités exceptionnelles en termes de formation
et d’expérience. Cette combinaison de formation et d’expérience
permet au client de profiter d’une véritable expertise en matière
d’intégration de SRDF et de TimeFinder dans les environnements
clients. Toute variation susceptible d’apparaître au cours de la mise
en œuvre est ainsi exclue.
304
Data Migration for Mainframe.
Le service EMC Data Migration for Mainframe est une offre de
migration complète qui transfère les données entre des baies de
stockage rattachées au système d’exploitation z/OS ou OS/390.
EMC utilise Symmetrix Remote Data Facility (SRDF) comme système
de migration initiée par l’hôte pour les migrations d’une baie
Symmetrix vers une autre baie Symmetrix. La migration des baies de
stockage source tierces requiert l’utilisation de solutions de copie
basées sur l’hôte. Ce service fournit quatre autres logiciels d’hôtes
aux clients qui souhaitent déplacer des volumes complets à partir de
plates-formes de stockage tierces avec des configurations de canaux
FICON :
◆
Fast dump and restore plug and swap (FDRPAS) d’Innovation
Data Processing ;
◆
Fast dump and restore move (FDRMOVE) d’Innovation Data
Processing ;
◆
EMC z/OS Migrator ;
◆
Transparent Data Migration Facility (TDMF) de Softek.
suivantes :
◆
environnements mainframe avec prise en charge IBM ;
◆
systèmes de stockage mainframe rattachés aux réseaux ESCON
ou FICON dans des configurations géométriques de type 3390.
Data Migration for Mainframe.
305
Les données mainframe connaissent une croissance annuelle de 35 à
40 %, ce qui rend leur gestion difficile. D’après la dernière étude
réalisée par le cabinet Goldman Sachs sur les dépenses informatiques,
la protection de l’information contre les attaques liées à la sécurité ou
les interruptions de fourniture de services constitue le poste de
dépenses prioritaire des services informatiques, suivi de près par la
restauration. D’après une enquête réalisée pour EMC par Roper
auprès de 300 responsables, la moitié des responsables informatiques
affirment qu’ils ne disposent pas du niveau de préparation nécessaire
à la restauration rapide des informations en cas de sinistre.
Au cœur de ces défis, les clients recherchent des moyens pour
améliorer les performances, équilibrer les charges de travail entre les
systèmes, voire changer de partenaires dans le domaine des
technologies. Par conséquent, ils sont confrontés à des scénarios de
migration complexes et urgents, auxquels s’ajoute une pression
croissante de l’entreprise sur le niveau de service.
La méthodologie EMC de migration des données fournit des résultats
prévisibles dans les environnements les plus complexes, ce qui réduit
les risques et accélère le « time-to-value ». L’offre EMC Data
Migration for Mainframe propose un large éventail d’options de
migration des données :
◆
stockage EMC et tiers ;
◆
baies EMC utilisant des offres de services basées sur des baies et
sur des hôtes.
Design and Implementation for Mainframe Connectivity
Le service personnalisé EMC Design and Implementation for
Mainframe Connectivity est une solution d’entreprise complète bâtie
autour des besoins des clients en matière de stockage et de
connectivité mainframe. Ce service fournit le framework de livraison
nécessaire à l’implémentation d’une infrastructure FICON.
Remarque : EMC souhaite que les partenaires s’impliquent dans la mise en
œuvre de ce service. L’équipe de livraison doit déterminer quels partenaires
engager et à quel endroit les déployer lors de la fourniture de ce service.
306
La quantité de données conservées par les entreprises sur les grands
serveurs mainframe connaît une croissance exponentielle. C’est
pourquoi les entreprises ont commencé à réfléchir aux moyens
d’accroître la capacité de stockage et les performances de ces
systèmes tout en réduisant les coûts. Les technologies capables de
satisfaire ces exigences sont notamment la connectivité FICON,
l’implémentation d’une connectivité ESCON nouvelle génération et
un protocole de transport des grands blocs de données à haut débit
extrêmement fiable.
suivantes :
◆
environnements mainframe avec prise en charge IBM ;
◆
baies EMC Symmetrix.
Les clients disposant d’une expertise technique suffisante peuvent
choisir de terminer eux-mêmes l’installation et la configuration de
leur baie de stockage et de leur switch. Toutefois, les clients qui
choisissent d’acheter le service EMC Design and Implementation for
Mainframe Connectivity bénéficient des avantages suivants :
◆
méthodologie de livraison testée et conception éprouvée ;
◆
évaluation de leurs besoins et de leurs projets d’extension futurs
en vue de recommander, de concevoir et de mettre en œuvre une
solution de stockage FICON ;
◆
capacité à tirer le meilleur parti des bonnes pratiques de
déploiement de solutions de stockage complexes d’EMC.
Design and Implementation for Mainframe Connectivity
307
Assessment for Mainframe Tape Environments
Le service EMC Assessment for Mainframe Tape Environments est
un engagement d’évaluation consultative sur site en plusieurs phases
comprenant des réunions avec facilitateur et des entretiens en vue de
découvrir et d’analyser l’environnement de bandes IBM z/OS du
client. Le service se conclut par la présentation d’un plan d’évolution
complet basé sur l’infrastructure et les priorités spécifiques de
l’entreprise.
Ce service d’évaluation fournit au client une analyse détaillée de ses
infrastructures physique et virtuelle, ainsi que des capacités et de
l’utilisation de ces dernières. EMC présente au client :
◆
un rapport détaillé sur les résultats de l’évaluation, comprenant
des entretiens avec le client et l’analyse des données système
fournies par ce dernier ;
◆
des recommandations en vue d’améliorer l’efficacité et de créer
une architecture optimale pour le traitement des bandes ;
◆
une proposition de solution sur bandes virtuelles EMC.
Le service EMC Assessment for Mainframe Tape Environments
s’applique aux environnements de bandes mainframe actuellement
installés, composés de matériels de bandes virtuelles et/ou réelles,
connectés via des canaux ESCON/FICON (Enterprise Systems
Connection/Fibre Connection) à un mainframe CPC équipé du
système d’exploitation IBM z/OS. Cette évaluation a pour but
d’analyser les sous-systèmes à bandes dans des configurations
autonomes ou complexes reposant sur des librairies. Les clients
d’IBM DFSMShsm peuvent également bénéficier de cette évaluation.
Ce service d’évaluation se limite actuellement aux environnements
suivants :
308
◆
prise en charge des systèmes d’exploitation IBM OS/390 ou
z/OS ;
◆
librairies de bandes mainframe IBM ou SUN autonomes
actuellement installées utilisant les technologies prises en
charge ;
◆
librairies de bandes automatisées actuellement installées telles
que
• les librairies de bandes automatisées IBM ;
• les librairies de bandes automatisées Sun StorageTek.
◆
librairies de bandes virtuelles actuellement installées telles que
• IBM Virtual Tape Server (VTS) ;
• Sun StorageTek Virtual Storage Manager (VSM) ;
• Diligent Virtual Tape Facility for Mainframe (VTFM) ;
• Fujitsu-Siemens CentricStor ;
• Bus-Tech Mainframe Data Library (MDL) avec CLARiiON,
EMC Centera et Celerra ;
• Bus-Tech Mainframe Appliance for Storage (MAS) avec
CLARiiON, EMC Centera et Celerra ;
• EMC Centera Mainframe HSM Migrator pour IBM
DFSMShsm.
Les clients qui utilisent des systèmes commerciaux de gestion des
bandes et du montage tels qu’IBM Tape Mount Management (TMM)
peuvent profiter de ce service.
Dans les datacenters, il existe un risque constant d’endommagement
ou de perte des supports de bandes physiques. En outre, la
technologie mécanique de traitement des bandes conduit
généralement à une dégradation des performances et du débit durant
les procédures de traitement par lot et en ligne. Le service EMC
Assessment for Mainframe Tape Environments s’adresse aux clients
inquiets des répercussions négatives sur leurs engagements de
niveau de service, sur la planification des traitements par lot ou se
souciant d’autres répercussions liées à la croissance de leurs besoins
en matière de bande. Ce service est parfaitement adapté aux clients
mainframe dont l’infrastructure de stockage sur bande s’est
développée rapidement et qui souhaitent disposer d’autres options
pour améliorer les performances et réduire l’envolée des coûts des
infrastructures de bandes. Les clients confrontés à des problèmes de
sauvegarde et de reprise après sinistre de leurs données critiques sur
bandes peuvent également profiter de ce service.
Assessment for Mainframe Tape Environments
309
Proposé dans le cadre d’une solution globale, ce service fournit des
recommandations pour l’utilisation de produits EMC ou de
partenaires commerciaux, par exemple :
◆
EMC Data Library for Mainframe Environments (DLm4000) ;
◆
Diligent VTFM ;
◆
Fujitsu-Siemens CentricStor ;
◆
Bus-Tech MDL avec CLARiiON, EMC Centera et Celerra ;
◆
Bus-Tech MAS avec CLARiiON, EMC Centera et Celerra ;
◆
EMC Centera Mainframe HSM Migrator pour IBM DFSMShsm.
Data Migration for Disk Library for Mainframe
Le service EMC Data Migration for Disk Library for Mainframe
consiste dans la configuration et l’implémentation d’une solution sur
bandes virtuelles EMC Disk Library for Mainframe (DLm) pour un
sous-système de stockage. Le DLm6000 se charge de l’émulation des
bandes vers le disque dans les environnements mainframe z/OS, ce
qui permet d’utiliser des baies de stockage sur disque plutôt que des
librairies de bandes physiques.
Le service EMC Data Migration for Disk Library for Mainframe est
une solution EMC d’émulation de bandes virtuelles destinée au
marché mainframe. Le DLm6000 prend en charge les systèmes
Celerra/VNX et Data Domain pour le stockage back-end.
L’utilisation du service EMC Assessment for Mainframe Tape
Environments est une condition préalable à l’utilisation de ce service.
Il permet de déterminer la capacité et le débit du canal pour le
dimensionnement.
Les composants physiques du DLm6000 sont les suivants :
◆
Virtual Tape Emulation Controller (VTEC) :
• un à six contrôleurs d’émulation de bandes virtuelles ;
• deux à 12 connexions de canal FICON, par multiples de deux ;
• 256 à 1 536 (maximum) lecteurs de bandes actifs.
◆
310
Systèmes de stockage back-end EMC VNX7500 :
• zéro à deux systèmes de stockage EMC VNX750 ;
• deux (un actif, un en veille) à huit (sept actifs, un en veille)
systèmes de stockage ;
• 40 To à 1,28 Po de capacité totale.
◆
Systèmes de stockage back-end Data Domain DD890 :
• zéro à deux systèmes de stockage Data Domain DD890 ;
• 20,92 à 259,67 To de capacité ;
• taux de compression logique de 10:1 (de 576 To à 2,856 Po).
Remarque : Au minimum, un DLm6000 doit comprendre un système de
stockage back-end, VNX ou Data Domain. En configuration maximale, le
DLm6000 comprend deux systèmes de stockage back-end VNX et deux
systèmes de stockage back-end Data Domain.
De nombreux clients continuent à dépendre des technologies
traditionnelles sur bande pour leurs procédures régulières de
traitement par lot, d’archivage, de sauvegarde et de restauration.
L’utilisation des bandes pose de nombreux défis en termes de niveau
de service, parmi lesquels : rappels retardés, temps de restauration
lents, impacts sur la disponibilité, envolée des coûts des supports et
encombrement accru. Ces problématiques ont pour conséquence une
augmentation des coûts, des risques et de la complexité de gestion de
l’infrastructure informatique, induits par la croissance continue des
informations.
Le DLm6000 émule les contrôleurs des lecteurs de bande
3480/3490/3590 sur le mainframe. Les volumes de bande écrits par le
mainframe vers l’un des périphériques DLm6000 sont stockés sur
l’unité de stockage sur disque des systèmes ouverts back-end,
c’est-à-dire sur le système EMC Celerra.
Data Migration for Disk Library for Mainframe
311
En combinant ses services d’experts et ses matériels et logiciels de
bandes virtuelles, EMC est en mesure de fournir des rappels et des
restaurations rapides et prévisibles, car les données des bandes
virtuelles sont transférées immédiatement à partir du disque sur
demande. Aucun montage ni récupération de bande n’est nécessaire
et les conflits d’accès aux lecteurs de bande sont éliminés. En
combinant les solutions sur bandes virtuelles avec les solutions de
réplication d’EMC, il est possible d’éliminer quasiment tout risque
d’interruption de service non planifiée grâce à la fourniture
d’objectifs de point de restauration (RPO) et d’objectifs de temps de
restauration (RTO) prévisibles, qui évitent de déplacer physiquement
les bandes. Ce service offre d’autres avantages, parmi lesquels la mise
en chambre forte en ligne via SRDF VNX7500 ou Data
Domain DD890.
Remarque : Le service EMC Assessment for Mainframe Tape Environments,
qui doit être utilisé préalablement à ce service, fournit les informations sur
lesquelles repose la migration.
Implementation for Disk Library for Mainframe
Le service EMC Implementation for Disk Library for Mainframe
consiste dans la configuration et l’implémentation d’une solution sur
bandes virtuelles EMC Disk Library for Mainframe (DLm) pour un
sous-système de stockage. Le DLm6000 se charge de l’émulation des
bandes vers le disque dans les environnements mainframe z/OS, ce
qui permet d’utiliser des baies de stockage sur disque plutôt que des
librairies de bandes physiques.
Disk Library for Mainframe (DLm) est le produit EMC d’émulation
de bandes virtuelles destiné au marché mainframe. Le DLm6000
prend en charge les systèmes Celerra, VNX et Data Domain pour le
stockage back-end.
L’utilisation du service EMC Assessment for Mainframe Tape
Environments est une condition préalable à l’utilisation de ce service.
Il permet de déterminer la capacité et le débit du canal pour le
dimensionnement. Les composants physiques du DLm6000 sont les
suivants :
312
◆
Virtual Tape Emulation Controller (VTEC) :
• un à six contrôleurs d’émulation de bandes virtuelles ;
• deux à douze connexions de canal FICON, par multiples de
deux ;
• 256 à 1 536 (maximum) lecteurs de bandes actifs.
◆
Systèmes de stockage back-end EMC VNX7500 :
• zéro à deux systèmes de stockage EMC VNX750 ;
• deux (un actif, un en veille) à huit (sept actifs, un en veille)
systèmes de stockage ;
• 40 To à 1,28 Po de capacité totale.
◆
Systèmes de stockage back-end Data Domain DD890 :
• zéro à deux systèmes de stockage Data Domain DD890 ;
• 20,92 à 259,67 To de capacité ;
• taux de compression logique de 10:1 (de 576 To à 2,856 Po).
Remarque : Au minimum, un DLm6000 doit comprendre un système de
stockage back-end, VNX ou Data Domain. En configuration maximale, le
DLm6000 comprend deux systèmes de stockage back-end VNX et deux
systèmes de stockage back-end Data Domain.
De nombreux clients continuent à dépendre des technologies
traditionnelles sur bande pour leurs procédures régulières de
traitement par lot, d’archivage, de sauvegarde et de restauration.
L’utilisation des bandes pose de nombreux défis en termes de niveau
de service, parmi lesquels : rappels retardés, temps de restauration
lents, impacts sur la disponibilité, envolée des coûts des supports et
encombrement accru. Ces problématiques ont pour conséquence une
augmentation des coûts, des risques et de la complexité de gestion de
l’infrastructure informatique, induits par la croissance continue des
informations.
Le DLm6000 émule les contrôleurs des lecteurs de bande
3480/3490/3590 sur le mainframe. Les volumes de bande écrits par le
mainframe vers l’un des périphériques DLm6000 sont stockés sur
l’unité de stockage sur disque des systèmes ouverts back-end,
c’est-à-dire sur le système EMC Celerra.
Implementation for Disk Library for Mainframe
313
En combinant ses services d’experts et ses matériels et logiciels de
bandes virtuelles, EMC est en mesure de fournir des rappels et des
restaurations rapides et prévisibles, car les données des bandes
virtuelles sont transférées immédiatement à partir du disque sur
demande. Aucun montage ni récupération de bande n’est nécessaire
et les conflits d’accès aux lecteurs de bande sont éliminés. En
combinant cette solution aux solutions de réplication d’EMC, il est
possible d’éliminer quasiment tout risque d’interruption de service
non planifiée grâce à la fourniture d’objectifs de point de restauration
(RPO) et d’objectifs de temps de restauration (RTO) prévisibles, qui
évitent de déplacer physiquement les bandes. Les autres avantages
fournis par ce service sont la capacité de sauvegarde sur disque,
l’accélération des délais de traitement par lot, l’accroissement de la
disponibilité des applications et du système, l’amélioration de la
fiabilité de sauvegarde et la simplification de l’implémentation et de
la gestion.
Remarque : Le service EMC Assessment for Mainframe Tape Environments,
qui doit être utilisé préalablement à ce service, fournit les informations sur
lesquelles repose la migration.
314
14
Outils de productivité
transférés à Rocket
Software
Cette annexe contient des informations relatives aux produits
logiciels qui appartenaient à EMC et qui sont à présent la propriété de
Rocket Software.
315
Catalog Solution
EMC Catalog Solution permet aux clients d’assurer la gestion, la
maintenance et la restauration de leur environnement de catalogues
de manière rapide, fiable et flexible. Catalog Solution prend en charge
la gestion des catalogues ouverts, offrant ainsi une plus grande
flexibilité aux clients dont les fenêtres de maintenance système sont
limitées. Catalog Solution permet aux clients d’effectuer diverses
tâches de maintenance des catalogues sans avoir à planifier
soigneusement des arrêts du système.
Catalog Solution permet la surveillance des environnements de
catalogues pour identifier et corriger les problèmes structurels avant
qu’ils ne provoquent des pannes système. Cette solution améliore la
productivité des programmeurs système en accélérant les procédures
quotidiennes de maintenance des catalogues. De plus, Catalog
Solution s’assure de la capacité de restauration d’un catalogue ICF en
cas de sinistre, garantissant ainsi la disponibilité du système. Catalog
Solution agit dans cinq principaux domaines :
◆
Maintenance
◆
Diagnostic
◆
Reporting
◆
Sauvegarde et restauration
◆
Gestion SMF
La Figure 56 représente la structure interne des catalogues ICF.
Master
Catalog
User
Catalog
VVDS VTOC
Figure 56
316
User
Catalog
VVDS VTOC
User
Catalog
VVDS VTOC
Structure des catalogues
User
Catalog
VVDS VTOC
VVDS VTOC
Caractéristiques
La solution de gestion des catalogues ICF Catalog Solution permet au
personnel informatique d’effectuer les opérations suivantes :
◆
Exécuter des rapports sur les catalogues ICF afin de répertorier
toutes leurs caractéristiques.
◆
Exécuter des tests de diagnostic pour vérifier l’état d’un catalogue
ICF et identifier les erreurs avant qu’elles n’affectent le système.
◆
Vérifier que les alias relatifs aux catalogues utilisateur spécifiés
sont les mêmes dans tous les catalogues maîtres spécifiés.
◆
Réorganiser les catalogues ICF pour éliminer les extensions,
modifier les caractéristiques du catalogue, etc.
◆
Fractionner et fusionner les catalogues ICF.
◆
Tester l’index et les données de la structure de base du catalogue
(BCS).
◆
Synchroniser BCS/VVDS/VTOC. Créer les entrées de Datasets
VSAM et non VSAM manquantes afin de garantir que tous les
Datasets sont catalogués et éliminer les orphelins présents dans le
système.
◆
Détecter et supprimer toute entrée de catalogue superflue.
En outre, l’utilisation de Catalog Solution est préconisée en cas de
panne de catalogue ICF pour assurer la disponibilité du système.
Catalog Solution réduit les interruptions de service de plusieurs
heures à quelques minutes en permettant de réaliser les opérations
suivantes :
◆
Sauvegarder les catalogues ICF pour garantir la capacité de
restauration quand cela est nécessaire. Durant la sauvegarde,
Catalog Solution vérifie la validité du catalogue ICF.
◆
Restaurer le catalogue ICF partir de la dernière sauvegarde.
◆
Effectuer une restauration par progression des catalogues ICF
pour garantir la disponibilité et l’accessibilité du système.
Catalog Solution
317
Voici certains des avantages et des exemples d’utilisation de Catalog
Solution :
Maintenance : il simplifie la maintenance des catalogues. Il facilite la
consolidation des extensions, améliore les temps d’accès et l’intégrité,
supprime les composants orphelins des Datasets, gère le déplacement
des catalogues vers d’autres volumes ou types de périphériques,
veille à ce que tous les Datasets soient catalogués, et fournit des
alertes concernant la présence d’éventuels problèmes structurels dans
les enregistrements des catalogues.
Diagnostics : il contribue à empêcher les problèmes mineurs de se
transformer en sinistres majeurs, et identifie et corrige de façon
proactive les problèmes structurels ou de synchronisation des
catalogues.
Reporting : il génère des rapports sur les caractéristiques et les
extensions à partir d’une ou plusieurs VTOC via une commande
unique, facilite la surveillance de l’état de santé des catalogues ICF et
des Datasets de manière sélective ou sur l’ensemble du système,
sélectionne les enregistrements de catalogue par classe de
stockage/classe de données/classe de gestion, et identifie les entrées
de catalogue en utilisant les caractéristiques du Dataset comme
critère de recherche.
Sauvegarde et restauration : il permet de sauvegarder vos catalogues
tout en veillant à l’intégrité des données et de la structure de chaque
sauvegarde. Il permet de restaurer les catalogues par progression
pour garantir l’accessibilité des données en quelques minutes en cas
de défaillance d’un catalogue.
Gestion SMF : il intègre une fonction complète de gestion et
d’application des données SMF liées à votre environnement de
catalogues.
Autre : il répertorie des informations relatives aux Datasets à partir
de copies BCS exportées ou de données SMF dans des formats
extraits ou actifs.
318
Les conditions préalables pour Catalog Solution sont notamment les
suivantes :
◆
◆
Un lecteur de bande 3480 ou plus récent (nécessaire uniquement
pour l’installation)
◆
Un accès TSO/ISPF
Licences
Conformément à un contrat de licence conclu avec EMC, Rocket
Software a repris la commercialisation et le support de Performance
Essential. Contactez Rocket Software pour signaler tout problème.
Performance Essential
Performance Essential améliore considérablement les performances
système en réduisant de façon significative la charge système, sans
modification de l’application ou du JCL (Job Control Language).
L’intelligence intégrée à Performance Essential gère les E/S des
applications, qui sont à l’origine de la plupart des goulots
d’étranglement en matière de performances applicatives. De plus,
Performance Essential minimise automatiquement les temps de
chargement des fichiers pour accroître encore les performances.
Performance Essential optimise les allocations de mémoire tampon
pour les Datasets VSAM et non VSAM. Les algorithmes de mise en
mémoire tampon et les paramètres par défaut de Performance
Essential se traduisent par une réduction du nombre d’appels EXCP,
ce qui libère le canal et les ressources CPU pour d’autres tâches.
319
Pour tous les fichiers auxquels les accès s’effectuent de façon
séquentielle, Performance Essentiel alloue la mémoire tampon
adéquate à l’ouverture de chaque fichier. Pour accéder aux fichiers
VSAM par traitement direct, Performance Essentiel permet
l’application sélective ou globale d’un traitement DFR (écriture
différée) ou LSR (mémoire tampon partagée) au niveau du système,
de la tâche, de l’étape, du catalogue, du volume ou du Dataset. De
plus, pour le chargement des Datasets VSAM, Performance Essential
réduit les chemins d’instructions et le nombre d’E/S, ce qui se traduit
par une diminution spectaculaire du temps écoulé, du nombre
d’appels EXCP et du temps CPU.La Figure 57 montre comment
Performance Essential réduit le nombre d’E/S et améliore les
performances.
Large buffer Size
Host
Get/Put
Performance
Essential increases
the buffer above the line
Buffer
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
............
Less I/O operations
DASD
EXCP
I/O
Exploiting locality of reference
principle in real storage
Reduce number of I/O dramatically
Increase performance
Free system resources
Figure 57
MF-000004
Performance Essential :
320
◆
Il réduit considérablement, de jusqu’à 75 %, les temps de
traitement par lot VSAM.
◆
Il exploite de manière transparente la mise en mémoire tampon
LSR/NSR VSAM pour toutes les applications.
◆
Il allège les contraintes du stockage virtuel en plaçant les tampons
mémoire au-delà de la limite de 16 Mo.
◆
Il fournit une analyse SMF via Application Performance Analyzer
qui permet de cibler les tâches offrant le plus gros potentiel
d’amélioration des performances.
◆
Il permet au client de choisir s’il souhaite que Performance
Essential intervienne automatiquement ou selon des paramètres
définis par l’utilisateur.
◆
Il ne nécessite pas d’IPL ni de modification des applications ou du
JCL.
Le fonctionnement de Performance Essential ne nécessite aucun
programme EMC supplémentaire.
La configuration requise par Performance Essential est notamment la
suivante :
◆
◆
◆
Un accès TSO/ISPF
Licences
321
TeraSAM
TeraSAM permet de segmenter facilement des Datasets VSAM
volumineux en Datasets plus petits et plus simples à gérer qui
peuvent être traités de façon sélective ou en parallèle. Le temps de
traitement des données, des sauvegardes et des restaurations est ainsi
considérablement réduit.La Figure 58 illustre comment la
segmentation des Datasets fournie par TeraSAM réduit le temps de
traitement par lot sans nécessiter de modification des applications.
TeraSAM optimise le taux d’utilisation du stockage en permettant à
l’utilisateur de placer les plages de clés très volatiles dans des
Datasets dotés d’un espace libre adéquat. Cela a pour objectif de :
◆
réduire les opérations de fractionnement des Datasets VSAM ;
◆
permettre aux données des plages de clés statiques (données
historiques) d’être chargées dans des segments de Datasets
dotées d’un espace libre restreint ou nul.
CICS Control
Regions
CICS Control
Regions
Concurrent Processing
for Job TRW01
VSAM
Dataset
Segmented
VSAM
Dataset
Job
TRW01A
Job
TRW01B
5GB
Job
TRW01C
5GB
20GB
VSAM
Dataset
Job
TRW01
Without TeraSAM: 8-Hour Elapsed Time
5GB
Conversion
5GB
Job
TRW01D
1 CYL
With TeraSAM: 2-Hour Elapsed Time
MF-000005
Figure 58
322
Segmentation des Datasets avec TeraSAM
TeraSAM :
◆
Il élimine les problèmes liés à la gestion des fichiers VSAM
volumineux.
◆
Il effectue les opérations logiques de sauvegarde et de
restauration des Datasets dans une fenêtre de traitement par lot
plus courte.
◆
Il permet une restauration plus rapide des Datasets partiels.
◆
Il ne restaure que la partie endommagée d’un Dataset
endommagé.
◆
Il offre une meilleure granularité.
◆
Il permet une gestion au niveau du Dataset.
◆
Il réduit les délais grâce au traitement en parallèle.
◆
Il permet une utilisation des fichiers répartis pour des
performances accrues.
Le fonctionnement de TeraSAM ne nécessite aucun programme EMC
supplémentaire.
TeraSAM nécessite une version de z/OS actuellement prise en charge
par IBM
Licences
TeraSAM
323
VSAM Assist
La gestion des données VSAM est complexe, car VSAM contient de
multiples composants par cluster, de multiples index, différentes
méthodes d’accès, un partage des données VSAM et des contraintes
liées aux fenêtres de traitement par lot.
Grâce à VSAM Assist, des sauvegardes complètes peuvent être
effectuées fréquemment, tout en simplifiant et en améliorant la
gestion des données VSAM et les processus de maintenance. En
utilisant seulement deux commandes, RESTORE et DUMP, VSAM
Assist réduit considérablement le temps nécessaire à la sauvegarde et
à la restauration des fichiers, et contribue à satisfaire les exigences de
traitement par lot grâce aux technologies fast-read et fast-write.
VSAM Assist peut effectuer le vidage de nombreux Datasets VSAM
dans un fichier à l’aide d’une commande unique, et ce, jusqu’à 40 %
plus rapidement qu’en utilisant d’autres solutions. VSAM Assist peut
également restaurer de nombreux Datasets à l’aide d’une commande
unique, et effectuer des modifications en masse pendant la
restauration.La Figure 59 illustre ces fonctions.
324
VSAM DS
VSAM DS
VSAM DS
VSAM DS
VSAM DS
VSAM DS
VSAM DS
VSAM DS
MF-000006
Figure 59
Avantages de VSAM Assist
Voici certains des avantages et des exemples d’utilisation de VSAM
Assist :
◆
Il permet de sauvegarder ou de restaurer des groupes de Datasets
VSAM ou des fichiers individuels en utilisant des critères tels
qu’un nom de Dataset, un nom de Dataset générique, une plage
de noms de Datasets, un volume ou un catalogue. Les formats
KSDS sont réorganisés lorsqu’ils sont restaurés.
◆
Il permet de vider plusieurs Datasets dans un fichier de
sauvegarde unique à l’aide d’une seule commande. Il permet de
sauvegarder ou de restaurer les index de substitution par nom de
Dataset ou par association avec le cluster de base du Dataset.
◆
Il permet d’apporter des modifications en masse aux
caractéristiques des Datasets pendant leur restauration (nom,
espace alloué, pourcentage d’espace libre, type de périphérique
et taille de l’intervalle de contrôle).
VSAM Assist
325
◆
Il calcule automatiquement l’espace requis pour chaque Dataset
et ajuste les allocations d’espace au fur et à mesure que les
Datasets sont restaurés.
◆
Il redistribue l’espace libre de façon efficace et calcule la taille
minimale de l’intervalle de contrôle.
◆
Il améliore la productivité du personnel en permettant une
gestion rapide et simplifiée des opérations de maintenance
VSAM liées à la sauvegarde et à la restauration.
◆
Il exige peu de connaissances techniques pour une utilisation
efficace.
Aucun programme EMC supplémentaire n’est nécessaire.
Les conditions préalables pour VSAM Assist sont notamment les
suivantes :
◆
◆
◆
Un accès TSO/ISPF
Licences
VSAM Quick Index
VSAM Quick Index est un outil logiciel complet qui permet de
construire des index de substitution VSAM à la fois rapidement et
simplement. Les index de substitution sont utilisés pour adresser les
données situées dans des Datasets VSAM via une clé spécifique.
326
Par exemple, votre numéro de compte bancaire sert de clé lorsque
vous utilisez les services téléphoniques de votre banque. Une autre
application, comme les virements électroniques, exige une autre clé,
constituée du code de votre banque et de votre numéro de compte
bancaire. Lorsque les comptes sont ouverts ou fermés, les index
utilisés par chacune de ces applications doivent être mis à jour pour
refléter les changements effectués au niveau du Dataset sous-jacent.
La valeur commerciale croissante des informations a suscité la
nécessité croissante de partager ces informations entre davantage
d’applications, ce qui a suscité à son tour la nécessité d’index de
substitution supplémentaires. Sans VSAM Quick Index, les clients
doivent se contenter d’IDCAMS, un utilitaire VSAM basique.
L’utilitaire IDCAMS est fourni gratuitement avec les licences z/OS et
offre généralement des capacités réduites. Cela se traduit par une
augmentation des temps de traitement et des périodes prolongées
d’indisponibilité des données.
VSAM Quick Index comble les lacunes d’IDCAMS. Contrairement à
IDCAMS, VSAM Quick Index peut construire de multiples index
avec une seule passe du cluster de base, ce qui constitue une méthode
bien plus rapide et efficace. Un autre avantage réside dans la capacité
de VSAM Quick à identifier tous les index de substitution définis
sans avoir à les spécifier individuellement.
Voici certains des avantages et des exemples d’utilisation de VSAM
Quick :
◆
Il construit les index de substitution pour les Datasets KSDS et
ESDS VSAM jusqu’à 80 % plus rapidement qu’IDCAMS
BLDINDEX.
◆
Il exploite l’utilitaire de tri maison (IBM Sort/Merge, SyncSort,
CA-SORT, etc.).
◆
Il crée plusieurs index de substitution avec une seule passe du
cluster de base.
Le fonctionnement de VSAM Quick Index ne nécessite aucun
programme EMC supplémentaire.
VSAM Quick Index
327
Conditions préalables pour VSAM Quick Index :
◆
◆
◆
Un accès TSO/ISPF
Licences
328
Glossaire
Ce glossaire contient des termes en rapport avec les sous-systèmes de
stockage sur disque. Ce manuel utilise la plupart de ces termes.
A
adaptateur
Carte qui fournit l’interface physique entre le directeur et les unités
de disque (carte SCSI), entre le directeur et les canaux parallèles
(adaptateur « bus and tag ») ou entre le directeur et les canaux série
(adaptateur série).
adaptateur SCSI
Carte du sous-système Symmetrix qui fournit l’interface physique
entre le directeur de disque et les unités de disque.
adresse d’unité
Valeur hexadécimale qui définit de façon unique un périphérique
d’E/S physique sur un chemin de canal dans un environnement
MVS. Voir aussi « adresse de périphérique ».
adresse de
périphérique
Valeur hexadécimale qui définit de façon unique un périphérique
d’E/S physique sur un chemin de canal dans un environnement
MVS. Voir aussi « adresse d’unité ».
adresse de piste
Premier champ d’une piste CKD qui identifie cette dernière et définit
son état opérationnel. L’adresse de piste est écrite après le point
d’index sur chaque piste.
C
cache
Stockage électronique à accès aléatoire servant à conserver les
données fréquemment utilisées afin d’y accéder plus rapidement par
le canal.
chaîne
Série d’unités de disque connectées qui partagent le même directeur
de disque.
Glossaire
329
Glossaire
CKD
code de redondance
longitudinal (LRC)
Format d'enregistrement de données Count Key Data
(nombre-clé-données).
OR exclusif (XOR) des octets accumulés dans l’enregistrement de
données.
D
DASD
destage
Écriture asynchrone de données nouvelles ou mises à jour depuis le
cache vers l’unité de disque.
diagnostics
Tests exécutés au niveau du système ou microprogramme conçu pour
inspecter, détecter et corriger les composants défaillants. Ces tests
sont complets et appelés automatiquement.
directeur
Composant du sous-système Symmetrix qui permet à ce dernier de
transférer des données entre les canaux hôtes et les unités de disque.
Voir aussi « directeur de canal ».
directeur de canal
Composant du sous-système Symmetrix qui sert d’interface entre les
canaux hôtes et le stockage des données. Il transfère les données entre
le canal et le cache.
directeur de disque
330
Direct Access Storage Device (périphérique de stockage en
attachement direct), périphérique proposant un stockage non volatile
des données et un accès aléatoire à celles-ci.
Composant du sous-système Symmetrix qui joue le rôle d’interface
entre le cache et les unités de disque.
directeur ESCON
Périphérique qui fournit une fonction de commutation dynamique et
des longueurs de chemins de liaisons étendues (avec la fonction XDF)
lors de la connexion d’un canal ESCON à une interface de canal série
Symmetrix.
disponibilité des
données
Accès à toutes les données utilisateur par l’application.
Glossaire
E
enregistrement zéro
ensemble disque-têtes
ESCON
extension
d'hypervolume
Premier enregistrement situé après l’adresse de piste sur un volume.
Pièce de remplacement sur site du sous-système Symmetrix qui
contient le disque et le mécanisme d’accès.
Enterprise Systems Connection, ensemble de produits IBM et
d’autres fournisseurs permettant de connecter des ordinateurs
mainframe entre eux ainsi qu’avec avec un stockage rattaché, des
postes de travail reliés localement et d’autres périphériques qui
utilisent la technologie de fibre optique et des switches modifiables
dynamiquement, appelés directeurs ESCON. Voir aussi « directeur
ESCON ».
Possibilité de définir plusieurs volumes logiques sur une seule unité
de disque physique pour utiliser la totalité de sa capacité après
formatage. La taille de ces volumes logiques peut être sélectionnée
par l’utilisateur. La taille de volume minimale est un seul cylindre. La
taille maximale dépend de la capacité de l’unité de disque et du mode
d’émulation sélectionné.
É
échec court
échec en écriture
échec en lecture
Les données demandées ne se trouvent pas dans le cache, mais sont
en cours d’extraction.
Le cache ne contient pas suffisamment d’espace pour les données
présentées par l’opération d’écriture.
Les données demandées par l’opération de lecture ne se trouvent pas
dans le cache.
échec long
Les données demandées sont absentes du cache et ne sont pas en
cours d’extraction.
écriture rapide
Dans un système Symmetrix, opération d’écriture à la vitesse du
cache qui ne requiert pas de transfert immédiat de données sur
disque. Les données sont écrites directement dans le cache et sont
disponibles pour écriture asynchrone ultérieure.
écriture rapide différée
Le cache ne contient pas suffisamment d’espace pour les données
présentées par l’opération d’écriture.
331
Glossaire
F
FBA
Fixed Block Architecture, format de stockage de données sur unité de
disque utilisant des blocs de données de taille fixe.
FICON
FICON (Fibre Connectivity) est le nom IBM propriétaire désignant le
protocole de mappage ANSI FC-SB-3 (Single-Byte Command Code
Sets-3) pour le protocole FC (Fibre Channel). Il s’agit d’un protocole
FC de niveau 4 servant à mapper l’infrastructure et le protocole de
câblage précédents (ESCON ou parallèle) d'IBM entre le canal et
l’unité de contrôle avec les services et l’infrastructure FC standard.
FRU
Field Replaceable Unit (pièce de remplacement sur site), composant
remplacé ou ajouté comme une seule entité par le personnel de
maintenance.
G
Go
Gigaoctet, soit 109 octets.
I
ID
ID de contrôleur
Numéro d’identification de contrôleur du directeur auquel les
disques sont reliés pour les besoins du programme EREP. Il existe un
seul ID de contrôleur par sous-système Symmetrix.
ID physique
Numéro d’identification physique du directeur Symmetrix pour les
besoins du programme EREP. Cette valeur est incrémentée
automatiquement d’une unité pour chaque directeur installé dans le
contrôleur Symmetrix. Il doit s’agir d’un nombre pair et d’un numéro
unique au sein du système mainframe. Ce numéro porte le nom de
SCU_ID.
IML
initiateur double
332
Identifiant sous forme de séquence de bits ou de caractères qui
désigne un programme, un périphérique, un contrôleur ou un
système.
Chargement initial du programme de microcode.
Fonction de la baie Symmetrix qui crée automatiquement un chemin
de données de sauvegarde vers les unités de disque directement
desservies par un directeur de disque, au cas où ce dernier ou le
matériel de gestion de ces disques tomberait en panne.
Glossaire
INLINES
iVTOC
Langage de commande utilisé pour le processeur de service
Symmetrix par les techniciens EMC.
L’iVTOC (VTOC instantanée) est une VTOC composée uniquement
de tables, qu’elle formate dans la mémoire VMAX globale sans
utiliser de disque. Elle constitue une solution alternative à la VTOC
existante.
K
Ko
Kilo-octet, soit 1 024 octets.
L
LRU (algorithme
d'ancienneté)
Algorithme permettant d’identifier et de rendre disponible l’espace
de cache en supprimant les données utilisées le moins récemment
(« Least Recently Used »).
LVTOC
LVTOC (VTOC héritée) est le terme par lequel les techniciens EMC
désignent la VTOC afin de la distinguer de l’iVTOC.
M
marqueur d’index
Indique le début et la fin physiques d’une piste.
mécanisme d'accès
Jeu de bras d’accès et de leurs têtes de lecture et écriture, qui se
déplacent en tant que composant indépendant au sein d’un ensemble
disque-têtes (HDA).
mise en miroir
Conservation par une baie Symmetrix de deux copies identiques d’un
volume désigné sur des disques distincts. Chaque volume se met à
jour automatiquement au cours d'une opération d’écriture. Si une
unité de disque est défaillante, Symmetrix utilise automatiquement
l’autre unité.
Mo
Mégaoctet, soit 106 octets.
333
Glossaire
N
nettoyage
numéro de
périphérique
Processus de lecture, de vérification des bits de correction d’erreurs et
de réécriture des données corrigées sur la source.
Valeur qui identifie logiquement une unité de disque dans une
chaîne.
P
paire en miroir
PAV
périphérique
périphérique d’E/S
piste de substitution
piste principale
point d’index
promotion
Volume logique dont toutes les données sont enregistrées deux fois :
une fois sur deux périphériques physiques différents.
Parallel Access Volume, volume à accès parallèle.
Partie du sous-système Symmetrix adressable de manière unique et
composée d’un jeu de bras d’accès, des surfaces de disque associées
et des circuits électroniques requis pour localiser, lire et écrire les
données. Voir aussi « volume ».
Unité d’entrée/sortie adressable, telle qu’une unité de disque.
Piste désignée pour contenir des données à la place d’une piste
principale défectueuse. Voir aussi « piste principale ».
Piste initiale sur laquelle les données sont stockées. Voir aussi « piste
de substitution ».
Point de référence sur la surface du disque qui détermine le début
d’une piste.
Processus de déplacement des données d’une piste de l’unité de
disque vers un slot de cache.
R
remplacement
dynamique
334
Fonction de la baie Symmetrix qui transfère automatiquement les
données d’une unité de disque défaillante vers un disque de secours
disponible afin que les données demeurent parfaitement disponibles.
Cette fonction prend en charge tous les périphériques non mis en
miroir dans le sous-système Symmetrix.
Glossaire
S
slot de cache
SSID
stage
Unité de cache équivalant à une piste.
Pour les émulations de contrôle de stockage 3990, cette valeur
identifie les composants physiques d’un sous-système DASD
logique. Le SSID doit être un numéro unique dans le système hôte. Il
doit être un nombre pair et débuter à zéro.
Écriture des données d’une unité de disque vers le cache.
succès en écriture
Le cache contient un espace suffisant pour les données présentées par
l’opération d’écriture.
succès en lecture
Les données demandées par l’opération de lecture se trouvent dans le
cache.
T
trame
Format de paquet de données dans un environnement ESCON. Voir
aussi « ESCON ».
U
unité de contrôle de
stockage
Composant du sous-système Symmetrix qui connecte ce dernier aux
canaux hôtes. Il exécute les instructions des canaux et communique
avec les directeurs de disque et le cache. Voir aussi « directeur de
canal ».
V
volume
Terme générique qui fait référence à un périphérique de stockage.
Dans le sous-système Symmetrix, un volume correspond à une seule
unité de disque.
volume logique
Périphérique de stockage défini par l’utilisateur. Sur le modèle 5200,
l’utilisateur peut définir une unité de disque physique comme un ou
deux volumes logiques.
volume système
Petit volume logique d’un sous-système de stockage Symmetrix
utilisé pour transmettre à ce dernier les instructions d’un hôte. Il est
configuré sur un disque Symmetrix standard.
335
Glossaire
VTOC
336
Volume Table of Contents, table des matières du volume. La VTOC
est une structure de données logique écrite dans chaque volume pour
le rendre utilisable par l’hôte z/OS. La VTOC est créée à l’aide de
l’utilitaire ICKDSF d’IBM. Cette structure se compose de sept types
de blocs de contrôle du Dataset (DSCB, Dataset Control Block) qui
décrivent collectivement chaque Dataset résidant sur le volume, ainsi
que l’espace disponible sur ce dernier.
Index
Numerics
3390 76, 80
A
ACF2 137
ACS 123
Allocation dynamique (Thin Provisioning) 77
ANTRQST 231
API 28
Automatic Class Selection 123
AutoSwap 153, 158, 185, 186, 188, 190, 191, 196,
198, 199, 200, 227
Avantages 200
B
Bande virtuelle 127, 308, 310, 312
Base de données RKM 42
BCDS 129
BCV 139, 152, 167, 176, 177, 184, 281, 282, 283
Brocade UltraNet Edge 3000 298
Bus-Tech 222, 309, 310
C
Capacité réservée sur le pool 83
CAS 69
Stockage dédié aux contenus fixes 69
Catalog Solution 316, 319
Catalogue ICF 175, 176, 316, 317
Celerra 74, 309, 310, 311, 312, 313
Centera 69, 70, 71, 74, 212, 216, 217, 218, 219, 310
Cluster 221
CentricStor 297, 309, 310
ChangeTracker 157
CHPID 286, 289
Ciena CN 2000 298
Ciena CN 4200 298
CKD 63, 141, 142, 161, 190, 207, 230, 291, 292
CLARiiON 74, 297, 309, 310
Classe de données 122
Classe de gestion 122
Classe de stockage 122, 123
CN 2000 298
CN 4200 298
CNTLUNIT 286
Compatibilité XRC 63
Compatible Flash 228, 229, 230, 231
Compatible Native Flash 59, 228, 231, 232, 233,
234, 235
Compatible Peer 238, 239
COM-PAV 61
COM-PAV/MA 61, 62
Configurations de boucle de disques 37
Consistency Group 158, 163
Consistent Dataset Snap 178
Consolidation 284
Copie simultanée 59, 226
CPU 319
CUIR 226
D
DARE 40, 42
DASDFMT 292
Data at Rest Encryption 40
Data Domain 311
DB2 for z/OS 263
337
Index
DCM 59
Dynamic Channel Management 59
DCP 25, 156, 270
DD890 311, 312, 313
DFSMS 138, 219
DFSMS Media Manager 264
DFSMSdss 231, 233
DFSMShsm 123, 138, 216, 217, 218, 219, 221, 231,
232, 308, 310
Diligent 309
Directeur FA 286
Dispositifs de surveillance DSE 154
Disques EFD (Enterprise Flash Drive) 80, 109,
125, 126, 130, 276, 277
Disques Flash 30, 124, 125, 126, 134, 276
DLm 212, 213, 310, 312
DLm6000 310, 311, 312, 313
DMX 22, 229, 256, 260, 268
DPAV 226
DS8000 233
Duplicate Snap 179
DWDM 298
Dynamic Cache Partitioning 25, 142, 156, 248,
249, 270
E
EAV 24, 63, 226, 249, 266, 267, 268
ECA 153, 178
ECKD 285, 286, 287, 290, 291, 293
ELM 46, 47
EMC Centera 221, 222
API 223, 224
Cluster 221
Mainframe SDK 224
EMC Compatible Flash for z/OS 229
EMC Consistency Groups 185
EMC ControlCenter 142
EMC Disk Library for mainframe 212
EMC Select 296, 298, 299
EMC TimeFinder 231
EMC z/OS Storage Manager 136
EMCQOS 271
EMCSCF 154, 155, 166, 229
EMCSNAP 234, 235
338
Enginuity 28, 29, 30, 31, 33, 47, 48, 49, 60, 61, 62,
63, 64, 66, 76, 118, 144, 155, 156, 158, 162,
163, 164, 166, 167, 170, 177, 183, 229, 230,
232, 233, 234, 237, 239, 245, 259, 260, 268,
274
Enginuity Consistency Assist 153, 178
Enregistrement zéro standard 81
ERDS 48
EREP 48, 49
Erreurs liées à l’environnement 50, 54
Error Recording Data Set 48
ESCON 73, 74, 159, 161, 232, 257, 282, 286, 293,
305, 307, 308
ESDS 327
Extended Address Volume 226
Extended Address Volumes 63, 249
Extended Distance FICON 249, 269
Extension de périphérique 78
EzSM 46, 124, 136, 138, 139, 140, 227
F
Famille de produits TimeFinder pour z/OS 174
TimeFinder/CG 175, 177, 178
TimeFinder/Clone for z/OS 174
FAST 133
FAST VP 25, 77, 108, 118, 119, 120, 121, 122, 123,
124, 125, 126, 130, 131, 132, 133
FBA 80, 141, 142, 161, 190, 230, 234, 258, 286, 287,
290
FCP 286, 287, 289, 290, 294
FDRMOVE 90, 305
FDRPAS 90, 305
Fibre Channel 159, 161
Fichier BIN 65
FICON 24, 32, 64, 73, 74, 161, 232, 248, 252, 255,
256, 257, 258, 259, 260, 261, 263, 264, 268,
269, 272, 282, 286, 291, 293, 299, 305, 306,
307, 308, 310
Express2 264, 269
Express4 264
Express8 264
Extended Distance 269
FlashCopy 24, 59, 129, 226, 228, 229, 230, 231, 232,
233, 234, 235
Fujitsu Siemens Computers 297
Index
G
GDDR 151, 168, 173, 187, 190, 192, 193, 196, 199,
200, 201, 227, 245
GDPS 23, 24, 226, 227, 236, 244, 245
General Pool Maintenance 91
Gestion électronique des licences 45
Gigabit Ethernet 32
GigE 159, 161, 170, 259
Global Mirror 228, 236, 240, 269
GNS 140
GPM 93, 109
Group Name Service 154
GNS 136, 140, 156
Groupe de pistes 76, 77, 78, 80, 82
Groupe de stockage 123
Groupes de stockage FAST 119, 126
IOSQ 62, 249, 252
IOSTEMC 59
iSCSI 32
ISPF 220
ISV 28, 30, 154, 156, 157, 176, 177
iVTOC 43
J
JES2 227, 237, 239
JES3 227, 237, 239
Jeux d’enregistrements 240
Journal d’audit Symmetrix 41
K
KSDS 327
H
L
HCD 23, 65
HCM 23
High Performance FICON 64, 249, 260
HMC 200
HSM 127, 128, 129, 130, 131, 132, 138, 213, 218
HSM Migrator 212, 216, 217, 218, 219, 220, 221,
223, 310
HyperPAV 24, 61, 65, 248, 251, 252, 268, 272, 274
HyperSwap 24
Legacy VTOC 44
Linux 284, 285
Linux on System z 284, 286, 292, 294
LLF 60
LPAR 285
LRU 87
LSS 253
LVTOC 44
M
I
ICKDSF 231
IDAW 255
IDCAMS 327
IECIOSxx 256, 264
ILM 296
InfoMover 207
Innovation Data Processing 305
Instant VTOC 43
Intercom Computer Systems 223
IOCDS 23, 65
IOCP 65, 289, 291, 293
IODEVICE 286, 289
IODEVICES 291
IODF 23
IORP 273
IOS 24, 155, 249, 253
MA 226, 248
Mainframe Data Library 73
Mainframe Enablers 151, 153, 154
MAS 74, 222
MDL 73
Metro Mirror 226, 228, 235, 238
MFE 111
MIBE 33
MIDAW 24, 63, 226, 248, 255, 256
Migration des données 305
MIH 263
Minidisk 285, 286
Mise en file d’attente des priorités d’E/S 226
ML1 127, 128
ML2 127, 128, 131
Mode Copie évolutive avec attente d’écriture 283
Mode disque de Copie évolutive 283
339
Index
Modified Indirect Data Address Word 226, 248
MPLF/CA 60
MSC 166
MSS 65
Multi Reader 240
Multi-Path Lock Facility/Concurrent Access 60
Multipathing 293
Multiple Allegiance 61, 226, 248, 254
Multiple Subchannel Sets 65
Multi-Session Consistency 153, 166
MultiSubsystem Imaging 60
Multitrack High Performance FICON 64
N
Niveau FAST 119
Niveaux de gravité des alertes SIM 49
Non-VSAM 317
Nortel Optical Metro 3500 298
Notification des erreurs 47
Numéro de série alphanumérique 67
O
OLTP 130
OSA 223
P
P 78
Parallel Access Volume 61, 226, 248, 250
PARALLEL SNAP 184
Partitioned Data Set Assist 61
Partitioned Dataset (PDS) Search Assist 61
PAV 24, 226, 248, 249, 250, 251
PAV dynamique 226, 248, 250, 251, 252, 253
PAV statique 248, 250
PCI-Express 33
PDS Search Assist 226
PDSE 263
Peer-to-Peer Remote Copy 62
Performance Essential 319, 321, 323, 326, 328
Périodes 121
Persistent IU Pacing 64, 269
Pool virtuel 76, 77, 78, 80
PowerPath 207, 294
PPRC 24, 62, 226, 235, 238, 244, 245
PREALLOCATE 81
340
Preserve Mirror 183
Princeton Softech 222
Prise en charge des unités de contrôle 2105 67
Prise en charge des unités de contrôle 2107 67
Q
QoS 156, 282
R
R 151
R21 166
RACF 137, 175, 176, 177, 187
RAID 22, 137
RAID 10 85
RAID 5 292
RAID 6 292
RAIN 69
Rapid IO 33
RECALL 127, 130, 132
Red Hat 285, 293
Rééquilibrage de thin pool 86
REFVTOC 90
Règles FAST 120
Remote Adapter 170
Remote Pair FlashCopy 183
ResourcePak 151, 154, 282, 283
ResourcePak Base 151, 154, 155, 158, 160, 163, 173,
184, 185, 187, 200, 227, 229, 231, 271, 274,
280, 282
REXX 157, 161
RHEL 294
RIO 33
RKM 40
RMF 258
RSA® Data Protection Manager 40
RTO 150
S
SATA 30, 80, 105, 109, 119, 124, 126, 131, 132, 134
SCF 91, 111
SDDF 59
Sécurité 142
Sequential Data Striping 60, 226
Serial Advanced Technology
Attachment (SATA) 134
Index
Service Information Message 49
Services mainframe 302
SIM 49
Simultaneous TimeFinder/Clone 181, 183
SLED 22
SLES 293, 294
SMC 141, 143, 289
SMS 119, 122, 123, 124, 125, 126, 128, 129, 138
SNAP DATASET 152, 178, 181, 182, 184
SNAP VOLUME 152, 182
Softek 305
Solutions Enabler 124, 294
SONET 298
SPA 143
SPC 156, 272, 273, 274
SPE 157, 161
SPLIT 152
SRDF 25, 91, 136, 138, 142, 151, 158, 159, 160, 161,
200, 207, 230, 239, 280, 281, 282, 283, 298,
303, 304, 305, 312
Asynchronous 162, 163
Automated Replication 177, 184
Cascaded 159, 166, 168
Cascaded SRDF/Star 196
Concurrent 163
Concurrent SRDF/A 165
Consistency 187
Consistency Group 160, 172
Consistency Groups 168
Data Mobility 163
EDP 159, 167
Extended Distance Protection 167, 168
Host Component 142, 151, 159, 160, 161, 169
SRDF/A Monitor (Processus de contrôle de
SRDF/A) 154
SRDF/AR 154, 168, 173, 177
Star 159, 163, 164, 165, 168, 173, 184, 188, 193,
196
Synchronous 162, 163, 187, 199
SRDF/A 166
Monitor 154
SRDF/A Delta Set Extension 111
SRDF/A Monitor (Processus de contrôle de
SRDF/A) 154
SRDF/AR 168
SRDF/Asynchronous 153, 164, 166, 199
SRDF/DM 163
SRDF/S 186
SRDF/Star 167
SSID 60
Stockage hiérarchisé 142
StorageTek 309
Surcharge 47
Surveillance de la réplication 142
SUSE 285, 293
SYMCLI 141, 289, 294
SymmAPI 155, 282
SymmAPI for TPF 282
Symmetrix Control Facility 111, 124
Symmetrix Management Console 141, 289
Symmetrix Priority Control 142, 248, 249, 272, 274
Symmetrix Priority Controls 25
SymmMerge 134
SYS1.LINKLIB 59
SYS1.PARMLIB 256, 264
Sysplex 186
T
TCW 261
TDMF 90, 305
Technologies de disque 36
TFU 153
Thin pool 76, 77, 78, 79, 80, 81, 82, 83, 84
Thin Reclaim Utility 88, 91
Tier Advisor 133
TimeFinder 25, 142, 151, 152, 158, 174, 184, 230,
239, 280, 281, 282, 303, 304
TimeFinder Utility 153, 175, 176, 184
TimeFinder/Clone 105, 152, 174, 175, 177, 178,
184, 281
TimeFinder/Clone Mainframe SNAP Facility
174, 176, 229, 231
TimeFinder/Mirror 136, 138, 139, 152, 174, 175,
176, 177, 178, 281
TimeFinder/SNAP 111
TimeFinder/Snap 136, 139, 175, 178, 184
TMM 309
TopSecret 137
TPF 280, 281, 282, 283
Transport Mode 261
TRU 88, 91
341
Index
U
Z
Unisphere 124, 289
z/OS Global Mirror 63, 226
z/OS Migrator 89, 305
z/VM 284, 285, 286, 287, 289
ZDMF 90
ZHPF 264
zHPF 24, 64, 249, 259, 260, 261, 263, 264, 265, 266
zHPF multitrack 64, 249
V
VDEV 175, 176
Vérification de l’environnement 48
Vérification de l’équipement 47
Vérification des données 47
Vérification du système ou du programme 47
Virtual Provisioning 75, 76, 77, 78, 80, 82, 85, 93,
108
VLUN VP 108
VMAX 22, 23, 24, 28, 30, 120, 121, 177, 245, 252,
254, 256, 258, 260, 264, 265, 266, 268, 274,
275
VNX 310, 311, 312, 313
VNX750 313
VNX7500 312, 313
VOLSER 142
Volumes thin 76, 78, 80, 81, 83
VSAM 219, 263, 317, 319, 320, 326
VSAM Quick Index 326
VSM 309
VTEC 310
VTFM 309, 310
VTOC 43, 80, 128, 176, 317
VTS 309
VVDS 153, 176, 317
W
WebSphere MQ 263
WLM 25, 250, 253, 272, 273, 274
Workload Manager 25
X
XRC 24, 63, 226, 241, 243, 244, 245, 269
342

Présentation des technologies mainframe EMC

Transcription

Documents pareils

Evaluation d`EMC 4ème, collège Le Cèdre, Le Vésinet. Trois

Flash EMC - Les bourses sur des niveaux records

Bac Pro EDPI

Diaporama EMC Cycle 2 ( PDF

Courrier Changement Adresse EMC

www.emc2.fr Présentation Générale de la Société EMC Corporation

emc vnx : jusqu`à 160 % plus rapide que les

Les outils de contrôle de la qualité et de test des