6 Uso de configuraciones de VTSS en cluster

Los VTSS en cluster le permiten copiar VTV de un VTSS a otro. El VTSS en cluster es una herramienta útil para aplicaciones como, por ejemplo, soluciones de recuperación ante desastres (DR). En estas secciones, se explican los aspectos básicos de los clusters de VTSS y cómo funcionan:

• ¿Qué es un VTSS en cluster?

• Requisitos de VTSS en cluster

• Cómo funcionan las configuraciones de VTSS en cluster

Después de la información básica, hay variaciones y funciones adicionales de los VTSS en cluster que usted puede desear conocer:

• Clusters unidireccionales y bidireccionales

• Agrupación en clusters ampliada

• Replicación sincrónica o asincrónica

• Agrupación en clusters con conexiones TCP/IP

¿Qué es un VTSS en cluster?

Un cluster de VTSS es una solución de alta disponibilidad (HA) que permite una máxima disponibilidad de los datos. Consta de dos o más sistemas VTSS conectados mediante enlaces de comunicación (CLINK) FICON o TCP/IP. Además, cada sistema VTSS dentro del cluster puede acceder a todos los datos creados dentro del cluster (VTSS residente o migrado). Los datos (VTV) creados en un cluster se replican de un sistema VTSS a otro VTSS dentro del mismo cluster bajo el control de políticas de VTCS.

Nota:

Para garantizar que todos los sistemas VTSS puedan acceder a todos los datos creados dentro del cluster, las configuraciones en cluster pueden ser cualquiera de las siguientes:

• Cada VTSS del cluster tiene RTD o VLE conectadas.

• "Sin cintas": ningún VTSS tiene VLE o RTD conectadas.

Por lo tanto, las configuraciones en cluster ofrecen la más alta disponibilidad de datos con una recuperación en caliente si un VTSS dentro de un cluster sufre una interrupción (los datos replicados permanecen disponibles sin necesidad de recuperación a partir de los MVC).

Antes de VTCS 7.0, un cluster solo podía alojar dos VTSS. Con VTCS 7.0, varios VTSS pueden conformar un solo cluster. No obstante, un VTV, solo puede residir en dos VTSS en cualquier momento determinado.

Un cluster puede abarcar varias ubicaciones geográficas. Sin embargo, un cluster debe estar dentro de un solo TapePlex (controlado por un solo CDS).

Un VTV se puede replicar (copiar) de un VTSS a otro:

• De manera asincrónica respecto de la creación del VTV. Se programa para completarse tan pronto como sea posible después del desmontaje del VTV.

• De manera sincrónica respecto de la creación del VTV. El desmontaje del VTV no finalizará hasta que haya finalizado la replicación.

Nota:

Para la replicación sincrónica, mediante CLINK o mediante una replicación mejorada, el VTSS termina la replicación si la replicación causará que se supere el manejador de interrupciones faltante (MIH).

Para VSM 6 y VSM 7, el valor de timeout de MIH se puede configurar de 20 a 45 minutos con incrementos de 5 minutos. Para VSM4 y VSM 5, el valor de timeout de MIH se puede configurar en 20 o 45 minutos. El valor configurado en el VTSS debe coincidir con el valor configurado en el mainframe.

Las conexiones entre los VTSS dentro de un cluster pueden ser unidireccionales, donde los datos (VTV) fluyen solo en una dirección, o bidireccionales, donde los datos (VTV) puede fluir en ambas direcciones. La utilidad CONFIG especifica si un cluster es unidireccional o bidireccional, y la clase de gestión de los VTV determina su política de replicación, si corresponde, y si la replicación se realiza de manera sincrónica o asincrónica.

Por lo tanto, el almacenamiento de MVC (descrito en Uso de la función de almacenamiento externo de ELS) y la replicación de VTV pueden facilitar una solución de recuperación ante desastres/continuidad empresarial. No obstante, la replicación de VTV es superior como solución de alta disponibilidad, porque gracias a la replicación:

