Raid Levels - Learning Module

Loading content...

0/241

RAID Selection: Decision Framework for Database Architects

The Art of RAID Selection

Selecting the right RAID configuration is one of the most impactful decisions a database architect makes. The choice affects performance, reliability, capacity, and cost for the entire lifetime of the storage system—often 3-5 years or more.

This final page synthesizes everything we've learned into a practical decision framework. We'll examine how to analyze requirements, evaluate tradeoffs, make informed selections, and plan for implementation and future changes.

Learning Objectives

By the end of this page, you will be able to systematically evaluate RAID options for specific database workloads, make justified selections that balance competing requirements, plan implementation and migration strategies, and adapt recommendations as technology and requirements evolve.

Requirements Analysis Framework

Effective RAID selection begins with understanding requirements across multiple dimensions. Rushing to 'just use RAID 10' or 'RAID 6 is fine' without analysis leads to suboptimal outcomes.

Dimension 1: Performance Requirements

Quantify performance needs before selecting RAID:

Performance Questions to Answer

•What IOPS are required? — Measure current workload or estimate from transaction rates. Note read vs. write ratio.
•What throughput is required? — Important for batch operations, ETL, backups. Sequential vs. random workloads differ.
•What latency is acceptable? — P99 latency matters more than average for user-facing systems.
•How will requirements grow? — Plan for 2-3 years of growth. Over-provisioning is cheaper than migration.
•What's the read/write ratio? — RAID 5/6 is viable for 90%+ read workloads but poor for write-heavy.

Dimension 2: Capacity Requirements

Capacity planning directly influences RAID selection:

Total usable capacity needed: After RAID overhead, not raw capacity
Growth projections: Monthly/yearly data growth rate
Expansion strategy: Can the RAID level grow, or must you rebuild?
Cost per GB constraints: Budget may dictate capacity-efficient RAID

Dimension 3: Reliability Requirements

Define durability and availability expectations:

RPO (Recovery Point Objective): Maximum acceptable data loss (e.g., 0 for no data loss)
RTO (Recovery Time Objective): Maximum acceptable downtime for recovery
Data criticality: Regulatory, financial, or operational sensitivity
Single points of failure: Beyond just drives—controllers, enclosures, power

Requirements Analysis Template
Dimension	Current State	Target State	Growth/Change Factor
Random Read IOPS	_____ IOPS	_____ IOPS	_____×/year
Random Write IOPS	_____ IOPS	_____ IOPS	_____×/year
Sequential Throughput	_____ MB/s	_____ MB/s	_____×/year
P99 Latency Requirement	_____ ms	_____ ms	N/A
Usable Capacity	_____ TB	_____ TB	+_____ TB/year
Durability (RPO)	_____ minutes	_____ minutes	N/A
Availability (RTO)	_____ hours	_____ hours	N/A

When Requirements Conflict

Often, requirements conflict: you want maximum write IOPS (favors RAID 10), maximum capacity efficiency (favors RAID 6), and minimum cost (favors RAID 5). The framework helps make these tradeoffs explicit. Document which requirements are hard constraints vs. nice-to-haves.

RAID Selection Decision Matrix

Based on requirements analysis, use this decision matrix to identify the appropriate RAID level(s) for each data category.

Step 1: Identify Workload Category

Workload Category Identification
Workload Category	Characteristics	Examples
OLTP (High-Write)	Random I/O, 40%+ writes, latency-critical	Order processing, banking transactions, gaming
OLTP (Read-Heavy)	Random I/O, 80%+ reads, latency-sensitive	Catalog browsing, social media feeds
OLAP / Data Warehouse	Sequential I/O, 95%+ reads, throughput-focused	Reporting, analytics, BI queries
Mixed / General Purpose	Variable patterns, moderate latency needs	ERP systems, CMS platforms
Transaction Logs / WAL	Sequential writes, durability-critical, low latency	PostgreSQL WAL, MySQL binlog, Oracle redo
Backup / Archive	Sequential I/O, capacity-focused, write-once	Backup staging, cold storage, compliance archives

Step 2: Apply Selection Matrix

