Configuring network requirements for Watson Query

To get the list of Kubernetes NodePort ports exposed by the Watson Query service and internal-to-external port mapping, run the following command.

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

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

The example indicates the following mapped ports.

Description	Internal port	External port
JDBC SSL	50001	32337
JDBC Non-SSL	50000	30662
DV Automated Discovery	7777	32178

Port	From	To	Function
Corresponding NodePort port value for internal 50000 port	External JDBC client	Watson Query head pod	Non-SSL for database communication.
Corresponding NodePort port value for internal 50001 port	External JDBC client	Watson Query head pod	SSL encrypted for database communication.
Corresponding NodePort port value for internal 7777 port	Remote connectors	Watson Query head pod	An encrypted data stream but non-SSL.

If you use an external infrastructure node to route external Watson Query traffic into the Red Hat OpenShift® cluster, you must forward traffic to the master nodes of your cluster by following these steps.

1. On the infrastructure node, open the HAProxy configuration file at /etc/haproxy/haproxy.cfg.
2. Update the haproxy.cfg file to specify port information.

   You must update the file directly. Don't copy and paste the following code sample. The values that are specified in the haproxy.cfg file come from the cluster. These values are different for each Watson Query service instance that is provisioned, even if you use the same cluster or namespace to provision the service.

3. Find the NodePort ports for the namespace. See Finding ports exposed by Watson Query for more instructions.
4. To get Master<n>-PrivateIP for each master node in the cluster, use the following command and look at the INTERNAL-IP column.

   oc get nodes -o wide

5. To update the haproxy.cfg file, ensure that the following requirements are met.
   • You include each master node in the cluster in the backend sections, so that if one master node goes down, the connection can go through a different master node.
   • Sections in the file are uniquely named if your cluster runs multiple namespaces, and each namespace has a Watson Query service instance.

     For example, you have the following sections in the haproxy.cfg file for Watson Query in namespace zen. However, if you also have a Watson Query service instance in namespace abc, you must add NodePort values for namespace abc, and ensure that sections in the haproxy.cfg file have a different name, such as dv-abc-ssl, dv-abc-nonssl, and dv-abc-discovery.

   • If you have multiple Watson Query instances, each one must have a different sets of NodePort ports. For example, you can append the namespace to the end of each set of NodePort ports.

   The following example shows the haproxy.cfg file with NodePort ports set for multiple instances in different namespaces:

   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)

6. Reload HAProxy by using the following command.

   systemctl reload haproxy

Because a virtual private cloud (VPC) in IBM® Cloud is geared toward security, workers nodes are not visible from outside of the VPC's LAN. The node servers don't have external IP addresses and cannot be accessed externally. As a result, instead of using NodePort access, you must configure a public load balancer.

1. Log in to Red Hat OpenShift Container Platform as a cluster administrator.

   oc login ${OCP_URL}

2. Change to the project where the Cloud Pak for Data control plane is installed:

   oc project ${PROJECT_CPD_INST_OPERANDS}

   This command uses an environment variable so that you can run the command exactly as written. For information about sourcing environment variables, see Setting up installation environment variables.
3. Go to Databases > Details and note the Deployment ID. You will use this value when you create the load balancer file.
4. Create a load balancer .yaml file with the following details:

   apiVersion: v1
   kind: Service
   metadata:
     name: lb-dv
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<provide public subnet names here>"
   spec:
     ports:
     - name: db
       protocol: TCP
       port: <external non-ssl port>
       targetPort: 50000
     - name: db-ssl
       protocol: TCP
       port: <external ssl port>
       targetPort: 50001
     type: LoadBalancer
     selector:
       app: db2u-dv
       component: db2dv
       formation_id: db2u-dv
       role: db
       type: engine
       name: dashmpp-head-0

5. Run the following command to create the .yaml file in the VPC:

   $ oc create -f db2-lb.yaml

6. Run the following command to see the details:

   $ oc get svc lb-dv

   The following example shows the details of load balancer named 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