Planning for multiple solutions
The IBM Cloud Pak for Data control plane is the foundation for multiple solutions. If you purchase multiple IBM Cloud Pak for Data solutions, you must decide how you will install the solutions.
Available solutions
You can install the following solutions on the IBM Cloud Pak for Data control plane:
| Solutions | More information |
|---|---|
| Cloud Pak for Data | You can purchase the following licenses:
|
| Cognos Analytics | You can purchase the following licenses:
|
| Data Product Hub | You can purchase the following licenses:
|
| Data Replication | You can purchase the following licenses:
|
| DataStage | You can purchase the following licenses:
|
| Db2 | You can purchase the following licenses:
|
| EDB Postgres | You can purchase the following licenses:
|
| IBM Knowledge Catalog Premium | You can purchase the following licenses:
|
| IBM Knowledge Catalog Standard | You can purchase the following licenses:
|
| Informix | You can purchase the following licenses:
|
| MANTA Automated Data Lineage | You can purchase the following licenses:
|
| MongoDB | You can purchase the following licenses:
|
| OpenPages | You can purchase the following licenses:
|
| Planning Analytics | You can purchase the following licenses:
|
| Product Master | You can purchase the following licenses:
|
| Watson Discovery | You can purchase the following licenses:
|
| Watson Speech services | You can purchase the following licenses:
|
| watsonx.ai | You can purchase the following licenses:
In addition, you can purchase the following licenses if you want to use Mistral Large with watsonx.ai:
|
| watsonx Assistant | You can purchase the following licenses:
|
| watsonx Code Assistant for Red Hat® Ansible® Lightspeed | You can purchase the following licenses:
|
| watsonx Code Assistant for Z | You can purchase the following licenses:
|
| watsonx.data | You can purchase the following licenses:
|
| watsonx.governance | You can purchase one or more of the following licenses:
|
| watsonx Orchestrate | You can purchase the following licenses:
|
Choosing a deployment strategy
You can choose whether you want to install all of the solutions on a single instance of Cloud Pak for Data or whether you want to install the solutions on different instances of Cloud Pak for Data.
Review the following table to determine which strategy is appropriate for your needs:
| Deployment strategy | Choose this option to... |
|---|---|
| Single instance of Cloud Pak for Data |
|
| Separate instances of Cloud Pak for Data |
|
Tracking license metrics when you deploy multiple solutions on a single instance
If you choose to install multiple solutions on a single instance of Cloud Pak for Data, you can use node pinning to ensure that you are compliant with your license terms. Node pinning uses node affinity to determine where the pods for each solution can be placed.
If you decide to use node pinning, you must install the resource specification injection feature.
Nodes fall into one of the following categories:
| Node type | Which pods run here? |
|---|---|
| VPC nodes | Pods that count against your VPC entitlement. |
| Non-VPC nodes | Pods that do not count against your VPC entitlement because they are part of a non-charged
entitlement. Refer to your license for information about which components are non-charged entitlements. |
| GPU nodes | Pods that count against your General Purpose Graphics Processing Units (GPGPUs)
entitlement. GPU nodes are not applicable if you don't have any services that require GPUs. |
If you decide to use node pinning, work with your cluster administrator to:
- Identify each type of node in your cluster
- Choose a strategy for passing node information to Cloud Pak for Data.
- Decide whether you will enforce node pinning.
Passing node information to Cloud Pak for Data
You can use either of the following strategies to pass node information to Cloud Pak for Data:
| Method for identifying nodes | Considerations |
|---|---|
| Node labels | If you use this method, pods can be scheduled on any nodes with the specified label. Important: If you back up your Cloud Pak for Data
deployment to a different cluster, it is recommended that you use this option over node lists,
especially if you plan to enforce node
pinning.
When you use node labels, you can re-create the labels on the target cluster before you restore Cloud Pak for Data, which enables node pinning to occur with minimal disruption. For example, you want to use the following labels:
If you choose this method, see Labeling nodes for node pinning for information on how to label your nodes. |
| Node list | If you use this method, pods can be scheduled only on the specified nodes. You can specify
nodes by host name or IP address. Important: If you back up your Cloud Pak for Data deployment to a different cluster, it is
recommended that you use node labels rather than node lists, especially if you plan to enforce node pinning.
If you choose to use node lists to pin pods to nodes, you cannot enforce node pinning, because it will prevent pods from coming up on the target cluster. In addition, if you use node lists to pin pods to nodes, you must
re-run the For example, you have 7 worker nodes in your cluster. However, when you run the
The pods will be scheduled only on the specified worker nodes. No pods will be
scheduled on |
Enforcing node pinning
When you run the cpd-cli
manage
apply-entitlement command, you can specify whether you want to
enforce node pinning.
By default, node pinning is not enforced. When pinning is not enforced, pods use the
preferredDuringSchedulingIgnoredDuringExecution setting for node pinning.
If you enforce node pinning, pods use the
requiredDuringSchedulingIgnoredDuringExecution setting for node pinning, which
means that the scheduler cannot schedule the pod unless the rule is met.
Pending
state.- You don't have sufficient resources to ensure that pods are scheduled on the specified nodes.
- You have existing pod affinity rules that you need to support.
Labeling nodes for node pinning
- VPC nodes
- Non-VPC nodes
- GPU nodes (Not applicable if you don't have any services that require GPUs.)
You must use the isc-entitlement key and specify the appropriate label for each
type of node where you want to schedule pods. For example:
- You want to use
chargeable-componentsto identify VPC nodes. Run the following command on each node where pods that count against your VPC entitlement can be scheduled:oc label node <node-name> isc-entitlement=chargeable-componentsReplace
<node-name>with the name of the node to label. - You want to use
non-chargeable-componentsto identify non-VPC nodes. Run the following command on each node where pods that do not count against your VPC entitlement can be scheduled:oc label node <node-name> isc-entitlement=non-chargeable-componentsReplace
<node-name>with the name of the node to label. - You want to use
chargeable-gpu-componentsto identify GPU nodes. Run the following command on each node where pods that count against your GPGPU entitlement can be scheduled:oc label node <node-name> isc-entitlement=chargeable-gpu-componentsReplace
<node-name>with the name of the node to label.