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/