CDH CM版本 6.0.1 升級到 CM 6.2.0 當前最新版本（CentOS 7.x）

CDH 的 6.0.1 是一個尷尬的版本，那時候 cloudera 還沒有將 spark 更新到 2.4 還使用的是 spark 2.2版本。 但后來我們發現 2.3 | 2.4 更新了非常多的 feature 和修復了一些 bug 以及更新了很多包括 structed streaming 特性。並且最近最新的 6.2.0 將會在不久之后提供 Apache phoenix 的支持。所以我嘗試將目前的 CDH 升級一下並且記錄下來。

 

CM 升級：

1. 准備工作：

在進行 CDH minor 版本升級之前需先對 CM 進行升級，CM 對之前的版本向下兼容，比如 6.0.1 不能管理 6.0.1 之上的版本卻能管理小於版本號 6.0.1 以下的版本。

follow 官方文檔首先我們通過 reference 的第一個鏈接進入到對 cm 升級准備頁面。

然后通過相關命令查看目前主機以及 CM CDH 系統的情況，並將信息填入上面的 prepare my environment 中。下面的升級步驟都會 follow 這里選擇的東西不要填錯或者亂填

查看 Operating System 

lsb_release -a

查看目前 CM 使用的 metastore 情況

cat /etc/cloudera-scm-server/db.properties

 

新版本 JDK 支持情況

Cloudera Enterprise Version    Supported JDK
5.3 -5.15    Oracle JDK 1.7, Oracle JDK 1.8
5.16 and higher 5.x releases    Oracle JDK 1.7, Oracle JDK 1.8, OpenJDK 1.8
6.0    Oracle JDK 1.8
6.1    Oracle JDK 1.8, OpenJDK 1.8
6.2    Oracle JDK 1.8, OpenJDK 1.8

可以看到我們使用的 6.2 版本依然支持 Oracle JDK1.8 所以這一部分我們無需升級。從 6.1 開始 CM 開始支持 OpenJDK 1.8 ，這在之前是不支持的，而且會引發很多 agent 上面的問題。

如果非 Oraclejdk1.8 的同學可能需要對此進行非常多的處理，下面的內容均跳過了重新安裝 jdk 的步驟，如果需要參考更全面的信息請參閱官方文檔。

 

下面就是做一些備份數據的工作，通常意義上來說，如果我們進行 major 版本的升級，這一步的工序應該非常多非常復雜，但是進行 minor 或者 maintaince 級別的升級相對來說改動較少會稍微輕松一點，需要注意的地方沒有那么多。但是該做的備份我們還是給做上，確保可回滾。

 

2. 備份相關監控和 scm 數據庫組件：

備份 CMA(Cloudera Manager Agent)

創建一個方便使用的環境變量，並且創建備份日期的文件夾一枚

export CM_BACKUP_DIR="`date +%F`-CM6.0.1"
echo $CM_BACKUP_DIR
mkdir -p $CM_BACKUP_DIR

備份跟 CMA 相關的目錄信息

sudo -E tar -cf $CM_BACKUP_DIR/cloudera-scm-agent.tar --exclude=*.sock /etc/cloudera-scm-agent /etc/default/cloudera-scm-agent /var/run/cloudera-scm-agent /var/lib/cloudera-scm-agent

備份安裝倉庫信息

sudo -E tar -cf $CM_BACKUP_DIR/repository.tar /etc/yum.repos.d

 

先去 admin 界面將 scm action 停止。正常停止所有服務。

然后對 scm 以及 scm agent 進行停機

sudo systemctl stop cloudera-scm-server
sudo systemctl stop cloudera-scm-agent

 

備份 CMS(Cloudera Management Service) 信息

備份 Service monitor 信息

sudo cp -rp /var/lib/cloudera-service-monitor /var/lib/cloudera-service-monitor-`date +%F`-CM6.0.1

備份 Host monitor 信息

sudo cp -rp /var/lib/cloudera-host-monitor /var/lib/cloudera-host-monitor-`date +%F`-CM6.0.1

備份 Event Server 信息

sudo cp -rp /var/lib/cloudera-scm-eventserver /var/lib/cloudera-scm-eventserver-`date +%F`-CM6.0.1

備份 cms 信息

sudo -E tar -cf $CM_BACKUP_DIR/cloudera-scm-server.tar /etc/cloudera-scm-server /etc/default/cloudera-scm-server

備份 scm 數據庫信息

mysqldump --databases database_name --host=database_hostname --port=database_port -u user_name -p > $HOME/database_name-backup-`date +%F`-CM6.0.1.sql

 

3. 開始升級過程：

注意所有的升級過程期間最好保證 cm 是正常退出的情況包括 scm 和 cm-agent 是停止的情況。並且要保障期間不會有任何快照之類的 job 還在執行，否則可能導致升級之后 cm 起不來。

刪除之前所有的 repo 設置

sudo rm /etc/yum.repos.d/cloudera*manager.repo*

添加我們的 6.2.0 的倉庫配置

[cloudera-manager]
# Packages for Cloudera Manager
name=Cloudera Manager
baseurl=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/
gpgkey=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/RPM-GPG-KEY-cloudera
gpgcheck=1

安裝 jdk 的步驟我們跳過，因為我們已經是 Oracle1.8 的 jdk 了。

更新 scm

sudo yum clean all
sudo yum upgrade cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent 

然后就是等待，因為如果是國內服務器，訪問 cloudera 的服務可能速度比較慢，如果網速不行這里要等蠻久的 demons 有 1.1GB

建議速度不行可以用 proxychain 提前代理上再進行升級。升級完成后可以看到

