2年目インフラエンジニアの茂木(@tkmoteki)です。CyberZエンジニアブログ初投稿です。
私が最近業務で行った、本番Hadoopクラスタ2つのメジャーアップグレード検証と実施について記載していきます。
Hadoopクラスタのメジャーアップグレードはかなりクリティカルでヘビーな業務でした。
検証から実施までは今年の9月下旬から10月下旬の1ヶ月間で行いました。
クリティカルな作業でもあり、検証や準備する項目が多く、なかなかタイトなスケジュールでした。
今回の記事では以下について記載します。
- 弊社のHadoop環境と構成
- アップグレード検証
- アップグレード実施
1. Hadoop環境と構成
運用に際しHadoop専任エンジニアを必要とせず、運用負荷を削減できる事から、
Cloudera社のCDH4とCloudera Manager4(以降CM4)を導入しております。
今回はCDH5とCloudera Manager5(以降CM5)へのメジャー アップグレードです。
今回アップグレードの対象になるHadoopクラスタは2つあり、1つがバッチ用途、もう1つがアドホック用途です。
Hadoopクラスタ自体は、オンプレミス環境の物理サーバ上で運用していて、合計数十台のノードが存在します。
構成について記載していきます。
1-1. システム構成
画像の左(Hadoopクラスタ1)がバッチ用途のクラスタで、右(Hadoopクラスタ2)がアドホック用途のクラスタです。 web+APサーバがログ(csv)をHadoopに送信し、Hadoopクラスタは各種システムと連携しています。 2つのクラスタ間では、dailyでdistcpによるリストコピーを行っています。
1-2. CM/CDHロール構成
Hadoopクラスタ1(バッチ用途のHadoopクラスタ)のロール構成ですが、ざっくり以下のようになっています。
マスタノードが3台、管理系が1台、スレーブノードが数十台です。
バッチ用途、アドホック用途のHadoopクラスタでロール構成が若干異なっています。
2つのクラスタで共通している構成を記載すると以下になります。
- ZK(ZooKeeper)は001～003で1リーダ、2フォロワ
- ANMとSNM(HDFS Name Node)は001～002でHA構成
- SJTとAJT(Map Reduce)は001～002でHA構成
- Hue/Hive/sqoopは003
- mgmtは004
- cloudera-scm-serverが003と004の構成
- meta store(DB)が003と004マルチmaster
- 他スレーブにDN(Data Node)/TT(Task Tracker)があり、ノードはたくさん
2つのクラスタで異なる点としては、アドホック用途のHadoopクラスタにImpalaロールがあります。
1-3. ハードウェア構成
ハードウェア物理構成は、ざっくり以下のようになっています。
- マスターノード CPU 12コア/memory 64GB, disk OS側:RAID1
- スレーブノード CPU 24コア/memory 64GB, disk OS側:RAID1 Data Node側:シングルRAID0
- マスターノード CPU 12コア/memory 64GB, disk OS側:RAID1
- スレーブノード CPU 24コア/memory 192GB, disk OS側:RAID1 Data Node側:シングルRAID0
2. アップグレード検証
今回のアップグレードはメンテを行い、クラスタを停止して行いました。
今回の検証した項目や準備した項目もそれに沿っています。
CDH4/CM4 → CDH5/CM5 upgradeを行った各versionは以下の通りです。
upgrade後のversionは、その時点での最新版です。
| 対象 | upgrade前 | upgrade後 |
|---|---|---|
| CDH | 4.4.0 | 5.4.4 |
| Cloudera Manager(CM) | 4.7.3 | 5.4.7 |
| 対象 | upgrade前 | upgrade後 |
|---|---|---|
| CDH | 4.4.0 | 5.4.4 |
| Cloudera Manager(CM) | 4.8.2 | 5.4.7 |
可能な限り、本番環境に近い構成/データ量で仮想の検証環境を用意し以下を行いました。 以下の項目について、記載します。
- 検証した項目
- 2-1. upgrade検証
- 2-2. 動作検証
- 2-3. 性能試験
- 2-4. 障害試験
- 2-5. 設定値の差分検証
- 2-6. ロールバック検証
- 準備した項目
- 2-7. 影響範囲の再精査と周知
- 2-8. upgrade検証からの手順作成
- 2-9. 当日のタイムスケジュールテーブル
- 2-10. upgrade失敗時のシナリオリスト
- 2-11. 他作業ツール類の用意
- 2-12. Clouderaサポートの活用
- 検証で苦労した事
(検証した項目) 2-1. upgrade検証
これは、CDH4/CM4 → CDH5/CM5に正常にupgrade出来るかの検証です。
2台構成のscm-server/scm-server-dbを順繰りにupgradeしていき、その後全ノードに対して、parcelsを展開してCDHのupgradeを行います。
基本的な手順詳細は、Clouderaの公式のドキュメントの通りです。
Upgrading to CDH 5.4 Using Parcels
このドキュメントを読み、自身の運用してるインフラ環境/クラスタ構成に合わせて、手順を追加&修正しました。
上記ドキュメントの以下注意点は精査しておきます。
- CDH/Cloudera Managerのリリースノートには目を通しておく
- Javaのversion
- upgradeのターゲットとなるCDHのversionとCloudera Managerのversionの対応関係
- Hiveの日付パーティションカラム等の検証
- HDFSを始めとして予約語の有無
- スケジューラやdistcpなど
また、CM/CDH以外に別入れバイナリがある場合は、それ相応の考慮が必要です。 弊社でも別入れバイナリで構築しているものがあります。
上記はサーバ側ですが、upgradeにより、クライアント側もドライバの変更など必要になるものがあるので、そちらも精査&検証しておきます。
そして、upgrade時のエラー回避をするために
ハードウェアの状態やネットワーク, OSやkernelパラメータ, 各Hadoopエコシステムの事前状態のチェックをやっておきます。
- ハードウェアに関しては、BMCや(弊社ではIBMの物理サーバなので)MegaCliで状態を確認
- ネットワークに関しては、帯域/負荷や経路の状態, プロキシ/NATなど確認
- OSに関しては、CDH等では自動でupgrade処理が走る箇所があるので、そこでエラーが起きないようなパラメータ周りの確認
- kernelに関しては、sysctlを始めとしたパラメータやprocファイルシステム等で状態を確認
- 各Hadoopエコシステム関しては、事前状態チェックにHadoopコマンドやCMの機能を使用。error/warnを取り除きログの確認
HadoopコマンドやCMの機能でクラスタの状態を確認しておくのは、重要です。
例を挙げると以下のようなものがあります。
確認したHadoopのコマンドの例
// DataNodeの状態やブロックの状態確認コマンド(Missing blocksがないか等) # date; hadoop dfsadmin -report | tee -a /path/hadoop-dfsadmin_`date +%Y%m%d%H%M`.log
// // HDFSのブロック(ファイル)の状態確認コマンド(HDFSのステータスは正常か, 書き込み用にオープンされてないか等) # date; hdfs fsck / -files -blocks -locations -openforwrite | tee -a /path/hdfs-fsck_`date +%Y%m%d%H%M`.log
CMの機能
- ホストインスペクタ/セキュリティインスペクタ
- diagnostic bundle
ホストインスペクタは、upgrade実施時にも行われますが、事前チェックで実行しておいても良いと思います。
CDH5/CM5後も 当然ながら、HadoopコマンドやCMの機能を使用し、error/warnを可能な限り全て取り除き、ログも確認します。
(検証した項目) 2-2. 動作検証
これは、upgrade後に使用しているHadoopエコシステム全てが正常に動作するかの検証です。
HDFS からMap Reduceなどの基本機能から、
集計job/クエリ/連携する周辺システムなど全ておいて、動作が問題ないかを検証します。
ざっくりですが、以下のような項目を行いました。
- HDFS
- webUI
- dfs基本コマンド
- httpfs(sendなど)
- フェールオーバ
- リバランス
- mapreduce1
- webUI
- job/job-kill
- フェールオーバ
- Hive
- Hue
- ファイルブラウザ
- Hive関連
- Impala関連
- Sqoop
- インポート
- エクスポート
- distcp
- CDH5 → CDH4
- CDH5 → CDH5
- Impala
- クエリなど
- 連携システム/周辺システムの動作など
- mgmtの各種機能
- CMの基本機能とCloudera Enterprise機能
- クラスタ全体的なもの
ここでキモになってきたのが、distcpでした。
Hadoopクラスタ2つのupgradeで1つ目のクラスタをupgradeするとCDH4 → CDH5のdistcpになります。
また、2つ目のクラスタをupgradeすると、CDH5 → CDH5になります。
そして、distcpはhdfsプロトコルとwebhdfsプロトコルがあります。
検証では、主に以下のような結果となりました。
| 対象 | プロトコル | 結果 |
|---|---|---|
| CDH4→CDH5 | hdfsプロトコル | × |
| CDH4→CDH5 | webhdfsプロトコル | ○ |
| CDH5→CDH5 | hdfsプロトコル | ○ |
| CDH5→CDH5 | webhdfsプロトコル | ○ |
(検証した項目) 2-3. 性能試験
これは、CDH4/CM4 → CDH5/CM5にupgrade後 性能劣化等がないかの検証です。
基本的に、メジャーアップグレードを行うと、性能があがるはずです。
性能改善によりクライアント側で別途対応が必要になってくるものがあります。
それも可能な限り、検証しておきます。
項目としては、基本的の検証した項目/動作検証を行うべき箇所を追従しています。
(検証した項目) 2-4. 障害試験
CDH4/CM4 → CDH5/CM5にupgrade後、冗長性が担保できているかの試験です。
主に1次障害を想定しており、スタンバイに自動で切り替わるか、想定した時間以内で切り替わるか等の試験です。
自身の運用してるインフラ環境/クラスタ構成に合わせた試験シナリオになります。
弊社では、以下に関して試験しました。
(検証した項目) 2-5. 設定値の差分検証
これは、CDH4/CM4 → CDH5/CM5にupgrade後、設定値の変更差分の検証です。
基本的に、upgrade時に設定パラメータの自動変換が行われますが、別途、追加/修正するものが複数あります。
1つ例をあげると、ulimit。
ulimit等、OS側で設定を反映しても、ミドルウェア側で反映されない事はあります。
OS側に設定を入れた後、
CDH4の時は、起動スクリプトで呼ばれるcmf-agentで以下の設定を入れていました。
# cat /usr/sbin/cmf-agent . . . # Max number of open files #ulimit -n 32768 ulimit -n 120000 # Max number of child processes and threads #ulimit -u 65536 ulimit -u unlimited
CDH5からは、GUI上で可能になっているので、上記を廃止し各Hadoopエコシステムに追加で設定を入れます。
GUI) 設定 → プロセスファイル記述子の最大数
(検証した項目) 2-6. ロールバック検証
これは、CDH4/CM4 → CDH5/CM5にupgrade中に問題が起きて、
戻すときの検証です。主に、downgradeとバックアップ/リストアの試験です。
CDH4/CM4 → CDH5/CM5では、upgradeの作業箇所によってdown grade可能な箇所と不可能な箇所があります。
HDFSのmeta data Finalizeをすると戻せなかったりします。
Clouderaの公式ドキュメントの通りです。
Rolling Back a CDH 4 to CDH 5 Upgrade
Reverting a Failed Cloudera Manager Upgrade
バックアップでは、以下を取得しました。
使用しているエコシステムによって、必要なバックアップを取得しておきます。
- Name Node metadataのバックアップ
editsやfsimageです。lockファイルがない状態で取得
- meta store(マルチmaster)のバックアップ
- Cloudera ManagerのDBバックアップ
それぞれ、scm/smon/amon/hmon/rman。パスワード情報は、以下から取得できます。
/etc/cloudera-scm-server/db.mgmt.properties /etc/cloudera-scm-server/db.properties
- Cloudera Manager apiによる設定情報のバックアップ
curl -u XXX:XXX http://localhost:7180/api/v5/cm/deployment > /path/cm_backup.json_`date +%Y%m%d%H%M`.dump
- Hue DB
- agent configのバックアップ
- 他一部のdata(後述)
(準備した項目) 2-7. 影響範囲の再精査と周知
そもそも、
検証前に一番最初にやる項目でHadoopを停止できるか という事に関わってきます。
弊社のHadoopは、さまざまな周辺システムと連携し機能提供しています。
これらの周辺システムを再精査し、Hadoop停止によって発生するサービス影響/システム影響を考慮し、その時間を決めておきます。
(準備した項目) 2-8. upgrade検証からの手順作成
upgrade検証(upgrade検証, 動作検証, 性能試験, 障害試験, 差分検証,ロールバック検証)で行った項目をupgrade当日の実施手順に落としていきます。
ここで、注意したのが時間です。
upgradeに使用していた検証環境は、本番環境とは同等のノード構成/データ量ではないため(諸事情によりそんな検証環境を構築できないため)、
検証環境でのupgrade時間が、本番環境のupgrade時間にはなりません。
例を挙げると、「バックアップ」,「HDFSのmeta data upgrade」「parcelsの展開とアンパック」等です。
これらの検証環境と本番環境の構成/データ量によって、時間がかかる処理を
ポイント/ポイントで洗い出していき、実際の本番環境実施時にかかる時間を計算します。
先ほど、挙げた例の「バックアップ」ですが、
Hadoopのようなビッグデータ系システムの完全なバックアップ(数百TB~PBクラス)をとるのが時間の都合上難しいです。
完全なバックアップをとれたとしても、リストアするのも時間の都合上難しいです。
完全なバックアップ保証するならば、あらかじめ本番環境のHadoopクラスタをそのようなアーキテクチャにしておかないと
現実的ではありません(例えば、完全にクラスタを2重化し同時に2クラスタにデータを書き込むなど)
弊社のクラスタは、アドホック用途/バッチ用途と2つの本番クラスタがありますが、
諸事情により、2つのクラスタで異なるサービスを提供し、完全なバックアップはとっていないため、上記の2重化の期待はできません。
「完全なバックアップはとれない」ので、実データの一部のバックアップを取得しておきます(検証した項目/ロールバック検証の他一部のdata)。
upgrade実施時に問題が発生した時は、その一部のバックアップからクラスタの状態をロールバックし、
縮退させた最小限のサービスを提供できる状態にします。
(準備した項目) 2-9. 当日のタイムスケジュールテーブル
実施のクラスタは2つあるので、2つのタイムテーブルを作成します。
各クラスタの作業時間は、作業バッファを考慮しつつも以下になりました。
1つの本番クラスタを行った後は、1週間ほど経過観察期間を設けました。
(準備した項目) 2-10. upgrade失敗時のシナリオリスト
upgrade実施作業で予期せぬ事象や、失敗(ケース)等が起こった時の対応方針リストを作成しておきます。
「事象:○○○が発生 → 対応:○○○行い復旧する」という○○○を埋めるようなリスト(最悪な失敗ケースも含む)です。
十数個リストアップしましたが、例を1つ挙げると、
事象 : CDH4/CM4 → CDH5/CM5に正常にupgrade終了後, HDFSにアクセス出来ない
対応 : クラスタ再インストール&一部取得したバックアップをdistcpしサービスを復旧する
(準備した項目) 2-11. 他作業ツール類の用意
実際のupgrade作業に使用するツール類の準備です。
1つ例を挙げると動画キャプチャソフトを使いました。
数時間のupgrade作業も人が行います。
作業者と確認者をたてたとしても、人が関わる以上、手順実施抜けが出たりする事はなくはありません。
そこで、実際の実施時の作業証跡を簡単振り返れるようにしておくのは、有事の際に有効だと思います。
今回のupgrade作業は、GUI作業とCUI作業がありました。
GUIで画面キャプチャ、CUI作業でバックグランドロギング等ありますが、それに並行してまとめて全オペレーションの動画キャプチャを取得しておくと、簡単に振り返れて便利なので用意しました。
(準備した項目) 2-12. Clouderaサポートの活用
弊社では、Hadoop専任エンジニアがいません。僕も普段は異なるインフラ業務も行っています。
そのため、Clouderaサポートに入り、知見を頂き相談しました。
サポートの活用として、例を挙げると、メジャーアップグレード前と後で diagnostic bundleを取得し精査してもらう、upgrade実施日の事前共有等です。
ご協力いただいたCloudera様 ありがとうございました。
検証で苦労した事
2クラスタ分まとめて記載します。
- CDHディストリビューション以外の後入れの別バイナリ対応
詳しくは述べませんが、いくつか後入れの別バイナリがありました。
こちらは、事前に可能な限り調査し検証しておきます。
本番でうっかり見つけ、その場対応だとけっこう死ねます。
後入れ別バイナリに関しては、upgradeの有無とupgradeをしたらサーバ側の動作/性能に問題ないか等を検証しておきます。
この程度ならば問題ないのですが、厄介なのが、
後入れ別バイナリがメジャーアップグレード前には一部動いてなかったもの(読み込まれてなかったもの)が、メジャーアップグレード後にその一部が勝手に動き始めて(読み込まれて)、動作に影響を与える事です。
実際に、この事象が発生しCDHのsqoopが一切動作せず苦労しました。
これは、クラスタがサービスインしてから、
スケールアウトで付け足して行ったノードのOS(CentOS)が異なっていました。
付け足していった時期がそれぞれ異なるので、その時期に沿って追加ノードをyum updateをかけていたのでしょう。
対応方法としては、OSのversionが異なるとyumの依存モジュールが異なるので、OSを偽造させたりします。
OS偽造は、scm-server側のupgrade前と後、もしくはCDH側のupgrade前と後でyumの依存モジュール群や別入れバイナリに影響がないか精査し、
タイミングを見計らって偽造、及び偽造解除を行います。
偽造の一例としては、redhat-releaseとかにOS開発コードネームを記載してシステム誤認識させます。
3. アップグレード実施
アドホック用途のHadoopクラスタのメジャーアップグレード実施を行い、 次にバッチ用途のHadoopクラスタのメジャーアップグレードを行いました。
停止させてのHadoopクラスタのupgrade自体は簡単でした。
本来あるべき姿としては、「検証の手順通りだったね。 突発的な対応や予期せぬ事象は何もなく無事完了! 」です。
しかし、Hadoopクラスタ2つとなると上記のように達成させるのは、なかなか難しかったです。。
実際に以下のようなが起きました。
実施時に発生した予期せぬ事象
2クラスタ分まとめて記載します。
- HDFS metadataのupgdate失敗
上記画像はCDHのアップグレード最後の画面です。各項目がありますが、正常時は順繰りに自動でアップグレードしていってくれますが、
実施時に、HDFS metadataのupgradeで失敗しました。
詳細を追って行くと、HDFSのmeta dataのupgradeは成功し、Data Nodeの起動で失敗したログが出力されていました。
CMがあるホストとData Node起動が失敗したホストで、FIN_WAIT2とCLOSE_WAITのセッションが残っていて、socketがbindできなかったのが原因でした。
ここで処理が失敗すると、CM5.4では後続のupgrade処理は全て行われません(このブログを書いた時点での最新CM5.5からはリトライ機能があります)。
具体的には、oozie, sqoop,Hive,Hue
こちらは、全て手動でupgradeを行いました。
- メジャーアップグレード作業を全て完了させても、実はまだupgrade中
scm-serverをあげ、parcelsを展開後CDHのupgradeを行い、upgrade完了のGUI上の案内が出てもバックグランドでupgrade処理が走り続けている事象が起きました。
具体的には、mgmtのeventserverで、CDHのupgrade後もindex version upgradeの処理が走り続けます。
そのため、起動ができずエラーでおちました。
最初はなかなか気づかず、以下のようなログが出力されていました。
# tail -f /var/log/cloudera-scm-eventserver/mgmt-cmf-mgmt1-EVENTSERVER-XXX.log.out . . . 2015-10-03 16:21:46,024 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: Index Upgrade destination /var/lib/cloudera-scm-eventserver/v3 is not an empty directory. This likely means that the Event Server exited during a previous upgrade attempt. Deleting all files in /var/lib/cloudera-scm-eventserver/v3 and retrying the upgrade to version 3 2015-10-03 16:21:46,831 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: Reading lucene index from /var/lib/cloudera-scm-eventserver/v2 2015-10-03 16:21:47,215 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: Writing new lucene index to /var/lib/cloudera-scm-eventserver/v3 2015-10-03 16:21:47,335 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: Upgrading documents in index 2015-10-03 16:21:47,335 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 0% complete 2015-10-03 16:22:31,853 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 10% complete 2015-10-03 16:23:16,309 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 20% complete 2015-10-03 16:23:58,001 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 30% complete // この辺りで、正常upgradeのGUI上の案内が表示された 2015-10-03 16:24:34,168 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 40% complete 2015-10-03 16:25:14,868 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 50% complete 2015-10-03 16:26:06,831 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 60% complete 2015-10-03 16:26:45,521 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 70% complete 2015-10-03 16:27:24,832 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 80% complete 2015-10-03 16:28:14,062 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 90% complete 2015-10-03 16:28:52,434 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: 100% complete 2015-10-03 16:28:52,434 INFO com.cloudera.cmf.eventcatcher.upgrade.IndexVersionManager: Closing IndexReader . . .
- distcpが不安定
upgrade前の2つのクラスタ(CM4/CDH4 → CM4/CDH4)間でのdistcpは、hdfsプロトコルでしたが、
1つのクラスタをupgradeし、CM5/CDH5 → CM4/CDH4間でのdistcpは、webhdfsプロトコルで対応していました。
このプロトコルを変えたことで、コネクションの張り方やchecksum等の方式が変わり、貧弱なネットワーク環境が悲鳴をあげました。
事象としては、数MBから数GBくらいまでのデータ量はdistcpできましたが、
数100GBクラスになるとコネクションが切断されました。
ネットワーク機器にログインして、ステータスを見るとCPUがほぼMAX状態で、パケットDropを検知しており、サーバ側でも以下のログが出ていました。
// TCP統計情報を時刻印時で秒間取得
# watch -n 1 'date >> /var/tmp/netstat.log; netstat -s|grep socket && cat /var/tmp/netstat.log|tail -n1’
Every 1.0s: date >> /var/tmp/netstat.log; netstat -s|grep socket && cat /var/tmp/netstat.log|tail -n1 Wed Oct 7 16:05:37 2015
79 resets received for embryonic SYN_RECV sockets
266993 packets pruned from receive queue because of socket buffer overrun
946064 TCP sockets finished time wait in fast timer
48206649 TCP sockets finished time wait in slow timer
207154 delayed acks further delayed because of locked socket
19543 times the listen queue of a socket overflowed
19543 SYNs to LISTEN sockets ignored
13910824 packets collapsed in receive queue due to low socket buffer
2015年 10月 7日 水曜日 16:05:37 JST
- oozieの起動でCM停止
upgradeのために、数年ぶりにoozieを起動したところ、
CMがメトリクスを収集し始め、LAが高騰して、cloudera-scm-agentからのheatbeatが切断されました。
クラスタをCMからコントロールできなくなりました。
そもそも、このoozieですが、普段使用しておらず、
クラスタから削除できない事情がありました(Hueと設定が依存している事からoozieの削除が出来ない)。
起動したままでは、リソースを消費するため、Hadoopクラスタローンチ時に停止していました。
- parcels展開とアンパックの時間が増加
ここの時間消費は、事前に見積もっていたものですが見積もり以上に時間がかかりました。
数十台のノード一気にparcels展開とアンパックを行うと、
checksum missmatchが大量に発生し、リトライが走ります。
事前の検証環境では、数台構成で行ったため、このような事象は起きませんでした。
上記のような事象が発生しましたが、
サービス上の深刻な問題はなく、実際の時間内に解決できたため、無事メジャーアップグレードを完遂しました。
最後に
データ量やクラスタ構成、ハードウェア構成などから同等の検証環境を用意するのが現実的ではなく、
本番環境と差異があり、様々な事象が発生しました。
CDHのようなパッケージを入れていても、
万全の体制で挑むならば、CDH4/CM4 → CDH5/CM5のupgrade検証も可能な限り、本番と同等の環境を用意して望んだ方が良いです。
また、当初 検証を始める前に、
ググってもHadoopメジャーアップグレードの似た事例がほとんど見つからず、なかなか大変でした。