我们将从aws mapreduce迁移到我们自己机架上的hadoop集群。最初我们将有7台服务器专用于hadoop/hdfs。
我们存储在hdfs上的数据将是任务关键型的，我不希望我们有备份选项（至少在使用的第一天没有），所以我想尽我所能保证连续性。
我还想充分利用我们的计算能力，因为我们的工作可以很容易地使用双倍的硬件。
在这个7服务器集群中，我应该为每个框指定什么？特别是哪些流程应该重叠（例如，备份名称节点是否应该作为任务节点和类似节点共享一个框？）
我们将从aws mapreduce迁移到我们自己机架上的hadoop集群。最初我们将有7台服务器专用于hadoop/hdfs。
我们存储在hdfs上的数据将是任务关键型的，我不希望我们有备份选项（至少在使用的第一天没有），所以我想尽我所能保证连续性。
我还想充分利用我们的计算能力，因为我们的工作可以很容易地使用双倍的硬件。
在这个7服务器集群中，我应该为每个框指定什么？特别是哪些流程应该重叠（例如，备份名称节点是否应该作为任务节点和类似节点共享一个框？）
1条答案
按热度按时间z9zf31ra1#
我们最后做的是：
使用lxc（这里的关键组件是lxc），我们在其中两台服务器上为管理组件（如作业管理器、namenode和其他各种组件）创建了单独的容器，因为namenode和作业管理器是资源最密集的，所以我们将它们分在这两台服务器上（每个组件都在其各自单独的lxc容器中）。我们在这两个服务器之间拆分的其余组件。
然后，我们为这两个“管理”服务器中的每一个都部署了一个“简化的”数据节点和任务跟踪器。我们使用lxc的控制组为管理组件提供cpu和磁盘优先级，而牺牲了数据/任务节点。我们使用cloudera管理器的简化配置，轻松地将数量减少的任务槽部署到这两个框上的数据/任务节点。
这样我们就充分利用了硬件，其余的盒子都是专用的“普通”数据/任务节点。
当然，我们有一个备份名称节点和作业跟踪器运行在同一个物理主机上，主名称节点运行在第二个物理框上，这给了我们备份。我们还在3台工作机的lxc容器中安装了usespace ntfs客户机，并让namenode在那里写出配置的副本作为进一步的备份。
我们的namenode确实出现过一次硬件故障（磁盘），并且能够成功地从辅助服务器恢复它。