Merging Two PowerScale Clusters Without Losing the Clinic Dataset
A healthcare imaging group runs a 5-node PowerScale cluster on OneFS 9.5 at its primary data center. The cluster has 480 TB raw, hosts 210 TB of DICOM studies over SMB and 40 TB of research data over NFS, and uses SmartConnect with a single access zone. The group acquires a clinic that stores 35 TB on a 3-node older Isilon cluster. Leadership wants one global namespace, but the clinic must keep read-only access during a 6-week migration and then be retired. The primary cluster has SnapshotIQ, SmartQuotas, and SmartConnect licensed; SyncIQ is licensed only at the primary. The clinic's cluster has no SyncIQ license. The team proposes joining the clinic nodes into the primary cluster to avoid replication. They also want to enable SmartDedupe on the replicated data on the target to save space. The migration window is 4 hours per night; WAN is 300 Mbps.
1. Assess the proposal to join the clinic nodes into the primary cluster. What are the immediate blockers, and what migration method should be used given the 4-hour nightly window?
Read the worked answer
Joining nodes is not a data migration. A node with existing data must be formatted to join a cluster, so the clinic dataset would be destroyed. Generation and OneFS compatibility also matter, but the data-loss issue is decisive. Use SyncIQ instead. SyncIQ requires a license on both source and target; the clinic cluster has none, so obtain a license or temporary evaluation before cutover. The initial 35 TB copy over 300 Mbps is about 259 hours theoretical: 35 x 8 x 1024 x 1024 Mb / 300 Mbps / 3600. At 4 hours per night, that is roughly 65 nights before overhead, so seed the target by shipping a copy or using a temporary bandwidth boost. Then run incremental SyncIQ jobs and fail over only at cutover.
2. The team wants to enable SmartDedupe on the target. What licensing and operational considerations apply, and how would you validate capacity savings?
Read the worked answer
SmartDedupe is a separately licensed service per cluster; a SyncIQ license does not include it. Running dedupe on a SyncIQ target can be operationally risky because the target is normally read-only and dedupe changes block layout; validate support with Dell and test in a lab before enabling it on production. Dedupe also consumes CPU and may not help DICOM or research data if blocks are not repetitive. Do not treat dedupe as guaranteed capacity. Validate with a controlled scan and compare logical versus physical usage using dedupe statistics. If the target must absorb 35 TB plus snapshots, size the target for the full dataset and retention rather than assuming dedupe will close the gap.