Capítulo 4 Modificación de un tipo de recurso

Este capítulo describe los conceptos necesarios para modificar un recurso. También se incluye información sobre los medios que permiten actualizar un recurso a un administrador del clúster.

En este capítulo se tratan los temas siguientes:

• Información general sobre la modificación de un tipo de recurso

• Configuración del contenido de un archivo de Registro del tipo de recurso

• Acciones posteriores a la actualización por parte del administrador del clúster

• Implementación del código del supervisor del tipo de recurso

• Requisitos de instalación y de paquetes

• Documentación necesaria para un tipo de recurso modificado

Información general sobre la modificación de un tipo de recurso

Los administradores del clúster deben poder realizar las siguientes tareas:

• Instalar y registrar una nueva versión de un tipo de recurso existente

• Permitir el registro de varias versiones de un determinado tipo de recurso

• Actualizar un recurso existente a una nueva versión sin necesidad de eliminar y volver a crear el recurso

El tipo de recurso que desea actualizar recibe el nombre de tipo de recurso habilitado para actualización . Entre los elementos de un tipo de recurso existente que puede cambiar, se incluyen:

• Los atributos de las propiedades de tipo de recurso

• El conjunto de las propiedades de recursos declaradas, incluidas las propiedades de extensión y estándar

• Loa atributos de propiedades de recursos como, por ejemplo, default, min, max, arraymin, arraymax o tunability

• El conjunto de métodos declarados

• La implementación de métodos o supervisores

No es necesario que modifique un tipo de recurso al modificar el código de la aplicación.

Debe conocer los requisitos para proporcionar las herramientas que permiten a un administrador del clúster actualizar un tipo de recurso. Este capítulo le indica los conceptos que debe conocer para configurar estas herramientas.

Configuración del contenido de un archivo de Registro del tipo de recurso

Nombre del tipo de recurso

El nombre del tipo de recurso está formado por tres componentes, las propiedades especificadas en el archivo RTR como vendor-id, resource-type y rt-version. El comando scrgadm inserta los delimitadores de punto, y punto y coma para crear el nombre del tipo de recurso.

vendor-id.resource-type:rt-version

El prefijo vendor-id sirve para distinguir entre dos archivos de registro con el mismo nombre proporcionados por diferentes compañías. Para garantizar la exclusividad de vendor-id, utilice el símbolo del valor de la compañía al crear el tipo de recurso. rt-version distingue entre varias versiones registradas (actualizaciones) del mismo tipo de recurso básico.

Para obtener el nombre completo del tipo de recurso, escriba el siguiente comando:

# scha_resource_get -O Type -R resource-name -G resource-group-name

Los nombres del tipo de recurso registrados antes de Sun Cluster 3.1 siguen usando la sintaxis siguiente:

vendor-id.resource-type

El formato de los nombres de tipos de recursos se describe en Formato de los nombres de tipos de recursos .

Especificación de las directivas #$upgrade y #$upgrade_from

Para garantizar que el tipo de recurso que se va a modificar esté habilitado para actualización, incluya la directiva #$upgrade en el archivo RTR del tipo de recurso. A continuación de la directiva #$upgrade, añada el valor cero o más directivas #$upgrade_from para cada versión anterior del tipo de recurso que desee admitir.

Las directivas #$upgrade y #$upgrade_from deben aparecer entre las secciones de declaraciones de propiedades del tipo de recurso y las declaraciones de recursos en el archivo RTR. Consulte la página de comando man rt_reg(4).

Ejemplo 4–1 Directiva #$upgrade_from en un archivo RTR

#$upgrade_from   "1.1"   WHEN_OFFLINE
#$upgrade_from   "1.2"   WHEN_OFFLINE
#$upgrade_from   "1.3"   WHEN_OFFLINE
#$upgrade_from   "2.0"   WHEN_UNMONITORED
#$upgrade_from   "2.1"   ANYTIME
#$upgrade_from   ""      WHEN_UNMANAGED

El formato de la directiva #$upgrade_from es el siguiente:

#$upgrade_from version tunability

version

RT_version. Si un tipo de recurso no tiene una versión o dispone de una versión diferente a la definida con anterioridad en el archivo RTR, especifique la cadena vacía (“”).

tunability

Las condiciones en las que un administrador del clúster puede actualizar la propiedad RT_version especificada o el momento en que debe hacerlo.

Utilice los siguientes valores de capacidad de ajuste en las siguientes directivas #$upgrade_from:

ANYTIME

Utilice este valor cuando no haya ninguna restricción para el momento en que el administrador del clúster puede actualizar el recurso. Los recursos pueden estar completamente en línea durante la actualización.

WHEN_UNMONITORED

Utilice este valor cuando los métodos de la nueva versión del tipo de recurso sean los siguientes:

• Los métodos Update, Stop, Monitor_check y Postnet_stop son compatibles con los métodos de inicio de la versión anterior del tipo de recurso (Prenet_stop y Start)

• El método Fini es compatible con las versiones anteriores de Init.

El administrador del clúster sólo debe detener el programa del supervisor de recursos antes de la actualización.

WHEN_OFFLINE

Utilice este valor cuando el método Update, Stop, Monitor_check o Postnet_stop de la nueva versión del tipo de recurso presente las siguiente características:

• Compatible con el método Init de una versión anterior

• Incompatible con los métodos de inicio de la versión anterior del tipo de recurso (Prenet_stop y Start)

El administrador del clúster debe poner fuera de línea el recurso antes de efectuar la actualización.

WHEN_DISABLED

Similar a WHEN_OFFLINE. Sin embargo, el administrador del clúster debe inhabilitar el recurso antes de realizar la actualización.

WHEN_UNMANAGED

Utilice este valor cuando el método Fini de la nueva versión del tipo de recurso sea incompatible con el método Init de la versión anterior. El administrador del clúster debe pasar el grupo de recursos existente al estado no administrado antes de efectuar la actualización.

Si una versión del tipo de recurso no aparece en la lista de directivas #$upgrade_from directives, RGM impone de forma predeterminada la capacidad de ajuste WHEN_UNMANAGED en esa versión.

AT_CREATION

Utilice este valor para impedir que se actualicen los recursos existentes a la nueva versión del tipo de recurso. El administrador del clúster debe eliminar un recurso y crearlo de nuevo.

Cambio de RT_version en un archivo RTR

Sólo se debe cambiar la propiedad RT_version en un archivo RTR cuando se modifique el contenido de dicho archivo. Seleccione un valor para esta propiedad que indique claramente que esta versión del tipo de recurso es la más reciente.

No incluya los siguientes caracteres en la cadena de RT_version del archivo RTR o fallará el registro del tipo de recurso:

• Espacio

• Ficha

• Barra diagonal (/)

• Barra diagonal inversa (\)

• Asterisco (*)

• Signo de interrogación (?)

• Coma (,)

• Punto y coma (;)

• Corchete izquierdo ([)

• Corchete derecho (])

La propiedad RT_version, que era opcional en Sun Cluster 3.0, es obligatoria desde Sun Cluster 3.1.

Nombres de los tipos de recursos en versiones anteriores de Sun Cluster

Los nombres de tipos de recursos de Sun Cluster 3.0 no contienen el sufijo de versión, como se muestra a continuación:

vendor-id.resource-type

Un tipo de recurso registrado originalmente en Sun Cluster 3.0 sigue teniendo un nombre de acuerdo con esta sintaxis, aunque el administrador del clúster actualice el software de clústeres a la versión 3.1 o posteriores. Del mismo modo, un tipo de recurso a cuyo archivo RTR le falte la directiva #$upgrade recibe un nombre con formato de Sun Cluster 3.0 (sin sufijo de versión) si el archivo RTR se ha registrado en un clúster que esté ejecutando, como mínimo, la versión 3.1 de Sun Cluster.

El administrador del clúster puede registrar los archivos RTR mediante la directiva #$upgrade o #$upgrade_from en Sun Cluster 3.0. Sin embargo, no se admite la actualización de los recursos existentes a los nuevos tipos de recurso en Sun Cluster 3.0.

Acciones posteriores a la actualización por parte del administrador del clúster

A continuación se muestran las acciones que debe realizar el administrador del clúster o lo que ocurre al actualizar un tipo de recurso:

• Si los atributos de propiedades del recurso existente cumplen las condiciones de validación de la nueva versión del tipo de recurso, el administrador del clúster debe proporcionar los valores correctos. El administrador del clúster debe realizar esta acción en las situaciones siguientes:

  • Cuando la nueva versión del tipo de recurso no tenga un valor predeterminado y utilice una propiedad no declarada en la versión anterior.

  • Cuando el recurso existente utilice una propiedad cuyo valor no se haya declarado en la nueva versión o no sea válido. Las propiedades que no se hayan declarado en la nueva versión de un tipo de recurso se eliminarán del recurso.

• Cualquier intento de realizar una actualización desde una versión del tipo de recurso no compatible fallará.

• Después de la actualización, los recursos heredan los atributos de propiedades de recurso de la nueva versión del tipo de recurso.

• Si cambia el valor predeterminado de un tipo de recurso en el archivo RTR, los recursos existentes heredarán este nuevo valor predeterminado. Este valor se hereda, incluso aunque la propiedad se declare sólo con las opciones de capacidad de ajuste AT_CREATION o WHEN_DISABLED. Una propiedad del mismo tipo creada por el administrador del clúster también hereda este valor predeterminado. Sin embargo, si el administrador del clúster especifica un nuevo valor para la propiedad, el nuevo valor predeterminado anula el que se había especificado en el archivo RTR.

