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
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.
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 .
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).
#$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
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 (“”).
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:
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.
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.
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.
Similar a WHEN_OFFLINE. Sin embargo, el administrador del clúster debe inhabilitar el recurso antes de realizar la actualización.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
La siguiente tabla resume los esquemas de paquetes que se utilizarán para los nuevos tipos de recursos.
Tabla 4–1 Selección del esquema de paquete que se utilizara
Tipo de cambio |
Valor de capacidad de ajuste |
Esquema de paquetes |
---|---|---|
Realice únicamente cambios en las propiedades del archivo RTR. |
ANYTIME |
Envíe sólo el nuevo archivo RTR. |
Actualice los métodos. |
ANYTIME |
Incluya los métodos actualizados en una ruta diferente a las de los métodos antiguos. |
Instale el nuevo programa del supervisor. |
WHEN_UNMONITORED |
Sobrescriba únicamente la versión anterior del supervisor. |
Actualice los métodos. Los nuevos métodos Update y Stop son incompatibles con los métodos Start. |
WHEN_OFFLINE |
Incluya los métodos actualizados en una ruta diferente a las de los métodos antiguos. |
Actualice los métodos y agregue las nuevas propiedades al archivo RTR. Los nuevos métodos requieren nuevas propiedades. Se pretende permitir que el grupo de recursos que contiene el recurso permanezca en línea, pero impedir que el propio recurso esté en línea cuando el estado del grupo se cambia de fuera de línea a en línea en un nodo. |
WHEN_DISABLED |
Sobrescribir las versiones anteriores de los métodos. |
Actualice los métodos y agregue las nuevas propiedades al archivo RTR. Los nuevos métodos no requieren nuevas propiedades. |
ANYTIME |
Sobrescriba las versiones anteriores de los métodos. |
Actualice los métodos. El nuevo método Fini es incompatible con el método Init antiguo. |
WHEN_UNMANAGED |
Incluya los métodos actualizados en una ruta diferente a las de los métodos antiguos. |
Actualice los métodos. No se realizan cambios en el archivo RTR. |
No se aplica. No se realizan cambios en el archivo RTR. |
Sobrescribir las versiones anteriores de los métodos. Como no se ha realizado ningún cambio en el archivo RTR, no es necesario registrar o actualizar el recurso. |
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.
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.
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 )
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
Versión |
Momento en el que el administrador del clúster puede actualizar un recurso |
---|---|
1.1, 1.2 ó 1.3 |
Sólo cuando el recurso está fuera de línea |
2.0 |
Sólo cuando no se supervisa el recurso |
2.1 |
En cualquier momento |
Todas las demás versiones |
Sólo cuando no se supervisa el grupo 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