Configuration des exigences réseau pour Data Virtualization

Le Data Virtualization service expose les ports de communication réseau afin de permettre les connexions depuis l'extérieur du IBM Software Hub cluster.

Rechercher les ports exposés par Data Virtualization

Data Virtualization prend en charge les connexions de clients externes en fournissant trois ports auxquels les clients peuvent se connecter depuis l'extérieur du cluster. Pour autoriser les connexions externes provenant des clients, Data Virtualization les ports sont configurés pour être exposés en externe en tant KubernetesNodePort que ports. NodePortKubernetes La configuration mappe un numéro de port généré aléatoirement (appelé port externe) à partir d'une plage prédéfinie vers le port réel utilisé en interne par Data Virtualization les pods (appelé port interne).

Vous pouvez également établir une connexion SSL vers Data Virtualization en utilisant la route OpenShift® prédéfinie nommée c-db2u-dv-db2u.

Meilleure pratique : vous pouvez exécuter les commandes de cette tâche exactement telles qu'elles sont écrites si vous configurez les variables d'environnement. Pour obtenir des instructions, consultez la section Configuration des variables d'environnement d'installation.

Assurez-vous de définir les variables d'environnement avant d'exécuter les commandes de cette tâche.

Reportez-vous au tableau des ports pour plus d'informations sur les ports exposés par Data Virtualization et leur utilisation. Voir le tableau des ports.

Applications clientes externes à connecter à Data Virtualization à l'aide de JDBC avec SSL.

Remarque : pour établir des connexions SSL vers Data Virtualization, téléchargez le certificat SSL. Dans le Data Virtualization menu, sélectionnez Administration > Configurer la connexion, puis sélectionnez Télécharger le certificat SSL.

Lors du provisionnement, Data Virtualization crée automatiquement une route de OpenShift transfert nommée c-db2u-dv-db2u dans son OpenShift projet.
Remarque : si l'itinéraire n'existe pas, consultez Data Virtualization L'itinéraire de transit est manquant après la mise à niveau.
Pour obtenir l'hôte de la route, exécutez cette commande. Utilisez ensuite l'hôte de route renvoyé avec le port 443 pour établir la connexion JDBC SSL vers Data Virtualization.
```
oc get route c-db2u-dv-db2u -n ${DV_INSTANCE_NAMESPACE}
```
Les étapes suivantes constituent une autre méthode pour établir une connexion SSL vers Data Virtualization.
Port interne : 50001

Communication : TCP
Pour obtenir le port externe, procédez comme suit.
1. Dans le Data Virtualization menu, sélectionnez Administration > Configurer la connexion.
2. Accédez à Configurer les ressources de connexion.
3. Sélectionnez l'option Avec SSL.
Le port externe est la valeur de la zone Numéro de port.
Vous pouvez éventuellement exécuter la commande suivante.
```
oc get -n ${PROJECT_CPD_INST_OPERANDS} -o jsonpath="{.spec.ports[?(@.name=='ssl-server')].nodePort}" services c-db2u-dv-db2u-engn-svc
```

Applications clientes externes à connecter à Data Virtualization à l'aide de JDBC sans SSL.

Port interne : 50000

Communication : TCP

Pour obtenir le port externe, procédez comme suit.

Dans le Data Virtualization menu, sélectionnez Administration > Configurer la connexion.
Accédez à Configurer les ressources de connexion.
Sélectionnez l'option Sans SSL.

Le port externe est la valeur de la zone Numéro de port.

Vous pouvez éventuellement exécuter la commande suivante.

oc get -n ${PROJECT_CPD_INST_OPERANDS} -o jsonpath="{.spec.ports[?(@.name=='legacy-server')].nodePort}" services c-db2u-dv-db2u-engn-svc

Reconnaissance automatisée pour rationaliser le processus d'accès aux sources de données distantes.

Voir Découverte de sources de données distantes.

Port interne : 7777

Communication : TCP

Pour obtenir le port externe, exécutez la commande suivante :

