设计高可用性、容错和数据隔离的 Hadoop 集群

Hadoop 不再仅仅是一个时髦词，它已成为业务必需品。数据总是大量涌入，但是在最近，我们可能已经在解锁这种指数级增长的数据。大数据分析中的现代技术提供了新的方法来识别和纠正故障、帮助数据挖掘、提供优化反馈，这些方法是无穷无尽的。现代的 Hadoop 生态系统不仅提供了可靠的分布式聚合系统，无缝地提供数据的并行处理，同时也通过分析来提供大数据的见解。

在这篇文章中，我们将研究一种高可用、容错的 Hadoop 集群的设计。但首先让我们潜入到 Apache Hadoop 的核心部件中，在这之后我们将通过一些修改，来满足简约的设计需求列表，即充分发挥底层 Apache Hadoop 的基础设施优势，同时又增加安全性和数据级隔离。那么，让我们先来谈谈核心组件（如图 1 所示）

图 1：Apache 的 Hadoop 的核心组件

HDFS 集群

HDFS 集群是由一个 NameNode 和多个 DataNodes 组成的主从结构，如图 2 所示。NameNode 是个数据管理器，负责管理 HDFS 文件和块，还有文件系统的命名空间。该信息作为命名空间镜像和可编辑的日志永久保存在本地驱动器上。NameNode 还存储非持久性的信息，例如给定文件中所有块（block）的位置。 HDFS 文件被分成块，然后复制和存储在 DataNodes 上。每个 DataNode 定期与 NameNode 同步块信息。HDFS 的架构考虑到 Apache Hadoop 的数据存储、容错性和防损数据丢失的需要。

图 2：HDFS 架构 - NameNode（主） - DataNodes（从）配置

YARN（YARN 应用资源协调）架构

MapReduce 2.0 或 YARN 分摊了 JobTracker（Hadoop 以前版本的作业调度器）中的责任，这样应用管理和资源管理就分割开来。YARN 还可以帮助不同的作业进行调度和监控资源管理。

ResourceManager 是一个全局性的主控的资源仲裁员。ApplicationMaster 负责管理不同的用户应用，每个应用程序对应一个 ApplicationMaster。因此，你可以有一个 ApplicationMaster 对应一个 MapReduce 应用，而另一个 ApplicationMaster 对应一个交互式应用，以及其它类似的情况。JobHistoryServer 守护进程负责跟踪这些应用程序，并记录其完成。最后，每个节点（node）上还有一个称为 NodeManager（类似于先前版本的 TaskTracker）的从属逻辑实体，负责跟踪该节点上运行的任务。 YARN 架构照顾了 Apache Hadoop 数据计算和管理方面的需要。

图 3：YARN 架构 - ResourceManager 中（主） - ApplicationMaster+ NodeManager（主 + 从）配置

现在，我们有了 Apache Hadoop 核心部件的背景，让我们快速记下这个简约的设计需求列表。我会先把它们列举出来，然后详细论述在 Apache Hadoop 2 上如何满足这些需求。

需求：

• 高可用性 - 集群应永远不会失败。
• 安全性 - 集群应涵盖所有的安全层次
• 向外扩展 - 最大化（网络 IO）性能并最大限度地减少物理尺寸。
• 虚拟机上的 Hadoop - 弹性、改进的多租户、提高系统的利用率。

高可用性

Hadoop 2 版本，建立了主备的 NameNode 配置，以此避免了单点故障。当保守的故障切换控制器（Failover Controller）检测到故障，它可以让备用节点接管，让主用节点退下来（通过“隔离”或“拍其他节点的头部”）。因为主用和备用的 NameNodes 分享了可编辑日志和报告，备用 NameNode 可以非常迅速地接管。

同样，YARN 中 ResourceManager 也可以支持高可用性。切换控制器是 ResourceManager 的一部分，它在主用 ResourceManager 失败后会让备用 ResourceManager 来接管。

安全

每当谈论安全，我们谈的就是“防御层”（也被称为“防御环”）。这些层包括认证，授权，审计和数据保护：

安全 - 身份验证（Authentication）：

在原生 Apache Hadoop 中最常见的认证形式就是 Kerberos。认证可以是从用户到服务，例如 HTTP 认证 ; 或者可以是从服务到服务（代表用户 - 例如用户代理；或作为服务，例如客户端 SSL 证书）。

安全性 - 授权（Authorization）：

Apache Hadoop 已经提供了类似 Unix 的文件权限，也有针对 Map Reduce 任务、YARN 的访问控制列表，等等。

安全性 – 责任（Accountability）/ 审计（Audit）：

问责需要审计日志，原生 Apache Hadoop 在 NameNodes 上提供了审计日志，记录文件的创建、打开，等等。另外，还有一些针对 JobTracker、JobHistoryServer 和 ResourceManager 的历史记录。历史日志记录了特定集群上运行的所有作业。

安全 –数据静止（Data at Rest）和数据移动（Data in Motion）时的保护：

在数据静止时进行加密是很容易做到的，可以使用操作系统所提供的任何加密方法，或者其他硬件级的加密。另一方面，针对移动中数据的加密，需要在配置文件中使能，具体详述如下：

通过 RPC 交互的客户端，可以启用 SASL（简单认证和安全层）协议，这通过设置 core-site.xml 中的’hadoop.rpc.protection=privacy’完成。注意：JAVA SASL 提供不同级别的数据保护（也称为 QOP - 保护质量）。根据所需的质量，用户可以将保护参数设定为“authentication”表示为仅需要身份认证 ; “integrity”表示为需要身份认证和数据交换的完整性；“privacy”表示需要添加加密（对称密钥）和避免“中间人”（man-in-the-middle）的攻击。无论完整性检查和加密都会带来性能开销。

