Comment choisir entre la reprise de transaction homologue automatisée et manuelle
Le type de votre système de fichiers est le facteur déterminant au moment de choisir le type de reprise homologue de transaction à utiliser. Chaque système de fichiers présente un comportement différent, et le comportement de verrouillage de fichier est particulièrement important au moment de choisir entre la reprise homologue automatisée et manuelle.
La prise en charge à haute disponibilité de WebSphere Application Server utilise un mécanisme de signal de présence pour déterminer si les serveurs sont toujours en cours d'exécution. Les serveurs sont considérés comme étant en panne lorsqu'ils cessent de répondre aux requêtes de signal de présence. Certains scénarios, comme une surcharge système ou un partitionnement du réseau (faisant l'objet d'une explication dans cette rubrique), peuvent contraindre les serveurs à cesser de répondre aux signaux de présence, même s'ils continuent à fonctionner. WebSphere Application Server utilise la technologie de verrouillage des fichiers pour éviter que de tels événements n'aboutissent à des accès simultanés aux journaux de reprise de transaction. En effet, l'accès à un journal de reprise par plusieurs serveurs peut entraîner une perte d'intégrité des données.
Néanmoins, tous les systèmes de fichiers ne proposent pas la sémantique nécessaire au verrouillage des fichiers. En particulier, ce verrouillage des fichiers est désactivé dès lors qu'un serveur rencontre un incident. Par exemple, Network File System Version 4 (NFSv4) propose ce comportement de déblocage, contrairement à Network File System Version 3 (NFSv3).
Vous pouvez tester si un système de fichiers partagé peut prendre en charge la reprise des journaux de transactions en exécutant le test de protocole concernant le verrouillage de système de fichiers pour WebSphere Application Server. Pour exécuter le test, voir http://www-01.ibm.com/support/docview.wss?uid=swg24010222.
NFSv4 ouvre les verrous maintenus pour le compte d'un hôte lorsque ce dernier rencontre un incident. La reprise homologue peut se dérouler automatiquement sans redémarrer le matériel défaillant. Par conséquent, cette version de NFS est mieux adaptée à une utilisation avec la reprise homologue automatisée.
NFSv3 maintient les verrous des fichiers pour le compte d'un hôte ayant échoué, jusqu'à ce que ce dernier redémarre. Dans ce contexte, l'hôte est la machine physique exécutant le serveur d'applications à l'origine de la demande de verrouillage et c'est le redémarrage de l'hôte, et non pas du serveur d'applications, qui ouvre finalement les verrous.
- Le serveur H s'exécute sur l'hôte H et maintient un verrouillage exclusif des fichiers de ses propres journaux de reprise.
- Le serveur P s'exécute sur l'hôte P et maintient un verrouillage exclusif des fichiers de ses propres journaux de reprise.
- L'hôte H rencontre un incident, entraînant le serveur H avec lui. Le gestionnaire de verrouillage NFS du serveur de fichiers maintient les verrous octroyés au serveur H pour son compte.
- WebSphere Application Server déclenche un événement de reprise homologue dans le serveur P pour le serveur H.
- Le serveur P tente d'obtenir un verrouillage exclusif des fichiers pour ce journal de récupération homologue, mais n'y parvient pas car il est maintenu pour le compte du serveur H. La procédure de reprise homologue est bloquée.
- A un moment donné, l'hôte H est redémarré. Les verrous maintenus pour son compte sont ouverts.
- La procédure de reprise homologue dans le serveur P est débloquée et obtient les verrous de fichiers exclusifs nécessaires à la reprise homologue.
- La reprise homologue se déroule sur le serveur P pour le serveur H.
- Le serveur H est redémarré.
- Si la reprise homologue est toujours en cours sur le serveur P, cette dernière est interrompue.
- Le serveur P libère le verrouillage exclusif sur les journaux de reprise et rend la propriété de ces derniers au serveur H.
- Le serveur H obtient le verrouillage exclusif et peut désormais réaliser une journalisation de transaction standard.
En raison de ce comportement, sur NFSv3, vous devez désactiver le verrouillage des fichiers afin d'utiliser la reprise homologue automatisée. La désactivation du verrouillage des fichiers peut se traduire par des accès simultanés aux journaux de reprise. Il est donc primordial de commencer par protéger votre système contre les surcharges système et les partitionnements réseau. D'une autre manière, vous pouvez configurer la reprise homologue manuelle, par laquelle vous évitez les accès simultanés en déclenchant manuellement la procédure de reprise uniquement pour les serveurs tombés en panne.
- Surcharge système
- La surcharge système se produit lorsqu'une machine devient chargée à un tel point que les temps de réponse sont médiocres et que les requêtes expirent. Plusieurs causes potentielles peuvent expliquer une telle surcharge. Par exemple :
- Le serveur est sous-alimenté et ne peut pas faire face à la surcharge.
- Le serveur reçoit un afflux temporaire de requêtes.
- La mémoire physique disponible est insuffisante. Par conséquent, le système d'exploitation est trop occupé par la pagination pour allouer le temps processeur nécessaire au serveur d'applications.
- Partitionnement réseau
- Le partitionnement réseau survient lorsqu'une panne des communications dans un réseau aboutit à deux réseaux de taille inférieure , indépendants, et ne pouvant pas se contacter mutuellement.

Dans le cadre d'un fonctionnement normal, deux serveurs d'un réseau échangent des signaux de présence. Au cours d'une surcharge système, l'opération de signal de présence expire, donnant l'illusion d'une panne de serveur. Après un partitionnement réseau, chaque serveur se trouve dans un réseau distinct, et les signaux de présence ne peuvent pas passer, donnant également l'illusion d'une panne de serveur.