oc get -n ${PROJECT_CPD_INST_OPERANDS} -o jsonpath="{.spec.ports[?(@.name=='qpdiscovery')].nodePort}" services c-db2u-dv-db2u-engn-svc

Pour obtenir la liste des KubernetesNodePort ports exposés par le Data Virtualization service et le mappage des ports internes vers externes, exécutez la commande suivante.

oc get -n ${PROJECT_CPD_INST_OPERANDS} services c-db2u-dv-db2u-engn-svc

Examinez la sortie.



NAME                    TYPE     CLUSTER-IP    EXTERNAL-IP PORT(S)                                   AGE
c-db2u-dv-db2u-engn-svc NodePort 172.30.13.109 <none> 50000:30662/TCP,50001:32337/TCP,7777:32178/TCP 2d4h

L'exemple indique les ports mappés suivants.

Descriptif	Port interne	Port externe
SSL JDBC	50001	32337
JDBC non-SSL	50 000 USD	30662
Reconnaissance automatisée DV	7777	32178

Data Virtualization ports pour connexions externes

Data Virtualization vous fournit des ports externes pour les connexions externes.

À l'intérieur des modules Data Virtualization principaux, Data Virtualization ouvre les ports suivants, qui sont mappés aux KubernetesNodePort ports.

Port	De	A	Fonction
Port 443	Client JDBC externe se connectant à l'hôte de OpenShift la route c-db2u-dv-db2u.	Data Virtualization capot avant	Cryptage SSL pour la communication avec la base de données.
Valeur de port NodePort correspondante pour le port interne 50000	Client JDBC externe	Data Virtualization capot avant	Non SSL pour la communication avec la base de données.
Valeur de port NodePort correspondante pour le port interne 50001	Client JDBC externe	Data Virtualization capot avant	Cryptage SSL pour la communication avec la base de données.
Valeur de port NodePort correspondante pour le port interne 7777	Connecteurs distants	Data Virtualization capot avant	Un flux de données crypté mais non SSL.

Définition des exigences réseau pour les environnements d'équilibrage de charge

A l'aide de l'utilitaire iptables ou de la commande firewall-cmd, vous pouvez vous assurer que les ports externes exposés répertoriés dans le tableau 1 et leur communication ne sont pas bloqués par des règles de pare-feu locales ou des équilibreurs de charge.

Pour plus d'informations sur la vérification des ports pour les blocages de communication, voir Gestion des données à l'aide de l'utilitaire NCAT dans la documentation Red Hat® .

Si votre IBM Software Hub déploiement utilise un équilibreur de charge et que vous obtenez une erreur de délai d'attente lorsque vous essayez de vous connecter au Data Virtualization service, augmentez les valeurs de délai d'attente de l'équilibreur de charge en mettant à jour le /etc/haproxy/haproxy.cfg fichier.

Mise à jour du fichier de configuration HAProxy

Si vous utilisez un nœud d'infrastructure externe pour acheminer le trafic Data Virtualization externe vers le Red Hat OpenShift cluster, vous devez transférer le trafic vers les nœuds maîtres de votre cluster.

Avant de commencer, veuillez remplir les conditions suivantes :

Veillez à remplacer <DV_instance_namespace> par l'espace de noms Data Virtualization de l'instance.

Exposition non SSL NodePort

Pour exposer les connexions non SSL, NodePort, vous devez définir frontend dv-nonssl-<DV_instance_namespace> et backend dv-nonssl-<DV_instance_namespace>.
Exposer SSL NodePort

Pour exposer SSL, NodePort, vous devez définir frontend dv-ssl-<DV_instance_namespace> et backend dv-ssl-<DV_instance_namespace>.
Exception : cette étape n'est pas nécessaire si vous prévoyez de vous connecter à Data Virtualization en utilisant uniquement la route c-db2u-dv-db2uOpenShift sécurisée sur le port 443.
Déploiement d'agents distants

