HDFS Architecture Guide

by Dhruba Borthakur

1. Introduction

분산 파일 시스템. 기존 시스템과의 차이점 : highly falut-tolerant , 저가 하드웨어에 디플로이 가능.
HDFS 는 Apache Nutch web search engine project 의 인프라로 만들어짐.
Apache Hadoop subproject.

2. Assumptions and Goals

2.1 Hardware Failure

하드 페일은 예외라기 보다는 ‘표준’ 이다. HDFS 인스턴스는 수백, 수천의 서버로 구성되어 파일 시스템의 데이터를 저장한다.
많은 수의 컴퍼넌트가 있다는 사실, 각 컴퍼넌트가 non-trivial 한 실패 가능이 있다는 것은 HDFS 의 일부 컴퍼넌트가 항상 non-functional 있다는 것을 의미한다.
그러므로, 결함의 발견과 그것의 빠르고, 자동적인 복구는 HDFS 의 코어 설계 목적이다.

2.2 Streaming Data Access

HDFS 에서 도는 어플은 자신의 데이터 셑에 접근하는 스트리밍이 필요하다. 그것들은 일반 파일 시스템에서 도는 일반 목적의 어플이 아니다.
HDFS 는 일반 유저 사용이 아니라 배칭 프로세싱에 더 알맞게 설계되었다. 데이터 억세스의 낮은 레이턴시보다 high throughtput of data access 에 집중.
Posix 는 HDFS 에 타게팅된 어플에 필요없는 많은 요구조건을 강요하고 있다.
Posix 의 몇몇 키 영역에서의 의미론은 데이터 처리율을 높이는 데 상쇄되었다.

2.3 Large Data Sets

HDFS 에서 도는 프로그램은 기가 / 테라 바이트의 파일.  그러므로, HDFS는 큰 파일을 지원하도록 튜닝 되었음.
싱글 클러스터에서 높은 최종 데이터 밴드위스 와 수백개의 노드를 지원해야 함. 한 인스턴스에서 수천만개의 파일을 지원해야 함.

2.4 Simple Coherency Model

파일에 대해 “1회 쓰고 – 여러번 읽기” 모델 이 필요. 파일이 생성, 기록, 닫히면 변경이 불필요하다. 이 가정은 데이터 일관성 이슈를 간단히 하고, 높은 데이터 억세스 생산량을 가능케 한다. 맵 리듀스나 웹 크롤러는 이 모델에 완벽히 맞아 떨어진다.
향후 추가-기록 을 지원하는 계획이 있음.

2.5 “Moving Computation is Cheaper than Moving Data”

어플의 요청에 의한 계산은 자료가 가까이에 있으면 효율적이다. 특히, 이것은 데이터가 클때 그렇다. 이것은 네트워크 사용을 최소화하고 시스템 성능을 증가시킨다. 가정은 이렇다. 데이터 가까이 컴퓨테이션을 이동하는 게 데이터를 이동하는 것보다 종종 낫다는…
HDFS 는 이렇게 데이터 가까이 어플리케이션을 가까이 가져가는 인터페이스를 제공한다.

2.6 Portability Across Heterogeneous Hardware and Software Platforms

플랫폼 간 이동이 쉽다.

3. NameNode and DataNodes

HDFS 는 마스터/슬레이브 아키텍쳐.
한개의 네임노드 (마스터 서버) +  여러개의 데이터 노드(보통 클러스터에서 노드당 한개), 노드에 붙은 스토리지 관리.
HDFS는 파일 시스템 namespace 를 노출하여 유저 데이터가 파일에 저장되도록 허용함.
내부적으로 한 파일은 하나이상의 블럭으로 나뉘고 이 블럭들은 데이터 노드들의 세트에 저장.
> 네임노드는 file system namespace operation 을 파일이나 폴더를 열고/닫고/리네임 하듯 함.
또한, 데이터노드에 블럭을 매핑하는 결정을 한다.
> 데이터 노드는 클라이언트로부터의 읽기/쓰기 요청에 대응할 책임이 있음.
데이터 노드는 블락생성/삭제/복제 등을 수행.

