loading

Resources

26Dec 2017

用改頭換面的方式部署 Cloudera EDH 叢集 - 第一部份

2017 年11 月30 日
作者:Benjamin Vera-Tudela、Brandon Freeman 和Mladen Kovacevic
原文:Cloudrea
 
 

Cloudera 相信,所有公司都應該把握資料的力量以利增進財務收益、降低營運成本以及規避風險。我們提供企業級平台,不限資料容量和種類,允許客戶輕鬆管理、儲存、處理和分析所有資料,實現上述目標。

Cloudera 的Enterprise Data Hub(EDH) 是現代的機器學習與分析平台,經最佳化適合雲端使用。您可以彈性地在公司內部以及雲端上部署儲存服務、核心運算服務以及Cloudera 的Shared Data Experience(SDX) 功能,以最符合財務和營運考量的方式選擇部署模式。無論您在公司內部或雲端部署都必須謹慎考慮,讓解決方案、團隊和組織皆能享有最佳效能和功能。

基礎架構是所有軟體解決方案的核心。基礎架構若缺乏妥善規劃和設計,則應用程式很可能會無法實現他們所承諾的價值。在這樣的基礎架構上執行的Enterprise Data Hub 以及應用程式亦無例外。市場上硬體產品選擇眾多,也往往很難確定哪個元件和組態才能為您的科技專案和商業目標帶來最佳價值。此外,形成生態系統的大量服務與角色也提供了更多不同類型的部署方式。使用案例和工作負載的考量在這裡變得格外重要。最後,隨著雲端出現,把使用案例移轉到雲端時還有許多其他考量。

在您使用Cloudera 導入巨量資料解決方案來應付許多可能出現的使用案例時,無論是內部部署或在雲端,我們試圖透過本篇分為三部份的文章協助您做出最重要的決定。第一部份討論基礎架構考量事項,第二部份討論服務與角色配置,而第三部份則探討雲端部署的考量事項。

 

節點分類

我們先把CDH 叢集的節點依其主要功能進行分類。Cloudera 依據下列命名法將節點分類:

  • 公用程式節點:這類節點提供多種服務協助您順利管理、監視和治理叢集。這類服務可能包括Cloudera Manager (CM) 和相關的Cloudera Management Services (CMS)、代表各種不同服務儲存元資料的metastore RDBMS (若與叢集位於相同位置),以及也許管理員用於備份、部署自訂二進位檔等的自訂程序檔。
  • 主節點:這類節點擁有「主節點」(master) 的角色,一般會管理在分散式叢集之間運作的一系列服務。HDFS NameNode、YARN ResourceManager、Impala Catalog/Statestore、HBase Master Server 以及Kudu Masters 全是主節點角色的例子。
  • 工作節點:這類節點擁有的角色會為相對應的服務執行大部份的運算/ IO 作業。HDFS DataNodes、YARN NodeManagers、HBase RegionServers、Impala Daemons、Kudu Tablet Servers 和Solr Servers 是工作節點角色的例子。
  • 邊緣節點:這類節點含有多個組態、二進位檔和服務,可當作企業網路的其餘部份與EDH 叢集之間的閘道器。許多CDH 服務會隨附常駐在這裡「閘道器角色」,以及執行REST API 呼叫的端點和來自企業網路的JDBC/ODBC 型連線。若企業網路流量僅允許流經這些節點,會比較容易設定周邊安全,而允許直接存取主節點和工作節點則是相反的情況。
  • 加密節點:您可以使用HDFS Transparent Encryption (把HDFS 上的資料加密) 及Navigator Encrypt (把非HDFS 磁碟區上的資料加密) 把靜止的資料加密並予以保護。執行這個功能需要兩個額外的服務,KeyTrustee Management Service (KMS) 以及KeyTrustee Service (KTS)。每個HDFS 叢集都有KMS 節點,而KTS 節點必須用防火牆分開並由本身的叢集代管。請注意,傳輸中的資料若要加密,可利用Transport Layer Security (TLS) 並啟用HDFS 的資料傳輸加密功能。

第一部份:基礎架構考量事項