Si vous prévoyez de déployer des agents distants, vous devez définir frontend dv-discovery-<DV_instance_namespace> et backend dv-discovery<DV_instance_namespace>.

Procédez comme suit :

Sur le noeud d'infrastructure, ouvrez le fichier de configuration HAProxy à l'adresse /etc/haproxy/haproxy.cfg.
Mettez à jour le fichier haproxy.cfg pour spécifier les informations de port.
Vous devez mettre le fichier à jour directement. Ne copiez pas et collez l'échantillon de code suivant. Les valeurs spécifiées dans le fichier haproxy.cfg proviennent du cluster. Ces valeurs sont différentes pour chaque Data Virtualization instance de service provisionnée, même si vous utilisez le même cluster ou le même espace de noms pour provisionner le service.
Recherchez les NodePort ports pour l'espace de noms. Pour plus d'informations, consultez la section Data Virtualization Rechercher les ports exposés par.
Pour obtenir Master<n>-PrivateIP pour chaque noeud maître du cluster, utilisez la commande suivante et regardez la colonne INTERNAL-IP.
```
oc get nodes -o wide
```

Pour mettre à jour le fichier haproxy.cfg, vérifiez que les conditions suivantes sont remplies.

Vous incluez chaque noeud maître dans le cluster dans les sections backend, de sorte que si un noeud maître est arrêté, la connexion peut passer par un noeud maître différent.
Les sections du fichier sont nommées de manière unique si votre cluster exécute plusieurs espaces de noms et que chaque espace de noms dispose d'une Data Virtualization instance de service.
Par exemple, vous avez les sections suivantes dans le haproxy.cfg fichier pour Data Virtualization dans l'espace de noms zen. Cependant, si vous disposez également d'une Data Virtualization instance de service dans l'espace de noms abc, vous devez ajouter NodePort des valeurs pour l'espace de noms abcet vous assurer que les sections du haproxy.cfg fichier ont un nom différent, tel que dv-abc-ssl, dv-abc-nonssl et dv-abc-discovery.
Si vous avez plusieurs Data Virtualization instances, chacune doit avoir un ensemble de NodePort ports différent. Par exemple, vous pouvez ajouter l'espace de noms à la fin de chaque ensemble de NodePort ports.

L'exemple suivant montre le haproxy.cfg fichier avec NodePort les ports définis pour plusieurs instances dans différents espaces de noms :

defaults
       log                     global
       option                  dontlognull
       option  tcp-smart-accept
       option  tcp-smart-connect
       retries                 3
       timeout queue           1m
       timeout connect         10s
       timeout client          1m
       timeout server          1m
       timeout check           10s
       maxconn                 3000

frontend dv-nonssl-<namespace1>
       bind *:<NodePort value for the internal 50000 port>
       default_backend dv-nonssl-<namespace1>
       mode tcp
       option tcplog

backend dv-nonssl-<namespace1>
       balance source
       mode tcp
       server master0 <Master0-PrivateIP>:<NodePort value for the internal 50000 port> check
       server master1 <Master1-PrivateIP>:<NodePort value for the internal 50000 port> check
      (repeat for each master node in the cluster)

frontend dv-nonssl-<namespace2>
       bind *:<NodePort value for the internal 50000 port>
       default_backend dv-nonssl-<namespace2>
       mode tcp
       option tcplog

backend dv-nonssl-<namespace2>
       balance source
       mode tcp
       server master0 <Master0-PrivateIP>:<NodePort value for the internal 50000 port> check
       server master1 <Master1-PrivateIP>:<NodePort value for the internal 50000 port> check
      
(repeat for each master node in the cluster)

frontend dv-ssl-<namespace1>
       bind *:<NodePort value for the internal 50001 port>
       default_backend dv-ssl-<namespace1>
       mode tcp
       option tcplog

backend dv-ssl-<namespace1>
       balance source
       mode tcp
       server master0 <Master0-PrivateIP>:<NodePort value for the internal 50001 port> check
       server master1 <Master1-PrivateIP>:<NodePort value for the internal 50001 port> check
      (repeat for each master node in the cluster)

