7 Utilisation du logiciel Concurrent Disaster Recovery Test (CDRT)

Les clients qui utilisent ou gèrent un site de récupération après sinistre (DR) dans le cadre d'un plan de continuité de l'activité voudront peut-être valider périodiquement leur capacité à poursuivre un traitement de production normal avant qu'un réel sinistre ne se produise ; d'autres n'ont pas le choix et doivent prouver régulièrement la préparation de leur modèle de continuité de l'activité pour répondre aux exigences de leur assurance et/ou de leurs auditeurs.

Grâce à la fonction Concurrent Disaster Recovery Test (CDRT), qui est désormais intégrée au logiciel StorageTek ELS, les entreprises qui utilisent actuellement des bandothèques StorageTek Streamline et/ou Nearline (matériel réel), VSM (matériel virtuel) et les logiciels associés (HSC, VTCS) peuvent valider leur fonctionnalité de continuité de l'activité sur bande réelle et virtuelle sans avoir besoin d'acquérir du matériel et des logiciels supplémentaires.

CDRT prend en charge un test parallèle des applications et hôtes de production avec un accès simultané aux données de production à la fois par les systèmes de production et de test DR.

Les principaux concepts de CDRT sont les suivants :

  • Grâce à CDRT, un test DR peut s'exécuter avec du matériel réel et/ou virtuel.

  • CDRT, HSC et VTCS appliquent par programmation certaines restrictions fonctionnelles lors de la préparation du CDS et du test DR réel pour tenter de garantir l'intégrité du système.

  • CDRT sépare logiquement une partie du matériel virtuel et réel de production existant et les pools de volume de bande pendant la durée du test DR. Cela vous permet de tester votre configuration DR tout en exécutant simultanément un travail de production, de garantir l'intégrité des données de production et de réduire les conflits pour les ressources matérielles et les volumes de bande.

  • CDRT crée une copie de test du CDS de production. Le sous-système ELS de production et les sous-systèmes ELS de test DR ne communiquent donc pas entre eux. Les changements qui ont lieu dans le CDS de test DR ne sont pas représentés dans la copie du CDS de production et inversement. Les hôtes de test DR utilisent uniquement le matériel séparé logiquement. Les hôtes de production continuent à utiliser tous les matériels à une exception près : les hôtes de récupération après sinistre disposent d'une utilisation exclusive des VTSS séparés logiquement lors du test DR. D'autres ressources, comme les RTD, les cartouches MVC (Multiple Virtual Cartridge) et les bandes provisoires réelles, doivent être contrôlées en définissant des pools distincts sur chaque jeu d'hôtes.

  • Un test DR peut être exécuté à l'aide de ressources locales uniquement ou d'une combinaison de ressources locales et distantes ; les configurations composées d'un site distant contenant uniquement du matériel réel et virtuel, ou de matériel réel et virtuel avec un processeur mainframe sont également prises en charge.

  • Le matériel de test DR peut inclure toute combinaison d'ACS, VTSS et VLE.

  • Après un test DR, la copie de test du CDS et toutes les données créées depuis le test DR sont généralement effacées et le matériel séparé logiquement est redéployé vers l'environnement de production normal.

    Remarque :

    • Pour répondre aux exigences de récupération après un sinistre réel, il est essentiel que les travaux figurant dans un flux de travaux de test DR ne mettent pas à jour les volumes créés en production, que ce soit via DISP=MOD ou en les écrasant. Si un véritable sinistre se produisait, de telles pratiques rendraient l'état de ces volumes imprévisible.

    • Pour l'exécution du test DR, il est fortement recommandé que les volumes de production qui auraient pu être modifiés pendant le test DR soient copiés sur de nouveaux volumes au début du test et que les volumes copiés soient mis à jour par le test DR, non les volumes d'origine. De même, le JCL doit être modifié si possible, afin que le statut de tous les volumes de bande au moment du sinistre soit connu.

Considérations relatives aux métadonnées

Pour que l'exécution d'un test DR à l'aide de la fonction CDRT aboutisse, il est fondamental de disposer d'une copie cohérente de l'état de tous les volumes de bande gérés par le logiciel ELS, ainsi que du matériel réel et virtuel. C'est la cohérence de l'état des volumes de bande entre les hôtes de production et les hôtes de récupération après sinistre au démarrage du test DR qui permet le traitement parallèle des applications client. Etant donné que le CDS reflète l'état de tous les volumes de bande et ressources dans le matériel réel et virtuel, CDRT répond partiellement à cette exigence de cohérence lorsqu'il réalise sa copie de test du CDS.

Toutefois, dans un environnement de volume de bande, il arrive souvent que des données d'état (métadonnées) de ce volume de bande soient conservées et gérées en dehors du sous-système ELS ainsi que du matériel réel et virtuel. Généralement, les métadonnées de volume de bande (à savoir VOLSER, DSN, date d'expiration, état de travail, désignation réelle ou virtuelle, etc.) sont stockées dans un ou plusieurs catalogues de gestion de bandes (TMC), un ou plusieurs catalogues z/OS et le jeu CDS.

Vous devez coordonner la création de copies des métadonnées conservées et gérées en dehors de ELS (et du matériel réel et virtuel) avec la création de la copie de test du CDS par CDRT.

Origine des données VTV du CDRT

CDRT obtient ses données VTV d'une ou plusieurs des ressources de site DR suivantes :

  • Cartouche MVC

  • VLE

  • VTSS

Le CDS de production étant la source d'informations relatives aux VTV accessibles par le test DR, il est important de s'assurer que le cycle de synchronisation de volumes provisoires permet aux volumes utilisés dans le test DR de ne pas être mis à l'état provisoire avant le début du test. StorageTek recommande également de basculer votre VTSS de test hors ligne avant de lancer l'opération DRTEST CREATE.