[root@ryze-1 yum.repos.d]# rpm -qa 'cloudera-manager-*'
cloudera-manager-daemons-6.2.0-968826.el7.x86_64
cloudera-manager-server-6.2.0-968826.el7.x86_64
cloudera-manager-agent-6.2.0-968826.el7.x86_64

 

完成升級啟動我們的 agent 服務和 scm 服務

來到此界面，如果沒能來到此界面可以參考日志進行一些排錯

tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log
tail -f /var/log/cloudera-scm-agent/cloudera-scm-agent.log
tail -f /var/log/messages

 

4. 幫助其他機器升級 agent：

官方提供了兩種方法進行安裝。

1. 第一種是在上面展示的界面下面可以直接點一下，然后像之前安裝包一樣對其他機器進行一鍵安裝。建議使用這個很方便，但是如果你網絡不行就只能使用下面的方法2了。

2. 方法二就是按照上面的步驟手動對每一台機器的 agent 版本進行更新，我拿升級一台來做介紹，如果是相同的部署可以寫腳本就行批量部署。

登陸目標機器

刪除之前的 repo 

sudo rm /etc/yum.repos.d/cloudera*manager.repo*

在目錄 /etc/yum.repos.d 創建升級文件需要的 /etc/yum.repos.d/cloudera-manager.repo 信息

[cloudera-manager]
# Packages for Cloudera Manager
name=Cloudera Manager
baseurl=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/
gpgkey=https://archive.cloudera.com/cm6/6.2.0/redhat7/yum/RPM-GPG-KEY-cloudera
gpgcheck=1

停止機器上的 agent

sudo systemctl stop cloudera-scm-agent

更新 agent packages

sudo yum clean all
sudo yum repolist
sudo yum upgrade cloudera-manager-daemons cloudera-manager-agent 

安裝完成

rpm -qa 'cloudera-manager-*'
cloudera-manager-agent-6.2.0-..cm...
cloudera-manager-daemons-6.2.0-..cm...

重新啟動 agent 向 cm 上報信息

sudo systemctl start cloudera-scm-agent

 

不管采用那種辦法，當 agent 全部升級完畢后，使用 Host Inspector 檢測所有上報機器情況。

注意在安裝包的過程可能出現某些主機失敗，放心 cm 會對安裝失敗的軟件包進行回滾，我們可以等到所有都安裝停下來之后刷新頁面重試失敗的即可。注意觀察相關的日志，看是否錯誤是因為一些包沖突引起的，那些錯誤需要手動排除一下。

 

升級完成之后

進入 HOME PAGE 應該會看到很多配置上的修改，應該都是新版本 CM 對 DP 上的一些優化，重新部署相關客戶端即可。

在完成了 CM 升級之后，未來幾天我將會對 CDH 進行升級，到時候會再記錄一下，以上。

TroubleShooting:

升級完成之后其中有一台機器的 jn 不知道為何突然信息被清空了。

/dfs/jn/nameservice1/current 下面變成了空白一片，cm 也愉快的報警了這個問題。

重啟 jn 查看日志發現相關問題

 

2019-07-29 19:00:20,308 INFO org.apache.hadoop.ipc.Server: IPC Server handler 0 on 8485, call Call#16800 Retry#0 org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocol.heartbeat from 10.222.95.179:34624
java.io.FileNotFoundException: /dfs/jn/nameservice1/current/last-promised-epoch.tmp (No such file or directory)
        at java.io.FileOutputStream.open0(Native Method)
        at java.io.FileOutputStream.open(FileOutputStream.java:270)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
        at org.apache.hadoop.hdfs.util.AtomicFileOutputStream.<init>(AtomicFileOutputStream.java:58)
        at org.apache.hadoop.hdfs.util.PersistentLongFile.writeFile(PersistentLongFile.java:78)
        at org.apache.hadoop.hdfs.util.PersistentLongFile.set(PersistentLongFile.java:64)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.updateLastPromisedEpoch(Journal.java:347)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.checkRequest(Journal.java:462)
        at org.apache.hadoop.hdfs.qjournal.server.Journal.heartbeat(Journal.java:445)
        at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.heartbeat(JournalNodeRpcServer.java:167)
        at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.heartbeat(QJournalProtocolServerSideTranslatorPB.java:176)
        at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:27403)
        at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:523)
        at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:991)
        at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:869)
        at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:815)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1726)
        at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2675)
2019-07-29 19:00:21,231 ERROR org.apache.hadoop.hdfs.qjournal.server.JournalNode: RECEIVED SIGNAL 15: SIGTERM
2019-07-29 19:00:21,233 INFO org.apache.hadoop.hdfs.qjournal.server.JournalNode: SHUTDOWN_MSG

 

被清空之后無法找到相關文件報出了錯誤，我 google 了一下相關資料並且發現 namenode 往下下發頻率不高

1. action 關閉有問題的 jn 節點。

2. 拷貝正常節點上的日志到該 jn 上。

3. 重啟該 jn 讓 jn 跟上其他機器。

解決這個問題，但是感覺時有 3台 jn 的時候 掛一台不會對 namenode 產生影響，但是掛兩台就會，不知道直接移除該 jn 然后再將其加回來是否能不用通過拷貝的類似命令解決該問題。

 

 

Reference:

https://www.cloudera.com/documentation/enterprise/upgrade/topics/ug_cm_upgrade_before.html#cm_upgrade_before

https://www.cloudera.com/documentation/enterprise/upgrade/topics/ug_cdh_upgrade.html

https://cloud.tencent.com/developer/article/1077573  如何升級Cloudera Manager和CDH