Stretched-Cluster CP4D Design for a Two-Site Bank
A national retail bank runs IBM Cloud Pak for Data on Red Hat OpenShift in two data centers 8 ms apart. The primary site has 3 control-plane nodes and 9 workers at 32 vCPU/128 GB; the secondary has 3 workers at the same size. Regulators require customer data and metadata to remain in the primary country, but disaster recovery must achieve RTO 4 hours and RPO 15 minutes for dashboards. The bank wants one logical platform for Watson Studio, Watson Knowledge Catalog, Db2, and DataStage, and proposes a single stretched OpenShift cluster with ODF stretched across both sites. Peak analytics adds 60 concurrent notebook users and a nightly 2 TB DataStage load. The infrastructure team wants to reduce cost by using the three secondary workers for all disaster-recovery operands and by placing Db2 and DataStage on the same worker pool. The security team asks whether a single CP4D instance can serve both sites without replicating governed metadata. Evaluate the design and recommend a target architecture.
1. Assess the stretched-cluster proposal. What are the failure-domain and storage risks, and what alternative topology would you recommend?
Read the worked answer
Reject a single stretched cluster. At 8 ms round-trip, etcd and ODF synchronous writes add latency to every control-plane and storage operation; ODF stretch clusters also require a third arbiter site and tightly bounded latency. CP4D is stateful: Zen, IAM, WKC metadata, Db2, and DataStage runbooks all assume low-latency local storage. The proposed topology also cannot guarantee RPO 15 minutes for governed metadata, because asynchronous replication of PVCs and catalog state is not application-consistent.
A two-cluster design is safer: an active primary CP4D instance and a warm-standby secondary. Replicate Db2 with HADR or CDC, land DataStage outputs in the primary, and export WKC metadata on a schedule. Keep the secondary at minimum platform capacity and scale operands during a declared disaster. Document that failover is a runbook, not a transparent stretch. This meets residency and gives a realistic RTO, but only if restore is tested.
2. How should components and worker pools be placed and sized, especially given Db2, DataStage, and 60 notebook users?
Read the worked answer
Use separate worker pools. Put IAM, Zen, and catalog control-plane operands on a platform pool; Watson Studio on an analytics pool; Db2 on a storage-optimized pool with local block PVCs and guaranteed IOPS; DataStage on a CPU-heavy pool. Do not co-locate Db2 and DataStage: DataStage shuffle and sort can starve the Db2 buffer pool and cause latency, and their peak profiles conflict. Use taints, tolerations, and per-namespace quotas so notebooks cannot consume the Db2 pool.
Size for 60 concurrent notebook users by measuring per-user requests, then add 30% headroom; notebooks are bursty but CP4D pods often have fixed requests. For DataStage, reserve enough CPU for parallel jobs and use node autoscaling only for the DataStage pool if supported. On the secondary site, keep platform and Db2 warm; do not run analytics there except during DR. This costs more than three shared workers but avoids noisy-neighbor failures.
3. How would you satisfy data residency and governed metadata requirements across the two sites?
Read the worked answer
Keep WKC as the system of record in the primary country and do not replicate raw regulated data to the secondary. Enforce residency through connection definitions: only primary-region endpoints are allowed in catalogs used by analysts, and Data Virtualization is not used to join cross-border sources. A single CP4D instance spanning sites would put metadata and token traffic over the 8 ms link and complicate residency evidence; use two instances.
For DR, export governed metadata, policies, and catalog membership, and restore them into the secondary instance; re-point connections during failover. Test that masking and row filters survive export/import, because policies may reference local user groups. If the business needs cross-site collaboration, publish de-identified aggregates or data products, not raw assets. Record the decision in an architecture decision record and include IdP group mapping in the restore test.