2 Funcionamiento de ELS

En este capítulo, se describe el funcionamiento de ELS.

Funcionamiento de SMC

SMC hace lo siguiente:

• Influencia la asignación de cintas en función de políticas y de las características de volúmenes y unidades proporcionadas por HSC/VTCS:

  Por ejemplo, el comando SMC POLICY se puede utilizar para dirigir las asignaciones temporales a dispositivos reales o virtuales, puede seleccionar subagrupaciones temporales y puede asignar un nombre de clase de gestión que VTCS utilice para gestionar volúmenes virtuales.

• Intercepta los mensajes de intercambio, montaje y desmontaje de MVS y los dirige a HSC o VTCS para su automatización.

SMC debe ejecutarse en todos los hosts en los que se lleva a cabo procesamiento de cintas. El componente del servidor ELS (HSC/VTCS) puede ejecutarse en el mismo host z/OS como el SMC o puede ejecutarse como un host remoto separado. Cuando SMC y HSC/VTCS residen en hosts z/OS diferentes, se utiliza TCP/IP para enviar solicitudes del host de cliente al host de servidor. Para recibir solicitudes de HTTP de un cliente SMC remoto, el componente HTTP debe estar activado en el SMC que se ejecuta en el host de servidor.

La función de cliente/servidor de SMC le permite ejecutar SMC únicamente en los hosts de cliente y ejecutar HSC/VTCS y el servidor HTTP en un host de servidor o más. El uso de la función de cliente/servidor de SMC proporciona las siguientes ventajas:

• Reduce el número hosts en que se puede ejecutar HSC/VTCS. Oracle recomienda ejecutar HSC/VTCS solamente en dos hosts (primario y de respaldo). La ejecución de HSC/VTCS en menos hosts reduce la contención de CDS y elimina la necesidad de gestionar varios archivos de syslog de MVS.

• Se comunica con varios sistemas TapePlex de HSC/VTCS que representan configuraciones de hardware físicamente diferentes.

• Proporciona funcionalidad de conmutación por error cuando se recicla un HSC para fines de mantenimiento.

Funcionamiento de HSC

HSC controla el entorno de cintas físicas. HSC, que responde las solicitudes de SMC, ordena a un HandBot o robot de LSM montar y desmontar las cintas físicas. HSC también controla todas las demás operaciones de cintas físicas, entre ellas, transferencias, intercambios, etc. HSC también gestiona el CDS (conjunto de datos de control) en el que se almacena la información sobre los entornos de cintas reales y virtuales.

Funcionamiento de VTCS

El VTSS proporciona unidades de cinta virtuales (VTD) que emulan dispositivos 3490E. VSM utiliza las VTD para escribir datos en los volúmenes de cintas virtuales (VTV) del VTSS.

VTCS es el software que controla el hardware del VTSS. Por ejemplo, se pueden especificar los umbrales de migración automática (AMT) alto y bajo del VTSS, que controlan el ciclo de migración de VTV o la gestión de espacio del VTSS. Las unidades de cinta reales (RTD) escriben los VTV migrados a cartuchos de varios volúmenes (MVC) físicos. VTCS controla las RTD (aunque HSC proporciona servicios de montaje y desmontaje para los MVC), mientras que HSC controla las unidades de cinta de ACS que no están asignadas a VSM.

Si el host solicita el montaje de un VTV que se migró a un MVC y que no reside en el VTSS, VSM recupera automáticamente el VTV migrado en el VTSS. En Figura 2-1, se muestra el ciclo de migración/recuperación de VTV.

Nota:

VSM admite uso compartido dinámico de las RTD entre los VTSS. No obstante, cuando los VTSS comparten RTD, estos deben tener acceso a todos los mismos hosts.

Figura 2-1 Ciclo de migración/recuperación de VTV

1. Migración: escritura del conjunto de datos de montaje virtual en el VTV, desmontaje virtual del VTV que reside en el VTSS, recopilación del VTV con los demás VTV, montaje real del VTV apilado en MVC y desmontaje real.

2. Recuperación: montaje real para recuperación de VTV, recuperación de VTV en el VTSS y montaje virtual.

Funcionamiento de CDRT

CDRT crea una copia de prueba del CDS de producción que utilizan los hosts de DR y, por lo tanto, admite dos subsistemas de ELS con dos CDS diferentes para gestionar el mismo hardware de ACS. El CDS refleja los cambios en el estado de los cartuchos de cinta y los recursos en el hardware de ACS. Sin embargo, durante una prueba de DR que utiliza CDRT, los dos subsistemas de ELS usan dos CDS diferentes y no se comunican. Por lo tanto, los cambios que se producen en el CDS de producción no se reflejan en la copia del CDS de prueba y viceversa. CDRT actúa para separar el hardware de VSM y ACS de prueba del hardware de VSM y ACS de producción, para lo cual gestiona la prueba de DR a fin de garantizar la integridad de los datos de producción y minimiza los conflictos entre los volúmenes de cinta y los recursos de hardware de ACS. Un factor clave y fundamental para realizar una prueba de DR exitosa mediante el CDRT es contar con una copia válida de un punto en el tiempo del estado de todos los volúmenes de cinta gestionados por el hardware de ACS y/o VSM y gestionados por el subsistema de ELS. 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 de ACS/VSM. Por lo general, los metadatos de los volúmenes de cintas (VOLSER, DSN, fecha de caducidad, estado temporal, designación real o virtual, etc.) se almacenan en un catálogo de gestión de cintas (TMC) o más, en un catálogo de z/OS o más y en el CDS. Garantizar que el estado de los volúmenes de cinta reflejado en los sistemas host sea igual o equivalente en los hosts de producción y en los hosts de DR es de vital importancia para la ejecución correcta de una prueba de DR. 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 para ayudar a validar un plan de continuidad empresarial. Los hosts de prueba de DR ejecutan el hardware separado, mientras que los hosts de producción siguen usando el hardware de ACS separado y no separado.

El hardware de prueba de DR tiene un requisito mínimo de un ACS. De manera opcional, se pueden utilizar un VTSS o más como hardware de prueba de DR. Los hosts de producción y los hosts de DR comparten el ACS. Durante la prueba de DR, los hosts de DR tienen el uso exclusivo de todos los VTSS separados. Para producir copias válidas de un punto en el tiempo de los catálogos de z/OS y TMC, consulte la documentación del software de terceros que corresponda. Por lo general, al final de una prueba de DR, se descartan todos los datos creados a partir de los hosts de prueba de DR, incluida la copia de prueba del CDS, y el hardware separado se vuelve a implementar en el entorno de producción normal.