BONNES PRATIQUES RELATIVES À z/OS AVEC LA · PDF fileVMAX se compose des systèmes VMAX ... cible de l’écriture. Les opérations d’allocation du stockage sont effectuées à

Livre blanc

Résumé

Ce livre blanc décrit la fonction EMC® Virtual Provisioning pour les volumes Count Key Data (CKD) dans un environnement d’exploitation z/OS. Il explique différentes bonnes pratiques et certains aspects à prendre en compte lors de l’implémentation du stockage provisionné virtuellement. octobre 2012

BONNES PRATIQUES RELATIVES À z/OS AVEC LA FONCTION VIRTUAL PROVISIONING™

2 Bonnes pratiques relatives à z/OS avec la fonction Virtual Provisioning

Copyright © 2012 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 diffusion de tout logiciel EMC décrit dans cette publication nécessitent une licence logicielle en cours de validité. 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. RÉF. h10688.1


Sommaire

Résumé analytique .................................................................................................. 4 Audience ............................................................................................................................ 4 Terminologie ...................................................................................................................... 4

Virtual Provisioning : présentation de la mise en oeuvre ........................................... 6

Performances .......................................................................................................... 7

Virtual Provisioning : instructions de configuration ................................................... 8

Dimensionnement des ressources pour les périphériques thin ................................. 8 Conditions supplémentaires requises par le cache ............................................................. 9 Conditions relatives à l’organisation du thin pool ............................................................. 10

Ajout de capacité à un thin pool à court d’espace ................................................... 10

Rééquilibrage d’un thin pool .................................................................................. 11

Compression des périphériques thin ...................................................................... 11

Remarques concernant la migration thick-to-thin ................................................... 13

Réplication locale et à distance et Virtual Provisioning ........................................... 14

Virtual Provisioning avec Mainframe Enablers (MFE) ............................................... 14

Exemples d’utilisation de GPM (General Pool Maintenance) .................................... 15 Création et affichage de thin pools ................................................................................... 15 Augmentation de la capacité et rééquilibrage d’un thin pool ............................................ 18 Compression des périphériques thin ................................................................................ 20

Mobilité des périphériques avec Virtual Provisioning .............................................. 27

Surveillance des pools Virtual Provisioning ............................................................ 28

Récupération d’espace dans un thin pool .............................................................. 29 Fonction de récupération SRDF thick R1 ............................................................................ 32

Conclusion ............................................................................................................ 33

Références ............................................................................................................ 33


Résumé analytique Le système VMAX® 40K a récemment rejoint la gamme des baies Symmetrix® VMAX. Il repose sur l’excellente Virtual Matrix Architecture et offre une évolutivité, des performances et un niveau de consolidation exceptionnels pour les environnements de datacenter virtuel les plus exigeants. La gamme Symmetrix VMAX se compose des systèmes VMAX® 40K, VMAX® 20K et VMAX® 10K.

La dernière version de l’Enginuity™ Operating Environment destinée à la gamme Symmetrix, Enginuity 5876, prend en charge les systèmes Symmetrix VMAX 10K, VMAX 20K et VMAX 40K. Les fonctionnalités d’Enginuity 5876 en matière de réseau, de partage et de hiérarchisation des ressources de stockage permettent aux datacenters de consolider les applications et d’offrir une efficacité sans précédent, grâce à des taux d’utilisation supérieurs, une mobilité améliorée, une consommation électrique réduite, un encombrement moindre et une gestion du stockage simplifiée.

Enginuity 5876 propose notamment des améliorations essentielles pour les utilisateurs mainframe des baies Symmetrix VMAX. L’importance de ces innovations est comparable à celle de l’introduction de la première baie de disques avec cache intégré (ICDA) Symmetrix au début des années 1990. Virtual Provisioning™ et Fully Automated Storage Tiering for Virtual Pools (FAST™ VP) ont déjà fait leur preuve dans les environnements de systèmes ouverts (FBA) et sont désormais accessibles aux utilisateurs mainframe de VMAX pour les volumes Count Key Data (CKD).

En offrant un meilleur taux d’utilisation de la capacité et une gestion simplifiée du stockage, EMC® Symmetrix Virtual Provisioning pour les périphériques CKD donne une nouvelle dimension au stockage hiérarchisé dans z/OS. Symmetrix Virtual Provisioning s’intègre avec les outils existants de gestion des périphériques, de réplication et d’administration. Les clients profitent ainsi d’une mise en oeuvre facile de cette fonction dans leurs processus de gestion du stockage z/OS.