이 노드들은 머신에서 돌도록 설계된 소프트웨어의 일부임. 이 머신들은 GNU/Linux .. 보통.
자바로 쓰여짐. 자바를 지원하면 노드들을 돌릴 수 있음. 자바가 포터블성이 좋으므로 여러 머신에서 동작 가능.
전형적인 디플로이는 전적으로 네임노드 소트트웨어를 돌림. 각각의 다른 머신은 한 데이터노드를 돌림.
여러 노드를 한 머신에서 돌리는 것이 구조상 가능하지만 실제로는 적다.

네임노드가 하나인 것은 구조를 간단히 해준다. 이 네임노드는 메타데이터 등을 담는 중재자 역할.
유저 데이터는 네임노드를 통해 ‘절대’ 흐르지 않음.

4. The File System Namespace

기존 파일 구성 체계 지원. 디렉토리 생성 가능.  파일을 생성, 이동, 리네임 등 기존 체계와 비슷.
하지만 유저 쿼타를 구현하지 않음. 하드/소프트 링크 지원 안함.  하지만, HDFS 아키텍춰는 이런 구현을 배제하지는 않음.

네임노드는 파일 시스템 네임스페이스를 유지한다. 파일 시스템 네임공간의 변화는 네임노드에 의해 기록된다. 어플이 복제의 수를 규정. 파일의 복제 갯수는 그 파일의 replication factor 라고 함.  이 정보는 네임노드에 저장됨.

5. Data Replication

HDFS 는 큰 클러스터에 큰 파일을 여러 머신에 안정적으로 저장하게 설계되어 있음. 블락의 연속으로 파일 저장 ;
마지막 블락을 제외한 모든 블락은 같은 크기.
파일의 블락은 fault tolerance 를 위해 복제됨. 블락 크기와 복제팩터은 파일 별로 조절 가능. 어플리케이션이 파일의 복제수를 규정.
복제팩터는 파일 생성시에 규정 가능하고 나중에 바뀔 수 있다.
파일은 한번-쓰고 항상 한 writer 를 갖는다.

네임노드는 모든 블락의 복제에 관해 결정을 내림. 주기적으로 핫빝과 블락 레포트를 데이터노드로 부터 받음.
핫빝의 영수증은 잘 기능한다는 걸 의미.
레포트는 데이터노드의 모든 블락의 리스트를 포함함.

5.1 Replica Placement : The First Baby Steps

복제는 신뢰성/성능에 매우 중요.  복제 최적화는 HDFS의 차별화 요소. 또한 튜닝과 경험 필요.
랙 인식 복제의 목적은 데이터 신뢰성, 가용성, 밴드폭 활용을 향상시키기 위함.
현재 복제 정책의 구현은 이 방향의 첫번째 노력이다. 단기 목표는 제품 시스템에서 검증, 행동 연구, 더 복잡한 정책 연구 등이다.

대규모 HDFS 인스턴스는 여러 랙에 걸쳐 분산된다. 다른 랙의 두 노드사이의 통신은 스위치를 통해야 한다. 대부분의 경우 같은 랙 머신간의 네트웤 밴드폭은 다른 랙 사이보다 크다.

네임노드는 각 데이터노드가 속한 랙 아이디를 ‘하둡 랙 인지(Awareness)’ 에서 정하는 프로세스에 따라 결정한다.
간단하지만 최적은 아닌 정책이 복제를 유니크한 랙에 둔다.
이것은 랙 전체가 페일날 때 데이터 유실을 예방하고 데이터 읽기작업에 여러 랙으로부터의 밴드폭을 허용한다.
이 정책은 복제를 골고루 분산시켜 콤포넌트 실패에 로드 발란스를 쉽게 한다. 하지만, 이 방법은 쓰기작업이 여러 랙에 블락을 옮기는 것을 막아야하기 때문에 쓰기 비용을 늘린다.

일반적인 경우 복제계수가 3이면 HDFS의 원칙은 하나를 로컬랙의 한 노드에 놓고, 다른 건 다른 랙의 노드에, 세번째는 다른 랙의 다른 노드에 놓는다.
랙 페일의 가능성은 노드 페일보다 훨씬 적다. 이 원칙은 데이터 신뢰도와 가응성을 해치지 않는다.
하지만, 3개가 아닌 2 랙에 분리되어 있어 데이터 읽을 때의 밴드폭은 줄여준다. 또한, 랙에 골고루 분산시키지는 않는다.
이 원칙은 데이터 신뢰성과 읽기 성능을 떨어뜨리지 않으면서 쓰기 퍼포먼스를 향상시킨다.

