門外漢的 Hadoop 部署大賽（下）

門外漢的 Hadoop 部署大賽（上） << 前情

繼上回參加的初賽完畢，在隊友強力的火力支援下，還沒弄清楚狀況就進了決賽。

確定取得門票後尷尬的是還沒有人真的架過 Fully Distributed 的 Hadoop Cluster 環境（後來聽各隊簡報時，大家似乎也都是如此）。首得第一個得面對的問題，參賽到底要使用哪個版本呢？這問題其實沒有太多的想法，但初賽使用的 BigTop 內含的 Hadoop 是 2.0.x alpha，看起來是舊了點。雖然我們沒有爭第一名的雄心壯志，但至少得在這次比賽獲得一點經驗，也就之後工作時能幫得上忙。

不過正式決定要使用的 Hadoop Distribution 版是在賽前說明會前才正式決定的，在那之前的準備方向其實與初賽差不多：

1. 有人去研究 Cloudera 發行版本怎麼弄
2. 有人試著純手工架 Apache 原始版本

前者是以架設的完整性、便利性與具有效率的工作流程為目標的；後者是以探索問題細節與設定值的原貌為目標的。一開始這些活動是平行的，使用 CDH 的路線會有較高的完成度，能開始進行一些針對 performance tuning 的實驗。後者 Apache 發行版本安裝，並包含對 hdfs HA 與 Kerberos 建置與設定進行更細節的了解，這些經驗能補充在實際以 CDH 部署時遇到的問題。

hdfs HA

要建置 hdfs HA 現行有 NFS 與 Journal Node 二種正式的方法。hdfs HA 主要是什麼樣的功能呢？簡單說，必需要有 2 個 NamdNode，一個負責正常服務，一個備用。它的角色有點像統總與副統總，當總統掛點時，副總統就得取代總統的功能來指揮國家。在 hdfs 的國度裡，它就是二個 NameNode，加上了 HA 機制。為了待命中 (standby) 的 NameNode 能完全清楚明白作用中 (active) 的 NameNode 知道他做了什麼，好在「萬一」的情況發生時無縫接軌，需要有一個傳遞交易記錄的地方。

這個記錄交易記錄的地方，早期是利用 NFS 指向一個 active NameNode 與 standby NameNode 都能讀取的目錄，當 active NameNode 接收到 hdfs 資料異動時，將它寫成交易檔在這個 NFS 做成的 shared folder 內，standby NameNode 會去 relay 交易記錄以達到未來能完全承擔的目標。不過這有個問題，那就是 NFS 只是一個被動的存儲機制，它不會與 hdfs 服務有狀態上的直接關聯。這情況會導致「萬一」的情況很難判斷真偽，當判斷失準時就會二個 NameNode 都變成 active 或另一種情況，在做 hdfs HA 的領域稱這情況為分腦 (Split-brain)。因此，賽制上規範使用新的做法，一律使用 JournalNode 來做。JournalNode 為 hdfs HA 體系的一部分，所以就能透過機制獲得內部狀態，同時取代 NFS 作為交易記錄存儲的新媒界。由於 JournalNode 機制還是很新的東西，在官方網站上看得不太明白，最後我們在 HDP 的手冊找到了明確的實作方式。

不過這僅是為了純手工打造的目標架設的，實際在比賽時我們採用的是 CDH，只需要安裝好相關元件，並設定部署目標就簡單完成。不過這仍是有用的經驗，至少明確地知道 JournalNode 設定是在 hdfs-site.xml 內設，參賽時使用 CDH 無法啟動第 4 台（邏輯上的限制）JournalNode 時，明白地知曉該去哪改設定。在同一份設定也要設 2 個 NameNode 邏輯上的 Service ID，由 CDH 自動指派會像是 NameNode73 這樣加個隨意數字的名稱，依參賽規則它需要改成 vm1 與 vm2。這些手工打造的經驗輔助我們在無法依賴 CDH 時也能順利作業。

