Sizing a Hybrid Array for Mixed OLTP and PACS
A hospital is replacing an ageing SAN with a Huawei OceanStor hybrid array that has 48 drive slots, two controllers and 64 GB cache. The proposed bill of materials contains 24 x 1.2 TB 10K SAS drives and 24 x 6 TB 7.2K NL-SAS drives. The application team wants one disk domain containing all 48 drives, with every drive in a single RAID 5 group, and two global hot spares. Workloads are a 12 TB HIS OLTP database with 18,000 peak IOPS, 8 KB blocks, 70% reads, and a target latency below 5 ms; plus a 100 TB PACS archive that grows 10 TB per year and is read mainly during clinic hours. Finance has approved no additional disks. The implementation engineer must finalise the disk-domain, RAID and hot-spare design before installation.
1. Evaluate the proposed single disk domain and single RAID 5 group. What disk-domain and RAID layout would you recommend, and why?
Read the worked answer
Separate the array into two disk domains, not one:
- Performance domain: the 24 SAS drives. Use RAID 2.0+ and create RAID 10 or RAID 5 (4+1) groups. For 18,000 IOPS at 8 KB with a 5 ms target, RAID 10 on 24 drives gives about 12 data drives and the best write penalty; RAID 5 is acceptable only if cache hit ratio is high and the business accepts slower rebuilds. Keep one SAS hot spare.
- Capacity domain: the 24 NL-SAS drives. Use RAID 6 (8+2 or 6+2) or RAID-TP, with one or two NL-SAS hot spares. PACS is capacity-oriented and tolerates higher latency; RAID 6 protects against a second failure during long NL-SAS rebuilds.
- Tiering: enable SmartTier between the tiers in one storage pool so active PACS metadata and OLTP overflow can use SAS, while cold images remain on NL-SAS.
A single 48-drive RAID 5 group is poor: rebuild uses every drive, double-failure risk is high, and OLTP and archive I/O contend in one domain. It also prevents independent hot-spare and tiering policies. Check usable capacity after parity and spares: 24 x 6 TB RAID 6 leaves roughly 100 TB usable, which is tight for 100 TB plus growth, so use compression or confirm PACS dedupe before acceptance.
2. Explain how RAID 2.0+ changes rebuild behaviour compared with this traditional RAID 5 proposal, and what protection RAID-TP adds.
Read the worked answer
Traditional RAID 5 rebuilds by reading all surviving drives in the RAID group and writing reconstructed data across the group; a 48-drive group means every drive participates, rebuild is slow and production I/O is degraded. RAID 2.0+ virtualizes drives into chunks/extents and builds RAID groups from chunks across the disk domain. A rebuild only needs to copy the used extents that were on the failed drive, and the load can be spread across the domain, so rebuild is faster and less disruptive. It also allows a hot spare to be used more flexibly and avoids the all-drives-in-one-group failure domain.
RAID-TP adds a third parity block. It can tolerate three simultaneous drive failures, which matters for high-capacity NL-SAS where rebuild takes hours and a second or third failure is plausible. The cost is extra parity capacity and potentially lower write performance, so use RAID-TP for the PACS capacity domain, not necessarily for the OLTP SAS domain.
3. How should hot spares be allocated, and what would you check before accepting the final configuration?
Read the worked answer
Allocate at least one hot spare per disk domain, matching drive type and capacity; ideally two for the NL-SAS domain because rebuild is slow and the archive is growing. Prefer dedicated hot spares over a single global spare so a failure in one domain cannot consume capacity needed by the other. Confirm the spare is visible to the disk domain and that the rebuild rate is set so it does not starve OLTP.
Before acceptance verify: RAID policies per domain; actual usable capacity after parity and spares with 20% headroom; SmartTier policy and data relocation schedule; enclosure and controller failure domains; baseline IOPS and latency for OLTP at 8 KB; PACS read throughput during clinic hours; alerting for predictive drive failure; and a documented rebuild and expansion procedure. Also confirm that no single RAID group spans more than the intended number of drives and that the design can lose one controller without losing access.