Choosing a Platform for Block, File, and Archive in One Refresh
A media company is refreshing a mixed workload. It has 40 TB for an Oracle database that needs block access, about 200,000 IOPS at 1 ms, and snapshots every four hours. Render projects use 600 TB of NFS capacity, grow by 20 TB per month, and are read by 3,000 Linux workstations; metadata operations are heavy. A 1.5 PB archive must be S3-accessible, retained for seven years, and read only a few times per year. The company has two racks, 10 kW per rack, and wants one vendor. The existing OceanStor 5500 V5 hybrid is out of support and cannot be expanded. The CIO wants to reduce silos by putting all three workloads on one OceanStor Pacific cluster. The storage team is worried about database latency and archive economics. A backup target is already budgeted separately.
1. Evaluate the CIO's proposal to place all three workloads on one OceanStor Pacific cluster. Which workload is the weakest fit, and why?
Read the worked answer
The weakest fit is the Oracle database. A scale-out file and object platform is optimized for throughput, capacity, and multi-protocol access; it is not the natural choice for a 200,000-IOPS block workload with 1 ms latency and four-hour snapshots. Even if Pacific can present block in some configurations, the design would mix metadata-heavy render traffic and archive scans with database I/O, making latency outliers and noisy-neighbor control much harder.
The render file workload is a good fit for scale-out NAS because capacity and client count grow. The archive is a good fit for object because access is rare and capacity is large. Putting all three on one cluster also creates a fault and upgrade domain that spans production database, user files, and long-term archive. I would keep the database on OceanStor Dorado all-flash with block LUNs and snapshots, and use OceanStor Pacific for file and object with separate pools, QoS, and network access.
If the CIO wants fewer silos, consolidate file and object first, not the database. The existing 5500 V5 should be migrated off and retired, not extended as a tier.
2. Propose a platform and pool/network placement. Include at least two isolation decisions that prevent one workload from harming another.
Read the worked answer
Place Oracle on Dorado all-flash: block LUNs, UltraPath on Linux, two FC fabrics, HyperSnap for four-hour snapshots, and a SmartQoS policy for non-production clones. Place render on OceanStor Pacific file pools with NFS exports on a dedicated 25 or 100 GbE storage network; set quotas per project and QoS on heavy clients. Place archive on OceanStor Pacific object pools with S3 access, erasure coding for capacity efficiency, and a separate object gateway or VIP.
Isolation decisions: first, separate storage pools and failure domains for file and object, so a render metadata storm or archive scan does not consume the other's capacity and performance. Second, separate VLANs and links for render clients, backup, and archive, with firewall rules limiting archive access to archive servers. Third, separate administrator roles and authentication domains for object and file. Keep database traffic on FC, not the Ethernet storage network.
If the seven-year archive requires immutability, confirm object retention or WORM licensing before approval; do not assume it. The design should also show how the 20 TB per month growth is absorbed without putting file and object on the same node pool.
3. What sizing and protection evidence would you require before approving the design?
Read the worked answer
Require a workload profile, not just capacity: Oracle IOPS at peak, read/write ratio, working set, snapshot frequency and retention, and growth; render metadata operations per second and client concurrency; archive object size distribution, ingress rate, and annual read rate. For Dorado, show front-end port count, host queue depth, and capacity after RAID and snapshot reserve. For Pacific, show node count for both performance and capacity, rebuild time, and whether file and object share nodes.
For protection, show that database snapshots are not the only copy, that file data has backup or remote copy consistent with RPO, and that archive retention is immutable if required. Require a pilot or benchmark with the real render client mix and a restore test. Check rack power at 10 kW per rack, especially for all-flash and dense archive nodes. Confirm support and licensing for the chosen protocols.
Approve only if the design has headroom for 20 TB per month growth, a documented failure-domain plan, and a migration plan off the unsupported 5500 V5.