How to Select Cache for Centralized Storage

— Example: Huawei OceanStor 5210 / 5310 / 5510 / 5610 Hybrid Flash Storage

In centralized storage architecture, controller cache (memory) is the key resource that determines performance ceilings. It is responsible not only for accelerating I/O, but also for I/O scheduling, metadata management, and running advanced features. Therefore, cache selection should be based on workload and system-level design rather than capacity alone.

I. Four Core Dimensions for Cache Sizing

Cache configuration should be evaluated based on:

1. Workload model (most important)
2. Storage scale (physical + logical)
3. Advanced feature requirements
4. 5–10 year future growth planning

II. Priority One: Workload Characteristics (I/O Pattern & Concurrency)

Controller cache acts as a performance buffer, and its requirement grows approximately linearly with I/O pressure.

1. High IOPS workloads (random small I/O)

Typical scenarios:

• Databases (OLTP)
• Virtualization platforms (VMware / KVM)
• Cloud platforms

Characteristics:

• I/O size: 4K / 8K
• High concurrency
• Random access dominant

Recommendation:

• ≥ 256GB cache (preferred)
• Purpose: improve cache hit ratio, reduce disk access, and lower latency

2. High bandwidth workloads (sequential large I/O)

Typical scenarios:

• Video streaming
• Big data analytics (OLAP)
• Backup and archiving

Characteristics:

• I/O size: ≥ 64K
• Throughput-oriented

Recommendation:

• ≥ 256GB cache
• Purpose: provide larger buffering space and prevent throughput bottlenecks

3. Low workload scenarios

Typical scenarios:

• File sharing
• Log storage

Recommendation:

• 128GB is sufficient

III. Key Factor: Storage Scale (Capacity & Object Count)

Cache is also used for metadata management, not only I/O acceleration.

1. Physical scale (number of disks)

• More disks → more RAID groups, bad block tracking, and status management overhead
• Recommendation:
  • Small scale: 128GB
  • Medium/large scale: ≥ 256GB

2. Logical resource scale

Includes:

• Number of LUNs / volumes
• Mapping relationships
• Permissions and policies

Impact:

• Each LUN consumes metadata resources in cache

Conclusion:

• More LUNs → higher cache requirement

IV. Often Overlooked: Advanced Features

Advanced features consume significant controller memory.

Examples include:

• Snapshots / cloning (multi-copy)
• Remote replication (sync / async)
• Inline deduplication / compression
• QoS / multi-tenant traffic control
• Heterogeneous virtualization

Guideline:

• More enabled features → move up one cache tier (e.g., 128GB → 256GB)
• Minimum memory requirements defined by vendor must be followed

V. System View: Composition of Centralized Storage

Centralized storage is not a single device but a system:

1. Main components

• Controller enclosure
• Disk shelves / arrays
• Front-end and back-end interface modules

2. Controller responsibilities

• Process I/O requests
• Execute configuration and management commands
• Manage disks and metadata
• Monitor system health (failures, cache consistency, etc.)

👉 Cache resides entirely in the controller and is the core of system performance

VI. Controller Reliability and Capacity Mechanisms

1. Built-in disk design

• Single-disk controllers: system data storage
• Dual-disk controllers: redundancy for higher reliability

2. Controller redundancy

• Dual-controller architecture:
  • If Controller A fails → Controller B takes over
• Cache mirroring ensures data consistency

VII. Capacity and Cache Co-Design

1. RAID and storage pools

• RAID level affects usable capacity
• Storage pool design impacts cache efficiency

2. Hardware constraints

• Disk type (SAS / SATA / SSD)
• Maximum disk capacity
• Front-end/back-end bandwidth (e.g., 100Gb RDMA)

3. Expansion strategy (must be planned early)

• Reserve 10%–20% for metadata overhead
• Plan for 3–5 years (ideally 5–10 years)
• Multi-controller scale-out improves performance and capacity utilization

VIII. Summary Recommendation (Practical Sizing Guide)

IX. Key Takeaways

• Cache is not just “enough to run”—it directly defines performance and stability

• Priority order for sizing:

  Workload model > concurrency > features > storage scale

• Under-sizing cache leads to:
  • performance bottlenecks that cannot be fully solved later by simple upgrades