Partager via


Fournir un environnement avec prévention des défaillances pour les transactions ACID

Le traitement des transactions ACID (atomique, cohérent, isolé et durable) à l’aide d’une validation en deux phases (2PC) nécessite généralement un environnement de sécurité des défaillances, qui est un environnement qui garantit la continuation malgré les défaillances matérielles. Cela est souvent appelé basculement 2PC ou sauvegarde à chaud.

Host Integration Server inclut des améliorations apportées au tp resync de SNA LU 6.2 , communément appelé service Resync, ainsi que des améliorations apportées à la configuration et à la DLL APPC pour que le basculement 2PC fonctionne via au moins deux serveurs (ordinateurs) SNA Host Integration Server configurés de manière redondante. En cas de défaillance de l’un des serveurs (ordinateurs), un ordinateur Host Integration Server distinct exécutant TI ou le fournisseur DB2 peut continuer à lancer des transactions via un autre serveur (ordinateur).

Pour configurer le basculement 2PC pour qu’il fonctionne avec Host Integration Server, effectuez les tâches suivantes :

  • Configurez deux serveurs Host Integration Server pour prendre en charge le même alias APPC local compatible avec SyncPoint, mais avec des noms de lu différents. Ces unités de référence APPC locales pointent vers le même nom d’ordinateur que celui où le service Microsoft Distributed Transaction Coordinator (DTC) et le service Resync sont en cours d’exécution (c’est-à-dire un ordinateur Host Integration Server distinct qui prend en charge TI ou une application qui utilise le fournisseur DB2). En outre, les deux serveurs prennent en charge le même alias et le même nom de lu APPC distants.

  • Dans l’environnement à distance TI (RE) applicable, configurez les alias lu locaux et distants, puis choisissez prise en charge transactionnelle. Si l’application utilise le fournisseur DB2, configurez universal Data Link avec les alias APPC LU locaux et distants, puis définissez la propriété Units of Work sur DUW.

    Lorsque le service Resync démarre, il recherche toutes les UNITÉS APPC locales compatibles avec SyncPoint qui spécifient le nom d’ordinateur où le service Resync s’exécute. Resynchronisation lance ensuite une demande de noms de journaux Exchange sur chaque LU APPC locale trouvée avec toutes les unités appC distantes compatibles avec SyncPoint.

    Lorsqu’un serveur TI Automation (application) ou le fournisseur DB2 appelle un programme de transaction (TP) sur le mainframe et lance une conversation, la DLL APPC localise tout serveur (ordinateur) Host Integration Server disponible qui prend en charge la paire LU/LU.

    De cette façon, un serveur TI Automation (application) ou le fournisseur DB2 obtient une tolérance de panne en obtenant une conversation via n’importe quel serveur Host Integration Server (ordinateur) qui prend en charge la paire LU/LU. Le service Resync coordonne ensuite le rapprochement du journal des transactions DTC lorsqu’un serveur SNA (ordinateur) Host Integration Server revient en ligne, si une défaillance de serveur (ordinateur) se produit pendant une transaction. Notez que cette configuration ne fournit pas de tolérance de panne pour le serveur (ordinateur) Host Integration Server qui exécute uniquement TI ou le fournisseur DB2, et non pour le service SNA.

Notes

Le clustering des serveurs (ordinateurs) qui exécutent le service SNA n’est pas recommandé. Au lieu d’utiliser le clustering Windows, utilisez les recommandations de configuration décrites dans cette rubrique.

Notes

2PC fonctionne uniquement lorsque vous utilisez le protocole SNA (APPC/LU 6.2) pour communiquer avec le système hôte. Ni TI ni le fournisseur DB2 ne prennent en charge 2PC sur le transport TCP/IP. Il n’existe donc pas de solution de basculement 2PC pour les systèmes TCP/IP.

Voir aussi

WIP (Windows-Initiated Processing)