Ce livre blanc explique la fonction Virtual Provisioning pour les volumes Count Key Data (CKD) dans un environnement de systèmes d’exploitation z/OS. Il décrit différentes bonnes pratiques et certains aspects à prendre en compte lors de la mise en oeuvre d’une stratégie de stockage provisionné virtuellement.

Audience

Ce document est destiné aux programmeurs système, analystes des performances, responsables de la planification de la capacité, administrateurs de stockage, administrateurs de SAN et ingénieurs informatiques utilisant z/OS, ainsi qu’à toutes les personnes chargées d’implémenter le stockage à provisionnement virtuel sur les baies Symmetrix VMAX dotées d’Enginuity 5876.

Terminologie

La fonction Virtual Provisioning pour z/OS fait appel à de nouveaux termes qui ne sont pas forcément connus des utilisateurs mainframe. Le tableau suivant décrit ces nouveaux termes utilisés à de nombreuses reprises dans le présent document.

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 thin)

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 (TDEV)

Périphérique accessible par l’hôte et non associé directement au stockage.

Périphérique de données (TDAT)

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.

Lier Processus associant un ou plusieurs périphériques thin à un thin pool.

Délier 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.

Périphérique de données activé

Périphérique de données appartenant à un thin pool, sur lequel des extensions peuvent être attribuées aux périphériques thin liés à ce pool.

Périphérique de données désactivé

Périphérique de données appartenant à un thin pool et dont la capacité ne peut pas être attribué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, une opération DRAIN doit être exécutée sur celui-ci afin de déplacer les extensions 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é à une utilisation exclusive par tous les périphériques thin liés à ce thin pool.

Capacité préallouée à l’utilisateur 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é allouée au périphérique thin

Partie de la capacité activée du thin pool allouée à une utilisation exclusive par un périphérique thin.

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.

Tableau 1. Terminologie relative à la fonction Virtual Provisioning


Virtual Provisioning : présentation de la mise en oeuvre 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 table des matières du volume (VTOC) ou d’une table des matières du volume indexée (IXVTOC) et qu’il soit disponible pour toute opération de données, il doit d’abord être associé au thin pool grâce à une opération dite de liaison. 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, la liaison initiale 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.

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.


Figure 1. Virtual Provisioning dans une baie Symmetrix VMAX

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.

La fonction Virtual Provisioning offre les principaux avantages suivants :

1. Les données font l’objet d’une répartition large efficace entre tous les disques du pool, réduisant ou éliminant ainsi les points sensibles et améliorant les performances globales de la baie.

2. Grâce à FAST VP, la baie permet la gestion active des performances à la fois au niveau des sous-volumes et des sous-Datasets.

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 oeuvre 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.

Le principe clé à comprendre, à propos des performances des périphériques thin, est la façon dont ces périphériques sont répartis sur le back-end. Comme indiqué précédemment, les groupes de pistes des périphériques thin sont distribués

Périphériques thin

Périphériques de données


(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 comportant 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).

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 des 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).

Taille du périphérique de données (TDAT) exprimée en nombre de cylindres

Pistes de métadonnées réservées

Minimum Maximum

48 76 800 12

76 801 153 600 24

153 601 230 400 36

230 401 256 000 48

Tableau 2. Pistes de métadonnées réservées en fonction de la taille du périphérique de données

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 comprenant 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 des capacités 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 comportant un thin pool doivent respecter toutes les conditions suivantes :

• 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.

Protection recommandée par type de disque :

Catégorie de disque

Type de protection

Disques Flash

RAID 5 (3+1)

FC/SAS RAID 1

SATA RAID 6 (6+2)

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.

• 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 de conserver la longueur de la file d’attente des disques et pour éviter les recherches excessives.

Ajout de capacité à un thin pool à court d’espace 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. L’ensemble des périphériques de données à ajouter au thin pool existant doit 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 sur le thin pool cible.

• Les périphériques doivent disposer de la même émulation que ceux déjà placés sur le thin pool cible.

• Les périphériques doivent être placés 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 d’un 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 une commande sur le thin pool qui assure 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.

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. FAST VP Small automatise la compression des pools virtuels pour les périphériques thin gérés par 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 utilisateurs ;