Notez que l'exécution d'une suppression lors du test n'affecte pas le contenu du VTSS du test DR, ni des cartouches MVC, s'ils sont définis sur READONLY à l'aide de l'utilitaire ACTMVCGN.

La copie du CDS du site de récupération après sinistre indique l'emplacement des VTV au moment de la copie, généralement sur des cartouches MVC ou des VLE. Toutefois, vous pouvez parfois choisir d'utiliser des copies VTV dans un VTSS qui se trouve sur le site de test. En général, vous procédez comme cela dans les situations suivantes :

  • Vous définissez votre VTSS de récupération après sinistre à l'aide du mot-clé SHARE, qui empêche la mise à jour du contenu d'un VTV de production.

  • Vous disposez de deux VTSS en cluster (l'un sur le site de production et l'autre sur le site DR) et votre test DR ne modifie pas le contenu d'un VTV de production.

  • Vous disposez de deux VTSS en cluster (l'un sur le site de production et l'autre sur le site DR) et vous voulez passer du temps après le test DR à identifier et migrer manuellement les VTV mis à jour par le test DR.

    Remarque :

    Vous pouvez vous servir de l'utilitaire DRMONitr pour vous assurer que les données critiques de récupération après sinistre atteignent l'emplacement de récupération désigné avant d'exécuter un test DR.

Opérations exécutées sur les données à la fin du test