CDH 可以利用根本的基礎架構所提供的資源,無論多少。這是您在部署第一個叢集時必須瞭解的重要概念。若是在共用的機架和網路設備上部署,請務必謹慎遵循電源與網路的要求。若是在雲端上部署,則必須考量例如讓主機互相接近以及確保特定角色並不是放置在相同的基本實體機器上等概念。為了確保執行過程適當,請參考硬體、虛擬化軟體和雲端供應商之參考架構最低硬體要求以及通用裸機參考架構。在大部份情況下,下列是常見的基礎架構考量事項。

 

磁碟配置

大部份企業軟體解決方案很習慣採用RAID 組態的概念來解決因為磁碟故障可能產生的資料遺失問題。不過,在CDH,所有角色和服務皆不需要使用RAID。事實上,對有些需要低延遲和高I/O 的角色而言,我們鼓勵採用「just a bunch of disks」(JBOD) 的方式提供單一專用磁碟。

以下是磁碟設定的建議大綱,內部部署的實作之各項元件皆適用:

  • 作業系統:作業系統可以用RAID1 執行,萬一發生磁碟遺失時,可減少發生節點故障。通常2U 伺服器產品會在機器背面隨附一對磁碟專供作業系統使用。這種情況非常適合把這一對磁碟設定為RAID1。
  • 資料庫:考慮到萬一發生磁碟故障您必須在效能與恢復能力之間作取捨時,您應該用RAID 磁碟區來保護metastore RDBMS 資料。至少,在任何情況下,若一個磁碟故障,您的RDBMS 仍可以存取資料。
  • HDFS JournalNode:每個JournalNode 程序應該使用它專用的磁碟(JBOD 或使用單一磁碟的RAID0)。這些目錄不應該使用SAN 或NAS 儲存。若是專用磁碟是SSD/NVMe SSD,您務必要使用企業級磁碟,才能應付寫入頻繁的循序作業。
  • ZooKeeper:ZooKeeper 的交易記錄必須儲存在專用裝置上(專用的磁碟分割區並不足夠)。ZooKeeper 循序寫入日誌記錄,不需搜尋。與其他程序共用您的日誌記錄裝置可能有搜尋和爭奪資源的問題,反而可能造成數秒的延遲。若是專用磁碟是SSD/NVMe SSD,您務必要使用企業級磁碟,才能應付寫入頻繁的循序作業。
  • HDFS NameNode:每個NameNode 程序必須使用自己的專用磁碟(2 個磁碟採用JBOD 或RAID1 設定)。這些目錄不應該使用SAN 或NAS 儲存。
  •  HDFS DataNode/Kudu Tablet Server:建議每個代管HDFS DataNode 的worker 節點使用一組JBOD。僅由檔案系統上的路徑(例如DataNode 是/dataX/dn 以及Kudu 是/dataX/kudu-data) 作區隔的Kuda Tablet 資料可以使用同一組磁碟和檔案系統。此外,若是靜止資料必須加密,HDFS 可以使用HDFS Transparent Encryption。如果Kudu 資料儲存在本身的專用裝置的話,則Kudu 可以使用Navigator Encrypt
  • Kudu 預寫式日誌(Kudu Write-Ahead Log, WAL):Kudu 的預先式日誌強烈建議使用專用磁碟,在Master 和Tablet Server 節點上都要備有專用磁碟。Kudu 的寫入效能倚賴WAL 的效能,所以為了確保寫入頻繁、高度循序的傳輸量,建議使用低延遲的磁碟。雖然使用可以處理這些要求的企業級SSD,SSD/NVMe SSD 是提升效能的好搭檔。
  • Kafka Brokers:Kafka Brokers 建議使用JBOD 或RAID10,不過它們各有本身的取捨。
  • 若是某個磁碟故障並扭曲了磁碟的使用情況,則JBOD 有可能讓broker 發生停機,因為有些分割區可能比其他分割區存有更多資料。不過,因為磁碟之間的寫入被區隔開來,不需要透過RAID 控制器進行協調,所以它的效能非常出色。最近發佈的Kafka 嘗試利用KAFKA-4763解決broker 因為磁碟故障而發生運作中斷的問題。
  • RAID 設定在磁碟故障時可避免發生停機,不同磁碟之間的資料始終平均分布,而且效能強大,因為所有軸承以您的身份執行IO,儘管要透過RAID 控制器。RAID 的缺點,尤其是RAID10,就是犧牲一半的可用容量來達成您的目標。
  • 作業系統頁面快取和非同步IO 能讓兩種磁碟配置策略皆受惠,藉此使最近(由生產者) 寫入的資料,通常不久後便被(消費者) 讀取,取得仍在快取記憶體內的資料。
  • Flume:執行Flume 的邊緣節點在使用Flume 的File Channel 時可能考慮使用專用磁碟。若是倚賴Flume 部署中的Memory Channel 或Kafka Channel,便沒有必要佈建專用磁碟。