여기서 기술된 현재의 디폴트 원칙은 진행 중임.

5.2 Replica Selection

글로벌 밴드폭 소비와 읽기 레이턴시를 최소화하기 위해 HDFS 는 리더에 가장 가까운 복제본으로부터 읽어야 한다?.
리더 노드와 같은 랙에 복제본이 있으면 그놈이 읽기 요청을 만족하는 것이 바람직함. 클러스터가 여러 데이터 센터로 펼쳐지면 로컬 데이터센터에 있는 복제본은 어느 원격 복제본보다 우선된다.

5.3 Safe Mode

시작 시 네임노드는 ‘안전 모드’ 로 들어간다. 이때 복제 작업 없음. 네임노드가 Heartbeat & Blockreport 메시지를 데이터노드로부터 받는다. 블락레포트는 한 데이터노드가 호스팅하는 블록들의 리스트를 담고 있다. 각 블럭은 복제본의 정해진 최소 수를 갖고 있다.
블락은 네임노드에 최소개수가 체크인하면 안전하게  복제됐다고 간주된다. 안전하게 복제된 복제본의 일정 퍼센트가 체크인하고 (추가 30초 ) 후에 안전모드에서 나온다. 그리고나서 정해진 숫자 이하의 블락을 갖는 데이터블록을 결정한다.
그리고나서 네임노드는 이 블락을 데이터노드에 복제한다.

6. The Persistence of File System Metadata

HDFS namespace 는 네임노드에 의해 저장된다.
네임노드는 현재 파일 시스템 메타데이터의 변화를 끊임없이 기록하기 위해 EditLog라 불리는 트랜잭션 로그를 사용한다.
예를 들어 새로운 파일을 생성할 때 네임노드는 이것을 가리키는 에딧로그에 레코드를 삽입한다. 복제 팩터를 바꾸는 것도 비슷.
네임노드는 수정로그 저장에 로컬 호스트 OS 파일 시스템을 이용한다.
파일 블록의 맵핑을 포함한 파일 시스템 이름공간 전체는 FsImage 라는 파일에 저장된다.
이 파일 역시 네임노드의 로컬 파일 시스템에 파일로 저장된다.

네임노드는 전체 파일 시스템 이름공간의 이미지와 파일 블록맵을 ‘메모리’에 띄운다. 이 키 메타데이터 아이템은 작게 설계되어 4기가의 램도 충분하다.
네임노드가 기동할 때 FsImage 와 EditLog 를 디스크에서 읽고 EditLog로 부터의 모든 트랜잭션을 FsImage의 인-메모리 객체에 적용하고 이 새로운 버전을 디스크의 새로운 FsImage 로 플러시아웃 한다.
그리고나서 기존의 EditLog 를 (반영이 되었으므로) 없앤다.
이 과정을 ‘체크포인트’ 라고 한다.
현재 구현에서는 체크포인트는 네임노드가 기동할 때만 일어난다. 향후에는 주기적으로 할 계획이다.

데이터 노드는 HDFS 데이터를 로컬 파일시스템에 저장한다. 데이터노드는  HDFS 에 대해 모른다.
단지 파일의 블럭을 로컬 파일 시스템에 저장할 뿐이다. 모든 파일을 같은 디렉토리에 생성하지 않는다. 대신, ‘자기발견 heuristic’ 을 사용하여 디렉토리당 최적의 파일 수를 결정하고 적당히 하위 디렉토리를 만든다. 모든 파일을 같은 디렉토리에 놓는 것은 적합하지 않다. (파일 시스템 문제)
데이터노드가 기동시 로컬 파일 시스템을 스캔하고 데이터 블록의 리스트를 만들고 이 레포트를 네임노드에 보낸다.
이것은 ‘블럭 레포트’ 이다.

7. The Communication Protocols

모든 HDFS 통신은 TCP/IP 위에 놓여진다. 클라이언트는 네임노드 머신위에 TCP 포트 연결을 확보하여 네임노드와 ClientProtocol 을 통신한다.
데이터노드는 네임노드와 ‘데이터노드 프로토콜’ 을 이용하여 소통한다.
RPC (remote procedure call) 추상화는 클라이언트 / 데이터노드 프로토콜 양쪽을 랩핑한다.
설계상, 네임노드는 어떤 RPC 도 초기화하지 않는다. 대신 데이터노드나 클라이언트에 의해 요청된 RPC 에 응답할 뿐.