• Se pueden realizar copias de seguridad de los datos de manera sincrónica.

• Los datos recientes que se han replicado en un VTSS de "recuperación", se pueden restaurar más rápidamente porque no necesita montar MVC.

Requisitos de VTSS en cluster

En Tabla 6-1, se muestran los requisitos de VTSS en cluster.

Tabla 6-1 Requisitos de VTSS en cluster

Componente	Requisito
Clusters ampliados	D02.07.00.00 o microcódigo superior del VTSS para VSM4 o VSM5 con conexiones FICON únicamente. Para VSM 6 y VSM 7, todos los niveles de microcódigo.
2 VTSS dentro de un cluster (interfaces ESCON)	Los VTSS principal y secundario pueden ser cualquier combinación de VSM4, donde el secundario puede tener cualquier capacidad. Los VSM5 no tienen interfaces ESCON y no pueden estar en un cluster con otros VTSS que usan ESCON
2 VTSS dentro de un cluster (interfaces FICON)	Los VTSS principal y secundario pueden ser cualquier combinación de VSM4 y VSM5, donde el secundario puede tener cualquier capacidad. Por ejemplo, todo lo que se indica a continuación es válido: VSM5 principal, VSM4 secundario VSM5 principal, VSM5 secundario VSM4 principal, VSM4 secundario VSM4 principal, VSM5 secundario (no recomendado)
Microcódigo del VTSS principal y secundario	El microcódigo del VTSS principal debe estar en un nivel que admita el envío de VTVS replicados. El microcódigo del VTSS secundario debe estar en un nivel que admita la recepción del VTVS replicado y el uso del secundario como VTSS de producción. Después de instalar el microcódigo, se debe activar la función de agrupación en clusters en ambos VTSS, el principal y el secundario, con un disquete de opciones. Consulte a su representante del servicio de hardware de StorageTek para obtener más información.
VTD reservados para agrupación en clusters	En las configuraciones de VTSS en cluster, debe asegurarse de que los primeros 16 VTD de cada VTSS (0-F) se reserven para agrupación en clusters. Estos dispositivos deben estar FUERA DE LÍNEA para los MVS, y sus rutas deben estar en línea para cada host de servidor de HSC. Esto también se aplica a los VTSS involucrados en la replicación cruzada entre sistemas TapePlex. VTCS no registra los primeros 16 VTD con SMC/HSC, lo cual impide montar los VTV en estos VTD.
RTD	En los entornos con dos ACS, los mismos tipos de dispositivos deben estar representados en las RTD conectadas a cada ACS, de modo que los datos migrados por un VTSS en un cluster puedan ser recuperados por el otro VTSS en el cluster. La cantidad de MVC, la ubicación y el tipo de medios usados para la migración se determinan mediante el parámetro MIGPOL de la sentencia MGMTclas. Se debe tener en cuenta cada ACS y, si un tipo de unidad en un ACS está conectada a uno de los VTSS en un entorno de VTSS en cluster, debe haber una unidad del mismo tipo y en el mismo ACS conectada a todos los demás VTSS de ese entorno en cluster.
IP nativo (agrupación en clusters con TCP/IP)	El IP nativo requiere CDSLEVEL F y versiones superiores, con los siguientes PTF: Para 6.2: L1A00P7 - SMC6200 L1H14IM - SMS6200 L1H14O2 - SOS6200 L1H14IL - SWS6200 Para 7.0, L1H150G (SES7000) Para 7.1 y superiores, se incluye compatibilidad en el nivel base. Para IP nativo, se admiten las siguientes conexiones: VSM5 a VSM5 VSM5 a VSM 6 VSM 6 a VSM 6 VSM 6 o VSM5 a VLE

Los requisitos de la replicación sincrónica, que se aplica solamente a VSM4 y versiones superiores, son los que se describen en Tabla 6-2.

Tabla 6-2 Requisitos de replicación sincrónica

