본 문서에서는 Cloudera Manager의 내부 동작 방식에 대해 설명을 하고 있습니다.
Cloudera Manager의 Term
아래의 그림은 Cloudera Manager에 내부 용어를 설명하고 있습니다:
"Deployment"는 가장 큰 개념으로 한 개이상의 클러스터를 포함할 수 있습니다. "Cluster"는 복 수개의 호스트의 집합(동일한 CDH 버전이 실행됨을 의미)이며, "Host"는 물리적인 장치입니다. "Service"는 다양한 역할을 담당하는 특정 호스트에 배포된 인스턴스입니다. "Role Config Goup"은 복 수의 Role을 한번에 구성하기 위한 기능을 제공하는 단위입니다.
구성정보는 컨텍스트 기반의로 구조화되어 있습니다. 예를 들어, DataNode의 로그 파일의 경로 정보는 일반적으로 "Role Config Group"하위에 존재하지만, 하위 Role에서 정의한 값으로 특정 서비스의 로그 경로 위치를 재정의할 수 있습니다.
하둡의 특성으로 인해 명심해야 하는 점은 다양한 서비스들이 하나의 호스트에서 실행될 수 있으며, 또한 하나의 서비스가 다중 호스트에서 실행된다는 점입니다.
Agent/Server Architecture
Cloudera Manager는 CDH를 관리하기 위한 특정 서버에서 실행되는 서버 프로세스로 일반적으로 Cloudera Manager Server라고 합니다(관리 콘솔). 이 Cloudera Manager Server를 사용하여 관리자는 CDH를 설치하고, 서비스를 구성하고, 특정 서비스들을 실행 및 중지하는 작업을 실행할 수 있습니다.
Cloudera Manager Agent는 Cloudera Manager Server에 의해 관리되는 모든 호스트에 설치됩니다. 이 에이전트는 리눅스 프로세스를 시작/중지하고, 다양한 설치 경로를 트리거링하며 설치된 호스트를 모니터링하는 역할을 담당합니다.
Heartbeating
Cloudera Manager는 기본 채널을 통해 Heartbeat 통신을 합니다. 에이전트는 15분 주기(Default)로 서버에게 Heartbeat 메시지를 전송하여 에이전트에서 수행되어야 하는 작업 목록을 받아옵니다.
Agent Process Supervision in Detail
에이전트의 주요 역할 중 하나는 프로세스를 시작하고 중지하는 것입니다. 에이전트가 서버로 부터 응답받은 heartbeat 메시지에 새로운 프로세스가 포함된 경우, 해당 에이전트는 /var/run/cloudera-scm-agent 디렉터리에 새로운 서비스를 위한 디렉터리를 생성하고 서버로 부터 전달받은 구성 정보를 압축을 풀어 해당 디렉터리에 배포합니다. 즉, Cloudera Manager 서버가 모든 역할을 수행하는 것이 아니라 에이전트들과 상호작용하는 부분이 매우 중요한 포인트입니다.
Cloudera Manager Agent는 자체 실행 및 구성 환경을 통해 호스트별로 독립된 실행 제어 환경을 제공함으로써, 하둡과 같은 복잡한 구성환경을 수용해야하는 시스템에 적합하게 설계되었습니다. 다음의 디렉터리 정보는 개별 호스트에 에이전트에 의해 구성된 독립적인 실행 환경의 예입니다:
Cloudera Manager는 내부적으로 프로세스를 실행하고 중지하기 위해서 supervisord라는 오픈소스 시스템을 사용합니다. 이 오픈 소스는 로그 파일을 리디렉션하고, 프로세스 장애를 감지하여 통지하고 올바른 사용자에게 "setuid" 명령을 수행합니다.
Cloudera Manager는 하둡 용 클라이언트 구성정보(Client Configuration)를 "/etc/hadoop/conf"에 저장합니다. 즉, Hadoop과 통신을 필요로하는 프로그램을 실행한 경우, 해당 프로그램은 NameNode와 JobTracker의 주소 정보 및 기타 중요하 구성 정보를 해당 호스트의 클라이언트 구성정보 디렉터리에서 참조하여 가져옵니다. Cloudera Manager는 내부적으로 "Client" 구성과 "Service" 구성을 분리하여 처리합니다. 예를 들면, MapReduce 작업을 위한 Java Heap 크기 정보나 default HDFS Replication Factor와 같은 설정은 클라이언트 구성정보이기 때문에 이와 관련된 정보가 변경된 경우, 변경된 정보를 각 호스트의 "클라이언트 구성 정보" 디렉터리에 갱신하기 위해서 "Deploy Client Configuration" 액션을 수행하면 됩니다. 즉, 불 필요하게 구성 정보 변경에 의해 서비스를 재시작할 횟 수를 최소화하도록 설계되어 있습니다.
Cloudera Manager가 관리하는 프로세스(예: RegionServer와 DataNode와 같은 실제 데몬 들)들은 /etc/hadoop/conf 디렉터로를 사용하지 않고, 위에서 설명된 것과 같이 프로세스 자신의 복사본을 사용합니다.
운영 환경에서는 클러스터와 동일한 네트워크에 존재하지만 하둡 데몬들이 실행되지 않는 "Edge", "Client"나 "Gateway"와 같은 호스트들이 존재할 수도 있습니다. 사용자들은 이와 같은 시스템에서 원격 작업을 수행하거나, 파일 시스템에 접속하기 위한 Proxy 용도로 활용됩니다. 이러한 호스트에 클라이언트 구성 정보를 배포하기 위해서는 Cloudera Manager에서 해당 호스트에 "Gateway" Role을 추가한 뒤, "Deploy Client Configuration" 액션을 사용하여 Gateway Role이 배포된 호스트에 클라이언트 구성정보를 배포니다.
또한, 에이전트기 실행되어 있지 않거나 에이전트에 문제가 발생한 경우, Cloudera Manager 관리 콘솔에는 호스트 모니터링 항목에 해당 호스트의 상태 정보가 "Bad" 상태로 마킹되어 있습니다.
Meanwhile, on the Server…
Cloudera Manager 서버는 전체 클러스트의 상태를 관리합니다. 또한, "Model"과 "Runtime" 상태로 나뉠 수 있으며, 이는 Cloudera Manager 서버의 리파지토리 데이터베이스에 저장됩니다.
"Model State"는 어떤 구성정보를 통해 어디서 수행되어야 하는지에 대한 것을 의미합니다. 예를 들어, 17개의 호스트에 DataNode가 실행되어 있는 환경에 대한 내용이 바로 "Model State"입니다. Cloudera는 다양한 하둡 컴포넌트를 역할(Role), 구성 및 상호 의존성 기반으로 모델링하였습니다. Cloudera Manager의 사용자는 관리 콘솔을 통해 이와 같은 모델들과 상호작용 되도록 설계되어 있습니다(예: 서비스 추가와 같은 오퍼레이션).
"Runtime State"는 어떤 프로세스어 어디서 실행되었고, 어떠한 명령어(예: HDFS Re-balance, Backup/Disaster Recovery 스케쥴이나 롤링 재시작 등)가 현재 실행중인지를 의미합니다. Runtime State는 프로세스를 실행하는데 필요한 정확한 구성정보 파일과 같은 중요 정보들을 포함하고 있습니다. 즉, 관리자가 Cloudera Manager 콘솔에서 "시작" 버튼을 클릭한 경우, Cloudera Manager 서버는 관련된 서비스와 역할에 대한 모든 구성정보를 수집하고, 수집된 구성정보 파일의 유효성 여부를 판별한 뒤, Config file을 생성한 뒤 Cloudera Manager Repository 데이터베이스에 저장합니다.
예를 들어, 관리자가 Hue의 웹 포트 구성정보를 변경하는 액션을 Cloudera Manager에서는 Model을 갱신된 것을 의미합니다. 그러나, Hue가 실행중인 환경에서 이 모델의 변경 사항은 이전에 구성된 Hue 웹 포트로 리스닝할 것입니다. 이와 같이 구성된 모델과 실행중인 모델의 불일치 정보가 존재하는 경우, Role은 "Outdated Configuration"로 Cloudera Manager에 표시되어 관리자에게 쉽게 식별할 수 있게 해줍니다. 즉, 관리자가 해당 Role을 재시작하여 내부적으로 Model에 반영된 새로운 구성 정보를 생성한 뒤, 해당 변경사항을 참조하여 프로세스가 기동됩니다.
빈번하게 요청받는 질문중의 하나가 구성정보를 백업하는 방법에 대한 내용입니다. 단순한 해결책은 "/api/cm/deployment API endpoint"의 정보를 수집하기위해 Cloudera Manager API를 사용하는 것입니다. 이는 Runtime 정보를 제외한 전체 Model 정보를 수집하는 방식입니다. 두 번째 방법은 전체 Cloudera Manager Server 데이터베이스를 정기적으로 백업받는 방식입니다.
Monitoring and Other Management Services
Cloudera Manager는 자체 Management Service들을 관리합니다. Cloudera Management Service들은 Activity Monitor, Service Monitor, Host Monitor, Event Server, Report Manager 및 Alert Publisher로 구성되어 있습니다. 운영 환경에 따라 Cloudera Manager는 내부 관리 서비스들을 확장성 및 자원 독립성의 목적으로 물리적으로 분리된 호스트에 배포하여 운영할 수도 있습니다.
Metric Collection
Cloudera Manager는 모니터링 기능을 제공하기 위해 내부적으로 메트릭(Metric)을 수집합니다. 메트릭은 모니터링 대상의 이름, 호스트와 같은 적용대상 및 시간과 연결된 단순한 숫자 값이며, 대부분의 메트릭 수집은 에이전트에 의해 수행됩니다. 에이전트는 supervised 프로세스와 연결되어 메트릭 정보를 수집하며 Service Monitor에게 수집된 메트릭 정보를 전송합니다. 메트릭 수집 주기는 매 1분마다 실행됩니다. 일부 특정 메트릭은 Service Monitor 자체에서 수집되기도 합니다. 관리자 및 사용자들은 Cloudera Manager의 차트 페이지를 사용하여 모니터링 용도로 수집된 메트릭 정보를 탐색하거나 검색할 수 있습니다.
Health Checks
Service Monitor는 시스템내의 모든 엔터티에 대한 헬스체크를 지속적으로 점검합니다. 예를 들면, NameNode 데이터 디렉터리내의 충분한 디스크 공간이 있는지를 확인 한다거나, HDFS용 최종 체크포인트가 임계 값내에 존재하는지 또는 DataNode가 NameNode에 연결되어 있는지를 확인하는 것입니다. 또한, 일부 헬스 체크는 HDFS와 같이 분산 시스템내에서 생성된 헬스 체크의 결과 값을 집계하여 보여주기도 합니다. 분산 시스템의 특성으로 전체 DataNode중 일부가 내려간 상태에 대해 관리자에게 임계값을 전체 DataNode 중 비율 기반으로 서비스의 상태 변화를 감지하도록 임계값(Threadhold)를 정의할 수도 있습니다. Cloudera Manager는 다양한 고객사의 실제 사용 기반으로 헬스 체크의 임계값을 적용하였습니다.
헬스 체크의 결과 값으로 특정 엔터티의 상태가 "빨간색"으로 변경된 경우, 이메일이나 SNMP를 통해 관리자에게 공지되도록 이벤트가 생성되고 Alert 기능을 구성하여 활용할 수도 있습니다. Cloudera Manager 모니터링 기능의 목적은 별도의 도구를 추가 설치 및 구성하지 않고 모니터링 기능을 제공하는 것입니다.
출처: http://blog.cloudera.com/blog/2013/07/how-does-cloudera-manager-work/
'Big DATA > Cloudera' 카테고리의 다른 글
| Cloudera - Oracle RAC 구성 (0) | 2017.01.10 |
|---|---|
| Sensitive Data Redaction (0) | 2016.11.14 |
| Authorization With Apache Sentry (0) | 2016.11.14 |