Direccionamiento de carga de trabajo de recursos

Utilice este tema para obtener más información sobre cómo habilitar el direccionamiento de recursos en el entorno.

[z/OS]
En un sistema z/OS, hay dos maneras de realizar el direccionamiento de recursos:
  • Configurar un recurso alternativo.
  • Configurar una notificación de acción.
[AIX Solaris HP-UX Linux Windows]

En sistemas distribuidos, puede habilitar el direccionamiento de recursos sólo configurando un recurso alternativo.

Configurar un recurso alternativo

Un origen de datos y una fábrica de conexiones pueden migrar tras error y realizar la retrotracción automáticamente cuando se alcanza un valor de umbral de anomalía especificado o predeterminado. Cuando se produce la migración tras error, la aplicación pasa de utilizar el recurso primario a utilizar el recurso alternativo. La retrotracción se produce cuando la aplicación pasa de utilizar el recurso alternativo a utilizar el recurso primario.

El recurso alternativo se crea de la misma forma que se crean otras fábricas de conexiones u orígenes de datos. La configuración del recurso alternativo debe duplicar la configuración del recurso primario. Por ejemplo, la configuración de seguridad del recurso alternativo y la configuración de recursos primarios, respecto a la aplicación y a los recursos, deben duplicarse entre sí de modo que la aplicación y base de datos puedan acceder a los datos necesarios. Una vez que se ha creado el recurso alternativo, puede cambiar los valores de la base de datos necesarios para la configuración de fondo del recurso alternativo. Si el recurso alternativo no es compatible, es probable que la migración tras error falle. Si los recursos no son compatibles, se producen los siguientes errores: tablas o campos que no existen, un registro esperado no existe y existen errores inesperados de recursos. Como una opción de prueba, antes de que se configure el recurso alternativo en el origen de datos primario, puede probar la aplicación cambiando el nombre JNDI en la aplicación del nombre JNDI primario al nombre JNDI alternativo.

Cuando se utiliza el recurso primario, el recurso alternativo se pone en pausa. Antes de que el recurso alternativo se ponga en pausa, el recurso alternativo puede estar disponible antes de que se utilice el primario. No se recomienda la utilización del recurso alternativo antes de que este esté en pausa, a menos que haya una razón especial por la que sea necesario acceder al recurso alternativo antes de al recurso primario. Un ejemplo de una razón especial es la prueba de la aplicación para la compatibilidad.

Un recurso alternativo no puede utilizarse como un primario. Cuando se utiliza la característica de migración tras error con adaptadores de recursos no relacionales que tienen programas de fondo que también dan soporte a la migración tras error, debe verificar que la migración tras error no esté configurada para estos programas de fondo. La migración tras error funciona con adaptadores de recursos no relacionales que tienen un objeto ManagedConnection que implementa un método testConnection. Se utiliza el método testConnection para emitir ping a los recursos alternativos y primarios para obtener un resultado satisfactorio antes de volver a establecer una conexión al recurso disponible actualmente. Si el adaptador de recursos no implementa un método testConnection o testConnection genera un error javax.resource.NotSupportedException, la característica de migración tras error está inhabilitada.

Para adaptadores de recursos que no cumplen el requisito de testConnection, se puede utilizar la migración tras error parcial. Debe invertir manualmente la migración mediante Mbeans al recurso primario cuando el recurso primario está disponible. La migración tras error parcial se puede habilitar estableciendo la propiedad enablePartialResourceAdapterFailoverSupport en true.

Se recomienda que pruebe la idoneidad de esta característica con el entorno y los recursos del sistema antes de habilitar el soporte de migración tras error.

[z/OS]Para obtener más información sobre el uso de adaptadores locales optimizados, consulte el tema sobre la habilitación del soporte de alta disponibilidad de adaptador local optimizado.

Las operaciones de Mbean

failOverToAlternateResource

Valores: none, hold o automated; el valor predeterminado es hold sin retrotracción automatizada.

Descripción: migración tras error manual a recurso alternativo. Esta acción se emite en el recurso primario.

failBackToPrimaryResource

