하둡이란?:

developer-woong.tistory.com/7

 

(하둡 기초) ep02_하둡에코시스템(Hadoop EcoSystem)

하둡의 역사에 대해 궁금하다면?! developer-woong.tistory.com/6 (하둡완벽설치!) ep01_하둡(Hadoop)의 역사, 등장 배경 데이터 시대 2013, 2014년 기준으로 뉴욕증권거래소에서는 하루 4.5테라바이트의 데이터

developer-woong.tistory.com

 

고가용성(HA:High Availability):

고가용성이란 서버와 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 말한다.

 

고가용성의 등장배경과 필요성:

하둡1에서의 HDFS(Hadoop Distributed FileSystem)는 네임노드 메타데이터를 다수의 파일시스템에 복제하는 방식, 보조 네임노드를 사용하여 체크포인트를 생성하는 방식으로 데이터의 손실을 방지하지만, 파일시스템의 고가용성을 궁극적으로 지원하지는 않는다.

 

이는 네임노드가 여전히 단일 고장점(SPOF:Single Point Of Failure)이기 때문이다. 네임노드에 장애가 발생하면 맵리듀스 잡을 포함, 모든 클라이언트가 파일의 읽기, 쓰기, 조회가 모두 불가능해진다. 이는 네임노드는 메타데이터와 파일 블록의 매핑 정보를 보관하는 유일한 저장소이기 때문이다. (= 네임노드의 이중화 필요)

 

 

HDFS(Hadoop Distributed FileSystem)란? - 하둡 1버전에서의 HDFS:

developer-woong.tistory.com/8

 

(하둡가이드) ep03_하둡 분산 처리 파일시스템(HDFS:Hadoop Distributed FileSystem)

하둡의 주요 구성 중 핵심 프레임워크 중 하나인 HDFS에 대해 알아본다. 하둡이란? developer-woong.tistory.com/7 (하둡완벽설치!)ep02_하둡에코시스템(Hadoop EcoSystem) 하둡의 역사에 대해 궁금하다면?! devel..

developer-woong.tistory.com


HDFS 네임노드에 문제 발생 시 재구동 과정(Not Support HA):

네임노드의 장애 복구를 위해 관리자는 파일시스템 메타데이터 복제본을 보유하고 있는 새 네임노드를 구동한 후 모든 데이터노드와 클라이언트에 새 네임노드를 사용하도록 알려주는 방식

 

- 새 네임노드는 네임스페이스 이미지를 메모리 상에 로드

 

- 에디트 로그(Edit Log, 변경 내역) 갱신

 

- 전체 데이터노드에서 블록 리포트를 받은 후 안전 모드를 벗어날 때까지 어떠한 요청도 처리 불가

 

하둡 2.x 릴리즈 버전의 HDFS 고가용성(HA):

위 문제의 해결을 위해 하둡 2.x 릴리즈부터 HDFS 고가용성(HA)를 지원한다.

고가용성은 활성대기(active-standby)상태로 설정된 한 쌍의 네임노드로 구성되는데 활성 네임노드(active namenode)에 장애 발생 시 대기 네임노드(standby namenode)가 역할을 이어 받아 중단 없이 클라이언트의 요청을 처리한다.

이러한 방식의 지원을 위해 HDFS의 구조를 변경하였다.

 

변경된 HDFS:

 

- 네임노드는 에디트 로그의 공유를 위해 고가용성 공유 스토리지를 반드시 사용해야한다. 대기 네임노드(Standby Namenode)가 활성화 시 우선적으로 기존 활성 네임노드(Active Namenode)의 상태의 동기화를 위해 공유 에디트 로그(Edit log, 변경 로그)를 읽고, 이어서 활성 네임노드(Active Namenode)에 새로 추가된 항목도 마저 읽는다

 

- 블록 매핑 정보는 디스크가 아닌 네임노드의 메모리에 보관되기 때문에 데이터 노드(Data Node)는 블록 리포트를 두 개의 네임노드에 보낸다.

 

- 클라이언트는 네임노드 장애를 사용자에게 투명한 방식으로 처리 가능하도록 구성해야 한다.

 

