IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Les disques, cassettes, et bandes magnétiques dans l'environnement z/OS

Les supports physiques du mainframe

Ce document présente les supports magnétiques actuels sous z/OS et les versions précédentes de ce système d'exploitation. Il reste général et présente l'histoire, l'état de l'art (si je peux me permettre cette expression) et mon interprétation du futur de ces supports.

Après votre lecture, n'hésitez pas à partager vos expériences : 7 commentaires Donner une note à l´article (5)

Article lu   fois.

L'auteur

Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Les disques

I-A. Historique

La nécessité de stocker des données sur un support magnétique à accès direct est apparue dès l'utilisation des ordinateurs. La première demande a été effectuée par l'armée américaine en 1955 qui a abouti à la création du 350 RAMAC : un monstre de plus d'une tonne pour un stockage de 3,75 Mb.

Nous ne présentons que les disques vendus par IBM et ses concurrents à partir de l'apparition du SYSTEM/360.

Modèle

Capacité

Temps d'accès moyen (ms)

Débit

Commentaires

2311

7,25 Mb

85

156 Kb/s

Disques démontables

2314

29,8 Mb

85

310 Kb/s

Disques démontables

3330

100 Mb

30

806 Kb/s

Disques démontables - Apparition de la correction d'erreur

3340

70 Mb

25

885 Kb/s

Apparitions de têtes fixes sur les premiers cylindres

3350

317 Mb

25

1,2 Mb/s

Têtes fixes sur les premiers cylindres (seek time nul sur les 5 premiers cylindres)

3370

571 Mb

20

1,86 Mb/s

Apparition des têtes en film mince - Structure des enregistrements en FBA pour DOS et VM

3375

571 Mb

20

1,86 Mb/s

Structure des enregistrements en CKD pour System/370

3380

1,26 Gb

12

3 Mb/s

3380K : 1,89 Gb

3390

2,84 Gb

9,5

4,2 Mb/s

Dernier modèle avec des HDA physiques

On peut voir la croissance des capacités du débit et la décroissance du temps d'accès moyen à une information dues au progrès du magnétisme dans les laboratoires des constructeurs.

Les 3390 seront les derniers disques utilisant cette technologie (HDA physiques).

Désormais, la technologie des unités de contrôle utilisant des disques « en grappe », moins chère et offrant des possibilités nouvelles sera la norme.

