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. Il s’agit d’un environnement qui garantit la continuité 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 programme de transaction de resynchronisation (TP) SNA LU 6.2, généralement appelé service resynchronisation , ainsi que des améliorations apportées à la configuration et à la DLL APPC pour que le basculement 2PC fonctionne via au moins deux serveurs SNA (ordinateurs) 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 l’intégrateur de transactions (TI) ou le fournisseur DB2 peut continuer à lancer des transactions via un autre serveur (ordinateur).
Configuration du basculement 2PC
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 de lu APPC local avec SyncPoint, mais avec des noms de lu différents. Ces unités logiques APPC locales pointent vers le même nom d’ordinateur que celui où le service Microsoft Distributed Transaction Coordinator (DTC) et le service resynchronisation 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 les mêmes alias et nom de lu APPC distants.
Dans l’environnement distant TI (RE) applicable, configurez les alias de LU locaux et distants, puis sélectionnez Prise en charge transactionnelle. Si l’application utilise le fournisseur DB2, configurez universal Data Link avec les alias de lu APPC 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 logiques APPC locales compatibles syncPoint qui spécifient le nom de l’ordinateur où le service resynchronisation 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 SyncPoint.
Lorsqu’un serveur TI Automation (application) ou le fournisseur DB2 appelle un programme transactionnel (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 Host Integration Server (ordinateur) revient en ligne en cas de défaillance d’un serveur (ordinateur) lors d’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, pas pour le service SNA.
Notez que clustering les 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. En outre, 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.