cdh裸机部署最佳推荐

官方文档：https://docs.cloudera.com/documentation/other/reference-architecture/topics/ra_bare_metal_deployment.html

服务器角色配置

• Master Node：运行 Hadoop 主守护进程：NameNode、备用 NameNode、YARN 资源管理器和历史服务器、HBase 主守护进程、Sentry 服务器以及 Impala StateStore 服务器和目录服务器。主节点也是 Zookeeper 和 JournalNodes 的安装位置。守护进程通常可以共享单个服务器池。根据集群大小，每个角色都可以在专用服务器上运行。Kudu 主服务器也应该部署在主节点上。

• Worker Node：运行 HDFS DataNode、YARN NodeManager、HBase RegionServer、Impala impalad、Search worker daemons 和 Kudu Tablet Servers。

• Utility Node：运行 Cloudera Manager 和 Cloudera Management Services。它还可以托管 MySQL（或其他受支持的）数据库实例，供 Cloudera Manager、Hive、Sentry 和其他 Hadoop 相关项目使用。

• Edge Node：包含所有面向客户端的配置和服务，包括 HDFS、YARN、Impala、Hive 和 HBase 的网关配置。边缘节点也是 Hue、Oozie、HiveServer2 和 Impala HAProxy 的好地方。HiveServer2 和 Impala HAProxy 充当外部应用程序（如商业智能 (BI) 工具）的网关。

• 有关详细信息，请参阅推荐的群集主机和角色分配。

• 
  

部署拓扑

下图描述了一个部署在多个机架(机架1，机架2，…机架n)上的集群。

每个主机与两个机架顶(TOR)交换机相连，这些交换机依次与一组脊柱交换机相连，脊柱交换机随后连接到企业网络。这种部署模型允许每个主机最大吞吐量和最小延迟，同时鼓励可伸缩性。后续部分将描述网络拓扑的细节。

物理组件列表

组件	备注	说明	数量
物理服务器	双插槽，8-14核每个插槽> 2 GHz;最低128gb内存。	容纳各种集群组件的主机。	基于集群的设计。
网卡	首选 10 Gbps 以太网 NIC	为集群提供数据网络服务。	每 台服务器至少有一个，尽管可以绑定两个 NIC 以获得额外的吞吐量。
内置硬盘	操作系统和日志推荐 500 GB HDD 或 SSD；数据盘用HDD（大小随数据量需求变化）	这些确保服务器重置时服务的连续性并包含集群数据。	每个物理服务器 6-24 个磁盘。
以太网 ToR/叶交换机	最少 10 Gbps 的交换机，具有足够的端口密度来容纳集群。这些需要足够的端口来创建一个真实的脊叶拓扑，提供高于 1:4 的超额订阅比（最好是 1:1）的 ISL 带宽。	尽管大多数企业都有成熟的数据网络实践，但可以考虑为 Hadoop 集群构建专用的数据网络。	每个机架至少两个。
以太网骨干交换机	最低 10 Gbps 交换机具有足够的端口密度以容纳传入的 ISL 链路并确保所需的主干吞吐量（用于机架间流量）。	与 ToR 交换机相同的注意事项。	取决于机架的数量。

网络

Hadoop 可以消耗所有可用的网络带宽。为此，Cloudera 建议将 Hadoop 放置在具有自己的核心交换机的单独物理网络中。

Hadoop 支持机架局部性的概念，并利用网络拓扑来最小化网络拥塞。理想情况下，一个机架中的节点应连接到单个物理交换机。两个架顶式 (TOR) 交换机可用于实现高可用性。每个机架交换机（即 TOR 交换机）上行连接到具有明显更大背板的核心交换机。Cloudera 建议在服务器和 TOR 交换机之间使用 10 GbE（或更快）连接。到核心交换机（HA 配置中的两个交换机）的 TOR 上行链路带宽通常会在一定程度上被超额订阅。

接入端口带宽（使用中）	上行端口带宽（绑定）	比率
48 x 1 GbE = 48 Gb/s	4 x 10 GbE = 40 Gb/s	1.2:1
24 x 10 GbE = 240 Gb/s	2 x 40 Gig CFP = 80 Gbit/s	3:1
48 x 10 GbE = 480 Gb/s	4 x 40 Gig CFP = 160 Gbit/s	3:1

磁盘

对于Master节点，推荐如下布局：