Los recursos creados en Sun Cluster 3.0 no heredan los atributos de propiedades predeterminados del tipo de recurso al actualizar a una versión posterior de Sun Cluster. Esta limitación sólo se aplica a los clústeres de Sun Cluster 3.1 actualizados a partir de los clústeres de Sun Cluster 3.0. El administrador del clúster puede superar esta limitación si especifica los valores de las propiedades y, por lo tanto, anula los valores predeterminados.

Implementación del código del supervisor del tipo de recurso

El administrador del clúster puede registrar un tipo de recurso habilitado para actualización en Sun Cluster 3.0. Sin embargo, Sun Cluster registra el nombre del tipo de recurso sin el sufijo de versión. Para que se ejecute correctamente en Sun Cluster 3.0 y Sun Cluster 3.1, el supervisor de este tipo de recurso debe ser capaz de administrar las dos convenciones de nomenclatura.

vendor-id.resource-type:rt-version
vendor-id.resource-type

El formato de los nombres de tipos de recursos se describe en Formato de los nombres de tipos de recursos .

El administrador del clúster no puede registrar la misma versión del tipo de recurso dos veces con nombres diferentes. Para habilitar el código del supervisor y determinar el nombre correcto, llame a estos comandos en el código:

scha_resourcetype_get -O RT_VERSION -T VEND.myrt
scha_resourcetype_get -O RT_VERSION -T VEND.myrt:vers

A continuación, compare los valores de salida con vers. Sólo uno de estos comandos se ejecuta satisfactoriamente para el valor específico de vers.

Requisitos de instalación y de paquetes

Tenga en cuenta los siguientes dos puntos al determinar los requisitos de instalacion y de paquetes para los paquetes de tipos de recursos:

• Cuando se registra un nuevo tipo de recurso, se debe poder acceder a su archivo RTR en el disco.

• Al crear un nuevo tipo de recurso, todos los nombres de ruta de métodos declarados y el programa del supervisor de este nuevo tipo deben residir en el disco y ser ejecutables. El método y los programas del supervisor antiguos deben permanecer en su lugar mientras el recurso se esté utilizando.

Para determinar el paquete correcto que debe utilizarse, tenga en cuenta las siguientes preguntas:

• ¿Cambia el archivo RTR?

• ¿Cambian el valor predeterminado o la capacidad de ajuste de una propiedad?

• ¿Cambian los valores min o max de una propiedad?

• ¿Agrega o elimina propiedades esta actualización?

• ¿Cambia el código del supervisor?

• ¿Cambia el código del método?

• ¿Son compatibles los nuevos métodos, el código del supervisor, o ambos, con las versiones anteriores?

Las respuestas a estas preguntas le ayudarán a determinar el paquete correcto que debe utilizarse para el nuevo tipo de recurso.

Antes de modificar el archivo RTR

No es necesario que cree un nuevo método o código del supervisor al modificar un tipo de recurso. Por ejemplo, puede cambiar únicamente el valor predeterminado o la capacidad de ajuste de una propiedad del recurso. En ese caso, al no cambiar el código del método, no es necesario un nuevo nombre de ruta válido al archivo RTR legible.

Si no necesita volver a registrar el tipo de recurso antiguo, el nuevo archivo RTR puede sobrescribir la versión anterior. De lo contrario, incluya el nuevo archivo RTR en la nueva ruta.

Si la actualización cambia el valor predeterminado o la capacidad de ajuste de una propiedad, utilice el método Validate para que la nueva versión del tipo de recurso compruebe si los atributos de propiedades existentes son válidos para el nuevo tipo de recurso. Si no lo son, el administrador del clúster puede cambiar las propiedades de un recurso existente para especificar los valores correctos. Si la actualización cambia los atributos min, max o type de una propiedad, el comando scrgadm valida automáticamente estas restricciones cuando el administrador del clúster actualice el tipo de recurso.

Si la actualización agrega una nueva propiedad o elimina una antigua, es probable que deba cambiar los métodos de rellamada o el código del supervisor.

Cambio del código del supervisor

Si sólo se cambia el código del supervisor de un tipo de recurso, la instalación del paquete puede sobrescribir los binarios del supervisor.

Cambio del código del método

Si sólo cambia el código del método en un tipo de recurso, debe determinar si el nuevo código es compatible con el antiguo. La respuesta a esta cuestión determina si se debe almacenar el nuevo código del método en una nueva ruta o si se pueden sobrescribir los métodos antiguos.

Si se pueden aplicar los nuevos métodos Stop, Postnet_stop y Fini (en caso de haberse declarado) inicializados o iniciados por las versiones antiguas Start, Prenet_stop o Init, estos métodos pueden sobrescribirse con los nuevos.