- 대기 네임노드(Standby Namenode)는 보조 네임노드(Secondary Namenode)의 역할을 포함하고, 활성 네임노드 네임스페이스(Active Namenode Namespace)의 체크포인트(Check Point) 작업을 주기적으로 수행해야 한다.

 

(* 활성 네임노드(Active Namenode)에 장애 발생 시 대기 네임노드(Standby Namenode)는 수십초 이내의 매우 빠른 시간으로 기존의 네임노드를 대체할 수 있는데, 활성과 대기 네임노드는 모두 최신 에디트 로그(Edit log, 변경 로그)와 실시간으로 갱신되어지는 블록 매핑정보를 메모리 상에 유지하고 있기에 가능하다. 실제 장애 복구 시간을 보면 대략 1분정도가 소요되는데 이는 시스템이 활성네임노드에 문제가 있다고 판단하는 것은 매우 신중해야하기 때문이다.)

 

 

(* 기존 하둡1버전에서의 HDFS의 구조가 궁금하다면 위 링크 참조!)

 

[하둡2.x 릴리즈버전 분산 파일시스템 고가용성의 구조(Hadoop Distributed FileSystem High Availability)QJM(QuorumJournalManager)방식

이미지 출저 http://pippisgoing.blogspot.com/2018/05/hadoop-2-hahigh-availability.html

 

고가용성 HDFS 주요 구성(Hadoop Distributed FileSystem High Availability):

   
저널노드(Journal node) - 하둡1버전은 네임노드에서만 에디트 로그, 즉, 변경 사항을 저장하였는데 하둡2버전 부터는 여러 서버에 에디트 로그를 복제해서 저장한다.

- 저널노드(데몬)는 에디트로그를 자신이 실행되는 서버의 로컬디스크에 저장한다.

- 네임노드는 클라이언트가 되어 저널노드에 접근 후 저장을 요청
(* 에디트 로그를 저장할 권한은 액티브 네임노드에게만 존재하고, 스탠바이 네임노드는 조회만 요청 가능)

- 저널노드는 최소 3대 이상의 서버에서 실행되야 하고, 홀수 단위로만 실행 가능하다.
(* 절반 이상의 저널노드가 동작 중이어야 에디트 로그를 파일이미지(fsimage)에 반영할 수 있기 때문 / 과반수 이상)

- 네임노드가 저널노드의 장애 발생에 영향을 받지 않기 위해선 (전체 저널노드 설치대수/2)+1 만큼 실행되어야 한다.
(* ex) 저널노드가 5대라면 최소 3대 이상의 저널노드가 실행되어야 한다.)

- 저널노드는 기본적으로 리소스를 적게 사용하기 때문에 네임노드, 잡트래커, 리소스매니저와 같은 데몬이 실행중인 서버에도 함께 구동이 가능하다.
주키퍼(Zookeeper) - 네임노드 HA 상태 정보를 저장하는 저장소

- 여러 서버들 중 어떤 서버가 액티브 네임노드인지 스탠바이 네임노드인지 선출 및 저장

- 분산시스템 코디네이터 역할
(* 애플리케이션들의 원할한 구동 환경을 위한 중재
분산 서버 간의 정보를 공유
서버의 상태변화를 타 노드들에게 전달 / ex) 서버 생성 및 삭제 등
서버의 모니터링 / ex) 오류로 인해 연결이 끊어진 노드 삭제 등
시스템관리, 분산 락 처리, 네이밍 서비스 등등의 서비스 제공
주키퍼(Zookeeper 더 알아보기) -> developer-woong.tistory.com/11)

- 주키퍼 마스터는 홀수 단위로 실행시킨다.

- 주키퍼 클라이언트의 요청에 주키퍼 마스터의 응답이 부재 시 다른 주키퍼 마스터에게 요청
(* 과반 정족수 이상으로 서버가 다운되었을 때, 서비스 중지 /
ex) 주키퍼 서버 2대 중 1대가 다운될 시에 바로 서비스 종료, 3대 중 1대가 다운되더라도 서비스 진행 -> 서버의 갯수를 홀수로 맞추는 이유)

ZKFC
(주키퍼 장애 컨트롤러ZookeeperFailoverController)
- 로컬 네임노드의 상태를 모니터링한다.