Les données qui sont créées par le test DR sont uniquement représentées dans le CDS du test DR (qui est effacé après le test) et sur les cartouches MVC de test DR, qui se trouvent dans une plage de volumes distincte des MVC de production. En outre, les VTV créés par le test DR restent sur le VTSS de test DR après le test, sauf si vous effectuez l'une des opérations suivantes :

  1. Servez-vous de l'utilitaire SLUADMIN SCRATCH dans l'environnement de test DR pour supprimer (à l'aide de MGMTCLAS DELSCR(YES)) tous les VTV dans la plage du sous-pool de test DR. Cette option requiert l'utilisation de la fonction POOLPARM/VOLPARM.

  2. Vérifiez que tous les VTV de production qui ont été modifiés par le test DR sont migrés vers les MVC de test DR à l'aide de la commande MIGRATE avec DELETE(YES) à partir du système de test DR. Si vous n'effectuez pas cette opération, le système de production utilise les données qui ont été modifiées par le test DR.

  3. Demandez à votre CSE StorageTek ou à un autre QSP de "nettoyer" le VTSS de test DR après le test pour supprimer toutes les données du VTSS.

    Remarque :

    Si vous utilisez l'option 2 ou 3, le contenu du VTSS ne correspondra pas au système de production, car les VTV manquent sur le CDS de test DR lorsqu'il est remis en production. Bien que cette condition soit traitée par le logiciel, les performances de production risquent de s'en trouver diminuées.

Gestion des ressources CDRT

Les sections suivantes expliquent comment gérer les ressources CDRT.

Ressources de volume

La première étape de gestion des ressources CDRT consiste à définir les volumes dans votre système à l'aide de l'utilitaire POOLPARM/VOLPARM. Cette fonctionnalité simplifie la gestion globale des volumes et pools de bande. Elle fournit également une méthode de séparation des volumes inscriptibles dans une configuration CDRT. L'utilisation de POOLPARM/VOLPARM est requise lorsque les VTSS de test DR sont partagés et est fortement recommandée dans les autres scénarios.

Remarque :

L'utilitaire SLUADMIN SET VOLPARM doit s'exécuter à l'aide du CDS de production et définir à la fois les pools de test DR et de production. L'utilitaire SET VOLPARM n'est pas valide pour un CDS de test DR.

Sous-pools provisoires

Les sous-pools provisoires peuvent s'appliquer à tous les scénarios de test DR. La syntaxe suivante montre l'utilisation des définitions POOLPARM/VOLPARM pour configurer les sous-pools provisoires de test DR et de production. Si vous utilisez les mêmes noms pour les sous-pools de production et de test DR (avec des plages de volume différentes), vous n'avez pas besoin de modifier vos stratégies de production lors de l'exécution du test DR, comme indiqué dans l'exemple suivant.

*   SCRATCH POOLS
POOLPARM NAME(SCRP1) TYPE(SCRATCH)
VOLPARM VOLSER(T11000-T11999) MEDIA(T10000T1) RECTECH(T1AE)
POOLPARM NAME(SCRP1) TYPE(SCRATCH) DRTEST
VOLPARM VOLSER(T12000-T12999) MEDIA(T10000T1) RECTECH(T1AE)
POOLPARM NAME(SCRVTV1) TYPE(SCRATCH)
VOLPARM VOLSER(V1000-V1999) MEDIA(VIRTUAL)
POOLPARM NAME(SCRVTV1) TYPE(SCRATCH) DRTEST
VOLPARM VOLSER(V2000-V2999) MEDIA(VIRTUAL)

Lorsque vous définissez des sous-pools provisoires à l'aide de l'utilitaire POOLPARM/VOLPARM, vous pouvez vous servir de l'utilitaire HSC SLUADMIN SCRATCH pour supprimer des volumes de sortie de test DR dans l'environnement de test DR. Combinée à une classe de gestion spécifiant DELSCR(YES), l'exécution de l'utilitaire de suppression supprime du VTSS les VTV créés par le test DR.

Ressources MVC

Les ressources MVC sont utilisées dans tous les scénarios de test DR, à l'exception des VSM sans bandes et à bandes réelles uniquement. L'exemple suivant montre l'utilisation des définitions POOLPARM/VOLPARM pour configurer les pools MVC de test DR et de production.

*   MVC POOLS
POOLPARM NAME(MVCP1) TYPE(MVC) MVCFREE(40) MAXMVC(4) THRESH(60) +
START(70)
VOLPARM VOLSER(T14000-T14999) MEDIA(T10000T1) RECTECH(T1AE)
POOLPARM NAME(MVCP1) TYPE(MVC) MVCFREE(40) MAXMVC(4) THRESH(60) +
START(70) DRTEST
VOLPARM VOLSER(T13000-T13999) MEDIA(T10000T1) RECTECH(T1AE)

Conservez le contenu des MVC de production en vue de l'utiliser dans un scénario de test DR en suivant la procédure ci-dessous.

  • Servez-vous de l'utilitaire ACTMVCGN pour définir les MVC qui seront utilisées comme entrée du test DR sur READONLY, comme indiqué dans l'exemple suivant.

    //ACTMVCG1 EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//* 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: THE FOLLOWING STEP SELECTS ALL "ACTIVE" MVCS
//* IN ACS 01.
//SLSIN DD *
ACTMVCGN ACS(01)
/*
//ACTMVCG2 EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//* NOTE: EXEC MVCMAINT TO SET READONLY(ON)

  • Vérifiez que la récupération ne s'exécute pas sur tous les hôtes de production à l'aide de VTCS CONFIG :

    CONFIG HOST NAME(host) NORECLAM

Ressources VTSS

Il existe deux types de ressources VTSS : non partagées et partagées.

Ressources VTSS non partagées

Dans un environnement où les VTV sont migrés vers des MVC ou des VLE, les ressources VTSS sont séparées lors d'un test DR. Le système de test DR n'a accès qu'aux VTSS qui sont définis via les utilitaires DRTEST PRIMEPRD/CREATE et qui doivent rester hors ligne en production. La commande DRTEST START est rejetée si un VTSS de récupération après sinistre est en ligne dans l'environnement de production.

Dans certains cas, deux VTSS peuvent porter le même nom dans les environnements de production et de test. Le paramètre SPARE de l'utilitaire DRTEST PRIMEPRD/CREATE indique alors que le VTSS de test DR porte le même nom qu'un VTSS de production, mais n'est pas physiquement le même périphérique, permettant ainsi au périphérique de production de rester en ligne lors du test. N'utilisez pas le paramètre SPARE dans les autres cas.

VTSS en cluster dans CDRT

Le Scénario 4 : VTSS en cluster avec sites de production et de test DR utilise des VTSS en cluster pour fournir des données au VTSS sur le site DR. Dans ce scénario, le cluster ne fonctionne pas lors du test DR, car le VTSS de test DR est hors ligne en production.

Si les VTV de production sont modifiés de quelque façon que ce soit lors du test DR, vous devez vérifier que les VTV modifiés sont supprimés du VTSS avant de rebasculer en ligne le VTSS de test en production. Sinon, les VTV modifiés peuvent être sélectionnés par le site de production. Pour empêcher cela, StorageTek recommande vivement de concevoir le test DR de sorte que les VTV de production ne soient pas modifiés par le test.

Dans un scénario de VTSS en cluster, il se peut qu'aucun VTD du VTSS de test ne soit accessible par l'hôte de production. Pour autoriser une communication ECAM entre la production et le VTSS de test DR, spécifiez l'instruction suivante dans VTCS CONFIG :

VTD LOW=xxxx HIGH=xxxx NOVERIFY
Préparation d'un cluster VTSS en vue d'un test de récupération après sinistre

  1. Basculez le VTSS de test DR à l'état Mis au ralenti. Par exemple :

    VARY VTSS1 QUIESCED

    Ici, l'objectif vise à arrêter (progressivement) la réplication sur VTSS1 afin que vous puissiez l'utiliser exclusivement pour le test DR.

  2. Surveillez la réplication jusqu'à ce qu'elle se termine à l'aide de Display REPLicat. Ici, la réplication est encore active :

    VTSS   HOST  QDEPTHVTSS0  PRODUCTION    1

    Vous savez que la réplication est terminée lorsque le message suivant s'affiche :

    VTSS   HOST  QDEPTH
VTSS0  PRODUCTION  0

  3. Vérifiez que la réplication est terminée en consultant le statut du CLINK à l'aide de Display CLINK. Ici, le CLINK est encore actif :

    VTSS  CLINK  STATUS USAGE        HOST
VTSS0   7    ONLINE REPLICATING  PRODUCTION
VTSS0   8    ONLINE REPLICATING  PRODUCTION
You know the CLINK is no longer active when you see this:
VTSS  CLINK  STATUS USAGE        HOST
VTSS0   7    ONLINE FREE
VTSS0   7    ONLINE FREE

  4. Basculez hors ligne le VTSS de test DR :

    VARY VTSS1 OFFLINE
Gestion du contenu VTSS avant et après le test DR

Avant de démarrer un test DR, vous devez :

  1. planifier votre test afin que la sortie du test ne passe pas en production par erreur ;

  2. préparer votre test afin que votre CDS de test DR corresponde au contenu de récupération après sinistre.

En outre, StorageTek recommande vivement que tous les VTSS du site de test soient nettoyés dès que possible après le test. Cela permet de s'assurer que les VTSS du site de test sont vides au début du test suivant et qu'aucune donnée de test DR ne reste sur les VTSS qui sont renvoyés en production.

Vous pouvez nettoyer les VTSS de test en effectuant l'une des opérations suivantes :

  1. N'autorisez pas le test DR à effectuer des mises à jour (remplacement ou ajout) sur les VTV de production et utilisez POOLPARM/VOLPARM pour définir des sous-pools provisoires de test DR. Cette méthode permet d'exécuter l'utilitaire de suppression pour supprimer tous les VTV figurant dans la plage de test DR. Ils sont automatiquement supprimés du VTSS (si la classe de gestion indique DELSCR(YES)).

  2. Si votre test DR peut mettre à jour les VTV de production, vous devez vérifier que les VTSS utilisés pour la sortie de test DR sont vidés avant de remettre le VTSS en production. Cette opération peut être effectuée via une migration vers zéro dans l'environnement de test DR, ou en demandant au CSE StorageTek ou à un autre QSP de "nettoyer" le VTSS.

Lorsque vous exécutez l'utilitaire DRTEST CREATE pour créer le CDS de test DR, les métadonnées relatives au contenu du VTSS sont propagées vers l'environnement de test. L'environnement de test DR peut accéder aux VTV situés sur le VTSS de test DR.

Si le VTSS de test DR est défini en tant que VTSS de rechange, le contenu du VTSS physique de récupération après sinistre ne correspondra pas aux métadonnées du CDS, qui font référence à l'instance de production du VTSS de rechange. Pour supprimer la divergence, avant de créer le CDS de test DR, migrez l'instance de production du VTSS de rechange vers 0 dans l'environnement de production. Vous pouvez exécuter VTCS VTVRPT OPTION(UNAVAIL) pour vérifier que tous les VTV sont migrés et accessibles par les autres VTSS. Si vous n'effectuez pas cette étape, les tentatives d'accès aux VTV sur le VTSS de rechange par le test DR provoqueront l'affichage de messages SLS6680E pour les montages VTV.

Ressources VTSS partagées

Si l'environnement de bande n'inclut pas de MVC de bande réelle ou VLE, vous pouvez exécuter CDRT dans un environnement VTSS partagé. Le paramètre DRTEST PRIMEPRD/CREATE SHARE indique qu'un VTSS est partagé entre la production et le test DR lors du test. Cet environnement applique les restrictions suivantes :

  1. DRTEST CREATE ne peut pas non plus définir de ressources DRACS ou STORMNGR. Par conséquent, aucune donnée ne peut être migrée à partir du VTSS partagé vers le média externe.

  2. Le système de production doit définir les ressources de volume à l'aide de la fonction POOLPARM/VOLPARM.

  3. Les montages d'un VTV de sous-pool non DRTEST dans l'environnement de test DR impliquent obligatoirement que le VTV soit en lecture seule. Le test DR n'est donc pas autorisé à effectuer un ajout à un VTV de production, ni à le remplacer.

Ressources ACS

Les ressources ACS sont utilisées dans les scénarios de test DR avec des bandes réelles uniquement ou avec des bandes virtuelles sans VLE dans un environnement VSM avec bandes. Les ressources ACS pour CDRT sont spécifiées dans le paramètre DRTEST PRIMEPRD/CREATE DRACS.

Restrictions relatives aux ressources ACS pour le test de récupération après sinistre

Vous devez émettre la commande HSC CAPPREF pour définir les ports d'accès aux cartouches (CAP) sur Manuel, avant de lancer l'utilitaire DRTEST CREATE. Le logiciel garantit qu'ils resteront dans cet état tant que le test sera en cours. Une fois que vous avez entré la commande DRTEST START, des restrictions s'appliquent à l'ACS de test de récupération après sinistre à la fois en production et dans l'environnement de test DR, pour assurer la cohérence entre le matériel et les CDS respectifs afin de permettre aux deux sites d'accéder aux données. La commande DRTEST START est rejetée si un CAP dans un ACS de test DR est en mode automatique dans l'environnement de production.

Les restrictions ci-dessous sont automatiquement appliquées par le logiciel.

Conditions requises pour l'hôte de production DR

Les conditions requises pour l'hôte de production DR lors d'un test DR actif pour l'ACS de récupération après sinistre sont les suivantes :

  • Les CAP doivent rester en mode manuel.

  • FLOAT(OFF) et EJCTAUTO(OFF) sont automatiquement appliqués, quels que soient les paramètres de la commande MNTD.

  • Vous ne pouvez pas exécuter d'utilitaires de rejet, de déplacement, d'audit et de suppression pour l'ACS de test DR.

Conditions requises pour l'hôte de test DR

Les conditions requises pour l'hôte de test DR lors d'un test de récupération après sinistre sont les suivantes :

  • Les ACS qui ne sont pas des ACS de test DR ne peuvent pas être basculés en ligne.

  • Les CAP doivent rester en mode manuel.

  • FLOAT(OFF) et EJCTAUTO(OFF) sont automatiquement appliqués et les autres valeurs ne sont pas valides dans la commande MNTD.

  • Vous ne pouvez pas exécuter d'utilitaires de rejet, de déplacement, d'audit et de suppression pour l'ACS de test DR.

  • Les mises à jour de volumes provisoires sont autorisées uniquement pour les volumes définis à l'aide de POOLPARM/VOLPARM en tant que volumes de sous-pool provisoire de test DR.

Ressources VLE

Définissez des ressources VLE à l'aide du paramètre STORMNGR des commandes DRTEST PRIMEPRD et CREATE. En général, les ressources de test DR sont des ACS ou des VLE, bien qu'il n'existe aucune restriction concernant l'utilisation de ces deux types de ressources.

Comme les MVC physiques, les VMVC VLE sont définies à l'aide de la fonctionnalité POOLPARM/VOLPARM, avec une plage de VMVC réservée au test DR. Le test DR dispose également d'un accès en lecture aux VMVC de production, comme indiqué dans l'exemple suivant.

//ACTMVCG1 EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//* 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: THE FOLLOWING STEP SELECTS ALL "ACTIVE" MVCS
//* IN VLE1 AND MVCPOOL MVCP1.
//SLSIN DD *
ACTMVCGN STORMNGR=VLE1,MVCP=MVCP1
/*
//ACTMVCG2 EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//* NOTE: EXEC MVCMAINT TO SET READONLY(ON)
//SLSIN DD DSN=hlq.SLUSMVON,DISP=SHR

Stratégies VTCS

Pour réduire les différences entre vos environnements de production et de test DR, CDRT vous permet de définir des stratégies de gestion pour les VTV qui portent le même nom dans les environnements de production et de test DR, mais qui possèdent des définitions de stratégie différentes.

Notez que les sites de production et de test peuvent partager un VTSS à l'aide du paramètre DRTEST DRVTSS SHARE. Notez également que l'indication d'un ACS de récupération après sinistre factice n'est plus requise pour un VTSS partagé ou un test DR utilisant une VLE. La spécification d'un VTSS partagé est soumise aux restrictions suivantes :

  • Le VTSS de test DR partagé ne doit pas contenir des connexions RTD actives à partir du site de production ou de test DR.

  • Le CDS doit contenir des définitions VOLPARM pour configurer les sous-pools provisoires de test DR.

  • Les VTV de production (ceux qui ne se trouvent pas dans un sous-pool de test DR) sont définis en lecture seule lors de leur montage et ne peuvent pas être modifiés.

Définition de MGMTCLAS/STORCLAS pour des VTSS non partagés

Lorsque vous définissez des classes de gestion pour un système de test DR, vous ne définissez en général qu'une seule copie MVC des VTV de sortie. Pour permettre un nettoyage VTSS après le test, il est conseillé de spécifier DELSCR(YES) comme indiqué dans l'exemple suivant.

STOR NAME(LOCAL) ACS(01) MVCPOOL(MVCP1)
MGMT NAME(CRITICAL) MIGPOL(LOCAL) IMMWAIT(0) DELSCR(YES)

Définition de MGMTCLAS pour des VTSS partagés

Lorsque vous utilisez un VTSS partagé pour le test DR, aucune copie de sortie migrée n'est autorisée. Vous devez spécifier DELSCR(YES) pour autoriser le nettoyage après le test, comme indiqué dans l'exemple suivant.

MGMT NAME(CRITICAL) DELSCR(YES)

Optimisation de l'accès aux ressources de test et de production

Lors d'un test de récupération après sinistre, il est recommandé d'appliquer des procédures permettant d'optimiser l'accès aux ressources dans les environnements de test et de production. Plus précisément :

  • Avant de démarrer le test DR, définissez des classes de gestion de production qui spécifient une migration immédiate vers les ACS de production et de test DR, afin que les VTV soient disponibles sur des MVC accessibles par le système de test DR et le système de production.

  • Définissez des classes de gestion de test DR qui spécifient une copie de migration unique, étant donné que le site de test DR ne peut généralement accéder qu'à un seul ACS.

  • Utilisez la fonctionnalité POOLPARM/VOLPARM pour séparer les sous-pools provisoires et les pools MVC entre la production et le test DR.

  • Si possible, vérifiez que le traitement de votre test DR ne met pas à jour des VTV préexistants (DISP=MOD ou ne les remplace pas à l'aide de DISP=OLD).

  • Pour réduire le conflit entre les travaux de production qui effectuent une migration vers l'ACS de test DR et les travaux de test DR qui accèdent aux VTV sur des MVC dans l'ACS de test DR, lancez l'utilitaire ACTMVCGN pour marquer les MVC actives en tant que MVC en lecture seule dans l'environnement de production.

  • Désactivez la récupération d'espace MVC (à l'aide de CONFIG HOST NORECLAM) sur les MVC de production lors d'un test DR, afin de préserver le contenu MVC des volumes utilisés par le système de test DR.

Exécution d'un test DR

Remarque :

Pour plus d'informations sur les commandes et utilitaires employés dans cette procédure, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS.

Pour exécuter un test DR :

  1. Définissez des pools de volume dans le CDS de production à l'aide de la commande SET VOLPARM et des instructions POOLPARM/VOLPARM figurant dans SLSPARM DD.

    Pour plus d'informations, voir "Ressources de volume."

  2. Vérifiez que vos ressources de test sont définies correctement.

    Pour plus d'informations, reportez-vous aux sections suivantes :

  3. Créez des instructions MGMTCLAS/STORCLAS pour l'environnement DRTEST.

    Pour plus d'informations, reportez-vous aux sections suivantes :

  4. Copiez le catalogue MVS pour le site de test DR, le cas échéant.

  5. Vous pouvez éventuellement copier la base de données TMS (si un système TMS est utilisé) pour le site de test DR.

  6. Sur le site de production, exécutez l'utilitaire DRTEST (avec le mot-clé PRIMEprd) pour préparer le CDS de production pour le test DR.

    Par exemple, consultez la section "Exemple de JCL pour le scénario 1."

    Il vous suffit d'exécuter PRIMEprd une fois dans votre environnement, quel que soit le nombre d'itérations de DRTES, sauf en cas de modification de votre configuration. Si votre configuration de test DR change, vous devez réexécuter PRIMEprd. De même, vous n'avez pas besoin d'exécuter l'utilitaire DRTEST RESET une fois que le test DR est terminé. Bien que les indicateurs restent définis dans le CDS de production, ils n'ont aucune incidence sur le traitement tant que le test DR n'est pas actif.

  7. Sur le système de production, utilisez la commande HSC CAPPREF pour définir tous les CAP situés dans l'ACS de test DR sur le mode manuel.

  8. Sur le site de test DR, exécutez l'utilitaire DRTEST (avec le mot-clé CREATE) sur la copie mise en miroir ou la copie de sauvegarde du CDS de production, afin de créer le nouveau CDS pour le test DR.

    Chaque scénario fournit un exemple de DRTEST CREATE.

    Les CDS doivent être alloués à l'aide des instructions DD sur l'utilitaire. Lorsque NOUPD est utilisé, seule l'instruction SLSCNTL DD est requise. Il peut s'agir du CDS principal réel, d'une sauvegarde ou d'une copie mise en miroir.

  9. Démarrez le test DR sur le site de production, en pointant vers les définitions DRTEST MGMTCLAS/STORCLAS que vous avez créées à l'étape 3.

    Par exemple :

    /PRIME EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSIN DD *
DRTEST START

    Remarque :

    Vous pouvez également démarrer le test en entrant une commande DRTEST START à partir de la console.

  10. Démarrez le système SMC sur le ou les hôtes client DRTEST.

  11. Démarrez le ou les systèmes SMC/HSC/VTCS (en pointant vers le CDS que vous avez créé à l'étape 8) sur les systèmes de test DR.

  12. Vérifiez que les VTD des chemins et VTSS de test sont en ligne.

  13. Basculez les VTSS de récupération après sinistre en ligne sur le système DR.

  14. Basculez les RTD de récupération après sinistre en ligne sur le système DR, le cas échéant.

  15. Exécutez les tests sur le site de test DR.

    Lors du test DR, les conditions suivantes sont appliquées par programmation :

    • Le ou les ACS du site de production sont déconnectés du ou des hôtes de test DR.

    • Les VTSS du site de production sont hors ligne sur le ou les hôtes de test DR.

    • Aucune opération flottante de démontage, d'éjection, de déplacement , de mise à jour des volumes provisoires, d'audit ou de redistribution des volumes provisoires ne peut être effectuée sur le site de test DR.

    • Aucune opération flottante de démontage, d'entrée/éjection, de déplacement, d'audit ou de redistribution des volumes provisoires sur l'ACS de test DR ne peut être effectuée sur le site de production.

    • Tous les CAP de l'ACS de test DR sont en mode manuel.

      Remarque :

      Vous pouvez entrer des volumes dans l'ACS de test DR, mais une fois que le test est terminé, vous devez les éjecter ou auditer les cellules pour synchroniser le CDS de production avec les volumes de bibliothèque réels.

Nettoyage après un test DR

Comme décrit au début de ce chapitre, il est essentiel que les travaux figurant dans un flux de travaux de test DR ne mettent pas à jour les volumes créés en production.

Remarque :

Pour obtenir des informations sur la commande DRTEST et l'utilitaire DRTEST, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS. Pour obtenir des informations sur les messages CDRT, voir Messages et codes ELS.

Nettoyage après un test DR

Remarque :

Pour ELS 7.1 et versions ultérieures, si le module CDRT Cleanup Enhancement SPE est installé, vous n'avez pas besoin d'exécuter cette procédure immédiatement après le test DR et avant la reprise de l'environnement de production normal. A la place, vous pouvez l'exécuter sans interruption (par exemple, avant le test DR suivant).

  1. Exécutez l'utilitaire SLUADMIN SCRAtch pour supprimer tous les VTV possibles dans vos sous-pools DRTEST.

    Etant donné que vous définissez DELSCR(YES) dans votre classe de gestion, les VTV sont automatiquement supprimés du tampon lorsque vous les supprimez à la fin du test.

    AVERTISSEMENT :

    Si vous n'utilisez pas SET VOLPARM et que vous ne configurez pas de pools provisoires distincts, vous risquez de perdre des données.

  2. Si votre test DR a modifié des VTV de production, vous devez également effectuer l'opération suivante pour vous assurer qu'aucune donnée de test DR ne demeure sur le VTSS de production :

    • Exécutez un rapport VTV sur le CDS DRTEST et examinez la sortie pour déterminer si des VTV figurant dans les plages de VTV de production ont été modifiés lors du test.

      Notez que VTVRPT COPIES signale désormais les copies VTV qui sont des copies de test DR, à l'aide de l'indicateur "D" dans la colonne DRT.

    • Si des VTV ont été modifiés, vous devez effectuer l'une des opérations suivantes :

      • Demandez à migrer les VTV modifiés en vous basant sur le rapport VTV.

      • Migrez le VTSS de test DR vers 0.

      • Demandez au CSE de "nettoyer" le VTSS de test.

  3. Arrêtez HSC/VTCS et SMC sur le système MVS de test DR.

  4. Si l'utilitaire ACTMVCGN a été exécuté avant le test pour faire passer les MVC à l'état READONLY (lecture seule), exécutez SLUADMIN en utilisant la sortie de l'instruction SLUSMVOF DD comme entrée afin de restaurer l'état READONLY.

Reprise des opérations normales

Suivez cette procédure pour redémarrer les opérations et arrêter le test DR.

  1. Arrêtez le test DR sur le système MVS PRODUCTION.

    Par exemple :

    /STOP EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
DRTEST STOP

    De même, vous n'avez pas besoin d'exécuter l'utilitaire DRTEST RESET une fois que le test DR est terminé. Bien que les indicateurs restent définis dans le CDS de production, ils n'ont aucune incidence sur le traitement tant que le test DR n'est pas actif.

  2. Si vous le souhaitez, placez les CAP en mode automatique.

Scénarios opérationnels

Cette section indique comment utiliser le logiciel de test DR pour configurer l'environnement pour le démarrage et l'arrêt des tests DR. Cette section contient les informations suivantes :

Pour obtenir des informations sur la commande DRTEST et l'utilitaire DRTEST, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS. Pour obtenir des informations sur les messages CDRT, voir Messages et codes ELS.

Remarque :

Pour tous les scénarios, exécutez la procédure indiquée dans la section "Nettoyage après un test DR" après le test.

Scénario 1 : sites de production et de test, ACS sur chaque site, VTSS de rechange sur le site de test

Dans le scénario 1, il y a un seul ACS, à la fois sur les sites de production et de test, et un ou plusieurs VTSS "de rechange" sur le site de test utilisé exclusivement pour les tests (il n'est pas nécessaire de migrer ou restaurer le contenu des VTSS "de rechange"). Dans des opérations normales, le site de production écrit les VTV sur les VTSS et y accède sur le site de production. Les VTV de sortie sont toujours migrés immédiatement et mis en duplex sur des MVC distinctes, une dans chaque ACS. La Figure 7-1 présente le système dans le scénario 1 avant l'exécution de l'utilitaire DRTEST.

Figure 7-1 Configuration de VTSS de rechange - avant l'exécution de l'utilitaire DRTEST

La description de Figure 7-1 est la suivante
Description de Figure 7-1 Configuration de VTSS de rechange - avant l'exécution de l'utilitaire DRTEST

Exemple de JCL pour le scénario 1

Etape PRIMEPRD :

//DRTPRIME EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
DRTEST PRIMEPRD +
DRACS(01) DRVTSS(VTSS0) SPARE HOST(MVS1,MVS2)

Etape CREATE :

//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSNEW1  DD DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2  DD DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW3  DD DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
DRACS(01) DRVTSS(VTSS0) SPARE HOST(MVS1,MVS2)

La Figure 7-2 présente le système dans le scénario 1 (VTSS de rechange sur le site de test) après l'exécution de l'utilitaire DRTEST.

Figure 7-2 Configuration de VTSS de rechange - après l'exécution de l'utilitaire DRTEST

La description de Figure 7-2 est la suivante
Description de Figure 7-2 Configuration de VTSS de rechange - après l'exécution de l'utilitaire DRTEST

Scénario 2 : sites de production et de test, ACS sur chaque site, reprise VTSS sur le site de test

Dans le scénario 2, il y a un seul ACS, à la fois sur les sites de production et de test, mais aucun VTSS "de rechange" sur le site de test utilisé pour les tests. Dans des opérations normales, le site de production écrit les VTV sur les VTSS et y accède sur les deux sites. Les VTV de sortie sont toujours migrés immédiatement et mis en duplex sur des MVC distinctes, une dans chaque ACS. Dans cette configuration, vous devez demander la migration vers zéro d'un ou plusieurs VTSS sur le site de test et basculer ces VTSS hors ligne sur le système de production, afin que les tests puissent reprendre les ressources VTSS requises. En outre, une ou plusieurs partitions LPAR sur le site de test fonctionnent comme des systèmes de production déplacés, en s'exécutant parallèlement aux systèmes de production réels. Les deux ACS sont en ligne sur le système de production.

La Figure 7-3 présente le système dans le scénario 2 (reprise VTSS sur le site de test) avant l'exécution de l'utilitaire DRTEST.

Figure 7-3 Configuration de la reprise VTSS - avant l'exécution de l'utilitaire DRTEST

La description de Figure 7-3 est la suivante
Description de Figure 7-3 Configuration de la reprise VTSS - avant l'exécution de l'utilitaire DRTEST

Exemple de JCL pour le scénario 2

Etape CREATE uniquement, étape PRIMEPRD exécutée précédemment :

//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSNEW1  DD DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2  DD DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW3  DD DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
DRACS(01) DRVTSS(VTSS1) HOST(MVS1,MVS2)

La Figure 7-4 présente le système dans le scénario 2 (reprise VTSS sur le site de test) après l'exécution de l'utilitaire DRTEST.

Figure 7-4 Configuration de la reprise VTSS - après l'exécution de l'utilitaire DRTEST

La description de Figure 7-4 est la suivante
Description de Figure 7-4 Configuration de la reprise VTSS - après l'exécution de l'utilitaire DRTEST

Scénario 3 : sites de production et de test, ACS sur chaque site, aucun VTSS

Dans le scénario 3, il y a un seul ACS, à la fois sur les sites de production et de test, mais aucun VTSS sur le site de test utilisé pour les tests. Dans des opérations normales, le site de production écrit les jeux de données de bande et y accède sur les deux sites. La Figure 7-5 présente le système dans le scénario 3 (configuration en lecture seule) avant l'exécution de l'utilitaire DRTEST.

Figure 7-5 Configuration en lecture seule - avant l'exécution de l'utilitaire DRTEST

La description de Figure 7-5 est la suivante
Description de Figure 7-5 Configuration en lecture seule - avant l'exécution de l'utilitaire DRTEST

La Figure 7-6 présente le système dans le scénario 3 (configuration en lecture seule) après l'exécution de l'utilitaire DRTEST.

Figure 7-6 Configuration en lecture seule - après l'exécution de l'utilitaire DRTEST

La description de Figure 7-6 est la suivante
Description de Figure 7-6 Configuration en lecture seule - après l'exécution de l'utilitaire DRTEST

Exemple de JCL pour le scénario 3

Etape CREATE uniquement, étape PRIMEPRD exécutée précédemment :

//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSNEW1  DD DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2  DD DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW3  DD DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
DRACS(01) HOST(MVS1,MVS2)

Scénario 4 : VTSS en cluster avec sites de production et de test DR

Comme indiqué à la Figure 7-7, dans des opérations normales, le scénario 4 est une configuration VTSS en cluster utilisée pour la récupération après sinistre, avec des sites de production et de test DR interconnectés avec les ACS de production et de test DR. VTSS0 est le VTSS principal sur le site de production et VTSS1 est le VTSS secondaire sur le site de test DR.

Figure 7-7 Configuration VTSS en cluster principal/secondaire - opérations normales

La description de Figure 7-7 est la suivante
Description de Figure 7-7 Configuration VTSS en cluster principal/secondaire - opérations normales

Exemple de JCL pour le scénario 4

Etape CREATE uniquement, étape PRIMEPRD exécutée précédemment :

//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSNEW1  DD DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2  DD DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW3  DD DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
DRACS(01) DRVTSS(VTSS1) SHARE HOST(MVS1,MVS2)

Et si vous utilisiez le site de test DR pour les tests ? La Figure 7-8 présente le système dans le scénario 4 lors du test DR.

Figure 7-8 Configuration VTSS en cluster principal/secondaire - lors du test

La description de Figure 7-8 est la suivante
Description de Figure 7-8 Configuration VTSS en cluster principal/secondaire - lors du test

Scénario 5 : sites de production et de test, ACS et VLE sur chaque site

Dans le scénario 5, il y a un seul ACS, à la fois sur les sites de production et de test, mais aucun VTSS "de rechange" sur le site de test utilisé pour les tests. Dans des opérations normales, le site de production écrit les VTV sur les VTSS et y accède sur les deux sites. Les VTV de sortie sont toujours migrés immédiatement et mis en duplex, une copie sur une MVC dans l'ACS, une autre sur une VMVC dans la VLE. Dans cette configuration, vous devez demander la migration vers zéro d'un ou plusieurs VTSS sur le site de test et basculer ces VTSS hors ligne sur le système de production, afin que les tests puissent reprendre les ressources VTSS requises. En outre, une ou plusieurs partitions LPAR sur le site de test fonctionnent comme des systèmes de production déplacés, en s'exécutant parallèlement aux systèmes de production réels. Les ACS et les VLE sont en ligne sur le système de production.

La Figure 7-9 présente le système dans le scénario 5 avant l'exécution de l'utilitaire DRTEST.

Figure 7-9 Configuration VLE et ACS - avant l'exécution de l'utilitaire DRTEST

La description de Figure 7-9 est la suivante
Description de Figure 7-9 Configuration VLE et ACS - avant l'exécution de l'utilitaire DRTEST

Exemple de JCL pour le scénario 5

Etape CREATE uniquement, étape PRIMEPRD exécutée précédemment :

//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSNEW1  DD DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2  DD DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW3  DD DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
DRACS(01) DRVTSS(VTSS1) HOST(MVS1,MVS2) STORMNGR(VLE1)

La Figure 7-10 présente le système dans le scénario 5 après l'exécution de l'utilitaire DRTEST.

Figure 7-10 Configuration VLE et ACS - après l'exécution de l'utilitaire DRTEST

La description de Figure 7-10 est la suivante
Description de Figure 7-10 Configuration VLE et ACS - après l'exécution de l'utilitaire DRTEST

Scénario 6 : sites de production et de test, VLE uniquement sur chaque site

Dans le scénario 6, il y a un seul VTSS connecté à une VLE sur chaque site. Le VTSS sur le site de test n'est pas un VTSS de rechange et est utilisé par le site de production dans des opérations normales. Les VTV de sortie sont toujours migrés immédiatement et mis en duplex sur des VMVC distinctes, une dans chaque VLE.

Dans cette configuration, vous devez demander la migration vers zéro d'un ou plusieurs VTSS sur le site de test et basculer ces VTSS hors ligne sur le système de production, afin que les tests puissent reprendre les ressources VTSS requises. En outre, une ou plusieurs partitions LPAR sur le site de test fonctionnent comme des systèmes de production déplacés, en s'exécutant parallèlement aux systèmes de production réels. Les deux VLE sont en ligne sur le système de production.

La Figure 7-11 présente le système dans le scénario 6 avant l'exécution de l'utilitaire DRTEST.

Figure 7-11 Configuration VLE uniquement - avant l'exécution de l'utilitaire DRTEST

La description de Figure 7-11 est la suivante
Description de Figure 7-11 Configuration VLE uniquement - avant l'exécution de l'utilitaire DRTEST

Exemple de JCL pour le scénario 6

Etape CREATE uniquement, étape PRIMEPRD exécutée précédemment :

//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSNEW1  DD DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2  DD DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW3  DD DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
STORMNGR(VLE1) DRVTSS(VTSS1) HOST(MVS1,MVS2)

La Figure 7-12 présente le système dans le scénario 6 après l'exécution de l'utilitaire DRTEST.

Figure 7-12 Configuration VLE uniquement - après l'exécution de l'utilitaire DRTEST

La description de Figure 7-12 est la suivante
Description de Figure 7-12 Configuration VLE uniquement - après l'exécution de l'utilitaire DRTEST

Scénario 7 : VTSS en cluster (sans bandes) avec sites de production et de test DR

Comme indiqué à la Figure 7-13, dans des opérations normales, le scénario 7 est une configuration VTSS en cluster (sans bandes) qui est utilisée pour la récupération après sinistre, avec des sites de production et de test DR. VTSS0 est le VTSS principal sur le site de production et VTSS1 est le VTSS secondaire sur le site de test DR.

Figure 7-13 Configuration VTSS en cluster principal/secondaire sans bandes - avant l'exécution de l'utilitaire DRTEST

La description de Figure 7-13 est la suivante
Description de Figure 7-13 Configuration VTSS en cluster principal/secondaire sans bandes - avant l'exécution de l'utilitaire DRTEST

Exemple de JCL pour le scénario 7

Etape CREATE uniquement, étape PRIMEPRD exécutée précédemment :

//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSNEW1  DD DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2  DD DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW3  DD DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,SPACE=(CYL,x)
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
DRVTSS(VTSS1) SHARE HOST(MVS1,MVS2))

Et si vous utilisiez le site de test DR pour les tests ? La Figure 7-14 présente le système dans le scénario 7 lors du test DR.

Figure 7-14 Configuration VTSS en cluster principal/secondaire sans bandes - lors du test

La description de Figure 7-14 est la suivante
Description de Figure 7-14 Configuration VTSS en cluster principal/secondaire sans bandes - lors du test