這類磁碟建議使用blkid 命令搭配UUID 一起掛載,並針對巨量資料工作負載微調。要進行微調,可使用ext4 或xfs 搭配noatime 掛載選項來設定這些磁碟,並在必要時執行tune2fs (參閱之前的部落格)。請注意,對於AWSAzureGCP上的雲端實作,會概述其具體的磁碟要求。例如,在AWS 應考慮使用暫用磁碟或是使用GP2 磁碟區的EBS。Azure 則強力建議使用Premium 磁碟。以及在GCP 上,DataNodes 則必須使用標準的永久性磁碟。按照實作中每種平台洽詢相對應的參考架構

 

網路

EDH 的網路必須謹慎規劃和詳細考量,確保您的工作負載享有最大的延展性。您可以選擇把位在同一機架中的硬體搭配其他軟體解決方案的硬體一起部署,或是擴大建置獨立的資料中心機架。當基礎架構即服務提供雲端作為網路的功能時,這些考量事項會有變動。

經過多年時間,網路效能已大幅改善,從1 Gb 至10 Gb 再到40 Gb 甚至100 Gb 以上。若要讓叢集的網路具備未來適用性,您的個別伺服器可利用100 Gb 累計機架頂端(Top-of-Rack, ToR) 交換器和10 Gb/25 Gb/40 Gb NIC。若可用的話,應該結合多個網路介面以便增加叢集傳輸量和可用性。

在執行內部部署的叢集時,許多服務的主節點角色會分散在三個伺服器之間。為了保證機架故障時的恢復能力,讓這些主節點角色分散在三個機架之間是理想的做法。一般上,每個機架會佈建雙ToR 交換器,才能應付交換器故障和網路維護的問題,以及經由連至叢集的專用交換器把流量路由到叢集以外的系統(例如提取來源、Hive 或Hue 存取等)。不過,在AWS上執行時,AWS 主機應該使用Availability Zones (可用區),確保主機之間使用低延遲連結。在Azure上應當使用設有容錯網域和更新網域的可用性設定組(Availability Sets)。在GCP上應該使用區域(Region) 和區塊(Zone)。在使用特定供應商的硬體和/或雲端執行時,相關詳細資料請務必參考特定供應商的參考架構。請洽詢已發表的各種參考架構,瞭解特定供應商和雲端拓撲的具體詳細資料。

我們也必須確保完整網域名稱(FQDN) 是小寫字母而且已註冊DNS,並正確設定反向查找。所有CDH 相關流量必須流經與FDQN 相聯連的NIC,而且那是CDH 安裝程序中所使用的叢集主機之FQDN,因為除了邊緣節點以外,皆不支援多重網路(multihoming)。在寫這篇文章的當時,在Azure 上部署叢集並不像AWS 和GCP 那樣享有開箱即可用的反向DNS 功能。

 

高可用性和負載平衡

一般而言,執行高可用性和負載平衡時必須結合多個網路介面並使用負載平衡基礎架構(例如HAProxy、F5、其他) 在服務發生故障時把請求重新導向或是平衡特定服務的負載。

