0488-Cloudera Manager6.1的新功能

北京时间2018年12月19日,Cloudera正式发布Cloudera Enterprise 6.1.0,昨天Fayson的文章介绍了《0487-CDH6.1的新功能》,因为本次更新内容较多,特意将CDH和Cloudera Manager的更新分开两篇文章来介绍,本文Fayson主要介绍Cloudera Manager6.1的新功能。

1

Cloudera免费版节点数限制

Cloudera免费版现在不允许集群节点数超过100,具体如下描述:

1.单个Cloudera Manager管理的所有CDH6.x集群所包含的主机总数不允许超过100个,如果超过,增加主机会失败。

2.如果Cloudera Manager管理的集群主机数量超过100,Cloudera Manager不允许将集群升级到CDH6.x。如果你主机总数超过100,从Cloudera Manager6.0升级到6.1会失败,这时你需要移除一些主机使总数小于100,然后重新升级才能成功。

注意:如果你从Cloudera企业版降级为Cloudera免费版后,并且你的主机数量超过了100,这时Cloudera Manager会禁用集群管理的所有功能除了停止集群。如果主机总数超过100,你将无法重启集群或以其他方式使用集群,必须使用Cloudera Manager删除主机使主机总数小于100后才能恢复正常。

受影响的版本:Cloudera Manager6.1或更高版本

2

Accumulo

Accumulo安装现在使用Hadoop Credential Provider来处理敏感属性。比如:实例密钥和跟踪用户密码。

3

Agents

如果agent的心跳是一个无效的CM_GUID,Cloudera Manager管理控制台现在会有提示消息。

4

API endpoints for Roles

新的API文档中基于Swagger的API客户端,可以从RolesResource而不是ServicesResource访问角色。这不会更改角色的endpoint,也不会影响使用curl等工具直接访问Cloudera Manager API endpoint。

5

Audit Events

当从Cloudera Manager管理控制台或任何其他客户端调用API时,Cloudera Manager会在Audits数据库表中记录事件。当调用API的频率较高时,Audits数据库表会增长很快,这会直接导致Cloudera Manager的性能下降。

Cloudera Manager现在可以在一个配置的时间段内将发生的类似审计事件合并到一个唯一的审计条目中,然后保存到Audits数据库中。这样可以防止Audits表被快速写入。可以通过在cloudera-scm-server.properties中设置CMF_JAVA_OPTS的参数来配置此功能:

1.com.cloudera.cmf.persist.cmAuditTrackerConfig.timeToLiveMs : 类似审计条目合并为一个的时间间隔,默认为10000毫秒,如果设置为0,则是表示禁用该功能。

2.com.cloudera.cmf.persist.cmEventCoalescer.maxTrackedEvents: 可以在某个时间段内合并的最大事件数。默认值为1024。如果达到此限制,则删除最早的事件。

6

Auto-TLS

6.1

Certificate Handling

certmanager现在可以使用--skip-invalid-ca-certs选项自动跳过无效证书并导入bundle的其余部分。以前,如果bundle中的一个或多个证书无效,则整个设置操作失败。

6.1.1

Randomization of Sequential Certificate Authority Serial Numbers

以前,Auto-TLS生成的证书始终以序号0开始。现在,证书将从随机序号开始。Auto-TLS新部署才会受到影响,已有的Auto-TLS部署将不受影响。

6.2

Supported Services

Auto-TLS现在支持以下服务:Flume,Java Keystore KMS,KeyTrustee服务器,KeyTrustee KMS,Thales HSM KMS和Luna HSM KMS。 在启用Auto-TLS后,添加这些服务时,将自动添加TLS配置。

7

Backup and Disaster Recovery (BDR)

7.1

非安全集群到安全集群的数据复制

你现在可以使用BDR将数据从非Kerberos集群复制到Kerberos集群,但反过来则不支持,即BDR不支持从Kerberos集群复制数据到非Kerberos集群。

要执行复制,目标群集必须是ClouderaManager6.1.0或更高。源集群必须是ClouderaManager5.14.0或更高。

参考:

https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/cm_bdr_hive_replication.html#insecure_to_secure_replication
https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/cm_bdr_hdfs_replication.html#insecure_to_secure

7.2

Invalidate Metadata

BDR增强了Invalidate Metadata功能,以便在复制后按照每个Impala服务发出命令。如果集群有多个Impala服务,这样可以确保只有目标Impala的元数据会被刷新,从而提高性能。

