Deploying a Two-Site Alletra Storage MP B10000 with FC and Async Replication
A reseller is deploying HPE Alletra Storage MP B10000 at a primary and DR site 50 km apart. Each site has a two-node array with four 32 Gb FC ports per node. The SAN has two independent Brocade fabrics per site, and 40 hosts run VMware vSphere and Windows Server. The design must support 8 paths per host, survive a single HBA, switch, cable, or array node failure, and replicate selected volumes asynchronously with an RPO of 15 minutes and RTO of 2 hours. The customer has not decided whether to use HPE Peer Persistence with a third-site quorum witness or simple async replication with manual failover. The network team can provide a 10 GbE inter-site link. The project has a four-hour maintenance window for initial configuration and a two-week pilot before production cutover. The architect must produce the zoning, host, replication, and validation plan without assuming the customer will buy additional hardware.
1. Design the FC zoning and host connectivity. State the zoning rule, path count, and what you would explicitly not do.
Read the worked answer
Zoning rule: one zone per initiator-target pair, single-initiator and single-target, with no host-to-host or inter-fabric zones. Keep fabric A and fabric B separate. For 8 paths per host, use two HBAs per host, one per fabric, and zone each HBA to four array target ports on its own fabric; that creates eight initiator-target pairs. If hosts have only two HBAs total, eight paths require four target ports per fabric, but verify HBA queue and fan-in. Do not put all array ports and all hosts in one large zone, do not cross-zone fabrics, and do not use the same target port as the only path for multiple high-load hosts without checking port utilization. Use the array's host-kit guidance for VMware and Windows, enable ALUA/multipath, and set the path policy consistently. Document WWPNs and aliases. Validate that each host sees the expected number of paths and that a single HBA disable leaves the other fabric unaffected. The design must survive one HBA, one switch, one cable, or one array node failure; prove it in the pilot, not in production.
2. Decide between Peer Persistence with quorum witness and async replication with manual failover for the stated RPO/RTO. Justify and describe the replication configuration.
Read the worked answer
Choose async replication with manual failover for the stated 15-minute RPO and 2-hour RTO. Peer Persistence with a quorum witness is for zero-RPO, transparent failover, and typically low-latency metro distances; it adds a third-site witness and more complexity. The customer has not funded additional hardware, and 15 minutes does not require synchronous replication. Configuration: create a replication set for selected volumes, take a 15-minute snapshot schedule, seed the DR copy locally or over a temporary high-bandwidth link, then replicate changes over 10 GbE. Estimate bandwidth from measured change: if 100 TB is replicated and 5% changes daily, that is 5 TB/day = about 46 MB/s average; 10 GbE is ample. Set a recovery plan and runbook: declare disaster, promote the DR volumes, remap hosts, validate Oracle/SQL consistency, then fail back. Test the runbook in the pilot. Condition to revisit: if the business later requires zero RPO or automatic transparent failover, propose Peer Persistence with a third-site quorum witness and verify distance/latency support. Do not deploy a witness just to check a box; it must be maintained and reachable.
3. Define the pilot validation and cutover checklist. Include at least five evidence-based tests.
Read the worked answer
Pilot validation checklist. 1. Path validation: each host sees eight paths, all up; disable one HBA, then one switch port, then one array node, and confirm no I/O errors and no unexpected failover. 2. Zoning validation: confirm single-initiator/single-target zones, no inter-fabric zones, no RSCN storms, and correct WWPN aliases. 3. Performance baseline: run expected peak IOPS and latency for VMware and Windows before and after a node failover. 4. Replication validation: confirm 15-minute snapshots, measure actual lag, force a replication cycle, and perform a controlled DR failover and failback. 5. Data integrity: validate Oracle/SQL consistency and VMware datastore mount after failover. 6. Operations: confirm monitoring, alerting, firmware baseline, backup integration, and runbooks. Cutover: freeze changes, take a final backup, verify replication is current, then migrate in waves. Keep the old path available for rollback. Require signed evidence for each test; a successful ping or login is not validation.