Presenting Existing RAC Devices to a Replacement Cluster
A customer is replacing a 12-node Oracle RAC cluster on RHEL 8 and will reuse the existing 48 × 1 TiB PowerMax devices. The devices sit in storage group SG_RAC and are already masked through masking view MV_OLD, which was built from initiator group IG_OLD (24 HBA WWNs, two per node), port group PG_OLD (eight 32 Gb FC ports across two directors) and SG_RAC. The new nodes arrive with 24 new WWNs, and cutover spans two weekends: the old cluster must keep running at full production while the new one is validated against a clone of the database. A junior engineer plans to create IG_NEW for the new WWNs and then 'add IG_NEW into MV_OLD'. Zoning for the new HBAs to the same eight array ports has already been activated, but nothing has been changed on the array. Change control requires that the devices be presented at the same LUN addresses to both clusters, and that the old cluster lose no paths before its final shutdown.
1. Explain why the engineer's plan cannot work as described, and give the exact object model you would build instead.
Read the worked answer
A masking view is a strict one-to-one-to-one binding of a single initiator group, a single port group and a single storage group. There is no mechanism to add a second IG to an existing view, so the request will be rejected at creation time.
Two further rules block the shortcut:
- An initiator (WWN) can belong to exactly one IG. So you cannot simply clone IG_OLD's contents into IG_NEW while both hosts are live; the new WWNs are unique, so this part is fine, but do not plan to move the old WWNs later without a disruptive change.
- A device can belong to only one storage group. This is why you must not try to build SG_NEW from the same 48 devices; share SG_RAC instead.
Build: MV_NEW = IG_NEW + PG_OLD + SG_RAC. Port groups and storage groups are reusable across views, which is exactly how the same LUNs are presented to two clusters during a migration. Validate with symaccess show view MV_OLD before and after, and confirm IG_NEW contains 24 unique, correctly typed (FC) WWNs.
2. What must be true of zoning and LUN addressing so both clusters see the 48 devices at identical LUN numbers, and what would you verify before creating anything?
Read the worked answer
Zoning: create single-initiator zones (one new HBA port with the chosen array ports) and leave the old zones untouched. Do not zone one HBA port to all eight array ports in a single zone; keep one zone per HBA port so a fabric event cannot cause an RSCN storm across the whole cluster. Confirm each port group member is on a director that has headroom - pull per-port percent-busy and MB/s first, because putting 24 new initiators on an already hot port pair creates the next performance incident.
LUN addressing: LUN numbers are assigned per masking view, not inherited from the source SG. So do not assume the new cluster will see identical addresses. After creating MV_NEW, rescan one new node and compare lsscsi output (or /dev/sd* to ASM disk mapping) against the documented LUN map of the old cluster. If ASM disk strings or mount scripts depend on exact LUNs, reconcile the map before proceeding to the remaining eleven nodes, and record the final map in the change record.
Also verify: 48 devices × 2 paths = 96 paths per node is within the multipath and HBA queue limits configured on the new build.
3. Give the verification and cleanup sequence from MV creation through decommissioning MV_OLD, including which steps are disruptive.
Read the worked answer
Sequence:
- Zone new HBAs (fabric-side, no host impact).
- Create IG_NEW, verify WWNs (symaccess show ig IG_NEW).
- Create MV_NEW on IG_NEW + PG_OLD + SG_RAC (non-disruptive; no I/O impact to the old cluster).
- Rescan the new nodes; verify multipath -ll shows 48 devices × 2 active paths, ASM discovers all disks, and I/O counters move.
- Validate the new cluster against the database clone; keep the old cluster live.
- After final cutover and shutdown, remove the old zones, then delete MV_OLD (symaccess delete view). This is non-disruptive to the devices; SG_RAC and the data are untouched. Delete or retain IG_OLD per audit policy.
Watch-outs: deleting a masking view does not delete devices, but deleting devices from SG_RAC later would remove them from the new cluster too, since both views share the SG. Any future change to PG_OLD - for example adding a port - affects both views, so every host using that port group needs a rescan.