La función de almacenamiento externo de ELS (almacén de ELS) reemplaza y mejora, en gran medida, a su predecesora, la función de almacenamiento fuera del sitio de VSM. La función de almacén de ELS proporciona las siguientes mejoras para volúmenes de cinta real para almacenamiento:
Utiliza el CDS de HSC para almacenar datos del volumen almacenado y datos de almacén. El uso de la información de almacenamiento de CDS, en lugar del TMS elimina:
El riesgo de errores humanos al devolver volúmenes al entorno automatizado
Volúmenes atascados en la ubicación de almacén cuando faltan en la lista desplegable que se genera
El riesgo de dejar accidentalmente volúmenes de almacén devueltos en el entorno automatizado
Utiliza LCM para gestionar el proceso de almacenamiento, que incluye tres métodos de almacenamiento:
Almacenamiento de MVC para recuperación ante desastres (DR). Para obtener más información, consulte "Almacenamiento de MVC para DR."
Almacenamiento de MVC para retención a largo plazo (LTR). Para obtener más información, consulte "Almacenamiento de MVC para LTR."
Expulsión de volúmenes a un almacén de planta. Para obtener más información, consulte "Expulsión de volúmenes específicos a un almacén local (planta)."
El primer paso consiste en definir el área de volumen almacenado del CDS del HSC. Para hacerlo, debe ejecutar la utilidad SLUADMIN SET VAULTVOL. Por ejemplo:
SET VAULTVOL NBRVOLS(40000)
Nota:
Si necesita agregar más volúmenes de almacén después de la definición inicial, debe hacerlo mediante MERGEcds; por lo tanto, permita volúmenes suficientes en la definición inicial para cubrir sus necesidades por anticipado.
Debe contar con bloques FREE (LIBRES) suficientes en el CDS para alojar los volúmenes que planea almacenar (volúmenes de cinta real), además de espacio adicional para crecimiento. Consulte Configuración de HSC y VTCS para obtener información sobre cómo calcular el espacio para volúmenes de almacén y consulte Gestión de HSC y VTCS para obtener información sobre cómo ampliar el CDS si no es lo suficientemente grande para alojar los volúmenes almacenados.
El paso dos consiste en definir los almacenes que contienen los volúmenes almacenados. Para hacerlo, debe ejecutar la utilidad SLUADMIN SET VAULT para cada almacén. Por ejemplo:
SET VAULT ADD NAME(DRVLT1) SLOTS(10000) DESC(’DR Vault’) SET VAULT ADD NAME(LTRVLT1) SLOTS(20000) DESC(’LTR Vault’) SET VAULT ADD NAME(FLOOR) SLOTS(500) DESC(’Floor Vault’)
Nota:
La cantidad total de ranuras en todos los almacenes que define no puede superar la cantidad de volúmenes especificados en la sentenciaVAULTVOL.Mientras que HSC define los almacenes y los volúmenes almacenados, LCM los gestiona. Tenga en cuenta, especialmente, los siguientes parámetros de almacenamiento de LCM:
La cantidad de días que transcurren entre el momento en que se selecciona un volumen para devolución a partir del almacén y el momento en que realmente se devuelve al entorno automatizado. El período de gracia proporciona un margen de seguridad, de modo que lleguen nuevos volúmenes al almacén antes de que se devuelvan volúmenes antiguos. Si no se especifica, el valor predeterminado es tres días.
DEFAULT se excluye mutuamente con GRACEPERIOD y, por lo general, se utiliza para el almacén de "planta" (bastidor manual) que contiene automáticamente todos los volúmenes expulsados del entorno automatizado mediante LCM EJECT(ASNEEDED). Otros volúmenes que se expulsan del ACS también se pueden asignar a este almacén, por ejemplo, un volumen que está activo pero que ya no es un buen candidato para automatización. Generalmente, este es un almacén definido que, en realidad, está constituido por bastidores en la planta del centro de datos. DEFAULT es un período de gracia de cero días para permitir que estos volúmenes se vuelvan a introducir en el ACS en cualquier momento.
También se debe tener en cuenta que hay opciones de expulsión estándares disponibles para todos los volúmenes de almacén. Entre ellas, se incluyen los CAP que se utilizarán, la definición de un mensaje de expulsión, el modo de las expulsiones y si las expulsiones deben estar en orden de serie de volúmenes o ranuras.
Siempre que los MVC se almacenan para DR, debe haber, como mínimo, dos copias de cada VTV para separar los MVC, uno de los cuales permanece en el sitio, mientras el otro MVC se expulsa y se coloca en un almacén externo. Esto se hace mediante la asignación de dos clases de almacenamiento en la clase de gestión que se asigna al VTV.
Por lo tanto, el desafío es que desea proteger los datos, pero desea usar el espacio del MVC de la manera más económica posible, como se indica a continuación:
Defina la mínima cantidad posible de clases de almacenamiento. El exceso de clases de almacenamiento, por lo general, significa demasiados MVC y/o MVC con pocos VTV.
Use la mínima cantidad posible de VTSS para crear MVC. De ser posible, use solo un VTSS para crear MVC de almacén.
¿Qué otras consideraciones hay para la creación y el almacenamiento de MVC? Considere lo siguiente:
En primer lugar, los VTV deben migrar a los MVC de almacén tan pronto como sea posible, de modo que se puedan expulsar y mover al almacén, porque estos VTV, generalmente, no se usan como entrada para otros pasos de trabajo.
En segundo lugar, dado que los VTV de DR caducan en distintos momentos, considere la posibilidad de agrupar los VTV con fechas de caducidad similares en los MVC. No obstante, para reducir la cantidad total de MVC que se crean para enviar al almacén, limite la cantidad de estos grupos. Dado que ya habrá actividad para consolidar los VTV en menos MVC, el beneficio es mínimo más allá de dos grupos, uno para los VTV con períodos de caducidad muy cortos, por ejemplo, en el plazo de los próximos siete días, y uno para todos los demás volúmenes. Los VTV con control de catálogo se deben considerar como parte de un segundo grupo, ya que no hay manera de saber la fecha de caducidad real.
En tercer lugar, si bien no es necesario tener almacenes separados para DR y LTR, puede resultar ventajoso tener MVC de DR ubicados en un almacén independiente. Esto permite que estos volúmenes se agrupen y se envíen al sitio de DR cuando es necesario.
Para los datos de LTR, las consideraciones son levemente distintas. En primer lugar, por definición, los datos de LTR no caducarán por un período prolongado. Por lo tanto, a diferencia de los datos de DR, que caducan con el transcurso del tiempo, los MVC de LTR no se fragmentarán. Se realizará un procesamiento periódico inicial de estos MVC para lograr que los MVC almacenados se llenen tanto como sea posible, al igual que con los MVC de DR; no obstante, una vez que estén suficientemente llenos, estos MVC permanecerán estáticos. No hay necesidad de tener más de una sola clase de almacenamiento para estos volúmenes. No obstante, debe tener en cuenta que es posible que desee migrar inmediatamente algunos de datos de LTR, mientras que otros datos se pueden migrar a medida que la automigración de VTCS los seleccione. Por lo tanto, se recomienda tener una clase de almacenamiento pero dos clases de gestión para datos de LTR.
El parámetro DELSCR de la sentencia MGMTclas se utiliza para especificar si VSM debe suprimir los VTV reutilizados, donde DELSCR(YES) hace que VSM suprima los VTV reutilizados, lo cual libera espacio del buffer del VTSS y espacio del MVC. Considere la posibilidad de especificar DELSCR(YES) para las clases de gestión de DR y LTR. Si especifica DELSCR(YES), use solamente SYNCVTV de LCM para sincronización de volúmenes reutilizables. Para obtener más información acerca del uso de LCM para gestionar la sincronización de volúmenes reutilizables, consulte la Guía del usuario de LCM.
El proceso de introducción de HSC se ha modificado para la función de almacenamiento de ELS, de modo que cada volumen que se introduce se verifique para determinar si el volumen es un volumen almacenado externamente. Para estos volúmenes almacenados, se realizarán una de dos acciones, en función del campo de fecha de devolución del registro de almacén de CDS:
Si la fecha de devolución ya ha pasado, el volumen se introduce, los metadatos de los volúmenes almacenados a partir del proceso de expulsión se restauran, y el volumen se elimina de los registros de almacén.
Si la fecha de devolución todavía no ha pasado o no se ha establecido una fecha de devolución para el volumen, el volumen se introduce, los metadatos de los volúmenes almacenados a partir del proceso de expulsión se restauran, pero el volumen se deja en los registros de almacén y se expulsa automáticamente durante el siguiente proceso de expulsión. ¿Por qué ocurre esto? Hay varias razones. Las dos razones más comunes son que el volumen se devolvió para algún tipo de proceso de recuperación de datos o que se extrajo el volumen incorrecto del almacén (lo cual ocurre con mucha frecuencia). Independientemente del motivo, el volumen pertenece al almacén y se devolverá a esta ubicación y se restablecerá su estado protegido.
Se debe tener en cuenta que este es el proceso para los volúmenes almacenados en un almacén físico. Para los volúmenes almacenados en una biblioteca remota, el proceso es levemente distinto; consulte "Almacenamiento de DR con MVC en una biblioteca remota."
En un escenario de DR, tiene los objetivos empresariales generales de optimizar el uso del buffer del VTSS, garantizar una migración rápida de datos críticos y, al mismo tiempo, mantener la disponibilidad de los datos.
De acuerdo con este enfoque, se crean volúmenes de DR todos los días; por lo tanto, el procesamiento para moverlos al almacén de DR se ejecuta todos los días para garantizar que los MVC se muevan a un sitio externo de manera segura y se protejan.
Nota:
Todos los VTV creados para fines de DR y todas las cintas nativas, incluida la cinta del archivo de manifiesto creada en "Paso 2: Exportación de los MVC de almacén,", son controlados por el TMS del sitio (en cuanto a la caducidad de los volúmenes). Este proceso se limita al almacenamiento de los MVC relacionados y los volúmenes nativos seleccionados involucrados.
Los MVC solo se pueden asignar a un almacén. Para asignar un volumen a un nuevo almacén, el volumen primero se debe eliminar de una asignación previa a un almacén.
En Paso 7: preparación de MVC almacenados para devolución, comienza el procesamiento periódico, que permite el reciclaje de los MVC de DR que se fragmentaron o se llenaron solo parcialmente en el momento de la creación. Esto se realiza mediante drenajes "lógicos" de los MVC almacenados que usan las copias de los VTV todavía actuales ubicados en los MVC locales. El procesamiento periódico minimiza la cantidad de volúmenes totales del almacén, al mismo tiempo que garantiza que toda la actividad relacionada se reduzca al mínimo, lo cual se logra mediante el uso de criterios de selección adecuados al entorno correspondiente. Después de un drenaje "lógico" correcto del MVC almacenado, se establece la fecha de devolución de ese volumen en el CDS. En el caso de los volúmenes nativos, como las cintas del archivo de manifiesto, los volúmenes que han pasado a tener el estado reutilizable en el TMS se seleccionan y se configuran para devolución. Es posible decidir con qué frecuencia ejecutar el procesamiento periódico (se puede ejecutar diariamente o mensualmente).
Los VTV de almacén de DR se crean mediante una clase de gestión que apunta a dos clases de almacenamiento: una que crea los MVC que quedarán dentro del entorno local y otra que crea los MVC que se almacenan. Por ejemplo:
STOR NAME(DRLOC)ACS(00) MEDIA(STK1RD) STOR NAME(DRVLT1) ACS(00) MEDIA(STK1RD)
Los MVC de almacén se exportan mediante un archivo de parámetros LCM, como se muestra en el siguiente ejemplo.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
NoSync
GracePeriod(3)
;
Action
Export
Control(Serial )
MVC
DSN(DRVAULT.MANIFEST)
Storageclass(DRVLT1)
Vault('DRVLT')
;
En este ejemplo:
La sentencia OPTIONS especifica NOSYNC y NOTMS, porque el almacenamiento no usa información de TMS para almacenamiento y no se necesitan metadatos de TMS.
La sentencia VAULT especifica DRVLT como el almacén de DR.
La sentencia ACTION EXPORT especifica:
Exportar MVC por volser.
Crear un archivo de manifiesto de exportación (DRVAULT.MANIFEST), en este caso, un volumen del ACS que se expulsa y se almacena con los MVC de DR.
Apuntar a la clase de almacenamiento de almacén creada en "Paso 1: Creación de VTV/MVC de almacén."
Definir el almacén de DR (DRVLT) y asignarle MVC no asignados anteriormente al almacén.
Nota:
Los MVC exportados se marcan como de solo lectura durante el procesamiento de la exportación.Puede crear varias clases de almacenamiento de almacén (por ejemplo, para separar los MVC con VTV con distintas fechas de caducidad). Si desea asignar distintas clases de almacenamiento de almacén al mismo almacén, puede hacerlo en una sola sentencia ACTION EXPORT. Por ejemplo, las siguientes sentencias asignan clases de almacenamiento DRVLT1 y DRVLT2 al mismo almacén (DRVLT):
Action
Export
Control(Serial )
MVC
DSN(DRVAULT.MANIFEST)
Storageclass(DRVLT1
DRVLT2)
Vault('DRVLT')
;
Después de crear la cinta de archivo de manifiesto en "Paso 2: Exportación de los MVC de almacén," puede ejecutar un trabajo que copie el juego de datos de control (CDS) del HSC, el catálogo de TMS, el catálogo del sistema y otros juegos de datos significativos de un momento determinado en la cinta del archivo de manifiesto para proporcionar puntos de DR adicionales.
Los MVC de almacén se expulsan mediante un archivo de parámetros LCM, como se muestra en el siguiente ejemplo.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Eject
When(
(inLsm)
and
(VaultName EQ 'DRVLT')
Control(Serial)
Ejmsg('Move to DR Vault')
;
En este ejemplo:
La sentencia OPTIONS especifica NOSYNC y NOTMS, porque el almacenamiento no usa información de TMS para almacenamiento y no se necesitan metadatos de TMS.
La sentencia VAULT especifica DRVLT como el almacén de DR.
La sentencia ACTION EJECT especifica:
Expulsar los MVC asignados a DRVLT; expulsar por volser.
El mensaje de expulsión.
Los volúmenes nativos (incluida la cinta del archivo de manifiesto) se deben expulsar mediante un archivo de parámetros LCM, como el que se muestra en el siguiente ejemplo.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Eject
When(
(InLsm)
and
(DataSetName EQ 'DRVLT.MANIFEST')
and
(TMSScratch EQ False)
)
Control(Serial)
Ejmsg('Move to DR Vault')
;
En este ejemplo:
La sentencia OPTIONS especifica NOSYNC, porque el almacenamiento no usa información de TMS para almacenamiento.
La sentencia VAULT especifica DRVLT como el almacén de DR.
La sentencia ACTION EJECT especifica:
Expulsar la cinta del archivo de manifiesto.
Expulsar los volúmenes nativos no reutilizados por el TMS.
El mensaje de expulsión.
Para crear una lista desplegable, use un archivo de parámetros LCM, como el que se muestra en el siguiente ejemplo.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Report
Volume
Sysout(*)
Title('Return Report')
When(
(VaultName EQ 'DRVLT')
and
(VaultReturnDate LE TODAY)
and
(VaultReturnDate NE MISSING)
)
Column (Serial,
VaultSlot)
;
En este ejemplo:
La sentencia OPTIONS especifica NOSYNC y NOTMS, porque el almacenamiento no usa información de TMS para almacenamiento y no se necesitan metadatos de TMS.
La sentencia VAULT especifica DRVLT como el almacén de DR.
La sentencia REPORT VOLUME crea un informe que muestra los volúmenes del almacén que han llegado a las fechas de devolución asignadas anteriormente. Este es un ejemplo simple; puede agregar más criterios de selección para los volúmenes que desea que se devuelvan.
Nota:
TODAY y MISSING son valores únicos en relación a las fechas. TODAY se convierte a la fecha de ejecución de LCM. MISSING significa que no hay ningún valor para la fecha. En este ejemplo, significa que no se ha establecido ninguna fecha. Ambas condiciones son necesarias, dado que una fecha faltante se vería como Less Than respecto de la fecha actual.
Los pasos 4, 5 y 6 se pueden combinar en un solo paso de trabajo. En algunos casos, el paso 6 se ejecuta periódicamente, por lo general, el día antes de que los volúmenes se devuelvan del almacén.
Los MVC se preparan para devolución mediante un archivo de parámetros LCM, como el que se muestra en el siguiente ejemplo.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Drain
When(
(MVC EQ True)
and
(VaultName EQ 'DRVLT')
and
(MVCVTVCount LE 30)
and
(MVCInUse LE 30)
and
(Days_Since(VaultAssignmentDate) GT 7)
)
Control(MVCVTVCount
Ascending)
Limit(30)
;
En este ejemplo:
La sentencia OPTIONS especifica NOSYNC y NOTMS, porque el almacenamiento no usa información de TMS para almacenamiento y no se necesitan metadatos de TMS.
La sentencia VAULT especifica DRVLT como el almacén de DR.
Para los MVC que actualmente están en el almacén de DR, la sentencia ACTION DRAIN especifica el drenaje de los MCV:
Que tengan menos de 30 VTV.
Que estén en uso menos del 30 % del tiempo.
Que hayan estado en el almacén al menos 7 días.
Que limiten la cantidad de MVC devueltos a un máximo de 30.
El parámetro GracePeriod establece la fecha de devolución en tres días.
Cuando crea un archivo de parámetros para drenar los MVC, necesita equilibrar los ciclos de procesamiento para el drenaje y la necesidad de reciclar MVC fragmentados o parcialmente llenos. Por lo tanto, los parámetros MVCVTVCount, MVCInUse, Days_Since y LIMIT proporcionan los controles para equilibrar estas necesidades.
Los volúmenes nativos se preparan para devolución mediante un archivo de parámetros LCM, como el que se muestra en el siguiente ejemplo.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Return
When(
Not (MVC)
and
(VaultName EQ 'DRVLT')
and
(TMSScratch EQ True)
)
;
En este ejemplo:
La sentencia OPTIONS especifica NOSYNC, porque el almacenamiento no usa información de TMS para almacenamiento.
La sentencia TMS RMM es necesaria para agregar el procesamiento de metadatos de TMS.
La sentencia VAULT especifica DRVLT como el almacén de DR.
La sentencia ACTION VAULT RETURN establece una fecha de devolución (mediante el parámetro GracePeriod) para volúmenes que no son MVC y que están en estado reutilizable en el TMS.
Los volúmenes que aparecen en el informe creado en Paso 6: Creación de una lista desplegable de volúmenes para devolución a partir del almacén se eliminan del almacén de DR y se devuelven al entorno local. Cuando introduce estos volúmenes en el ACS, el HSC verifica si la fecha de devolución del almacén asignada para cada volumen ya ha pasado. Si ya ha pasado, significa que el volumen ha alcanzando la fecha de devolución programada y se elimina del almacén. A continuación, los MVC devueltos se convierten en elegibles para migración, y los volúmenes nativos se convierten en reutilizables en el CDS la próxima vez que se produce el procesamiento de SYNC del LCM. Si la fecha de devolución del almacén no ha pasado, el volumen se expulsa mediante "Paso 4: Expulsión de los MVC de almacén."
Si lo desea, puede combinar los pasos 7 y 8 en un solo archivo de parámetros LCM, como se muestra en el siguiente ejemplo:
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Drain
When(
(MVC EQ True)
and
(VaultName EQ 'DRVLT')
and
(MVCVTVCount LE 30)
and
(MVCInUse LE 30)
and
(Days_Since(VaultAssignmentDate) GT 7)
)
Control(MVCVTVCount
Ascending)
Limit(30)
;
Action
Vault
Return
When(
Not (MVC)
and
(VaultName EQ 'DRVLT')
and
(TMSScratch EQ True)
)
;
Algunos sitios pueden optar por usar un proceso de varias semanas en el que el procesamiento de DR incluya una copia de seguridad semanal y completa de volúmenes de datos críticos, seguida de copias de seguridad incrementales durante los seis días siguientes. Mediante el proceso de almacenamiento externo se mueven los volúmenes fuera del sitio el día de la creación. Este proceso supone un ciclo de cuatro semanas durante el cual los datos de DR se mantienen completos y fuera del sitio hasta que el comienzo de la cuarta semana. Se debe tener en cuenta que el único cambio entre Almacenamiento básico de DR con MVC y el proceso de varias semanas es la diferencia en el criterio de selección para los pasos 7 y 8, como se describe a continuación. Esta acción se realiza configurando las fechas de caducidad, de modo que los VTV de almacén en los MVC asociados y las cintas del archivo de manifiesto (y todas las demás cintas nativas involucradas) caduquen en la fecha especificada 22 días después de la creación.
La cronología de varias semanas se desarrolla como se indica a continuación:
Día 1: copias de seguridad de volúmenes completas (caducan el vigésimo segundo día).
Día 2: copia de seguridad incremental n.º 1 (caduca el vigésimo segundo día).
Día 3: copia de seguridad incremental n.º 2 (caduca el vigésimo segundo día).
Día 4: copia de seguridad incremental n.º 3 (caduca el vigésimo segundo día).
Día 5: copia de seguridad incremental n.º 4 (caduca el vigésimo segundo día).
Día 6: copia de seguridad incremental n.º 5 (caduca el vigésimo segundo día).
Día 7: copia de seguridad incremental n.º 6 (caduca el vigésimo segundo día).
Días 8 a 21: los volúmenes permanecen fuera del sitio.
Día 22: las copias de seguridad y las cintas del archivo de manifiesto de los días 1 a 7 caducan, y los VTV se reutilizan en CDS mediante el proceso LCM VTVSYNC. Los MVC se drenan mediante el siguiente parámetro en el criterio de selección para Paso 7: preparación de MVC almacenados para devolución y "Paso 8: Preparación de volúmenes nativos almacenados para devolución."
DAYS SINCE (VaultAssignmentDate) GT 15
La fecha de devolución para los MVC drenados y las cintas del archivo de manifiesto se establece para el vigésimo quinto día.
Nota:
Todos los MVC asignados al almacén durante los primeros siete días del ciclo se drenan. Si la fecha de caducidad de los VTV se estableció correctamente, no debe haber VTV actuales en este momento y el proceso de drenaje lógico se debe ejecutar rápidamente. La escritura de VTV actuales en un nuevo MVC se podría producir debido al establecimiento de una fecha de caducidad incorrecta.Días 23 y 24: los volúmenes permanecen fuera del sitio.
Día 25: los volúmenes almacenados del día 1 al 7 se devuelven y se eliminan del estado almacenado, y quedan disponibles para reutilización.
Día 29: se repite el ciclo.
Nota:
Algunos sitios pueden optar por dejar las copias de seguridad de volúmenes completas fuera del sitio y por mantener las copias de seguridad incrementales en el sitio. En este caso, los MVC incrementales, el archivo de manifiesto relacionado y los volúmenes nativos se deben colocar en un contenedor que se debe cerrar con llave y no se debe volver a abrir hasta su devolución el día 25. Para ese momento, todos los volúmenes creados el día 1 deben haber caducado.En este proceso, en lugar de almacenar volúmenes en un almacén físico, los volúmenes se almacenan en una biblioteca remota (ACS). Este proceso es similar al proceso que se describe en Almacenamiento básico de DR con MVC, con las siguientes excepciones:
Pasos 1 a 3: sin cambios.
Paso 4: se elimina porque no se realizan expulsiones de MVC almacenados.
Paso 5: al igual que en el paso 4, los volúmenes nativos no se expulsan. En cambio, una sentencia Action Vault Assign asigna volúmenes nativos al almacén mediante los mismos criterios de selección que se hubieran utilizado para la realización y la expulsión de estos volúmenes nativos, como se muestra en el siguiente ejemplo.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Assign
Vault('DRVLT')
When(
(InLsm)
and
(DataSetName EQ 'DRVLT.MANIFEST')
and
(TMSScratch EQ False)
)
;
Paso 6: se elimina porque no se vuelven a introducir volúmenes.
Paso 7: sin cambios.
Nota:
Dado que el procesamiento del drenaje se produce en la biblioteca remota, los drenajes se ejecutan más eficazmente que el procesamiento de drenaje lógico para los volúmenes de un almacén manual.Paso 8: sin cambios.
Paso 9: en el proceso básico, la asignación del almacén se elimina mediante el proceso de introducción, que no ocurre en el escenario de la biblioteca remota. Para eliminar el volumen almacenado, use la sentencia Action Vault Release. Los volúmenes almacenados que se liberarán se seleccionan por Vault Name y Return Date, como se realizó anteriormente para generar la lista desplegable. La sentencia Action Vault Release solo procesa volúmenes almacenados cuya Return Date ya haya pasado.
A continuación, se muestra un ejemplo de la sentencia Action Vault Release.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Release
When(
(VaultName EQ 'DRVAULT')
and
(VaultReturnDate LE TODAY)
and
(VaultReturnDate NE MISSING)
)
;
El proceso para usar los MVC para alojar MVC de retención a largo plazo (LTR) es básicamente el mismo que se describe en el proceso básico para recuperación ante desastres, en "Almacenamiento básico de DR con MVC". Las dos consideraciones principales para el uso de LTR son las siguientes:
El movimiento al almacén, Paso 2: Exportación de los MVC de almacén a "Paso 5: Expulsión de volúmenes nativos (incluida la cinta del archivo de manifiesto)," puede no ser una función diaria, de modo que más volúmenes de LTR se llenen completamente antes de ser almacenados.
Los VTV de LTR no caducan por períodos de tiempo prolongados; por lo tanto, el proceso periódico descrito puede producirse únicamente a intervalos más prolongados. Seguirán existiendo MVC de LTR que estén solo parcialmente llenos; por lo tanto, en algún momento, los MVC parcialmente llenos con menos VTV y bajo uso de MVC se deberán procesar para que los VTV de los MVC parcialmente llenos se consoliden en menos MVC de LTR.
En algún momento del futuro, puede existir la necesidad de realizar drenajes lógicos de los MVC de LTR para mover los datos archivados a nuevos medios. El proceso básico realiza fácilmente esa actividad, simplemente, mediante las elecciones apropiadas de los criterios de selección y la limitación de la cantidad de MVC de LTR procesados a la vez. Con cada ejecución, los VTV actuales se mueven a los medios nuevos, los MVC se mueven al almacén y los MVC drenados lógicamente se devuelven para reutilización o destrucción.
Es posible que muchos sitios requieran la eliminación de volúmenes específicos del entorno automatizado y que necesiten almacenar eficazmente estos volúmenes localmente en bastidores del entorno local. Esta necesidad puede surgir a partir de actividades tales como retirar los volúmenes del uso y a partir del deseo de mantener los volúmenes disponibles durante algún tiempo. Varios almacenes locales (planta) se pueden definir con volúmenes específicos que se envían a distintos almacenes, pero solo un almacén local (planta) se puede definir como un almacén "predeterminado". A todos los volúmenes colocados en un almacén local/planta se les asigna automáticamente una fecha de devolución a partir la fecha actual. Esto permite que estos volúmenes se devuelvan al entorno automatizado y se supriman de la asignación de su almacén sin necesidad de realizar ninguna otra acción.
En el siguiente ejemplo, se muestra un ejemplo de un archivo de parámetros LCM mediante el cual se expulsan volúmenes específicos a un almacén de planta.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('FLOOR')
Default
;
Action
Eject
When(
(InLsm EQ True)
and
(DaysSinceReference GT 100)
and
(MVC EQ False)
and
Not
(DataSetName Matches 'HMIG.**')
)
Control(
VaultSlot
Ascending
)
Ejmsg('Move to Floor Vault')
;
Manage
ACSID(00)
Numfree(500)
;
En este ejemplo:
La sentencia OPTIONS especifica NOSYNCH, porque el almacenamiento no usa información de TMS para almacenamiento.
La sentencia TMS RMM es necesaria para agregar el procesamiento de metadatos de TMS.
La sentencia VAULT especifica FLOOR como el almacén de planta predeterminado.
La sentencia ACTION EJECT especifica la expulsión al almacén de planta de los volúmenes:
Que estén en el LSM.
Que no se hayan consultado durante más de 100 días.
Que no sean MVC.
Que tengan una máscara de nombre de juego de datos HMIG.**.
La sentencia ACTION EJECT también especifica:
Procesar los volúmenes en orden de volser ascendente.
Expulsar por números de ranura de TMS.
El mensaje de expulsión.
La sentencia MANAGE especifica:
Gestionar volúmenes en ACS 00.
Garantizar 500 celdas libres en el ACS.