RAID Selection Matrix by Workload
Workload Category	Primary Recommendation	Alternative	Avoid
OLTP (High-Write)	RAID 10	RAID 1 (small scale)	RAID 5, RAID 6
OLTP (Read-Heavy)	RAID 10	RAID 6 (if capacity constrained)	RAID 5
OLAP / Data Warehouse	RAID 6	RAID 10 (if budget allows)	RAID 5 (large drives)
Mixed / General Purpose	RAID 10	RAID 6	RAID 5
Transaction Logs / WAL	RAID 10 or RAID 1	None—no compromise	All parity RAID
Backup / Archive	RAID 6	RAID 5 (small drives only)	RAID 0, RAID 10

RAID Selection Decision Flowchart (Pseudocode)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
// RAID Selection Decision Algorithm
 
function selectRAID(requirements) {
    // Step 1: Check if data is non-critical (scratch/temp)
    if (requirements.durabilityRequired === false) {
        return "RAID 0";  // Maximum performance, zero protection
    }
    
    // Step 2: Transaction logs and WAL
    if (requirements.dataType === "transaction_log" || 
        requirements.dataType === "WAL") {
        return "RAID 10 or RAID 1";  // Never compromise on logs
    }
    
    // Step 3: Write-intensive workloads
    if (requirements.writeRatio >= 0.30) {  // 30%+ writes
        if (requirements.latencyCritical) {
            return "RAID 10";  // No question
        }
        // Accept higher latency for cost savings
        return "RAID 10";  // Still RAID 10; parity RAID write penalty too severe
    }
    
    // Step 4: Read-dominated workloads
    if (requirements.writeRatio < 0.10) {  // 90%+ reads
        if (requirements.capacityPriority === "high") {
            return "RAID 6";  // Best capacity efficiency with protection
        }
        if (requirements.performancePriority === "high") {
            return "RAID 10";  // Maximum read IOPS
        }
        return "RAID 6";  // Default for read-heavy
    }
    
    // Step 5: Mixed workloads (10-30% writes)
    if (requirements.latencySLA <= 10) {  // Strict latency requirement (ms)
        return "RAID 10";
    }
    if (requirements.driveSize >= 8) {  // TB
        return "RAID 10 or RAID 6";  // RAID 5 too risky with large drives
    }
    
    // Step 6: Backup and archive
    if (requirements.dataType === "backup" || 
        requirements.dataType === "archive") {
        return "RAID 6";  // Capacity efficiency for large datasets
    }
    
    // Default recommendation
    return "RAID 10";  // When in doubt, maximize reliability and performance
}

The 'Just Use RAID 10' Heuristic

For database systems with budget flexibility, 'just use RAID 10' is actually a reasonable heuristic. RAID 10 never performs poorly for any workload—it just costs more in capacity. If capacity cost is acceptable, RAID 10 eliminates complexity in selection and avoids future regret from parity RAID limitations.

Cost-Benefit Analysis

RAID selection has significant cost implications. A rigorous cost-benefit analysis helps justify decisions to stakeholders and ensures optimal resource allocation.

Total Cost of Ownership (TCO) Components:

RAID TCO Factors

•Drive cost: Raw cost per TB × required raw capacity for usable capacity
•Infrastructure cost: Enclosures, controllers, cables, rack space proportional to drive count
•Power consumption: More drives = more watts and cooling; significant in large deployments
•Management overhead: Complex configurations require more administrator time
•Downtime cost: Performance during degraded mode, rebuild operations
•Data loss risk cost: Expected loss probability × business impact of data loss
•Expansion cost: Some RAID levels expand easily; others require migration

RAID Cost Comparison Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Cost Analysis: 100TB Usable Storage Requirement
// Drive cost: $200 per 18TB enterprise SAS drive
// Controller: $1,000 (hardware RAID)
 
// RAID 10 Configuration:
//   Usable capacity = N/2, so need 200TB raw = 12 drives
//   Drive cost: 12 × $200 = $2,400
//   Controller: $1,000
//   Total: $3,400
//   Cost per usable TB: $34/TB
 
// RAID 6 Configuration:
//   Usable capacity = (N-2)/N
//   For 100TB usable with 18TB drives: Need (100/18) drives for data
//   Plus 2 drives for parity = ~7.5 drives → 8 drives minimum
//   But with 8 drives: usable = 6 × 18 = 108TB ✓
//   Drive cost: 8 × $200 = $1,600
//   Controller: $1,000
//   Total: $2,600
//   Cost per usable TB: $26/TB
 
