[AIX Solaris HP-UX Linux Windows][IBM i]

Configuration des transactions sur les serveurs pour une disponibilité optimale

Vous pouvez configurer des aspects liés aux transactions des serveurs d'applications afin d'en optimiser la disponibilité. De cette façon, vos transactions se terminent ou sont récupérées plus rapidement. Une fois modifiées les propriétés d'un serveur d'applications liées aux transactions, vous devez redémarrer ce serveur.

Pourquoi et quand exécuter cette tâche

Pour configurer les aspects liés aux transactions des serveurs d'applications pour une disponibilité optimale, procédez comme suit :

Procédure

  1. Enregistrez les fichiers journaux des transactions sur un disque rapide dans un système de fichiers à disponibilité élevée (technologie RAID, par exemple). Chaque transaction globale peut avoir à accéder au journal des transactions qui est utilisé pour la restauration des transactions après une panne. Par conséquent, le disque sur lequel sont écrits les fichiers journaux doit se trouver sur un disque à disponibilité élevée (technologie RAID, par exemple).

    Par ailleurs, les performances du disque affectent directement les performances des transactions. En général, un transaction globale effectue deux inscriptions sur le disque : une après la phase de préparation lorsque l'issue de la transaction est connue (ces informations sont forcées sur le disque) et l'autre lorsque la transaction est terminée. Par conséquent, les journaux des transactions doivent être placés sur les disques les plus rapides dont vous disposez.

    Afin de permettre le basculement automatique de la reprise sur incident d'un journal de transactions dans une topologie en clusters WebSphere Application Server, vous devez utiliser des unités montées en réseau pour les journaux de transactions, sur un disque rapide dans un système de fichiers à haute disponibilité, tel qu'une unité RAID, auquel chaque membre du cluster peut accéder.

  2. Créez un disque miroir pour les fichiers journaux des transactions à l'aide de la technologie de miroir de disque matériel ou de disques à double port. Si un miroir des fichiers journaux a été créé ou si ceux-ci peuvent être restaurés, ils peuvent être utilisés pour redémarrer un serveur défaillant ou déplacés vers une autre machine et un autre serveur peut être démarré pour effectuer la restauration.

    Vous pouvez configurer la mise en miroir matériel d'un disque ou les disques à double ports en utilisant la console d'administration pour spécifier le répertoire du système de fichiers approprié pour les journaux de transactions.

  3. Spécifiez l'emplacement optimal du répertoire des journaux de transactions pour les serveurs d'application.

    Par défaut, un serveur d'applications place les fichiers journaux des transactions dans un sous-répertoire du répertoire d'installation de WebSphere Application Server, où le nom du sous-répertoire est identique au nom du serveur.

    [AIX Solaris HP-UX Linux Windows]Par exemple, le répertoire par défaut d'un serveur d'applications nommé server1 est

    /IBM/WebSphere/AppServer/profiles/nom_profil/tranlog/server1

    [IBM i]Par exemple, le répertoire par défaut d'un serveur d'applications nommé server1 est

    /QIBM/UserData/WebSphere/AppServer/version_was/ND/profiles/nom_profil/tranlog/server1

    version_was indique le numéro de version de cette installation d'IBM® WebSphere Application Server. Par exemple, V6 pour la version 6 de WebSphere Application Server.
    [z/OS]Par exemple, le répertoire par défaut d'un serveur d'applications nommé server1 est

    /IBM/WebSphere/was_version/AppServer/profiles/nom_profil/tranlog/server1

    version_was indique les numéros de version, d'édition et de modification de cette installation d'IBM WebSphere Application Server. Par exemple, V6R0M2 pour la version 6.0.2 de WebSphere Application Server.

    Vous pouvez définir un emplacement par défaut pour le répertoire du journal des transactions d'un serveur d'applications en définissant la propriété Répertoire du journal des transactions du serveur. Si le répertoire des journaux de transactions n'a pas été créé au démarrage du serveur d'applications, la structure de répertoires est générée automatiquement.

    Remarque : Si vous modifiez le répertoire du journal des transactions, vous devez appliquer la modification et redémarrer le serveur d'applications dès que possible afin de réduire le risque d'incidents se produisant avant le redémarrage du serveur d'applications. Par exemple, si un incident entraîne un échec du serveur (avec des transactions en cours), le serveur redémarre avec le nouveau répertoire de journal et ne peut pas convertir automatiquement les transactions en cours enregistrées dans l'ancien répertoire de journal.
  4. Ne permettez pas à plusieurs serveurs d'application d'utiliser simultanément le même ensemble de fichiers journaux. Dans la mesure où les journaux de transactions enregistrent l'état des transactions globales sur un serveur, si les journaux sont perdues ou altérés, les transactions qui se trouvent à l'état "préparé" avant l'échec peuvent sortir des ressources dans un état "douteux" (en attente de validation) et empêchent des mises à jour ultérieures des ressources ou des accès ultérieurs aux ressources par d'autres utilisateurs ou d'autres serveurs. Il peut être nécessaire de convertir manuellement ces transactions en validant ou annulant les transactions au niveau des gestionnaires de ressources concernés. Le serveur défaillant peut alors être démarré à froid, ce qui crée des journaux de transactions vides.

    Si un miroir des fichiers journaux a été créé ou si ceux-ci peuvent être restaurés, ils peuvent être utilisés pour redémarrer un serveur défaillant ou déplacés vers une autre machine et un autre serveur peut être démarré pour effectuer la restauration, conformément à la description de la procédure associée.

    Ne permettez jamais à plusieurs serveurs d'application d'utiliser simultanément le même ensemble de fichiers journaux, car chaque serveur va détruire les informations enregistrées par l'autre, ce qui crée des fichiers journaux altérés et inutilisables pour une restauration ultérieure.

  5. Configurez des serveurs d'applications pour qu'ils utilisent toujours la même adresse de port d'écoute à chaque démarrage. Si vous exécutez des transactions réparties entre plusieurs serveurs d'applications, les références d'objets distants sauvegardées dans le journal des transactions doivent être réacheminées vers le serveur d'origine au moment de la reprise.

    Sous WebSphere Application Server, Network Deployment, les agents de noeuds réacheminent automatiquement ces références d'objets distants vers les serveurs d'applications appropriés au moment de la reprise. Toutefois, si la transaction répartie s'effectue entre des serveurs d'applications qui ne s'exécutent pas sous WebSphere Application Server, Network Deployment, vous devez gérer le réacheminement des références d'objets distants pour que la reprise de transaction aboutisse. Par exemple, vous devez procéder de la sorte si un serveur d'applications est déployé dans WebSphere Application Server, Network Deployment et exécute des transactions réparties avec des serveurs Corba ou autres que WebSphere EJB.

    En particulier, l'action de redémarrage par défaut d'un serveur d'applications qui ne s'exécute pas sous Application Server WebSphere Application Server, Network Deployment consiste à utiliser une adresse de port d'écoute différente du port utilisé lors de l'arrêt du serveur. Ceci empêche l'exécution de la reprise de transactions. Pour contourner ce problème, vous devez configurer les serveurs d'applications pour qu'ils utilisent toujours la même adresse de port d'écoute à chaque démarrage (voir la propriété de l'ORB com.ibm.CORBA.ListenerPort dans la rubrique relative aux propriétés personnalisées de l'ORB). Vous pouvez avoir besoin d'effectuer des modifications de configuration similaires à d'autres serveurs d'applications impliqués dans les transactions afin de pouvoir accéder à ces serveurs au cours de la reprise.


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=tjta_optsrv
Nom du fichier : tjta_optsrv.html