Planification et conception de solutions à l’aide du service Microsoft pour DRDA

Les sections suivantes fournissent de l’aide pour la planification et la conception de solutions à l’aide du service Microsoft pour DRDA (service DRDA).

Planification

Les organisations informatiques doivent proposer de nouvelles solutions, tout en augmentant l’efficacité des développeurs et en réduisant les coûts. Le service DRDA offre des technologies et des outils permettant aux professionnels de l’informatique et aux développeurs de déployer de nouvelles solutions basées sur Microsoft SQL Server, tout en connectant des charges de travail existantes basées sur IBM DB2. Le diagramme suivant fournit une architecture de haut niveau des technologies et des composants impliqués dans une solution du service DRDA qui connecte des clients IBM DB2 à des bases de données Microsoft SQL Server.

L’illustration précédente montre le plan permettant de connecter des programmes clients IBM CICS pour z/OS, via DB2 pour z/OS et le service pour DRDA, à des bases de données Microsoft SQL Server distantes.

Le service Microsoft pour DRDA (Distributed Relational Database Architecture) est un serveur d’applications (AS) qui permet aux clients DRDA Application Requester (AR), tels qu’IBM DB2 pour z/OS et DB2 pour IBM i, d’exécuter des instructions SQL statiques mappées à SQL Server procédures stockées. Le service DRDA fournit une intégration des données initiées par l’hôte, essentielle pour les entreprises lors d’une migration de charge de travail échelonnée, ou pour les opérations quotidiennes pour la prise en charge de solutions de traitement par lots ou d’analyse décisionnelle à distance.

Le service DRDA offre les fonctionnalités suivantes.

• Accès à partir de clients DRDA à SQL Server via une connexion réseau TCP/IP.

• Authentification de sécurité et chiffrement des données.

• Transactions de validation à deux phases distribuées.

• Instructions SQL statiques mappées à des appels de procédure SQL Server stockée.

• Commandes de langage de manipulation de données dynamiques limitées mappées à des commandes T-SQL.

• Mappage et conversion de type de données, encodage de chaîne et mise en forme de la date et de l’heure.

• Code d’erreur et mappage de texte pour les messages de réponse DRDA et les objets d’erreur mis en forme.

• Utilitaire de trace pour l'enregistrement des flux et des commandes afin de permettre la résolution des problèmes.

Architecture des bases de données relationnelles distribuées