// RAID 10 premium: ($3,400 - $2,600) / $2,600 = 31% more expensive
 
// BUT: Factor in write performance value
// OLTP system processing $1M/day in transactions
// 10% performance degradation from RAID 6 write penalty = $100K/day potential impact
// Decision: $800 premium for RAID 10 is trivial compared to business risk
 
// Conclusion: Raw storage cost comparison misleads
// Factor in performance, reliability, and business impact

Cost Efficiency Comparison (100TB Usable, 18TB Drives)
RAID Level	Drives Needed	Drive Cost	Cost/Usable TB	Relative Cost
RAID 0	6	$1,200	$12/TB	1.0× (baseline)
RAID 6	8	$1,600	$16/TB	1.33×
RAID 5	7	$1,400	$14/TB	1.17×
RAID 10	12	$2,400	$24/TB	2.0×

The Hidden Costs of Capacity Efficiency

RAID 6's capacity efficiency advantage shrinks when you factor in: (1) Extra controller capacity needed for parity calculations, (2) Extended rebuild time requiring more hot spares, (3) Performance overhead requiring more drives to meet IOPS requirements. For write-intensive workloads, RAID 10 often requires fewer total drives to meet performance SLAs.

Implementation Planning

Selecting a RAID level is only the beginning. Successful implementation requires careful planning across multiple dimensions.

Array Sizing Decisions:

How do you divide drives into arrays? Options include:

Single Large Array

•Maximum capacity in one volume
•Simpler management (one array to monitor)
•Better stripe distribution
•Longer rebuild times
•Larger blast radius if something goes wrong
•Example: 24 drives in one RAID 6 array

Multiple Smaller Arrays

•Faster individual rebuilds
•Workload isolation possible
•Smaller failure domain
•Multiple volumes to manage
•Potential capacity fragmentation
•Example: 4 arrays of 6 drives each

General guidance: For RAID 10, larger arrays are fine (rebuild is per-pair, not per-array). For RAID 6, limit arrays to 12-16 drives to keep rebuild times reasonable.

Stripe Size Configuration:

Stripe size (chunk size) affects performance characteristics:

Stripe Size	Best For	Trade-offs
16-32 KB	Random I/O distribution	More metadata overhead
64-128 KB	Balanced workloads	Common default, works well
256-512 KB	Sequential throughput	Large sequential I/O benefits
1+ MB	Streaming video, backups	Too large for most databases

For databases: Match stripe size to a multiple of your database page size. PostgreSQL's 8KB pages work well with 64KB stripes (8 pages per stripe). MySQL's 16KB InnoDB pages work well with 64KB or 128KB stripes.

Implementation Checklist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// Pre-Implementation Checklist
 
1. Hardware Verification
   □ All drives same model and firmware version
   □ Drives from different manufacturing batches (reduce correlated failure)
   □ Controller firmware is current
   □ Battery/capacitor backup tested and functional
   □ Drive health verified (SMART, burn-in test)
 
2. Configuration Planning
   □ RAID level confirmed for each data category
   □ Array sizes determined (drives per array)
   □ Stripe size selected (aligned with database page size)
   □ Hot spare allocation (minimum 1 per array or 1 per 10 drives)
   □ Cache settings documented (write-back with BBU)
   □ Rebuild priority configured (high for production)
 
3. Alignment Verification
   □ Partition alignment to stripe boundaries
   □ Filesystem alignment verified
   □ Database tablespace locations on correct arrays
   □ Transaction logs on dedicated RAID 10/1 array
 
4. Monitoring Setup
   □ SMART monitoring enabled for all drives
   □ Array status alerts configured
   □ Rebuild monitoring in place
   □ Performance baseline captured
 
5. Documentation
   □ Array configuration documented
   □ Drive serial numbers and slot positions recorded
   □ Recovery procedures written and tested
   □ Escalation contacts defined

Test Before Production

Never deploy a new RAID configuration directly to production without testing. Run burn-in tests, benchmark performance, verify alignment, and practice failure/recovery procedures. The hour invested in testing prevents days of emergency troubleshooting.

Migration and Evolution Strategies

