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