實驗環境：Ubuntu 12.04，Hadoop-1.1.2, VirtualBox 虛拟機 3-4 台
192.168.1.7 hadoop-master
192.168.1.8 hadoop-slave1
192.168.1.9 hadoop-slave2
為分離NameNode 和 SecondaryNameNode ，建立以下SecondaryNameNode節點
192.168.1.10 SNN
一、 能否給web監控界面加上安全機制，怎樣實作？抓圖過程
1. 配置core-site.xml，并scp到其他節點
2013-8-9 22:55 上傳 下載下傳附件 (243.98 KB)
2. 手動建立 ${user.home}/hadoop-http-auth-signature-secret 檔案，并sep到其他節點
2013-8-9 22:55 上傳 下載下傳附件 (492.96 KB)
注：這裡無法自動建立，必須手動建立。見 BUG ：HADOOP-8857
3. 通路web console，無法匿名通路，輸入user.name後能通路
2013-8-9 22:55 上傳 下載下傳附件 (208.15 KB)
2013-8-9 22:55 上傳 下載下傳附件 (537.11 KB)
注：隻有首次通路需要user.name
主要參考：
http://hadoop.apache.org/docs/stable/HttpAuthentication.html
以上隻是簡單的僞驗證，如果需要使用kerberos來加密，過程非常複雜，可參考：
http://www.cloudera.com/content/support/en/documentation/cdh3-documentation/cdh3-documentation-v3-latest.html
http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/4.2.1/CDH4-Security-Guide/cdh4sg_topic_3_2.html
http://blog.zhengdong.me/2011/10/20/install-hadoop-with-kerberos-in-ubuntu
http://blog.chinaunix.net/uid-1838361-id-3243243.html
二、 模拟namenode崩潰，例如将name目錄的内容全部删除，然後通過secondary namenode恢複namenode，抓圖實驗過程
1. 删除NameNode中 name目錄下的所有内容， NameNode down
2013-8-9 22:56 上傳 下載下傳附件 (719.67 KB)
2013-8-9 22:56 上傳 下載下傳附件 (839.33 KB)
2. 停止叢集，格式化NameNode
3. 從DataNode擷取down之前的namespaceID
2013-8-9 22:56 上傳 下載下傳附件 (414.69 KB)
4. 修改NameNode namespaceID 為 down之前的namespaceID
2013-8-9 22:56 上傳 下載下傳附件 (242.42 KB)
5. 删除新NameNode 的 fsimage檔案
2013-8-9 22:56 上傳 下載下傳附件 (433.51 KB)
6. 從 SecondaryNameNode scp fsimage 到 NameNode
2013-8-9 22:56 上傳 下載下傳附件 (259.16 KB)
7. 重新啟動叢集
2013-8-9 22:56 上傳 下載下傳附件 (436.79 KB)
三、怎樣改變HDFS塊大小？實驗驗證并抓圖過程
1. 檢視原block size
2013-8-9 22:56 上傳 下載下傳附件 (228.95 KB)
2. 設定hdfs-site.xml 中 dfs.block.size = 128M, scp 到其他節點，并重新開機叢集
2013-8-9 22:56 上傳 下載下傳附件 (72.82 KB)
3. bin/hadoop fs -put ~/input in, 并檢視web console
2013-8-9 22:56 上傳 下載下傳附件 (204.6 KB)
四、 把secondary namenode和namenode分離，部署到單獨的節點，抓圖實驗過程
原系統namenode 和 secondaryNamenode 運作在同一機器上：hadoop-master
2013-8-9 22:56 上傳 下載下傳附件 (447.23 KB)
1. clone hadoop-master
2. ip：192.168.1.10
3. /etc/hostname : SNN
所有節點：
4. /etc/hosts : 192.168.1.10 SNN
5. /usr/local/hadoop/conf/masters: SNN
6. hdfs-site.xml 設定 dfs.http.address 和 dfs.secondary.http.adress
2013-8-9 22:56 上傳 下載下傳附件 (139.15 KB)
7.重新開機虛拟機
8. 配置 ssh 免密碼登陸
9. bin/hadoop namenode -format
10. 修改其他節點（包括SNN）的namespaceID 與namenode 的 namespaceID 相同，或者删除其他節點tmp目錄下的資料。（參考第五題）
11. 啟動叢集
NameNode 和 SecondaryNameNode 已經分開
2013-8-9 22:58 上傳 下載下傳附件 (478.53 KB)
12. 參考第六題 設定 fs.checkpoint.period, 實作NameNode和SecondaryNameNode分離送出下，checkpoint 控制
2013-8-9 22:59 上傳 下載下傳附件 (554.01 KB)
五、 在Hadoop叢集實施成功後，再次格式化名稱節點，請問此時datanode還能加入叢集不？如果不能加入怎樣解決？模拟過程并抓圖
1. 停止叢集，并bin/hadoop namenode -format
2013-8-9 22:59 上傳 下載下傳附件 (815.35 KB)
2. 啟動叢集，并檢視datanode
2013-8-9 22:59 上傳 下載下傳附件 (631.29 KB)
datanode 無法啟動
3. 檢視日志，顯示 datanode 與 namenode namespaceID 不同所緻
2013-8-9 22:59 上傳 下載下傳附件 (475.29 KB)
4. 修改所有datanode /usr/local/hadoop/tmp/dfs/data/current/VERSION 中namespaceID 為 namenode namespaceID，或删除datanode 中 /usr/local/hadoop/tmp/dfs/data 目錄。這裡采用後者。
2013-8-9 22:59 上傳 下載下傳附件 (316.97 KB)
5. 重新開機叢集，datanode 啟動
2013-8-9 22:59 上傳 下載下傳附件 (620.54 KB)
六、 怎樣控制namenode檢查點發生的頻率，用實驗模拟檢查點發生的前後過程，并抓圖發生前和發生後的中繼資料情況進行比較，說明之
1. core-site.xml 中設定 fs.checkpoint.period=180, scp 到 所有節點
2013-8-9 22:59 上傳 下載下傳附件 (74.39 KB)
2. 重新開機叢集，并檢視namenode /usr/local/hadoop/tmp/dfs/name/current中 fsimage,edits等的更新頻率。
每隔4分鐘檢視，發現namenode 每隔 180 秒 checkpoint 更新
2013-8-9 22:59 上傳 下載下傳附件 (646.82 KB)
3. 觀察checkpoint 前後 namenode的變化
檢查點發生前：
（1）16:10 的checkpoint 顯示，namenode的fsimage和edits 最後修改時間為16：10。
（2）16：11 向hdfs系統加入 input ，namenode 中的edits 記錄 這次操作，其修改時間為16：11
檢查點發生後（16：13）：namenode 中的fsimage（16：10） 被 seondarynamenode 新産生的fsimage（16：13-由fsimage16：10 和 edits 16：11合成）代替，edits（16：11）被新産生的edits代替。
2013-8-9 22:59 上傳 下載下傳附件 (622.6 KB)
4. 基本原理
當距離上個checkpoint 時間 為${fs.checkpoint.period} 時：
1. 次（secondary）名稱節點請求名稱節點滾動edits檔案，使新的edits log 放到另一個新生成的edits檔案。
2. 次名稱節點 通過 HTTP GET 擷取名稱節點的fsimage和edits檔案
3. 次名稱節點将fsimage檔案載入 記憶體，并應用edits 檔案中的每一項操作，這樣就建立了一個新的合成的fsimage 檔案。
4. 次名稱節點采用 HTTP POST 方式 将剛合成的fsimage 發送回 名稱節點
5. 名稱節點用剛從次名稱節點收到的fsimage代替老一版本的fsimage, 并用第一步中産生的edits 代替原先的edits，同時将fctime檔案更新到checkpoint發生的時間
最終，名稱節點就有了一份最新的fsimage檔案和一個更短的edits檔案（該edits檔案不一定空，當次名稱節點在執行checkpoint操作時，edits 可能已經記錄下了一些hdfs系統的操作）