组建纠删码卷

[igweek]

实验题目：构建企业级“高性价比”云盘存储——纠删码卷（Dispersed Volume）实战

1. 背景

你是一家初创云存储公司的首席架构师。

• 痛点：公司资金有限，买了 3 台服务器（每台 10GB）。如果用“复制卷（Replica 3）”，用户只能存 10GB 数据，太费钱，客户不买账；如果用“分布式卷”，坏一台机器数据全丢，口碑会烂。
• 老板的需求：
  1. 空间要大：3 台 10GB 硬盘，至少要给客户提供 20GB 的可用空间。
  2. 安全性要保：必须允许任意坏掉 1 台机器，数据不能丢。
• 你的方案：部署 纠删码卷（Dispersed Volume）。利用数学校验（Erasure Coding）技术，实现“损耗 1 台的容量，换取 1 台的容错”。

---

2. 实验详细步骤（基于 3 台 Ubuntu 22.04）

第一阶段：物理盘准备（Node1, Node2, Node3 同步执行）

1. 新增磁盘：VMware 各添加一块 10GB 硬盘。
2. 格式化与挂载：

   sudo mkfs.xfs /dev/sdb
   sudo mkdir -p /data/ec_bricks
   sudo mount /dev/sdb /data/ec_bricks
   echo "/dev/sdb /data/ec_bricks xfs defaults 0 0" | sudo tee -a /etc/fstab

3. 安装服务：

   sudo apt update && sudo apt install glusterfs-server -y
   sudo systemctl enable --now glusterd

第二阶段：建立集群（仅在 Node1 执行）

sudo gluster peer probe 192.168.10.12  # Node2
sudo gluster peer probe 192.168.10.13  # Node3

# 检查朋友圈，确保 3 台都连通
sudo gluster peer status

第三阶段：创建纠删码卷（核心逻辑）

这里我们需要定义两个参数：disperse（总块数）和 redundancy（冗余块数）。

1. 创建卷：

   # disperse 3 表示总共 3 个节点参与
   # redundancy 1 表示允许坏掉 1 台（系统会自动拿 1 台的量做校验）
   sudo gluster volume create cloud-disk disperse 3 redundancy 1 \
   192.168.10.11:/data/ec_bricks/br1 \
   192.168.10.12:/data/ec_bricks/br1 \
   192.168.10.13:/data/ec_bricks/br1 force

2. 启动卷：

   sudo gluster volume start cloud-disk

第四阶段：业务挂载与验证（Client 节点执行）

1. 挂载：

   sudo mount -t glusterfs 192.168.10.11:/cloud-disk /mnt/cloud

2. 容量奇迹：

   df -h /mnt/cloud
   # 结果应为 20GB！

   • 解释：如果是复制卷（Replica 3），这里只有 10GB。纠删码通过数学算法，只浪费了 1/3 的空间就实现了备份。

---

3. 深度解释：它是怎么“算”出来的？

当你往 /mnt/cloud 存入一个文件 hello.txt 时，GlusterFS 不再是简单地把文件扔进某台机器，而是：

1. 切片：把文件切成 2 个数据块（Data Blocks）。
2. 计算：根据这 2 个块，通过数学公式算出 1 个校验块（Parity Block）。
3. 分发：把这 3 个块分别存到 Node1、Node2、Node3。

为什么坏 1 台没事？
假设 Node3 坏了（校验块丢了），剩下 Node1 和 Node2 的原始数据块可以直接拼出文件。
假设 Node1 坏了（数据块丢了），系统会用 Node2 的数据块和 Node3 的校验块，通过反向数学公式计算出 Node1 丢失的内容。

---

4. 实验验证方案

• 验证 1（容量比对）：请解释为什么 3 块 10G 硬盘，在这个模式下可用空间是 20G，而复制卷只有 10G？
  • 答案核心：纠删码利用 $(n-k)$ 公式，只预留了 $k$ 份冗余空间，而不是全量备份。
• 验证 2（压力测试）：在 Client 持续拷贝一个 1GB 的大文件。
  • 观察点：观察 3 台 Node 的 CPU 使用率。你会发现比复制卷高，因为“切片和计算”很耗 CPU。
• 验证 3（容灾）：关闭 Node2。
  • 动作：在客户端执行 cat /mnt/cloud/hello.txt。
  • 结论：依然能秒开！证明了冗余算法的有效性。