【云计算】云主机的亲和性策略（二）：集群节点组

在上一篇博文《【云计算】云主机的亲和性策略（一）：快乐旅行团》中，我们用「旅行团分车」的比喻来解释云主机组如何实现反亲和性策略。

本文让我们将「旅行团分车」的比喻转化为真实的云计算场景，用 集群节点组（Master / Core / Task）和 宿主机调度 来解释反亲和性策略的实现过程。

1.场景设定

目标：在公有云上部署一个高可用大数据集群（如 Spark 集群），包含三类节点：

• Master 组：$3$ 个管理节点（必须高可用，任意两个不能在同一宿主机）
• Core 组：$5$ 个核心计算节点（承载关键服务，需分散部署）
• Task 组：$20$ 个弹性计算节点（可容忍适度集中）
• ✳️ 要求：同组节点必须分散在不同宿主机上（反亲和性）！

1.1 第一步：创建反亲和性云主机组

在云平台中创建三个独立的 反亲和性组，每组绑定一类节点：

# 创建Master反亲和组（策略：严格分散）
aws ec2 create-placement-group --group-name master-anti-group --strategy spread

# 创建Core反亲和组（策略：严格分散）
aws ec2 create-placement-group --group-name core-anti-group --strategy spread

# 创建Task反亲和组（策略：软性分散，资源不足时可集中）
aws ec2 create-placement-group --group-name task-soft-group --strategy spread

✅ 相当于为三类节点制定独立规则：

• Master 组：必须 1 人/车（宿主机）
• Core 组：必须 1 人/车
• Task 组：尽量 1 人/车，但允许拼车

1.2 第二步：创建节点并加入对应组

1.2.1 创建 Master 节点（3个）

for i in {1..3}; do
  aws ec2 run-instances \
    --placement-group master-anti-group \  # 加入Master组
    --tag-specifications "ResourceType=instance,Tags=[{Key=Role,Value=Master}]" \
    --instance-type m5.xlarge
done

调度规则：每个 Master 必须运行在 不同宿主机（若宿主机不足，则创建失败）

1.2.2 创建 Core 节点（5个）

for i in {1..5}; do
  aws ec2 run-instances \
    --placement-group core-anti-group \    # 加入Core组
    --tag-specifications "ResourceType=instance,Tags=[{Key=Role,Value=Core}]" \
    --instance-type c5.4xlarge
done

调度规则：每个 Core 必须运行在 不同宿主机（且不能与 Master 同机）

1.2.3 创建 Task 节点（20个）

for i in {1..20}; do
  aws ec2 run-instances \
    --placement-group task-soft-group \    # 加入Task组（软性策略）
    --tag-specifications "ResourceType=instance,Tags=[{Key=Role,Value=Task}]" \
    --instance-type t3.medium
done

调度规则：尽量分散，但宿主机资源紧张时可部署到同一宿主机（每宿主机最多 4 个 Task）

1.3 第三步：调度器执行反亲和性逻辑

假设云平台有 10 台宿主机（H1~H10），调度器工作流程如下：

• 1️⃣ 放置 Master 节点
  • ✅ Master-1 → 随机选 H1
  • ✅ Master-2 → 排除 H1 → 选 H2
  • ✅ Master-3 → 排除 H1 / H2 → 选 H3
• 2️⃣ 放置 Core 节点
  • ✅ Core-1 → 排除 H1 / H2 / H3（已有 Master）→ 选 H4
  • ✅ Core-2 → 排除 H4 → 选 H5
  • …
  • ✅ Core-5 → 排除 H4 / H5 / H6 / H7 → 选 H8
• 3️⃣ 放置 Task 节点
  • ✅ Task-1 ~ 4 → 因软性策略，允许放在 H9（每机 4 个）
  • ✅ Task-5 ~ 8 → 放 H10（每机 4 个）
  • ✅ Task-9 ~ 20 → 因 H1-H8 已有Master / Core 但未满，分散部署到 H1-H8（每机 1-2 个）

⭐ 最终分布：

2.故障模拟：宿主机宕机的影响

假设 H9 宿主机故障：

• Master 组：H1 / H2 / H3 节点完好 → 集群管理功能正常
• Core 组：H4 / H5 / H6 / H7 / H8 节点完好 → 核心计算服务正常
• Task 组：H9 上的 Task-1~4 宕机 → 自动迁移到其他宿主机（损失部分算力但可恢复）

✅ 关键效果：

• Master / Core 组因严格反亲和，单宿主机故障 不影响同组其他节点。
• Task 组允许集中部署，故障时损失可控（牺牲部分可用性换取成本优化）。

3.技术组件对应表

4.为什么这样设计？

• Master / Core 组严格反亲和
  • → 避免单宿主机宕机导致 集群管理瘫痪 或 核心数据丢失（如 HDFS 同一块数据的多个副本被分散）。
• Task 组软性反亲和
  • → 计算节点可快速重建，优先保证 资源利用率 和 弹性伸缩能力。
• 分层策略
  • → 不同节点重要性不同，反亲和性强度需差异化（Master > Core > Task）。

5.输出结果验证

通过云平台 API 查看节点分布：

# 查看Master节点位置（每个宿主机仅1个）
aws ec2 describe-instances \
  --filters "Name=tag:Role,Values=Master" \
  --query "Reservations[].Instances[].[InstanceId, Placement.AvailabilityZone]"

# 输出示例：
[
  ["i-001", "us-east-1a (宿主机H1)"],
  ["i-002", "us-east-1b (宿主机H2)"],
  ["i-003", "us-east-1c (宿主机H3)"]
]

💡 这就是公有云反亲和性组的本质：

• 通过组策略约束，让关键节点在物理层面 “保持距离”，当单个宿主机爆炸时，你的集群不会全军覆没！