Si, por el contrario, la aplicación de un nuevo valor predeterminado a una propiedad provoca que un método como, Stop, Postnet_stop, o Fini falle, el administrador del clúster debe restringir convenientemente el estado del recurso al actualizar el tipo de recurso.

Se puede permitir al administrador del clúster restringir el estado del recurso cuando se limita la capacidad de ajuste de la propiedad Type_version para actualizarlo.

Una posible forma de actualizar un paquete consiste en incluir todas las versiones anteriores de un tipo de recurso compatible aún con dicho paquete. Este enfoque permite sustituir la antigua versión del paquete por la nueva, sin necesidad de sobrescribir o eliminar las rutas anteriores a los métodos. Debe decidir el número versiones anteriores que se admitirán.

Selección del esquema de paquetes que se utilizará

La siguiente tabla resume los esquemas de paquetes que se utilizarán para los nuevos tipos de recursos.

Documentación necesaria para un tipo de recurso modificado

Las instrucciones que indican al administrador del clúster cómo actualizar un tipo de recurso se encuentran en Upgrading a Resource Type de Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Para permitir que el administrador del clúster actualice un tipo de recurso modificado, proporcione estas instrucciones con información adicional, como se describe en esta sección.

Normalmente, al crear un tipo de recurso, se debe proporcionar la documentación que:

• Describe las propiedades que se deben agregar, cambiar o eliminar.

• Describe cómo lograr que las propiedades se ajusten a los nuevos requisitos.

• Indica las limitaciones de capacidad de ajuste de los recursos.

• Especifica los nuevos atributos de propiedades predeterminados.

• Informa al administrador del clúster que puede establecer las propiedades de recursos existentes en sus valores correctos si es necesario.

Información sobre las acciones necesarias antes de instalar una actualización

Explique al administrador del clúster las acciones que debe realizar antes de instalar el paquete de actualización en un nodo, como se indica a continuación:

• Si el paquete de actualización sobrescribe los métodos existentes, indíquele al administrador del clúster que reinice el nodo en modo sin clúster.

• Si el paquete de actualización sólo actualiza el código del supervisor, pero no modifica el código del método, indíquele al administrador que siga ejecutando el nodo en el modo con clúster. También debe pedirle al administrador del clúster que desactive la supervisión de todos los tipos de recursos.

• Si el paquete de actualización sólo actualiza el archivo RTR, pero no modifica el código del método ni del supervisor, indíquele al administrador que siga ejecutando el nodo en el modo con clúster. También debe pedirle al administrador del clúster que mantenga activada la supervisión de todos los tipos de recursos.

Información sobre cuándo actualizar los recursos

Explique al administrador del clúster cuándo puede actualizar los recursos a una nueva versión del tipo de recurso. Las condiciones en las que el administrador puede actualizar el tipo de recurso dependen de la capacidad de ajuste de la directiva #$upgrade_from para cada versión del recurso del archivo RTR, como se indica a continuación:

• En cualquier momento (ANYTIME)

• Sólo cuando se supervisa el recurso (WHEN_UNMONITORED)

• Sólo cuando el recurso está fuera de línea (WHEN_OFFLINE)

• Sólo cuando el recurso está inhabilitado (WHEN_DISABLED)

• Sólo cuando se administra el grupo de recursos (WHEN_UNMANAGED )

Ejemplo 4–2 Cómo #$upgrade_from define el momento en el que el administrador del clúster puede realizar la actualización

Este ejemplo muestra cómo afecta la directiva #$upgrade_from a las condiciones en las que el administrador del clúster puede actualizar un recurso a una nueva versión del tipo de recurso.

#$upgrade_from   "1.1"   WHEN_OFFLINE
#$upgrade_from   "1.2"   WHEN_OFFLINE
#$upgrade_from   "1.3"   WHEN_OFFLINE
#$upgrade_from   "2.0"   WHEN_UNMONITORED
#$upgrade_from   "2.1"   ANYTIME
#$upgrade_from   ""      WHEN_UNMANAGED

Información sobre los cambios realizados en las propiedades de recursos

Describa los cambios que ha realizado en el tipo de recursos que requieren que el administrador del clúster modifique las propiedades de los recursos existentes al realizar la actualización. Entre los posibles cambios que puede realizar, se incluyen:

• El cambio de la configuración predeterminada de las propiedades del tipo de recurso

• La inclusión de nuevas propiedades de extensión del tipo de recurso

• La eliminación de propiedades existentes del tipo de recurso

• Los cambios realizados en el conjunto de propiedades estándar declaradas para el tipo de recurso

• Los cambios en los atributos de propiedades de recursos como, por ejemplo, min, max, arraymin, arraymax, default y tunability

• Los cambios realizados en el conjunto de métodos declarados

• Los cambios en la implementación de métodos o en el supervisor de fallos