共计 10081 个字符，预计需要花费 26 分钟才能阅读完成。
vSphere Big Data Extensions（简称 BDE）支持多种部署方式来构建 Hadoop 集群。按：
- 存储 / 计算绑定模型：将存储节点（Data Node）和计算节点（Task Tracker）部署在相同的虚拟机中。这是最直接简单的部署模型，可以用于概念验证和承载小规模集群的数据处理任务。
- 单一计算模型：只部署计算节点（Job Tracker 和 Task Tracker）的集群类型。
- 存储 / 计算分离模型：将存储节点（Data Node）和计算节点（Task Tracker）部署在不同的虚拟机中，并且根据特定的业务需求，通过相应的分布算法决定集群在 vSphereESX 物理主机上的拓扑结构。
- 自定制集群：用户可以根据具体的业务需求，自定制集群的部署结构、资源模型和配置参数。
本文我们将着重介绍前 2 个部署模型，即存储 / 计算绑定模型和单一计算模型。
存储和计算节点绑定模型（Data-Compute Combined Deployment）
通常情况下，我们为了保证 Hadoop 集群数据本地化（Data Locality）的需要，会将存储（DataNode）和计算（TaskTracker）服务部署在相同节点上。Big Data Extensions 也提供这样的部署模式。
你可以使用 BDE 的命令行工具，通过运行 cluster create –name cluster_name 命令创建一个基本的默认 Hadoop 集群。
这类集群将包含一个主节点（master），运行 Apache Hadoop 1.2.1（BDE 1.0 内置的默认 Hadoop 发行版）的 NameNode 和 JobTracker；三个工作节点（worker），运行 DataNode 和 TaskTracker；一个客户端节点（Clientnode），运行 Hadoop 客户端，Pig 和 Hive 等。
这里将 DataNode 和 TaskTracker 搭建在同一个虚拟机节点内部，这就是存储和计算节点绑定模型。
单一计算节点模型（Compute-OnlyDeployment）
如果你的生产或开发环境里已经有了 HDFS，并且有数以 TB 的分析型数据存在于其中，商业分析团队根据新的业务需求，开发新功能去挖掘新的模式，这时您可以搭建一个单一计算节点集群（Compute-OnlyCluster）。
单一计算节点集群指的是只部署 MapReduce 服务，包括 Jobtracker 和 Tasktracker，并且链接到某个已经存在的 HDFS 上。这样做的好处有很多，首先可以避免搭建完整集群后的大规模数据拷贝或迁移，减少开发环境的等待时间，可以立即部署立即使用，非常适合临时性的开发测试环境；其次，也可以在不同的计算集群之间做到性能隔离，安全性隔离和故障隔离；另外，在兼容性满足的情况下，您也可以使用第三方的商业版 HDFS 如 Isilon 等等。
对于单一计算节点集群，您也可以使用动态伸缩功能（Auto-Elasiticity）来动态地调配您的资源。
下面列举了这种集群部署的实例定义文件，您可以使用它创建 Compute-OnlyCluster。externalHDFS 字段定义了要使用的已存在的 HDFS 服务。请将 hadoop_jobtracker 角色赋给 master 节点组，将 hadoop_tasktracker 角色赋给 worker 节点组。对于 externalHDFS 所指定的 HDFS 集群，默认情况下请设置 port_num 为 8020。对于 Hadoop2.0 集群，例如 CDH4 或是 PivotalHD 等，默认情况下请设置 port_num 为 9000。在集群定义文件中，ExternalHDFS 字段和 hadoop_namenode，hadoop_datanode 角色不能同时存在，否则可能会导致集群创建失败或创建的集群无法正常运行。
{
“externalHDFS”: “hdfs://<hostname-of-namenode>:<port_num>”,
“nodeGroups”: [
{
“name”: “master”,
“roles”: [
“hadoop_jobtracker”
],
“instanceNum”: 1,
“cpuNum”: 2,
“memCapacityMB”: 7500,
},
{
“name”: “worker”,
“roles”: [
“hadoop_tasktracker”,
],
“instanceNum”: 4,
“cpuNum”: 2,
“memCapacityMB”: 7500,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 20
},
},
{
“name”: “client”,
“roles”: [
“hadoop_client”,
“hive”,
“pig”
],
“instanceNum”: 1,
“cpuNum”: 1,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 50
},
}
]
}
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2013-10/92033p2.htm
相关阅读：
Hadoop 2.0 安装向导 (0.23.x) http://www.linuxidc.com/Linux/2012-05/61463.htm
Hadoop 1.2.1 单节点安装 (Single Node Setup) 步骤 http://www.linuxidc.com/Linux/2013-08/89377.htm
在 CentOS 上安装 Hadoop http://www.linuxidc.com/Linux/2013-08/88600.htm
Ubuntu 12.04 安装 Hadoop http://www.linuxidc.com/Linux/2013-08/88187.htm
CentOS 6.3 x86_64 安装与配置 Hadoop-1.0 http://www.linuxidc.com/Linux/2013-07/87959.htm
Hadoop 入门 –Hadoop2 伪分布式安装 http://www.linuxidc.com/Linux/2013-06/86403.htm
文中，我们介绍了 Hadoop 集群部署模型中的 2 个类型，分别是存储 / 计算绑定模型和单一计算模型。这篇文章我们会着重介绍存储 / 计算分离的 Hadoop 集群部署模型。
存储和计算节点分离模型（Data-ComputeSeparation Deployment）
如果你把存储和计算部署在相同的节点内，这固然可以达到数据本地化（DataLocality）的需要，但是当你的计算能力不足需要扩容时，增加计算节点的同时也必须增加存储节点。因此存储和计算绑定模型下，对于存储和计算节点的扩容必须同时进行，无法灵活定制，这难免会造成计算或存储资源的浪费。
这里我们向您推荐一种新的部署模型——存储和计算节点分离模型。该模型是指您可以把存储服务（DataNode）和计算服务（TaskTracker）等分开部署在不同的虚拟机中。这样您既可以灵活地为存储节点和计算节点单独扩容，也为多个计算集群共享相同的存储集群打下基础，为您节省了绑定模式下扩容导致的资源浪费，减少 CAPEX，也避免了维护多个存储集群、造成大量数据迁移拷贝的 OPEX 麻烦。关于多个计算集群使用同一的存储，请参见本文的自定制集群部分。
但是纯粹的分离模型并不能保证传统的 Hadoop 的数据本地性特性。因此 BDE 做了相应改进。用户可以指定将独立的计算节点虚拟机部署在存储节点所在的物理主机（Host）上，这样就避免其间的通信经过网络。
为了方便用户控制存储节点和计算节点的拓扑，BDE 提供了几类节点分布策略。首先是单位主机节点数目策略（InstancePerHost），用户可以指定在同一台物理主机上，同时运行的存储节点和计算节点的数目；其次，节点组依赖关系（GroupAssociation），用户也可以指定计算节点组和存储节点组之间的依赖关系——弱依赖（weakgroupAssociation）和严格依赖（strictgroupAssociation）等；第三，当然对于任何一种部署模型，BigData Extensions 都提供机架感知网络拓扑结构策略（RackAwareness），这部分与本文关系不大，如果您感兴趣，请参考 BDE 的官方用户手册获取更多信息。
因此，后续我们会从不适用任何分布策略和应用分布策略两个方面为大家详细介绍本模型。
不包含主机排布限制的存储 / 计算分离模型
BDE 支持部署不包含任何节点排布限制的存储 / 计算分离的 Hadoop 集群。部署计算节点时不会考虑存储节点的主机排布，也无法利用存储节点的磁盘空间作为计算节点运行任务的临时文件夹（BDE 提供的 TempFS 功能能够让计算节点利用存储节点的磁盘空间作为运行 Job 的临时文件夹。有关 TempFS 简介，请参加下一小节的介绍）。这种集群无法充分支持 Hadoop 的数据本地化特性，适用于简单的概念验证（PoC）。
下面列举了这种集群部署的示例定义文件，使用它，您可以创建四个数据存储节点和八个计算节点，instanceNum 配置节点数目。默认情况下，BDE 使用 RoundRobin 算法将各个节点排布在物理主机上。
{
“nodeGroups”:[
{
“name”: “master”,
“roles”: [
“hadoop_namenode”,
“hadoop_jobtracker”
],
“instanceNum”: 1,
“cpuNum”: 2,
“memCapacityMB”: 7500,
},
{
“name”: “data”,
“roles”: [
“hadoop_datanode”
],
“instanceNum”: 4,
“cpuNum”: 1,
“memCapacityMB”: 3748,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 50
}
},
{
“name”: “compute”,
“roles”: [
“hadoop_tasktracker”
],
“instanceNum”: 8,
“cpuNum”: 2,
“memCapacityMB”: 7500,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 20
}
},
{
“name”: “client”,
“roles”: [
“hadoop_client”,
“hive”,
“pig”
],
“instanceNum”: 1,
“cpuNum”: 1,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 50
}
}
],
“configuration”: {
}
}
包含节点网络拓扑和主机排布策略的存储 / 计算分离模型
看到这里您一定会发问，如果不将计算节点（TaskTracker）部署在存储节点（DataNode）所在的虚拟机上，那如何保证数据本地化的特性呢？BDE 提供了优雅的分布策略可以既享有存储 / 计算分离的易扩展性，同时又保证数据本地化的要求。
如果您对数据本地化诉求很高，希望尽量减少网络通讯、以节约带宽并提升处理速度，BDE 在部署存储 / 计算分离的 Hadoop 集群时，也可以同时考虑网络拓扑和主机排布策略。
下面列举了这种集群部署的示例定义文件，使用它可以创建四个数据存储节点（DataNode）和八个计算节点（TaskTracker），每个节点组（NodeGroup）中的 placementPolicy 字段定义了该组节点的排布策略。
其中存储节点（节点组 data），instancePerHost= 1 表明一个物理主机上最多有且仅有一个数据节点，因此四个数据节点会被部署在四台物理主机上。groupRacks 定义了存储节点的网络拓扑定义，4 台要使用的物理主机会按照 RoundRobin 算法在 Rack1，Rack2，Rack3 这三个机架里面选择。
计算节点（节点组 compute），instancePerHost= 2 表明一个物理主机上最多有且仅有两个节点。groupAssociations 定义了节点组之间的依赖关系，reference=data 表明计算节点的分布会依赖于存储节点的位置，依赖程度由“type=STRICT”定义，意即计算节点将被严格部署在存储节点所在的物理主机上，否则将会部署失败。从物理主机的视图，您会看到所用到的 4 台物理主机上，每个都将会部署一个存储节点和两个计算节点，这样在同一台物理主机上的存储虚拟机和计算虚拟机之间可以避免网络通信。
这样做在保持了存储 / 计算相分离的可扩展性优势的同时，如果在部署集群时，指定网络拓扑结构为 HVE，就可以彻底保证数据本地化的要求。HVE 功能会使得 Hadoop 自身对虚拟化架构感知，能够配合数据本地化的策略进行计算任务的调度。目前 PivotalHD 1.2 之后的版本都支持 HVE 功能。
HVE 功能简介：
传统的 Hadoop 集群节点拓扑结构包括机架和主机层，但虚拟化在此基础上还需要知道 hypervisor 这一层。HVE 功能使得 Hadoop 集群能够感知机架 - 物理主机 -Hadoop 节点三层架构，并且根据相应算法使运行于同一台物理主机上的存储节点和计算节点之间的通信方式满足数据本地化的要求。
另外，如果在集群定义文件中开启计算节点 tempFS 功能，那计算节点会利用存储节点的磁盘空间作为任务运行的临时文件夹，有效地使用磁盘空间。
TempFS 功能简介：
当我们部署存储 / 计算分离的集群时，要为计算节点设置一个容量能满足业务需求的临时文件夹以保存任务运行期间的中间过程文件。另外如果整个集群的计算负载降低，计算节点被收缩减除（decommission）, 他所占用的磁盘空间无法被回收，也会造成存储空间的浪费。
所以这里我们引入了 TempFS 功能。这个功能使得计算节点可以使用部署在同一台物理主机上的存储节点的磁盘空间，这样既能够保证临时文件夹的空间充足，同时也能在计算节点被 decommission 后，也可以回收它的空间以供其他节点或应用使用。
另外 BDE 对于独立的计算节点，提供自动动态伸缩功能（Auto-Elasticity）。如果通过命令行 cluster setParam –name cluster_name –elasticityMode auto –minComputeNodeNum minNum，可以根据当前 vCenter 的负载，避免资源的过量使用，适时地动态调整已经启动的计算节点的数目，并且保证开机运行的计算节点的数目不少于 minNum，这样就可以最大化地有效利用资源，又可以节能减排。
关于 HVE，tempFS 和 Auto-Elasticity 功能的详细介绍，请参见 BDE 的官方用户手册。
{
“nodeGroups”:[
{
“name”: “master”,
“roles”: [
“hadoop_namenode”,
“hadoop_jobtracker”
],
“instanceNum”: 1,
“cpuNum”: 2,
“memCapacityMB”: 7500,
},
{
“name”: “data”,
“roles”: [
“hadoop_datanode”
],
“instanceNum”: 4,
“cpuNum”: 1,
“memCapacityMB”: 3748,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 50
},
“placementPolicies”: {
“instancePerHost”: 1,
“groupRacks”: {
“type”: “ROUNDROBIN”,
“racks”: [“rack1”, “rack2”, “rack3”]
},
}
},
{
“name”: “compute”,
“roles”: [
“hadoop_tasktracker”
],
“instanceNum”: 8,
“cpuNum”: 2,
“memCapacityMB”: 7500,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 20
},
“placementPolicies”: {
“instancePerHost”: 2,
“groupAssociations”: [
{
“reference”: “data”,
“type”: “STRICT”
}
}
},
{
“name”: “client”,
“roles”: [
“hadoop_client”,
“hive”,
“pig”
],
“instanceNum”: 1,
“cpuNum”: 1,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 50
}
}
]
}
vSphere Big Data Extensions（简称 BDE）支持多种部署方式来构建 Hadoop 集群。按：
- 存储 / 计算绑定模型：将存储节点（Data Node）和计算节点（Task Tracker）部署在相同的虚拟机中。这是最直接简单的部署模型，可以用于概念验证和承载小规模集群的数据处理任务。
- 单一计算模型：只部署计算节点（Job Tracker 和 Task Tracker）的集群类型。
- 存储 / 计算分离模型：将存储节点（Data Node）和计算节点（Task Tracker）部署在不同的虚拟机中，并且根据特定的业务需求，通过相应的分布算法决定集群在 vSphereESX 物理主机上的拓扑结构。
- 自定制集群：用户可以根据具体的业务需求，自定制集群的部署结构、资源模型和配置参数。
本文我们将着重介绍前 2 个部署模型，即存储 / 计算绑定模型和单一计算模型。
存储和计算节点绑定模型（Data-Compute Combined Deployment）
通常情况下，我们为了保证 Hadoop 集群数据本地化（Data Locality）的需要，会将存储（DataNode）和计算（TaskTracker）服务部署在相同节点上。Big Data Extensions 也提供这样的部署模式。
你可以使用 BDE 的命令行工具，通过运行 cluster create –name cluster_name 命令创建一个基本的默认 Hadoop 集群。
这类集群将包含一个主节点（master），运行 Apache Hadoop 1.2.1（BDE 1.0 内置的默认 Hadoop 发行版）的 NameNode 和 JobTracker；三个工作节点（worker），运行 DataNode 和 TaskTracker；一个客户端节点（Clientnode），运行 Hadoop 客户端，Pig 和 Hive 等。
这里将 DataNode 和 TaskTracker 搭建在同一个虚拟机节点内部，这就是存储和计算节点绑定模型。
单一计算节点模型（Compute-OnlyDeployment）
如果你的生产或开发环境里已经有了 HDFS，并且有数以 TB 的分析型数据存在于其中，商业分析团队根据新的业务需求，开发新功能去挖掘新的模式，这时您可以搭建一个单一计算节点集群（Compute-OnlyCluster）。
单一计算节点集群指的是只部署 MapReduce 服务，包括 Jobtracker 和 Tasktracker，并且链接到某个已经存在的 HDFS 上。这样做的好处有很多，首先可以避免搭建完整集群后的大规模数据拷贝或迁移，减少开发环境的等待时间，可以立即部署立即使用，非常适合临时性的开发测试环境；其次，也可以在不同的计算集群之间做到性能隔离，安全性隔离和故障隔离；另外，在兼容性满足的情况下，您也可以使用第三方的商业版 HDFS 如 Isilon 等等。
对于单一计算节点集群，您也可以使用动态伸缩功能（Auto-Elasiticity）来动态地调配您的资源。
下面列举了这种集群部署的实例定义文件，您可以使用它创建 Compute-OnlyCluster。externalHDFS 字段定义了要使用的已存在的 HDFS 服务。请将 hadoop_jobtracker 角色赋给 master 节点组，将 hadoop_tasktracker 角色赋给 worker 节点组。对于 externalHDFS 所指定的 HDFS 集群，默认情况下请设置 port_num 为 8020。对于 Hadoop2.0 集群，例如 CDH4 或是 PivotalHD 等，默认情况下请设置 port_num 为 9000。在集群定义文件中，ExternalHDFS 字段和 hadoop_namenode，hadoop_datanode 角色不能同时存在，否则可能会导致集群创建失败或创建的集群无法正常运行。
{
“externalHDFS”: “hdfs://<hostname-of-namenode>:<port_num>”,
“nodeGroups”: [
{
“name”: “master”,
“roles”: [
“hadoop_jobtracker”
],
“instanceNum”: 1,
“cpuNum”: 2,
“memCapacityMB”: 7500,
},
{
“name”: “worker”,
“roles”: [
“hadoop_tasktracker”,
],
“instanceNum”: 4,
“cpuNum”: 2,
“memCapacityMB”: 7500,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 20
},
},
{
“name”: “client”,
“roles”: [
“hadoop_client”,
“hive”,
“pig”
],
“instanceNum”: 1,
“cpuNum”: 1,
“storage”: {
“type”: “LOCAL”,
“sizeGB”: 50
},
}
]
}
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2013-10/92033p2.htm
相关阅读：
Hadoop 2.0 安装向导 (0.23.x) http://www.linuxidc.com/Linux/2012-05/61463.htm
Hadoop 1.2.1 单节点安装 (Single Node Setup) 步骤 http://www.linuxidc.com/Linux/2013-08/89377.htm
在 CentOS 上安装 Hadoop http://www.linuxidc.com/Linux/2013-08/88600.htm
Ubuntu 12.04 安装 Hadoop http://www.linuxidc.com/Linux/2013-08/88187.htm
CentOS 6.3 x86_64 安装与配置 Hadoop-1.0 http://www.linuxidc.com/Linux/2013-07/87959.htm
Hadoop 入门 –Hadoop2 伪分布式安装 http://www.linuxidc.com/Linux/2013-06/86403.htm
在前两篇文章中，我们介绍了 Hadoop 集群部署的 3 个方式，即《存储 / 计算绑定和单一计算的 Hadoop 集群》，《存储 / 计算分离的 Hadoop 集群部署》。本文我们着重讲解最后一种方式，即构建自定义的 Hadoop 集群，作为对用户更为开放的一个部署选项。
自定制集群（Customcluster）
在复杂的业务背景下，往往某一种特定模型无法满足需求。比如，公司三个部门 A、B、C，分别需要自建 Hadoop 集群，但是他们需要消费相同的数据。三个部门对 Hadoop 集群的资源要求（CPU、内存、存储）存在不同需求，且大多数情况下他们对 Hadoop 使用不在同一时间：A 部门主要于凌晨至早六点，运行每日例行任务；B 部门需要在下午四点至夜间十点左右运行查询处理任务，对实时性要求相对比较高；C 部门需要在大部分的白天时段运行一些研究、开发和测试的任务。如何有效利用硬件服务器资源成为该公司 IT 部门重点考虑的问题。
如下图所示，如果不采用虚拟化技术进行整合，资金投入（CAPEX）意味着每个集群最大负载时硬件投资总和。但是通过整合，可以将三个集群共享资源池，CAPEX 意味着通盘最大负载。而且目前虚拟化可以带来 2:1 到 4:1 的整合比，极大的减少了资本投入。
根据三个部门的需求，我们搭建统一的一套 HDFS 存储集群，分别为三个计算集群提供存储服务。这样避免了搭建三个存储集群所引发的跨网络的大量数据迁移和拷贝工作，让需要维护的存储集群从三个减少到一个，从而减少操作成本 OPEX，也节省了原来需要采买大量存储器的资本投入 CAPEX。另外，由于 B 部门对时间延迟要求高，我们将其搭建成具有虚拟化节点感知的满足数据本地性要求的计算集群（具体方法请参见本博客“包含节点网络拓扑和主机排布策略的存储 / 计算分离模型”）。另外 A、C 部门的集群搭建成单一计算节点集群，并指向上述统一的 HDFS 集群。这样搭建，就保证了不同计算集群之间的资源隔离、故障隔离、配置隔离和安全隔离。
当然您也可以根据您的具体业务需求，将 Hadoop 集群和其他应用一并整合。
注：本文所使用的所有集群定义文件和命令都基于 BDE1.0 GA Build。
更多 Hadoop 相关信息见Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13
