0685-6.2.0-什么是Cloudera虚拟私有集群和SDX-续

本文是续上一篇文章《0667-6.2.0-什么是Cloudera虚拟私有集群和SDX》

虚拟私有群集的兼容性注意事项

5.1 CDH版本兼容性

Compute集群的CDH版本必须与Base集群的major.minor版本匹配。未来可能会添加对Compute和Base集群版本的其他组合的支持。VPC支持以下CDH版本：

CDH 5.15
CDH 5.16
CDH 6.0
CDH 6.1
CDH 6.2

5.2 CDH组件

1.Kafka - Compute集群不支持

2.SOLR - Compute集群不支持

3.Kudu - Compute集群不支持

Compute集群上的Impala不能访问Hive Metastore中的Kudu数据

4.HDFS

a)Compute集群需要“本地”HDFS服务作为临时的持久空间，目的是将其用于Hive查询临时数据，也建议用于多阶段Spark ETL作业。

b)Cloudera建议每个主机存储最小空间为1TB，配置为HDFS DataNode存储目录。

c)Base集群必须具备HDFS服务。

d)Base集群不支持Isilon。

e)只有Base集群才支持S3或ADLS连接器，Compute集群使用与其关联的Base集群的S3或ADLS证书。

f)Base集群上的HDFS服务必须配置HA高可用。

g)Cloudera强烈建议在Compute群集上为HDFS服务启用高可用性，但这不是必需的。

h)Base和Compute集群的namespace命名空间必须不相同。

i)Compute集群上本地HDFS服务的以下配置必须与Base群集上的配置匹配，为了使Compute集群上的服务能够正常访问Base集群上的服务：

i.Hadoop RPC protection

ii.Data Transfer protection

iii.Enable Data Transfer Encryption

iv.Kerberos Configurations

v.TLS/SSL Configuration(仅当集群没有启用 Auto-TLS时)

j)请勿使用“高级配置代码段”覆盖Compute集群中的namespace名称服务配置。

k)Compute集群home目录的HDFS路径使用以下格式：

代码语言：javascript复制

/mc/<cluster_id>/fs/user

您可以通过单击Cloudera Manager Admin Console中的集群名称找到<cluster_id>。浏览器显示的URL包含集群ID。例如，在下面的URL中，集群ID为1。

代码语言：javascript复制

http://myco-1.prod.com:7180/cmf/clusters/1/status

5.Backup and Disaster Recovery (BDR) - 如果源集群是Compute集群，或者目标集群的Cloudera Manager的版本低于6.2，都不支持。

6.YARN和MapReduce

如果Base集群既配置了MapReduce(MR1，在CM6中已弃用)和YARN(MR2)，因为Cloudera Manager中处理服务依赖的方式，Compute集群中的相关服务(如Hive Execution Service)将使用MR1。要使用YARN，您可以更新配置，以便在应用程序中使用YARN之前使这些Compute集群服务依赖于YARN（MR2）。

7.Impala

a)摄取新数据或元数据到Base集群会影响Hive Metastore，如果Compute集群中安装了Impala，需要在Compute集群中运行INVALIDATE METADATA或REFRESH METADATA。

b)Impala中的一致性由Catalog服务（catalogd）中的表级锁保证。对于多个Compute集群，通过多个集群中的多个catalogd访问相同的表或者数据会导致问题。例如，在删除文件时查询可能会失败，或者当在一个集群上运行刷新命令，但同时另一个集群正在摄取数据到Impala中如果只进行了一般，这时会导致元数据不正确。为避免一致性问题，Impala集群应在互斥的表和数据集上运行。

8.Hue

a)Compute集群上仅支持一个Hue服务实例。

b)Compute集群上的Hue服务不会与其他Compute集群上的Hue服务或Base集群上的Hue服务共享用户特定的查询历史记录。

c)由于创建表和插入数据的权限不同，Hue示例可能无法正确安装。您可以通过删除示例表然后重新添加它们来解决此问题。

d)如果在创建完Compute集群后才添加Hue服务，则需要在Compute集群中手动配置对其他服务（如Hive，Hive Execution Service和Impala）的依赖关系。

