在在VPC中发布和运行一个中发布和运行一个AmazonEMR集群（一）集群（一）
我们已经完成了对Hadoop需求的探索，并看到了VPC与EC2搭配起来让EMR服务更具效率的操作。通过建立一个新的
VPC，我们看到默认设置如何提供通信，以及构成Hadoop集群的实例需求，并通过修改这些行为来影响EMR。
时下，VPC已经成为发布Amazon EC2实例的默认环境，因此掌握Amazon VPC环境中的Amazon EMR集群运行原理
至关重要。在这篇博文中，我们将弄清楚为什么需要在EC2 VPC环境中运行Hadoop集群。然后，我们将建立一个新的
VPC环境，并发布一个EMR集群。这是这系列博文的第一部分，第二部分我们将详细介绍如何定制化DNS。
Hadoop通信需求（1）
通过 Hadoop wiki我们了解到：“为了让Hadoop正常工作，所有的机器必须可以相互感知，并相互通信；因此，它们需
要一个识别机制，从而其它主机可以快速找到它们。”在EMR中，主机间的感知和通信通过设置 VPC中的DNS解决方
案和DNS主机名称完成。通过启用这些默认设置，你的实例会被自动地指配主机名称——使用公共和私有IP地址（同
时，使用“-”替换“.”，比如ip-10-128-8-1.ec2.internal）。从而，实例可以通过 EMR-managed security groups实现通
信。
Hadoop 通讯需求（2）
在Hadoop 1中，通信需求是非常简单的，同时大部分情况也是非常宽容的。举个例子，Hadoop 1中，如果HDFS
DataNodes不可以被NameNode解析成一个全称域名，那么它将被回滚到一个IP地址，通信继续。因此，除下环境中
出现问题，一个配置得当的Hadoop 1环境很少崩溃。
随着Hadoop项目逐渐成熟，更健壮的 Hadoop安全模型需求也逐渐提升。Kerberos识别、网络加密等功能被加入
Hadoop以帮助阻止节点被添加到一个集群，比如下面这个HDFS配置参数：
dfs.namenode.datanode.registration.ip-hostname-check
在Hadoop 2中，不可以被NameNode解析的DataNode将会被拒绝通信：
org.apache.hadoop.hdfs.server.protocol.DisallowedDatanodeException: Datanode denied communication with namenode
本质上，Hadoop 1升级到Hadoop 2后并没有引起技术要求的改变。为了保证正常运行，节点间还是需要相互感知并通
信。但是在Hadoop 2中，升级引起的改变很可能会造成不适当的环境配置，从而造成HDFS因为UnknownHost、
ConnectionRefused和NoRouteToHost异常无法加载文件。
VPC中的设置
EMR位于VPC之外，同时还需要在任何时间可以与所有节点交互。集群中的实例需要定位（通过DNS）以及与EMR和
Amazon S3服务端点交互（使用宽松的安全组和网络ACLs）。以上这些将帮助到集群的创建、CloudWatch监视、日
志同步以及提交处理。微了完成这些，EMR集群还需要一个 Inernet网关。
默认路由或者非VGWs的情况下，NAT实例将不被支持。在这两种场景尝试发布一个集群将导致集群终止或者错误：
"The subnet configuration was invalid: Cannot find route to
InternetGateway in main RouteTable rtb-036bc666 for vpc vpc-a33690c6"
此外，在使用网络ACL子网中发布的EMR集群可能会打断这个通信。这主要因为 ACLs是无状态的，输入和输出规则
必须被明确的规定，不像 EMR-managed security groups中使用的有状态规则。如果EMR集群发布在一个使用了ACL
的子网中，并且没有提供足够的访问，那么集群将被终止。如果你必须使用ACL，那么请使用 EMR-managed security
groups作为IP地址和端口范围导航以满足实例的通信。
剩余8页未读，继续阅读
资源评论