Requisito de replicación sincrónica	Nivel de microcódigo de VTSS	Nivel de CDS
IP nativo o puertos FICON para los CLINK	D02.03.00.00 o superior para VSM4 y VSM5. Para VSM 6 y VSM 7, todos los niveles de microcódigo	"F" o superior

Los requisitos de la replicación mejorada, que se aplica solamente a VSM6 y versiones superiores, son los que se describen en Tabla 6-3.

Tabla 6-3 Requisitos de la replicación mejorada

Requisito de la replicación mejorada	Nivel de microcódigo de VTSS	Nivel de CDS
IP nativo o puertos FICON para los CLINK	VSM 6.3.0.03.000 (se recomienda 6.3.0.05.000) para VSM 6; VSM 7.0.0.05.000 para VSM 7. Se aplica PTF L1H18MB.	"H" o superior

Cómo funcionan las configuraciones de VTSS en cluster

Puede usar VSM para conectar dos VTSS mediante enlaces de cluster (CLINK) para formar una Configuración de VTSS en cluster. Debe usar las mismas sentencias para implementar una configuración en cluster:

• Los clusters pueden ser unidireccionales o bidireccionales según las sentencias CLINK.

• El VTSS secundario (o segundo par) puede estar en la misma ubicación física que el principal (o primer par) o en una ubicación remota.

• La sentencia CONFIG CLUSTER especifica los VTSS que forman el cluster.

• La sentencia CONFIG CLINK define los CLINK que conectan los VTSS. La manera en que escribe las sentencias CLINK determina si una replicación es unidireccional o bidireccional. Para obtener ejemplos, consulte VTSS en cluster unidireccional y "VTSS en cluster bidireccional."

• El parámetro MGMTclas REPLICAT identifica la clase de gestión que contiene los VTV que VSM replica (copia) de un VTSS del cluster al otro.

El parámetro CONFIG GLOBAL REPLicat ahora especifica cuándo replicar un VTV de la siguiente manera:

REPLicat

Especifica cuándo el VSM replica el VTV.

ALWAYS

La solicitud de replicación se agrega a la cola de replicación del VTCS cada vez que el VTV se desmonta, independientemente de que el VTV haya cambiado durante el montaje (el valor predeterminado).

CHANGED

La solicitud de replicación se agrega a la cola de replicación del VTCS si el VTV:

• se cambió durante el montaje o

• se encontraba en modo de solo lectura durante el montaje, pero existen menos copias de MVC del VTV de lo previsto.

Independientemente de la configuración de CONFIG GLOBAL REPLicat, la replicación también exige lo siguiente:

• El VTV debe estar desmontado en un VTSS que admita replicación, y no puede haber una copia idéntica del VTV en el otro VTSS del cluster.

• Además del valor CONFIG GLOBAL REPLicat , debe especificar REPLICAT(YES) en la clase de gestión de un VTV para que se produzca la replicación.

  Para obtener más información, consulte la Referencia de comandos, sentencia de control y utilidades de ELS.

