[z/OS]

Activation du support haute disponibilité avec les adaptateurs locaux optimisés

Utilisez cette tâche pour permettre aux adaptateurs locaux optimisés d'exploiter le support haute disponibilité.

Avant de commencer

L'adaptateur de ressource local optimisé participe au support haute disponibilité de WebSphere Application Server, support qui offre la possibilité de spécifier le nom JNDI d'une fabrique de connexions secondaire dans les propriétés personnalisées du pool de fabriques de connexions.

Important : Pour que le support haute disponibilité fonctionne correctement, le nom du registre de ressources doit être spécifié sur la connexion gérée en utilisant l'attribut Nom de registre de la fabrique de connexion à la fois pour la ressource principale et pour la ressource secondaire. L'utilisation de la méthode setRegisterName() empêche la ressource secondaire d'obtenir le contrôle.

Pour utiliser le support haute disponibilité des adaptateurs locaux optimisés, effectuez les étapes suivantes.

Procédure

  1. Ajoutez la propriété alternateResourceJNDIName aux propriétés de pool de connexions d'une fabrique de connexions. Spécifiez le nom JNDI de la fabrique de connexions de la ressource secondaire.

    Par exemple, si votre élément JNDI principal est eis/ola et que vous voulez désigner eis/ola_backup comme ressource secondaire, attribuez la valeur eis/ola_backup à la propriété alternateResourceJNDIName puis ajoutez cette propriété à une propriété de pool de connexions sur la fabrique de connexions eis/ola.

  2. Pour que le basculement puisse avoir lieu, assurez-vous que l'espace adresse externe associé au nom d'enregistrement de la fabrique de connexions secondaire est disponible.

    Avec les adaptateurs locaux optimisés, le processus de basculement de ressource est déclenché lorsqu'une application émet une demande getconnection() sur une ressource et que cette demande échoue en raison de l'indisponibilité de l'enregistrement cible. Durant ce processus, le nom JNDI de la ressource secondaire est utilisé en remplacement dans l'appel getconnection(). Le nombre de tentatives infructueuses autorisées avant que le basculement ne soit déclenché peut être configuré par l'ajout d'une autre propriété de pool de connexions, failurethreshold. Si vous réglez cette propriété à 1, cela signifie que le basculement a lieu dès le premier échec. Autrement dit, dès lors que l'obtention d'une connexion échoue (avec une ResourceException), les demandes suivantes sont adressées à la fabrique de connexions secondaire.

    Un événement de basculement déclenche un processus consistant à envoyer les demandes suivantes à la ressource secondaire, avec le nom JNDI et le nom d'enregistrement secondaires. Simultanément, un processus d'interrogation périodique démarre. Ce processus consiste, pour la gestion des connexions de WebSphere Application Server, à envoyer une demande toutes les 10 secondes afin de déterminer si la ressource principale est à nouveau disponible. La gestion des connexions de WebSphere Application Server peut aussi envoyer un message au journal du serviteur (servant) WebSphere Application Server indiquant qu'il y a eu basculement sur la ressource secondaire, puis rebasculement sur la ressource principale. Vous pouvez utiliser la propriété failureNotificationActionCode du pool de connexions de la fabrique de connexions pour spécifier la notification voulue. La valeur par défaut de cette propriété est 1, ce qui signifie que des messages sont envoyés au journal des travaux du serviteur. Pour plus d'informations, référez-vous à la rubrique consacrée au routage de charge de travail des ressources source de données et fabrique de connexions.

    Lorsque l'adaptateur de ressource WOLA détecte que la ressource principale est à nouveau disponible ou que le nom de registre est actif, une notification est envoyée à la gestion des connexions de WebSphere Application Server pour l'informer que les nouvelles demandes portant sur le nom JNDI de la ressource principale peuvent être à nouveau routées vers la fabrique de connexions principale. Comme la disponibilité de la ressource principale est vérifiée à intervalles de 10 secondes, lorsque l'enregistrement principal est à nouveau actif, il peut s'écouler jusqu'à 10 secondes avant que le basculement vers cet enregistrement ne soit effectif.

  3. Redémarrez le serveur. Après avoir ajouté la propriété alternateResourceJNDIName ou toute autre propriété du pool de connexions, vous devez redémarrer le serveur pour que ces propriétés soient prises en compte.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_enablehaola
Nom du fichier : tdat_enablehaola.html