8. Robustness

HDFS 의 주된 목적은 실패가 나더라도 데이터를 안정적으로 저장하는 것.
3가지 실패.

8.1 Data Disk Failure, Hearbeats and Re-Replication

각 데이터노드는 네임노드에게 핫빗 메시지를 주기적으로 보냄. 네트워크 파티션은 데이터노드의 섭셋이 네임노드와 연결을 잃게 할 수 있다. 네임노드는 최근에 핫빗을 안 보낸 데이터노드를 죽은 것으로 간주하고 더 이상의 IO 를 보내지 않는다. 죽은 노드에 기록된 데이터는 HDFS 에서 접근할 수 없다. 데이터노드의 죽음은 블럭의 복제 팩터가 내려가게 한다. 네임노드는 끊임없이 어떤 블락이 복제가 필요한 지 추적한다.
재-복제의 필요성이 여러 이유에 의해 제기된다 : 데이터노드가 접근불가,
복제본이 상한경우, 하드 디스크 페일 또는 복제 팩터 증가.

8.2 Cluster Rebalancing

HDFS 구조는 데이터 재균형 계획과 호환됨. 이것은 데이터노드의 빈 공간이 어느 레벨 이하로 내려가면 자동으로 다른 데이터노드로부터 옮겨온다.  어떤 파일에 대해 갑자기 높은 요구가 생기면 스킴은 동적으로 추가의 복제를 생성하고 클러스터의 다른 데이터와 재-균형할 수 있다.
이런 재균형은 아직 ‘미 구 현’ ..

8.3 Data Integrity

데이터노드로부터 가져온 블락이 손상되었을 가능성이 있다.  원인은 스토리지 이상, 네트워크 부실, 소프트웨어 버그.
클라이언트는 첵섬을 구현한다.
클라이언트가 HDFS 파일을 생성하면 각 블럭의 첵섬을 계산하여 HDFS 네임 공간에 히든 파일로 저장한다.
클라이언트가 데이터를 받을 때 확인.
틀리면 그 블럭을 다른 복제본에서 가져온다.

8.4 Metadata Disk Failure

FsImage & EditLog 는 중앙 데이터 구조임. 이 파일이 망가지면 HDFS 인스턴스가 기능 정지하게 됨.
이런 이유로 네임노드는 이 파일들을 여러 카피 유지하도록 함.
이 파일이 수정되면 각각의 복사본이 싱크되게 함.
이런 싱크 작업은 초당 트랜잭션 정도를 줄일 수 있다.
하지만, 메타데이터가 큰 것은 아니기 때문에 이런 성능저하는 수용할 만 하다.
네임노드가 재 시작할 때 최근의 파일들을 이용한다.

HDFS 클러스터에서는 네임노드 머신이 페일나는 한 지점이다. 네임노드가 페일나면 매뉴얼 작업이 필요하다.
현재, 자동 재시작과 네임노드의 페일오버시 다른 머신으로 이전은 지원되지 않는다.

8.5 Snapshots

특정 시간의 데이터의 카피 저장을 지원.  쓰임은 타임머쉰.. 에러 나기 전 시간으로 되돌림.  향후 기능.

9. Data Organization

9.1 Data Blocks

HDFS 는 큰 파일을 지원하기 위해 설계 되었음. 호환되는 어플은 큰 데이터 세트를 다룬다.
이 어플들은 데이터를 한번 쓰지만 한번 이상 읽고 이러한 읽기는 스트리밍 속도를 만족하는 것이 필요하다.
HDFS는 1번쓰고 여러번 읽는 개념을 지원한다. 전형적인 블럭 사이즈는 64 메가 바이트.
그러므로 64씩 잘라지고 다른 데이터 노드에 자리잡는다.

9.2 Staging