7.3

Kudu

BDR现在在复制时会忽略数据保存在Kudu上的Hive表,这个修改不会对BDR现有的功能造成任何影响因为BDR本身就不支持复制Kudu表。这样修改是为了防止Hive Mestastore,Imapla和Kudu在交互时造成数据丢失。

7.4

Log Retention

以前,Cloudera Manager会永久保留BDR复制作业的日志。现在,Cloudera Manager默认保留BDR日志90天。你现在可以在CM中配置Backup and Disaster Log Retention参数来设置保留BDR日志的天数,或者完全禁用该功能。

7.5

使用HDFS快照差异报告更快地进行增量复制

此功能比较两个HDFS快照,它会比较两个快照从而获得需要复制的文件,进而减少扫描的文件数。如果有大量文件不需要合并,这可以显著提升复制性能。

该功能依赖于HDFS的immutable snapshot功能。以前的CDH版本中也包含此功能,现在在6.1中默认开启该功能。在创建或编辑复制计划时,你也可以配置将复制作业配置为在快照diff失败时中止。如果在目标群集上新增,修改或删除了需要被复制的文件(通常不受BDR支持),则会发生这种情况。但是如果这样,BDR也可以回退到详细比较文件的阶段,你也可以通过其他的配置来避免这种情况,比如“delete policy”。参考:

https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/cm_bdr_hive_replication.html#bdr_snapshotdiff_hive
https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/cm_bdr_hdfs_replication.html#bdr_snapshotdiff_hdfs

8

PostgreSQL 10 Support

Cloudera Manger以及Cloudera Management Service现在支持使用PostgreSQL10作为数据库。

9

诊断包

诊断包从以下2个方面进行了改进:

1.主机的dmesg命令的输出结果,诊断包在搜集时会包含格式化后的时间戳,如果主机操作系统支持的话。

2.不管网口名字是什么,诊断包现在会搜集每个主机上所有的网口信息。

10

HBase从CDH5升级到CDH6时检查hbase prefix_tree_encoding

OPSAPS-44701:当从CDH5升级到CDH6时,增加了一个对HBase表是否使用PREFIX_TREE_ENCODING的检查,并警告用户。

11

HDFS

你现在可以对NFS Gateway在HDFS配置中配置nfs.export.point

12

Hive

12.1

Size of Hive query locks in ZooKeeper

在对表进行锁定时,Hive会为每个这类锁创建一个Zookeeper对象,这个对象包含完整的查询字符串。这个查询字符串仅当你使用SHOW LOCKS EXTENDED命令时会显示锁。它对实际锁定过程没有任何影响。

但是,这通常会给ZooKeeper实例带来巨大的内存压力。例如,对于大小为1MB的查询字符串,如果在表的10000个分区上获取锁,则在ZooKeeper上需要10GB的内存。为了缓解这种压力,默认情况下,通过hive.locks.query.string.max.length属性,存储在ZooKeper的锁对象中的最大查询长度限制为10000个字符。 重申一下,除了在SHOW LOCKS EXTENDED命令的输出中显示如何查询之外,这不会影响任何其他事情。此配置值可以增加到最大值100万,这是znode(1 MB)的数据限制。

12.2

Hive Metastore Connection Retries

HiveServer2中增加了一个新的配置参数hive.metastore.connect.retries,比默认值会大一些。

13

Hue

对于RedHat7和与其兼容的其他OS,如果Hue使用Postgres数据库(包括使用默认的CM内置Postgres),CM会自动安装相应版本的psycopg2

14

Hue logs

CM现在可以解析httpd日志文件,包括Hue使用的文件,意味着诊断包和日志搜索都会包含这些日志文件,同时你也可以在CM界面上进行查看。

15

Impala

1.新增Impala空闲查询超时和空闲会话超时配置,配置参数名为:idle_query_timeout和idle_session_timeout

2.新增配置ImpalaD的JVM大小,CM中现在你可以为Impala Daemon配置Java的heap大小,参数名为:Java Heap Size of Impala Daemon in Bytes,默认为4GB。

3.OPSAPS-47832:在Cloudera Manager的Impala Daemon的Status页面,会显示Impala Daemon的JVM使用情况。

