CDH6官⽅⽂档中⽂系列（1）---适⽤于裸机部署的ClouderaEnterprise参考架构
适⽤于裸机部署的Cloudera Enterprise参考架构
最近在学习cdh6的官⽅⽂档，⽹上也⽐较难到中⽂的⽂档。
其实官⽅英⽂⽂档的阅读难度其实并不是很⾼，所以在这⾥在学习官⽅⽂档的过程中，把它翻译成中⽂，在翻译的过程中加深学习了解，并分享出来和⼤家⼀起学习。
中⽂内容是本⼈的渣渣英⽂⽔平结合有道词典，⾕歌翻译的结果，⽂中部分词语可能翻译的并不准确，希望⼤家多多提出意见，共同进步。
cdh6的官⽅中⽂⽂档系列长期更新，最后⽬标整理成gitbook，同⼤家交流学习。
最后，如果你觉得本⽂对你有⽤，希望点个赞给作者⼀点⿎励哈。
与其感慨路难⾏不如马上上路，诸位道友，共同学习，加油！-------天南第⼀剑修
⽂章⽬录
概要
⼀个组织对⼤数据解决⽅案的要求很简单：在同⼀个平台保证数据的有效原始性获取和组合任意数量或类型的数据，只要有必要，以最快的速度向所有⽤户提供技术⽀持。
Cloudera，⼀家企业数据管理公司，介绍了企业数据中⼼(EDH)的概念:⼀个存储和处理所有数据的中央系统。EDH具有灵活性，可以运⾏各种企业⼯作负载(例如，批处理、交互式SQL、企业搜索和⾼级分析)，同时满⾜企业需求，如与现有系统的集成、健壮的安全性、治理、数据保护和管理。EDH是新兴的企业数据管理中⼼。EDH构建于Cloudera Enterprise之上，后者由包括Apache Hadoop (CDH)在内的开源Cloudera发⾏版组成，后者是⼀套管理软件和企业级⽀持。
当组织接受hadoop⽀持的⼤数据部署时，它们也需要企业级的安全性、管理⼯具和技术⽀持——所有这些都是Cloudera企业版的⼀部分。
Cloudera参考架构⽂档举例说明了集配置和认证的合作伙伴产品。RAs并不是官⽅⽀持声明的替代品，相反，它们是辅助部署和分级选项的指南。有关RA中受⽀持的配置的语句是信息性的，应该与最新的⽂档进⾏交叉引⽤。
本⽂档是在物理机器部署Cloudera企业的⾼级设计和最佳实践指南。
基础设施
系统架构最佳实践
本节描述Cloudera的建议和适⽤于Hadoop集系统架构的最佳实践。
Java
Cloudera Manager和CDH被证明可以在Oracle JDK上运⾏。OpenJDK也⽀Cloudera Manager和CDH 5.16及更⾼版本5.x版本。有关更多信息，请参见。
Cloudera通过Cloudera管理器库发布了⼀个兼容的Oracle JDK版本。客户也可以免费安装由Oracle发布的兼容版本的Oracle JDK。
请参考。
每个主机与两个机架顶部(TOR)交换机联⽹，这些交换机依次连接到⼀个脊柱交换机集合，然后连接到企业⽹络。这种部署模型允许每个主机最⼤吞吐量和最⼩延迟，同时⿎励可伸缩性。⽹络拓扑的细节将在后续的设置中描述。
物理组件列表
下表描述了推荐部署EDH集的物理组件。
组件配置描述数量
Physical servers 双槽、8-14核每槽
⼤于2GHZ
最⼩128G内存
容纳各种集组件的主机。基于集设计
NICs10 Gbps以太⽹⽹卡优先。为集提供数据⽹络服务。每个服务器⾄少有⼀个，不过可以绑定两个NICs以获得额外
的吞吐量。
Internal HDDs 操作系统和⽇志推荐使⽤500gbHDD或SSD；数据磁盘使⽤
HDD(⼤⼩随数据量需求⽽变化)
这确保了服务器重置和包含集数据的
服务的连续性。
每个物理服务器有6-24个磁
盘。
Ethernet ToR/leaf switches 最少10 Gbps的交换机具有⾜够的端⼝密度来容纳集。这些需
要⾜够的端⼝来创建⼀个真实的spine-leaf拓扑，提供⼤于1:4的
ISL带宽(最好是1:1)。
尽管⼤多数企业都有成熟的数据⽹络实
践，但是考虑为Hadoop集构建专⽤
的数据⽹络。
每个机架⾄少两个。
Ethernet spine switches 最少10 Gbps的交换机具有⾜够的端⼝密度，以适应传⼊的ISL链
接，并确保通过脊柱所需的吞吐量(⽤于机架间通信)与ToR开关相同的注意事项。取决于机架的数量。
⽹络说明
专⽤⽹络硬件
Hadoop可以消耗所有可⽤的⽹络带宽。由于这个原因，Cloudera建议将Hadoop放置在⼀个单独的物理⽹络中，使⽤⾃⼰的核⼼交换机。
开关每个机架
Hadoop⽀持机架局部性的概念，并利⽤⽹络拓扑最⼩化⽹络拥塞。理想情况下，⼀个机架中的节点应该连接到单个物理开关。两个顶部机架(TOR)开关可⽤于⾼可⽤性。每个机架开关(即TOR开关)连接到
⼀个具有更⼤背板的核⼼开关。Cloudera建议在服务器和TOR交换机之间建⽴10 GbE(或更快)连接。TOR到核⼼交换机(在⼀个HA配置中有两个交换机)的上⾏带宽常常会在某种程度上被超额使⽤。
上⾏的过载
多⼤的过载是合适的取决于⼯作负载。Cloudera的建议是，总访问端⼝带宽和上⾏带宽之间的⽐例应尽可能接近1:1。这对于沉重的ETL⼯作负载和向reducers发送⼤量数据的MapReduce作业尤其重要。
对于平衡的⼯作负载来说，⾼达4:1的过载通常是可以接受的，但是需要⽹络监控来确保上⾏带宽不是Hadoop的瓶颈。下表提供了⼀些例⼦作为参考:
接⼊端⼝带宽(使⽤中)上⾏端⼝带宽(绑定)⽐率
48 x 1 GbE = 48 Gbit/s  4 x 10 GbE = 40 Gbit/s  1.2:1
24 x 10 GbE = 240 Gbit/s  2 x 40 Gig CFP = 80 Gbit/s3:1
48 x 10 GbE = 480 Gbit/s  4 x 40 Gig CFP = 160 Gbit/s3:1
重要的是:
超额认购⽐例不超过4:1。例如，如果TOR使⽤20 x 10 GbE端⼝，那么上⾏链路⾄少应该是50 Gbps。不同的交换机有特定带宽的专⽤上⾏端⼝(通常为40 Gbps或100 Gbps)，因此需要进⾏仔细的规划，以选择正确的开关类型。
冗余⽹络交换机
在完全⽹格配置中拥有冗余的核⼼交换机将允许集在核⼼交换机故障时继续运⾏。冗余的TOR开关将防⽌整个机架的处理和存储能⼒的损失，在TOR开关故障的情况下。在机架丢失的情况下，只要主节点分布在多个机架上，仍然可以维护⼀般的集可⽤性。
可访问性
Cloudera企业集的可访问性由⽹络配置定义，并取决于安全需求和⼯作负载。通常，有直接访问集的边缘/客户端节点。⽤户通过客户端应⽤程序访问这些边缘节点，与集和驻留在其中的数据进⾏交互。这些边缘节点可以运⾏⼀个web应⽤程序，⽤于实时处理⼯作负载、BI⼯具，或者只是⽤于提交或与HDFS交互的Hadoop命令⾏客户机。
Cloudera建议只允许通过边缘节点访问Cloudera企业集。可以在提供的主机的安全组中配置此配置。本⽂档的其余部分详细描述了各种选项。
互联⽹连接
不需要在Internet之间或直接⽹络之外的服务之间进⾏⼤量数据传输的集和HDFS仍然可能需要访问诸如⽤于更新的软件存储库或其他低容量外部数据源等服务。
如果完全断开集与Internet的连接，就会阻塞对软件更新的访问，从⽽增加维护的难度。
集管理
Cloudera强烈建议使⽤Cloudera Manager (CM)安装CDH。在通过CM安装CDH的过程中，可以选择使⽤包或本地包进⾏安装。包裹是⼆进制的分发格式。包裹提供了许多好处，包括⼀致性、灵活的安装位置、不需要sudo的安装、减少升级停机时间、滚动升级和容易降级。Cloudera建议使⽤包裹，但也⽀持使⽤包。
集Sizing最佳实践
(对于Sizing这个词，总是不到合适的翻译，希望道友可以提点建议)
每个⼯作节点通常有⼏个物理磁盘，⽤于Hadoop的原始存储。这个数字将⽤于计算每个集的可⽤存储总量。此外，下⾯列出的计算假定为YARN临时存储分配了10%的磁盘空间。Cloudera建议将10-25
%的原始磁盘空间分配给临时存储，这是⼀个通⽤的指导原则。这可以在Cloudera Manager中更改，并且应该在分析⽣产⼯作负载之后进⾏调整。例如，向reducers发送少量数据的MapReduce作业允许将这个数字百分⽐向下调整
下表包含包含17个⼯作节点的集的⽰例计算。每个服务器有12个3 TB的驱动器可供Hadoop使⽤。下表列出了基于⼯作节点数量的可⽤Hadoop存储:
mysql操作官方文档默认的复制因⼦
Raw Storage612 TB
HDFS存储(可配置)550.8 TB
HDFS唯⼀存储(默认复制因⼦)183.6 TB
MapReduce中间存储(可配置)61.2 TB
纠删码 RS-6-3
Raw Storage612 TB
HDFS存储(可配置)550.8 TB
HDFS唯⼀存储(EC RS-6-3 – 1.5x overhead)367.2 TB
MapReduce中间存储(可配置)61.2 TB
纠删码 RS-10-4
Raw Storage612 TB
HDFS存储(可配置)550.8 TB
Raw Storage612 TB
HDFS唯⼀存储(EC RS-10-4 – 1.4x overhead)393.4 TB
MapReduce中间存储(可配置)61.2 TB
注意:
HDFS惟⼀存储将根据存储在EC⽬录中的数据量和选择的RS策略⽽有所不同。上⾯的表只是不同策略如何影响HDFS惟⼀存储的⽰例。
压缩原始数据可以有效地增加HDFS的存储容量。
虽然Cloudera Manager提供了⼀些⼯具，⽐如利⽤Linux Cgroups的静态资源池，允许多个组件共享硬件，但是在⼤容量⽣产集中，为Solr、HBase和Kafka等⾓⾊分配专⽤主机是有益的。
集硬件选择最佳实践
本节将对不同的硬件组件选择将如何影响Hadoop集的性能进⾏概述。
有关具体⼯作负载的详细实践，请参阅。
磁盘的数量
传统上，Hadoop被认为是⼀个⼤型I/O平台。虽然有许多新的⼯作负载在Cloudera集上运⾏，它们可能不像传统的MapReduce应⽤程序那样受I/O限制，但在架构Cloudera集时考虑I/O性能仍然很有⽤。
与CPU的核⼼数量和RAM的密度不同，从⼀个机械磁盘(主轴)读取数据的速度在过去10年没有太⼤的变化。为了应对硬盘读写操作的有限性能，Hadoop并⾏地从多个硬盘进⾏读写操作。每个节点每增加⼀个额外的主轴，都会提⾼集的总体读/写速度。
注意:SSD已经极⼤地改变了持久存储性能的前景，但是每GB机械磁盘的价格仍然明显低于SSD存储。随着ssd成本的下降以及诸如Intel的Optane™之类的技术进⼊市场，⼯作负载可能会重新回到CPU限制的状态。⼤多数Cloudera客户仍在部署将数据存储在旋转硬盘上的集。
额外的主轴还可能带来集中更多的⽹络流量。在⼤多数情况下，节点之间的⽹络流量通常受到写⼊或从节点读取数据的速度的限制。因此，通常遵循的规律是，随着主轴数的增加，对⽹络速度的要求也随之提⾼。
⼀般来说，⼀个节点的主轴数越多，每TB的成本就越低。但是，⼀个节点上存储的数据量越⼤，如果该节点宕机，重新复制的时间就越长。Hadoop集被设计成具有多个节点。⼀般来说，拥有更多的平均节点⽐拥有更少的超级节点要好。这与数据保护以及增加MapReduce和Spark等分布式计算引擎的并⾏性有很⼤关系。
如果CDH集利写不利读，可以选择⼤磁盘少节点⽅案，充分发挥hdfs的存储优势。
如果CDH集⽤来分析使⽤，选择⼩磁盘多节点⽅案。⼤磁盘少节点的⽅案在磁盘发⽣故障时需要更多的数据恢复时间，不适于分析集使⽤
最后，每个节点的驱动器数量将影响为节点配置的YARN容器的数量。是⼀个复杂的主题，但对于I/O限制的应⽤程序，每个主机的物理驱动器数量可能是决定每个节点配置的容器槽数量的限制因素。
Kafka集通常在专⽤服务器上运⾏，这些服务器不运⾏HDFS数据节点或处理组件(如YARN和Impala)。因为Kafka是⼀个基于消息的系统，所以快速存储和⽹络I/O对性能⾄关重要。尽管Kafka确实将消息持久化到磁盘，但通常不需要将Kafka主题⽇志的全部内容⽆限期地存储在Kafka集上。Kafka代理应该为⽇志数据⽬录配置专⽤的旋转硬盘。使⽤ssd⽽不是旋转磁盘并没有显⽰出可以为Kafka提供显著的性能改进。
Kafka驱动器还应该配置为RAID 10，因为Kafka节点上的单个驱动器的丢失将导致节点中断。
磁盘布局
对于**主节点**，建议采⽤以下布局:

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。