Valores: none, hold o automated; el valor predeterminado es automated con migración tras error automatizada.

Descripción: retrotracción manual a recurso primario. Esta acción se emite en el recurso primario.

Propiedades de los atributos de Mbean

currentActivePool

Valores: Un valor de serie devuelto que contiene un nombre JNDI.

Descripción: Un nombre JNDI primario o alternativa se devuelve dependiendo del que se esté utilizando actualmente.

populateAlternateResource

Valores: booleano

Descripción: False - Inhabilita llenar el recurso alternativo. True - Habilita llenar el recurso alternativo. Esta acción se emite en el recurso alternativo.

resourceFailOver

Valores: booleano

Descriptción: False - Inhabilita la migración tras error del recurso. True - Habilita la migración tras error del recurso. Esta acción se emite en el recurso primario.

resourceFailBack

Valores: booleano

Descripción: False - Inhabilita la migración tras error del recurso. True - Habilita la migración tras error del recuso. Esta acción se emite en el recurso primario.

[z/OS]

Direccionamiento manual de recursos con el mandato modify para recursos configurados con un recurso alternativo

En la plataforma z/OS, puede utilizar parte de las funciones de Mbean utilizando el mandato modify. El mandato modify se utiliza para inhabilitar el soporte de migración tras error del recurso, habilitar el soporte de la migración tras error del recurso, realizar la migración tras error a un recurso alternativo configurado y retrotraer al recurso configurado primario. Consulte el tema Mandato Modify para obtener más detalles sobre cómo emitir el mandato y conocer más sobre los parámetros de la migración tras error.

[z/OS]

Configurar una notificación de acción

Cuando se configura la notificación de acciones de un determinado recurso en y las solicitudes a ese recurso empiezan a fallar más allá de un valor de umbral especificado o predeterminado, la ejecución de WebSphere Application Server para z/OS recibe notificación de que se va a realizar una acción determinada. La acción es un valor configurable. Los códigos de acción se definen en el contenido de la propiedad failureNotificationActionCode que se encuentra en la sección "Propiedades personalizadas" más adelante en este tema.

