如何搭建一個易於維護的 Hadoop 叢集？

光光頭去打醬油發表於2016-08-25
Hadoop

學習如何搭建一個易於維護的hadoop叢集。

之前，關於部署Apache Hadoop的硬體選擇上，我們發表了一些推薦規範。那篇文章就叢集規劃和部署方面提出了一些不錯的想法。比如工作負載分析，CPU、磁碟、記憶體分配相關的建議。這篇文章我們將對下一實施步驟提供最佳的實踐指導：等機器一到，我們就能開始配置機器了。通過這兩篇文章，你就可以向著部署一個完美Hadoop生產壞境的目標邁出一大步了。

具體的說，我們會討論一些比較重要的決定，你必須保證你的網路，磁碟和hosts配置正確。我們還將介紹根據資料集規模如何正確配置磁碟、服務，讓資源高效利用以及問題最小化。

Networking: May All Your SYNs Be Forgiven

Hadoop的Java程式，如DataNode得到其所在執行主機的主機名，然後查詢這個主機名以確定IP地址。再根據這個IP來確定儲存在DNS或/ etc/ hosts中的規範名稱。每個主機必須保證其主機名能夠進行正向解析，使用其IP地址進行反向解析。此外，叢集中的所有主機要能夠解析到其他主機。可以使用Linux命令來驗證正向和反向解析配置是否正確。

Cloudera Manager使用Python命令來測試配置是否正確。

這一步配置/etc/hosts檔案很容易就能達到目的，但是我們推薦使用DNS。DNS和hosts檔案相比，前者更不容易出錯，而且修改起來也很方便。主機名應該使用全稱域名（FQDN）。啟用像TLS加密和Kerberos等安全功能時要注意，使用Kerberos需要用到FQDNs。你可以用下面的命令進行驗證

如果你使用/etc/hosts，那麼要確保是正確的順序。

名稱快取服務

Hadoop中使用了大量的網路服務，像DNS、NIS和LDAP。以幫助解決網路問題，緩解共享基礎裝置的壓力，改善名稱解析的延遲，有助於守護名稱快取服務程式（NSCD）。NSCD將本地和遠端查詢的結果快取在記憶體中，來減少潛在的網路傳輸成本。大多數情況下，你可以啟用NSCD,讓它一直工作著，不用管它。但是如果你執行了Red Hat SSSD，那就需要修改NSCD配置。啟動SSSD後，不要用NSCD快取密碼、組或者網路組資訊。

鏈路聚合

也被稱為NIC繫結或NIC聚合，這指的是結合網路介面，以提高吞吐量和冗餘。具體的設定取決於你的實際環境。

有許多不同的繫結介面的方法。通常情況下，我們建議結合吞吐量來考慮，而不是可用性，但實際上很大程度上取決於介面的數量和內部網路策略。NIC繫結是Cloudera對錯誤配置的最終武器之一。我們建議在啟用繫結之前先驗證叢集的狀態，這將有助於定位到您可能遇到的任何問題。

多連線網路

另一個常被問到的問題是Hadoop能否處理不同網路層的介面。HDFS文件上有一些幫助資訊，將Hadoop節點網路從“管理”網路分離出來，從邏輯上來說是有意義的。然後以我們的經驗來看，多連線網路在配置和技術支援方面是十分棘手的。痛苦源於Hadoop整合的元件是一個大的生態系統，它們都有自己的網路和繫結埠的設定。新的元件可能無法根據你的設定繫結到特定的網路或者通用的地址上。首先設定你的網路不使用多連線可以避免很多麻煩，並能讓你的叢集保持在同一個網路中，這是十分有利的。如果你確定一切都設定正確了，然後再回頭加入“管理”網路。

VLAN

VLANs不是必須的，但從網路角度看，它們可以使事情變得簡單。建議將生產環境部署到專用交換基礎裝置上，與網路上其他業務通訊更加便利。然後確保所有Hadoop業務在一個VLAN中，便於故障診斷和隔離。

Operating System (OS)

Cloudera Manager能夠很好的識別作業系統配置中一些常見的問題，但請仔細檢查以下配置：

IPTables

一些使用者在初始化叢集設定時會完全禁用IPTables。在管理方面看這麼做無疑使得一些操作變得簡單了，但是也增加了一些風險。根據叢集中資料的敏感度，適當啟用IPTables。Hadoop中的元件佔用了許多埠來進行通訊，不過我們的文件將有助於定位具體是哪些埠。

SELinux

在Hadoop生態系統中控制所有不同版本的元件，構造一個SELinux策略是具有挑戰性的。所以大部分使用者都禁用SELinux。如果你對SELinux有興趣的話，一定要確認你使用的版本是一個受支援的作業系統版本。開始我們建議使用permissive模式，這樣就可以捕獲輸出，定義一個滿足需求的策略。