4.Impala指标:Impala暴露了一些跟JVM和GC相关的一些指标。在Cloudera Manager的Impala Daemon的角色状态页面,可以查看Impala Daemon内嵌JVM的GC指标。

5.新增2个Impala的健康检查:

  • JVM暂停时间
  • 客户端连接Impala Daemon的最大并发数,通过配置参数Impala Daemon Max Client Connections以实现该健康检查

6.Impala图表库:更新了Impala的预定义图表,删除了一些很少用到的图表,并更新引入了更多有意义的一些指标。

7.Impala资源池,IMPALA-7349:Impala资源池功能对每个池新增了最小/最大内存限制。

16

Intel's MKL Repository

Cloudera Manager6.1现在默认包含 Intel Math Kernel Library (MKL) 的parcel仓库地址。这个parcel可以加速机器学习工作负载。默认情况下,parcel不会在集群中自动下载和激活。参考:

https://software.intel.com/en-us/articles/installing-intel-mkl-cloudera-cdh-parcel

17

Kafka

17.1

Kafka Data Retention参数

Cloudera Manager移除了Kafka Broker的参数Data Retention Hours (data.retention.hours),替代请使用Data Retention Time (data.retention.ms) 参数。

17.2

Kafka Broker网络线程参数

Kafka broker配置参数新增num.network.threads,默认值是基于上游版本。

17.3

默认Kafka Broker性能参数

从CDH6.1开始,num.replica.fetchers和num.network.threads的默认值调整为4和8,对于生产系统来说,这是Cloudera的推荐值。

17.4

Kafka指标

Broker Topic新增如下指标:

kafka_fetch_message_conversions_per_sec

kafka_produce_message_conversions_per_sec

kafka_replication_bytes_in_per_sec

kafka_replication_bytes_out_per_sec

kafka_total_fetch_requests_per_sec

kafka_total_produce_requests_per_sec

Controller新增以下指标:

kafka_auto_leader_balance_rate_and_time_ms

kafka_controlled_shutdown_rate_and_time_ms

kafka_controller_change_rate_and_time_ms

kafka_isr_change_rate_and_time_ms

kafka_leader_and_isr_response_received_rate_and_time_ms

kafka_log_dir_change_rate_and_time_ms

kafka_manual_leader_balance_rate_and_time_ms

kafka_partition_reassignment_rate_and_time_ms

kafka_topic_change_rate_and_time_ms

kafka_topic_deletion_rate_and_time_ms

kafka_controller_state

kafka_global_partition_count

kafka_global_topic_count

ReplicaManager新增如下指标:

kafka_failed_isr_updates

kafka_offline_replica_count

kafka_under_min_isr_partition_count

LogCleaner新增如下指标:

kafka_logcleaner_cleaner_recopy_percent

kafka_logcleaner_max_buffer_utilization_percent

kafka_logcleaner_max_clean_time_secs

kafka_logcleaner_max_dirty_percent

kafka_logcleaner_time_since_last_run_ms

kafka_logcleaner_offline_log_directory_count

17.5

关闭和恢复Kafka

Kafka服务正常停止超时已增加到120秒,新增配置参数:num.recovery.threads.per.data.dir。

17.6

JBOD相关的指标

添加了新的指标来显示Kafka的离线日志目录和离线分区。

18

改进Kerberos凭据的Redaction

增强Import KDC Account Manager Credentials命令,如果命令失败,则当前配置的redaction policy会被应用于命令的错误输出。用户名和密码始终从输出中进行编辑。

19

云存储的读写指标

OPSAPS-44748:MapReduce jobs在读写S3和Azure Data Lake storage中的数据时,读写的数据量现在有指标进行查看,比如:s3a_bytes_read和adl_bytes_written

20

Network Performance Inspector

Network Performance Inspector允许你检查主机之间的延迟。你可以使用此工具来诊断可能显著影响工作负载性能的延迟问题,比如MapReduce作业,Spark作业以及Hive和Impala查询,尤其是在使用远程存储时。

inspector会从每个主机向所有其他主机运行ping命令,然后报告平均ping时间和丢包百分比。你可以使用此信息来识别有问题的主机或网络基础架构问题,从而采取修复方法。你可以按需使用inspector,添加新集群的时候也可以使用它。同时使用Cloudera Manager API也可以调用。

参考:

https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/cm_network_perf_inspector.html#cm_network_perf_inspector

21

OpenJDK