• VTCS migra inmediatamente (con KEEP) los VTV replicados. Puede especificar el VTSS de origen para la migración de los VTV replicados en el parámetro MIGRATE de la sentencia STORclas. También debe tener en cuenta que debe especificar la replicación en una clase de gestión que apunta a una clase de almacenamiento con un valor de parámetro MIGRATE para realizar la migración a partir del VTSS deseado. De lo contrario, es posible que no se produzca la migración a partir del VTSS deseado.

  Dado que el VTCS migra inmediatamente (con KEEP) VTV replicados, independientemente de la configuración de MGMTclas IMMDELAY, StorageTek recomienda enfáticamente que no establezca explícitamente una política MGMTclas IMMDELAY para VTV replicados. Si lo hace, el VTCS cumple con la solicitud explícita de migración inmediata y migra inmediatamente el VTV afectado desde cualquier VTSS que pueda realizar la migración en primer lugar (es decir, el primer VTSS que tenga una copia residente de VTV y una RTD disponible para realizar la migración). Por lo tanto, la configuración de una política MGMTclas IMMDELAY explícita es redundante y puede interferir en la migración y la replicación óptimas del VTV.

  También debe tener en cuenta que la migración inmediata (KEEP) después de una replicación no es lo mismo que la automigración. Es decir, durante la migración inmediata implícita, no se suprimen VTV de ningún VTSS para gestionar la DBU. En cambio, los VTV, simplemente, se "prealmacenan de manera provisional" mediante la migración a un MVC a partir del VTSS receptor, y dejan ambos contenidos del buffer de VTSS sin modificaciones. Para gestionar el espacio en un cluster de VTSS, VTCS realiza una automigración de VTV, de acuerdo con el ciclo de migración y la gestión del espacio de cualquier VTSS. Si la capacidad del VTSS receptor es mayor o igual a la del VTSS emisor, mediante la automigración del VTSS emisor se suprime un VTV replicado de ambos VTSS. Si la capacidad del VTSS receptor es menor que la del VTSS emisor, la automigración puede comenzar en el VTSS receptor. En este caso, mediante la automigración se suprime un VTV replicado solo del VTSS receptor y se deja la copia para que siga siendo residente en el VTSS emisor.

• Tenga en cuenta que los requisitos de replicación de los datos se determinan después de un desmontaje, no después de una recuperación. La recuperación de un VTV no genera una replicación; por lo tanto, la recuperación bajo demanda y MVCdrain no generarán una replicación. No obstante, si el VTV se recupera y se monta en un VTD, en el momento del desmontaje se replicará en el VTSS secundario o par.

• Un cluster puede admitir distintas cargas de trabajo en cada uno de los cuatro modos operativos. Por ejemplo, solo los cluster de funcionamiento completo pueden admitir la replicación activa, pero en el modo primario degradado, puede cambiar el estado de los VTD secundarios a en línea para que MVS tome el control de la carga de trabajo. Puede usar Query para mostrar el estado del VTSS, la replicación del VTV, el enlace del cluster y el cluster. Puede usar VARY VTSS para cambiar los estados de VTSS y VARY CLink para cambiar los estados de CLINK.

Cómo funciona la conciliación de VTSS

• Siempre que un par de VTSS en cluster reanuda el estado de funcionamiento completo, VTCS concilia el contenido de los dos VTSS. Esto ocurre durante la inicialización del VTCS o cuando un VTSS se coloca en línea y su par también.

• La conciliación consiste en suprimir, o migrar y suprimir VTV (o replicar un VTV si la replicación no se completó anteriormente de forma correcta). Es decir, que no hay recuperación involucrada en la conciliación del contenido de VTSS.

  Por ejemplo, en un cluster unidireccional con un VTV residente en el VTSS receptor, pero no en el emisor, VTCS suprime el VTV del receptor (después de asegurarse de que todas las copias necesarias del MVC se hayan hecho). De esta manera, se evita la recuperación en el emisor.

  De manera similar, en un cluster unidireccional con un VTV residente en el emisor pero no en el VTSS receptor, VTCS replica el VTV en el receptor, en lugar de recuperarlo a partir de un MVC.

• El proceso de conciliación supone que si un VTV replicado reside en el VTSS emisor, entonces es una copia válida. Si la copia que se encuentra en el receptor es distinta, el VTCS la suprime.

• Para mantener acciones de conciliación coherentes en un cluster bidireccional, el VTSS en el que el VTV residía o en el que residió por última vez (según lo indicado por el registro de VTV del CDS), se considera el VTSS emisor. El proceso de conciliación es el que se describe anteriormente para los clusters unidireccionales.

Clusters unidireccionales y bidireccionales

Los clusters de los VTSS pueden ser:

• Unidireccionales, donde un VTSS es el principal y otro, el secundario. Para obtener más información, consulte "VTSS en cluster unidireccional."

• Bidireccionales, donde ambos VTSS son pares y la replicación se realiza de uno a otro en cualquier dirección. Para obtener más información, consulte "VTSS en cluster bidireccional."

