Requisito network capability, Requisito raid level, Requisito resource existence – HP Software HP Matrix Operating Environment Manual del usuario

Página 30: Requisito service deactivation policy

Advertising
background image

3.

Si no se especifican grupos Host de ningún tipo, los servicios coincidentes se configurarán
para ser inaccesibles para todos los hosts (sin enmascarar, sin asignar y sin división de zonas).

4.

No se admite la combinación de grupos Host con Pre-presented=TRUE y
Pre-presented=FALSE

.

Requisito Network Capability

El requisito Network Capability especifica las capacidades que un servicio coincidente debe
poder realizar después de su aprovisionamiento. Si no se especifica una capacidad de red como
se requiere, la capacidad del servicio aprovisionado después del aprovisionamiento es opcional.
Por ejemplo, un requisito Network Capability con un valor de “Zonificación automatizada”
coincide únicamente con redes que son capaces de realizar la zonificación automatizada.

Requisito RAID Level

El requisito RAID Level especifica el nivel de RAID de volúmenes que coinciden con este requisito.
Los valores de nivel de RAID representan los conceptos generales de cada nivel de RAID, por
ejemplo, las características de eficiencia de espacio y de redundancia. El verdadero nivel de RAID
escogido en el dispositivo se determina mediante una asignación de los conceptos generales a
la implementación del RAID en el array.

Requisito Resource Existence

El requisito Resource Existence es un requisito del momento del aprovisionamiento solamente,
que coincide con recursos que ya existen, en vez de hacerlo con recursos que podrían crearse.
El único recurso con clase reconocida es la clase de recurso Volumen, dado que es el único tipo
de recurso que se puede crear en SPM en este momento. El uso de este requisito con la aplicación
“No debe realizarse” especifica que los volúmenes coincidentes deben crearse mediante el
aprovisionamiento a petición y no serán recursos prexistentes (aprovisionados previamente).

Requisito Service Deactivation Policy

El requisito Service Deactivation Policy especifica las acciones que deberán realizarse
para desactivar el servicio. Las directivas disponibles son:

No Action

: después de la desactivación del servicio, no se realiza ninguna acción. La

zonificación de SAN, los datos del volumen y la presentación del volumen se dejan como
estaban. Tenga en cuenta que el servidor que consume el almacenamiento aún puede acceder
a este después de la eliminación del servicio.

Quarantine Resources

: después de la desactivación del servicio, el volumen dentro del

servicio se pondrá en cuarentena para evitar el acceso del servidor, lo que garantiza que
los servidores ya no puedan leer ni escribir datos, pero el volumen y los datos se conservan
en el array. El enmascaramiento y la asignación de volúmenes se elimina, y la zonificación
de SAN se elimina del SAN. El volumen de almacenamiento se pone en estado de cuarentena
para que solicitudes futuras en SPM no lo aprovisionen. Mover los datos a un archivo
apropiado antes de devolver el volumen a un estado habilitado o eliminarlo manualmente es
responsabilidad del administrador de almacenamiento.

Destroy Data

: después de la desactivación del servicio, el volumen de almacenamiento

se elimina, lo que destruirá los datos que contiene y dejará disponible la capacidad para el
aprovisionamiento por parte de servicios de datos en el futuro. La zonificación de SAN
realizada también se elimina. Esta directiva únicamente debe utilizarse en situaciones con
procesos de archivado y donde todos los datos necesarios se hayan guardado antes de la
eliminación del servicio.

Recycle

: después de la desactivación del servicio, si la presentación del volumen de

almacenamiento se modificó, se cancela la presentación del volumen. Si se creó el volumen
de almacenamiento, este se eliminará (lo que destruirá los datos que contiene) y la capacidad

30

Directiva del servicio de almacenamiento

Advertising