Haute disponibilité transactionnelle
La haute disponibilité du service de transaction permet à un serveur dans un cluster de récupérer le travail transactionnel pour un autre serveur du même cluster. Cette fonction fait partie de la stratégie globale de haute disponibilité de WebSphere Application Server.
Cette fonction complète le support de redémarrage et de la reprise homologues, qui permet de redémarrer sur un système homologue du sysplex.
Elément essentiel dans la reprise de transactions, le service de transaction consigne les informations sur le travail transactionnel actif dans le journal de reprise du service de transaction. Ce journal stocke les informations sous une forme persistante : par conséquent, tout travail transactionnel en cours au moment de la défaillance du serveur peut être résolu au redémarrage de ce serveur. Cette activité est qualifiée de processus de reprise du service de transaction. Outre l'exécution des transactions en attente, ce processus assure également la désactivation de tous les verrous dans les gestionnaires de ressources associés.
Processus de reprise homologue
Dans le processus standard de reprise réalisé au redémarrage d'un serveur d'applications, le serveur extrait et traite les informations de transactions consignées, reprend le travail transactionnel et exécute les transactions douteuses. La fin du travail transactionnel (et donc la libération de tous les verrous de base de données maintenus par les transactions) se produit après succès du redémarrage et du traitement de ses journaux de transactions par le serveur. Si le serveur tarde à effectuer la reprise ou requiert une intervention manuelle, le travail transactionnel ne peut pas être achevé et l'accès aux bases de données associées est interrompu.
Pour éviter l'interruption du travail transactionnel et des bases de données associées, WebSphere Application Server offre une stratégie de haute disponibilité qualifiée de reprise homologue des transactions.
La reprise homologue est possible à l'intérieur d'un cluster de serveurs. Un serveur homologue (autre membre du cluster) peut traiter les journaux de reprise d'un serveur défaillant tout en poursuivant la gestion de sa propre charge de travail transactionnel. Inutile donc d'attendre le redémarrage du serveur en échec ou de démarrer un nouveau serveur d'applications pour la reprise de ce dernier.

Le processus de reprise homologue est l'équivalent logique du redémarrage du serveur défaillant, sans pour autant représenter un redémarrage complet dans le serveur homologue. Il donne la possibilité de terminer le travail restant, mais ne permet pas de démarrer un nouveau travail en dehors du traitement de la reprise. Aucun traitement en aval n'est possible pour le serveur défaillant.
La reprise homologue éloigne les conditions de haute disponibilité requises des serveurs individuels vers le cluster de serveurs. Après de tels échecs, le système de gestion du cluster répartit un nouveau travail entre les serveurs restants et la seule différence est la chute potentielle du rendement du système général. Si un serveur est défaillant, il suffit de terminer le travail actif et de réacheminer les demandes vers un autre serveur.
- Reprise homologue automatisée
- Il s'agit du style par défaut pour l'initiation de la reprise homologue. Si un serveur d'applications est défaillant, WebSphere Application Server sélectionne automatiquement un serveur pour exécuter le processus de reprise homologue et repasse le contrôle de la reprise au serveur défaillant à son redémarrage. Pour employer ce modèle, activez la reprise du journal de transactions et configurez l'emplacement du journal de reprise pour chaque membre du cluster.
- Reprise homologue manuelle
- Vous devez configurer de façon explicite ce style de reprise homologue. Si un serveur d'applications est défaillant, servez-vous de la console d'administration pour sélectionner un serveur et exécuter le processus de reprise.
Dans un environnement HA, vous devez configurer les fichiers journaux des compensations ainsi que les fichiers journaux des transactions. Pour chaque serveur du cluster, utilisez les paramètres du service de compensation pour configurer un unique emplacement pour les fichiers journaux des compensations et contrôlez que tous les membres du cluster peuvent accéder à ces fichier journaux.
Exemple de reprise homologue
Les diagrammes ci-dessous illustrent le processus de reprise homologue se produisant si un serveur échoue. La figure 2 montre trois serveurs stables s'exécutant dans un cluster WebSphere Application Server. La charge de travail est équilibrée entre ces serveurs, ce qui assure la conservation des verrous pour chacun d'eux par la base de données dorsale.

La figure 3 montre l'état du système après l'échec du serveur 1 sans suppression des verrous de la base de données. Les serveurs 2 et 3 peuvent exécuter leurs transactions existantes et libérer les verrous dans la base de données dorsale. Toutefois, l'accès peut s'avérer impossible car des verrous sont toujours suspendus pour le serveur 1. Dans la pratique, un certain degré d'accès doit encore être possible pour les serveurs 2 et 3, à condition que la granularité du verrou soit correcte. Dans cet exemple, les serveurs 2 et 3 ont tenté d'accéder à des enregistrements verrouillés et sont par conséquent bloqués.

L'illustration 4 montre le processus de reprise homologue pour le serveur 1 exécuté sur le serveur 3. La partie service de transaction du processus de reprise extrait les informations stockées sur le serveur 2 et utilise ces informations pour exécuter les transactions douteuses. Dans cette figure, le processus de reprise homologue est partiellement exécuté car certains verrous sont toujours maintenus par la base de données pour le serveur 1.

La figure 5 montre l'état du cluster de serveurs au terme du processus de reprise homologue. Le système se trouve dans un état stable avec deux serveurs seulement, entre lesquels la charge de travail est équilibrée. Le serveur 1 peut être redémarré et il n'aura plus de processus de reprise à effectuer.