Clusters unidireccionales

Como se muestra en Figura 6-1, en un cluster unidireccional, la replicación solo se realiza del principal al secundario.

Figura 6-1 VTSS en cluster unidireccional

Descripción de Figura 6-1 VTSS en cluster unidireccional

Cómo funcionan los clusters de VTSS unidireccionales

• El secundario puede recibir ambos VTV replicados del principal y carga de trabajo de producción no replicada mediante ninguno de los métodos de enrutamiento estándares (por ejemplo, TAPEREQs). Debe cambiar el estado de los VTD en el secundario a en línea para MVS, de modo que el secundario pueda aceptar trabajo de producción. No puede cambiar el estado de las direcciones de VTD utilizadas por las terminaciones de CLINK a en línea para MVS, como se describe en "Cómo funcionan las configuraciones de VTSS en cluster."

• Un VTV con replicación activada se asigna a un VTSS principal en línea, a menos que no haya ninguno disponible; en ese caso, el VTV se asigna a un VTSS secundario en línea. Si no hay VTSS secundarios disponibles, el VTV se asigna a un VTSS sin cluster. Un VTV sin replicación se puede asignar a cualquier VTSS en línea, incluido el secundario de un cluster de funcionamiento completo.

• En el momento del desmontaje, un VTV con replicación activada que reside en un cluster de funcionamiento completo se agrega a la cola para replicación en el VTSS secundario. Si un VTV con replicación activada se desmonta de un VTD en un VTSS que no es parte de un cluster de funcionamiento completo, el VTV se agrega a la cola para migración inmediata.

  Cuando el VTSS secundario recibe un VTV replicado de un VTSS principal, el VTV se migra de inmediato (con la opción KEEP) independientemente de la configuración de migración inmediata de la clase de gestión para este VTV.

• Tanto el VTSS principal como el secundario pueden gestionar todas las recuperaciones de espacio.

• Si está utilizando interfaces ESCON o FICON, en el VTSS principal, los CIP/FIP de CLINK están configurados en modo Nearlink, mientras que en el VTSS secundario, los CIP/FIP están configurados en modo de host.

  Por lo tanto, debe configurar CLINK solo para el VTSS principal, como se muestra en el siguiente ejemplo, donde VTSS1 es el VTSS principal.

  .
  .
  CLUSTER NAME=CLUSTER1 VTSSs(VTSS1,VTSS2)
   CLINK VTSS=VTSS1 CHANIF=0G
   CLINK VTSS=VTSS1 CHANIF=0O
   CLINK VTSS=VTSS1 CHANIF=1G
   CLINK VTSS=VTSS1 CHANIF=1O
  .
  .
  

Clusters bidireccionales

Como se muestra en Figura 6-2, la agrupación en clusters bidireccionales requiere pares de CLINK unidireccionales, de modo que los datos fluyan en direcciones opuestas en los CLINK.

Figura 6-2 VTSS en cluster bidireccional

Descripción de Figura 6-2 VTSS en cluster bidireccional

Cómo funcionan los clusters de VTSS bidireccionales

Durante el funcionamiento normal de un cluster bidireccional, ambos VTSS están en línea para el VTCS, como se muestra a continuación:

• En un cluster bidireccional, cada uno de los VTSS pares puede recibir trabajo de producción mediante métodos de enrutamiento estándares (por ejemplo, TAPEREQs). Debe cambiar el estado de los VTD en ambos VTSS a en línea para MVS, de modo que cada uno pueda aceptar trabajo de producción. No obstante, tenga en cuenta que no puede cambiar el estado de las direcciones de VTD utilizadas por las conexiones de CLINK a en línea, como se describe en "Cómo funcionan las configuraciones de VTSS en cluster."