Storage requirements evolve over time. Planning for migration and expansion from the beginning reduces future disruption.

Common Migration Scenarios:

RAID Migration Paths
From	To	Method	Downtime Required
RAID 5	RAID 6	Add drive, migrate online (some controllers)	Minutes to hours
RAID 5	RAID 10	New array, migrate data	Hours (with replication)
RAID 6	RAID 10	New array, migrate data	Hours (with replication)
RAID 10	RAID 6	New array, migrate data	Hours (rarely done)
Smaller array	Larger array	Add drives, expand (if supported)	Minutes to hours
Smaller array	Larger array	New array, migrate data	Hours

Online Migration Strategies:

For minimal downtime, consider:

Database Replication: Set up replica on new storage, failover when synchronized
Storage-Level Replication: SAN/NAS features for mirroring to new arrays
Live Migration (Software RAID): ZFS, LVM, and similar can add/remove devices live
Controller Online RAID Migration: Some controllers migrate RAID levels without dismounting

Evolution Planning:

When you can't predict future needs exactly:

Prefer flexible architectures: Software RAID (ZFS, LVM) adapts more easily than hardware RAID
Don't over-optimize for today: A slightly oversized configuration prevents painful migration later
Modular expansion: Multiple smaller arrays can be expanded independently
Document capacity thresholds: Know when you'll need to expand before it's urgent

The Cloud Option

For environments where storage needs are unpredictable, cloud block storage (AWS EBS, Azure Managed Disks, GCP Persistent Disk) eliminates RAID complexity. The provider handles redundancy; you pay for capacity and IOPS. This isn't always cost-effective, but it eliminates migration planning entirely.

Modern Alternatives and Hybrid Approaches

Traditional RAID levels aren't the only options. Modern storage architectures offer alternatives worth considering.

ZFS and Software-Defined Storage:

ZFS combines volume management, RAID, and filesystem into an integrated system:

RAIDZ1/RAIDZ2/RAIDZ3: Similar to RAID 5/6/triple-parity, but with end-to-end checksumming
Mirror vdevs: Like RAID 10, with self-healing from checksums
Variable stripe width: Optimizes for different workloads automatically
Copy-on-write: Eliminates write hole; consistent on-disk state always
Native snapshots and clones: Point-in-time copies without additional RAID configuration

When to Consider ZFS Over Traditional RAID

•Data integrity is paramount: ZFS checksums detect and correct silent corruption
•Flexible expansion needed: Add vdevs without predefined sizing
•Snapshot/clone capability required: Native support without additional tools
•Mixed workloads: ZFS ARC and L2ARC provide intelligent caching
•Budget constraints: Eliminates hardware RAID controller cost
•Linux/BSD environment: Mature, well-supported on these platforms

Erasure Coding:

Distributed storage systems (Ceph, HDFS, object storage) use erasure coding—a generalized form of parity that can be tuned for specific durability/efficiency tradeoffs:

Reed-Solomon variants: Can tolerate any K of N failures (configurable)
Example: 8+2 erasure coding tolerates any 2 drive failures with 80% efficiency
Trade-off: Higher compute overhead than simple RAID; better suited for cold/warm data

Tiered Storage:

Combine RAID levels based on data temperature:

Hot tier: RAID 10 on NVMe for active database pages and transaction logs
Warm tier: RAID 6 on SAS SSD for older data, indexes
Cold tier: RAID 6 on HDD or object storage for archives

Automatic tiering (available in enterprise storage arrays and ZFS) moves data between tiers based on access patterns.

Storage Technology Comparison
Technology	Best For	Complexity	Cost
Hardware RAID	Traditional enterprise, VMware, simple deployments	Low	High (controller)
Linux MD RAID	Linux servers, cost-sensitive deployments	Medium	Low
ZFS	Data integrity critical, flexible requirements	Medium-High	Low (CPU overhead)
Storage Arrays (SAN/NAS)	Enterprise, shared storage, VMware	Medium	Very High
Cloud Block Storage	Variable needs, operational simplicity	Low	Variable
Distributed Erasure Coding	Large-scale object storage, cold data	High	Low per-GB

Evaluate, Don't Assume

Many organizations default to hardware RAID because 'that's how it's always been done.' Modern software-defined storage often provides better features, flexibility, and even performance at lower cost. Evaluate alternatives for each new deployment.