• 用于操作系统和日志的 RAID 1（软件或硬件）中的 2 个磁盘（容量至少 500GB）
• RAID 10 中的 4 个磁盘（每个 >= 1TB）用于数据库数据（见注）
• RAID 1（软件或硬件）中的 2 个磁盘（容量至少 1 TB）用于 NameNode 元数据
• 1 x 磁盘 JBOD/RAID 0 用于 ZooKeeper (>= 1TB)（见注）
• ZooKeeper 磁盘必须是 HDD，而不是 SSD
• 1 x 磁盘 JBOD/RAID 0 用于 Quorum JournalNode (>= 1TB)

对于 Worker 节点，推荐如下布局：

• 用于操作系统和日志的 RAID 1（软件或硬件）中的 2 个磁盘（容量至少 500GB）
• 15-24 个 SATA 磁盘 JBOD 模式（如果使用无法执行 JBOD 直通的 RAID 控制器，则作为多个单驱动器 RAID 0 - 阵列）容量不超过 4 TB。如果 RAID Controller 有缓存，将其用于写缓存（最好有备用电池）；禁用读取缓存。如果可用，请遵循硬件供应商的最佳实践。
• 要获得更高的性能配置文件，请使用 10K RPM SATA 或更快的 SAS 驱动器；这些通常具有较低的容量，但可以通过添加更多数据节点来抵消容量方面的考虑。
• 支持 SAS 驱动器，但通常无法提供足够显着的性能或可靠性优势来证明额外成本的合理性。Hadoop 具有容错性，因此可以轻松容忍驱动器故障。为了实现良好的价格点，通常应使用 SATA 驱动器。

RAID 控制器应配置为禁用 RAID 0 阵列的任何优化设置。

每个驱动器的数据密度

今天的硬盘驱动器有多种尺寸。流行的驱动器大小为 1-4 TB，但更大的驱动器正变得越来越普遍。在选择驱动器大小时，需要考虑以下几点。

• 更低的每 TB 成本– 一般来说，驱动器越大，每 TB 的成本就越便宜，从而降低 TCO。
• 复制风暴——更大的驱动器意味着驱动器故障将产生更大的重新复制风暴，这可能需要更长的时间并使网络饱和，同时影响正在进行的工作负载。
• 集群性能——一般来说，驱动器大小对集群性能的影响很小。例外情况是驱动器具有不同的读/写速度以及利用此增益的用例。MapReduce 是为长顺序读取和写入而设计的，因此延迟时间通常不那么重要。HBase 可能会从更快的驱动器中受益，但这取决于多种因素，例如 HBase 访问模式和架构设计；这也意味着获取更多节点。Impala 和 Cloudera Search 工作负载也可能受益于更快的驱动器，但对于这些应用程序，理想的架构是在内存中维护尽可能多的数据。
  Cloudera 不支持每个数据节点超过 100 TB。您可以使用 12 x 8 TB 轴或 24 x 4 TB 轴。Cloudera 不支持大于 8 TB 的驱动器。

cpu

除了成本之外，购买更多更好的 CPU 没有负面影响，但是必须仔细评估额外 CPU 功率的投资回报率。以下是一些需要考虑的要点：

• 集群瓶颈——一般来说，CPU 资源（及其缺乏）不会成为 MapReduce 和 HBase 的瓶颈。瓶颈几乎总是驱动器和/或网络性能。当然也有例外，例如低效的 Hive 查询。其他计算框架（如 Impala、Spark 和 Cloudera Search）可能受 CPU 限制，具体取决于工作负载。
• 额外的核心/线程——在给定的 MapReduce 作业中，单个任务通常一次使用一个线程。如前所述，每个节点分配的插槽数量可能是节点中驱动器数量的函数。只要内核（线程）的数量和驱动器的数量没有巨大的差异，那么为额外的内核付费是没有意义的。此外，一个 MapReduce 任务将是典型作业的 I/O 绑定，因此任务使用的给定线程在等待 I/O 响应时将有大量空闲时间。
• 时钟速度——因为 Cloudera 集群通常从少量用例和相关工作负载开始，并随着时间的推移而增长，因此购买可用的最快 CPU 是有意义的。实际 CPU 使用率取决于用例和工作负载；例如，与 I/O 绑定 MapReduce 应用程序相比，计算密集型 Spark 作业将从更快的 CPU 中受益更多。
  为操作系统和其他非 Hadoop 用途分配两个 vCPU（尽管如果其他非 Hadoop 应用程序在集群节点上运行，例如第三方主动监控/警报工具，则此数量可能需要更高）。您运行的服务越多，需要的 vCPU 就越多；您将需要使用功能更强大的主机来满足这些需求。

