Cloudera Manager(CM) 7.11.x → 7.13.x 업그레이드를 진행하면서 정리한 절차와, 버전별로 달라지는 JDK·Python 요구사항이다. 7.13.2 로 올릴 때 yum upgrade 가 %prein 스크립틀릿에서 실패한 사례가 출발점이다.
CM 업그레이드는 준비 → 백업 → 서버 패키지 업그레이드(CLI) → 에이전트 업그레이드(웹 마법사) → 마무리 순서로 진행한다. CM 업그레이드는 Cloudera Runtime(파슬) 이나 서비스 롤을 건드리지 않으므로 클러스터 다운타임이 필요 없다. 반드시 내려야 하는 것은 Cloudera Management Service 뿐이다.
/etc/cloudera-scm-server, /etc/cloudera-scm-agent/config.ini, Management Service 상태 디렉터리. 상세는 SCM DB 백업 참고.cloudera-scm-server · cloudera-scm-agent 중지 → 대상 버전 .repo 구성 → yum clean all → 패키지 업그레이드 → 서버 기동.yum upgrade cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent
# 임베디드 PostgreSQL 사용 시에만 cloudera-manager-server-db-2 를 추가한다.
systemctl start cloudera-scm-server
config.ini 를 복원한다.에이전트 업그레이드 뒤에도 각 롤 프로세스는 supervisord 아래에서 그대로 살아 있다. cloudera_agent_post_upgrade_checker.sh 가 기존 PID 를 새 에이전트에 재연결하며, agent_upgrade.log 와 아래 명령으로 실제 재기동 여부를 확인할 수 있다.
/opt/cloudera/cm-agent/bin/supervisorctl -c /run/cloudera-scm-agent/supervisor/supervisord.conf status
less /var/log/cloudera-scm-agent/agent_upgrade.log
실제 사례에서는 Python 3.8 → 3.11 전환과 함께 업그레이드하면서 ZooKeeper 만 proc_monitor 재연결에 실패해 재기동됐다.
| CM 버전 | JDK | Python (RHEL 8) | 비고 |
|---|---|---|---|
| 7.11.3 | 8 / 11 / 17 | 3.8 | Runtime 7.1.9 |
| 7.13.1 (CHF1~) | 8 / 11 / 17 | 3.8 또는 3.9 (3.9 권장) | RHEL 9.2 는 3.9, SLES 15 는 3.10 |
| 7.13.1.800 (CHF8) | 8 / 11 / 17 | 3.9 또는 3.11 권장 | CM UI 의 "Cloudera 제공 OpenJDK 설치" 옵션 제거, 저장소에서 OpenJDK 8 RPM 삭제 |
| 7.13.2 | 17 만 지원 | 3.11 | Runtime 7.3.2 와 함께 JDK 8/11 지원 제거 |
This system is not registered with an entitlement server 는 RHEL subscription-manager 경고일 뿐 업그레이드 실패 원인이 아니다.