Architecture 具有7台服务器的Hadoop体系结构-平衡连续性和性能

我们正在从AWS MapReduce转移到我们自己机架上的Hadoop集群。最初，我们将有7台专用于Hadoop/HDFS的服务器

我们存储在HDFS上的数据将是任务关键型的，我不希望我们有备份选项（至少在使用的第一天没有），所以我想尽我所能保证连续性

我还想最大限度地利用我们的计算能力，因为我们的工作可以很容易地使用两倍的硬件

• 在这个7服务器集群中，我应该为每个框指定什么？特别是哪些流程应该重叠（例如，备份名称节点是否应该作为任务节点和类似节点共享一个框？）

---

我们最后做的是：

使用LXC（LXC是这里的关键组件），我们在两台服务器上为管理组件（如作业管理器、namenode和其他各种组件）创建了单独的容器，因为namenode和作业管理器是资源最密集的，所以我们将它们分放在这两台服务器上（每个组件在其各自单独的LXC容器中）。我们在这两台服务器之间拆分的其余组件

然后，我们在这两个“管理”服务器上分别部署了一个“精简”数据节点和任务跟踪器。我们使用LXC的控制组为管理组件提供CPU和磁盘优先级，而以牺牲数据/任务节点为代价。我们使用Cloudera Manager的简化配置，在这两个框上轻松地向数据/任务节点部署数量减少的任务插槽

通过这种方式，我们充分利用了硬件，其余的盒子都是专用的“普通”数据/任务节点

当然，我们有一个备份名称节点运行在与作业跟踪器相同的物理主机上，主名称节点运行在第二个物理框上，这为我们提供了备份。我们还在3台工作机器上的LXC容器中安装了一个use space NTFS客户端，并让namenode在那里写出一份配置副本作为进一步的备份

---

我们确实有一次（磁盘）因硬件故障丢失了namenode，并且能够成功地从次要节点恢复它。

我们将尝试使用LXC容器来分离各种进程（任务节点、名称节点、次要名称节点、主节点），并将名称节点、次要节点和主节点与任务节点重叠（因为这些服务器都有一个大磁盘和比名称节点或主节点所需的更多cpu+内存）。我们将使用cgroups来保证主节点和名称节点的资源。我将在将来尝试时自己回答这个问题。您曾经实现过这一点吗？