20161214 17:30——17:56
操作備註：本文基於《Hadoop淺學習&實踐學習——初級1》一文的實踐結果，進一步研究真實分佈集羣環境的實現。
參考：Hadoop基礎教程之分佈式環境搭建
http://www.kwstu.com/ArticleView/hadoop_201408181042089382
一、 配置slave節點主機的SSH,使得主機可以免密登錄slave主機，最終實現多臺linux主機可以相互由SSH免密登錄：
1.1 兩臺linux主機相互免密登錄訪問的實現過程（hadoop0和hadoop1之間相互免密訪問的實現）
爲了實現這個功能，作爲slave結點的主機的公鑰文件中必須要包含作爲主結點主機的公鑰信息，這樣作爲主節點的hadoop0就可以順利安全地訪問這slave結點hadoop1了。操作過程如下：
cd ~/.ssh
scp root@hadoop0:~/.ssh/id_rsa.pub ./master_rsa.pub #據說dsa文件是ssh版本2中對應的文件
cat master_rsa.pub >> authorized_keys
備註：1. 上面的第二步是把要免密登錄hadoop1的主機hadoop0中生成的id_rsa.pub文件複製到本機對應的當前目錄下並重命名爲master_rsa.pub，而後第三步是將master_rsa.pub文件內容輸出重定向到authorized_keys文件中（等同於將master_rsa.pub文件複製並重命名爲authorized_keys），經實踐已驗證：其實上面的第二、三兩步驟可以合併爲scp root@hadoop0:~/.ssh/id_rsa.pub ./authorized_keys
。 2. 在實現hadoop1免密登錄hadooop0時，是將hadoop0中生成的id_rsa文件複製到hadoop1中對應的目錄下，在實現hadoop0免密登錄hadoop1的過程中，是將hadoop0中生成的id_rsa.pub複製到hadoop1中對應的目錄下，簡言之，實現的是相互免密訪問，但所需要的rsa文件都是同一臺主機產生的。3.這裏的多臺linux主機相互訪問主要是作爲主節點的hadoop0分別和作爲slave節點的hadoop1、hadoop2之間的相互訪問，還不涉及到配置實現兩個slave節點hadoop1、hadoop2之間的相互訪問。
（1）創建./ssh目錄
方式一：mkdir .ssh #在root家目錄下新建目錄
方式二： 可以通過在slave節點主機中執行ssh-keygen命令（過程中不要輸入口令ssh-keygen -t rsa）來創建，如果不覺得大材小用的話。當然後續實現hadoop1和hadoop2之間相互訪問的話或許用得到。
（2）而後依次執行上面的三條命令
配置完後，回到作爲主節點的hadoop0機器中，再來試一下ssh 192.168.0.177，如果在hadoop0的hosts中綁定了177和對應的主機名或該IP地址的別名則可以別名替換上面的IP地址，來測試是否可由SSH免密登錄作爲slave節點的主機:
下面的結果是：在hadoop0中通過“ssh 192.168.0.177”的方式免密登錄成功，但是雖然在該主機hosts中綁定了IP地址和別名，但是通過“ssh hadoop1”未能免密登錄成功。
1.2 多臺linux主機相互免密登錄的實現過程（作爲主節點的hadoop0分別和作爲slave節點的hadoop2、hadoop1、hadoop3之間的免密方式相互訪問）（13:38——15:50）
參考： Ssh 信任關係建立後仍需要輸入密碼 （關閉selinux思路的來源在此）
http://blog.sina.com.cn/s/blog_c08a102e0102wdv1.html
備註：如括弧所述，多臺linux主機相互免密登錄的實現過程，指代的是作爲主節點的hadoop0分別和作爲slave節點的hadoop2、hadoop1、hadoop3之間的免密方式相互訪問的實現，並不涉及到hadoop1、2、3之間的相互免密訪問的設定和實現。下面主要描述的是 在hadoop0分別與hadoop1、3之間相互免密訪問的設定操作完成後，hadoop1、3分別能夠由SSH成功免密訪問hadoop0，但是反向的hadoop0卻不能分別由SSH免密訪問hadoop1和hadoop3，這樣的在全面設定後卻只能單向由SSH免密訪問的問題和該問題的解決。——最關鍵的處理操作是：關閉selinux應用，臨時或永久性地。通過命令getenforce可以查看selinux的狀態。
20161215 （09:38——12:00）
繼續處理兩臺linux相互免密登錄時hadoop0主機不能由命令“ssh hadoop1”登錄到hadoop1主機的問題：
備註：在第一次嘗試免密登錄的過程中會有如上提示，其中“Permanently”是說臨時性地添加這樣主機的RSA到known_hosts文件中去。可以進一步研究如何纔是永久性的。
二、配置hadoop主節點主機hadoop0
在hadoop安裝目錄下的conf文件夾中，找到masters文件，編輯，在裏面輸入“hadoop0”後保存。這裏的“hadoop0”對應的是作爲主節點主機的主機名或別名。
在同文件夾下，找到slaves，編輯，在裏面輸入“hadoop1”“hadoop2”後保存。同樣這裏的“hadoop1”“hadoop2”分別對應的是作爲slave節點的主機的主機名或別名。
三、複製hadoop安裝目錄（二進制或源碼包安裝的hadoop所有的安裝文件都在其安裝目錄下）
在一臺機器上部署時，我們的hadoop包是二進制包文件直接解壓作爲安裝的。在這裏，從機上就不用這麼麻煩了，我們可以從主機hadoop0上 複製過去。如何複製呢？ 遠程登陸我們用SSH，遠程複製就用SCP。在複製前要注意，我們在主機中hadoop存放在什麼位置，在從機中也要存放在該位置纔行。 如下：
scp -r hadoop-1.2.1/ hadoop2:/usr/local #到主節點主機hadoop0的/usr/local目錄下，執行scp命令將目錄傳送到slave節點主機上對應的/usr/local中。
四、啓動hadoop進程（17:01——18:00；）
20161216 11:25——12:12（記錄整理昨日下午的實踐）
操作備註：嘗試在作爲主節點的主機hadoop0中通過start-all命令啓動用了一個小時，期間遇到好多問題，並逐個嘗試解除，現在簡要記述在這裏：
4.1.1.保證各個主機的hadoop的安裝路徑及相關信息完全一致（安裝路徑、安裝目錄名稱、安裝路徑的全局環境變量和安裝目錄的軟連接）
hadoop1和2兩臺作爲slave節點的主機中hadoop安裝目錄文件是從hadoop0中scp遠程傳送過去的，這是唯一關聯起來而相同的地方，後續在hadoop1和2的全局環境變量配置文件中按照hadoop0中的相關內容爲各自本機中的hadoop應用配置了全局變量，但是hadoop0中全局變量是基於爲應用安裝目錄hadoop-1.2.1做的軟連接“hadoop”即/usr/local/hadoop，所以，第一次報錯出現。解除辦法就是爲hadoop1和2各自的安裝目錄創建與hadooop0中相同的軟連接名稱（直到在hadoop0中執行find命令時才聯想到hadoop-daemon.sh是存在的，錯誤在於：是hadoop1和2中沒有這樣的存儲路徑）。這次失敗的啓動執行後，執行命令jps只能看到三行信息：
4.1.2 保證各個主機的基礎環境信息完全一致
在主節點hadoop0執行start-all.sh之後可以使用jps查看啓動信息，但從slave節點主機中執行jps卻提示找不到該命令，於是在主節點hadoop0中執行find命令，發現該命令是包納在java安裝包jdk當中的，而hadoop1和2並沒有佈置這樣的java環境……。所以需要注意的是，除主節點主機hadoop0之外的其他linux主機在加入分佈集羣架構之前要仿照主節點主機的基礎環境準備階段的操作，首先部署相同的基礎環境，然後纔是圍繞hadoop應用服務的相關配置。
4.1.3 第二次啓動start-all.sh之後
經過排查和適當調整，再次啓動start-all.sh的時候，沒有出現報錯。在hadoop0中執行命令jps，返回四行信息。但是在hadoop1和2中執行命令jps，卻只有一行關於進程jps的信息。
4.2.1 禁用防火牆或者在iptables中添加匹配hadoop服務所有端口策略
備註：基於4.1.2中的問題（進程無法全部開啓），參考資料
操作備註：接下來要處理的就是1.如何實現主節點服務界面“Live Nodes”能檢測到作爲slave節點的主機（hadoop1和2）（應該是配置問題） 2.若開啓iptables狀態下實現slave節點出現本次關閉狀態下的三條進程信息，需要做哪些匹配策略？ 3.重新部署一遍hadoop實質分佈集羣環境|全分佈進羣環境，把本windows7主機PC上的主節點hadoop0和slave節點slave2擱置，換做windows-server2012中的虛擬主機hadoop4做主節點，hadoop5和6作爲slave節點。這樣做可以梳理一下全局部署思路，或許順便能夠發現主節點檢測不到slave節點的原因。
20161224 15:02——（未進入狀態）15:42——（着手調試hadoop0-1-2第一版集羣環境）16:09——（進程啓動階段總結）18:43
操作備註：這部分的實踐是基於《Hadoop淺學習&實踐學習——初級2.1[真實分佈集羣]》的成功，來調試hadoop0-1-2組成的實分佈集羣環境，使之成功：在50070端口的web界面檢測到“Live Nodes”的存活。階段目標有三個（1）分析集羣環境中slave主機部分進程啓動失敗的原因 （2）在50070端口的web界面檢測到“Live Nodes”slave主機存活狀態 （3）進一步瞭解hdfs-site.conf的配置 指定文件資源的存儲，以及core-site.xml 、mapred-site.xml。
零、 實分佈集羣環境基礎配置設定
操作備註： 本步驟基於實分佈集羣環境部署完畢之後的初始化基礎配置，關於環境部署搭建操作可以參考《Hadoop淺學習&實踐學習——初級2.1[真實分佈集羣]》所記錄。
備註：分佈集羣環境部署完畢之後需要初始化配置的文件有：masters、slave、hadoop-env.sh、core-site.conf、hdfs-site.conf、mapred-site.xml，配置完畢後分別如下圖所示：
一、集羣環境中slave主機部分進程啓動失敗的原因
備註：部分進程啓動失敗，指代的一般是slave節點主機中的datanade進程啓動失敗。經測試，發現主機中iptables進程開啓與否會影響某進程啓動
（1）主節點主機和slave主機全部關閉iptables條件下hadoop進程的啓動
service iptables stop
（2）主節點主機關閉iptables，slave所有主機開啓iptables的條件下hadoop進程的啓動
（3）主節點主機和slave主機全部開啓iptables條件下hadoop進程的啓動
備註：本步驟在下面步驟（4）測試之後進行的。發現各主機全部開啓iptables的條件下，slave節點主機似乎能夠啓動相比只有主節點主機開啓iptables時更多的進程。但是終止hadoop進程的時候會發現，其實沒有slave節點的進程關閉的信息，而是提示“no XYZ to stop”。
（4）主節點主機開啓iptables，slave所有主機關閉iptables的條件下hadoop進程的啓動
綜上，可見，要使得slave節點各主機都正常啓動hadoop子進程，重點在於主節點主機要關閉iptables進程，或者匹配相關策略，而slave節點主機中iptables的開啓與否，並不影響hadoop進程在slave節點主機中整體的啓動和終止。但是iptables的開啓與否對主節點主機本身hadoop進程是沒有影響的，這點顯而易見。——另外。由此可以明白在博文《2.1》記錄的實踐中出現的部分slave節點進程爲何會啓動失敗了——slave節點主機的hadoop子進程namenode進程啓動失敗，實際因主節點主機系統開啓了iptables所致。另外，已證實，core-site.xml、mapred-site.xml兩個配置文件分別對應的是namenode|datanode
和jobtracker|tasktracker進程，在主節點主機爲其中配置的端口添加iptables防火牆匹配策略，如此，在主節點主機開啓防火牆的情況下，slave節點主機的hadoop各子進程依然能夠正常啓動（一如之前所述，slave節點主機開啓防火牆與否，配置端口匹配策略與否並不影響進程的啓動）。
二、在50070端口的web界面檢測到“Live Nodes”slave主機存活狀態
（1）啓動進程，觀察
備註：爲防止slave節點主機iptables的影響致使主節點主機無法檢測到其中的datanode，本環節將hadoop1和2的iptables關閉，但是目前來看依然檢測不到live nodes。下面是各主機hadoop子進程正常啓動之後，使用命令" hadoop dfsadmin -report ”看到的分佈集羣狀態信息，這點與50070端口web界面看到的信息一致：
20161224 18:43——（live nodes存活性檢測階段實踐）19:33——（階段總結記錄）20:08
參考：
Hadoop在master查看live nodes爲0解決方案（提供多種排查方法）
http://blog.csdn.net/shenlan211314/article/details/7414728
Hadoop-2.2.0集羣部署時live nodes數目不對的問題(/etc/hosts文件配置是否存在邏輯的錯誤)
http://www.cnblogs.com/chasewade/p/3509305.html
Hadoop datanode正常啓動，但是Live nodes中卻缺少節點的問題（這裏涉及hdfs-site.xml高一級別的配置）
http://blog.csdn.net/wk51920/article/details/51729460
爲排查默認的50070端口web界面中live nodes存活性檢測不到問題（對應的在linux終端中是執行命令"hadoop dfsadmin -report”之後"Datanodes available"部分顯示不到slave節點主機信息），分別參考資料，做了如下處理：
（1）刪除主節點主機和所有slave節點主機上的 hadoop安裝目錄下的logs文件
（2）終止hadoop全體進程，重新執行格式化命令" hadoop namenode -formate"，但是格式化之後，提示信息和《2.1》實踐記錄中的不同（沒有博文2.1中的多），終端顯示如下：
（3）編輯hosts文件，並重啓hadoop0和hadoop1兩主機系統
（3.1）對比hadoop4-5-6分佈集羣環境的完全成功（檢測到live nodes）中的應用本身配置文件外，hosts文件中的區別，發現其中迴環網址後面的主機名沒有修改，於是就嘗試分別將hadoop0和1中的內容（hadoop2中本身就是原樣沒有改動），將其改回原樣，如下：
（3.2）在改回hadoop0和1的hosts內容後，重新執行了格式化hadoop的hdfs文件系統，發現輸出的內容還是修改hosts之前的那樣；而後想起修改hostname之後需要重啓系統纔會生效，於是重啓hadoop0和1兩系統；重啓系統後重新執行hadoop格式化，輸出信息依然如之前那樣，可能格式化命令執行後的輸出因系統而異；再而後在保證主節點主機hadoop0的iptables關閉狀態下，和全部主機selinux禁用條件下，啓動hadoop進程，並檢測"live nodes"的信息，發現成功檢測到，分別如下：
小結：認爲，[ 已證實 ]，將hadoop0和1主機的hosts文件中（至少應該要修改主節點主機hadoop0的hosts）迴環網卡地址127後面的主機名修改回去是最關鍵的處理操作。hadoop0-1-2集羣環境的主機中將這裏修改是錯誤參考了百度經驗中的做法，這在僞分佈集羣博文《1》中有記錄。現在想想，修改主機名的話，直接在/etc/sysconfig/network 中修改就是了，hosts文件只是用來向其中添加主機名和IP的綁定信息，從而起到本地dns的作用，沒必要修改其中原有內容！——在原樣和自定義主機名間修改然後保存，並且不需要重啓操作系統，只要重啓hadoop整體進程就可以看見其中區別，就可以證實本段黑體字所述。
20161225 10:30——（分析開啓iptables狀態下hadoop進程正常啓動的配置）11:00； 13:00——（調試hdfs-site.conf）13:51；
14:20——（調試hdfs-site.conf關於datadir的生成）14:37
三、進一步瞭解hdfs-site.conf的配置 指定文件資源的存儲，以及core-site.xml 、mapred-site.xml。
參考資料：
首先可以到hadoop的安裝目錄下share/hadoop/templates/conf中瞭解配置的示例模板，比如我的hadoop環境中文件在 /usr/local/hadoop-1.2.1/share/hadoop/templates/conf
關於hadoop的數據存放目錄
http://blog.sina.com.cn/s/blog_912389e501010sb0.html
hadoop fs -ls文件存儲位置
http://bbs.csdn.net/topics/390391055
分佈式文件系統HDFS(大數據存儲實戰)
http://www.cnblogs.com/Bestsonic/p/4201882.html
（1）瞭解core-site.xml 、mapred-site.xml中的配置
core-site.xml、mapred-site.xml兩個配置文件分別對應的是namenode | datanode 和jobtracker | tasktracker進程
將core-site.xml、mapred-site.xml中設定的端口添加匹配策略到主節點主機的iptables中，如此在主節點主機開啓iptables的情況下，slave節點主機的hadoop各子進程依然正常啓動。
（2）hdfs-site.conf文件中的最簡配置和進一步配置。
將文件存到hdfs之後，hadoop實際將它存儲到了哪裏？！
hdfs-site.conf文件中的最簡配置就是隻配置相應於slave節點主機數量的replication的參數數值。這是hdfs文件的存儲位置是默認的。
默認的數據存放目錄如下:
dfs.name.dir /tmp/hadoop-%username%/dfs/name
dfs.data.dir /tmp/hadoop-%username%/dfs/data
hdfs-site.conf文件進一步配置可以設定 dfs.name.dir 和 dfs.data.dir。
備註1：進一步的設定內容如下，（1）重新設定後，需要終止hadoop各進程，重新執行hdfs格式化。否則主節點主機的namenode進程會啓動失敗。（2）經實踐，發現只在主節點主機hdfs-site.conf中作如下配置和在所有節點主機hdfs-site.conf中設定如下內容，有一樣是相同的，就是隻有在主節點主機中hadoop的安裝目錄下生成'name1”子目錄 （3）下面的設定中是設定了data路徑的，但是指定的hadoop路徑下沒有生成data子目錄，原因有待分解——在集羣中所有主機都設定了dfs.name.dir和dfs.data.dir後，主節點主機下生成name1（需要重新格式化hdfs），slave節點主機下生成data目錄（若是在設定namedir之後設定的，那麼只需重啓hadoop就可以）。
備註2：經調試發現，爲slave節點主機也配置了相同的設定內容後，在不重新格式化hdfs的情況下，只需要重新啓動hadoop，在slave節點主機的安裝目錄下就會生成在hdfs-site.conf通過dfs.data.dir設定的存儲數據的數據目錄。
操作備註：至此，繼《初級2.1》基礎版本的hadoop集羣環境完全搭建完成之後，這裏調試找到了先前部署失敗的原因，並進一步瞭解了hdfs-site.conf以及core-site.xml 、mapred-site.xml三個配置文件簡單的基礎理論，包括結合的實踐（1）主節點主機開啓iptables對slave節點hadoop子進程的影響；（2）主節點主機hosts文件配置對錯 對 在50070端口的web界面能否檢測到“Live Nodes”slave主機存活狀態或使用命令" hadoop dfsadmin
-report ”能否看到分佈集羣中slave節點主機狀態 的影響；（3）hdfs-site.conf的進一步配置 指定文件資源的存儲。接下來，就基於基礎版本（1.2.1hadoop舊版本）（1）瞭解hadoop的使用，站在使用者的角度，新開博文《Hadoop實踐學習——初級2.2》記錄之。（2）瞭解外圍配置，hadoop是否適合如隨機啓動等。（3）深入瞭解更多hadoop理論基礎
國內第一篇詳細講解hadoop2的automatic HA+Federation+Yarn配置的教程
http://www.cnblogs.com/meiyuanbao/p/3545929.html
Hadoop入門進階步步高（六）-Hadoop1.x與Hadoop2的區別
http://blog.csdn.net/fenglibing/article/details/32916445
hadoop2集羣搭建
https://my.oschina.net/u/1464779/blog/312073
Hadoop 新 MapReduce 框架 Yarn 詳解
http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/