CDH初期集群構建方案建議

集群規模計算
集群規模取決于用戶數據及應用需求，最終規劃值為以下各種計算方式得出的最小集群規模的最大值
? 容量需求
– 估算相對容易且準確
– 大多數案例可以通過容量來決定集群規模
? 計算需求
– 準確的估算計算資源只能通過小規模測試并合理估算
? 其他資源限制
– 如用戶MapReduce應用可能對內存等資源有特殊要求，且單節點可配置資源相對有限，則集群最小規模需滿足用戶此類資源要求

網絡建議
? 建議使用萬兆網絡或更高速度網絡
– 如要充分利用磁盤并行操作帶寬，至少需要萬兆網絡
– 即使帶寬足夠，使用高帶寬網絡也能帶來性能提升
? 對網絡帶寬敏感的場景：
– ETL類型或其他高輸入輸出數據量的MapReduce任務
– 對于空間或者電力資源有限的環境中，可使用大容量節點并配合高速度網絡
– HBase等時延敏感類應用也對網絡傳輸速度有要求

傳統樹狀網絡
? 網絡超額(Oversubscription)
– 通過增加層次擴充網絡，但會有如下問題
– 節點間網絡距離增加
– 網絡超額問題惡化
? 因此盡量采用超多端×××換機或擴充交換機背板擴充端口容量
– 小型或中型網絡可以使用雙層樹形架構
– 僅通過頂層交換機上行端口和外部系統進行交互
– 避免Hadoop的網絡傳輸風暴污染外部網絡

組件架構
? 管理節點(Head/Master Node)：如NameNode, Yarn及Master等
– 提供關鍵的、集中的、無替代的集群管理服務
– 若該管理服務停止，則對應集群Hadoop服務停止
– 需要可靠性高的硬件設備
? 數據節點(Data/Worker/Slave Node)
– 處理實際任務，如數據存儲，子任務執行等
– 同節點運行多個服務，為保證局部性
– 若該服務停止，則由其他節點自動代替服務
– 硬件各部件皆可能損壞，但能方便的替換
? 邊緣節點(Edge Node)
– 對外提供Hadoop服務代理以及包裝
– 作為客戶端訪問實際Hadoop服務
– 需要可靠性高的硬件設備

管理節點硬件要求
? 管理節點角色主要包括NameNode，Secondary NameNode，Yarn RM
– Hive Meta Server以及Hive Server通常部署在管理節點服務器上
– Zookeeper Server以及Hmaster可以選取數據節點服務器，由于一般負載有限，對節點無太大特殊要求
– 所有HA候選服務器(Active以及Standby)使用相同配置
– 通常對內存要求高但對存儲要求低
? 建議使用高端PC服務器甚至小型機服務器，以提高性能和可靠性
– 雙電源、冗余風扇、網卡聚合、RAID…
– 系統盤使用RAID1
– 由于管理節點數目很少且重要性高，高配置一般不是問題

數據節點配置策略建議
? 數量少但單點性能高的集群 vs. 數量多但單點性能低的集群
– 一般而言，使用更多的機器而不是升級服務器配置
– 采購主流的最”合算”配置的服務器，可以降低整體成本
– 數據多分布可獲得更好的scale-out并行性能以及可靠性
– 需要考慮物理空間、網絡規模以及其他配套設備等綜合因素來
? 考慮集群服務器數目
– 計算密集型應用考慮使用更好的CPU以及更多的內存

內存需求計算
? 需要大內存的主節點角色：
– NameNode, Secondary NameNode,YARN AM, Hbase Regionserver
? 節點內存算法：
– 大內存角色內存相加
– 計算類應用需要大內存，如Spark/Impala建議至少256GB內存

硬盤容量選擇
? 通常建議使用更多數目的硬盤
– 獲得更好的并行能力
– 不同的任務可以訪問不同的磁盤
– 8個1.5TB的硬盤性能好于6個2TB的硬盤
– 除去數據永久存儲需求外，一般建議預留20%至30%的空間用于存儲臨時數據
? MapReduce任務中間數據
? 實際部署中每服務器配備12個硬盤非常常見
– 單節點存儲容量最大值不超過48TB

存儲服務需求

服務器配置建議