L'utilisation de VLE (Virtual Library Extension) en tant que solution de récupération après sinistre propose une méthode sans interruption et simplifiée de tests DR, ainsi qu'une méthode de récupération après un événement d'interruption d'activité.
Le système gère VLE comme une bibliothèque (ACS). Toutefois, étant donné que la VLE utilise le stockage sur disque plutôt que sur bande et conserve un inventaire interne des VTV qu'elle contient, elle offre davantage de fonctionnalités qu'une vraie bibliothèque :
La VLE est une solution "sans bandes", qui évite les problèmes de gestion de média.
Les données sont envoyées à la VLE via le protocole IP et ne requièrent pas d'extension de canal.
Par rapport au montage et à la lecture d'une cartouche MVC, la VLE peut effectuer un audit MVC en quelques secondes, à l'aide de sa base de données interne.
Ce chapitre décrit l'utilisation de la VLE dans un environnement simple à deux sites. Il convient toutefois de noter que la solution peut prendre en charge autant de sites que vous le souhaitez, qui contiennent chacun autant de VLE que nécessaire. De même, l'un des sites peut être un site DR uniquement, qui n'exécute pas de partitions LPAR MVS, sauf pendant un DR ou un sinistre déclaré.
La procédure ci-après utilise l'environnement suivant : deux sites, SITE1 et SITE2. Chaque site dispose d'un VSM et d'une VLE. Dans cet exemple, SITE2 est décrit en tant que site DR uniquement, mais peut également être un site de production défini en tant qu'image miroir de SITE1.
Remarque :
La taille du tampon VLE sur SITE2 doit être suffisante pour contenir à la fois les données de production migrées et les données créées lors d'un test DR.Lors d'une production normale, des stratégies sont définies sur SITE1 pour migrer une copie des données vers la VLE locale sur le site SITE1 et une deuxième copie vers la VLE distante sur le site SITE2. Vous pouvez créer des copies supplémentaires si vous le souhaitez, en incluant les deux copies dans une autre VLE, ainsi que des copies de bande.
Vous trouverez ci-dessous un exemple des stratégies définies sur SITE1.
Les définitions SMC sont utilisées pour affecter un nom MGMTCLAS de VLEPROD à des jeux de données avec un qualificatif de haut niveau "PAYROLL".
POLICY NAME(VLEPOL) MEDIA(VIRTUAL) MGMT(VLEMGMT) + SUBP(VIRTSCR) TAPEREQ DSN(PAYROLL.*) POLICY(VLEPOL)
Les définitions HSC POOLPARM/VOLPARM sont utilisées pour définir les volumes de production :
POOLPARM TYPE(MVC) NAME(LOCAL) VOLPARM VOLSER(VLL000-VLL099) POOLPARM TYPE(MVC) NAME(VAULT1) VOLPARM VOLSER(VLV000-VLV099) POOLPARM TYPE(SCRATCH) NAME(VIRTSCR) VOLPARM VOLSER(V00000-V99999) MEDIA(VIRTUAL)
Remarque :
Notez que les MVC dans les pools LOCAL et VAULT1 sont des VMVC (cartouches MVC virtuelles) dans les VLE SITE1 et SITE2, respectivement, et ne sont associées à aucun type de média.Les instructions VTCS STORCLAS et MGMTCLAS sont utilisées pour définir les stratégies VTCS :
STOR NAME(VLE1) STORMNGR(SITE1VLE) MVCPOOL(LOCAL) STOR NAME(VLE2) STORMNGR(SITE2VLE) MVCPOOL(VAULT1) MGMT NAME(VLEMGMT) DELSCR(YES) MIGPOL(VLE1,VLE2)
Lorsqu'un travail s'exécute avec un jeu de données débutant par le qualificatif de haut niveau "PAYROLL," SMC utilise TAPEREQ et POLICY pour affecter une instruction MGMTCLAS de VLEPROD à la demande de montage. VTCS sélectionne un volume virtuel provisoire dans le pool LOCSCR (plage V00000-V99999) et lui affecte un MGMTCLAS de VLEPROD. Une fois que le volume est démonté, une copie est migrée vers la VLE locale (STORMNGR SITE1VLE) tandis que la deuxième copie est migrée vers la VLE distante (STORMNGR SITE2VLE).
Le processus de configuration d'un test DR sur SITE2 est simple et rapide. En outre, il requiert des restrictions minimales sur SITE1.
Les principales étapes sont les suivantes :
Créez un nouveau CDS sur SITE2 contenant uniquement les données de configuration de base.
Marquez les VMVC de SITE1 à l'aide de l'attribut READONLY (lecture seule) pour éviter les conflits.
Effectuez un audit des cartouches MVC de production virtuelles dans la VLE SITE2VLE. Cette étape remplit le CDS à l'aide des métadonnées virtuelles existantes. En fonction du nombre de VTV dans la VLE, cette étape peut durer de quelques minutes à moins d'une heure.
Exécutez la charge globale de test DR, en utilisant une plage de VTV et de MVC qui ne chevauche pas les volumes de production.
Le reste de cette section fournit des détails relatifs à la définition des paramètres sur le site DR et décrit les étapes que vous devez exécuter pour vérifier que les VMVC de production de contenu ne sont pas modifiées lors du test.
Créez le CDS du test DR.
Utilisez le processus LIBGEN/SLICREAT pour créer le CDS sur le site SITE2. Notez que vous devez créer ce CDS même si vous exécutez déjà un travail de production sur SITE2. Le nouveau CDS ne contient que des données DR provenant de SITE1. Vous devez également définir au moins un ACS dans les macros LIBGEN, même si votre configuration ne contient pas de bande physique.
Lancez l'utilitaire SET VOLPARM pour définir les volumes pour le test DR :
POOLPARM TYPE(MVC) NAME(VAULT1) VOLPARM VOLSER(VLV000-VLV099) POOLPARM TYPE(EXTERNAL) NAME(PRODVTVS) VOLPARM VOLSER(V00000-V99999) MEDIA(VIRTUAL) POOLPARM TYPE(MVC) NAME(DRMVC) VOLPARM VOLSER(VLT000-VLT099) POOLPARM TYPE(SCRATCH) NAME(VIRTSCR) VOLPARM VOLSER(VT0000-VT9999) MEDIA(VIRTUAL)
Les deux premiers pools définissent les volumes créés par SITE1 qui seront utilisés comme entrée du test sur SITE2. Le type de pool EXTERNAL indique que les volumes ne font pas partie d'un sous-pool provisoire. Les deux derniers pools sont des pools locaux qui seront utilisés comme sortie du test sur SITE2.
Définissez les instructions VTCS MGMTCLAS et STORCLAS qui seront utilisées pour le test DR :
STOR NAME(DRVLE) STORMNGR(SITE2VLE) MVCPOOL(DRMVC) MGMT NAME(VLEMGMT) DELSCR(YES) MIGPOL(DRVLE)
Etant donné que les sous-pools provisoires et MGMTCLAS sur le système DR de SITE2 portent les mêmes noms que les stratégies de production (mais ont des définitions différentes), vous pouvez désormais utiliser les mêmes instructions SMC POLICY et TAPEREQ pour le test DR de votre SITE2 que sur le site de production SITE1.
Affichez HSC/VTCS sur la partition LPAR de test DR.
Marquez les cartouches MVC de production à l'aide de l'attribut READONLY (lecture seule).
Cela constitue une étape essentielle du processus, qui doit être effectuée à la fois sur le CDS de production de SITE1 et sur le CDS de test DR de SITE2. Une fois que les cartouches MVC ont été définies en tant que READONLY sur le CDS de production, vous pouvez continuer à exécuter un traitement normal, incluant :
RECLAIM. La récupération automatique ne sélectionnera pas de cartouche MVC avec le statut READONLY.
SCRATCH. Bien que les VTV soient mis à jour dans le CDS de production pour passer à l'état provisoire et qu'ils puissent être réutilisés, la copie sur la cartouche MVC virtuelle en lecture seule de la VLE ne s'en trouve pas affectée.
Le traitement normal permet d'effectuer un ajout aux VTV ou de les écraser sur les VMVC. Les nouvelles versions VTV seront migrées vers les nouvelles VMVC, tandis que la copie située sur la cartouche MVC virtuelle en lecture seule de la VLE demeurera inchangée.
Remarque :
Toutefois, vous ne pouvez pas exécuter l'utilitaireDRAIN sur ces MVC, car il supprime la copie VLE des métadonnées de la cartouche MVC virtuelle.Utilisez la fonction d'utilitaire ACTMVCGN pour sélectionner les cartouches MVC de production sur le site de production, en utilisant le CDS de production. Cet utilitaire génère des instructions de contrôle pour définir l'indicateur READONLY sur les cartouches MVC qu'il sélectionne, ainsi que des instructions de contrôle pour désactiver l'indicateur READONLY une fois le test terminé. L'utilisation du mot-clé ALL dans l'instruction de contrôle ACTMVCGN garantit que la totalité des cartouches MVC seront sélectionnées pour un traitement en lecture seule (READONLY), permettant ainsi l'exécution d'une récupération automatique sur le système de production sans impact sur le test DR. L'instruction SLUSMAUD DD doit également être incluse pour générer des instructions AUDIT pour les VMVC qui seront utilisées dans le test. Si vous voulez, vous pouvez exécuter l'utilitaire ACTMVCGN sur le site de production pour créer les mises à jour de production et sur une copie en miroir du CDS sur le site DR pour créer les mises à jour du CDS de test DR. Vous trouverez ci-dessous un exemple du JCL permettant d'exécuter cet utilitaire :
//ACTMVCGN JOB (ACCT),'ACTMVCGN',NOTIFY=&SYSUID //ACTMVCG1 EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //* NOTE: CDS DD statements are optional if running at the production //* site with an active HSC LPAR. //SLSCNTL DD DSN=hlq.DBASEPRM,DISP=SHR //SLSCNTL2 DD DSN=hlq.DBASESEC,DISP=SHR //SLSSTBY DD DSN=hlq.DBASESBY,DISP=SHR //* NOTE: MVCMAINT READONLY(ON) STATEMENTS //SLUSMVON DD DSN=hlq.SLUSMVON,DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,1) //* NOTE: MVCMAINT READONLY(OFF) STATEMENTS //SLUSMVOF DD DSN=hlq.SLUSMVOF,DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,1) //* NOTE: AUDIT MVC(VVVVVV) STATEMENTS //SLUSMAUD DD DSN=hlq.SLUSMAUD,DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,1) //* NOTE: THE FOLLOWING SELECTS ALL "NON-EMPTY" VMVCS //SLSIN DD * ACTMVCGN ALL MVCPOOL(VAULT1) /*
Sur le site de production, exécutez la fonction d'utilitaire MVCMAINT pour marquer les VMVC à l'aide de l'indicateur READONLY.
//RDONLYON EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //* NOTE: EXEC MVCMAINT TO SET READONLY(ON). Output of //* ACTMVCGN utility. //SLSIN DD DSN=hlq.SLUSMVON,DISP=SHR
Affichez le HSC/VTCS sur le site DR.
Exécutez un audit MVC des VMVC de production dans la VLE SITE2 à l'aide du CDS SITE2 récemment créé et de la sortie de l'utilitaire ACTMVCGN. Cette étape remplit les métadonnées du CDS contenant les relations entre les VTV et les VMVC.
//AUDIT EXEC PGM=SLUADMIN //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //* NOTE: AUDIT CONTROL STATEMENTS FROM ACTMVCGN UTILITY //SLSIN DD DSN=hlq.SLUSMAUD,DISP=SHR
Vous pouvez éventuellement rappeler dans le tampon VTSS des VTV qui seront utilisés dans le test DR, soit à l'aide de LCM, soit à l'aide d'une autre méthode de sélection des VTV à rappeler. Cette étape n'est cependant pas nécessaire, étant donné que les rappels à partir du tampon VLE sont relativement rapides.
Exécutez l'utilitaire MVCMAINT à l'aide de la sortie de la commande ACTMVCGN READONLY(ON) pour définir les VMVC de production sur READONLY sur le site SITE2 du CDS DR.
//RDONLYON EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //* NOTE: EXEC MVCMAINT TO SET READONLY(ON). Output of //* ACTMVCGN utility. //SLSIN DD DSN=hlq.SLUSMVON,DISP=SHR
Facultatif: avant de démarrer le test DR, vous voudrez peut-être exécuter un VTVRPT et un MVCRPT pour valider le contenu de votre CDS de test DR.
Exécutez votre charge globale de test DR.
Affichez SMC. Si vous avez utilisé les mêmes noms sur vos sous-pools provisoires et MGMTCLAS que sur le système de production, vous pouvez vous servir de vos instructions de production TAPEREQ et POLICY. Il n'est pas obligatoire, mais conseillé, d'utiliser un nom de TapePlex différent pour le TapePlex de test DR.
Exécutez votre charge de travail de test DR à l'aide du SMC et du nouveau CDS de HSC/VTCS.
Il n'existe pas de restrictions quant à la mise à jour des volumes VTV de production lors du test DR. Les données figurant sur les VTV de production peuvent être ajoutées à (DISP=MOD) ou remplacées (DISP=OLD). Ces mises à jour n'affectent pas le contenu de la copie VTV sur la cartouche MVC virtuelle de production READONLY et n'affectent donc pas non plus la copie de production des données.
Une fois le test DR terminé, l'objectif du nettoyage vise à supprimer des métadonnées du VTSS et de la VLE afin que le test DR suivant ne voie pas ces données. Notez que le HSC/VTCS du test DR doit rester actif jusqu'à la fin du nettoyage. Pour ce faire, procédez comme suit :
Exécutez la fonction d'utilitaire SCRATCH pour supprimer tous les VTV créés lors du test, à la fois du VTSS et des VMVC de test DR de la VLE. Lorsque le paramètre DELSCR(YES) est spécifié sur la MGMTCLAS du test DR, l'exécution de l'utilitaire de suppression provoque la suppression des VTV dans le tampon et les métadonnées VLE.
//SCRATCH EXEC PGM=SLUADMIN //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * SCRATCH VOL(VT0000-VT9999)
Si vous avez modifié des VTV de production à l'aide de DISP=MOD ou DISP=OLD, ces VTV restent dans le tampon et sur la VLE.
En supprimant les VTV dans le sous-pool de test DR après le test, vous réduisez le temps requis pour le nettoyage du VTSS ainsi que la quantité de données restantes dans la VLE à la fin du test.
Migrez le VTSS vers 0.
//MIGRTO0 EXEC PGM=SLUADMIN //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * MIGRATE VTSS(DRVTSS) THRESHLD(0)
Cette étape est requise uniquement si la sortie de votre test DR incluait de nouvelles versions des VTV de production.
Vérifiez que le VTSS DR est maintenant vide.
//AUDVTSS EXEC PGM=SLUADMIN //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * AUDIT VTSS(DRVTSS)
Si vous avez modifié des VTV de production lors de votre test DR, les copies de ces données, ainsi que les métadonnées, restent dans la VLE pour le pool MVC de test DR (VLT000-VLT099, VTV V00000-V99999). Lors du test DR suivant, ces VMVC seront écrites en commençant au début logique de la bande et toutes les données qu'ils contiennent seront supprimées de la VLE. Etant donné que le nouveau CDS du test DR ne connaît pas ces données, cela n'aura aucun impact sur le test DR suivant.
Sur le site de production, utilisez les cartes de contrôle READONLY(OFF) créées par l'utilitaire ACTMVCGN au début du test pour que les VMVC de production se trouvent à nouveau dans un statut inscriptible.
//RDONLYOF EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //* NOTE: EXEC MVCMAINT TO SET READONLY(OFF) //SLSIN DD DSN=hlq.SLUSMVOF,DISP=SHR
En cas de panne sur le site SITE1 nécessitant que SITE2 reprenne la charge globale de SITE1, le processus est presque identique à la procédure de test DR.
S'il arrive qu'un test DR soit en cours d'exécution lors de la panne de SITE1, suivez le processus ci-dessus pour effectuer un nettoyage après le test DR et arrêter ce dernier.
Pour commencer à exécuter la charge globale de SITE1 sur SITE2, suivez la procédure décrite ci-dessus pour le démarrage d'un test DR. Certes, vous omettrez l'étape de marquage des VMVC de production à l'aide du paramètre READONLY sur le CDS de production, car il n'existe pas de CDS de "production" à mettre à jour. Toutefois, vous utiliserez la copie en miroir du CDS de production pour générer les cartes de contrôle MVCMAINT READONLY pour les cartouches MVC de production dans la VLE.
Vous voudrez également utiliser les stratégies de test DR qui séparent les VTV créés et les VMVC de sortie en deux plages distinctes, afin d'éliminer toute possibilité d'endommager les données de production tant que la continuité de l'activité n'a pas été vérifiée.
Remarque :
Si aucun point de synchronisation n'est défini pour les travaux de production qui exécutent le traitementDISP=MOD pour les données de bande, il est possible que le contenu d'un VTV au moment d'une panne soit imprévisible. StorageTek recommande de passer en revue toutes les procédures de récupération après sinistre pour garantir des points de synchronisation prévisibles pour les données de bande.