Swappiness

傳統方案是將工作節點的swappiness (vm.swappiness)設定為0。不過這個設定在新的核心中有所改變，我們現在建議將其設定為1。（這個帖子裡有更多的細節。）

Limits

預設檔案控制程式碼範圍(又名ulimit)設定為1024，對大多數發行版可能設定的不夠高。Cloudera Manager將會解決這個問題，但是如果你沒有使用Cloudera Manager，也要注意這個問題。Cloudera Manager不會改變Hadoop預設設定以外的使用者設定。然後，將全侷限制提高到64k是有益的。

Transparent Huge Pages (THP)

大部分Linux平臺都支援CDh3 中一個名叫Transparent Huge Page壓縮的特性，其在Hadoop工作負載方面互動很差，會嚴重影響效能。Red Hat聲稱過去在6.4版本中修復了這個bug，但是仍有餘留問題會影響到效能。我們建議禁用磁碟碎片整理，除非bug被真正解決。

Red Hat/CentOS: /sys/kernel/mm/redhat_transparent_hugepage/defrag
Ubuntu/Debian, OEL, SLES: /sys/kernel/mm/transparent_hugepage/defrag

記住將這行命令新增到/etc/rc.local 檔案中，使機器重啟後仍然有效。

Time

確保所有的主機啟用了NTP。

Storage

為叢集配置適當的儲存層是初始化最重要的一步。配置不當的話後期修改配置會是十分痛苦的，還可能被入侵，通常需要完全重做儲存層。

OS, Log Drives and Data Drives

傳統的2U伺服器配置了16-24個專用的資料磁碟擴充套件槽，還有一些（通常是兩個）擴充套件槽留給系統盤和日誌儲存盤。Hadoop的設計有一個簡單的原則：“硬體容錯。”因此就算一個磁碟一個節點甚至一個機櫃發生故障，它也能正常執行。（這一原則真的適合這種大規模的叢集，不過讓我們面對事實吧。如果你正在閱讀這篇文章，你肯定不在Google或者Facebook工作。）

即使正常規模（少於4000個節點），Hadoop也能在硬體故障中很好的維持正常執行，但是仍應該設計一些冗餘來減少這些硬體錯誤。作為一般準則，我們建議對系統盤使用 RAID-1（備份），這樣即使資料節點失去系統盤也能很快的恢復。雖然這一步不是絕對必要的，在較小的叢集中失去一個節點可能導致計算能力顯著的下降。

其他磁碟應該部署為一個JBOD(Just a Bunch Of Disks，磁碟簇)，使用ext4分割槽，作業系統為RHEL6+、Debian 7.x、 或 SLES11+。在某些硬體配置檔案,RAID控制器是為一些特定機器構建的，那麼RAID-0卷必須使用。這種方法和增加磁碟作為單個spindles具有相同的效果。

有一些安裝選項是十分有用的，這些選項在Alex Moundalexis的Hadoop Operations一書中詳細進行了介紹，這就不再重複了。

Root Reserved Space

預設情況下，ext3、ext4檔案系統都會有5%的預留空間給root使用者。這對於HDFS資料目錄來說是不需要的，不過你可以在建立分割槽的時候把它調整為0，或者使用mkfs、tune2fs命令將其調整為0。

檔案訪問時間

Linux檔案系統會維護檔案訪問記錄的後設資料，每當一個檔案被訪問，甚至讀取結果等記錄都會被寫入到磁碟上。這種時間戳被稱為atime，Hadoop中應該禁用這項功能。通過修改/etc/fstab中的配置可以設定：

無需重啟即可生效。

Directory Permissions 目錄許可權

這是一個小問題，但是還是要注意，在掛載資料磁碟之前將目錄的許可權設定為700。這樣的話一旦資料磁碟被解除安裝了，沒有被作業系統裝載的情況下還是可以寫入到這個目錄的。

LVM, RAID or JBOD

經常有人詢問JBOD 、RAID或者LVM是否必須的。記住整個Hadoop生態系統隨著JBOD一起建立的。HDFS是專為大檔案順序讀取設計的不可變檔案系統。這個目標已經基本達到了，在獨立的SATA硬碟上取得了順序讀取的最優效能。總之，RAID通常用來為現有系統增加冗餘，HDFS已經內建該特性。實際上在Hadoop上使用RAID反而會降低系統的效能。

