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

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

本文让我们将「旅行团分车」的比喻转化为真实的云计算场景，用 集群节点组（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}; doaws 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}; doaws 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}; doaws 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 个）

⭐ 最终分布：

宿主机	节点类型
H1	Master-1 + Task-9
H2	Master-2 + Task-10
H3	Master-3 + Task-11
H4	Core-1 + Task-12
…	…
H9	Task-1~4（集中部署）
H10	Task-5~8（集中部署）

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

假设 H9 宿主机故障：

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

✅ 关键效果：

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

3.技术组件对应表

云计算场景	说明
Master 组	集群大脑（如 Spark Master），需最高可用性
Core 组	核心服务（如 HDFS DataNode），需高可用
Task 组	弹性计算单元（如 Spark Executor），可容忍适度故障
反亲和性云主机组	声明 “同组节点必须物理隔离” 的策略载体
宿主机（H1~H10）	物理服务器，承载虚拟化的云主机
软性策略（Task 组）	资源不足时允许策略妥协，避免节点创建失败

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)"]
]

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

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