Les clients et serveurs IBM DB2 communiquent à l’aide du protocole et des formats Distributed Relational Database Architecture (DRDA). Le service DRDA fonctionne comme un serveur d’applications DRDA (AS) pour permettre aux clients DRDA d’interagir avec les bases de données Microsoft SQL Server. Le service DRDA prend en charge un ensemble limité de points de code DRDA tels que définis dans les références d’architecture publiées par The Open Group (http://www.opengroup.org).

• DRDA, Version 5, Volume 1 : Distributed Relational Database Architecture (DRDA)

• DRDA, Version 5, Volume 2 : Formatted Data Object Content Architecture (FD:OCA)

• DRDA, Version 5, Volume 3 : Distributed Data Management (DDM) Architecture

  Vous pouvez télécharger DRDA V5 Vol. 3 : Distributed Gestion des données Architecture, numéro de publication C114, à partir de la librairie Open Group (https://go.microsoft.com/fwlink/?LinkID=219127& ; clcid=0x409).

Serveurs et clients IBM DB2

Microsoft, IBM et des fournisseurs tiers implémentent des protocoles et des formats DRDA dans différentes technologies clientes de demandeurs d’application DRDA (AR). Le service DRDA prend en charge les connexions entrantes à partir de clients DRDA conformes à la norme DRDA Version 5, y compris les AR DRDA empaquetés dans ces produits IBM et Microsoft.

• IBM DB2 pour z/OS 12 et 11

• IBM DB2 pour IBM i 7.4, 7.3 et 7.2

• IBM DB2 pour LUW 11.5, 11 et 10.5

  Microsoft Host Integration Server comprend deux clients DRDA Application Requester, l’un conçu pour se connecter aux serveurs de base de données IBM DB2 distants et l’autre conçu pour se connecter aux serveurs de base de données IBM Informix distants. Ces AR DRDA prennent en charge un sous-ensemble DRDA Version 5.0. Le client Microsoft pour DB2 prend en charge ces fournisseurs de données pour DB2 :

• Pilote Microsoft ODBC pour DB2

• Fournisseur Microsoft OLE DB pour DB2

• Fournisseur de données Microsoft ADO.NET Framework pour DB2

• Adaptateur Microsoft BizTalk pour DB2

  Le service pour DRDA offre une prise en charge DRDA de base pour les clients DRDA Microsoft et les clients DRDA IBM.

Authentification unique de l’entreprise

Le service DRDA s’appuie sur Microsoft Enterprise Single Sign-On pour mapper les informations d’identification de l’hôte entrant (par exemple, l’identificateur d’autorisation de l’utilisateur RACF) aux informations d’identification Windows Active Directory (AD) sortantes, ce qui permet au service DRDA de se connecter à SQL Server à l’aide de la sécurité intégrée.

L’illustration précédente montre comment, en activant Enterprise Single Sign-One, le service DRDA peut mapper les informations d’identification DRDA entrantes aux informations d’identification SQL Server sortantes.

L’authentification ESSO initiée par l’hôte requiert des autorisations élevées dans Active Directory (délégation contrainte Kerberos et Utiliser tout protocole d’authentification). ESSO requiert un nom de principal de service Kerberos pour l’ordinateur SQL Server auquel le service DRDA se connecte. .

Microsoft SQL Server

Les administrateurs d’entreprise et développeurs s’appuient sur Microsoft SQL Server pour créer des plateformes de données critiques pour les applications métier. SQL Server aide les entreprises à découvrir de nouveaux insights en accédant à des données au sein de l’organisation tout en fournissant des informations aux outils et à l’analyse à grande échelle et à l’entreposage des données. Le service DRDA peut connecter des charges de travail hôtes IBM existantes à de nouvelles solutions basées sur Microsoft SQL Server pour permettre le développement d’applications d’entreprise hétérogènes et l’analyse décisionnelle.

Le service DRDA s’appuie sur le client réseau Microsoft SQL Server et le fournisseur de données ADO.NET Framework pour SQL Server pour la connectivité et l’accès aux informations des bases de données SQL Server. Pour plus d’informations sur Microsoft SQL Server, consultez http://www.microsoft.com/sql.

Architecture

Le service DRDA permet la connectivité à partir d’un programme client IBM DB2 distant et d’une base de données Microsoft SQL Server locale, en fournissant des services de compatibilité basés sur la norme DRDA (Distributed Relational Database Architecture), qui définit des communications client-serveur DB2 sous la forme d’un ensemble de points de code et de formats de protocole. Le service DRDA fonctionne au sein du DRDA en tant que serveur d’applications (AS). Les programmes clients IBM DB2 (par exemple, COBOL TOS et CICS pour z/OS) sont attachés localement à DB2 pour z/OS et fonctionne au sein de DRDA comme des clients demandeurs d’application (AS). Le service DRDA est un programme de service Windows qui héberge une instance de Microsoft .NET Framework, se connecte à une instance de Microsoft SQL Server locale ou distante à l’aide du fournisseur de données Microsoft ADO.NET Framework pour SQL Server et le client réseau Microsoft SQL Server sous-jacent.

L’illustration précédente montre une solution de service DRDA qui connecte IBM DB2 pour z/OS à Microsoft SQL Server.

Connectivité

Architecture des bases de données relationnelles distribuées

Le service DRDA convertit les points de code et les formats de données DRDA en connexions, transactions, commandes, types de données et objets d’erreur Microsoft ADO.NET correspondants. La fonction principale du service DRDA consiste à mapper de manière fonctionnelle des packages statiques SQL pour DB2 et l’exécution d’instructions pour une procédure stockée Microsoft SQL Server et des instructions CALL. Le service DRDA traite les flux de protocole DRDA tels qu’ils sont définis dans l’architecture basée sur les différents gestionnaires DRDA.

Transports et transactions réseau

Le service DRDA prend en charge les connexions clientes DRDA authentifiées entrantes sur un réseau TCP/IP. Le service DRDA ne prend pas en charge SNA APPC sur LU 6.2 à l’aide de HPR/IP (High Performance Routing over Internet Protocol). Pour se connecter à SQL Server, le service DRDA utilise un fournisseur de Microsoft ADO.NET sous-jacent pour SQL Server et un client réseau SQL, prenant en charge les canaux nommés et de mémoire, ainsi que les connexions réseau TCP/IP.

Par défaut, le service DRDA écoutera sur le port DRDA par défaut 446 pour les connexions entrantes, en acceptant toute demande de connexion cliente DRDA. Le service DRDA peut éventuellement écouter un autre numéro de port préconfiguré. En outre, pour améliorer la sécurité, le service DRDA peut être configuré pour accepter les demandes de connexion entrantes à partir d’une liste prédéfinie d’adresses réseau distantes.

Pour permettre des mises à jour fiables sur l’ensemble du réseau, le service DRDA prend en charge les transactions de validation en deux phases DRDA DUW (Distributed Unit of Work). Les transactions DUW DRDA sont mappées à des transactions SQL Server par le biais du fournisseur de données Microsoft ADO.NET Framework pour SQL Server et du client réseau SQL sous-jacent.

Regroupement et basculement

Le service DRDA prend en charge le regroupement de connexions clientes SQL via la configuration des options de regroupement de clients SQL dans les arguments de chaîne de connexion SQL Server de la configuration de l’application du service DRDA. En outre, le service DRDA offre un pool de connexions interne, en mappant les connexions clientes DRDA et les informations d’identification d’authentification liées aux connexions de base de données et aux informations d’identification SQL Server.

Le serveur principal et le serveur partenaire DRDA fonctionnent conjointement pour garantir un basculement tolérant aux pannes.

Le service DRDA peut fonctionner dans des groupes de deux (2) serveurs, un par ordinateur, pour fournir une tolérance aux pannes de base. Lorsqu’un client AR DRDA se connecte à une base de données SQL Server, le service DRDA retourne une liste de serveurs SRVLST DRDA avec une liste pondérée d’instances de serveur de données. En cas de basculement d’un service DRDA principal, le client AR DRDA peut utiliser ces informations pour se connecter à l’autre membre d’une paire d’ordinateurs de service DRDA. Combinée à la mise en miroir ou au clustering SQL Server, cette technologie peut offrir un niveau raisonnable de protection avec un basculement tolérant aux pannes.

Authentification et chiffrement

Pour sécuriser les informations, le service DRDA prend en charge l’authentification DRDA et les technologies de chiffrement de données courantes. Par exemple, le service DRDA peut prendre en charge l’authentification de base (nom d’utilisateur encodé en texte brut avec mot de passe) ou l’authentification sécurisée à l’aide du protocole Advanced Encryption Standard (AES) 256 bits. En outre, le service DRDA peut prendre en charge l’authentification et le chiffrement combinés à l’aide du protocole SSL (Secure Sockets Layer) (SSL) V3.0 ou TLS (Transport Layer Security) V1.0.

Pour fournir une authentification intégrée, le service DRDA peut combiner la validation et le mappage des informations d’identification entrantes à l’aide de Microsoft Enterprise Single Sign-On (ESSO) avec une authentification SQL Server sortante à l’aide de Windows SSPI (Security Support Provider Interface). Par exemple, le service DRDA peut utiliser ESSO pour mapper un nom d’utilisateur et un mot de passe IBM RACF (Resource Access Control Facility) à un domaine\nom d’utilisateur Microsoft Windows Active Directory en vue d’établir une connexion avec sécurité intégrée à une base de données SQL Server distante.

Compatibilité

Instructions SQL statiques et dynamiques

En premier lieu, le service DRDA permet aux programmes clients DB2 d’exécuter des instructions SQL statiques définies à distance pour les packages DB2, en mappant les instructions du package des procédures stockées SQL Server. Par exemple, lorsqu’un administrateur DB2 ou une liaison de programmeur copie un package DB2 dans SQL Server, le service DRDA convertit les flux BNDSQLSTT DRDA (Bind SQL Statement) en instructions SQL Server T-SQL CREATE PROCEDURE. Lorsque le programme DB2 exécute l’instruction de package distante, le service DRDA convertit l’instruction DRDA OPNQRY (Open Query) ou EXCSQLSTT (Execute SQL Statement) en instruction CALL.

Accessoirement, le service DRDA prend en charge des opérations SQL dynamiques limitées pour permettre aux programmes clients DB2 d’exécuter des commandes T-SQL SQL Server distantes. Par exemple, un administrateur DB2 peut utiliser QMF (Query Management Facility) pour z/OS afin d’interroger une table SQL Server distante.

Syntaxe SQL

Le service DRDA dispose d’un transformateur de syntaxe de commande DB2 ANSI vers SQL Server T-SQL limité pour la liaison de packages, l’exécution d’instructions SQL statiques et dynamiques. Le service DRDA offre éventuellement des fonctions DB2 compatibles supplémentaires sous la forme de fonctions SQL Server CLR.

Le service DRDA offre un composant de liaison de package remplaçable pour convertir des instructions DRDA BNDSQLSTT (Bind SQL Statement) en SQL Server T-SQL CREATE PROCEDURE. Par exemple, un éditeur de logiciels indépendant (ISV) ou un développeur d’entreprise peut implémenter un composant de liaison de package défini personnalisé pour prendre en charge la syntaxe, le type de données, l’encodage ou d’autres conversions requises.

Noms de catalogue et de schéma

Le service DRDA offre un mappage de base des identificateurs d’objets de haut niveau, y compris les noms de catalogue et de schéma. Par exemple, le service DRDA peut mapper un nom DRDA RDBNAM (Relational Database Name) entrant en un nom de base de données SQL Server sortant. En outre, le service DRDA peut mapper un identificateur DRDA COLLID (Collection Identifier) entrant à un nom de schéma SQL Server sortant.

Conversion de type de données

Pour prendre en charge l’interopérabilité multiplateforme entre les bases de données SQL Server s’exécutant sur les systèmes d’exploitation Windows et les serveurs DB2 s’exécutant sur z/OS et IBM i, le service DRDA propose un ensemble de mappages et de conversions de types de données définis dans des fichiers XML (DB2ToMSSql.xml et MSSQLToDB2.xml). Par exemple, le service DRDA peut mapper et convertir des données DB2 DECIMAL entrantes en données SQL Server sortantes.

Encodages de chaîne

Le service DRDA prend en charge la conversion d’encodages de chaîne DB2 EBCDIC en encodages SQL Server ANSI et UNICODE. Si vous le souhaitez, le service DRDA prend en charge les fichiers de conversion remplaçables Windows EBCDIC-to-UNICODE NLS (National Language Support) modifiés. En outre, le service DRDA offre un remplacement des caractères en ligne basé sur un mappage prédéfini à l’aide de paires de valeurs hexadécimales CCSID (Coded Character Set Identifier).

Mise en forme de la date et de l’heure

Le service DRDA permet de convertir en ligne les formats DATE/TIME/TIMESTAMP de DB2 en format date/time/datetime2 SQL Server et en valeurs littérales de chaînes de caractères. Par exemple, le service DRDA peut convertir une valeur de littéral de chaîne TIMESTAMP au format DB2 au format YYYY-MM-DD-hh.mm.ss.tttttt en une valeur SQL Server datetime2 (6) de sortie au format YYYY-MM-DD hh:mm:ss.tttttt.

Administration

Un administrateur peut configurer le service DRDA en modifiant le fichier MsDrdaService.exe.config, ainsi que les fichiers XML auxiliaires (types de données et mappage des erreurs), avant de démarrer le service DRDA. Le service DRDA offre également une lecture immédiate du fichier MsDrdaService.exe.config pour activer les mises à jour de la configuration dynamique.

Configuration

Après l’installation, le service informatique peut personnaliser la configuration du service DRDA en modifiant le fichier MsDrdaService.exe.config et en mettant à jour d’autres fichiers XML. La liste suivante répertorie les composants du service DRDA, les éléments configurables et les magasins de configuration.

Le tableau précédent répertorie les composants, éléments et magasins de configuration configurables du service DRDA.

Traçage

Le service DRDA prend en charge plusieurs options de suivi : suivi de l'écouteur de la console, suivi de l'écouteur de texte, suivi du journal des événements, suivi ETW (Event Tracing for Windows) et suivi personnalisé. L'administrateur utilise le suivi de la console lorsqu'il exécute le service DRDA en mode console Windows, pour afficher les données de suivi à l'écran. L'administrateur utilise le suivi de texte lorsqu'il exécute le service DRDA en mode de service Windows ou en mode console, afin de transmettre les données de suivi à un fichier lisible en mode texte. Le service DRDA envoie automatiquement les éléments de suivi des écouteurs du journal des événements au journal des événements Windows. L’administrateur utilise le suivi ETW pour la collecte de données à haut débit. S’il le souhaite, le développeur d’entreprise peut implémenter un écouteur de suivi personnalisé pour obtenir toutes les données de suivi ou certaines données d’un autre composant.

Comptabilité et journalisation

Le service DRDA prend en charge les points de code de comptabilité DRDA standard : Nom de la station de travail du client ; ID d'utilisateur client ; nom de l'application cliente ; et Comptabilité client. Un développeur d’entreprise peut spécifier des valeurs dynamiques dans son programme avec lequel remplir les propriétés de comptabilité client DRDA. Le service DRDA lit les valeurs au moment de l’exécution pour alimenter le suivi du service DRDA, ce qui permet de corréler les problèmes à une application spécifique et au contexte de l'utilisateur. Le développeur d'entreprise peut également implémenter un écouteur de suivi client du service DRDA afin de consigner les demandes du client AR DRDA. Par exemple, un écouteur de suivi client peut consigner l’accès au réseau et à la base de données sélectionné, en fonction d’une valeur de compte client, dans une base de données de journalisation SQL Server distante.

Mappage des erreurs

Le service DRDA renvoie les erreurs SQL Server sous la forme d'un message de réponse (RM) en code point DRDA ou d’un DRDA SQLCARD (SQL Communications Area Reply Data). Par défaut, pour les problèmes courants, le service DRDA utilise une table intégrée pour mapper les codes d'erreur SQL et les chaînes d'erreur aux messages de réponse et aux erreurs DRDA. Le service DRDA utilise également un fichier externe MsDrdaErrorMappings.xml pour mapper le code d'erreur et le texte d'erreur SQL Server à SQLCODE, SQLSTATE, Reason Code et Error Message.