frontend dv-ssl-<namespace2>
       bind *:<NodePort value for the internal 50001 port>
       default_backend dv-ssl-<namespace2>
       mode tcp
       option tcplog

backend dv-ssl-<namespace2>
       balance source
       mode tcp
       server master0 <Master0-PrivateIP>:<NodePort value for the internal 50001 port> check
       server master1 <Master1-PrivateIP>:<NodePort value for the internal 50001 port> check
      (repeat for each master node in the cluster)

frontend dv-discovery-<namespace1>
       bind *:<NodePort value for the internal 7777 port>
       default_backend dv-discovery-<namespace1>
       mode tcp
       option tcplog

backend dv-discovery<namespace1>
       balance source
       mode tcp
       server master0 <Master0-PrivateIP>:<NodePort value for the internal 7777 port> check
       server master1 <Master1-PrivateIP>:<NodePort value for the internal 7777 port> check
      (repeat for each master node in the cluster)


frontend dv-discovery-<namespace2>
       bind *:<NodePort value for the internal 7777 port>
       default_backend dv-discovery-<namespace1>
       mode tcp
       option tcplog

backend dv-discovery<namespace2>
       balance source
       mode tcp
       server master0 <Master0-PrivateIP>:<NodePort value for the internal 7777 port> check
       server master1 <Master1-PrivateIP>:<NodePort value for the internal 7777 port> check
      (repeat for each master node in the cluster)

Reload HAProxy à l'aide de la commande suivante.
```
systemctl reload haproxy
```

Configuration d'un service d'équilibrage de charge public pour autoriser le trafic externe vers un Red Hat OpenShift on IBM Cloud cluster

Étant donné qu'un cloud privé virtuel (VPC) dans IBM Cloud est axé sur la sécurité, les nœuds des travailleurs ne sont pas visibles depuis l'extérieur du réseau local du VPC. Les serveurs de nœuds n'ont pas d'adresses IP externes et ne sont pas accessibles depuis l'extérieur. Par conséquent, au lieu d'utiliser NodePort access, vous devez configurer un équilibreur de charge public.

Connectez-vous à Red Hat OpenShift Container Platform en tant qu'administrateur de cluster.
```
oc login ${OCP_URL}
```
Passez au projet où le plan IBM Software Hub de contrôle est installé :
```
oc project ${PROJECT_CPD_INST_OPERANDS}
```
Cette commande utilise une variable d'environnement afin que vous puissiez l'exécuter exactement telle qu'elle est écrite. Pour plus d'informations sur la recherche des variables d'environnement, consultez la section Configuration des variables d'environnement d'installation.
Dans la IBM Cloud console, accédez à Infrastructure VPC > Réseau > Sous-réseaux et recherchez le sous-réseau public.
Trouvez celui Subnet ID qui ressemble à l'exemple suivant. Vous avez besoin de cette valeur lorsque vous créez le fichier d'équilibrage de charge.
```
0245-a1b123a4-1234-1234-1a2b-1b23d3bv9a45c
```

Créez un fichier.yaml pour le répartiteur de charge avec les informations suivantes :

apiVersion: v1
kind: Service
metadata:
  name: lb-dv
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<Subnet ID from step 4>"
spec:
  ports:
  - name: db
    protocol: TCP
    port: <Port value of your choice to be the non-ssl port that is used by external clients to connect to Data Virtualization>
    targetPort: 50000
  type: LoadBalancer
  selector:
    app: db2u-dv
    component: db2dv
    formation_id: db2u-dv
    role: db
    type: engine
    name: dashmpp-head-0

Exécutez la commande suivante pour créer le fichier.yaml dans le VPC :
```
$ oc create -f db2-lb.yaml
```

Exécutez la commande suivante pour voir les détails :

$ oc get svc lb-dv

