이 기사는 Zookeeper의 원리에 대해 이야기합니다. 편집자는 그것이 꽤 좋다고 생각합니다. 나는 당신의 참조를 위해 당신과 공유 할 것입니다. 세부 사항은 다음과 같습니다.
머리말
Zookeeper는 Yahoo가 만든 오픈 소스 분산 조정 서비스이며 Google Chubby의 오픈 소스 구현입니다. 분산 응용 프로그램은 데이터 게시/구독,로드 밸런싱, 이름 지정 서비스, 분산 조정/알림, 클러스터 관리, 마스터 선거, 분산 잠금 및 분산 큐와 같은 기능을 구현할 수 있습니다.
1. 소개
Zookeeper는 Yahoo가 만든 오픈 소스 분산 조정 서비스이며 Google Chubby의 오픈 소스 구현입니다. 분산 응용 프로그램은 데이터 게시/구독,로드 밸런싱, 이름 지정 서비스, 분산 조정/알림, 클러스터 관리, 마스터 선거, 분산 잠금 및 분산 큐와 같은 기능을 구현할 수 있습니다.
2. 기본 개념
이 섹션에서는 Zookeeper의 몇 가지 핵심 개념을 소개합니다. 이러한 개념은 나중에 Zookeeper에 대해 더 깊이 설명되므로 이러한 개념을 미리 이해해야합니다.
2.1 클러스터 역할
Zookeeper에는 세 가지 문자가 있습니다.
지도자
수행원
관찰자
사육사 클러스터는 동시에 하나의 리더 만 갖고 다른 리더는 추종자 또는 관찰자가 될 것입니다.
Zookeeper의 구성은 매우 간단합니다. 각 노드의 구성 파일 (zoo.cfg)은 동일하며 MyID 파일 만 다릅니다. MyID의 값은 zoo.cfg의 서버의 {numeric} 부분이어야합니다. {numeric}.
zoo.cfg 파일 콘텐츠의 예 :
동물원 키퍼
Zookeeper와 함께 기계의 터미널에서 Zookeeper-Server 상태를 실행하십시오. 현재 노드의 Zookeeper가 어떤 역할을하는지 (리더 또는 추종자) 알 수 있습니다.
동물원 키퍼
위에서 언급했듯이 Node-20-104는 리더이고 Node-20-103은 추종자입니다.
Zookeeper는 기본적으로 리더와 추종자, 관찰자 역할이 없습니다. 옵저버 모드를 사용하려면 다음과 같이 추가하십시오. peertype = 옵저버가되고 추가하려는 모든 노드의 구성 파일에 대한 관찰자 : 모든 서버의 구성 파일에서 관찰자 모드로 구성된 서버의 구성 줄에 관찰자가 다음과 같습니다.
server.1:localhost:2888:3888:observer
Zookeeper 클러스터의 모든 기계는 리더 선거 과정을 통해 "리더"라는 기계를 선택합니다. 리더 서버는 고객에게 읽기 및 쓰기 서비스를 제공합니다.
추종자와 관찰자는 모두 읽기 서비스를 제공 할 수 있지만 서비스를 작성할 수는 없습니다. 둘의 유일한 차이점은 관찰자 기계가 리더 선거 과정에 참여하지 않으며 작문 작업의 "쓰기 성공적인 성공적인"전략에 참여하지 않으므로 관찰자는 쓰기 성능에 영향을 미치지 않으면 서 클러스터의 읽기 성능을 향상시킬 수 있다는 것입니다.
2.2 세션
세션은 클라이언트 세션을 말합니다. 클라이언트 세션을 설명하기 전에 먼저 클라이언트 연결을 이해해 봅시다. Zookeeper에서 클라이언트 연결은 클라이언트와 Zookeeper 서버 간의 긴 TCP 연결을 나타냅니다.
Zookeeper의 기본 서비스 포트는 2181입니다. 클라이언트가 시작되면 서버와 함께 TCP 연결이 설정됩니다. 첫 번째 연결 설정에서 시작하여 클라이언트 세션의 수명주기도 시작됩니다. 이 연결을 통해 클라이언트는 하트 비트 감지를 통해 서버와 유효한 세션을 유지할 수 있으며 Zookeeper 서버에 요청을 보내고 응답을 수락 할 수도 있습니다. 동시에이 연결을 통해 서버에서 Watch Event 알림을받을 수도 있습니다.
세션의 세션 타임 아웃 값은 클라이언트 세션의 시간 초과 시간을 설정하는 데 사용됩니다. 세션 타임 아웃에 의해 지정된 시간 내에 클러스터의 서버를 다시 연결할 수있는 한, 서버 압력, 네트워크 고장 또는 클라이언트의 과도한 단절로 인해 클라이언트 연결이 분리 된 경우, 이전에 만든 세션은 여전히 유효합니다.
2.3 데이터 노드 (Znode)
분산에 대해 이야기 할 때 일반적으로 "노드"는 클러스터를 형성하는 각 컴퓨터를 나타냅니다. Zookeeper의 데이터 노드는 Znode라는 데이터 모델의 데이터 단위를 나타냅니다. Zookeeper는 모든 데이터를 메모리에 저장합니다. 데이터 모델은 트리 (Znode 트리)입니다. 경로는 슬래시 (/)로 나눈 경로는/hbase/master와 같은 znode이며, 여기서 hbase와 mas 각 Znode는 자체 데이터 컨텐츠를 저장하고 일련의 속성 정보가 저장됩니다.
메모:
여기 Znode는 UNIX의 파일과 UNIX의 디렉토리로 이해할 수 있습니다. 각 Znode에는 데이터 자체를 작성할 수있을뿐만 아니라 (UNIX의 파일에 해당) 차세대 파일 또는 디렉토리도 있습니다 (UNIX의 디렉토리와 동일).
Zookeeper에서 Znode는 영구 노드와 임시 노드의 두 가지 범주로 나눌 수 있습니다.
지속적인 노드
소위 영구 노드는이 Znode가 생성되면 Znode가 활발하게 제거되지 않으면 Znode가 Zookeeper에 저장 될 것임을 의미합니다.
임시 노드
임시 노드의 수명주기는 클라이언트 세션에 바인딩됩니다. 클라이언트 세션이 실패하면이 클라이언트가 생성 한 모든 임시 노드가 제거됩니다.
또한 Zookeeper를 사용하면 사용자가 각 노드에 순차적 인 특수 속성을 추가 할 수 있습니다. 노드 에이 속성이 표시되면이 노드가 생성되면 Zookeeper는 노드 다음에 정수 번호를 자동으로 추가합니다.
버전 2.4
데이터는 Zookeeper의 각 Znode에 저장됩니다. 각 Znode에 해당하는 Zookeeper는 STAT라는 데이터 구조를 유지합니다. STAT는이 Znode의 세 가지 데이터 버전, 즉 버전 (현재 Znode 버전), cversion (현재 Znode 하위 노드 버전) 및 Aversion (현재 Znode ACL 버전)을 기록합니다.
2.5 상태 정보
각 Znode는 데이터 컨텐츠를 저장하는 것 외에도 Znode 자체의 일부 상태 정보를 저장합니다. get 명령을 사용하여 특정 Znode의 내용 및 상태 정보를 동시에 얻으십시오. 다음과 같이 :
동물원 키퍼
Zookeeper에서 버전 속성은 낙관적 잠금 메커니즘에서 "쓰기 검증"을 구현하는 데 사용됩니다 (분산 데이터의 원자력 작동).
2.6 거래 운영
Zookeeper에서 Zookeeper 서버의 상태를 변경할 수있는 작업을 트랜잭션 작업이라고합니다. 일반적으로 데이터 노드 생성 및 삭제, 데이터 컨텐츠 업데이트, 클라이언트 세션 생성 및 실패와 같은 작업이 포함됩니다. 각 거래 요청에 대해 Zookeeper는 ZXID (일반적으로 64 비트 번호)로 표시되는 전 세계적으로 고유 한 트랜잭션 ID를 할당합니다. 각 ZXID는 Zookeeper가 이러한 거래 작업 요청이 처리되는 글로벌 주문을 간접적으로 식별 할 수있는 업데이트 작업에 해당합니다.
2.7 Watcher
감시자 (이벤트 리스너)는 Zookeeper에서 매우 중요한 기능입니다. Zookeeper는 사용자가 지정된 노드에 일부 감시자를 등록 할 수 있으며 일부 특정 이벤트가 트리거되면 Zookeeper 서버는 관심있는 클라이언트에게 이벤트를 알립니다. 이 메커니즘은 분산 조정 서비스를 구현하는 Zookeeper의 중요한 기능입니다.
2.8 ACL
Zookeeper는 ACL (Access Control Lists) 정책을 사용하여 권한을 통제합니다. Zookeeper는 다음 5 개의 권한을 정의합니다.
작성 : 자식 노드 생성 허가.
읽기 : 노드 데이터 및 하위 노드 목록에 대한 권한을 얻습니다.
쓰기 : 노드 데이터를 업데이트 할 수있는 권한.
삭제 : 자식 노드의 권한을 삭제합니다.
관리자 : 노드 ACL에 대한 권한을 설정하십시오.
참고 : 생성 및 삭제는 자식 노드에 대한 권한 제어입니다.
3. Zookeeper의 일반적인 응용 시나리오
Zookeeper는 사용 가능한 분산 데이터 관리 및 조정 프레임 워크입니다. ZAB 알고리즘의 구현을 기반 으로이 프레임 워크는 분산 환경에서 데이터의 일관성을 보장 할 수 있습니다. 또한 Zookeeper를 분산 일관성 문제를 해결하기위한 강력한 도구로 만드는이 기능을 기반으로합니다.
3.1 데이터 게시 및 구독 (구성 센터)
이름에서 알 수 있듯이 소위 구성 센터 인 데이터 게시 및 구독은 게시자가 데이터를 가입자에 대해 Zookeeper 노드에 게시하여 데이터를 동적으로 얻는 목적을 달성하고 중앙 집중식 관리 및 구성 정보의 동적 업데이트를 실현하는 목적을 달성한다는 것입니다.
일반적인 애플리케이션 시스템 개발에서 우리는 종종이 요구 사항에 직면합니다. 시스템 목록 정보, 데이터베이스 구성 정보 등과 같은 시스템에 몇 가지 일반적인 구성 정보가 필요합니다. 이러한 전역 구성 정보에는 일반적으로 다음 세 가지 기능이 있습니다.
데이터의 양은 일반적으로 비교적 작습니다.
런타임에 데이터 컨텐츠가 동적으로 변경됩니다.
클러스터의 모든 시스템은 공유되고 구성은 일관됩니다.
이러한 글로벌 구성 정보는 Zookeeper에 게시 할 수 있으며 클라이언트 (클러스터 머신)가 메시지를 구독 할 수 있습니다.
게시/구독 시스템을위한 두 가지 설계 모드, 즉 밀고 당기는 두 가지 디자인 모드가 있습니다.
푸시 : 서버는 가입 된 모든 클라이언트에게 데이터 업데이트를 적극적으로 보냅니다.
풀 : 클라이언트는 최신 데이터를 얻기위한 요청을 적극적으로 시작합니다. 일반적으로 클라이언트는 시간이 정해진 폴링 및 풀링 방법을 채택합니다.
Zookeeper는 Push and Pull의 조합을 사용합니다. 다음과 같이 :
클라이언트는 서버가주의를 기울여야하는 노드를 등록하기를 원합니다. 노드의 데이터가 변경되면 서버는 해당 클라이언트에게 감시자 이벤트 알림을 보냅니다. 클라이언트 가이 메시지 알림을받은 후에는 최신 데이터 (푸시 앤 풀로 결합)를 얻으려면 서버로 적극적으로 이동해야합니다.
3.2 이름 지정 서비스
이름 지정 서비스는 분산 시스템에서 일반적인 유형의 시나리오입니다. 분산 시스템에서 이름 지정 서비스를 사용하여 클라이언트 응용 프로그램은 지정된 이름을 기반으로 리소스 또는 서비스, 제공자 등의 주소와 같은 정보를 얻을 수 있습니다. 이름 지정된 엔티티는 일반적으로 클러스터의 기계, 제공된 서비스, 원격 개체 등을 통합 할 수 있습니다.
그 중에서 가장 일반적인 것은 일부 분산 서비스 프레임 워크 (RPC, RMI)의 서비스 주소 목록입니다. Zookeepr에서 순차적 노드를 만들면 이름으로 사용할 수있는 전 세계적으로 고유 한 경로를 쉽게 만들 수 있습니다.
Zookeeper의 이름 지정 서비스는 전 세계적으로 고유 한 ID를 생성합니다.
3.3 분산 조정/알림
Zookeeper는 고유 한 감시자 등록 및 비동기식 알림 메커니즘을 보유하고 있으며, 이는 분산 환경에서 다른 시스템과 다른 시스템 간의 알림 및 조정을 깨닫고 데이터 변경의 실시간 처리를 실현할 수 있습니다. 사용법은 일반적으로 다른 클라이언트가 ZK에 동일한 Znode를 등록하여 Znode의 변경 사항 (Znode 자체 및 자식 노드 포함)을 듣습니다. Znode가 변경되면 구독 한 모든 클라이언트는 해당 감시자 알림을 받고 해당 처리를 수행 할 수 있습니다.
ZK의 분산 조정/알림은 분산 시스템과 기계 간의 일반적인 통신 방법입니다.
3.3.1 심장 박동 탐지
기계 간의 하트 비트 감지 메커니즘은 분산 환경에서 서로 다른 기계 (또는 프로세스)가 서로가 정상적으로 실행되는지 여부를 감지해야 함을 의미합니다. 예를 들어, 기계 A는 기계 B가 정상적으로 실행되는지 여부를 알아야합니다. 전통적인 발전에서 우리는 일반적으로 호스트가 서로 직접 핑을 할 수 있는지 판단합니다. 더 복잡하다면, 우리는 기계 사이에 긴 연결을 설정하고 TCP 연결의 고유 한 심장 박동 탐지 메커니즘을 통해 상위 수준의 기계의 심장 박동 감지를 실현할 것입니다. 이것들은 매우 일반적인 심장 박동 탐지 방법입니다.
ZK를 사용하여 분산 기계 (프로세스) 간의 하트 비트 감지를 구현하는 방법을 살펴 보겠습니다.
ZK의 임시 노드의 특성에 따라 다른 프로세스는 ZK의 지정된 노드 아래에 임시 자식 노드를 생성 할 수 있습니다. 다른 프로세스는이 임시 아동 노드를 기반으로 해당 프로세스가 살아 있는지 직접 판단 할 수 있습니다. 이러한 방식으로, 감지 및 감지 된 시스템은 직접 관련 될 필요는 없지만 ZK의 특정 노드를 통해 관련되어 시스템 커플 링이 크게 줄어 듭니다.
3.3.2 작업 진행 보고서
공통 작업 배포 시스템에서, 일반적으로 작업이 실행을 위해 다른 컴퓨터에 배포 된 후에는 작업 실행의 진행 상황을 분배 시스템에 실시간으로보고해야합니다. 이번에는 ZK를 통해 달성 할 수 있습니다. ZK에서 노드를 선택하고 각 작업 클라이언트는이 노드 아래에서 임시 하위 노드를 생성하여 두 기능을 달성 할 수 있습니다.
임시 노드가 존재하는지 판단하여 작업 기계가 살아남는 지 여부를 결정하십시오.
각 작업 머신은이 임시 노드에 작업 실행 진행 상황을 실시간으로 작성하여 중앙 시스템이 실시간으로 작업 실행 진행 상황을 얻을 수 있도록합니다.
3.4 마스터 선거
마스터 선거는 Zookeeper의 가장 일반적인 응용 시나리오라고 할 수 있습니다. 예를 들어, HDFS의 활성 나 메노 노드 선거, 원사의 활성 자원 제수 선거 및 HBase에서 활성 HMASTER 선거.
마스터 선거의 요구에 부응하여 일반적으로 공통 관계 데이터베이스에서 기본 키 기능을 선택할 수 있습니다. 마스터가되는 기계가 동일한 기본 키 ID의 레코드를 데이터베이스에 삽입하면 데이터베이스가 기본 주요 충돌 점검을 수행하는 데 도움이됩니다. 즉, 하나의 컴퓨터만이 데이터베이스에 성공적으로 데이터를 삽입 할 수 있다고 생각합니다.
관계형 데이터베이스의 주요 주요 특성에 의존하면 실제로 유일한 마스터가 클러스터에서 선출 될 수 있습니다.
그러나 현재 선출 된 주인이 죽었다면 어떻게해야합니까? 주인이 죽었다고 누가 말해 줄까요? 분명히, 관계형 데이터베이스는이 이벤트를 알려줄 수 없습니다. 그러나 동물원 키퍼는 그것을 할 수 있습니다!
Zookeepr의 강력한 일관성을 사용하면 노드를 생성하면 분산 된 높은 동시성에서 전역의 독창성을 보장 할 수 있습니다.
즉, 여러 클라이언트가 동시에 동일한 임시 노드를 동시에 작성하도록 요청하면 결국 하나의 클라이언트 요청 만 성공적으로 생성 할 수 있습니다. 이 기능을 사용하여 분산 환경에서 마스터 선거를 쉽게 수행 할 수 있습니다.
노드를 성공적으로 생성 한 클라이언트가 위치한 기계가 마스터가됩니다. 동시에 노드를 성공적으로 생성하지 않은 다른 클라이언트는 현재 마스터 머신이 살아 있는지 모니터링하기 위해 노드의 하위 노드 변경에 대한 감시자를 등록합니다. 현재 마스터가 사망 한 것으로 밝혀지면 다른 고객이 재선됩니다.
이것은 역동적 인 마스터 선거를 가능하게합니다.
3.5 분산 잠금
분산 잠금 장치는 분산 시스템 간의 공유 리소스에 대한 동기식 액세스를 제어하는 방법입니다.
분산 잠금 장치는 독점 잠금 및 공유 잠금으로 나뉩니다.
3.5.1 독점 잠금
글쓰기 잠금 또는 독점 잠금으로도 알려진 독점 잠금 장치 (짧은 X 잠금).
트랜잭션 T1이 데이터 객체 O1에 독점 잠금을 추가하면 전체 잠금 기간 동안 트랜잭션 T1 만 O1을 읽고 업데이트 할 수 있으며 T1이 독점 잠금을 방출 할 때 까지이 데이터 객체에서 모든 유형의 작업을 수행 할 수 없습니다.
독점 잠금의 핵심은 하나의 트랜잭션 만 현재 잠금을 취득하는 방법이며, 잠금 장치가 릴리스되면 잠금을 취득하기 위해 대기하는 모든 트랜잭션에 알릴 수 있음을 알 수 있습니다.
Zookeeper를 사용하여 독점적 인 잠금을 달성하는 방법은 무엇입니까?
잠금을 정의하십시오
Zookeeper의 Znode는 자물쇠를 나타낼 수 있습니다. 예를 들어, /독점 _lock /잠금 노드는 잠금으로 정의 될 수 있습니다.
자물쇠를 얻으십시오
위에서 언급했듯이 Zookeeper의 Znode를 잠금으로 고려하고 Znode를 만들어 잠금을 얻는 것이 달성됩니다. 모든 클라이언트는 /Exclusive_Lock /Lock으로 이동하여 임시 자식 노드 /독점 _Lock /잠금 UNDEND /PEREVERUBIN_LOCK 노드를 만듭니다. Zookeeper는 모든 고객 중 하나만 성공적으로 만들어 질 수 있도록하고 고객이 잠금을 얻은 것으로 간주 될 수 있습니다. 동시에, 잠금을 얻지 못한 모든 클라이언트는 실시간으로 잠금 노드 변경에서 청취하기 위해 /Exclusive_Lock 노드에서 아동 노드 변경에 대한 감시자를 등록해야합니다.
잠금을 해제하십시오
/exclusive_lock /lock은 임시 노드이므로 두 경우 모두 잠금을 해제 할 수 있습니다.
현재 잠금 장치를 얻는 클라이언트 시스템이 실패하거나 다시 시작되면 임시 노드가 삭제되고 잠금이 해제됩니다.
비즈니스 로직이 정상적으로 실행 된 후 클라이언트는 생성 된 임시 노드를 적극적으로 삭제하고 잠금을 해제합니다.
어떤 상황에서 잠금 노드가 제거 되더라도, 동물원 키퍼는 Node Change Watcher를 등록한 모든 클라이언트에게 /Exclusive_Lock 노드를 듣습니다. 알림을받은 후,이 클라이언트는 분산 잠금 획득을 다시 시작하여 "잠금의 획득"을 반복합니다.
3.5.2 공유 잠금
공유 잠금 장치 (잠금 장치, S 잠금이라고도 함), 읽기 잠금이라고도합니다. 트랜잭션 T1이 데이터 객체 O1에 공유 잠금을 추가하면 T1이 O1 만 읽을 수 있으며 다른 트랜잭션은 동시에 공유 잠금을 추가 할 수 있습니다 (독점 잠금이 아님). O1은 O1의 모든 공유 잠금 장치가 해제 될 때까지 독점 잠금에만 추가 할 수 있습니다.
요약 : 여러 트랜잭션은 객체에 대한 공유 잠금 장치를 동시에 얻을 수 있습니다 (동시에 읽으십시오). 공유 잠금 장치가 있으면 독점 잠금 장치를 추가 할 수 없습니다 (독점 잠금 장치가 쓰기 잠금 장치이기 때문에)
4. 대규모 분산 시스템에서 Zookeeper의 적용
Zookeeper의 일반적인 응용 시나리오가 이전에 소개되었습니다. 이 섹션에서는 공통 빅 데이터 제품 Hadoop 및 HBase에서 Zookeeper의 응용 프로그램을 소개하여 모든 사람이 Zookeeper의 분산 응용 프로그램 시나리오를 더 잘 이해할 수 있도록 도와줍니다.
4.1 Hadoop에서 Zookeeper의 적용
Hadoop에서 Zookeeper는 주로 HDFS의 Namanode 및 Yarn 's ResourceManager's HA를 포함하여 HA (Hive 가용성)를 구현하는 데 사용됩니다. 동시에, 원사에서 Zookeepr은 응용 프로그램의 작동 상태를 저장하는 데 사용됩니다.
HA를 구현하기 위해 Zookeepr을 사용하는 원리는 HDFS의 Namanode 및 Yarn의 ResourceCemanager에서 동일 하므로이 섹션에서는 원사와 함께 소개합니다.
동물원 키퍼
위 그림에서 볼 수 있듯이, 원사는 주로 Resourcemanager (RM), Nodemanager (NM), ApplicationMaster (AM) 및 컨테이너의 네 가지 부분으로 구성됩니다. 그들 중 가장 핵심은 ResourcEmanager입니다.
ResourcEmanager는 클러스터의 모든 리소스의 통합 관리 및 할당을 담당합니다. 또한 각 노드 (NODEMANAGER)에서 리소스보고 정보를 수신하고 특정 정책에 따라이 정보를 각 응용 프로그램 (응용 프로그램 관리자)에 할당합니다. 각 애플리케이션의 응용 프로그램 마스터 정보, NODEMANAGER 정보 및 리소스 사용 정보를 유지 관리합니다.
HA를 구현하려면 다수의 ResourcEmanagers는 공존해야하며 (일반적으로 2 개), 하나의 ResourceManager 만 활성 상태에 있고 다른 Resourcemanager만이 대기 상태에 있습니다. 활성 노드가 제대로 작동 할 수없는 경우 (예 : 기계 다운 타임 또는 재시작) 대기는 새로운 활성 노드를 생성하기 위해 경쟁합니다.
4.2 메인 및 백업 스위치
원사가 여러 자원 관리자 사이에 마스터 보조금 전환을 구현하는 방법을 살펴 보겠습니다.
1. 잠금 노드를 만듭니다. Zookeeper에는 A /Yarn-Leader-Oxection /AppCluster-Yarn Lock 노드가 있습니다. 모든 ResourcEmanagers가 시작되면 잠금 하위 노드를 작성하기 위해 경쟁합니다. 이 노드는 임시 노드입니다.
Zookeepr는 결국 하나의 ResourceManager만이 성공적으로 생성 할 수 있도록 할 수 있습니다. 성공적으로 생성 된 ResourcEmanager는 활성 상태로 전환되며 성공하지 못한 사람들은 대기 상태로 전환됩니다.
동물원 키퍼
현재 클러스터의 ResourcEmanager2가 활성화되어 있음을 알 수 있습니다.
감시자 모니터를 등록하십시오
대기 상태의 모든 ResourcEmanagers는/YARN-LEADER-OLECTION/APPCLUSTER-YARN/ActiveBreadCrumb 노드에 대한 노드 변경에 대한 감시자를 등록합니다. 임시 노드의 특성을 사용하여 활성 상태에서 ResourcEmanagers의 작동을 빠르게 감지 할 수 있습니다.
메인 및 백업 스위치
활성 상태 ResourceCemanager가 가동 중지 또는 재시작과 같은 예외를 경험하면 Zookeeper에 연결된 클라이언트 세션이 유효하지 않으므로/Yarn-Leader-Exection/AppCluster-Yarn/ActiveBreadCrumb 노드가 삭제됩니다. 현재 대기 상태의 다른 ResourcEmanagers는 Zookeeper 서버에서 Watcher 이벤트 알림을받은 다음 1 단계의 작동을 반복합니다.
위의 것은 Zookeeper를 사용하여 ResourcManager의 HA를 실현하는 ResourcEmanager의 메인 및 백업 전환을 실현하는 과정입니다.
HDFS에서 Namenode HA의 구현 원리는 원사에서 ResourcManager HA의 구현 원리와 동일합니다. 잠금 노드는/hadoop-ha/mycluster/activebreadcrumb입니다.
4.3 ResourcEmanager 상태 저장소
ResourcEmanager에서 RMStatestore는 응용 프로그램 및 시도 정보, 대표 토큰, 버전 정보 등을 포함하여 RM의 내부 상태 정보를 저장할 수 있습니다. RMStatestore의 대부분의 상태 정보는 리소스 사용법과 같은 컨텍스트 정보에서 재구성하기 쉽기 때문에 스토리지를 유지할 필요가 없습니다. 스토리지 설계 체계에서는 다음과 같이 각각 3 가지 가능한 구현이 제공됩니다.
메모리 구현을 기반으로 일반적으로 일상 개발 및 테스트에 사용됩니다.
HDFS와 같은 파일 시스템 기반 구현.
사육장 구현을 기반으로합니다.
이러한 상태 정보의 데이터 양은 크지 않기 때문에 Hadoop은 공식적으로 동물원에 기반한 상태 정보의 저장을 실현할 것을 권장합니다. ZooKeepr에서 ResourcEmanager의 상태 정보는 /rmstore의 루트 노드 아래에 저장됩니다.
동물원 키퍼
RMAPPROOT 노드는 각 응용 프로그램과 관련된 정보를 저장하고 RMDTSECRETManagerRoot는 보안 및 기타 정보와 관련된 정보를 저장합니다. 각 활성 상태의 ResourcEmanager는 초기화 단계에서 Zookeeper의 이러한 상태 정보를 읽고 이러한 상태 정보를 기반으로 그에 따라 계속 처리합니다.
4.4 요약 :
Hadoop에서 Zookeepr의 주요 응용 프로그램은 다음과 같습니다.
hdfs의 namenode와 원사의 ResourceManager의 ha.
rmstatestore 상태 정보를 저장하십시오
5. HBASE에서 Zookeeper의 적용
HBASE는 주로 Zookeeper를 사용하여 Hmaster 선거 및 마스터 슬립 스위칭, 시스템 결함 공차, 루트 지역 관리, 지역 상태 관리 및 분산을 실현합니다.
분할 작업 관리 등
5.1 H 마스터 선거 및 주요 백업 스위치
Hmaster 선거 및 마스터 지원 스위칭의 원칙은 HDFS의 Namenode 및 원사의 자원 관리자와 동일합니다.
5.2 시스템 오류 공차
HBase가 시작되면 각 RegionServer는 Zookeeper의/hbase/rs 노드 아래에서 정보 노드를 생성합니다 (이 노드는/hbase/rs/[hostname]과 같은 노드를 "RS 상태 노드"라고합니다). 동시에 HMaster는이 노드를 등록하고 듣습니다. 지역 서버가 실패하면 Zookeeper는 일정 기간 동안 하트 비트를 허용 할 수 없기 때문에 ReceationServer 서버에 해당하는 RS 상태 노드를 삭제합니다 (즉, 세션은 유효하지 않음).
동시에, HMaster는 Zookeeper로부터 NodeDelete 알림을받을 수 있으므로 노드가 연결이 끊어지고 즉시 결함이 발생하는 작업을 시작합니다.
HBase가 HBASE가 직접 Hmaster를 지역 서버 모니터링에 책임을지게하지 않습니까? Hmaster가 심장 박동 메커니즘을 통해 지역 서버의 상태를 직접 관리하면 클러스터가 커지면 Hmaster의 관리 부담이 무거워지고 실패 할 수 있으므로 데이터를 지속해야합니다. 이 경우 Zookeeper가 이상적인 선택이됩니다.
5.3 루트 지역 관리
HBase 클러스터의 경우 데이터 저장소의 위치 정보는 메타 데이터 영역, 즉 루트 영역에 기록됩니다. 클라이언트가 새로운 요청을 시작하고 데이터의 위치를 알아야 할 때마다 루트 지역을 쿼리하며 루트 지역의 위치는 Zookeeper에 기록됩니다 (기본적으로 Zookeeper /HBase /Meta-region-Server Node에 기록됩니다).
지역의 수동 이동, 재 장전 밸런싱 또는 루트 지역 서버의 실패와 같은 루트 영역이 변경되면 Zookeeper를 통해 이러한 변경을 감지하고 일련의 해당 재해 복구 조치를 취하여 클라이언트가 항상 올바른 루트 영역 정보를 얻을 수 있도록 할 수 있습니다.
5.4 지역 관리
HBase의 영역은 종종 변경됩니다. 이러한 변경의 이유는 시스템 고장,로드 밸런싱, 구성 수정, 지역 분할 및 병합 등입니다. 지역이 움직이면 오프라인 및 온라인 프로세스를 통과합니다.
오프라인에서는 데이터에 액세스 할 수 없으며이 지역의 상태 변경은 글로벌 수준으로 알려져 있어야합니다. 그렇지 않으면 트랜잭션 예외가 발생할 수 있습니다.
대형 HBASE 클러스터의 경우 영역의 수가 100,000 또는 그 이상으로 높을 수 있습니다. 또한이 규모의 지역 주 경영진을 Zookeeper에게 맡기는 것이 좋습니다.
5.5 분산 된 분할 작업 관리
지역 서버 서버가 끊어지면, 지역 서버 서비스를 마이그레이션 할 때 새로 쓰여진 데이터의 일부가 HFile에 지속되지 않은 일부가 있기 때문에 WAL에서 여전히 메모리에있는 데이터 의이 부분을 복원하는 것이 중요합니다. 이 작업의 가장 중요한 단계는 Splitwal입니다. 즉, HMaster는 RegionServer 서버의 WAL을 가로 지르고 작은 조각으로 나누고 새 주소로 이동하고 로그를 재생해야합니다.
단일 지역 서버의 로그 볼륨이 비교적 크기 때문에 (GB의 로그가있는 수천 개의 영역이있을 수 있음) 사용자는 종종 시스템이 로그 복구 작업을 신속하게 완료 할 수 있기를 희망합니다. 따라서, 가능한 솔루션은 공동 프로세싱을 위해 WAL을 여러 지역 서버 서버에 처리하는이 작업을 할당하는 것이며, 이는 HMARS가 작업 할당을 완료하는 데 도움이되는 지속적인 구성 요소가 필요합니다.
현재 관행은 Zookeeper에서 분할 노드를 생성한다는 것입니다 (기본적으로 /hbase /splitwal 노드), "지역 서버가 목록의 노드에 어떤 영역을 처리하는지"와 같은 정보를 저장 한 다음 각 지역 서버는 작업을 수집하고 작업 실행이 성공적이거나 후속 단계를 계속하지 않기 위해 노드의 정보를 업데이트하기 위해 노드로 이동합니다. Zookeeper는 분산 클러스터에서 상호 알림 및 정보 지속성의 역할을 수행합니다.
5.6 요약 :
위의 것은 분산 조정 기능을 완료하기 위해 Zookeeper에 의존하는 HBase의 몇 가지 전형적인 시나리오입니다. 그러나 실제로 HBase는이 의존성보다 더 많은 것보다 더 많은 것을 가지고 있습니다. 예를 들어, Hmas
Zookeeper의 탁월한 분산 조정 기능과 우수한 알림 메커니즘으로 인해 HBase는 각 버전의 진화에 Zookeeper 응용 시나리오를 점점 더 추가했으며 트렌드 관점에서 두 사람은 점점 더 많은 교차로를 가지고 있습니다. HBase의 Zookeeper의 모든 작업은 org.apache.hadoop.hbase.zookeeper 패키지에 캡슐화됩니다. 관심있는 학생들은 스스로 공부할 수 있습니다.
위는 편집기가 소개 한 스프링 부팅 모듈입니다. 나는 그것이 당신에게 도움이되기를 바랍니다. 질문이 있으시면 메시지를 남겨 주시면 편집자가 제 시간에 답장을 드리겠습니다!