《云主機的親和性策略》系列，共包含以下文章：

• 1?? 云主機的親和性策略（一）：快樂旅行團
• 2?? 云主機的親和性策略（二）：集群節點組
• 3?? 云主機的親和性策略（三）：云主機 & 宿主機
• 4?? 云主機的親和性策略（四）：云主機組

😊 如果您覺得這篇文章有用 ?? 的話，請給博主一個一鍵三連 🚀🚀🚀 吧 （點贊 🧡、關注 💛、收藏 💚）！！！您的支持 💖💖💖 將激勵 🔥 博主輸出更多優質內容！！！

在上一篇博文《【云計算】云主機的親和性策略（一）：快樂旅行團》中，我們用「旅行團分車」的比喻來解釋云主機組如何實現反親和性策略。

本文讓我們將「旅行團分車」的比喻轉化為真實的云計算場景，用 集群節點組（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)"]
]

💡 這就是公有云反親和性組的本質：

• 通過組策略約束，讓關鍵節點在物理層面 “保持距離”，當單個宿主機爆炸時，你的集群不會全軍覆沒！