Las diversas acciones de notificación de anomalía están diseñadas para ayudar en entornos de alta disponibilidad de modo que cuando se produzca una anomalía de recurso, el trabajo se pueda direccionar a otros servidores de un clúster. Se pueden utilizar los siguientes códigos de acción:
  • Código de acción 1

    Este código de acción emite mensajes BBOJ0130I y BBOJ0131I a la corriente de registro de copia impresa del controlador. El mensaje BBOJ0130I se emite cuando el recurso no está disponible, y BBOJ0131I se emite cuando el recurso se reinicia y está disponible. WebSphere Application Server no realiza ninguna acción automatizada adicional.

    El código de acción 1 está diseñado para proporcionar una notificación a los administradores de WebSphere de forma que se puedan configurar acciones de mitigación manual o automatizada fuera del servidor de aplicaciones. BBOJ0130I contiene la siguiente información:
    • El nombre JNDI que identifica el recurso que ha fallado.
    • El nombre del servidor donde se ha utilizado el recurso que ha fallado.
    • La acción que se ha realizado. Por ejemplo: NINGUNA, PAUSANDO ESCUCHAS
    BBOJ0131I contiene la siguiente información:
    • El nombre JNDI que identifica el recurso que se ha reiniciado.
    • El nombre del servidor en el que se ha reiniciado el recurso.
    • La acción que se ha realizado. Por ejemplo: NINGUNA, REANUDANDO ESCUCHAS
    • La razón por la que se ha realizado la acción: 1: Notificación de disponibilidad de región de sirviente normal. 2: Disponibilidad de recurso desconocida.
  • Código de acción 2

    Este código de acción pausa y reanuda los escuchas en el servidor donde se encuentra el recurso para el que se ha configurado esta acción. Los escuchas del servidor se ponen en pausa cuando se considera que el recurso no está disponible. Los escuchas del servidor se reanudan cuando se considera que el recurso está disponible. Cuando se combina con un direccionador frontal que da soporte a la alta disponibilidad, por ejemplo, un servidor proxy o un direccionador bajo demanda, el trabajo para este servidor se direcciona a otros servidores del clúster. Como parte de esta acción, se emiten dos mensajes de información a la copia impresa en la región del controlador. El mensaje BBOJ0130I se emite cuando el recurso no está disponible, y BBOJ0131I se emite cuando el recurso se reinicia y está disponible.

  • Código de acción 3

    Este código de acción detiene e inicia todas las aplicaciones con módulos instalados localmente que utilizan este recurso para los que se ha configurado esta acción. Las aplicaciones se detienen cuando se considera que el recurso que utilizan estas aplicaciones no está disponible. Las aplicaciones se inician cuando se estima que el recurso que utilizan está disponible.

    Como parte de esta acción, se emiten dos mensajes de información a la copia impresa en la región del controlador. El mensaje BBOJ0130I se emite cuando el recurso no está disponible, y BBOJ0131I se emite cuando el recurso se reinicia y está disponible.
    Atención: Las únicas aplicaciones para las que está definida una referencia de recurso se detienen sólo en el servidor que ha experimentado la anomalía de recurso. Por consiguiente, si la aplicación está instalada en un clúster, la aplicación permanece iniciada en los otros servidores del clúster.

    Los mensajes BBOJ0130I y BBOJ0131I contienen la siguiente información:

    BBOJ0130I:
    • El nombre JNDI que identifica el recurso que ha fallado.
    • El nombre del servidor donde se ha utilizado el recurso que ha fallado.
    • La acción que se ha realizado; por ejemplo: NINGUNA, "PAUSANDO LOS ESCUCHAS", "DETENIENDO LAS APLICACIONES QUE UTILIZAN ESTE RECURSO"
    BBOJ0131I:
    • El nombre JNDI que identifica el recurso que se ha reiniciado.
    • El nombre del servidor en el que se ha reiniciado el recurso.
    • La acción que se ha realizado; por ejemplo: NINGUNA, "REANUDANDO LOS ESCUCHAS", "INICIANDO LAS APLICACIONES QUE UTILIZAN ESTE RECURSO"
    • La razón por la que se ha realizado la acción: 1: Notificación de disponibilidad de región de sirviente normal. 2: Disponibilidad de recurso desconocida.

Propiedades personalizadas

Todas las propiedades de esta característica se deben crear como propiedades personalizadas nuevas en la agrupación de conexiones para una fábrica de conexiones u origen de datos determinado. En la consola administrativa, vaya al origen de datos o fábrica de conexiones para la que está habilitada la notificación. Pulse el enlace Propiedades de agrupación de conexiones. En el panel Propiedades de la agrupación, pulse el enlace Propiedades personalizadas de la agrupación de conexiones. Se visualizará el panel Propiedades personalizadas de la agrupación de conexiones de recursos. Pulse Nuevo para crear las propiedades personalizadas tal como se describen a continuación:

[z/OS]failureNotificationActionCode
[z/OS]

Valores: {1,2,3}

Descripción: la propiedad failureNotificationActionCode se utiliza para habilitar la característica de notificación. Si esta propiedad no está establecida en uno de los siguientes valores de entero válidos especificados, la característica de notificación estará inhabilitada:
  • 1 = Un mensaje BBOJ0130I es la salida de la copia impresa que indica que este recurso no está disponible. Cuando el recurso pasa a estar disponible, un mensaje BBOJ0131I es la salida en la copia impresa que indica que el recurso está disponible de nuevo.
  • 2 = Se emite al servidor un mandato de pausar escuchas, lo que impide que el servidor reciba más trabajo entrante. También se emite el mensaje BBOJ0130I para describir la acción realizada. Cuando el recurso está disponible, se emite un mandato de reanudar escuchas para permitir que el servidor reciba de nuevo trabajo entrante. Se emite el mensaje BBOJ0131I para describir la acción realizada.
  • 3 = Todas las aplicaciones con módulos instalados localmente que utilizan este recurso se detienen en este servidor. También se emite el mensaje BBOJ0130I para describir la acción realizada. Cuando el recurso pasa a estar disponible, estas aplicaciones se inician. También se emite el mensaje BBOJ0131I para describir la acción realizada.