因負載平衡器而獲益的一些服務包括Cloudera Manager、HiveServer2、Impala、Oozie、HDFS HttpFS 服務、Hue、Solr 等。請務必閱讀這裡的Cloudera 文件,瞭解上述服務的負載平衡器組態之詳細資料,因為有些服務(例如Impala) 在工作階段持續性與來源IP 追蹤方面會有特殊要求。

大多數企業客戶要求一個有恢復能力而且可以隨著叢集使用量增長而一起擴展的解決方案。為了達成高可用性和負載平衡的目標,必須擁有下列基礎架構:

  • 公用程式:建議至少兩台主機。如果要管理的主機數量極大(超過100 個),必須把兩個主機之間的Cloudera Manager Services (CMS) 及Cloudera Manager (CM) 分開。非常大型(超過500 個) 的節點叢集還可以在額外的公用程式節點之間拆分CMS 服務。此外,如果資料庫也同樣位在叢集中(相反的情況是位在叢集外),公用程式節點可用來代管資料庫和執行兩個資料庫執行實例之間的原生複寫。具備高用性的CM也需要Network Attached Storage (NAS) 功能,才能在CM 主機之間共享特定目錄。請記得依據必要的保留政策佈建額外的硬碟空間供CM 伺服器服務測量基準和日誌記錄使用。
  • 主節點:HA 的每個叢集建議至少使用三台主機。ZooKeeper、HDFS JournalNode 和Kudu 尤其需要奇數數量的主機,才能達成多數共數。一般而言,節點數量大於100 的叢集建議使用三個主節點,節點數量介於100 至500 之間則建議使用五個主節點。注意:公用程式節點可能暫時包含第三個主節點的服務,直至能夠增加第三個主節點為止。
  • 工作節點:最低限度要有三台不同的主機才能實現資料持久性,但是參考架構一般會指定開始時要有五台主機,才能提供合理程度的資料可用性、備援性和儲存容量。務必要記得,因為預設的HDFS 複寫是3 份,所以有效的HDFS 空間受限於單一主機所能提供的空間(?儲存空間)。隨著任何特定叢集對於儲存或運算的需求增加,Worker 節點也會擴充。按照您的使用案例之要求,應該要為處理引擎的暫用空間和相同資料的額外備份準備額外的空間(大約25% 預留空間是不錯的開始)。
  • 邊緣節點:邊緣節點必須根據HiveServer2 同時連線的數量、HUE 使用者、HttpFS 擴充要求等進行擴充。至少需要兩個節點來平衡負載和啟用HA。按照一般的經驗法則,每增加20 個工作節點,建議增加一個邊緣節點。邊緣節點上會安裝Cloudera Data Science Workbench (CDSW) 以及一些第三方工具,部署這些功能時必須一併調整邊緣節點的數量。
  • 加密:KMS 和KTS 服務各別需要兩個節點才能達成高可用性。注意,每個HDFS 節點都需要KMS 服務,所以任何入若執行超過一個HDFS 叢集,則每個HDFS 叢集需要兩台主機負責KTS 以及兩台主機負責KMS。KTS 伺服器應該當作本身的叢集,受到防火牆規則的保護。若有必要,KTS 節點可以虛擬化,只要您充分瞭解這樣做可能帶來的風險。
  • 風險:若是VM 環境離線,或是CDH 環境與VM 環境之間的網路無法使用,便會無法使用叢集。
  • 若因資料中心空間和成本限制之故而無法增加實體節點,才可以考慮這種做法。
  • KTS 主機應該妥善備份或是頻繁地建立快照,避免資料遺失及洩漏金鑰致使機敏資料解密。

結論

在本〈第一部份:基礎架構考量事項〉部落格文章中,我們解說了一個健康叢集的重要基礎概念,包括節點分類的簡述、磁碟配置設定、網路拓撲以及達成高可用性和負載平衡的考慮事項。請閱讀本系列文章的第二部份,我們會根據使用案例和工作負載考量事項仔細說明CDH 服務和角色配置。

Back to list.
Prev
案例 | 物聯網在醫療領域的應用
案例 | 物聯網在醫療領域的應用
Next
解釋 Hadoop Delegation Token 上篇
解釋 Hadoop Delegation Token 上篇