Containerization
Containerization is among the latest software development trends, and its adoption has grown significantly in both magnitude and speed. It enables developers to create and deploy software and applications faster. Containerization is more secure than other traditional methods. Containerization takes Db2 to the world of Cloud Paks, Red Hat OpenShift, Public Cloud Kubernetes platforms (AWS, Azure, Google Cloud and IBM Cloud), and other Kubernetes flavors (Rancher). The Db2 “Universal” (Db2U) Container — drives Db2 modernisation on IBM Cloud Pak for Data, Red Hat OpenShift, Kubernetes, and public cloud. Db2 database instances in the container environment are created as StatefulSets rendered from the same Pod Template by using Custom Resources (CR). It means that all pods are most often identical in terms of their specifications, such as resource requirements, usernames, ports, memory, CPU limits, and so on, unless the pods are customised for every instance.
To create an instance of Db2uCluster on a container using CR, a user can follow any of the following methods:
-
- On IBM Cloud Pak for Data (CP4D) platform
Use the CP4D UI that will use the underlying CPD provisioning layer to generate the CR spec based on the user inputs and manage the lifecycle of this CR instance.
Use the OCP control plane UI to define the Db2uCluster CR schema fields and manage the lifecycle of this CR instance.
-
- On Kubernetes and OpenShift platforms
Define the Db2uCluster CR schema fields in the YAML format and manage the lifecycle of this CR instance.
For more information on containerized Db2 deployments, refer to IBM official documentation.
Instana and Db2
Instana is a fully automated application performance management (APM) solution. Instana has sensors capable of monitoring Db2LUW database servers. What really makes Instana stand out is its ability to automatically discover and monitor the ever-changing infrastructure that makes up a modern application, especially when it comes to running containerised microservices. Our previous blog had a glimpse of how multi instance and multi database can be monitored, enabling SSL, and so on. Db2LUW instances can be created either on standalone servers or on cloud platforms. This blog focuses on how to configure Instana to monitor Db2 databases deployed on the OCP (OpenShift Container Platform). For more information on Instana, see IBM Instana Observability.
Configuring Instana to monitor Db2(LUW) on OCP
1. Install the Instana agent in your OCP cluster. Follow the steps explained in the official documentation.
2. After the Instana agent is installed, configure the Instana agent to monitor the Db2 databases.
The Instana agent is configured to monitor the applications/services by updating the configuration. In an OCP environment, it is typically done by updating the configmap. The following example shows a configmap entry with instana-agent as the namespace created for agents.
Config Maps for Instana Agent
3. Updating Instana configuration to monitor Db2 servers and databases
The host URL of the db2 services which is a combination of the servicename and namespace would typically take the form — <servicename>.<namespace>.svc, considering an example where we have c-db2ucluster-sample-one as the service name and openshift-operators as the namespace where the database instances are created in the OCP cluster the database host url would take the form — c-db2ucluster-sample-one-db2u.openshift-operators.svc.
4. Choosing the monitoring mode.
Db2 monitoring in Instana can be remote or local depending on where the Instana agent is running. If the Instana agent and the database process are running on the same worker node(host) it qualifies for local monitoring and remote otherwise. In a scenario where you have four db2 database instances running the configuration would be as follows, the hostname derived based on step 3.
data:
cluster_name: instana-agent
configuration-disable-kubernetes-sensor.yaml: |
com.instana.plugin.kubernetes:
enabled: true
configuration.yaml: |
com.instana.plugin.db2:
local: # multiple local configurations supported
- instance: 'db2inst1'
host: 'c-db2ucluster-sample-one-db2u.openshift-operators.svc'
port: '50000'
environment: 'ocp'
user: 'db2inst1'
password: 'xxxxxxxx'
poll_rate: 5 # seconds
tabschema: 'SYSTOOLS'
databases:
- 'BLUDB'
- instance: 'db2inst1'
host: 'c-db2ucluster-four-db2u.openshift-operators.svc'
port: '50000'
environment: 'ocp'
user: 'db2inst1'
password: 'xxxxxxxx'
poll_rate: 5 # seconds
tabschema: 'SYSTOOLS'
databases:
- 'BLUDB'
- instance: 'db2inst1'
host: 'c-db2ucluster-sample-two-db2u.openshift-operators.svc'
port: '50000'
environment: 'ocp'
user: 'db2inst1'
password: 'xxxxxxx'
poll_rate: 5 # seconds
tabschema: 'SYSTOOLS'
databases:
- 'BLUDB'
- instance: 'db2inst1'
host: 'c-db2ucluster-three-db2u.openshift-operators.svc'
port: '50000'
environment: 'ocp'
user: 'db2inst1'
password: 'xxxxxxx'
poll_rate: 5 # seconds
tabschema: 'SYSTOOLS'
databases:
- 'BLUDB'
Instana Agent Configuration.
When the monitoring mode is local, the Instana Db2 sensor looks for a Db2 process on the host where the agent is running. The Instana Db2 sensor picks up the relevant configuration from the list of configuration supplied through the configmap for each host.
5. Restarting the agent.
After the configuration is saved, the existing pods must be restarted for the new configuration to take effect. When the new configuration in place, you can monitor the Db2 instances on the Instana UI as shown in the following images.
Host Dashboard with the local Db2 instances
Dashboard for one of the Db2 instances
Conclusion
With this settings in place, you can monitor the host and the databases on a bunch of performance metrics. Instana can be used to generate alerts, create custom dashboards, identify outages, measure traffic volumes and resource consumptions, export the performance statistics collected, visualise data flow as graphs constructed by analysing the traces, identify bottlenecks and so on to name a few features.
References
#Instana#IBMInstana#AIOps