Redémarrage d'un serveur d'applications en mode reprise après incident

Lorsqu'une instance de serveur d'applications avec des transactions actives en cours redémarre suite à une défaillance, le service de transaction utilise les journaux de récupération pour réaliser la procédure de récupération. Ces journaux, entretenus par chaque ressource transactionnelle, sont utilisés toutes les transactions InDoubt et rétablissent la cohérence globale du système.

[z/OS]

Avant de commencer

En cas de migration d'une version précédente du produit, assurez-vous que le paramètre REC inclus dans l'instruction de procédure JCL du contrôleur contient REC=N ou REC=Y. Si la procédure JCL ne spécifie pas REC=N ou REC=Y, le serveur ne redémarre pas en mode reprise, même si vous spécifiez l'option -recovery.

Si les procédures JCL incluent REC=N, la configuration est automatiquement modifiée en REC=Y si vous spécifiez l'option -recovery lors du redémarrage du serveur. REC=N est automatiquement inclus dans la procédure JCL si vous ne migrez pas à partir d'une version précédente du produit. Voici une exemple de ce pourrait être l'état de votre PROC à jour :

//BBO6ACR  PROC PARMS=' ',REC=N,Z=BBO6ACRZ       

Pourquoi et quand exécuter cette tâche

Lors du redémarrage d'un serveur d'applications en mode reprise :
  • Les ressources transactionnelles effectuent les opérations dans leurs journaux de reprise, puis s'arrêtent. Ceci permet de libérer les verrous de ressource placés par le serveur d'applications avant l'incident.
  • Lors de la période de reprise, seules sont disponibles les quelques fonctions de serveur d'applications nécessaires à la reprise transactionnelle.
  • Le serveur d'applications n'accepte pas de nouveaux travaux lors du processus de reprise.
  • Le serveur d'applications s'arrête à l'issue de la reprise.

Ce processus de reprise commence dès que tous les sous-systèmes nécessaires du serveur d'applications sont disponibles. Si le serveur d'applications n'est pas redémarré en mode reprise, il peut accepter du nouveau travail dès que le serveur est prêt, ce qui peut ne pas être possible avant la fin du processus de reprise.

En principe, ce processus ne pose pas de problème. Cependant, dans certains cas, il peut arriver que les procédures d'exploitation ne soient pas compatibles avec la prise en charge simultanée du travail de reprise et de nouveaux travaux. Par exemple, dans certains environnements de haute disponibilité, la défaillance d'un serveur d'applications entraîne le transfert automatique du travail qu'il était en train de traiter vers un autre serveur d'applications. Ce serveur de secours traite alors exclusivement le travail du serveur d'applications défaillant jusqu'à la fin de la reprise totale sur celui-ci, les deux serveurs d'applications pouvant ensuite être resynchronisés. Dans cette situation, vous pouvez choisir que le serveur d'applications défaillant effectue le processus de reprise transactionnel, puis s'arrête. Vous ne souhaiterez probablement pas que ce serveur d'applications accepte de nouveaux travaux durant la reprise.

Pour éviter l'affectation de nouveau travail à un serveur d'applications en cours de reprise transactionnelle, redémarrez celui-ci en mode reprise.

Lorsque vous redémarrez un serveur d'applications défaillants, l'agent de noeud du noeud sur lequel ce serveur réside doit être préalablement en cours d'exécution.

Eviter les incidents Eviter les incidents: Quand un serveur d'applications s'arrête dans le cadre d'un processus d'arrêt normal, un message WSVR0024I: Server xxxxxxxx PROCESS xxxxxxxx stopped est envoyé au fichier journal système. Si les ID utilisateur du serveur possèdent l'accès ALTER pour les profils MVSADMIN.* appropriés de la classe FACILITY, l'entrée d'enregistrement du gestionnaire de ressources associée à cette instance de serveur d'applications est supprimée des journaux RRS. Toutefois, si les ID utilisateur du serveur ne possède pas l'accès ALTER pour les profils MVSADMIN.* appropriés de la classe FACILITY, l'entrée d'enregistrement du gestionnaire de ressources associée à cette instance de serveur d'applications n'est pas supprimée des journaux RRS.

Si l'entrée d'enregistrement du gestionnaire de ressources a été supprimée des journaux RRS, un démarrage à froid est effectué lors d'un démarrage suivant du serveur d'applications. Toutefois, vous ne pouvez pas effectuer un démarrage à froid avec RRS, si vous démarrez le serveur d'applications en mode reprise.

[z/OS]Dans cette version des services, vous pouvez effectuer un démarrage à froid du serveur en mode reprise uniquement sur le système où le serveur est configuré.

gotcha

Si vous souhaitez redémarrer un serveur d'applications en mode récupération, vous devez appliquer la procédure suivante avant qu'une défaillance ne se produise, puis vous devez redémarrer le serveur d'applications de manière à appliquer les modifications apportées à la configuration :

Procédure

Résultats

Le serveur d'applications redémarre en mode reprise, mène à bien la reprise transactionnelle, puis s'arrête. Les verrous de ressources placés par le serveur d'applications avant l'incident sont libérés.
[z/OS]

Que faire ensuite

Configurez la prise en charge haute disponibilité intégrée au sous composant du service de transaction de sorte qu'il récupère les transactions.


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