Database-Specific RAID Recommendations

Different database systems have specific recommendations based on their I/O patterns and architecture. Here are guidelines for major database platforms.

RAID Recommendations by Database Platform
Database	Component	Recommended RAID	Notes
PostgreSQL	Data directory (PGDATA)	RAID 10	Random R/W, latency-sensitive
PostgreSQL	WAL (pg_wal)	RAID 10 or RAID 1	Sequential write, durability critical
PostgreSQL	Temp tablespace	RAID 10 or RAID 0	Regenerable, performance over durability
MySQL/MariaDB	InnoDB data	RAID 10	Random R/W, latency-sensitive
MySQL/MariaDB	Binary logs	RAID 10 or RAID 1	Sequential write, critical for replication
MySQL/MariaDB	InnoDB logs	Same as data or RAID 1	Often same volume as data
Oracle	Data files	RAID 10	Oracle's own recommendation
Oracle	Redo logs	RAID 10 or RAID 1	Multiplexed, sequential write
Oracle	Archive logs	RAID 6	Sequential, capacity matters
SQL Server	Data files (.mdf)	RAID 10	Random R/W dominant
SQL Server	Log files (.ldf)	RAID 10 or RAID 1	Sequential write, latency-critical
SQL Server	TempDB	RAID 10	Heavy random I/O, regenerable
MongoDB	Data directory	RAID 10	Random R/W with journaling
Cassandra	Data (SSTables)	RAID 0 or RAID 10	Replication handles durability

Cassandra and Distributed Databases

Distributed databases like Cassandra, CockroachDB, and TiDB replicate data across multiple nodes. RAID becomes less critical at the node level—some deployments use RAID 0 or even JBOD (raw disks). However, RAID still helps by reducing operational overhead of node failures and speeding recovery.

Cloud Database Storage:

Cloud-managed databases abstract RAID entirely:

Cloud Service	Storage Type	RAID Equivalent
AWS RDS	EBS gp3/io2	Provider-managed, replicated
AWS Aurora	Distributed storage	6-way replication across AZs
Azure SQL Database	Managed storage	Provider-managed
Google Cloud SQL	Persistent Disk	Provider-managed replication

For cloud deployments, focus on selecting the right storage class (IOPS, throughput) rather than RAID configuration.

Summary: RAID Selection Mastery

We've completed a comprehensive examination of RAID technology for database systems. Let's consolidate the key takeaways from this entire module:

RAID Module Key Takeaways

•RAID fundamentals: Striping provides performance, mirroring and parity provide redundancy. All RAID combines these building blocks differently.
•RAID 5 is obsolete for large drives: URE probability during rebuild makes RAID 5 unacceptable for drives larger than 1-2TB.
•RAID 10 is the gold standard for databases: No write penalty, fast rebuilds, predictable performance—worth the 50% capacity overhead.
•RAID 6 is appropriate for read-heavy workloads: When capacity efficiency matters and write performance is less critical.
•Performance depends on workload pattern: Random I/O needs IOPS; sequential I/O needs throughput. Match RAID to workload.
•Degraded mode matters: RAID 10's minimal degraded impact often makes it more reliable in practice than RAID 6's guaranteed 2-drive tolerance.
•RAID is not backup: RAID protects against hardware failure. Backups protect against everything else.
•Consider modern alternatives: ZFS and software-defined storage often provide superior features at lower cost.
•Document, test, and monitor: RAID configuration should be documented, tested with failure scenarios, and continuously monitored.

Decision Summary for Database Architects:

When in doubt, use RAID 10 for database data files and transaction logs
Use RAID 6 for backup storage, read-heavy data warehouses, and large archival datasets
Never use RAID 5 for new deployments with modern drive sizes
Consider ZFS for Linux/BSD environments where data integrity and flexibility matter
Separate transaction logs from data onto dedicated RAID 1 or RAID 10 arrays
Plan for growth and migration from the beginning

Module Complete

Congratulations! You've mastered RAID storage technology for database systems. You understand the concepts, can calculate performance and reliability, know how to select appropriate RAID levels, and can implement and manage RAID arrays for production database workloads. This knowledge forms the foundation for designing resilient, high-performance database storage architectures.