L'exemple suivant montre les détails du répartiteur de charge nommé lb-db2-2:

NAME       TYPE           CLUSTER-IP       EXTERNAL-IP                         PORT(S)                           AGE
lb-db2-2   LoadBalancer   172.21.100.200   fbec480d-eu-de.lb.appdomain.cloud   51000:32149/TCP,51001:32514/TCP   21m

Définition de la configuration de passerelle pour accéder aux connecteurs distants isolés

Un connecteur distant sert de passerelle vers des sources de données éloignées. Si la machine hôte du connecteur distant dispose d'un accès réseau au cluster IBM Software Hub, le connecteur distant contacte automatiquement et se connecte au cluster. Si le port de découverte automatique n'est pas exposé à partir de HAProxy et des règles de pare-feu, ou si la configuration réseau physique n'autorise qu'une communication unidirectionnelle de IBM Software Hub vers le connecteur Data Virtualization distant, vous devrez peut-être établir la connexion manuellement.

Après avoir déployé le connecteur distant et vérifié qu'il fonctionne sur l'hôte, si le connecteur distant n'apparaît pas dans la vue Sources de données > Constellation >, vous pouvez configurer manuellement la connexion entre Data Virtualization et le connecteur distant à l'aide de l'API DEFINEGATEWAYS().

Cliquez sur Données > Data virtualization > Exécuter SQL.
Exécutez la procédure mémorisée DVSYS.DEFINEGATEWAYS(). Cette procédure mémorisée comporte un argument qui contient une liste d'hôtes séparés par des virgules où les connecteurs distants sont en cours d'exécution. Dans l'exemple suivant, deux connecteurs distants sont en cours d'exécution : un sur host1 et un autre sur host2.
```
CALL DVSYS.DEFINEGATEWAYS('host1:6414, host2:6414') 
```
Remplacez les variables host1 et host2 par le nom d'hôte ou l'adresse IP du connecteur distant. Cet exemple utilise le port 6414, que vous spécifiez lorsque vous générez le script de configuration dv_endpoint.sh. Pour déterminer le mappage de port à utiliser dans la procédure mémorisée DVSYS.DEFINEGATEWAYS(), vérifiez le Queryplex_config.log sur votre connecteur distant et recherchez la valeur GAIAN_NODE_PORT comme indiqué dans l'exemple suivant.
```
GAIAN_NODE_PORT=6414
```
Si vous utilisez le transfert de port (par exemple, NAT ou VPN) vers le connecteur distant, vous devez spécifier deux ports, comme illustré dans l'exemple suivant.
```
CALL DVSYS.DEFINEGATEWAYS('host1:37400:6414, host2:37400:6414')
```
Dans cet exemple, deux connecteurs distants sont à l'écoute en interne sur les ports 6414, mais ces ports ne sont pas exposés en externe par l'hôte. Par exemple, les connecteurs distants ne peuvent être accessibles qu'à partir de IBM Software Hub à l'aide d'un serveur VPN configuré pour mapper le port VPN 37400 externe sur le port interne 6414. La définition de la passerelle permet Data Virtualization d'ouvrir une connexion vers les connecteurs distants qui s'exécutent sur host1 et host2. Data Virtualization se connecte au port 37400 de l'hôte distant, et le VPN transfère le trafic vers le port interne 6414 du connecteur distant.

Suppression de la configuration de gateway définie

Si un gateway défini n'est plus nécessaire ou n'est plus accessible, il peut avoir un impact négatif sur les performances de la requête. Vous pouvez supprimer la passerelle à l'aide de l'API REMOVEGATEWAYS(). Cette API utilise une liste de paramètres ID de passerelle séparés par des virgules comme argument littéral chaîne unique, comme illustré dans l'exemple suivant.

CALL DVSYS.REMOVEGATEWAYS('GTW0,GTW2')

Remarque : cette API supprime la passerelle de l'utilisation, mais ne supprime pas sa configuration. Elle apparaît donc toujours lorsque vous appelez listrdbc.