这个issue主要提供跨区域的Hadoop+Spark集群构建解决方案，并附带上一个疑难杂症的记录，避免后面的同学踩坑。
跨区域集群构建
经过痛苦的Debug，我们找到了一个异常优雅的方式来解决这个问题。最终排查发现问题所在：Slave服务器上没有任何关于自身公网IP的配置，但Slave竟然尝试使用自身的公网IP来访问自身（云服务器使用公网IP访问自身是被禁止的）。
我们推测这个问题是在Master服务器上的/etc/hosts中，填写的了Slave的公网IP，然后通过Master在整个Hadoop集群中广播，导致Slave尝试使用自己的公网IP去访问自身。
问题清楚了，那么解决方案也很简单，让Slave服务器通过公网IP访问自身的时候先转到自己的内网IP再通过内网IP访问自己。具体操作只是在Slave服务器的/etc/hosts中新增一行公网IP到内网IP的映射，最终文件类似：
// /etc/hosts on slave02
127.0.0.1 localhost
master的公网IP master
salve02的内网IP slave02
salve02的内网IP slave02的公网IP // 新增这一行
验证修改是否生效，可以在Slave上cha尝试运行下面这个命令：
// 先往hdfs中放一个测试文件
hadoop fs -put data.csv /
// 测试命令
hdfs dfs -cat /data.csv | head -n 5
如果在Slave上能够成功获取到测试文件的前5行，那么就是成功了，然后就可以按照实验教程进行集群部署了。
刚开机内存就占满了？！
我们在部署Hadoop集群的时候发现Master上的内存刚开机就被占用了90%，导致Hadoop无法启动。一开始以为是用户进程占用了太多，结果发现是Lniux的HugePage锁定：不知道是哪一个程序修改了配置文件，导致开机就有1280个大页表被分配出去了，但是又没有被使用！
下面是一系列解决这个问题的命令：
// 查看可用内存
free -h
// 查看大页表占用内存
grep Huge /proc/meminfo
// 临时释放大页表
sudo sysctl -w vm.nr_hugepages=0
另外还需要去修改系统配置文件/etc/sysctl.conf，检查其中有没有类似vm.nr_hugepages=1280的一行，直接把这行删掉，避免下次开机又占用那么多内存。
这个issue主要提供跨区域的Hadoop+Spark集群构建解决方案，并附带上一个疑难杂症的记录，避免后面的同学踩坑。
跨区域集群构建
经过痛苦的Debug，我们找到了一个异常优雅的方式来解决这个问题。最终排查发现问题所在：Slave服务器上没有任何关于自身公网IP的配置，但Slave竟然尝试使用自身的公网IP来访问自身（云服务器使用公网IP访问自身是被禁止的）。
我们推测这个问题是在Master服务器上的
/etc/hosts中，填写的了Slave的公网IP，然后通过Master在整个Hadoop集群中广播，导致Slave尝试使用自己的公网IP去访问自身。问题清楚了，那么解决方案也很简单，让Slave服务器通过公网IP访问自身的时候先转到自己的内网IP再通过内网IP访问自己。具体操作只是在Slave服务器的
/etc/hosts中新增一行公网IP到内网IP的映射，最终文件类似：验证修改是否生效，可以在Slave上cha尝试运行下面这个命令：
// 先往hdfs中放一个测试文件 hadoop fs -put data.csv / // 测试命令 hdfs dfs -cat /data.csv | head -n 5如果在Slave上能够成功获取到测试文件的前5行，那么就是成功了，然后就可以按照实验教程进行集群部署了。
刚开机内存就占满了？！
我们在部署Hadoop集群的时候发现Master上的内存刚开机就被占用了90%，导致Hadoop无法启动。一开始以为是用户进程占用了太多，结果发现是Lniux的HugePage锁定：不知道是哪一个程序修改了配置文件，导致开机就有1280个大页表被分配出去了，但是又没有被使用！
下面是一系列解决这个问题的命令：
另外还需要去修改系统配置文件
/etc/sysctl.conf，检查其中有没有类似vm.nr_hugepages=1280的一行，直接把这行删掉，避免下次开机又占用那么多内存。