• En un cluster bidireccional, un VTV con replicación activada se asigna a cualquiera de los VTSS pares. Si uno de los VTSS pares está fuera de línea o desactivado, la carga de trabajo de producción se puede ejecutar en el resto de los VTSS que estén en línea. No obstante, los VTV que requieren replicación, se asignan a los VTSS restantes solamente si no hay otros clusters de funcionamiento completo disponibles o adecuados. En este caso, los VTV replicados se migran de inmediato mediante la función KEEP y se los agrega a la cola para replicación hasta el momento en que el VTSS esté en línea.

• En un cluster bidireccional, en el momento del desmontaje, un VTV con replicación activada que reside en un cluster de funcionamiento completo se agrega a la cola para replicación en el otro VTSS par. Si un VTV con replicación activada se desmonta de un VTD en un VTSS que no es parte de un cluster de funcionamiento completo, el VTV se agrega a la cola para migración inmediata. Tenga en cuenta que los requisitos de replicación de los datos se determinan después de un desmontaje, no después de una recuperación. La recuperación de un VTV no genera una replicación; por lo tanto, la recuperación bajo demanda y MVCdrain no generarán una replicación. No obstante, si el VTV se recupera y se monta en un VTD, en el momento del desmontaje se replicará en el VTSS secundario, a menos que especifique REPLICAT(CHANGED) (la opción recomendada), como resultado de lo cual el VTV se replicará nuevamente solo si los datos cambiaron.

• Los dos VTSS pares pueden gestionar recuperaciones de espacio.

• Si está usando interfaces ESCON o FICON:

  • En cada VTSS par, los CLINK CIPs/FIPs "emisores" están configurados en modo Nearlink, mientras que los CLINK CIPs/FIPs "receptores" están configurados en modo de host.

    Por lo tanto, debe configurar los CLINK "emisores" en cada VTSS par, como se muestra en el siguiente ejemplo, donde VSMPR1 y VSMPR2 son VTSS pares.

    .
    .
    CLUSTER NAME=CLUSTER1 VTSSs(VSMPR1,VSMPR2)
     CLINK VTSS=VSMPR1 CHANIF=0O:0
     CLINK VTSS=VSMPR1 CHANIF=0O:1
     CLINK VTSS=VSMPR2 CHANIF=1O:0
     CLINK VTSS=VSMPR2 CHANIF=1O:1
    .
    .
    

• Cada CLINK debe estar conectado al mismo cluster de almacenamiento de cada VTSS (cluster de almacenamiento 0 a cluster de almacenamiento 0 o cluster de almacenamiento 1 a cluster de almacenamiento 1). Si no puede realizar la configuración de esta manera, se pueden producir errores de replicación, canal y comunicación.

  Como se muestra en el ejemplo de Figura 6-3, el puerto del CLINK emisor (modo Nearlink) en VSMPR1 está en el cluster de almacenamiento 1 y se conecta a un puerto del CLINK receptor (modo de host), que también está en el cluster de almacenamiento 1, en VSMPR2. De manera similar, un puerto del CLINK emisor en el cluster de almacenamiento 0 de VSMPR2 se conecta a un puerto del CLINK receptor en el cluster de almacenamiento 0 de VSMPR1.

  Figura 6-3 CLINK ESCON/FICON para VTSS en cluster bidireccionales

  
  Descripción de Figura 6-3 CLINK ESCON/FICON para VTSS en cluster bidireccionales
  
  

Agrupación en clusters ampliada

La agrupación en clusters ampliada (EC) permite la conexión de tres o más VTSS mediante CLINK con una sola configuración de TapePlex (1 CDS). La agrupación en clusters es una solución de alta disponibilidad diseñada para que una carga de trabajo pueda continuar sin interrupciones durante una interrupción del VTSS. La agrupación en clusters exige que todos los subsistemas VTSS que formen parte de un cluster tengan acceso a todos los MVC generados por un solo subsistema VTSS en ese cluster. Si un VTSS dentro de un cluster se conecta a un Tapeplex remoto (CTR), todos los subsistemas VTSS del cluster se deben conectar al mismo TapePlex para conservar la capacidad de HA.