Cloudera Manager6.1和CDH6.1或更高版本支持和OpenJDK,参考:

https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_java_requirements.html#java_requirements
https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/ug_jdk8.html#concept_yky_c3z_4fb

22

Sentry

1.为Sentry增加了新的配置,可以开启Sentry的OWNER权限,默认是关闭的。

2.为Sentry增加了新的配置,默认ALL_WITH_GRANT增加到OWNER权限。

23

YARN的公平调度配置

Cloudera Manager中现在可以看到两个已有的YARN的配置参数。添加了Fair Scheduler Assign Multiple Tasks,只要Fair Scheduler Assign Multiple Tasks设置为true,ResourceManager就可以在节点心跳期间分配节点上最多一半的可用资源,默认为true。同时还添加了 Fair Scheduler Max Assign配置,该配置设置ResourceManager为每个节点心跳分配的容器数,默认值是-1代表没有限制。这个修改对YARN没有影响,现在只是在Cloudera Manager中进行显示,默认值保持不变。

24

System User Group Membership

若果大量Linux系统用户(yarn,hdfs,hue,sentry等)不在相同名字的group里,主机检查会显示告警,如果启用Kerberos认证后,这是必须的。参考:

https://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_cm_users_principals.html

25

TLS

你现在可以使用ssl.server.exclude.cipher.list属性为Hadoop设置TLS cipher suites

26

Zookeeper

ZooKeeper中的Enable Kerberos AuthenticationEnable Server to Server SASL Authentication两个配置现在绑在了一起,即任一参数更改为打开或关闭,则另一个参数将自动更改为相同的值,关于这个CM也新增了警告。

本文原文参考:

https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_cm_610_new_features.html#concept_wpv_rn4_bgb

本文分享自微信公众号 - Hadoop实操(gh_c4c535955d0f)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-12-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏码神联盟

微服务 | 资深架构师解读如何使用微服务架构

备注:本文7000多字,可先收藏在阅读,精心总结,切勿盗权,认真读后,定会受益匪浅

36240
来自专栏程序猿DD

Spring Cloud Stream消费失败后的处理策略(一):自动重试

今天第一节,介绍一下Spring Cloud Stream中默认就已经配置了的一个异常解决方案:重试!

24620
来自专栏程序猿DD

Spring Cloud Stream消费失败后的处理策略(四):重新入队(RabbitMQ)

之前我们已经通过《Spring Cloud Stream消费失败后的处理策略(一):自动重试》一文介绍了Spring Cloud Stream默认的消息重试功能...

18730
来自专栏吴伟祥

Spring Cloud 入门教程1、服务注册与发现(Eureka)

Eureka是Netflix开源的服务注册与发现框架,Eureka由两个组件组成:Eureka服务器和Eureka客户端。

12720
来自专栏Java架构师进阶

只需五分钟-用Maven快速搭建Spring Cloud微服务

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring,MyBatis,Netty源码分析的朋友可以加我的Java高级交流:854630135...

15820
来自专栏ios 技术积累

Spring Boot 自动配置

○@SpringBootConfiguration:标记当前类为配置类 ○@EnableAutoConfiguration:开启自动配置 ○@Compone...

16830
来自专栏happyJared

Spring Data JPA 的时间注解:@CreatedDate 和 @LastModifiedDate

选择 Spring Data JPA 框架开发时,常用在实体和字段上的注解有@Entity、@Id、@Column等。在表设计规范中,通常建议保留的有两个字段,...

1.6K30
来自专栏程序猿DD

Spring Cloud Stream消费失败后的处理策略(三):使用DLQ队列(RabbitMQ)

前两天我们已经介绍了两种Spring Cloud Stream对消息失败的处理策略:

27030
来自专栏吴伟祥

Spring Cloud 入门教程:聊聊Spring Cloud

Spring Cloud 是将分布式系统中一系列基础框架/工具进行整合的框架。其中包含:服务注册与发现、服务网关、熔断器、配置中心、消息中心、服务链路追踪等等。

10720
来自专栏Java架构师进阶

Spring Cloud 分布式链路跟踪 Sleuth + Zipkin + Elasticsearch

随着业务越来越复杂,系统也随之进行各种拆分,特别是随着微服务架构的兴起,看似一个简单的应用,后台可能很多服务在支撑;一个请求可能需要多个服务的调用;当请求迟缓或...

22120

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励