RAID-5和RAID-6都增加了奇偶校驗的功能。這給標準讀/寫操作帶來顯著的開銷。獨立的SATA硬碟可以連續讀/寫不用擔心奇偶校驗，因為它沒有這項功能。相比之下,HDFS利用其眾多單獨掛載點,可以允許單個驅動器/卷在節點故障前出現錯誤——HDFS不那麼神祕的並行I / O武器。在硬碟上設定RAID-5或RAID-6陣列時，會建立一個或幾個擁有許多掛載點的巨大硬碟陣列，具體取決於硬碟設定。這些RAID陣列會削弱HDFS原生的資料保護功能，降低順序讀效能，破壞Map tasks的資料區域性性。

RAID也會影響在眾多掛載點上的其他系統。舉個例子，Impala會在每個系統中的spindle 進行執行緒加速，JBOD環境VS單個巨大的RAID陣列組，哪個環境更適合呢。同樣的原因，在Hadoop中使用LVM既不需要也不推薦。

部署環境硬體種類多樣化

許多使用者定期的採購新的硬體，因為隨著資料量和工作量的增長，增加新一代的計算機硬體資源是有意義的。對於含有異構磁碟、記憶體或CPU配置這樣的環境中，Cloudera Manager允許管理員為每個節點或節點組指定記憶體，YARN容器和Cgroup設定的角色組。

雖然Hadoop能夠在硬體規格不一的環境上執行，如果可以的話，我們還是建議工作節點上的配置保持一致。在分散式計算環境中，工作負載分佈在各個節點，本地資料優先訪問是比較好的。計算資源較少的節點可能會成為瓶頸，而採用混合硬體配置可能會導致SLA視窗期變寬。下面這些值得去思考的：

  • 混合spindle配置—HDFS預設block會已迴圈的方式放入由dfs.data.dir指定的目錄中。例如，有6個1.2T的磁碟，6個600G的磁碟，較小的磁碟最快被填滿，導致剩餘容量不平衡。使用可用空間策略需要額外配置，並且在這種情況下I / O密集型工作負載可能會受到影響，可能全部被寫入到磁碟的一個子集。預先了解這種情況下部署磁碟帶來的影響。此外，如果你要部署更加全面的儲存節點，記住HDFS的剩餘空間是按照百分比算的。
  • 混合記憶體配置-混合工作節點的可用記憶體可能會有問題,因為它需要額外的配置。
  • 混合CPU配置-同樣的概念；作業可能受到最慢的那個CPU影響，使用新的CPU或者多核CPU的優勢完全發揮不出來。

弄清上述幾點是很重要的，但是記住Cloudera Manager可以幫助將資源分配到不同的主機，讓您輕鬆地管理和優化配置。

Cloudera Manager Like A Boss

我們強烈建議使用Cloudera Manager來管理Hadoop叢集。Cloudera Manager提供了許多有價值的功能，使得管理更加便利。Cloudera Manager文件中關於這塊的描述已經很清楚了，但是為了杜絕任何含糊之處，下面就是用 Cloudera Manager部署一個生產Hadoop環境的主要步驟。

  1. 建立外部資料庫和預建立需要部署的模式。
  2. 安裝cloudera-manager-server和cloudera-manager-daemons包/文件。
  3. 根據你的資料型別選擇對應的 scm_prepare_database.sh 指令碼執行。
  4. 啟動Cloudera Manager服務，並按照提示進行下一步操作。

這是安裝 Cloudera Manager最簡單的方法，能夠讓你在20分鐘內就緒生產環境部署。

You Play It Out: Services Layout Guide

基於Cloudera Manager的部署，下圖展現了一種比較合理的跨叢集配置方式。

如何搭建一個易於維護的 Hadoop 叢集？

（點選檢視大圖）

在較大的叢集（50個節點以上）中，可能需要5個管理節點，還有為ResourceManager和NameNode服務提供專用的節點。 此外，為Cloudera Manager、Hive Metastore等等部署外部資料庫的情況並不少見，並且額外的HiveServer2或者HMS服務也能部署好。

我們建議每個管理節點分配128GB ,每個工作節點分配256-512GB。記憶體比較便宜，計算引擎越來越依賴於在記憶體中執行，額外的記憶體將被善加利用。

更加深入一些，下面的圖表描述磁碟如何適當的對映到各種服務儲存元件。

如何搭建一個易於維護的 Hadoop 叢集？

如何搭建一個易於維護的 Hadoop 叢集？

我們特意給Cloudera Manager的資料庫使用了LVM,不過RAID 0也是一個不錯的選擇。

如何搭建一個易於維護的 Hadoop 叢集？

總結

具備了相應的知識再去搭建一個Hadoop叢集還是相對簡單的。花一些時間去採購合適的基礎設施，一開始就正確的配置。按照上述的指導方針部署Hadoop，可以避免那些眾多且複雜的配置項，而且最後基本上都能成功。這也能讓你像個大牛一樣，將時間集中在解決實際業務問題。

相關文章