- 액티브 네임노드가 정상 상태이면 주키퍼 마스터에 대한 세션을 유지한다.

- 액티브 네임노드에 장애 발생 시, 이를 감지하여 자동적으로 zkfc와 주키퍼 마스터간의 세션을 종료하고 스텐바이 네임노드를 액티브 네임노드로 전환한 후 다운된 기존의 액티브 네임노드를 제거한다.
네임노드(Name Node) - 네임노드 내부에 있는 QJM(QuorumJournalManager)이 저널노드에 에디트 로그를 출력한다.
(* QJM: HDFS에서 구현하였고 에디트 로그 HA를 제공하기 위한 목적으로 설계되었으며 권장되는 옵션이다. QJM은 그룹의 저널노드를 실행, edit event는 대다수의 저널노드에 작성된다)

- 절반 이상의 저널노드가 실행되고 있어야 파일이미지(fsimage)에 에디트 로그를 반영 가능하다.

- 액티브 네임노드만이 저널노드에 에디트 로그를 쓸 수 있는 권한을 가지고, 스탠바이 네임노드는 저널노드에서 에디트 로그의 조회 및 파일이미지(fsimage)를 갱신할 수 있다.(= 보조네임노드를 실행할 필요가 없는 이유)
데이터노드(Data Node) - 액티브 네임노드와 스탠바이 네임노드 모두에게 블록 리포트를 전송한다.

- 액티브 네임노드에 오류 발생 시에도 곧바로 스탠바이 네임노드에 투입되어 기능 작동이 가능하다.

 

필요 지식:

 

얀(YARN)이란?

developer-woong.tistory.com/9

 

(하둡 기초) ep05_YARN이란?

하둡의 구성 요소 중 핵심 프레임워크인 Yarn에 대해 알아본다. 하둡이란? developer-woong.tistory.com/7 (하둡완벽설치!)ep02_하둡에코시스템(Hadoop EcoSystem) 하둡의 역사에 대해 궁금하다면?! developer-woo..

developer-woong.tistory.com

맵리듀스(MapReduce)란?

developer-woong.tistory.com/10

 

(하둡 기초) ep04_ MapReduce 맵리듀스란?

하둡 분산 파일시스템(HDFS)와 함께 핵심 구성 요소인 MapReduce에 관해 알아본다. 하둡이란? developer-woong.tistory.com/7 (하둡완벽설치!)ep02_하둡에코시스템(Hadoop EcoSystem) 하둡의 역사에 대해 궁금하다..

developer-woong.tistory.com

주키퍼(Zookeeper)란?

developer-woong.tistory.com/11

 

(하둡 기초) ep06_주키퍼(Zookeeper)란?

효과적인 분산 코디네이션 시스템을 위한 주키퍼(Zookeeper)에 대해 알아본다. 하둡이란?: developer-woong.tistory.com/7 (하둡 기초) ep02_하둡에코시스템(Hadoop EcoSystem) 하둡의 역사에 대해 궁금하다면?! d..

developer-woong.tistory.com

[참고1] Hadoop The Dfinitive Guide (하둡 완벽가이드 4판) - 톰 화이트 지음, 장형석, 장정호, 임상배, 김훈동 옮김

[참고2]brocess.tistory.com/194

[참고3]pippisgoing.blogspot.com/2018/05/hadoop-2-hahigh-availability.html

[참고4]eyeballs.tistory.com/251

[참고5]kadensungbincho.tistory.com/33?category=910848

 

자! 그럼 이제 본격적으로 서버 6대를 활용한 하둡 HA 클러스터 구축을 시작해보겠습니다!

감사합니다!!

developer-woong.tistory.com/13

 

(하둡 설치) ep00_필요 파일 준비 과정

서버 6대를 활용하여 하둡 고가용성(HA)모드로 클러스터를 구축한다. 하둡이란? developer-woong.tistory.com/7 (하둡 기초) ep02_하둡에코시스템(Hadoop EcoSystem) 하둡의 역사에 대해 궁금하다면?! developer-w..

developer-woong.tistory.com

 

반응형

+ Recent posts