Security

對於 Hadoop 的 Security 有二種模式，一種是 simple，另一種是 kerberos。預設的 simple 模式依賴的是系統權限，例如 linux 的權限系統來管理。它其實同時包含在 linux 上的權限系統與 hdfs 內的權限系統。當需要額外啟用 Security 機制時，就得啟用 kerberos。kerberos 其實是來自 Cerberus，祂是希臘神話負責看守通往冥界入口的神獸（聽起來就很威，很安全的感覺）。一旦啟用 Kerberos，就必需全部的軟體元件都符合 Kerberos 設定，需要具有 Kerberos Principal，我們初學可以單純地把 Kerberos 的 Principal 想像成作業系統內的使用者。當啟用 Kerberos 時它與 simple 模式的重要區分是：你不再以系統的使用者作為執行 hdfs 時的身份，而是以獲得授權的 Kerberos Principal 作為執行身份。

例如：在 simple 模式，我以 user1 這個作業系統使用者進行 hdfs 的操作，hdfs 服務會將我視為 user1。在 Kerberos 啟用的模式，我在作業系統內使用的是 user1，但由 Kerberos KDC 獲得 user2 的授權後，我執行 hdfs 操作時，hdfs 服務將我看成 user2 的身份。所以，在 hdfs 內的權限要看 user2。 這是使用 Kerberos 最大的差別，也是許多人啟用 Kerberos 安全模式所有東西動起來跟以前不太一樣的關鍵因素。

在手工打造 Security 的 hdfs cluster 過程，最重要的是資料比起 hdfs HA 更加不完整，以 Hadoop 管理手冊來說，它針對 hdfs 與 mapred 需要建的 keytab (將一組 Kerberos Principal 匯出成認證檔) 描述缺少一些關鍵的 principal，像是 HTTP/_HOST@{realm} 就缺少了，導致 hdfs 要啟用 Web UI 相關功能時失敗而關閉，加上書本撰寫的時間 yarn 還沒有正式 release 書上用的是 mapred principal，若啟用的是 yarn 的情況，那就需要建立 yarn principal。最後，還有 hbase 等相關服務的 principal 需要建立才能攻略比賽的範圍。這些書本上來不及更新的內容，我們在 CDH 手冊有找到它：

雖然手工的做過了，但 CDH 又提供了另一種不同等級的「便利」。它讓我們產生一個給 Cloudera Management Service 使用的 principal，這個 principal 是具有管理者權限的。因為它具有管理者權限，所以 CDH Manager 可以替我們產生需要的 principal 並且完美快速地部署在正確的位置。

這樣自動化的部署模式帶來便利，同時也帶來困擾。因為 CDH 的部署路徑都是依當時的情況自動產生的，它並不是固定的位置。對於需要手動執行 hadoop client 端的情況會稍嫌麻煩，因為存認證資訊的 keytab 沒有固定置（手工打造的情況會放在固定位置方便 script 更新），這時又得回到 Kerberos Principal 的設計來談！一個 principal 的完整格式為：

user/instance@REALM

後面的 /instance 是一種修飾的效果，用來修飾 user 的。例如接 /admin 對 Kerberos 來說這個 principal 就有管理者身份。當然也可以不加修飾寫成：

user@REALM

將此 user 視為通用的存在，對 Hadoop Security 來說，它的修飾是 _HOST：

hdfs/_HOST@REALM

將這個 principal 被載入後 _HOST 會被 getLocalHost() 換掉，例如：

1. hdfs/vm1@REALM
2. hdfs/vm2@REALM
3. hdfs/vm3@REALM
4. hdfs/vm4@REALM

Hadoop 允許我們建立通用各 host 的 principal，例如可以建立：

hdfs@REALM

使用這組 principal 取得授權，不管現在在哪一台機器上執行都是能被接受的。額外建立這組 principal 巧妙地解決 keytab 不固定位置的問題。