파일을 생성하라는 클라이언트 요청은 네임노드에 즉시 닿지 않는다.
실제로, 초기에 HDFS 클라이언트는 파일 데이터를 임시 로컬 파일에 캐시한다.
어플 쓰기는 이 임시 로컬 파일에 투명하게 redirect 된다.
로컬 파일이 블럭 사이즈만큼 데이터를 쌓게 되면 클라이언트는 네임노드에 컨택한다.
네임노드는 파일 이름을 파일시스템 위계에 넣고 데이터블럭을 잡는다.
클라이언트 요청에  네임노드는 데이터노드의 아이디와 최종 데이터 블록을 갖고 응답한다. 그리고나서 클라이언트는 임시파일에서 데이터 블럭을 지운다.
파일이 닫히면, 남은 데이터는 데이터노드로 옮겨진다. 그리고, 클라이언트는 네임노드에 파일이 닫혔다고 한다.
이때, 네임노드는 영구 공간에 파일생성 작업을 커밋한다.
파일이 닫히기전에 네임노드가 죽으면 파일은 잃어버린다.

위의 접근방식은 어플의 특성을 고려하여 세심히 설계 되었다. 이 어플들은 파일에 대해 스트리밍 쓰기가 필요하다. 클라이언트가 클라이언트 측 버퍼링 없이 원격파일에 직접 쓰면 네트워크 속도와 congestion in the network 는 작업에 상당히 영향을 준다.
이 접근은 선례가 없지 않다.  초기의 분산 파일 시스템은 성능을 향상시키기 위해 클라이언트 캐싱을 이용했다.
POSIX 요구는 더 높은 성능을 위해 relaxed ..

9.3 Replication Pipelining

클라이언트가 파일을 쓸 때 로컬 파일에 먼저 쓴다.
복제 계수가 3일 때를 가정.
로컬 파일이 데이터로 가득 차면, 클라이언트는 네임노드로 부터 데이터노드 리스트를 갱신한다.
이 리스트는 그 블록의 복제물을 보관할 데이터노드를 갖고 있다.
그럼 클라이언트는 그 블록을 첫번째 데이터노드에 플러시 한다.
첫번째 데이터노드는 데이터를 작은 조각(4KB)으로 받기 시작해서 로컬 저장소에 쓰면서 그 부분을 두번째 데이터노드에 전달한다.
두번째 노드는 똑같이 세번째 노드에 전달한다.
마침내 세번째 노드가 저장소에 보관한다.
데이터 노드는 파이프라인의 이전 노드에서 데이터를 받고 다음 노드로 넘겨준다.
그러므로 데이터는 한 데이터 노드에서 다음으로 파이프라인 된다.

10 Accessability

HDFS 는 어플에서 여러가지 방법으로 접근 가능하다.  네이티브는 자바 API 제공.
이것에 대한 C 래퍼 또한 가능.   HTTP 브라우저 가능.
WebDAV 프로토콜을 통하는 방법은 개발 중.

10.1 FS Shell

HDFS 는 사용자 데이터를 파일/ 디렉토리로 구성한다. 사용자 인터페이스를 위해 쉘 제공.
다른 쉘과 비슷.
스크립트 언어 지원 위해 필요.

10.2 DFSAdmin

Command set..  HDFS cluster 관리용
관리자 만의 용도.

10.3 Browser Interface

전형적인 HDFS 설치는 TCP 포트를 통한  ‘네임스페이스’를 노출시키는 웹서버를 구성한다.
이것을 통해 브라우징 하면서 내용을 확인할 수 있다.

11. Space Reclamation

11. 1 File Deletes and Undeletes

어플이나 사용자에 의해 파일이 삭제되면 바로 삭제 되지 않음.
휴지통으로 이동.
이동한 파일은 정해진 시간만큼 존재.
완전히 삭제된 후 네임노드는 HDFS 이름공간에서 파일을 삭제.
파일의 삭제는 그에 할당된 블락들을 해제시킴.
파일의 삭제와 빈공간의 증가 사이에는 시간 차이가 존재함.

파일이 휴지통에 있는 동안은 복구 가능.
복구하려면 휴지통으로 가서 복구 해야 함. 여기에는 최종본만 있음.
복구하는 규칙 :: 현재의 정책은 6시간 이상 경과한 파일을 지우는 것.
향후에는 여러 옵션을 적용할 수 있을 것이다.

11.2 Decrease Replication Factor

복제 계수가 줄어들면 네임노드가 지워질 여분의 복제분을 선택한다.
다음번의 핫빗 이 이 정보를 데이터노드에 전달.
데이터 노드가 블럭을 지우고 자유 공간이 증가.  역시 시간차이가 존재.

 

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중