9.Hive Execution Service

新引入的“Hive execution service”仅支持Compute集群，Base或Regular集群不支持该服务。要使Hue能够在Compute集群上运行Hive查询，您必须在Compute集群上安装Hive Execution Service。

5.3 Compute集群服务

Compute集群上只能安装以下服务：

Hive Execution Service (此服务只提供给HiveService2角色)
Hue
Impala
Spark2
Oozie (装Hue服务必须该服务)
YARN
HDFS (必须)

5.4 Cloudera Navigator支持

Compute集群不支持Navigator的元数据，审计，数据溯源和KMS。

5.5 Cloudera Manager权限

被授权仅查看Base或Compute集群的集群管理员只能查看和管理这些集群，但无法创建，删除或管理数据上下文(Data Contexts)。只有使用Full Administrator这个角色的管理员才能创建和删除数据上下文。

5.6 安全

1.KMS

a)Base Cluster

i.不支持Hadoop KMS

ii.Base集群支持KeyTrustee KMS

b)Compute Cluster：不支持任何类型的KMS

2.认证/用户目录

a)Base集群和Compute集群上的用户应该是完全一致的，就像在同一个集群一样。包括Linux本地用户，LDAP，Active Directory或其他第三方用户目录集成，都应该一致。

3.Kerberos

a)如果Base集群安装了Kerberos，则Compute集群也必须使用Kerberos，而且必须和Base集群在相同的Kerberos域中。Cloudera Manager可以在集群的创建过程中帮助完成该配置。

4.TLS

a)如果Base集群为集群服务配置了TLS，则Compute集群服务也必须配置TLS才能访问Base集群中的相应服务。

b)Cloudera强烈建议启用Auto-TLS以确保Base和Compute集群上的服务统一使用TLS进行通信。

c)如果您已配置TLS但未使用Auto-TLS，请注意以下事项：

d)使用Cloudera Manager为Compute添加主机时，必须在这些主机中创建相同的配置。将位于以下配置属性指定的目录中的所有文件从Base集群复制到Compute集群主机：

i.hadoop.security.group.mapping.ldap.ssl.keystore

ii.ssl.server.keystore.location

iii.ssl.client.truststore.location

e)创建Compute集群时，Cloudera Manager会将以下配置复制到Compute群集。

i.hadoop.security.group.mapping.ldap.use.ssl

ii.hadoop.security.group.mapping.ldap.ssl.keystore

iii.hadoop.security.group.mapping.ldap.ssl.keystore.password

iv.hadoop.ssl.enabled

v.ssl.server.keystore.location

vi.ssl.server.keystore.password

vii.ssl.server.keystore.keypassword

viii.ssl.client.truststore.location

ix.ssl.client.truststore.password

5.7 Compute集群的主机存储需求

如果Compute集群中运行了Impala服务，则Compute集群的主机需要附加存储，容量至少1TB。此存储用于Impala的暂存空间(scratch space)，以及用于Compute集群本身的HDFS空间。

5.8 网络

在Compute集群上运行的工作负载将与Base集群上的主机进行大量通信; 客户应该对网络硬件（例如交换机，包括TOR，spine/leaf路由器等）进行网络监控，以跟踪和调整Compute集群机架与Base集群机架之间的带宽。

5.9 Altus Director

Altus Director不支持运行Compute集群，也不能用于创建Compute群集。

5.10 Cloudera Data Science Workbench (CDSW)

计算集群不支持CDSW。

虚拟私有集群的网络注意事项

6.1 最低网络性能要求

虚拟私有集群部署对网络性能有以下要求：

1.最坏情况下IO吞吐量为100MB/s，即任何计算节点和任何存储节点之间的网络吞吐（持续）为1Gb/s。为了达到最坏的情况，我们会测试当所有计算节点同时从存储节点读取/写入时的网络吞吐，这种并发执行也是典型的大数据应用程序。

2.最坏的情况是任何两个工作负载集群节点或任何两个Base集群节点之间的网络带宽为1Gbps。

下图总结了这些要求：

6.2 规划和设计网络拓扑

6.2.1 最低和推荐的性能要求

