操作場景
大型集群的所有主機通常分布在多個機架上，不同機架間的主機通過交換機進行數據通信，且同一機架上的不同機器間的網絡帶寬要遠大于不同機架機器間的網絡帶寬。在這種情況下網絡拓撲規劃應滿足以下要求：
- 為了提高通信速率，希望不同主機之間的通信能夠盡量發生在同一個機架之內，而不是跨機架。
- 為了提高容錯能力，分布式服務的進程或數據需要盡可能存在多個機架的不同主機上。
Hadoop使用一種類似于文件目錄結構的方式來表示主機。兩層網絡的集群如下圖所示，Node1的Rack建議設置為 /Switch1/Rack1 ，Node4的Rack建議設置為 /Switch1/Rack2 。
兩層網絡結構
由于HDFS不能自動判斷集群中各個DataNode的網絡拓撲情況，管理員需設置機架名稱來確定主機所處的機架，NameNode才能繪出DataNode的網絡拓撲圖，并盡可能將DataNode的數據備份在不同機架中。同理，YARN需要獲取機架信息，在可允許的范圍內將任務分配給不同的NodeManager執行。
當集群網絡拓撲發生變化時，需要使用FusionInsight Manager為主機重新分配機架，相關服務才會自動調整。
對系統的影響
修改主機機架名稱，將影響HDFS的副本存放策略、Yarn的任務分配及Kafka的Partition存儲位置。修改后需重啟HDFS、Yarn和Kafka，使配置信息生效。
不合理的機架配置會導致集群的節點之間的負載（包括CPU、內存、磁盤、網絡）不平衡，降低集群的可靠性，影響集群的穩定運行。所以在分配機架之前，需要進行全局的統籌，合理地設置機架。
機架分配策略
說明物理機架：主機所在的真實的機架。
邏輯機架：在FusionInsight Manager中給主機設置的機架名稱。
策略1：每個邏輯機架包含的主機個數基本一致。
策略2：主機所設置的邏輯機架要盡量符合其所在的物理機架。
策略3：如果一個物理機架的主機個數很少，則需要和其他的主機較少的物理機架合并為一個邏輯機架，以滿足策略1。不能將兩個機房的主機合并為一個邏輯機架，否則會引起性能問題。
策略4：如果一個物理機架的主機個數很多，則需要將其分隔為多個邏輯機架，以滿足策略1。不建議物理機架中包含的主機有太大的差異，這樣會降低集群的可靠性。
策略5：建議機架的第一層為默認的“default”或其他值，但在集群中保持一致。
策略6：每個機架所包含的主機個數不能小于3。
策略7：一個集群的邏輯機架數，不建議多于50個（過多則不便于維護）。
最佳實踐示例
假設一個集群，共有主機100臺，分別在兩個機房中：機房A有40臺主機，機房B有60臺主機。在機房A中，物理機架Ra1有11臺主機，物理機架Ra2有29臺。在機房B中，物理機架Rb1有6臺主機，物理機架Rb2有33臺主機，物理機架Rb3有18臺主機，物理機架Rb4有3臺主機。
根據以上的“機架分配策略”，我們設置每個邏輯機架包含20個主機，具體分配如下：
- 邏輯機架/default/racka1: 包含物理機架Ra1的11臺主機，Ra2的9臺主機。
- 邏輯機架/default/racka2: 包含物理機架Ra2的剩余的20臺主機。
- 邏輯機架/default/rackb1: 包含物理機架Rb1的6臺主機，Rb2的13臺主機。
- 邏輯機架/default/rackb2: 包含物理機架Rb2的剩余的20臺主機。
- 邏輯機架/default/rackb3: 包含物理機架Rb3的18臺主機，Rb4的3臺主機。
機架劃分示例如下：
操作步驟
- 登錄FusionInsight Manager。
- 單擊“主機”。
- 勾選待操作主機前的復選框。
- 在“更多”選擇“設置機架”。
- 機架名稱需遵循實際網絡拓撲結構，以層級形式表示；各層級間以斜線“/”隔開。
- 機架命名規則為：“/level1/level2/…”，級別至少為一級，名稱不能為空。機架名稱由字母、數字及下劃線“_”組成，且總長度不超過200個字符。
例如“/default/rack0”。
- 如果待修改機架中所包含的主機中有DataNode實例，請確保所有DataNode實例所在主機的機架名稱的層級一致。否則，會導致配置下發失敗。
- 單擊“確定”，完成機架分配設置。