Mediante la agrupación en clusters ampliada, puede configurar un VSM con CLINK conectados a varios VTSS y la cantidad de conexiones de CLINK solo se ve limitada por la cantidad de conexiones físicas disponibles. Se requiere D02.07.00.00 o microcódigo superior. Todas las reglas de agrupación en clusters y replicación disponibles se aplican a EC. Todas las configuraciones de una agrupación en clusters ampliada se establecen en función de dos configuraciones básicas unidireccionales, como se muestra en Figura 6-4.

Figura 6-4 Configuraciones básicas de una agrupación en clusters ampliada

Descripción de Figura 6-4 Configuraciones básicas de una agrupación en clusters ampliada

Replicación sincrónica o asincrónica

Puede elegir entre una de las siguientes opciones: puede replicar de manera sincrónica o asincrónica, en función de las políticas de su sitio.

Implementación de la replicación sincrónica

Atención:

Con la replicación sincrónica, el tiempo necesario para replicar un volumen virtual demorará la finalización de cualquier trabajo que genere datos que tengan una política de replicación sincrónica.

1. Asegúrese de que el sistema cumpla con los requisitos de replicación sincrónica que se describen en Tabla 6-2.

2. Con todos los sistemas HSC/VTCS apagados, use CONFIG GLOBAL para activar la replicación sincrónica:

   CONFIG GLOBAL SYNCHREP=YES
   

3. Asegúrese de que el parámetro CONFIG GLOBAL REPLICAT esté establecido como lo desea:

   ALWAYS

   La solicitud de replicación se agrega a la cola de replicación del VTCS cada vez que el VTV se desmonta, independientemente de que el VTV haya cambiado durante el montaje (el valor predeterminado).

   CHANGED

   La solicitud de replicación se agrega a la cola de replicación del VTCS si el VTV:

   • se cambió durante el montaje o

   • se encontraba en modo de solo lectura durante el montaje, pero existen menos copias de MVC del VTV de lo previsto.

4. Especifique la replicación sincrónica en las sentencias MGMTClas que desee:

   MGMT (name) ..... REP(YES_SYNC)
   

Implementación de replicación asincrónica con supervisión de trabajos

Puede optar por usar la replicación asincrónica, pero también es posible que quiera saber si la replicación finalizó correctamente. En este procedimiento, debe usar la utilidad DRMONitr para pausar el trabajo de MVS asociado hasta que la replicación finalice correctamente.

1. Asegúrese de que el sistema cumpla con los requisitos de replicación sincrónica que se describen en Tabla 6-2.

2. Con todos los sistemas HSC/VTCS apagados, use CONFIG GLOBAL para activar la replicación asincrónica:

   CONFIG GLOBAL SYNCHREP=NO
   

3. Asegúrese de que el parámetro CONFIG GLOBAL REPLICAT esté establecido como lo desea:

   ALWAYS

   La solicitud de replicación se agrega a la cola de replicación del VTCS cada vez que el VTV se desmonta, independientemente de que el VTV haya cambiado durante el montaje (el valor predeterminado).

   CHANGED

   La solicitud de replicación se agrega a la cola de replicación del VTCS si el VTV:

   • se cambió durante el montaje o

   • se encontraba en modo de solo lectura durante el montaje, pero existen menos copias de MVC del VTV de lo previsto.

4. Especifique la replicación asincrónica en las sentencias MGMTClas que desee:

   MGMT (mgmtname) ..... REP(YES)
   

