Linux 存储高可用性设计：RAID、DRBD 与分布式存储的冗余策略

一、存储高可用性为何重要？

想象公司的服务器硬盘突然冒烟宕机，导致核心数据库停摆。如果用普通单盘存储，这种物理故障会直接造成业务中断，此时冗余存储方案的价值就凸显出来了。在Linux生态中，RAID、DRBD与分布式存储构成了存储高可用的三种经典技术路线，本文将用大量可落地的示例解读它们的核心逻辑。

二、硬件级冗余的基石：RAID实战解析

（技术栈：Linux mdadm）

1. RAID方案对比表

2. 创建RAID5阵列实例

sudo yum install mdadm -y

# 清空四块硬盘原有数据（假设为sdb、sdc、sdd、sde）
sudo mdadm --zero-superblock /dev/sd[b-e]

# 创建RAID5阵列（预留一块热备盘）
sudo mdadm --create /dev/md0 --level=5 --raid-devices=3 --spare-devices=1 /dev/sd[b-e]

# 验证阵列状态（Observe重建进度）
watch -n1 "cat /proc/mdstat"

# 持久化配置（防止重启失效）
echo "DEVICE /dev/sd[b-e]" | sudo tee -a /etc/mdadm.conf
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf

3. 典型故障处理

# 模拟sdb磁盘故障
sudo mdadm /dev/md0 --fail /dev/sdb

# 查看热备盘自动接管（State应显示spare rebuilding）
sudo mdadm --detail /dev/md0

# 移除故障盘并添加新盘
sudo mdadm /dev/md0 --remove /dev/sdb
sudo mdadm /dev/md0 --add /dev/sdf

4. 技术点评

优势：硬件兼容性强、恢复流程成熟
缺点：容量扩展困难、无法跨节点同步
适用场景：单机MySQL数据库存储、虚拟机镜像存储池

三、跨节点数据同步：DRBD双机热备

（技术栈：DRBD 9.x）

1. 双节点架构示意图

Primary节点（Active） ↔ 10G网络 ↔ Secondary节点（Standby）
      ↓                          ↗
  本地磁盘                  实时数据同步

2. 全流程配置示例

# 在两台主机安装DRBD（Ubuntu环境）
sudo apt install drbd-dkms drbd-utils -y

# 创建资源配置文件（/etc/drbd.d/db.res）
resource db {
    device    /dev/drbd0;
    disk      /dev/sdb1;
    meta-disk internal;

    on node1 {
        address    192.168.1.100:7788;
    }

    on node2 {
        address    192.168.1.101:7788;
    }

    net {
        # 启用数据压缩（适合带宽受限场景）
        compression algo lz4;
    }
}

# 初始化元数据（双节点执行）
sudo drbdadm create-md db
sudo systemctl start drbd

# 设置主节点
sudo drbdadm primary db --force

# 验证同步状态（显示UpToDate即正常）
sudo drbdadm status db

3. 数据切换演练

# 主节点宕机时执行切换
# 在备节点提升为主
sudo drbdadm primary db

# 原主节点恢复后重新同步
sudo drbdadm connect db

4. 技术纵深

网络要求：建议专用心跳线+数据同步双通道
注意事项：

• 避免"双主"状态导致数据分裂
• 同步延迟需监控（drbd-overview工具）
  典型应用：Keepalived双主高可用、Oracle RAC共享存储

四、横向扩展的终极方案：Ceph分布式存储

（技术栈：Ceph Luminous）

1. 基础架构拓扑

  Client
    │
    ↓
[Monitor集群] → 维护集群拓扑
    │
    ↓  
[OSD节点] × 3 → 物理磁盘集合
    │
    ↓
[CRUSH算法] → 动态数据分布

2. 三节点集群部署

# 节点规划（node1为admin节点）
ceph-deploy new node1 node2 node3

# 初始化Monitor（生成初始配置）
ceph-deploy mon create-initial

# 部署OSD（每个节点2块硬盘）
ceph-deploy osd create node1:/dev/sdb node1:/dev/sdc
ceph-deploy osd create node2:/dev/sdb node2:/dev/sdc  
ceph-deploy osd create node3:/dev/sdb node3:/dev/sdc

# 创建存储池（副本数为3）
ceph osd pool create mypool 128 128 replicated
ceph osd pool set mypool size 3

3. 客户端挂载验证

# 创建RBD镜像
rbd create myimg --size 10240 --pool mypool

# 映射到本地
rbd map myimg --pool mypool

# 文件系统格式化
mkfs.ext4 /dev/rbd0

# 实时容量监控
ceph df

4. 核心技术特征

数据冗余：支持副本与纠删码两种模式
恢复机制：增量恢复、并行回填技术
扩展瓶颈：Monitors数量不宜超过5个（可用Paxos优化）

五、选型决策指南与实施注意事项

1. 决策树分析

                  单机冗余需求 → 选择RAID
                   │
                   ├─ 双节点实时同步 → DRBD
                   │
                   └─ 三节点以上扩展 → Ceph

2. 硬件配套建议

• RAID：建议使用BBU缓存卡提升性能
• DRBD：万兆网络延迟应<2ms
• Ceph：SSD作为Journal盘可提升吞吐量

3. 数据一致性保障

• RAID：重建期间避免写入密集型操作
• DRBD：启用双主仲裁（quorum服务）
• Ceph：设置合理的PG数量（公式：总PG = (OSD数 × 100)/副本数）

六、技术演进与未来展望

随着NVMe-oF技术的普及，RDMA网络逐渐成为高速存储方案的标配。在Kubernetes生态中，Rook项目正在将Ceph容器化部署推向主流，而新一代分布式存储如MinIO则在对象存储领域开辟了新赛道。但无论技术如何变化，数据分片算法、副本策略和故障自愈机制始终是高可用存储的三大核心支柱。