对于工作节点，运行在 2.4-2.5 GHz 的中端 12-14 核 CPU 通常会提供良好的成本/性能权衡。对于主节点，具有稍快时钟速度（例如 2.6 GHz）的中档 8 核 CPU 就足够了。在可用的情况下，应启用同步多线程实现（例如英特尔的超线程）。CPU 和内存的 BIOS 设置应设置为最高性能模式或等效模式。

内存

更多的内存总是好的，建议在预算允许的情况下购买。Impala 和 Cloudera Search 等应用程序通常配置为使用大量堆，支持这两种服务的混合工作负载集群应该有足够的 RAM 来支持所有必需的服务。
为操作系统和其他非 Hadoop 用途分配至少 4 GB 内存（尽管如果在集群节点上运行其他非 Hadoop 应用程序，例如第三方主动监控/警报工具，则此数量可能需要更高）。您运行的服务越多，需要的内存就越多；您将需要使用功能更强大的主机来满足这些需求。

考虑到操作系统和非 Hadoop 进程，分配给所有 Hadoop 相关进程（包括 HBase 等进程）的总内存小于节点上的总内存对性能至关重要。过度订阅系统上的内存会导致 Linux 内核的内存不足进程杀手被调用并终止重要进程。将不必要的内存过度分配给 Hadoop 进程也可能对性能有害，因为这会导致 Java 垃圾收集长时间暂停。
为了获得最佳性能，应该致力于填充给定 CPU 上可用的所有内存通道。这可能意味着更多较小的 DIMM，但这意味着内存和 CPU 都以最佳性能运行。与您的硬件供应商协商以定义最佳内存配置布局。

虽然可以容纳 128 GB RAM，但这通常会限制分配给 YARN 和 Impala 等服务的内存量，因此会降低集群的查询容量。通常建议使用 256 GB 的值，也可以使用更高的值

电源

Hadoop 软件是围绕节点会失败的预期而设计的。工作节点不需要冗余热插拔电源，但应用于主节点、公用事业节点和边缘节点。

内核和操作系统调优

文件系统

在Linux中有几种格式化和组织驱动器的选择。也就是说，只有少数几种选择是Hadoop的最佳选择。
在RHEL/CentOS中，不应该将LVM (Logical Volume Manager)用于数据驱动器。它不是最优的，可能会导致将多个驱动器组合到一个逻辑磁盘中，这与Hadoop跨HDFS管理容错的方式完全相反。在操作系统驱动器上保持LVM是有益的。对系统可管理性的改进可以抵消可能发生的任何性能影响。在操作系统驱动器上使用LVM可以使管理员避免
Cloudera推荐使用基于区段的文件系统。这包括ext3、ext4和xfs。大多数新的Hadoop集群默认使用ext4文件系统。Red Hat Enterprise Linux 7使用xfs作为默认文件系统。

创建用于Hadoop数据卷的ext4文件系统时，我们建议将root用户的超级用户块保留从5%减少到1%(使用-m1选项)，并设置以下选项:

• 每1 MB(大文件)使用一个inode
• 最小化超级块备份的数量(sparse_super)
• 启用日志记录(has_journal)
• 对目录树使用b-tree索引(dir_index)
• 使用基于区段的分配(extent)
  创建这样的ext4文件系统应该是这样的:
  mkfs -t ext4 -m 1 -O sparse_super,dir_index,extent,has_journal /dev/sdb1 .
  创建一个xfs文件系统可能看起来像

mkfs –t xfs /dev/sdb1

磁盘挂载选项
HDFS在设计上是一个容错文件系统。因此，DataNode机器用于数据的所有驱动器都需要在不使用RAID的情况下挂载。此外，驱动器应该使用noatime选项(这也意味着nodiratime)挂载在/etc/fstab中。如果是SSD或flash，也可以在安装时指定丢弃选项来开启TRIM。
在/etc/fstab中，确保适当的文件系统指定了noatime挂载选项:

/dev/sda1 / ext4 noatime 0 0

为了启用TRIM，编辑/etc/fstab并设置挂载选项discard。

/dev/sdb1 /data ext4 noatime,discard 0 0