5. Cree un JCL para supervisar la replicación asincrónica.

   Para esto, use la utilidad DRMONitr para supervisar la replicación. DRMONitr hace que el trabajo de MVS asociado pause hasta que la replicación finalice correctamente. Por ejemplo:

   //MONITOR EXEC PGM=SLUADMIN,PARM='MIXED'
   //STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
   //* If HSC IS NOT OR MAY NOT BE ACTIVE, INCLUDE THE 
   //* FOLLOWING:
   //SLSCNTL DD DSN=primary.cds.name,DISP=SHR
   //SLSCNTL2 DD DSN=secondary.cds.name,DISP=SHR
   //SLSSTBY   DD DSN=standby.cds.name,DISP=SHR
   //SLSPARMP DD DSN=hlq.PARMLIB(BKPCNTL),DISP=SHR
   //SLSPARMS DD DSN=hlq.PARMLIB(BKPCNTL2),DISP=SHR
   //SLSPARMB DD DSN=hlq.PARMLIB(BKPSTBY),DISP=SHR
   //SYSIN          DD UNIT=SYSDA,SPACE=(TRK,1)
   //* THE FOLLOWING IS USED BY THE SNAPSHOT UTILITY:
   //SYSPRINT  DD  SYSOUT=* 
   //SLSPRINT   DD SYSOUT=* 
   //SLSIN         DD *
   DRMON MGMT(mgmtname) REPL MAXAGE(24) TIMEOUT(120)
   

En este ejemplo, la utilidad DRMON supervisa las replicaciones de la clase de gestión especificada. Asimismo, supervise únicamente los VTV que se actualizaron en las últimas 24 horas y genere un timeout para DRMON después de 120 minutos.

Agrupación en clusters con conexiones TCP/IP

La función de conexión de IP nativo del VTSS le permite usar el protocolo TCP/IP parar "agrupar en clusters" (conectar) dos o más VTSS para replicación de VTV. Con la agrupación en clusters de IP nativo, cada VTSS tiene puertos de Ethernet para conexión a la red TCP/IP. Antes, estaba limitado a las conexiones ESCON o FICON para replicación. Mediante el uso de TCP/IP para CLINK puede ofrecer un mejor rendimiento de la replicación en protocolos ESCON o FICON y, si lo desea, los puertos ESCON o FICON existentes se pueden usar exclusivamente para RTD y conexiones host, donde se admiten las siguientes conexiones:

• VSM5 a VSM5

• VSM5 a VSM 6

• VSM 6 a VSM 6

En esta sección, se describe solo la implementación de VTCS para IP nativo. El personal de soporte del hardware de StorageTek u otros QSP son responsables de la configuración del VTSS.

El entorno de TCP/IP

Los CLINK conectados a TCP/IP cumplen la misma función que los CLINK de conexión de canal FICON o ESCON, pero el CLINK TCP/IP se conecta mediante un puerto Ethernet en el VTSS, en lugar de hacerlo desde un puerto ESCON o FICON. En el ejemplo que aparecen en Figura 6-5, se muestran VSM5 pares, cada uno con 4 tarjetas IFF3 con puertos Ethernet. Los cables Ethernet de los puertos Ethernet de las tarjetas IFF3 se conectan a las redes de área local (LAN, una para cada VTSS) y las LAN se conectan mediante una red de área amplia (WAN).

Figura 6-5 Entorno de TCP/IP con dos VSM5

Descripción de Figura 6-5 Entorno de TCP/IP con dos VSM5

Configuración de VTCS para CLINK TCP/IP

A continuación, se muestran los parámetros de la sentencia CONFIG CLINK.

Sentencia CONFIG CLINK

La sentencia CONFIG CLINK suministra dos tipos de conexiones de VTSS a VTSS mediante los siguientes parámetros:

CLINK CHANIF=nn o nn:n

Define un puerto FICON o ESCON para usar como CLINK.

CLINK IPIF=ci:p

Define un puerto Ethernet para usar como CLINK. Los valores válidos para CONFIG RTD IPIF son c=0 o 1, i=A o I, p=o a 3 para VSM5 y VSM 6. En los VSM5, este valor debe coincidir con los valores especificados en la pantalla de estado de configuración de IFF de VSM5. En los VSM 6, este valor debe ser único para cada VTSS; y no corresponde a un valor real de los puertos TCP/IP de VSM 6.

Nota:

La sentencia CLINK debe contener el parámetro CHANIF o el parámetro IPIF, pero no ambos.