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.

[z/OS]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.

Figure 1. Reprise homologue
Reprise homologue dans un cluster de serveurs, montrant le serveur 1 avant et après le début du processus de reprise pour les serveurs défaillants 2 et 3.

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.

Par défaut, la reprise homologue est désactivée tant que vous n'activez pas le recours à la reprise du journal de transactions dans la configuration du cluster et ne redémarrez pas les membres du cluster. Une fois la reprise du journal de transactions activée, WebSphere Application Server prend en charge deux styles d'initiation d'une reprise homologue de transactions : automatisée et manuelle. Vous définissez le type le plus adapté en fonction de votre déploiement et définissez le type en configurant la règle de haute disponibilité appropriée. Cette stratégie de haute disponibilité est qualifiée ailleurs dans ces rubriques de règle pour le service de transaction.
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.

Figure 2. Cluster de serveurs actif, juste avant la panne d'un serveur
Cette figure décrit le cluster de serveurs avant l'échec du serveur.

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.

Figure 3. Le serveur 1 est défaillant. Les serveurs 2 et 3 sont bloqués.
Cette figure présente les serveurs 2 et 3 bloqués suite à l'échec du serveur 1.

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.

Figure 4. Processus de reprise homologue démarré dans le serveur 3
Cette figure présente le processus de reprise homologue du serveur 3.

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.

Figure 5. Cluster de serveurs à nouveau stable avec seulement 2 serveurs : les serveurs 2 et 3
Cette figure présente la stabilité du cluster des serveurs 2 et 3.

Icône indiquant le type de rubrique Rubrique de concept



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