HDFS 数据使用的数据传输协议（DTP）不使用 SASL 框架进行认证，从而产生的直接影响是没有 QOP（保护质量）。因此，有必要来包装 DTP 并与 SASL 进行握手，这可通过在 hdfs-site.xml 中设置’dfs.encrypt.data.transfer=true’来实现。

最后，基于 SSL 的 HTTP 只要简单设置’dfs.https.enable=true’，然后在 hdfs-site.xml 中设定“dfs.client.https.need-auth=true’就能实现双向 SSL。对于 MapReduce 的洗牌（Shuffle），SSL 可以通过在 mapred-site.xml 中设置“mapreduce.shuffle.ssl.enabled=true’来启用。

向外扩展

虽然 Hadoop 吹嘘仅需要廉价的商用硬件，但 Hadoop 的数据流量始终是一个大问题。即使你只有一个中等规模的集群，仍会有很多复制流量，Mappers 和 Reducers 之间也会有数据移动。因此，选用支持集群硬件的网络骨干网是非常重要的，它可以同时满足良好的性能和足够的经济性，达到甚至超越向外扩展的需求。

在 Servergy 公司，我们设计这样一个系统，使用飞思卡尔的 QorIQ T4240 64 位通信处理器。高能效的 Servergy CTS 存储设备（在图 4 中示出）具有两个 T4240 处理器。每个 T4240 都有安全协处理器用于加速加密 / 解密操作。该 T4240 还拥有四个万兆以太网端口和一个 20Gig SRIO（serial Rapid IO）端口。 SRIO 提供低延迟，高带宽互连。我们目前的单一集群只使用八个万兆以太网端口中的四个，每个 Servergy CTS 设备 - 两个万兆以太网端口连接到活动的交换机和其他两个分别连接到冗余 / 待机开关，以提供在交换机级别的高可用性，这种构造示于图 5。注意：根据部署我们可以将万兆以太网端口绑定以增加带宽或者使用 SRIO 低延迟传输。

图 4：Servergy CTS 存储设备框图

图 5：CTS 设备解决方案： 10x12x2=240 核 ; 480 线程

虚拟机上的 Hadoop

许多在 Hadoop 集群上的系统不仅处理计算需求，同时也提供数据存储。因此，如果你正考虑将 Hadoop 作为一种服务，那么就需要关注数据安全。进入虚拟化！虚拟化不仅提供了所需的隔离，同时也提供了弹性。虚拟化增强了 YARN 提供的多租户特性，并最大限度地提高了资源的利用率和系统的利用率。除了以上所说，易于部署的也是虚拟化的很大的优势。

跟随 Hadoop 的传统布局，每个虚拟机（VM）可以运行 NodeManager/TaskTracker 和 DataNode，如图 6 所示。这种配置没有体现虚拟化的所有好处。首先，这种配置并不是真的有弹性；你必须预先为你的（增长）需求进行配置。例如，在紧密配置的集群上任何的数据增长将需要添加新的节点到集群中，但现在计算资源是空闲的，所以有必要去平衡集群，并且数据计算和数据存储也没有分离。

图 6：虚拟机上传统 Hadoop 布局

为了使其更有弹性，我们可以改变虚拟机的数据和计算配置，设计成更加面向服务的体系结构，将更有利于 Hadoop 作为一种服务提供者（甚至是基础设施即服务的提供者）。让我们来讨论两个新的配置：

图 7：虚拟化的 Hadoop 在 SOA（面向服务）架构中配置

图 7 给出了一种配置，我们有一个虚拟化的 DataNode 对应了多个 NodeManagers/TaskTracker。更多的 NodeManagers 可以作为虚拟节点被添加到集群中，这取决于集群的计算需求。因为每个虚拟机都在运行自己的 NodeManager，所以这种配置不仅提供了计算和数据层面的隔离，还提供了巨大的多租户隔离。关键是要找到一个很好的平衡，即在一个给定的主机上，虚拟 DataNode 对应的虚拟 NodeManagers 的数目。这将在很大程度上取决于你的数据，复制因子，应用程序和集群容量。

在基础设施即服务（IaaS）领域的另一种配置获得了很多的关注，即有持久性数据，并加入虚拟化的计算节点（NodeManagers/ TaskTracker）；或者组合数据节点和计算节点来完成集群。这种构造示于图 8。

图 8：虚拟化的 Hadoop 在 IaaS（基础设施即服务）中配置

这里的基础设施需要关注所有的网络、负载均衡和持久性数据的存储需要。集群和虚拟机管理器控制负责控制 Hadoop 集群，后者是由计算的虚拟机（TaskTracker/NodeManagers）和“DataNode+ NodeManager”组合虚拟机所组成。此配置易于对在云中的 HDFS 数据进行访问（当需要计算时），并且也便于数据备份到持久的存储器中。在这样的结构中，没有必要在云中长时间运行集群，因为所有的数据（原始、分析或挖掘）都会持久的存储。

作者简介

莫妮卡. 贝克威思是软件性能工程师，在硬件行业工作超过十年。她最新的头衔是 Servergy 公司的性能架构师 - Servergy 是一家技术解决方案的集成公司，专注于数据安全。在 Servergy 之前，莫妮卡曾在甲骨文 / Sun 和 AMD 为服务器级系统优化 JVM。莫妮卡在 2013 年被 JavaOne 评为明星讲师。你可以在 Twitter（@mon_beck）上关注莫妮卡。

查看英文原文： Designing a Highly Available, Fault Tolerant, Hadoop Cluster with Data Isolation