Cloudera 에서 "버전" 이라고 할 때는 Cloudera Manager(CM) 와 Cloudera Runtime(CDP Private Cloud Base · Cloudera Base) 를 따로 봐야 한다. 두 축의 수명 주기가 다르고, 한쪽만 올리는 업그레이드도 정상적인 선택지이기 때문이다. CM 은 자기보다 낮은 Runtime 을 관리할 수 있으므로 CM 을 먼저 올리고 Runtime 은 나중에 올리는 순서가 표준이다. 반대 순서는 지원되지 않는다.
LTS(장기 지원) 계열과 STS(단기 지원) 계열도 구분한다. 운영 클러스터는 LTS 계열에 머무르는 것이 원칙이고, STS 는 특정 기능이 필요할 때만 선택한다.
| 구분 | 버전 | 성격 |
|---|---|---|
| CDP Private Cloud Base | 7.1.9 (SP 포함) | 기존 LTS 계열 |
| Cloudera Base on premises | 7.3.x | 새 LTS 방향 계열 |
| Cloudera Manager | 7.11.3 | 7.1.9 계열에서 쓰던 CM. 수명 종료에 가까움 |
| Cloudera Manager | 7.13.1 | 현행 CM. 7.1.9 와 7.3.x 를 모두 관리 |
7.1.9 를 쓰고 있다면 Runtime 을 당장 바꿀 이유는 없고, CM 을 7.11.3 에서 7.13.1 로 먼저 올리는 것이 부담이 가장 적은 경로다. 신규 구축이라면 7.3.x 계열과 그에 맞는 CM 을 고른다.
정확한 지원 종료 일자와 LTS 여부는 계속 바뀐다. 구축 직전에 Cloudera 의 Support Lifecycle 문서와 해당 버전의 Release Notes 를 직접 확인한다.
RHEL 계열이 주 대상이지만 Ubuntu 도 지원 목록에 들어 있다. 실무에서 고를 수 있는 것은 사실상 Ubuntu 22.04 LTS 하나다. 20.04 는 OS 자체의 표준 지원이 끝났고, 24.04 는 Cloudera 지원 매트릭스에 올라온 것을 확인하지 못했다. (확인 필요 — Support Matrix 는 CHF 단위로도 바뀌므로 구축 시점에 다시 본다.)
주의할 점은 OS 버전 하나만 보면 안 된다는 것이다. Runtime · CM · CHF/SP · Python · JDK 조합이 같이 맞아야 한다. 같은 Ubuntu 22.04 라도 Runtime/CM 조합에 따라 요구하는 Python 마이너 버전이 달라지는 사례가 있다.
OS Ubuntu Server 22.04 LTS
Cloudera Manager 7.13.1 계열
Runtime 7.1.9 SP 계열 또는 7.3.x
parcel · 패키지 저장소는 archive.cloudera.com 아래의 인증 구역에 있다. 구독 계정으로 받은 사용자 이름과 비밀번호가 있어야 접근되고, 경로에는 제품군과 버전이 들어간다.
https://${CLOUDERA_USER}:${CLOUDERA_PASSWORD}@archive.cloudera.com/p/<제품>/<버전>/parcels/
CHF(누적 핫픽스) 는 같은 마이너 버전 아래에서 -h<번호> 같은 하위 경로로 갈린다. 어떤 CHF 가 어떤 경로를 쓰는지는 해당 버전의 Cumulative Hotfixes 문서에 정리돼 있으므로, 경로를 추측하지 말고 문서에서 복사한다.
자격 증명은 .repo 파일이나 CM 의 원격 저장소 설정에 들어가므로 파일 권한을 제한하고 저장소에 커밋하지 않는다.