Learn RAID - RAID-as-a-Service & Cloud

#Introduction

In the cloud, virtual disks no longer look physical — but the RAID concepts live on. Episode 20 covers how striping, mirroring, and parity are applied in EBS, cloud NVMe, Kubernetes, and Ceph. You'll see that RAID changes form, not existence.

The biggest difference in the cloud: redundancy is already provided by the provider at the lower layers. EBS replicates data across several storage nodes without your knowledge. That's why cloud RAID strategies must be recalculated — mirroring EBS volumes sometimes wastes money, and sometimes is the only way to add IOPS.

#EBS RAID on EC2

#Creating RAID 0 from EBS

The most common need on EC2 is RAID 0 to combine the throughput and IOPS of several EBS volumes. EBS replicates data, so striping on top doesn't need more redundancy:

sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1

The mdadm --create --level=0 command above combines two attached EBS volumes. EBS volumes on modern instances appear as /dev/nvmeNn1. RAID 0 here is purely for performance — redundancy already exists at the EBS layer.

#RAID 10 for Write-heavy Workloads

For databases needing high IOPS plus tolerance to individual volume failures, RAID 10 over four EBS volumes is a common pattern:

sudo mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1

The mdadm --create --level=10 output shows the active array. Before using RAID 10 on EBS, check each volume's IOPS profile: a single provisioned IOPS volume can already exceed many workloads' needs — RAID only adds complexity when truly necessary.

#EBS Snapshots and Backup

EBS has built-in snapshots that capture a volume's state to S3:

aws ec2 create-snapshot --volume-id vol-0abc1234 --description "backup mingguan"

The aws ec2 create-snapshot command creates an EBS snapshot. A snapshot is your backup layer in the cloud — equivalent to a ZFS snapshot, managed by the provider. Use it for recovery when an instance fails.

#Managed RAID and Cloud NVMe

#Services That Hide RAID

Modern clouds offer managed storage that hides RAID details: provisioned IOPS EBS, instance store NVMe, and SAN-like services such as AWS EFS or block volumes on other providers. You don't create arrays — the provider decides placement and replication.

#Instance Store NVMe

Some instances have instance store NVMe — disks attached directly to the instance, very fast but ephemeral (lost when the instance stops). For workloads needing aligned NVMe performance, combine them with striping:

sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1

Striping instance store gives large throughput for caches and temporary data — as long as you're aware the data isn't persistent.

#Object Storage as a Redundancy Layer

#Why Object Storage Goes Beyond RAID

Object storage (S3, R2, GCS) stores data as objects with cross-zone redundancy at the provider layer. This fulfills a dream RAID can't achieve: data that survives even if an entire data room in one location is lost. Use it as the outermost defense layer:

rclone sync /mnt/raid s3:backup-bucket/data

The rclone sync command syncs the array data to an S3 bucket. Combine it with an automated backup cycle to meet the 3-2-1 rule we discussed in episode 12.

#RAID in Kubernetes

#Local Persistent Volumes

In Kubernetes, local persistent volumes expose a node's local disk or array to pods. Local PVs require pods to be scheduled to the right node using affinity. An mdadm array on a node can be exposed as a local PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-md0
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/raid
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - node-storage

The PersistentVolume manifest above exposes /mnt/raid on a specific node as a local PV. The data still lives on the mdadm array; Kubernetes only manages the volume lifecycle.

#Abstraction with Rook and Ceph

For distributed storage that survives node failures, many clusters use Rook, a Kubernetes operator that manages Ceph:

• Ceph distributes data and parity across many nodes — RAID at cluster scale.
• Rook automatically creates pools, manages OSDs, and provides StorageClasses.
• CrushMap determines replica placement independently per node.

With Rook and Ceph, redundancy is no longer tied to one machine — one node dying doesn't stop the data. This is the natural evolution of the RAID concept in the cloud-native era.

#Conclusion

Episode 20 brought you into the cloud and Kubernetes world: RAID 0 and 10 on top of EBS, managed storage hiding RAID details, object storage as a redundancy layer, and local PVs and Rook with Ceph as distributed storage abstractions.

Key takeaways:

• EBS already replicates data; RAID 0 on top is for performance, not redundancy.
• RAID 10 over four EBS volumes for write-heavy workloads needing tolerance.
• EBS snapshots are the standard backup layer in the cloud.
• Instance store NVMe is fast but ephemeral — only for temporary data.
• Object storage provides cross-location redundancy that RAID can't.
• Rook and Ceph deliver RAID at Kubernetes cluster scale.

In the next episode, episode 21, we'll discuss modern features & roadmap — the lockless bitmap and boot fixes in mdadm 4.6, OpenZFS 2.4 with RAIDZ expansion, AnyRaid, and BRT, and the trend toward integrity-oriented software-defined storage. You'll see the RAID technology roadmap.