CM和CDH升级操作手册
前言
因为cdh版本更新频率较快，各个小版本之间变化可能不是很大，但是Cloudera公司的每一次更新带来的都是bug的修复，技术的革新。相较于我们公司生产上还是cdh5.9.0有点掉队了，现在急需进行一场更新变革，跟上技术的脚步，适应行业的发展。对于此次升级，主要是cm及cdh的操作，采用的是Cloudera官方给出的Tarballs方式升级，包括Cloudera Manager Server和Cloudera Manager Agent 的升级，然后再利用cm来升级cdh。
详细步骤
收集升级信息
-
主机信息，确保能够通过root免密码登录
-
Cloudera Manager版本（通过cm主界面可查看）
版本信息.png
-
JDK版本
-
CDH版本（通过cm主界面可查看）
-
确保CDH之前部署的方式是Parcels还是Packages（通过cm主界面可查看）
-
CM service，Hue，Hive Metastore，Sentry Server的数据库信息。
升级前准备工作
- 阅读要升级版本的要求和系统需求：https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html(包括cm跟cdh的匹配规则；cm跟服务器版本的匹配规则；JDK的选择等等)
- 由于我们的集群未开启TLS/SSL功能，故可不关注这方面。
- 确保Java 1.7或Java 1.8版本
- 确保Cloudera Manager次要版本等于或大于CDH的次要版本
- 运行Host Inspector并且修复出现的问题(Cluster > Inspect Hosts)
- 运行Security Inspector并且修复出现的问题(Administration > Security ，然后点击Security Inspector)这个是集群若开启了kerberos认证时使用。
- 检查HDFS是否正常，修复检查出的问题（hdfs fsck / 和 hdfs dfsadmin -report 命令）
- 检查HBASE是否正常（hbase hbck命令）
- 通知业务，升级CM和整个CDH大数据平台需要花费较长的时间
- 为了避免在升级期间出现不必要的警告，可以在启动升级之前打开维护模式(当该群集处于维护模式中时，从该群集的服务和角色发出的警报将会被抑制)，升级完成后记得退出维护模式。
在NameNode上备份HDFS Metadata
- 在Active NameNode的服务上找到配置的数据目录，如果配置了多个目录，备份其中一个目录即可（每个目录都是完全拷贝的元数据）
[图片上传失败...(image-5389f0-1530292392783)]
需要注意的是：如果NameNode的数据目录下面还有以.lock扩展名的文件，那么说明NameNode还在运行，需要先停止NameNode服务。
备份数据库数据
注意：备份数据库之前，需要停止对应一些组件的服务，备份期间，服务不可用。
需要备份的数据库的组件有：
Hue
Oozie
Cloudera Navigator Audit Server
Cloudera Navigator Metadata Server
Activity Monitor
Reports Manager
Sentry Server
Hive Metastore
针对我们的生产环境，数据库采用的是MariaDB，所以备份方式可以采用：
测试环境的数据库有：
scm
hue
hive
sqoop
oozie
sentry
升级Cloudera Manager Server／Agent
- 配置需要升级的cm版本的yum源（前面讲到要安装适合本服务器对应的cm版本，此次测试集群是centos7.4的）
- 参照之前的Cloudera的yum源配置创建新版本的本地repo注意：一定要选择与自己服务器匹配的cm版本。 - yum clean all
- yum makecache
- 接着可查看是否已更新,验证：
-
验证可知，新版本的yum源已配置好，接下来就是更新升级啦。
-
web页面关闭Cloudera Management Service服务。（当然在升级cm的时候其实跟cdh是分开的，集群可关闭也可不关，建议关闭吧）
-
关闭cloudera-scm-server服务，备份相关数据（备份数据库的时候确保服务已关闭）
-
升级Cloudera相关组件：
更新cm安装包.png
-
检查安装是否成功：
cm安装成功.png
-
开启cloudera-scm-server服务： -
登录cm界面，选择升级现在升级Cloudera Manager Agent
cm界面.png
-
接下来就是升级agent的操作。（可能会比较耗时，因为要下载更新的软件包，最好是都配置成公司内部的yum安装包源地址）
- 选择是，我想立即升级Cloudera Manager Agent软件包，然后单击继续。
- 选择要安装的Cloudera Manager Agent的版本。 通常情况下，这是Cloudera Manager Server的匹配版本。 但是，如果您使用Cloudera Manager server的自定义repository( 而不是 archive.cloudera.com)，请选择Custom Repository并提供所需的信息。 自定义repository 位置必须包含匹配的Agent 版本。
- 点击继续。 显示“JDK安装选项”
如果前面已经安装这里跳过 - 点击继续
- 指定证书并启动代理程序安装
选择root或输入具有无密码sudo权限的帐户的用户名。
选择一种认证方法：
如果您选择密码认证，请输入并确认密码。
如果您选择公钥认证，请提供所需密钥文件的密码和路径。
您可以指定一个备用的SSH端口。 默认值是22。
您可以指定一次运行的主机安装的最大数量。 默认值是10。 - 点击继续。
Cloudera Manager Agent软件包和JDK（如果选择是）将被安装 - 点击继续。
- 主机检查器运行检查您的托管主机是否有正确的版本和配置。 如果发生问题，您可以进行更改，然后重新运行检查。
如果您对检查结果满意，请点击继续 - agent升级成功之后会进入数据库配置页面， 配置这些数据库设置： 1. 输入数据库的数据库主机，数据库类型，数据库名称，用户名和密码。
- 因为我们的生产集群agent的config.ini中server_host属性配置的是主机名，而自动升级之后，会把之前的配置文件备份重新生产一个server_host值是ip的文件，这个需要手动更改。
- 验证并测试升级
- 验证代理是否正在向Cloudera Manager发送检测信号：
a. 点击主机>所有主机。
b. 点击标题为Last Heartbeat的列标题对其进行排序。
c. 验证每个主机的最后一次检测信号是否在一分钟内发生。 - 在Cloudera Manager管理控制台中，单击主机选项卡
- 点击检查所有主机。 在大型集群上，主机检查员可能需要一些时间才能完成运行。在继续下一步之前，您必须等待过程完成。
- 点击 显示检查结果。 显示主机检查器进程的所有结果，包括当前安装的版本。如果这包括当前组件版本的列表，则安装按预期完成。
- 验证监视功能是否按预期工作; 请按照测试安装中的说明进行操作。
升级CDH
-
配置适合新版本的parcel包(配置好后，最好点击下载，因为待会升级也会要求下载分发并激活)
parcel入口.png
parcel配置入口.png
配置parcel.png
刷新parcel.png
-
点击升级群集（确保集群此时已关闭，各服务不能要数据库写数据。）
升级群集入口.png
cdh更新版本.png
升级cdh_1.png
-
它会提示你备份数据库的相关数据，当然也备份namenode的元数据。
-
等待cdh更新包的下载完成，然后分发激活。（比较花费时间，最好是先自己将parcel包下载好，再分发到各个服务器的/opt/cloudera/parcel-repo/目录下，或者将远程地址配置成公司内部可用的地址。）
-
parcel解压激活后，点击继续，检查主机（可跳过），然后重启集群。
-
选择“完整群集重启”后，点击“继续
-
如果升级过程遇到失败后，修复问题后，继续升级。
-
至此集群的整个升级过程都已完成，后面可通过查看hdfs文件看数据量的变化，也可向yarn提交任务验证此次升级操作的准确性。
总结
- 升级过程是一个严谨的操作，必须按照特定的顺序操作流程，且不容有差错。
- 整个过程中比较耗时的都是集群在下载cm的安装包和parcel的软件包的步骤，这个我们可通过提交配置好环境来规避这一点，另外在下载parcel包时可以提前在本地下载好放到特定的目录下面(/opt/cloudera/parcel-repo)，因为集群内部的分发速度是很快的。
- 升级之前最好要测试一下集群自身有问题没，包括集群的重启，namenode的ha的切换等等。
- 升级过程中遇到问题解决问题，不能瞎操作。
