FusionInsight MRS配置機架策略最佳實踐

大型集群的所有主機通常分布在多個機架上，不同機架間的主機通過交換機進行數據通信，且同一機架上的不同機器間的網絡帶寬要遠大于不同機架機器間的網絡帶寬。在這種情況下網絡拓撲規劃應滿足以下要求：

為了提高通信速率，希望不同主機之間的通信能夠盡量發生在同一個機架之內，而不是跨機架。

為了提高容錯能力，分布式服務的進程或數據需要盡可能存在多個機架的不同主機上。

Hadoop使用一種類似于文件目錄結構的方式來表示主機。兩層網絡的集群如下圖所示，Node1的Rack建議設置為/Switch1/Rack1，Node4的Rack建議設置為/Switch1/Rack2。

由于HDFS不能自動判斷集群中各個DataNode的網絡拓撲情況，管理員需設置機架名稱來確定主機所處的機架，NameNode才能繪出DataNode的網絡拓撲圖，并盡可能將DataNode的數據備份在不同機架中。同理，YARN需要獲取機架信息，在可允許的范圍內將任務分配給不同的NodeManager執行。

當集群網絡拓撲發生變化時，需要使用FusionInsight Manager為主機重新分配機架，相關服務才會自動調整。

修改主機機架名稱，將影響HDFS的副本存放策略、Yarn的任務分配及Kafka的Partion存儲位置。修改后需重啟HDFS、Yarn和Kafka，使配置信息生效。

不合理的機架配置會導致集群的節點之間的負載（包括CPU、內存、磁盤、網絡）不平衡，降低集群的可靠性，影響集群的穩定運行。所以在分配機架之前，需要進行全局的統籌，合理地設置機架。

策略 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臺主機。

機架劃分示例如下：

EI企業智能 FusionInsight Hadoop MapReduce

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。