Dans les années 80, MEMOREX (un concurrent d'IBM pour les disques et la mémoire) présente un tambour électronique. Émulant un 3380, c'est une unité sans pièces mobiles, rien que de la mémoire mais très cher. Il était réservé pour placer des fichiers très utilisés (Temporary Storage d'un gros CICS par exemple). Il n'eut pas le succès attendu. Une anecdote : lors d'une visite du labo MVS de Poughkeepsie, nous avons reconnu un tambour électronique MEMOREX bien que la couleur soit devenue bleue et que les logos aient disparu.

En 1990, EMC (EMC2 à cette époque) proposait des unités de contrôle intégrant des disques du marché, des minis et des micros (« Des disques de PC ! » m'avait dit un commercial d'IBM) 30 % moins cher que les disques IBM et permettant la mise en œuvre des technologies RAID (Redundant Array of Independent Disks).

I-B. Définition des niveaux de RAID

L'université de Berkeley a défini sept niveaux de technologie RAID.

Quatre sont utilisés aujourd'hui : un pour la performance (RAID 0) et trois pour la sécurité (RAID 1, RAID 5 et RAID 6).

I-B-1. RAID 0

Image non disponible
RAID0

Le niveau 0 (appelé également striping ou entrelacement) utilise deux ou plusieurs disques en écrivant les blocs du fichier sur les disques tel qu'indiqué dans la figure ci-contre.

Cela permet d'accélérer la lecture ou l'écriture. Par contre, il n'offre aucune possibilité de restaurer un fichier après la perte d'un des disques.

Il est souvent utilisé en complément des autres niveaux.

I-B-2. RAID 1

Image non disponible
RAID1

Le niveau 1 a pour but de dupliquer l'information à stocker sur deux disques. On parle de mirroring pour désigner ce procédé.

La sécurité est assurée par redondance. Si un des disques tombe en panne, l'autre continue à fonctionner.

En contrepartie la technologie RAID1 est très onéreuse étant donné que chaque volume principal doit être doublé. Seule la moitié de la capacité de stockage est effectivement utilisée. Pour des raisons de performance, c'est ce niveau qui est utilisé dans les baies de disques.

I-B-3. RAID 5

Image non disponible
RAID5

Dans ce mode, les données sont stockées au niveau du bloc et la parité est calculée au niveau d'un secteur (plusieurs blocs) et répartie sur l'ensemble des disques.

Le mode RAID 5 permet d'obtenir des performances très proches de celles obtenues en RAID 0, tout en assurant une tolérance aux pannes élevée, c'est la raison pour laquelle c'est un des modes RAID les plus intéressants en termes de performance et de fiabilité.

Il faut au moins trois disques pour implanter un mode RAID 5.

I-B-4. RAID 6

Ce niveau est presque identique à celui du RAID 5 avec le stockage de deux parités au lieu d'une sur deux disques différents.

Il est moins utilisé que le RAID 5.

Il faut au moins quatre disques pour implanter ce mode.

I-B-5. RAID 1+0 ou 10

On peut combiner ces deux modes afin de sécuriser le mode RAID 0 en y ajoutant des disques « miroir ».

I-C. Structure d'une baie de disques

Image non disponible
Structure Baie de Disques

La structure représentée est très simplifiée et contient les principales fonctions qu'assure la baie de disques :

  • Gestion des interfaces avec les différents types de canaux pour z/OS (FICON) ou les systèmes distribués (Fiber Channel, iSCSI). La baie peut généralement accepter de partager les disques qu'elle contient entre les deux systèmes d'exploitation, mais chacun d'eux ne connaît que les disques qui lui sont attribués. L'étanchéité est absolue, car les modes d'enregistrement des données sont différents : CKD (Count Key Data) pour z/OS et FBA (Fixed Block Architecture) pour les systèmes distribués. Seul le logiciel de gestion du constructeur implanté dans la baie peut « voir » les deux espaces disques.

Si les disques sont répliqués, des canaux Fiber Channel sont utilisés pour la connexion avec la baie de disques distante.

  • Gestion des données en lecture :

    • Si cette donnée est présente dans le cache, elle est passée à l'interface avec un canal (qui n'est pas forcément celui qui a initié la requête) afin de transférer celle-ci vers la CPU.
    • Dans le cas contraire, une requête est faite vers l'interface avec les unités de stockage où elle réside. C'est un « READ MISS » qui est comptabilisé dans les statistiques de RMF. Lorsque la donnée est remontée dans le cache, l'interface avec les données est avertie et la transfère vers un canal.
  • Gestion des données en écriture. L'interface avec les données vérifie qu'une zone de la mémoire non volatile (NVS) est disponible pour y stocker cette donnée :

    • Si oui, elle écrit cette donnée dans la mémoire non volatile et indique à l'interface avec les canaux que la donnée est stockée. L'interface avec les unités de stockage se charge d'écrire en asynchrone la donnée sur le disque qui lui est attribué. La donnée étant écrite dans la mémoire NVS, elle est conservée dans cette mémoire tant qu'elle n'est pas écrite sur un disque, même en cas de coupure d'électricité de la baie.
    • Si non, l'interface avec les données libère un espace dans la NVS avant de la stocker. C'est un « WRITE MISS » qui est également comptabilisé dans les statistiques RMF. Elle indique alors à l'interface avec les canaux que la donnée est stockée dans la baie. L'interface avec les unités de stockage se charge d'écrire la donnée sur le disque qui lui est attribué comme précédemment.
  • Gestion de la mémoire cache : cette mémoire est généralement de grande taille (multiple de 64 Gb). Les données y résident en fonction des requêtes faites par les applications. Plus une donnée est référencée en lecture, moins elle a de chance d'être supprimée du cache (on dit maintenant « Hot Data ») et d'être présente lorsqu'on la demande.
  • Gestion des unités de stockage :

    • En lecture, elle assure la remontée des données vers le cache lorsque celles-ci doivent être recherchées sur les différents disques dont la baie est équipée. Plusieurs blocs de données sont généralement remontés dans le cache en prévision des demandes futures (lecture séquentielle par exemple). Chaque constructeur possède son propre algorithme de prévision.
    • En écriture, elle assure le transfert des données de la mémoire non volatile vers un ou plusieurs disques physiques dont la baie est équipée.
  • Les unités de stockage sont généralement de trois types :

    • Les disques dits « HDD » qui sont connectés à l'interface par des liens Fiber Channel. Leurs capacités sont de 146 à 300 Gb à 15 000 tr/mn (ils coûtent très cher !), de 600 Gb à 1,2 Tb à 10 000 tr/mn.
    • Les disques SATA (Serial ATA) ou SAS (Serial Attached SCSI) sont également connectés par des interfaces plus simples et moins coûteuses que les liens Fiber Channel. Leur capacité actuelle est de 1,6 et 3,2 Tb à 7 200 tr/mn. Ces disques sont moins chers que les précédents.
    • Les disques SSD (Solid State Device) ne contiennent pas de pièces mécaniques (plateaux, bras, moteurs), uniquement de l'électronique (mémoire Flash généralement). De ce fait, leur temps de réponse est très court. Leur capacité actuelle est de 200 et 400 Gb. Il coûte plus cher que les disques « HDD », mais on peut penser que dans l'avenir ils concurrenceront ces disques.

Les constructeurs annoncent des configurations de baies de disques d'une capacité supérieure à 1 Pb et un débit supérieur à un million d'E/S par seconde.

I-D. Les fonctionnalités apportées par z/OS

I-D-1. Le PAV

Le sigle PAV veut dire « Parallel Access Volume ». Cette fonction est apparue en 1990 afin d'apporter une solution à un grave problème d'accès lors de l'apparition des baies de disques.

Les unités de disque physiques (HDA) n'avaient qu'un bras pour lire ou écrire une donnée. Aucune autre opération n'était possible tant que la précédente n'était pas terminée. Un bit dans l'UCB (Unit Control Block) était positionné à 1 (UCB Busy). La requête restait en attente dans la file d'attente de l'IOS (IOSQ) tant que l'E/S n'était pas terminée.

C'est le poids du passé car ce traitement existe depuis les premiers disques des Systems 360.

Comme à cette époque certains utilisateurs avaient encore des 3380 ou 3390 accrochés à des unités de contrôle 3990, la modification de MVS n'était pas envisageable.

La solution d'IBM pour contourner ce problème consiste à créer un ou plusieurs « ALIAS » pour un disque particulièrement chargé en E/S.

Chaque disque possède une adresse appelée BASE liée à un UCB. Si le disque est « busy », WLM effectuera l'opération en attribuant un ALIAS à chaque disque passant par d'autres UCB que celui de l'adresse BASE.

I-D-2. PAV statique

C'est la première solution apportée par IBM.

On attribue un ou plusieurs ALIAS à un UCB (BASE) dont on estime qu'il aura une forte charge en E/S. Cette définition est effectuée lors de la création d'un HCD (Hardware Configuration Definition).

La variété des charges dans la journée (WORKLOAD) ne permet pas une modulation des ALIAS entre TP et Batch. Si la charge de la BASE est mal estimée, il faut refaire une configuration matérielle.

I-D-3. PAV dynamique

Le sous-canal de 256 UCB est partagé entre BASE et ALIAS. Il n'y a pas de relation entre BASE et ALIAS. Lorsque l'UCB d'une BASE est « busy », WLM cherche un ALIAS dans ceux définis et en sélectionne un afin de permettre l'E/S sur le volume logique de l'unité BASE. Le temps de résidence dans l'IOSQ diminue. Malheureusement, WLM est activé toutes les 10 secondes et de nombreuses E/S sont effectuées durant ce temps.

I-D-4. HyperPAV

Apparue en 2006, cette technique est destinée à répondre à la limite des 64 K unités pouvant être connectées sur une machine z en réduisant le nombre d'ALIAS déclarés dans chaque sous-canal.

Un pool d'ALIAS est créé pour chaque sous-canal. Le principe est le même que pour le PAV dynamique, mais elle est effectuée pour chaque E/S et l'ALIAS est retourné dans le pool à la fin de l'E/S. Le temps de résidence en IOSQ devient nul.

Une simple commande dans le membre IECIOSxx permet de l'activer à l'IPL.

I-D-5. Extended Address Volume

Certaines configurations importantes (US principalement) se trouvent à l'étroit malgré la possibilité de disposer de 65 536 UCB (de ‘0000' à ‘FFFF' en EBCDIC). Passer de 4 à 5 octets pour augmenter ce nombre n'était pas la solution pour z/OS.

D'autre part, la limite de 65 520 cylindres pour un fichier était un frein à l'augmentation de l'espace de stockage.

Pour répondre à ces problèmes, IBM a choisi d'augmenter la taille des volumes.

Un volume EAV permet l'allocation d'un fichier de plus de 65 520 cylindres. Ceci nécessite un nouveau format d'adressage.

Actuellement, l'adressage d'une donnée utilise 16 bits de la forme CCCCHHHH (CCCC = Cylindre, HHHH = Piste).

Pour aller au-dessus de 65 520 cylindres, il faut un nouveau format d'adressage.

Les caractéristiques utilisées par DFSMS sont celles des 3390 (15 pistes par cylindre et 56 k pour la taille de la piste) et ne changeront plus. Quatre bits suffisent donc pour indiquer la piste dans le cylindre. Les douze autres bits sont nuls.

Afin de faire sauter cette limite, l'adressage des cylindres peut s'effectuer sur 28 bits de la forme CCCCcccH avec :

  • H = 4 bits pour le numéro de piste,
  • ccc = 12 bits de rang le plus haut dans l'adressage 28 bits des cylindres,
  • CCCC = 16 bits de rang le plus bas dans l'adressage 28 bits des cylindres.

Le numéro du cylindre n'est plus sous une forme contiguë.

Ce format préserve l'existant : si ccc est nul, le volume fait moins de 65 520 cylindres. Dans le cas contraire, c'est un volume EAV.

Avec ce nouveau mode d'adressage, la taille maximale théorique d'un volume EAV est de 268 434 453 cylindres soit 228 TB ! Actuellement, la taille maximale est de 1 Tb (z/OS V1R13).

Aujourd'hui, tous les fichiers peuvent être EAV sauf quelques fichiers spécifiques (les fichiers PAGE, les VTOC et VTOC index, etc.).

Les volumes EAV sont créés dans les baies de disques (avec un microcode spécifique) par l'intermédiaire de l'interface web. Ils ne nécessitent pas de modifications de l'IOCDS de z/OS. On indique simplement à DFSMS que nous utiliserons des volumes EAV (USEEAV(YES|NO)).

I-D-6. zHPF

zHPF (z High Performance FICON) est un nouveau protocole développé pour accélérer les E/S des canaux FICON. Il remplace celui basé sur des CCW et CSW que nous connaissions jusqu'à aujourd'hui.

Sans entrer dans les détails, le nouveau protocole diminue les échanges entre le canal et l'unité de contrôle et permet donc d'augmenter le nombre d'E/S de plus de 70 % pour un canal FICON occupé à 100 %.

Il est particulièrement efficace lors des transferts d'enregistrements de 4K (DB2, VSAM, PDSE, etc.).

Les constructeurs de baies concurrents d'IBM ont implanté ce protocole dans leurs unités de contrôle.

zHPF n'a aucun impact sur les données ou les applications. Il s'active par une commande MVS (SET IOS ZHPF=YES or NO).

I-E. Anatomie d'une I/O

Le schéma ci-dessous indique le cheminement des actions pour lire ou écrire un bloc sur disque :

Image non disponible
Anatomie d'une I/O
  1. L'application effectue une requête à la méthode d'accès pour une lecture ou une écriture (GET, PUT, READ, WRITE).
  2. La méthode d'accès détermine si la requête doit conduire à une lecture ou à l'écriture d'un bloc de données. Cela ce traduit par la réalisation d'un EXCP (Execute Channel Program).
  3. Cet EXCP construit les CCW (Channel Command Word) ou les DCW (Device command Word), fixe les pages des buffers et des CCW ou DCW, etc. L'I/O Supervisor place l'EXCP dans une file d'attente qui sera traitée par le SAP (System Assist Processor).
  4. Ce SAP est un des processeurs de la machine z. Il est spécialisé dans le traitement des E/S par un microcode spécifique. Il peut y avoir plusieurs SAP dans une machine z. À partir des UCB, il sélectionne l'unité destinatrice et effectue une instruction START SUBCHANNEL (SSCH) à destination du système de gestion des canaux.
  5. Celui-ci sélectionne un chemin entre un canal (CHPID) et l'unité de contrôle du disque et initialise la commande vers l'unité de contrôle.
  6. L'unité de contrôle vérifie la disponibilité de l'unité et initialise l'E/S sur l'unité. Dans certains cas, elle libère le canal qui peut être utilisé pour une autre E/S. L'unité de contrôle attend que l'opération soit effectuée (lecture ou écriture).
  7. Le disque exécute la commande afin de retrouver l'enregistrement ou d'écrire un enregistrement.
  8. Lorsque l'opération est terminée, l'unité de contrôle est avertie et récupère les données dans un buffer afin de les rendre en cas de lecture.
  9. Le contrôleur déconnecte alors l'unité qui libère les buffers utilisés et remonte l'information vers un canal qui n'est pas forcément celui qui a initialisé l'E/S.
  10. Lorsque l'opération est terminée, le canal signale la fin en provoquant une interruption au niveau z/OS (FLIH = First Level Interrupt Handler) afin d'indiquer la fin de cette opération.
  11. Le SAP traite cette interruption et lance un test sur ce canal (TSCH) afin de connaître l'état de l'opération (réussie ou non).
  12. L'EXCP indique que l'E/S est terminée en « postant » un ECB (Event Control Block) dans la méthode d'accès et active le dispatcheur de z/OS.
  13. Le dispatcheur réactive alors la méthode d'accès.
  14. L'application est avertie de la fin de l'E/S et peut continuer le traitement.

I-F. Quelques informations sur les performances

Sans vouloir rentrer dans les détails de la gestion des performances des baies de disques, la connaissance de quelques indicateurs est nécessaire.

L'objectif principal est le temps de réponse de l'E/S afin d'offrir un bon service à l'utilisateur derrière son écran.

Le tableau ci-dessous présente un extrait des enregistrements RMF reformatés dans un tableau EXCEL datant de 2007 (Sans HiperPav) sur une durée de 15 mn en heure de pointe :

VOLSER

PAV

I/O Rate

Read

Write

Resp Time

IOSQ Time

Pending Time

Discon Time

Connect Time

Read hit

Write hit

TEMPO3

3

102,00

53,90

43,30

2,80

0,20

0,40

1,50

0,60

0,919

1,000

TEMPO2

2

102,70

54,20

43,80

4,80

0,90

0,30

2,70

0,90

0,920

1,000

PRD338

2

92,00

51,50

39,10

3,50

0,00

0,30

2,30

0,80

0,973

1,000

PRD330

4

340,90

82,20

257,30

2,90

0,10

0,30

1,90

0,60

0,983

1,000

DB2Q25

2

161,00

155,10

4,60

1,50

0,10

0,30

0,20

0,90

0,992

1,000

On ne s'intéresse qu'aux volumes dont le débit en lecture est supérieur à 50 E/S par seconde.

Les règles généralement utilisées pour les « Read Hits » :

  • rien à dire pour des valeurs comprises entre 95 à 100 %,
  • à surveiller pour des valeurs comprises entre 90 et 95 %,
  • faire une action si le taux est inférieur à 90 % (équilibrer les disques ou unités de disques ou ajouter du cache à la baie de disques).

Par contre, le « Write hit » doit toujours être égal à 100 %.

Le temps de réponse est la somme de :

Tr = IOSQ time + Pending time + Disconnect time + Connect time

  • L'IOSQ time n'est pas nul en l'absence ou avec une mauvaise configuration des PAV.
  • Le Pending time peut être dû à un RESERVE placé par une autre partition ou de l'unité de contrôle non prête qui provoque l'attente du canal pour exécuter l'E/S.
  • Le Disconnect time peut être dû à la copie synchrone à distance, un Read miss ou l'unité de contrôle occupée.
  • Le Connect time représente le temps de transfert des données vers le canal.

I-G. Les fonctions complémentaires des baies de disques

Les baies de disques disposent de fonctionnalités (payantes naturellement) dont nous présentons les plus courantes. Nous utiliserons la dénomination d'IBM, chaque constructeur les décline sous d'autres noms.

I-G-1. PPRC (Peer to Peer Remote Copy)

Cette fonction permet l'écriture synchrone d'un enregistrement sur deux baies de disques distantes (Miroir à distance).

Les deux baies sont reliées par des liens Fiber Channel en fibre optique.

Lorsqu'une application écrit un enregistrement sur un disque logique (primaire) d'une baie, celle-ci envoie l'enregistrement sur une baie distante et attend que l'écriture de cet enregistrement sur le disque logique (secondaire) de la baie distante (en mémoire non volatile) soit effective avant de rendre la main à l'application. Nous avons bien une écriture synchrone sur deux baies de l'enregistrement.

Les volumes secondaires appartiennent au site primaire. Il est impossible de les « voir » depuis le site secondaire sans désactiver la réplication.

En cas de perte du site primaire, il est possible de reprendre l'exploitation sur le site secondaire, aucun enregistrement n'ayant été perdu.

Dans ce cas, il est nécessaire d'effectuer une opération pour supprimer le lien entre les deux baies et permettre au second site de mettre « ON LINE » les disques secondaires.

La distance entre les deux sites impacte directement le temps d'écriture d'un enregistrement.

En cas de rupture des liens entre les deux sites, la baie utilise une « bit map » par volume pour noter quelles sont les pistes qui ont été modifiées.

Lorsque les liens sont rétablis, la baie primaire transfère uniquement les pistes modifiées du volume primaire vers le volume secondaire en tâche de fond. Lorsque les deux disques sont au même niveau, la baie émet un message d'acquittement vers la console z/OS.

Cette technique est aussi appelée METRO MIRROR chez IBM.

I-G-2. XRC (Extended Remote Copy)

C'est la version asynchrone de PPRC. Elle permet de stocker des données du site de production vers un centre secondaire situé à des centaines de kilomètres du site de production. Sa dénomination actuelle par IBM est GLOBAL MIRROR.

À cause de la distance, la réplication asynchrone s'impose pour deux raisons :

  • Le temps de réponse de l'écriture devient insupportable pour les utilisateurs.
  • L'établissement de liens à gros débit entre les deux sites peut être prohibitif financièrement.

Sa mise en œuvre nécessite la fonctionnalité SDM (System Data Mover) de z/OS qui contrôle le transfert sur le site de secours.

Lorsqu'une donnée est écrite dans le cache, un Time Stamp lui est accolé à partir du SYSPLEX TIMER. La mise à jour d'un volume pouvant être effectuée par plusieurs partitions, il importe d'avoir une source unique de temps. SDM lit ces données et les transfère sur le site secondaire avec le Time Stamp afin d'écrire les données sur le site secondaire dans l'ordre dans lequel elles ont été créées.

I-G-3. FlashCopy

Cette fonctionnalité permet la copie instantanée de données d'un volume primaire vers un volume cible sans interrompre le processus de mise à jour des informations du volume primaire.

Deux types de traitement sont assurés par Flashcopy :

  • au niveau du volume,
  • au niveau d'un fichier.

Pour le volume, cette copie peut être totale (la première fois) ou incrémentale (on ne met à jour que les pistes qui ont été modifiées depuis la dernière opération de Flashcopy.

L'exécution d'un Flashcopy comporte deux phases :

  • La copie logique qui met en Å“uvre un jeu de pointeur dans la baie de disques et la création d'une « Bit Map ». Cette opération est effectuée en quelques millisecondes et n'affecte pas le volume primaire d'où le terme « instantané ».
  • La copie physique des pistes du volume primaire vers le volume secondaire s'effectue en tâche de fond.

Le volume secondaire n'est disponible que lorsque toutes les pistes du volume primaire auront été copiées sur le disque secondaire. Celui-ci sera alors le clone du volume primaire à l'instant où la commande Flashcopy aura été passée. Le volume secondaire est alors disponible pour un traitement par une autre LPAR (par exemple : DUMP sur cassette et envoi vers un site de secours).

Cette opération peut être ponctuelle pour sauvegarder régulièrement des données pouvant être corrompues lors d'un traitement. On appelle cela « Point In Time » (PIT).

Il est possible d'effectuer un Flashcopy sur plusieurs centaines de volumes contenus dans des baies différentes.

Il faut s'assurer qu'aucune modification ne s'effectue durant la copie logique afin de préserver la cohérence des données. Cela s'appelle « Point Of Consistancy » (POC). La fin d'une production hebdomadaire est souvent un POC avant les sauvegardes pour le site de secours.

Même si cette copie logique ne prend que quelques millisecondes par volume, elle peut durer plusieurs secondes pour des centaines de volumes. La baie de disques fait alors une opération de gel des écritures (« FREEZE ») le temps de l'exécution de la copie logique. Lorsque celle-ci est terminée, les E/S en attente sont relancées (« RESUME »).

Cette technique est utilisée dans la mise en œuvre d'un « GLOBAL MIRROR ».

Nota : le POC peut aussi prendre en compte des disques utilisés par les systèmes distribués.

I-G-4. Migration de baies

Les constructeurs offre des services permettant de migrer des volumes d'une baie à une autre sans interruption du service.

Ces migrations peuvent s'effectuer sur des baies du même constructeur ou de constructeurs différents.

II. Les bandes et cassettes

II-A. Historique

II-A-1. Les bandes et cassettes

Comme pour les disques, nous ne présenterons que les dérouleurs de bandes et de cassettes apparus depuis le SYSTEM 360 :

Unité

Nombre de pistes

Support

Densité

Capacité

Débit

Commentaires

2400

9

Bande magnétique

de 800 à 1600 bpi

de 20 à 140 Mb

de 15 à 320 Kbps

Premier dérouleur à puits à vide

3400

9

Bande magnétique

1600 - 6250 bpi

170 Mb

1,25 Mbps

Chargement automatique de la bande

3480

18

Cassette

6250 bpi

200 Mb

3 Mbps

Utilisation d'une cassette de 4"x5"x1"

3490

18 ou 36

Cassette

N/A

800 Mb

4,5 ou 9 Mbps

Utilisation de la compression (IDRC)

3590

de 128 à 1152

Cassette

N/A

de 10 à 640 Gb

de 9 à 160 Mbps

Utilisation de la compression

Les premières unités (2400,3420) utilisaient des bandes magnétiques de 10½ pouces de diamètre. L'inertie de ces bandes nécessitait un puits à vide pour permettre de respecter la vitesse de défilement du support magnétique.

C'est vers cette époque que sont apparus les logiciels de gestion d'un parc de bandes et de cassettes (TLMS, CA-1 et DFSMSrmm plus tard).

Ces logiciels ont simplifié le travail des préparateurs de JCL en banalisant le parc de bandes en éliminant l'obligation d'indiquer un VOLSER.

Il a également permis aux entreprises de réduire considérablement leur parc de supports magnétiques comme pour les disques avec DFSMS.

À partir des 3480, les bandes magnétiques furent abandonnées au profit de cassettes plus petites (4"x5"x1") et plus denses qui deviennent le standard des cassettes pour IBM. L'inertie mise en jeu était plus faible et les capacités de stockage plus importantes.

La taille des fichiers stockés sur cassettes n'évoluent pas aussi vite que la technologie : des cassettes de 40 Gb peuvent contenir des fichiers de moins de 1 Gb.

Les dérouleurs physiques étant en nombre limités dans une exploitation, les traitements batch de nuit sont souvent en attente d'un dérouleur libre (message IEF238D jobname - REPLY [DEVICE NAME] [,] [‘WAIT'] OR ‘CANCEL' bien connu des pupitreurs de l'époque), conduisant très souvent à des débordements des travaux batch sur la fenêtre TP.

II-A-2. Utilisation de TMM

TMM (Tape Mount Management) est une méthodologie proposée par IBM pour réduire le nombre de montages de cassettes et réduire les temps d'attente d'un dérouleur libre par les travaux de batch.

Par l'intermédiaire de DFSMS, elle consiste à stocker sur disque des fichiers de petite taille et qui ne sont pas à destination du coffre.

Ses avantages sont :

  • pas de modifications des JCL de production,
  • diminution du nombre de montages de cassettes donc de la durée de la fenêtre batch,
  • meilleure utilisation des cassettes de grande capacité lors de la migration des fichiers par DFSMShsm ou autre logiciel.

L'inconvénient est de disposer d'un espace disque supplémentaire pour le stockage.

Cette méthodologie a souvent été utilisée en attendant la mise en œuvre des cassettes virtuelles (VTS) d'où l'avantage de ne pas modifier le JCL des travaux de production. Elle sera peut-être réutilisée dans le futur.

Tout l'art du gestionnaire des médias est de trouver l'équilibre entre la diminution du nombre de montages et la taille du buffer disques utilisé.

Le choix des fichiers à passer sous TMM va permettre de constituer une ou plusieurs FILTLIST qui seront utilisées par l'ACS routine de DATA CLASS afin de diriger ces fichiers vers un pool de disques avec des paramètres d'allocation adéquats (espace primaire et secondaire en particulier).

II-A-3. Une unité particulière : 3850

Annoncée en 1974, cette unité de stockage de masse (appelée MSS également) est l'ancêtre des systèmes de cassettes virtuelles.

Elle se compose de trois parties :

  • La librairie 3851 Mass Storage Facility qui gère des cartouches cylindriques dans des alvéoles hexagonales (identiques aux rayons d'une ruche). Deux bras permettent à cette librairie de rechercher une cartouche pour la placer dans un lecteur ou de la replacer dans une alvéole. Chaque cartouche a une capacité de stockage de 50 MB. L'utilisateur ne peut adresser directement cette librairie.
  • Un pool de disques 3330 est utilisé pour stocker les données en provenance de l'application ou de la librairie (staging ou destaging). Ces disques ne sont pas accessibles directement par une application.
  • Une unité de contrôle 3830-3 contenant un microcode permettant d'assurer la gestion du pool de disques et la liaison avec la librairie.

Le 3850 a été beaucoup utilisé dans les grands centres informatiques (banques, assurances, etc.). Il avait malheureusement une forte tendance à perdre ses tables ce qui provoquait une perturbation importante des travaux batch.

II-A-4. Le coffre

C'est un site appartenant ou non à l'entreprise où sont stockées dans des coffres généralement ignifugés les bandes ou cassettes nécessaires au redémarrage de l'exploitation de tout ou partie des applications critiques d'une entreprise. Ceci implique de sauvegarder la partie système (le système d'exploitation et les logiciels nécessaires à l'exploitation des applications) et la partie applicative (base de données, données utilisées par les batch, etc.).

L'alimentation de ce site s'effectue à des périodes définies par l'entreprise (journalière, hebdomadaire, mensuelle, etc.). Ceci se traduit par des mouvements de bandes ou cassettes entrants et sortants impliquant un ballet de valises de transport.

Des tests de reprises de l'exploitation sont réalisés régulièrement avec plus ou moins de succès (PRA = Plan de Reprise d'Activité).

Si le coffre est encore utilisé par certaines entreprises, il est ou sera remplacé par un coffre électronique situé dans un site sans personnel. Il n'y aura plus de mouvements de cassettes entrants ou sortants dans le site de production.

II-B. Les lecteurs de cassettes

Les lecteurs de cassettes pour les configurations système z sont essentiellement basés sur l'architecture des 3490 et des 3590.

Les unités 3490 étaient et sont toujours adaptées aux sauvegardes intégrées des applications de production caractérisées par :

  • la faible taille de ces sauvegardes (moins de 1 Gb généralement),
  • la limite d'un BLKSIZE de 32K par les méthodes d'accès.

C'est ce type d'unité qui est utilisé pour les cassettes virtuelles.

La grande différence de capacité entre les 3490 et 3590 implique un faible taux de remplissage pour ces sauvegardes car souvent, le gap entre les enregistrements est supérieur à la taille de l'enregistrement.

Les 3590 seront utilisées beaucoup plus efficacement avec des tailles de blocs très importantes. Aujourd'hui, certains lecteurs permettent des tailles de blocs jusqu'à 2 Gb.

De plus, ces unités possèdent des fonctionnalités transparentes pour l'utilisateur :

  • Encryptions du contenu afin d'interdire la lecture des données sur un site n'ayant pas les clés d'encryptions.
  • Compression du contenu afin de diminuer la taille des données sur les cassettes.
  • Cassettes WORM (Write Once Read Many) : cette technologie de stockage facilite la création d'archives conformes aux originaux, par exemple pour les E-Mails ou les données financières (relevés de comptes bancaires).

II-C. Les librairies de cassettes

Afin de diminuer l'activité de montage et démontage des cassettes, les lecteurs ont d'abord été équipés de chargeurs pour les cassettes SCRATCH, puis ont été intégrés dans des librairies contenant plusieurs centaines de cassettes qui ne nécessitaient plus de montages manuels et sont souvent placées dans des locaux sans présence humaine.

Dans les années 80 certaines librairies étaient à base de robots de l'industrie. Elles ont disparu peu à peu. Ne sont restés que les silos de StorageTek bien connu dans les sites informatiques et que l'on voit souvent lors de reportages télévisés sur des sociétés informatiques.

Néanmoins, la mise en œuvre de cassettes externes (cassettes venant de sites externes comme les nouvelles versions du système d'exploitation) nécessitent une présence humaine pour leur introduction dans la librairie et leur reconnaissance par les gestionnaires de bandothèques.

II-D. Les cassettes virtuelles

L'utilisation insuffisante des cassettes de forte capacité (3590) et le nombre limité de dérouleurs disponibles pour l'exploitation ont conduit à la création d'unités interfaces entre les utilisateurs et ces cassettes.

Ces unités (VTL, VSM ou VTS selon les constructeurs) utilisent un buffer de disques comme pour les baies de disques pour stocker les données à écrire sur cassettes et émulent un grand nombre de dérouleurs virtuels (jusqu'à 256).

Ce sont les mêmes disques que pour les baies (Disques Fiber Channel ou SATA mais pas de SDD) en RAID 5 ou 6. Les disques SSD sont utilisés pour la performance en lecture des baies de disques. Pour les sauvegardes ou le ML2 de DFSMShsm, cet aspect performance est secondaire. Le coût des disques SSD rendrait les unités de cassettes virtuelles très chères.

Les applications n'ont plus à attendre un dérouleur et les techniques d'écriture permettent de mieux utiliser les cassettes réelles.

L'écriture de données par une application s'effectue sur les disques de l'unité (c'est un volume logique identifié par le VOLSER). L'écriture sur cassette de ce volume peut s'effectuer dès la fermeture du fichier par l'application ou ultérieurement.

Une interface web intégrée à l'unité permet :

  • la gestion des volumes logiques et physiques,
  • la définition et la modification des constructs SMS spécifiques aux fichiers sur cassettes,
  • la sauvegarde et la restauration des constructs SMS.

Le pool de disques est géré par l'unité de contrôle de virtualisation :

  • allocation d'un espace suffisant pour l'écriture. La taille standard est obtenue par la DATA CLASS des fichiers cassettes. Elle est généralement un multiple de 400 Mb,
  • allocation d'un espace suffisant pour charger les données lors d'une opération de lecture,
  • transfert des données des disques vers les cassettes en tâche de fond,
  • tenue des statistiques d'utilisation du buffer disques et des cassettes,
  • remontée des alertes en cas de dépassement des seuils d'utilisation.
    Ces alertes peuvent être traitées par un logiciel de gestion des opérations (System Automation, CA-OPS ou autre) afin d'être remontées vers le point focal de surveillance.

Nota : certaines commandes de l'interface peuvent être exécutées par commandes z/OS (LIBRARY REQUEST, etc.).

Ces unités permettent également :

  • la compression du contenu afin de diminuer la taille des données sur les cassettes,
  • la déduplication : les données stockées sur cassettes comportent souvent une répétition du contenu. Associée à la compression, une analyse permet - à la volée - de remplacer les données répétées par un code et ainsi diminuer considérablement la taille stockée (près de 90 % annoncé par les constructeurs).

Comme pour les fichiers disques, les données peuvent être répliquées sur un site distant. Seules différences :

  • Le transfert vers le site secondaire s'effectue lors du CLOSE du fichier sur cassette sur le site primaire.
  • La réplication entre les sites utilise des liens ETHERNET avec le protocole TCP/IP plus simple et moins coûteux que les liens Fiber Channel (mais moins rapide).

II-E. Les unités de cassettes virtuelles « TAPELESS »

En 2011 sont apparues des unités de cassettes virtuelles dites « TAPELESS » c'est-à-dire sans lecteurs de cassettes physiques connectés. L'ensemble des données est conservé sur les disques dont elles sont équipées.

L'avantage principal de ces unités est que les données étant déjà dans l'espace disque, leur restitution est quasi immédiate. Plus besoin de rechercher les données sur les cassettes. Ceci est appréciable pour le niveau ML2 de DFSMShsm.

Ces unités occupent moins de place dans les sites (pas de librairies de cassettes), consomment moins d'énergie (électrique, climatisation) et semblent globalement moins coûteuses en exploitation.

L'absence de cassettes permet d'éliminer la perte de cassette ou des cassettes illisibles et la suppression des problèmes de robotique (réglage des lecteurs, maintenance, etc.).

Autre avantage, les tests de reprise d'activité sur le site de secours peuvent être effectués sans interruption de la réplication.

Par contre, l'espace disque doit être suffisant pour ne pas provoquer de blocage lors de l'allocation d'une cassette virtuelle pour écriture.

Ces unités peuvent être couplées ensemble et offrir des tailles de buffer disque supérieures à 1 Petabytes.

Ces unités représentent l'avenir (le « tout disque » espéré depuis plusieurs années). Encore faut-il vaincre les hésitations de certains utilisateurs car pour eux, une sauvegarde est forcément sur cassettes (le poids du passé !).

II-F. Le coffre électronique

La notion de coffre existe toujours dans une production informatique mais son rôle a évolué.

Les opérations de mise au coffre ne sont plus manuelles. Elles sont automatisées grâce aux librairies ou par l'utilisation d'unités de cassettes virtuelles « TAPELESS ».

De plus, les directives Bâle III pour les établissements financiers vont conduire à la création d'un troisième site afin d'assurer de nouveau le service suite à la destruction des deux premiers.

III. De quoi demain sera-t-il fait ?

Le « Big Data » est une réalité. IDC (une société spécialisée dans les études d'évolution de l'informatique) a fait les prévisions suivantes (pour les États-Unis) :

  • La croissance du volume de données créées ou répliquées dépasse 44 % par an pour la prochaine décade.
  • En 2020, ce volume est estimé à 35 zétabytes !
  • 80 % de ces données ne sont pas structurées.

Pour répondre à la mise en œuvre des gigantesques bases de données, les constructeurs de baies de disques ou de cassettes virtuelles vont augmenter la densité des disques qu'elles contiennent sans augmenter la surface au sol ni augmenter les prix et utiliser des dispositifs matériels de compression des données à la volée.

L'autre challenge est de diminuer le temps de réponse d'une E/S. Le débit de plus en plus important des canaux FICON (8 Gbs à ce jour) et l'intégration de plus en plus de disques SSD permettra de répondre à ce challenge.

Le temps de réponse d'une E/S sera largement inférieur à la milliseconde.

À ce jour, la composition des baies de disques pour l'ensemble des constructeurs est :

  • 2 % de disques SSD,
  • 33 % de disques HDD,
  • 65 % de disques SATA.

Si les coûts des disques SSD et SATA vont continuer de baisser, celui des disques HDD restera relativement stable. Ces disques seront replacés par les deux autres dans l'avenir. Je pense que les 15 000 tr/mn qu'ils atteignent aujourd'hui sont une limite supérieure.

Les baies de disques et les unités de cassettes virtuelles ont la même structure :

  • même interface FICON,
  • écriture sur des disques RAID.

La seule différence est la présence d'une taille importante de mémoire, des disques SSD pour les baies de disque que ne possèdent pas les unités de cassettes virtuelles. On peut envisager des baies hybrides supportant les disques et les cassettes virtuelles pour des petites configurations z/OS.

Les unités de cassettes virtuelles « TAPELESS » vont se substituer aux unités avec lecteurs de cassettes (question : a-t-on encore besoin de cassettes dans une production informatique ?).

Enfin, je pense que les grandes entreprises créeront un troisième site qui sera interne ou externe (retour des salles blanches ?) situé à plusieurs dizaines ou centaines de kilomètres des sites principaux.

IV. Remerciements

Cet article a été rédigé par egshuml (Gérard HUMLER) qui souhaite partager son expérience, et la communauté developpez.net l'en remercie.

Metalman (Fabrice BOISSIER) a réalisé la mise en forme du document pour l'adapter au format.

Il ne faut pas oublier f-lebqui a relu et corrigé l'ensemble du document, merci aussi à lui.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2014 Gérard HUMLER (egshuml). Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.