本章通过下表中列出的最小网络吞吐量，来了解最低要求。

注意：为了方便大家理解，后面的内容将使用以下术语：南北（NS）流量模式表示Compute层和Storage层之间的网络流量。东西（EW）流量模式表示Storage或Compute集群内的内部网络流量。

注意：后端Base集群上的存储跟Compute集群的节点连接数有关系，所以后端的存储不仅需要考虑容量，还包括吞吐量。由于后端的存储就是HDFS DataNode，因此需要对后端的存储节点进行合理规划，参考以下内容：

1.如果Base集群上的节点使用SATA磁盘，假设SATA磁盘在裸机上的吞吐为100MB/S，在使用DAS(Directly Attached Storage)的虚拟化集群中吞吐预计可以达到70-80MB/S。

2.每块磁盘需要一个物理的CPU核，因此，如果节点有12块磁盘，则这个节点至少应该有12个CPU核。

3.网络带宽应该规划为2倍的NS流量。例如，如果你的Base集群的一个节点有12块磁盘，则预期的NS流量应该是1200MB/S(1.2GB/S)，也就大概需要~10Gbps的网络吞吐。而因为需要2倍的NS流量，所以可以为该节点规划20Gbps的网络，主要为了解决可能同时存在的EW流量。

4.Compute层和Storage层之间的网络连接需要考虑NS方向的流量的吞吐。本文后面的内容会继续讨论网络设计的注意事项，并说了不同的网络过载对于集群总吞吐量的影响。

6.2.2 网络拓扑注意事项

首选的网络拓扑是叶脊(spine-leaf)拓扑网络，在leaf和spine交换机之间的过载率接近1:1，理想情况是没有过载。这样我们就可以确保存储和计算节点的任何组合之间的全线路速率(full line-rate)。因为SDX的架构是存储和计算分离，所以为了达到最佳性能网络设计非常重要。

所需的最小网络吞吐包含以下2个方面，这也将决定计算与存储节点的比例。

1.后端存储集群的网络吞吐和磁盘IO吞吐能力。

2.计算和存储层之间的网络吞吐量和网络过载率，即南北流量(NS)。

让我们来举一个例子更好的理解这一点，假设搭建安装是绿地(greenfield)模式，计算节点和存储节点都是使用的虚拟机(VM)：

1.因为EW和NS流量会共享总网络带宽，因此，对于1Gbps的NS流量，我们也应该规划1Gbps的EW流量。

2.计算和存储层之间的网络过载率为1:1。

3.后端存储集群包含5个节点（VM），每个节点有8块SATA盘。

a)对于后端存储集群，每个节点8块盘，假设每块盘的吞吐为100MB/S，则每节点总的磁盘IO吞吐为800MB/S，则一共5个节点的总IO吞吐在~4GB/S。集群的网络吞吐总和为~32Gbps，5*800MB/S=4GB/S，大B和小b用8换算，南北(NS)流量每节点需要7Gbps，32Gbps/5=~7Gbps。

b)考虑到EW NS，我们需要每个节点14Gbps网络带宽来处理每个节点800MB/s的IO吞吐量。

4.然后，计算群集最好具有以下条件：

a)5个虚机节点，每个具有7 Gbps NS 7 Gbps EW = 14Gbps的总网络吞吐。

b)这种情况可以处理~6个节点，最小吞吐量（100MB/s），前提是它的CPU和内存不是瓶颈，以便占满后端的流量(6 x 100 MB/s x 5 = 3000 MB/s)。每个节点应具有~2 Gbps的网络带宽，以满足NS EW流量。

c)如果每节点的吞吐使用我们建议的200MB/S，则只需要3个这样的节点（3 x 200 MB/s x 5 = 3000 MB / s）。每个节点应具有~4 Gbps的网络带宽，以满足NS EW流量。

假设计算节点和存储节点的比例为4:1，当然这个比例会因为实际情况有所不同，需要充分考虑各种工作负载才能做到更精确的节点数目规划。

以下表格按照假设计算节点和存储节点的比例为4:1，即50个节点的存储集群，200个阶段节点来举例说明：

Storage-Compute Node Level Sizing