雜談

要完整準備決賽的內容是相當辛苦的。對我們來說能取得 Hadoop 部署的經驗才是最重要的。決賽的前一下還在打屁：「不要最後一名就好」，是的「不要想著贏，要想不能輸」。雖然這次幸運獲得較好的成績，無謂怎麼回顧也許都是事後諸葛，但仍得歸納一些心得作為參考。

掌握備賽步調

隊友總在適當的時間將大家拉回主要的路徑上。作為開發者總是能被有趣的設計吸引，或執著於搞不定的事項。稍為佇足停看路邊風光是可以的，但別忘了要適時移動腳步，得確定每天有離終點近一點。

同時得停損無關緊要的事項！例如我是負責手工打造的，所以也弄了一些的 fabric script 進行 configuration 的自動化，但參賽在即得決定使用的 Hadoop Distribution 後，就不再需要這樣自動化的工具就不需再花時間研究它。

另外，即使時間不夠充份也要盡可能試完會用到的東西。大家白天都在上班，其實只有下班後的一二個小時有時間練習，但這就像接力賽，一個人先起了頭，另一個接著做後續的事項（利用 hackpad 做 checklist），並盡可能貼近主辦者公佈的環境。像我都是用 EC2 模擬的，沒遇到 vagrant 掛 shared folder 後無法變更權限的問題，還好有人事先了它發現權限有問題才能提早應變。

參賽資訊與競賽

「想要得高分，就得先弄懂規則」這是我很喜歡引用的一句話。這些主辦單位提供窗口可以解答疑惑，也主辦賽前說明會解說實際的問題。我們主要確認了幾個疑惑：

1. 是不是能使用 CDH 這類的 solution：只要是免費版本的都能使用
2. 由於會場主機沒有對外網路，是否能先灌好 VM 到現場掛載：只要符合規定並能透過 vagrant 登入送分即可

這二個問題的確認影響了備賽的決策。一個是解除了猶豫是否只能用 Apache 發行版本，一個解決了如何爭取更多時間的問題。這些問題都是在認知不同時提出的，例如隊員間的認知不一致或我們需確認主辦方是否認同我們的想法。

實際參賽時，基本的策略就是以先每項都有分再來調整效能。到現場後才知，原來每項都有分是那麼地困難，又恰巧每項都有分，表示執行時該解決的問題都大致被解決了，所以效能即使是預設的其實也不會太差。我想最後分數較優的因素，大概是適時地停損，不要漫無目地的進行優化，只要沒有人超前太多，就先不理會繼續朝完賽前進。

良好習慣

由於我們報名的是社會組，正也說明了其實隊友都是上班人士了。大家做的都是 RD 的工作。這些習慣適時地發揮作用，讓我們能較快看清問題。因為我們使用預先灌好的 VM，所以要分工的部分其實不多，但主要是解問題為主。我們常用的一個準則是「有事看 log，不懂看文件」。

在工作分派上，我也將 Watch Log 列在自己的項目，負責的部分是接觸最多錯誤訊息的手工安裝路線的。這個習慣與「洗腦式」的口號，常讓我們能趨吉避兇。好在 CDH 比原生的 tarball 安裝在 log 檔位置有更明地安排，我們只要集眾人「犯錯」的經驗，就能較快地分析出問題的原因與對應解法（或 work around）。

完賽

經歷了這回的比賽，相信隊友們對於架設 Hadoop 有相當完整的瞭解。這比賽的設計，其實比較像是「傳教」式的將一些最佳實踐刻印在參與者的心中。稍為可惜的是決賽時，多數的參賽者可能苦於與 Linux 與基礎架設奮戰而沒有發揮原本的實力。這就稍為偏離了題目設計的主軸：performance tuning，但有一隊雖然沒完成卻很用心地列出準備期時測試實驗數據。若他們準備的更加充份，相信是非常可怕的對手。

後續 >> 門外漢的 Docker 小試身手