failureThreshold

Valores: debe ser un entero y > 0.

Descripción: la propiedad failureThreshold es de sólo lectura si la propiedad failureNotificationActionCode o alternateResourceJNDIName se establece en un valor válido. Si la propiedad failureThreshold no se establece o se establece en un número no válido, se utilizará el valor predeterminado de 5. El valor de entero especificado para failureThreshold es el número de excepciones de recursos consecutivas que debe producirse para un recurso determinado antes de que se envíe una notificación o se produzca una migración tras error.

A continuación se muestra un ejemplo de cómo funciona este valor: si la propiedad failureThreshold se establece en 5 para el origen de datos B, el origen de datos B debe obtener cinco excepciones de recurso consecutivas al intentar establecer conexiones, sin intentos satisfactorios entre estas anomalías, para que se envíe la notificación o se produzca la migración tras error del recurso. Un intento de enviar la notificación o la anomalía se realiza pasadas cinco excepciones de recursos consecutivas. Sin embargo, en un entorno de varias hebras, después de alcanzar el valor del umbral de anomalía, el momento de la notificación o anomalía puede producirse después de excepciones de recursos adicionales.
Atención: Los contadorse de excepciones de recurso no se comparten entre recursos. Las excepciones de recursos deben ser consecutivas para alcanzar el umbral de anomalía.
alternateResourceJNDIName

Valores: Valor de serie que contiene un nombre JNDI directo.

Descripción: Un recurso de origen de datos o fábrica de conexiones alternativo debe ser como el recurso primario. Proporcione el nombre JNDI del recurso alternativo para habilitar la característica de migración tras error.

Propiedades avanzadas de migración tras error

resourceAvailabilityTestRetryInterval

Valores: valor entero, el valor predeterminado es 10.

Descripción: el intervalo de conexión de prueba predeterminado es 10 segundos. Cada 10 segundos, la hebra de conexiones de prueba intenta probar el recurso primario. Dependiendo de los recursos del sistema, este valor se puede cambiar de 1 - MAXINIT segundos.

enablePartialResourceAdapterFailoverSupport

Valores: valor booleano, el valor predeterminado es false.

Descripción: si este valor es true, se produce la migración tras error al recurso alternativo, pero la retrotracción al recurso primario es manual. Esta propiedad se puede establecer si el adaptador de recursos que se utiliza no cumple los requisitos de la migración tras error de la conexión, por ejemplo, no tiene implementado testConnection o emite una excepción no soportada.

disableResourceFailOver

Valores: valor booleano, el valor predeterminado es false.

Descripción: si este valor es true, la migración tras error automática no se produce.

disableResourceFailBack

Valores: valor booleano, el valor predeterminado es false.

Descripción: si este valor es true, la retrotracción automática no se produce.

populateAlternateResource

Valores: valor booleano, el valor predeterminado es false.

Descripción: si este valor es true, el recurso alternativo se llena con conexiones hasta el número máximo de conexiones. Cada intento se realiza para mantener el recurso alternativo en el número máximo de conexiones. Si la base de datos se desactiva para el recurso alternativo, las conexiones caducadas se eliminan y la hebra de llenar vuelve a llenar el recurso alternativo cuando la base de datos está disponible. Puede habilitar e inhabilitar dinámicamente llenar recurso alternativo mediante las operaciones de Mbean disablePopulateAlternateResource y enablePopulateAlternateResource.
Atención: Es posible que mejore el rendimiento durante una migración tras error con llenar recurso alternativo habilitado, pero el coste es alto para mantener el recurso alternativo lleno. La mayoría del coste es mantener el doble del número de conexiones normalmente necesarias para un origen de datos. Debido a que las conexiones son objetos grandes, el mantenimiento de las conexiones utiliza recursos de memoria adicionales en el servidor y recursos adicionales en la base de datos.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_dsfailover
File name: cdat_dsfailover.html