• activité 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 l’espace réservé du thin pool lié aux 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.

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 liaison 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 écritures), 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, une tâche d’arrière-plan est associée au périphérique thin et effectue sa compression.

Si un périphérique thin contenant des allocations à plusieurs pools est compressé (possible dans un environnement FAST VP), 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é.


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 suivant présente des exemples de choix de migration accompagnés de remarques utiles.

Copie basée sur l’hôte

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.

TDMF (ZDMF) NON

TDMF = produit de niveau volume ; ZDMF = produit de niveau Dataset ; réalisation de REFVTOC de petit volume vers un grand.

FDRPAS (FDRMOVE) NON

FDRPAS = produit de niveau volume ; FDRMOVE = produit de niveau Dataset ; réalisation de REFVTOC de petit volume vers un grand.

Réplication VMAX basée sur la baie

Perturbation de l’application (l’accès doit être interrompu) Remarques

EMC SRDF/Data Mobility (copie évolutive) OUI

Consultez la matrice de support EMC pour connaître les niveaux de code Enginuity.

Reportez-vous à la section Fonction de récupération SRDF thick R1.

EMC TimeFinder®/Clone (VOLUME DE SNAPSHOT) OUI Reportez-vous aux exemples qui suivent.

EMC TimeFinder/Clone (DATASET DE SNAPSHOT) OUI

Tableau 3. Matrice d’exemples de migration thick-to-thin


Réplication locale 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 locale, 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 mapper vers 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, 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) de cette version est décrit ultérieurement dans la section Récupération d’espace dans un thin pool.

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 des fonctions centrées sur les pools virtuels et des fonctions centrées sur les périphériques thin, comme indiqué ci-après :

• Commandes centrées sur les pools :

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 au thin pool

POOLATTR : indiquer les attributs au niveau du pool

REBALANCE : démarrer l’équilibrage des pistes allouées au sein d’un pool

RENAME : modifier le nom d’un thin pool

• Commandes centrées sur les périphériques :

ADD : ajouter un ou plusieurs périphériques back-end à un thin pool

ALLOCATE : allouer toutes les pistes du 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 les périphériques thin (MFE version 7.5 et Enginuity 5876 version de service Q4-2012)

DECOMPRESS : décompresser les données pour les 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 du pool d’actif à inactif

DRAIN : réattribuer les pistes allouées à d’autres périphériques du pool

ENABLE : faire passer l’état d’un ou de plusieurs périphériques du pool d’inactif à actif

HDRAIN : interrompre la réattribution des pistes des périphériques du 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 du pool précédemment lié au pool actuel

REBIND : modifier le pool auquel le périphérique thin est lié

REMOVE : supprimer un périphérique inactif d’un pool de périphériques

UNBIND : délier un ou plusieurs périphériques thin d’un pool de périphériques thin

USR_NRDY : faire passer l’état de l’unité de contrôle du périphérique à user-not-ready (utilisateur non prêt)

USR_RDY : faire passer l’état de l’unité de contrôle du périphérique à user-ready (utilisateur prêt)

Exemples d’utilisation de GPM (General Pool Maintenance) Vous trouverez ci-après des exemples de configuration, de mise à jour et de surveillance d’un environnement Symmetrix Virtual Provisioning à l’aide des commandes GPM et du dispositif de surveillance du thin pool implémenté dans Symmetrix Control Facility. Les exemples utilisés dans le présent livre blanc 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

Les périphériques thin sont désormais prêts pour l’initialisation ICKDSF (commande ICKDSF INIT) et peuvent être utilisés. Vous trouverez ci-après 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 lancer une recherche de périphériques de données pour connaître les périphériques disponibles (à partir du pool par défaut DF_DDEV_POOL ou .NOPOOL.) à ajouter aux 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



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)


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 du 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 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)


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 au 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. Figure 2 La figure 2 ci-dessous 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.


Figure 2. Thin pool non équilibré

