|
集群規模計算 集群規模取決于用戶(hù)數據及應用需求，最終規劃值為以下各種計算方式得出的最小集群規模的最大值 ⦁ 容量需求 ⦁ 估算相對容易且準確 ⦁ 大多數案例可以通過(guò)容量來(lái)決定集群規模 ⦁ 計算需求 ⦁ 準確的估算計算資源只能通過(guò)小規模測試并合理估算 ⦁ 其他資源限制 ⦁ 如用戶(hù)MapReduce應用可能對內存等資源有特殊要求，且單節點(diǎn)可配置資源相對有限，則集群最小規模需滿(mǎn)足用戶(hù)此類(lèi)資源要求 網(wǎng)絡(luò )建議 ⦁ 建議使用萬(wàn)兆網(wǎng)絡(luò )或更高速度網(wǎng)絡(luò ) ⦁ 如要充分利用磁盤(pán)并行操作帶寬，至少需要萬(wàn)兆網(wǎng)絡(luò ) ⦁ 即使帶寬足夠，使用高帶寬網(wǎng)絡(luò )也能帶來(lái)性能提升 ⦁ 對網(wǎng)絡(luò )帶寬敏感的場(chǎng)景： ⦁ ETL類(lèi)型或其他高輸入輸出數據量的MapReduce任務(wù) ⦁ 對于空間或者電力資源有限的環(huán)境中，可使用大容量節點(diǎn)并配合高速度網(wǎng)絡(luò ) ⦁ HBase等時(shí)延敏感類(lèi)應用也對網(wǎng)絡(luò )傳輸速度有要求 
傳統樹(shù)狀網(wǎng)絡(luò ) ⦁ 網(wǎng)絡(luò )超額(Oversubscription) ⦁ 通過(guò)增加層次擴充網(wǎng)絡(luò )，但會(huì )有如下問(wèn)題 ⦁ 節點(diǎn)間網(wǎng)絡(luò )距離增加 ⦁ 網(wǎng)絡(luò )超額問(wèn)題惡化 ⦁ 因此盡量采用超多端口交換機或擴充交換機背板擴充端口容量 ⦁ 小型或中型網(wǎng)絡(luò )可以使用雙層樹(shù)形架構 ⦁ 僅通過(guò)頂層交換機上行端口和外部系統進(jìn)行交互 ⦁ 避免Hadoop的網(wǎng)絡(luò )傳輸風(fēng)暴污染外部網(wǎng)絡(luò ) 組件架構 ⦁ 管理節點(diǎn)(Head/Master Node)：如NameNode, Yarn及Master等 ⦁ 提供關(guān)鍵的、集中的、無(wú)替代的集群管理服務(wù) ⦁ 若該管理服務(wù)停止，則對應集群Hadoop服務(wù)停止 ⦁ 需要可靠性高的硬件設備 ⦁ 數據節點(diǎn)(Data/Worker/Slave Node) ⦁ 處理實(shí)際任務(wù)，如數據存儲，子任務(wù)執行等 ⦁ 同節點(diǎn)運行多個(gè)服務(wù)，為保證局部性 ⦁ 若該服務(wù)停止，則由其他節點(diǎn)自動(dòng)代替服務(wù) ⦁ 硬件各部件皆可能損壞，但能方便的替換 ⦁ 邊緣節點(diǎn)(Edge Node) ⦁ 對外提供Hadoop服務(wù)代理以及包裝 ⦁ 作為客戶(hù)端訪(fǎng)問(wèn)實(shí)際Hadoop服務(wù) ⦁ 需要可靠性高的硬件設備 管理節點(diǎn)硬件要求 ⦁ 管理節點(diǎn)角色主要包括NameNode，Secondary NameNode，Yarn RM ⦁ Hive Meta Server以及Hive Server通常部署在管理節點(diǎn)服務(wù)器上 ⦁ Zookeeper Server以及Hmaster可以選取數據節點(diǎn)服務(wù)器，由于一般負載有限，對節點(diǎn)無(wú)太大特殊要求 ⦁ 所有HA候選服務(wù)器(Active以及Standby)使用相同配置 ⦁ 通常對內存要求高但對存儲要求低 ⦁ 建議使用高端PC服務(wù)器甚至小型機服務(wù)器，以提高性能和可靠性 ⦁ 雙電源、冗余風(fēng)扇、網(wǎng)卡聚合、RAID… ⦁ 系統盤(pán)使用RAID1 ⦁ 由于管理節點(diǎn)數目很少且重要性高，高配置一般不是問(wèn)題 數據節點(diǎn)配置策略建議 ⦁ 數量少但單點(diǎn)性能高的集群 vs. 數量多但單點(diǎn)性能低的集群 ⦁ 一般而言，使用更多的機器而不是升級服務(wù)器配置 ⦁ 采購主流的最”合算”配置的服務(wù)器，可以降低整體成本 ⦁ 數據多分布可獲得更好的scale-out并行性能以及可靠性 ⦁ 需要考慮物理空間、網(wǎng)絡(luò )規模以及其他配套設備等綜合因素來(lái) ⦁ 考慮集群服務(wù)器數目 ⦁ 計算密集型應用考慮使用更好的CPU以及更多的內存 內存需求計算 ⦁ 需要大內存的主節點(diǎn)角色： ⦁ NameNode, Secondary NameNode,YARN AM, Hbase Regionserver ⦁ 節點(diǎn)內存算法： ⦁ 大內存角色內存相加 ⦁ 計算類(lèi)應用需要大內存，如Spark/Impala建議至少256GB內存 硬盤(pán)容量選擇 ⦁ 通常建議使用更多數目的硬盤(pán) ⦁ 獲得更好的并行能力 ⦁ 不同的任務(wù)可以訪(fǎng)問(wèn)不同的磁盤(pán) ⦁ 8個(gè)1.5TB的硬盤(pán)性能好于6個(gè)2TB的硬盤(pán) ⦁ 除去數據永久存儲需求外，一般建議預留20%至30%的空間用于存儲臨時(shí)數據 ⦁ MapReduce任務(wù)中間數據 ⦁ 實(shí)際部署中每服務(wù)器配備12個(gè)硬盤(pán)非常常見(jiàn) ⦁ 單節點(diǎn)存儲容量最大值不超過(guò)48TB 存儲服務(wù)需求 數據源 Hadoop方式物理存儲容量 數據節點(diǎn)數量 原始文件 數據量 625T 625TB*3(復制份數)*0.3(壓縮比)/80%(硬盤(pán)利用率)=703TB (只存放明細數據，無(wú)表，無(wú)MR） 按30T每節點(diǎn) 703TB/30*1.05(冗余度)=25臺 Hbase 和 Cassandra 數據服務(wù)：假設歷史數據量為2.6T，每日增量為55G，數據保留365天，3副本 使用壓縮時(shí)： ( 2.6 + 0.055*365 ) *1.3*1.2（key開(kāi)銷(xiāo)）/70%(硬盤(pán)利用率)=51T 按30T每節點(diǎn) 51T/30*1.3(冗余度)=3臺 打開(kāi)WAL時(shí)需增加： region server wal大小(通常小於RS內存的一半) 服務(wù)器配置建議 管理服務(wù)器 數據服務(wù)器 邊緣服務(wù)器 CPU 2*E5-2620v4 2*E5-2620v4 2*E5-2620v4 硬盤(pán) SAS 600GB*4 RAID0+1 SAS 600GB*2 SATA 2T*15 SAS 600GB*2 SATA 2T*15 內存 256G ECC 256G ECC 256G ECC 網(wǎng)絡(luò ) 雙萬(wàn)兆網(wǎng)卡 雙萬(wàn)兆網(wǎng)卡 雙萬(wàn)兆網(wǎng)卡 數量 3 30 3 文件來(lái)源于www.bemore.cn |
