El posible que los clientes que usan o mantienen un sitio de recuperación ante desastres (DR) como parte de un plan de continuidad empresarial deseen validar periódicamente su capacidad para continuar el procesamiento normal de la producción antes de que ocurra un desastre real; otros clientes no tienen opción y deben probar de forma periódica la preparación de su modelo de continuidad empresarial para cumplir con los requisitos de seguro y/o de los auditores.
Mediante el uso de la función de prueba concurrente de recuperación ante desastres (CDRT), que ahora es una función integrada al software de StorageTek ELS, las empresas que actualmente usan las bibliotecas de cintas StorageTek Streamline y/o Nearline (hardware real), VSM (hardware virtual) y software asociado (HSC, VTCS) pueden validar su capacidad de continuidad empresarial de cintas reales y virtuales sin necesidad de comprar hardware o software adicional.
CDRT admite una prueba paralela de aplicaciones y hosts de producción con acceso simultáneo a los datos de producción, mediante los sistemas de prueba de DR y producción.
Los conceptos clave de CDRT son:
Mediante el uso de CDRT, una prueba de DR puede ejecutarse con hardware real, virtual o ambos.
CDRT, HSC y VTCS aplican de forma programática algunas restricciones funcionales durante la preparación de CDS y la prueba real de DR en un intento por garantizar la integridad del sistema.
CDRT separa de forma lógica una porción de hardware real y virtual y agrupaciones de volúmenes de cintas de producción existentes para el período de la prueba de DR. Esto permite probar la configuración de DR y, al mismo tiempo, ejecutar el trabajo de producción, además, permite garantizar la integridad de los datos de producción y minimizar los conflictos para los volúmenes de cinta y los recursos de hardware.
La CDRT crea una copia de prueba del CDS de producción. Por lo tanto, el subsistema de producción de ELS y los subsistemas de prueba de DR de ELS no se comunican entre sí. Los cambios que se producen en el CDS de prueba de DR no se reflejan en la copia del CDS de producción y viceversa. Los hosts de prueba de DR ejecutan el hardware separado de forma lógica únicamente. Los hosts de producción siguen usando todo el hardware con una excepción: los hosts de DR usan exclusivamente los VTSS separados de forma lógica durante la prueba de DR. Otros recursos, como las RTD, los cartuchos de varios volúmenes (MVC) y las cintas reutilizables reales se deben controlar mediante la definición de agrupaciones separadas para cada conjunto de hosts.
Una prueba de DR se puede realizar solo con recursos locales o con una combinación de recursos locales y remotos; también se admiten las configuraciones que constan de un sitio remoto con hardware real y virtual solamente, o que constan de hardware real y virtual con un procesador de mainframe.
El hardware de prueba de DR puede incluir cualquier combinación de ACS, VTSS y VLE.
Después de una prueba de DR, la copia de prueba de CDS y todos los datos creados a partir de la prueba de DR, por lo general, se desechan, y el hardware separado lógicamente se vuelve a desplegar en el entorno de producción normal.
Nota:
Para satisfacer las necesidades de recuperación de un verdadero desastre, es fundamental que los trabajos en un flujo de trabajos de prueba de DR no actualicen los volúmenes creados en la producción, ya sea mediante DISP=MOD
o mediante la sobrescritura de estos volúmenes. El uso de dichas prácticas significa que si ocurrió un verdadero desastre, el estado de estos volúmenes será impredecible.
Para la ejecución de la prueba de DR, se recomienda enfáticamente que los volúmenes de producción que se pudieron modificar durante la prueba de DR se copien a nuevos volúmenes al comienzo de la prueba y que los volúmenes copiados sean actualizados por la prueba de DR, en lugar de los volúmenes originales. Además, el JCL se debe modificar, de ser posible, de modo que se conozca el estado de todos los volúmenes de cinta en el momento de un desastre.
Un factor fundamental para realizar una prueba de DR exitosa mediante CDRT es contar con una copia coherente del estado de todos los volúmenes de cinta gestionados por el software de ELS y el hardware real y virtual. La coherencia en el estado de los volúmenes de cinta entre los hosts de producción y los hosts de DR al comienzo de la prueba de DR es lo que permite el procesamiento paralelo de las aplicaciones del cliente. Dado que el CDS refleja el estado de todos los recursos y volúmenes de cinta en el hardware real y virtual, la CDRT cumple parcialmente con este requisito de coherencia cuando hace la copia de prueba del CDS.
No obstante, en un entorno de volúmenes de cintas, muchas veces, algunos de los datos del estado de estos volúmenes de cintas (metadatos) se conservan y se gestionan fuera del subsistema de ELS y el hardware real y virtual. Por lo general, los metadatos de los volúmenes de cintas (VOLSER, DSN, fecha de caducidad, estado reutilizable, designación real o virtual, etc.) se almacenan en uno o más catálogos de gestión de cintas (TMC), en uno o más catálogos de z/OS y en el CDS.
Debe coordinar la creación de copias de metadatos conservados y gestionados fuera del ELS (y el hardware real y virtual) con la creación de la copia de prueba del CDS que realiza la CDRT.
La CDRT obtiene los datos de VTV de uno o más de los siguientes recursos del sitio de DR:
MVC
VLE
VTSS
Debido a que el CDS de producción es la fuente de información de los VTV disponibles para la prueba de DR, es importante asegurarse de que el ciclo de sincronización de volúmenes reutilizables permita que los volúmenes utilizados en la prueba de DR no se coloquen en el estado reutilizable antes del comienzo de la prueba. StorageTek también recomienda que cambie el VTSS de prueba a fuera de línea antes de realizar la DRTEST CREATE
.
Tenga en cuenta que la ejecución de la reutilización durante la prueba no afecta al contenido del VTSS de prueba de DR ni los de los MVC, si este se establece en READONLY
mediante la utilidad ACTMVCGN
.
La copia de CDS del sitio de DR proporciona la ubicación de los VTV en el momento de la copia, y la ubicación, por lo general, se encuentra en los MVC o las VLE. No obstante, en ocasiones, puede optar por usar copias de VTV en un VTSS que existe en el sitio de prueba. En general, puede hacer esto en las siguientes situaciones:
Define su VTSS de DR con la palabra clave SHARE
, que impide actualizaciones del contenido de cualquier VTV de producción.
Tiene dos VTSS en cluster: uno en el sitio de producción y uno en el sitio de DR; y su prueba de DR no modifica el contenido de ningún VTV de producción.
Tiene dos VTSS en cluster: uno en el sitio de producción y uno en el sitio de DR; y desea dedicar tiempo, después de la prueba de DR, a identificar y migrar manualmente cualquier VTV que actualizó la prueba de DR.
Nota:
Puede usar la utilidadDRMONitr
para garantizar que los datos críticos de DR lleguen a la ubicación de recuperación designada antes de ejecutar una prueba de DR.Los datos creados por la prueba de DR se reflejan únicamente en el CDS de prueba de DR (que se desecha después de la prueba) y en los MVC de prueba de DR, que se encuentran en un rango separado de volúmenes de los MVC de producción. Además, los VTV creados por la prueba de DR permanecen en el VTSS de prueba de DR después de la prueba, a menos que realice una de las siguientes acciones:
Use la utilidad SLUADMIN SCRATCH
en el entorno de prueba de DR para reutilizar (con MGMTCLAS DELSCR(YES)
) todos los VTV en el rango de la subagrupación de prueba de DR. Esta opción requiere el uso de la característica POOLPARM/VOLPARM
.
Asegúrese de que todos los VTV de producción que fueron modificados por la prueba de DR se migren a los MVC de prueba de DR mediante el comando MIGRATE
con DELETE(YES)
a partir del sistema de prueba de DR. Si no puede hacer esto, el sistema de producción recoge los datos que fueron modificados por la prueba de DR.
Solicítele al CSE de StorageTek CSE o a otro QSP que "limpie" el VTSS de prueba de DR después de la prueba para eliminar todos los datos del VTSS.
Nota:
Si elige la opción 2 o la opción 3, el contenido del VTSS no coincidirá con el sistema de producción, porque los VTV estarán ausentes del CDS de prueba de DR cuando este se devuelva a la producción. Si bien es el software el que controla esta situación, el rendimiento de su producción puede degradarse.En las siguientes secciones, se indica cómo gestionar los recursos de CDRT.
El primer paso para gestionar los recursos de CDRT consiste en definir los volúmenes de su sistema mediante la utilidad POOLPARM/VOLPARM
. La función simplifica la gestión general de sus volúmenes y agrupaciones de cintas, y proporciona un método de segregación de volúmenes que se escriben en una configuración de CDRT. El uso de POOLPARM/VOLPARM
es necesario cuando se comparten los VTSS de prueba de DR y se recomienda enfáticamente para otros escenarios.
Nota:
La utilidadSLUADMIN SET VOLPARM
se debe ejecutar mediante el CDS de producción y debe definir las agrupaciones de producción y prueba de DR. La utilidad SET VOLPARM no es válida para un CDS de prueba de DR.Las subagrupaciones reutilizables son aplicables a todos los escenarios de prueba de DR. La siguiente sintaxis muestra el uso de las definiciones POOLPARM/VOLPARM
para definir las subagrupaciones reutilizables de producción y prueba de DR. Al usar los mismos nombres para las subagrupaciones de producción y prueba de DR (con distintos rangos de volumen), no es necesario cambiar las políticas de producción cuando ejecuta la prueba de DR, como se muestra en el siguiente ejemplo.
* 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)
Cuando define subagrupaciones reutilizables mediante la utilidad POOLPARM/VOLPARM
, puede usar la utilidad SLUADMIN SCRATCH
de HSC para reutilizar volúmenes de salida de prueba de DR dentro del entorno de prueba de DR. Junto con una clase de gestión que especifica DELSCR(YES), la ejecución de la utilidad de reutilización elimina los VTV creados por la prueba de DR a partir del VTSS.
Los recursos de MVC se utilizan para todos los escenarios de prueba de DR, excepto para cinta real únicamente y VSM sin cinta. En el siguiente ejemplo, se muestra el uso de las definiciones POOLPARM/VOLPARM
para definir las agrupaciones de MVC de producción y prueba de DR.
* 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)
Conserve el contenido de los MVC de producción para utilizarlo en un escenario de prueba de DR con lo siguiente:
Use la utilidad ACTMVCGN
para definir los MVC que se utilizarán como entrada para la prueba de DR en READONLY
, como se muestra en el siguiente ejemplo.
//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)
Mediante VTCS CONFIG
, asegúrese de que no se ejecute la recuperación en todos los hosts de producción:
CONFIG HOST NAME(host) NORECLAM
Hay dos tipos de recursos de VTSS: no compartidos y compartidos.
En un entorno donde los VTV se migran a los MVC o a la VLE, los recursos de VTSS se separan durante una prueba de DR. El sistema de prueba de DR tiene acceso solamente a los VTSS definidos mediante las utilidades DRTEST PRIMEPRD/CREATE
, y estos VTSS deben permanecer fuera de línea para la producción. El comando DRTEST START
se rechaza si un VTSS de DR está en línea en el entorno de producción.
En algunos casos, puede haber dos VTSS con el mismo nombre, tanto en el sitio de prueba como en el de producción. En este caso, el parámetro SPARE
de la utilidad DRTEST PRIMEPRD/CREATE
especifica que el VTSS de prueba de DR tiene el mismo nombre que un VTSS de producción, pero no es físicamente el mismo dispositivo, lo que permite que el dispositivo de producción permanezca en línea durante la prueba. Es importante que tenga en cuenta que no debe utilizar el parámetro SPARE
para ningún otro escenario.
En Escenario 4: VTSS en cluster con sitios de producción y prueba de DR, se utiliza VTSS en cluster para enviar datos al VTSS del sitio de DR. En este escenario, el cluster no funciona durante la prueba de DR, porque el VTSS de prueba de DR se encuentra fuera de línea para la producción.
Si los VTV de producción se modifican de alguna manera durante la prueba de DR, debe asegurarse de que todos los VTV modificados se eliminen del VTSS antes de volver a colocar el VTSS de prueba nuevamente en línea para producción. De lo contrario, el sitio de producción puede recoger los VTV modificados. Para evitar esta situación, StorageTek recomienda enfáticamente que la prueba de DR se diseñe de manera tal que los VTV de producción no sean alterados por la prueba.
En un escenario de VTSS en cluster puede no haber VTD en el VTSS de prueba accesible para el host de producción. Para permitir la comunicación mediante ECAM de la producción al VTSS de prueba de DR, especifique lo siguiente en VTCS CONFIG
:
VTD LOW=xxxx HIGH=xxxx NOVERIFY
Cambie el estado del VTSS de prueba de DR a un estado inactivo. Por ejemplo:
VARY VTSS1 QUIESCED
El objetivo aquí es cerrar (de forma controlada) la replicación para VTSS1, de modo que pueda usarlo exclusivamente para la prueba de DR.
Supervise la replicación hasta que finalice con Display REPLicat
. Aquí, la replicación todavía está activa:
VTSS HOST QDEPTHVTSS0 PRODUCTION 1
Usted sabrá que la replicación ha finalizado cuando vea lo siguiente:
VTSS HOST QDEPTH VTSS0 PRODUCTION 0
Realice una comprobación cruzada para verificar que la replicación haya finalizado comprobando el estado del CLINK con Display CLINK (Visualizar CLINK)
. Aquí, el CLINK todavía está activo:
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
Cambie el estado del VTSS de prueba de DR a fuera de línea:
VARY VTSS1 OFFLINE
Antes de comenzar una prueba de DR, debe:
Planificar la prueba de modo que la salida de la prueba no entre accidentalmente en la producción.
Preparar la prueba de modo que el CDS de prueba de DR coincida con el contenido del VTSS de DR.
Además, StorageTek recomienda enfáticamente que todos los VTSS del sitio de prueba se limpien tan pronto como sea posible después de la prueba. Esta práctica garantiza que los VTSS del sitio de prueba estén vacíos al comienzo de la próxima prueba y que ningún dato de prueba de DR permanezca en los VTSS que se devuelven a la producción.
Para limpiar los VTSS de prueba, realice alguna de las siguientes acciones:
No permita que la prueba de DR realice ninguna actualización (sobrescritura o agregación) en los VTV de producción y utilice POOLPARM/VOLPARM
para definir las subagrupaciones reutilizables de prueba de DR. Mediante este método, puede ejecutar la utilidad de reutilización para reutilizar todos los VTV del rango de prueba de DR, y estos se suprimen automáticamente del VTSS (si la clase de gestión especifica DELSCR(YES)
).
Si la prueba de DR puede actualizar los VTV de producción, debe asegurarse de que cualquier VTSS que se utilice para la salida de prueba de DR se vacíe antes de que el VTSS regrese a la producción. Para hacer esto, debe migrar a cero en el entorno de prueba de DR o debe solicitarle a un CSE de StorageTek o a otro QSP que "limpie" el VTSS.
Cuando ejecuta la utilidad DRTEST CREATE
para crear un CDS de prueba de DR, los metadatos del contenido de VTSS se propagan al entorno de prueba. Los VTV del VTSS de prueba de DR están disponibles para el entorno de prueba de DR.
Si el VTSS de prueba de DR se define como de reserva, el contenido del VTSS físico de DR no coincidirá con los metadatos de CDS, que hacen referencia a la instancia de producción del VTSS de reserva. Para eliminar esta discrepancia, antes de crear el CDS de prueba de DR, migre la instancia de producción del VTSS de reserva a 0 en el entorno de producción. Puede ejecutar VTCS VTVRPT OPTION(UNAVAIL)
para garantizar que todos los VTV se migren y estén disponibles para otros VTSS. Si este paso no se realiza, los intentos de la prueba de DR por acceder a los VTV del VTSS de repuesto ejecutarán mensajes SLS6680E a los montajes de VTV.
Si el entorno de cinta no incluye MVC de VLE o cinta real, puede ejecutar la CDRT en un entorno de VTSS compartido. El parámetro DRTEST PRIMEPRD/CREATE SHARE
especifica que la producción y la prueba de DR comparten un VTSS durante la prueba. Este entorno aplica las siguientes restricciones:
DRTEST CREATE
no puede definir también recursos DRACS o STORMNGR. Es decir, no se pueden mirar datos del VTSS compartido a medios externos.
El sistema de producción debe definir recursos de volúmenes mediante la utilidad POOLPARM/VOLPARM
.
Los montajes de un VTV de una subagrupación distinta de DRTEST en el entorno de prueba de DR hacen que el VTV sea de solo lectura. Es decir, no se permite que la prueba de DR se sobrescriba o se agregue a ningún VTV de producción.
Los recursos de ACS se utilizan para los escenarios de prueba de DR con cinta real únicamente o con cinta virtual sin VLE en un entorno de VSM sin cinta. Los recursos de ACS para CDRT se especifican en el parámetro DRTEST PRIMEPRD/CREATE DRACS
.
Debe ejecutar el comando CAPPREF
de HSC para establecer los CAP en modo manual antes de ejecutar la utilidad DRTEST CREATE
. El software garantiza que permanezcan en ese estado durante la realización de la prueba. Después de que introduce el comando DRTEST START
, se aplican restricciones de ACS sobre la prueba de DR, tanto en el entorno de producción como en el de prueba de DR, para garantizar la coherencia en el hardware y los respectivos CDS a fin de permitir que ambos sitios accedan a los datos. El comando DRTEST START
se rechaza si un CAP en un ACS de prueba de DR está en modo automático en el entorno de producción.
El software aplica automáticamente las siguientes restricciones.
Los requisitos del host de producción de DR durante una prueba de DR activa para el ACS de DR son los siguientes:
Los CAP deben permanecer en modo manual.
FLOAT(OFF)
y EJCTAUTO(OFF)
se aplican automáticamente, independientemente de las configuraciones del comando MNTD.
No puede ejecutar las utilidades de expulsión, movimiento, auditoría y reutilización para el ACS de prueba de DR.
Los requisitos del host de prueba de DR durante una prueba de DR son los siguientes:
Ningún ACS distinto de los de prueba de DR se puede cambiar al estado en línea.
Los CAP deben permanecer en modo manual.
FLOAT(OFF)
y EJCTAUTO(OFF)
se aplican automáticamente y ningún otro valor es válido en el comando MNTD.
No puede ejecutar las utilidades de expulsión, movimiento, auditoría y reutilización para el ACS de prueba de DR.
Solo se permiten actualizaciones reutilizables para volúmenes definidos mediante POOLPARM/VOLPARM
como volúmenes de subagrupaciones reutilizables de prueba de DR.
Puede definir recursos de VLE mediante el parámetro STORMNGR
de los comandos PRIMEPRD
y CREATE
de DRTEST. Por lo general, los recursos de prueba de DR son los ACS o las VLE, aunque no hay ninguna restricción sobre el uso de ambos.
Al igual que los MVC físicos, los VMVC de VLE se definen mediante la utilidad POOLPARM/VOLPARM
, con un rango de VMVC reservado para la prueba de DR. La prueba de DR también tiene acceso de lectura a los VMVC de producción, como se muestra en el siguiente ejemplo.
//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
Para minimizar las diferencias entre los entornos de producción y de prueba de DR, la CDRT le permite definir políticas para la gestión de VTV que tienen el mismo nombre en los entornos de producción y prueba de DR, pero distintas definiciones de políticas.
Tenga en cuenta que los sitios de producción y de prueba pueden compartir un VTSS mediante el parámetro DRTEST DRVTSS SHARE
. También se debe tener en cuenta que ya no es necesario especificar un ACS ficticio de DR para un VTSS compartido o una prueba de DR que utiliza la VLE. La especificación de un VTSS compartido presenta las siguientes restricciones:
Un VTSS compartido de prueba de DR no debe tener conexiones de RTD activas del sitio de producción o de prueba de DR.
El CDS debe incluir definiciones VOLPARM
para definir las subagrupaciones reutilizables de prueba de DR.
Los VTV de producción (los que no están en una subagrupación de prueba de DR) se deben definir como de solo lectura cuando se montan, y no se pueden modificar.
Cuando define clases de gestión para un sistema de prueba de DR, normalmente, define solamente una copia de MVC de los VTV de salida. Para permitir la limpieza del VTSS después de la prueba, se recomienda que se especifique DELSCR(YES)
, como se muestra en el siguiente ejemplo.
STOR NAME(LOCAL) ACS(01) MVCPOOL(MVCP1) MGMT NAME(CRITICAL) MIGPOL(LOCAL) IMMWAIT(0) DELSCR(YES)
Cuando usa un VTSS compartido para la prueba de DR, no se permiten copias de salida migradas. Debe especificar DELSCR(YES)
para permitir la limpieza después de la prueba, como se muestra en el siguiente ejemplo.
MGMT NAME(CRITICAL) DELSCR(YES)
Durante una prueba de DR, se recomienda que aplique procedimientos para optimizar el acceso a los recursos, tanto en el entorno de prueba como en el de producción. Específicamente:
Antes de comenzar la prueba de DR, defina clases de gestión de producción que especifiquen la migración inmediata a los ACS de producción y prueba de DR, de modo que los VTV estén disponibles en los MVC accesibles para el sistema de prueba de DR y el sistema de producción.
Defina clases de gestión de prueba de DR que especifiquen una sola copia de migración, dado que un solo ACS está normalmente disponible para el sitio de prueba de DR.
Use la utilidad POOLPARM/VOLPARM
para separar ambas subagrupaciones reutilizables y las agrupaciones de MVC entre la producción y la prueba de DR.
De ser posible, asegúrese de que el procesamiento de la prueba de DR no actualice ningún VTV preexistente (DISP=MOD
o sobrescritura con DISP=OLD
).
Minimice la contención entre los trabajos de producción que migran al ACS de prueba de DR y los trabajos de prueba de DR que acceden a los VTV de los MVC en el ACS de prueba de DR mediante la ejecución de la utilidad ACTMVCGN
para marcar los MVC activos como de solo lectura en el entorno de producción.
Desactive la recuperación de espacio del MVC (mediante CONFIG HOST NORECLAM
) en los MVC de producción durante la prueba de DR, a fin de preservar el contenido de volúmenes de MVC que está utilizando el sistema de prueba de DR.
Nota:
Para obtener más información acerca de los comandos y las utilidades que se usan en este procedimiento, consulte la Referencia de comandos, sentencia de control y utilidades de ELS.Para ejecutar una prueba de DR:
Defina agrupaciones de volúmenes en el CDS de producción mediante el comando SET VOLPARM
y las sentencias POOLPARM/VOLPARM
en SLSPARM DD
.
Para obtener más información, consulte "Recursos de volúmenes."
Asegúrese de que los recursos de prueba estén correctamente definidos.
Para obtener más información, consulte:
Cree sentencias MGMTCLAS/STORCLAS
para el entorno DRTEST.
Para obtener más información, consulte:
Si es necesario, copie el catálogo de MVS para el sitio de prueba de DR.
De manera opcional, copie la base de datos de TMS (si se usa un TMS) para el sitio de prueba de DR.
En el sitio de producción, ejecute la utilidad DRTEST (mediante la palabra clave PRIMEprd
) para preparar el CDS de producción para la prueba de DR.
Por ejemplo, consulte "JCL de muestra para el escenario 1."
Debe ejecutar PRIMEprd
una vez en el entorno, independientemente de cuántas iteraciones de DRTEST ejecute, a menos que la configuración cambie. Si la configuración de la prueba de DR cambia de alguna manera, debe volver a ejecutar PRIMEprd
. Tenga en cuenta también que no debe ejecutar la utilidad DRTEST RESET
después de que la prueba de DR se ha completado. Si bien los indicadores permanecen establecidos en el CDS de producción, no afectan el procesamiento, siempre que la prueba de DR no esté activa.
En el sistema de producción, use el comando CAPPREF
de HSC para establecer todos los CAP del ACS de prueba de DR en modo manual.
En el sitio de prueba de DR, ejecute la utilidad DRTEST (mediante la palabra clave CREATE
) en una copia de seguridad o reflejada del CDS de producción para crear el nuevo CDS de prueba de DR para la prueba de DR.
Cada escenario ofrece un ejemplo de DRTEST CREATE
.
Los CDS se deben asignar utilizando las sentencias DD en la utilidad. Tenga en cuenta que cuando se utiliza NOUPD
, solo se necesita la sentencia SLSCNTL DD
, y puede tratarse del CDS principal real, una copia de seguridad o una copia reflejada.
Comience la prueba de DR en el sitio de producción, apunte a las definiciones MGMTCLAS/STORCLAS
de DRTEST que creó en el paso 3.
Por ejemplo:
/PRIME EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSIN DD * DRTEST START
Nota:
También puede iniciar la prueba si introduce el comandoDRTEST START
desde la consola.Inicie el sistema SMC en los hosts del cliente de DRTEST.
Inicie los sistemas SMC/HSC/VTCS (apunte a los CDS que creó en el paso 8) en los sistemas de prueba de DR.
Verifique que los VTD para los VTSS de prueba y las rutas estén en línea.
Cambie los VTSS de DR a en línea para el sistema de DR.
Si corresponde, cambie las RTD de DR a en línea para el sistema de DR.
Ejecute las pruebas en el sitio de prueba de DR.
Durante la prueba de DR, se aplican las siguientes condiciones programáticas:
Los ACS del sitio de producción se desconectan de los hosts de prueba de DR.
Los VTSS del sitio de producción están fuera de línea para los hosts de prueba de DR.
No se pueden producir desmontajes, expulsiones, movimientos, actualizaciones reutilizables, auditorías ni redistribuciones reutilizables flotantes en el sitio de prueba de DR.
No se pueden producir desmontajes, inserciones/expulsiones, movimientos, auditorías ni redistribuciones reutilizables flotantes en el ACS de prueba de DR en el sitio de producción.
Todos los CAP del ACS de prueba de DR se encuentran en modo manual.
Nota:
Puede introducir volúmenes en el ACS de prueba de DR, pero una vez que la prueba ha finalizado, debe expulsar los volúmenes o auditar las celdas para sincronizar el CDS de producción con los volúmenes de biblioteca reales.Como se describe al comienzo de este capítulo, es fundamental que los trabajos de un flujo de trabajo de prueba de DR no actualicen los volúmenes creados en la producción.
Nota:
Para obtener información acerca del comandoDRTEST
y la utilidad DRTEST
, consulte la Referencia de comandos, sentencia de control y utilidades de ELS. Para obtener información acerca de los mensajes de CDRT, consulte los Mensajes y códigos de ELS.Nota:
Para ELS 7.1 y superiores, si tiene instalado SPE de mejora de limpieza de CDRT, no debe ejecutar este procedimiento inmediatamente después de la prueba de DR o antes de reanudar el entorno de producción normal. En cambio, puede ejecutarlo sin interrupciones (por ejemplo, antes de la próxima prueba de DR).Ejecute la utilidad SCRAtch
de SLUADMIN para reutilizar todos los VTV posibles en las agrupaciones de DRTEST.
Debido a que establece DELSCR(YES)
en la clase de gestión, los VTV se suprimirán automáticamente del buffer cuando los reutilice al final de la prueba.
ADVERTENCIA:
Si no utiliza SET VOLPARM
y no establece agrupaciones reutilizables independientes, correrá el riesgo de perder datos.
Si la prueba de DR ha modificado o puede haber modificado cualquier VTV de producción, también debe hacer lo siguiente para asegurarse de que ningún dato de prueba de DR permanezca en el VTSS de producción:
Ejecute un informe de VTV en el CDS de DRTEST y examine la salida para determinar si algún VTV en los rangos de VTV de producción se modificaron durante la prueba.
Tenga en cuenta que VTVRPT COPIES
ahora indica con una "D" en la columna de DRT las copias de VTV que son copias de prueba de DR.
Si se modificó un VTV, debe realizar alguna de las siguientes acciones:
Realice una migración bajo demanda de los VTV modificados en función del informe de VTV.
Migre el VTSS de prueba de DR a 0.
Solicítele a un CSE que "limpie" el VTSS de prueba.
Detenga el HSC/VTCS y el SMC en el sistema de MVC de PRUEBA de DR.
Si la utilidad ACTMVCGN
se ejecutó antes de la prueba para colocar los MVC en el estado READONLY
, ejecute SLUADMIN mediante la salida de la sentencia SLUSMVOF DD
como entrada para restablecer el estado READONLY
.
Siga este procedimiento para reiniciar las operaciones y detener la prueba de DR.
Detenga la prueba de DR en el sistema MVS de PRODUCTION
.
Por ejemplo:
/STOP EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * DRTEST STOP
Tenga en cuenta también que no debe ejecutar la utilidad DRTEST RESET
después de que la prueba de DR se ha completado. Si bien los indicadores permanecen establecidos en el CDS de producción, no afectan el procesamiento, siempre que la prueba de DR no esté activa.
Si lo desea, coloque los CAP en modo automático.
En esta sección, se indica cómo usar el software de prueba de DR para configurar el entorno para iniciar y detener las pruebas de DR. Esta sección incluye la siguiente información:
Escenario 1: Sitios de prueba y producción, ACS en cada sitio, VTSS de reserva en el sitio de prueba
Escenario 3: Sitios de prueba y producción, ACS en cada sitio, sin VTSS
Escenario 4: VTSS en cluster con sitios de producción y prueba de DR
Escenario 5: Sitios de prueba y producción, ACS y VLE en cada sitio
Escenario 6: Sitios de prueba y producción, solo VLE en cada sitio
Escenario 7: VTSS en cluster (sin cinta) con sitios de producción y prueba de DR
Para obtener información acerca del comando DRTEST y la utilidad DRTEST, consulte la Referencia de comandos, sentencias de control y utilidades de ELS. Para obtener información acerca de los mensajes de CDRT, consulte los Mensajes y códigos de ELS.
Nota:
Para todos los escenarios, después de la prueba, ejecute el procedimiento que se indica "Limpieza después de una prueba de DR."En el escenario 1, hay un solo ACS en los sitios de prueba y producción, y los VTSS de "reserva" en el sitio de prueba se usan únicamente para la realización de pruebas (no hay requisitos que establezcan que se debe migrar o restaurar el contenido de los VTSS de "reserva"). En las operaciones normales, el sitio de producción escribe los VTV y accede a ellos en los VTSS del sitio de producción, y los VTV de salida siempre se migran inmediatamente y se duplican en MVC separados, uno en cada ACS. En Figura 7-1, se muestra el sistema del escenario 1 antes de ejecutar la utilidad DRTEST.
Figura 7-1 Configuración de VTSS de reserva: antes de la ejecución de la utilidad DRTEST
Paso 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)
Paso 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)
En Figura 7-2, se muestra el sistema del escenario 1 (VTSS de reserva en el sitio de prueba) después de la ejecución de la utilidad DRTEST
.
Figura 7-2 Configuración de VTSS de reserva: después de la ejecución de la utilidad DRTEST
En el escenario 2, hay un solo ACS, tanto en el sitio de producción como en el de prueba, pero no hay VTSS de "reserva" en el sitio de prueba para la realización de la pruebas. En las operaciones normales, el sitio de producción escribe los VTV y accede a ellos en los VTSS de ambos sitios, y los VTV de salida siempre se migran inmediatamente y se duplican en MVC separados, uno en cada ACS. En esta configuración, debe realizar una migración bajo demanda a cero de uno o más VTSS en el sitio de prueba y colocar estos VTSS en estado fuera de línea para el sistema de producción, de modo que las pruebas puedan tomar el control de los recursos de VTSS necesarios. Además, en el sitio de prueba, una o más LPAR funcionan como sistemas de producción desplazados que se ejecutan en paralelo con los sistemas de producción reales. Ambos ACS están en línea para el sitio de producción.
En Figura 7-3, se muestra el sistema del escenario 2 (toma de control del VTSS en el sitio de prueba) antes de la ejecución de la utilidad DRTEST
.
Figura 7-3 Configuración de toma de control del VTSS: antes de la ejecución de la utilidad DRTEST
Paso CREATE solamente, PRIMEPRD ejecutado anteriormente:
//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)
En Figura 7-4, se muestra el sistema del escenario 2 (toma de control del VTSS en el sitio de prueba) después de la ejecución de la utilidad DRTEST
.
Figura 7-4 Configuración de toma de control del VTSS: después de la ejecución de la utilidad DRTEST
En el escenario 3, hay un solo ACS, tanto en el sitio de producción como en el de prueba, pero no hay ningún VTSS en el sitio de prueba para la realización de la pruebas. En las operaciones normales, el sitio de producción escribe los juegos de datos de cinta y accede a ellos en ambos sitios. En Figura 7-5, se muestra el sistema del escenario 3 (configuración real únicamente) antes de la ejecución de la utilidad DRTEST
.
Figura 7-5 Configuración real únicamente: antes de la ejecución de la utilidad DRTEST
En Figura 7-6, se muestra el sistema del escenario 3 (configuración real únicamente) después de la ejecución de la utilidad DRTEST
.
Figura 7-6 Configuración real únicamente: después de la ejecución de la utilidad DRTEST
Paso CREATE solamente, PRIMEPRD ejecutado anteriormente:
//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)
Como se muestra en Figura 7-7, en las operaciones normales, el escenario 4 es una configuración de VTSS en cluster que se usa para DR, con los sitios de producción y prueba de DR interconectados a los ACS de producción y prueba de DR. En el sitio de producción, VTSS0 es el principal y VTSS1 es el secundario en el sitio de prueba de DR.
Figura 7-7 Configuración de un VTSS principal/secundario en cluster: operaciones normales
Paso CREATE solamente, PRIMEPRD ejecutado anteriormente:
//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)
¿Qué ocurre si desea usar el sitio de prueba de DR para realizar pruebas? En Figura 7-8, se muestra el sistema del escenario 4 durante la prueba de DR.
Figura 7-8 Configuración de un VTSS principal/secundario en cluster: durante la prueba
En el escenario 5, hay un solo ACS, tanto en el sitio de producción como en el de prueba, pero no hay VTSS de "reserva" en el sitio de prueba para la realización de la pruebas. En las operaciones normales, el sitio de producción escribe los VTV y accede a ellos en los VTSS de ambos sitios, y los VTV de salida siempre se migran inmediatamente y se duplican; una copia se migra a un MVC del ACS y otra, a un VMVC de la VLE. En esta configuración, debe realizar una migración bajo demanda a cero de uno o más VTSS en el sitio de prueba y colocar estos VTSS en estado fuera de línea para el sistema de producción, de modo que las pruebas puedan tomar el control de los recursos de VTSS necesarios. Además, en el sitio de prueba, una o más LPAR funcionan como sistemas de producción desplazados que se ejecutan en paralelo con los sistemas de producción reales. Tanto los ACS como las VLE están en línea para el sistema de producción.
En Figura 7-9, se muestra el sistema del escenario 5 antes de la ejecución de la utilidad DRTEST
.
Figura 7-9 Configuración de VLE y ACS: antes de la ejecución de la utilidad DRTEST
Paso CREATE solamente, PRIMEPRD ejecutado anteriormente:
//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)
En Figura 7-10, se muestra el sistema del escenario 5 después de la ejecución de la utilidad DRTEST
.
Figura 7-10 Configuración de VLE y ACS: después de la ejecución de la utilidad DRTEST
En el escenario 6, hay un solo VTSS con una VLE conectada en cada sitio. El VTSS del sitio de prueba no es de reserva y lo usa el sitio de producción durante las operaciones normales. Los VTV de salida siempre se migran inmediatamente y se duplican en VMVC independientes, uno en cada VLE.
En esta configuración, debe realizar una migración bajo demanda a cero de uno o más VTSS en el sitio de prueba y colocar estos VTSS en estado fuera de línea para el sistema de producción, de modo que las pruebas puedan tomar el control de los recursos de VTSS necesarios. Además, en el sitio de prueba, una o más LPAR funcionan como sistemas de producción desplazados que se ejecutan en paralelo con los sistemas de producción reales. Ambas VLE están en línea para el sitio de producción.
En Figura 7-11, se muestra el sistema del escenario 6 antes de la ejecución de la utilidad DRTEST
.
Figura 7-11 Configuración de solo VLE: antes de la ejecución de la utilidad DRTEST
Paso CREATE solamente, PRIMEPRD ejecutado anteriormente:
//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)
En Figura 7-12, se muestra el sistema del escenario 6 después de la ejecución de la utilidad DRTEST
.
Figura 7-12 Escenario de solo VLE: después de la ejecución de la utilidad DRTEST
Como se muestra en Figura 7-13, en las operaciones normales, el escenario 7 es una configuración de VTSS en cluster (sin cinta) utilizada para DR, con un sitio de producción y uno de prueba de DR. En el sitio de producción, VTSS0 es el principal y VTSS1 es el secundario en el sitio de prueba de DR.
Figura 7-13 Configuración de un VTSS principal/secundario en cluster sin cinta: antes de la ejecución de la utilidad DRTEST
Paso CREATE solamente, PRIMEPRD ejecutado anteriormente:
//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))
¿Qué ocurre si desea usar el sitio de prueba de DR para realizar pruebas? En Figura 7-14, se muestra el sistema del escenario 7 durante la prueba de DR.
Figura 7-14 Configuración de un VTSS principal/secundario en cluster sin cinta: durante la prueba