La commande suivante vous permet d’afficher une vue détaillée du thin pool concerné : DISPLAY LCL(UNIT(1000) POOL(ZOS_FC_2M)


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.

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 la plus haute priorité aux opérations d’E/S de l’hôte plutôt 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é. Figure 3 La figure 3 ci-dessous 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 3. Thin pool rééquilibré

La commande suivante vous permet d’afficher une vue détaillée du thin pool concerné : DISPLAY LCL(UNIT(1000) POOL(ZOS_FC_2M)


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 l’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 %.

Une colonne (intitulée 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



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


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


L’affichage du thin pool indique que la compression est activée et que le pourcentage de pistes utilisées s’élève à deux 2 % (au lieu des 31 % précédents). Les commandes suivantes permettent d’afficher le pool et d’interroger les périphériques de données : DISPLAY LCL 3A00

QUERY DATAD LCL UNIT 3A00 POOL MFCKD1 SUM



Clone thick-to-thin TimeFinder avec fonction automatique de liaison/suppression des liaisons TimeFinder/Clone vous permet de créer et de gérer des copies ponctuelles pour les produits de la gamme 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 automatique de liaison et de suppression des liaisons 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 délier 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 liaison/suppression des liaisons de TimeFinder. Reportez-vous au document EMC Mainframe Enablers TimeFinder/Clone Snap Facility Version Product Guide pour en savoir plus sur les opérations de TimeFinder.

La commande suivante vous permet d’interroger les périphériques thin pour rechercher les périphériques disponibles (non liés) à lier aux pools : QUERY THINDEV LCL(UNIT(3800))


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 résultat :

Pour interroger le périphérique thin servant de cible de clonage, exécutez la commande suivante : QUERY THINDEV LCL(UNIT(13C0))DEV(165)


La commande suivante vous permet d’afficher une vue détaillée du thin pool : QUERY THINDEV LCL(UNIT(13C0)) POOL(SATA_R6)

Exemple de réponse à la commande DISPLAY :


Vous pouvez interrompre la session de clonage (commande STOP SNAP) avec suppression des liaisons automatique en utilisant le format de commande suivant : STOP SNAP TO VOLUME ( TARGET(UNIT(3E75)) AUTO_UNBIND_TDEV(YES) )

Exemple de résultat :

Si vous affichez le thin pool après l’exécution de la commande STOP SNAP alors que l’option Auto_unbind est activée, vous remarquerez que l’espace a été automatiquement supprimé. DISPLAY LCL(UNIT(13C0) POOL(SATA_R6)



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 utilisateurs et en exerçant 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. 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 l’option de liaison automatique était employé pour réaliser une copie ponctuelle de volumes d’une base de données vers le thin pool SATA économique. Le pool SATA permet de répondre aux exigences 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ête aléatoire à haute priorité d’échec de lecture, le pool Flash serait un pool de stockage 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 de volume de snapshot TimeFinder/Clone à l’aide de la fonction de liaison 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


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 la requête aléatoire à haute priorité d’échec de lecture peut être effectuée dès la fin de la tâche MOVE/REBIND.

Surveillance des pools Virtual Provisioning Symmetrix Control Facility prend actuellement en charge les dispositifs persistants de surveillance des pools de périphériques SAVE utilisés par TimeFinder/Snap et le pool DSE utilisé par la fonction Delta Set Extension SRDF/A. MFE version 7.4 étend cette fonction de surveillance à la capacité du pool virtuel par le biais 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 des alertes et actions peuvent être définies au niveau global, du contrôleur ou de chaque pool. Voici un exemple de paramètre global du dispositif de surveillance du périphérique 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.

Récupération d’espace dans un thin pool Le deuxième composant majeur de MFE versions 7.4 et par suite, de la prise en charge de Virtual Provisioning est un nouvel environnement Symmetrix Control Facility, l’utilitaire TRU (Thin Reclaim Utility).

Pour les périphériques thin non liés aux attributs PERSIST et PREALLOCATE, TRU permet la récupération de groupes de pistes de périphériques thin qui pourront alors être réutilisés par d’autres périphériques thin du pool virtuel. Pour ce faire, l’utilitaire commence par identifier l’espace disponible dans la VTOC, d’abord par le biais d’une fonction d’analyse, puis au fur et à mesure à l’aide de la sortie z/OS SCRATCH. Il réalise ensuite une opération régulière de récupération qui indique les pistes comme étant vides dans la baie Symmetrix (pas d’enregistrement utilisateur, uniquement R0 standard). La tâche d’arrière-plan Symmetrix de récupération totale de l’espace renvoie finalement ces groupes de pistes vides vers la liste de disponibilité du pool virtuel. Figure 4 représente ce processus sous forme de graphique.


Figure 4. Procédure TRU

Remarque : Les volumes thin liés à l’attribut PERSIST ne peuvent pas faire l’objet d’une récupération.

La récupération d’espace nécessite un volume associé à un canal présentant une adresse d’unité de contrôle (CCUU) disponible. La présence d’une VTOC indexée est recommandé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 :

Remarques et limitations concernant TRU :

• La sortie z/OS Scratch doit être exécutée sur tous les LPAR associés à la baie Symmetrix pour permettre la capture et l’enregistrement de l’activité de remplacement. Si celle-ci ne s’exécute pas sur un LPAR remplaçant des Datasets sur des périphériques thin, l’espace n’est pas récupéré automatiquement par cette implémentation.

• Nous vous recommandons de configurer la tâche RECLAIM de sorte qu’elle s’exécute comme une tâche démarrée pour limiter la durée de réserve (état RESERVED) d’un volume et l’impact global sur le traitement SCF.

• La récupération n’aura pas lieu s’il existe des sessions actives de clonage, de snapshots ou virtuelles sur un périphérique.

L’exemple suivant illustre un périphérique thin (MF3E80) doté de sept Datasets et d’une VTOC indexée :


La commande suivante vous permet d’afficher le thin pool et de connaître le nombre de pistes utilisées et disponibles : DISPLAY LCL(UNIT(1000)) POOL(ZOS_FC_2M)


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 l’analyse à la demande de l’espace disponible des Datasets supprimés de la VTOC, exécutez l’utilitaire afin d’effectuer la tâche SCAN par lot.

Exemple de JCL :

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.

Exemple de JCL :

//SCFTRU JOB EMC,EMC,CLASS=A,MSGCLASS=X //JS10 EXEC PGM=ESFTRURC,PARM=‘SCAN,3E80’//STEPLIB DD DISP=SHR,DSN=EMC.MFE740.LINKLIB//ESFTRURC DD SYSOUT=*//SCF$MF74 DD DUMMY//


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 consulter 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. DISPLAY LCL(UNIT(1000)) POOL(ZOS_FC_2M)


Remarque : lorsque vous utilisez ICKDSF pour effacer un volume thin, la sortie scratch SCF n’est pas invoquée. Elle 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 Activer la prise en charge de l’analyse des R1 thick (OUI par défaut)

Espace récupéré


Vous bénéficierez ainsi de la prise en charge des périphériques R2 en aval, même s’ils sont en cascade d’un périphérique R21. Les périphériques R1 thin et thick seront ainsi pris en charge. Les topologies SRDF multisites, 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 périphériques R1 thick associés à des périphériques 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 R1 local est un périphérique thick, celui-ci ne fait l’objet d’aucune surveillance.

Conclusion Grâce à l’introduction de Virtual Provisioning pour les volumes CKD, Enginuity 5876 marque un tournant important dans la prise en charge de VMAX dans les environnements mainframe. Il est essentiel de définir les processus, applications et charges de travail pour lesquels Virtual Provisioning peut être utilisé efficacement, ainsi que les avantages spécifiques à obtenir. Lorsqu’elle est correctement implémentée, la fonction Virtual Provisioning peut permettre de compléter judicieusement les processus et technologies des entreprises, de simplifier le provisionnement, d’améliorer les performances et d’utiliser plus efficacement les capacités de stockage. Symmetrix Virtual Provisioning s’intègre de manière fluide dans les environnements de systèmes d’exploitation z/OS ainsi que dans les technologies de gestion et de continuité d’activité existantes. Cette fonction représente une avancée significative pour les clients possédant des baies Symmetrix VMAX.

Références New Features in EMC Enginuity 5876 for Mainframe Environments

Mise en oeuvre de FAST VP pour les baies de la gamme EMC Symmetrix VMAX

DB2 for z/OS Best Practices with Virtual Provisioning

EMC Mainframe Enablers ResourcePak Base for z/OS Version 7.5 Product Guide

EMC Mainframe Enablers TimeFinder/Clone Snap Facility Version 7.5 Product Guide

Documents

BONNES PRATIQUES RELATIVES À z/OS AVEC LA · PDF fileVMAX se compose des systèmes VMAX ... cible de l’écriture. Les opérations d’allocation du stockage sont effectuées à