Hadoop distributed file system rev3

Hadoop
Distributed File System
DMC 공학과
박성제 (nicesj@nicesj.com)

Hadoop 이란?
• High-Availability Distributed Object-Oriented Platform
• JAVA 로 개발됨
• Nutch 라는 검색 엔진 개발 과정에서 탄생
o Doug Cutting
• Storage 와 Processing Part 로 구성됨
o Storage : Hadoop Distributed File System
o Processing : MapReduce

HDFS 의 배경 및 목표
• 수백, 수천 대의 서버들 중 문제는 늘 발생할 수 있다.
 문제를 발견하고, 자동으로, 빠르게 복구할 수 있어야 한다.
• 응답성(Latency) 보다는 처리 성능(Throughput) 이 더
중요하다.
• 대용량 데이터를 처리한다.
 수 기가 바이트에서 수 테라 바이트의 파일을 다룬다.
• 데이터 일관성 유지를 단순화 시킨다.
 Append 와 Truncate 외의 수정은 지원하지 않는다.
(Write-Once Read-Many)

HDFS 의 구조
Application
HDFS
Client Library
Name Node
Data
Node
Data
Node
Data
Node
Heartbeat, Blockreport
Replication
Local Rack Remote Rack
Create
Delete
Rename
Truncate
Read, Write

Client Library
• JAVA 로 개발
o C 언어 등으로 포팅된 라이브러리도 있음
• 특정 HDFS 의 파일에 접근하기 위해 Server URI 를 사용
o 직접 지정  hdfs://localhost:9000
o 기본 설정 값  Configuration 클래스를 이용해 기본 설정 값 사용
Configuration conf = new Configuration();
FileSystem dfs = FileSystem.get(conf);
Path filePath = new Path(“/tmp/hello.txt”);
if (dfs.exists(filePath)) {
dfs.delete(filePath, true);
}
…

Name Node
• File System 의 Namespace 정보를 관리
• Client 의 파일 접근에 대한 통제
• 모든 파일 및 디렉토리 Metadata 관리
• DataNode 의 Replica 관리
• 전체 Metadata 를 메모리에서 관리
• Single Point Of Failure 문제
Name Node
Metadata (name, replicas, block list, …)
/home/foo/data, 3, {1, 3, 6 }, …

Name Node
DataNode Management
• NameNode 는 DataNode 에 직접 요청을 보내지 않는다.
o DataNode 가 주기적으로 보내는 Heartbeat 에 대한 응답을 할 때 명령을 전달함
• 다른 노드로 Block을 복사하라는 명령
• 복사된 Block을 삭제하라는 명령
• NameNode 에 재 등록을 하거나 종료 하라는 명령
• Blockreport 를 즉시 보내라는 명령

Name Node
Check Pointing
• 재시작시, 최신 상태로 복구하기 위해 이미지를 저장
o fsImage 와 editLog 파일
• fsImage : 특정 시점의 모든 metadata 정보가 기록된 파일
• editLog : 트랜잭션 로그를 저장, 파일 크기에 제한이 없음
o fsImage 은 효과적으로 로딩할 수 있도록 구조를 최적화
• 일부 metadata 를 수시로 업데이트 하기에는 비효율적
• editLog 를 이용해 이 점을 보완
https://blog.cloudera.com/blog/2014/03/a-guide-to-checkpointing-in-hadoop/

Name Node
Check Pointing (cont’d)
• CheckPointing
editLog 의 모든 transaction log 가 replay 된 최신 상태를
fsImage 로 저장하는 것
• CheckPointing 조건
o 마지막 CheckPointing 시점으로 부터 일정 시간 후
• dfs.namenode.checkpoint.period
o Transaction Log 가 일정 크기에 도달했을 때
• dfs.namenode.checkpoint.txns
o NameNode 가 재시작 될 때

Name Node
Check Pointing (cont’d)
• editLog 가 크면, CheckPointing 을 하는 시간이 길어진다!
o CheckPointing 이 Client Request 에 영향을 끼침
• Secondary NameNode (CheckpointNode)
o Client 의 Request 를 처리하지 않음
o NameNode 로 부터 fsImage 와 editLog 를 받아서 CheckPointing 을 대신 진행함
o NameNode 가 CheckPointing 으로 인해 Client Request 를 처리하지 못하는 상황이
발생하지 않도록 하는 역할

Name Node
Single Point Of Failure
• CheckPointing 을 해도 NameNode 가 재시작 되는 동안
Client Request 를 처리하지 못하는 문제는 해결되지 않음
• High Availability (SPoF 해결) 를 위해 Hadoop 2.x 에서
부터 새로운 기능들이 소개됨
o HDFS High-Availability With NFS
o HDFS High-Availability With QJM

Name Node
HDFS High Availability
• NameNode 에 대한 SPoF 문제를 해결 하자
o NameNode 를 하나 더 만들자!
• Active / StandBy NameNode
• Active NameNode
o Client 들의 Request 를 처리하고 있는 NameNode
• StandBy NameNode
o Client 들의 Request 는 처리하지 않음
o Active NameNode 가 문제가 발생했을 때를 대비
o Active NameNode 와 같은 최신 상태 정보는 어떻게 유지하지?
• NFS, QJM, …

Data Node
• 기본 설정
o Block 크기 : 128 MB (설정 파일에서 변경 가능)
o Replica 개수 : 3 개 (파일 별 설정 가능)
• Heartbeat 와 Blockreport 를 모든 NameNode 에 주기적으로
보냄
o Heartbeat
• 3 초에 한번씩.
• 10 분 이상 받지 못하면, 해당 DataNode 는 오류 처리
• 가용 저장 공간 크기, 사용 중인 저장 공간(비율), 진행 중인 데이터 전송
정보를 포함  NameNode 가 Load Balancing 을 할 때 참고
o Blockreport
• Local File System 안의 모든 Data Block 목록을 전송
• 최초 실행 시 한 번 보내고, 이 후 시간 단위 주기로…

Data Node (cont’d)
• Block은 다른 파일과 공유 하지 않음
o 기본 Block 사이즈 보다 작은 파일 또는 파일 끝 부분 일부를 위해 하나의
Block으로 할당 되면, 해당 데이터 크기와 같은 크기의 Block 파일이 생성됨
• Block당 두 개의 파일이 생성됨
o Data File, Metadata File (Checksum, Generation Stamp)
• Replica 위치 결정 기준 (기본 3개인 경우)
o Local Rack 내 다른 Data Node 에 Replica 1개
o Remote Rack 내 Data Node 에 Replica 1개

Data Node (cont’d)
• DataNode 가 시작될 때, NameNode 와 Handshake
o Namespace ID 와 S/W Version 을 확인
• 다른 경우 종료됨
• 새롭게 초기화되어 Namespace ID 가 없는 DataNode 는
NameNode 를 통해 Cluster 에 합류할 수 있다.
• NameNode 에 등록되면 Storage Id 를 부여 받으며, 이 후
해당 Node 를 구분하는 용도로 사용된다.
o IP 는 바뀔 수 있으므로

File Operations
• Read
• Write
• Rename/Delete

File Operations
Read
FSDataInputStream in = dfs.open(filePath);
String msg = in.readUTF();
in.close();
dfs.close();

File Operations
Write
FSDataWriteStream out = dfs.create(filePath);
out.writeUTF(“Hello World”);
out.close();
dfs.close();

File Operations
Write (cont’d)
• Write Pipeline
o Pipeline setup
• Client 가 Write_Block 요청을 Pipeline 으로 보냄
• Pipeline 의 마지막 DataNode 가 응답 패킷을 회신하는 것으로 설정 완료
o Data streaming
• Client 버퍼가 찰 때 마다 패킷을 만들어 pipeline 으로 보냄
o 버퍼가 차기 전에 hflush() 함수를 호출하면 패킷을 만들어 보냄
o hflush() 로 인해 전달된 패킷은 응답 패킷이 올 때까지 다음 패킷을
보내지 않음
o Close : replica 생성을 종료 하고, pipeline 을 닫음
• Client 는 모든 패킷에 대한 응답 패킷을 받은 후 close 를 처리한다.
• 모든 DataNode 의 replica 상태를 FINALIZED 로 바꾸고, NameNode 에 알린다.
• NameNode 는 최소한의 replica 들이 FINALIZED 상태로 된 것이 확인 되면,
Block의 상태를 COMPLETE 로 바꾼다.
https://blog.cloudera.com/blog/2015/03/understanding-hdfs-recovery-processes-part-2/

File Operations
Write (cont’d)
• Client 는 Write 를 하기 위해 NameNode 로 부터 Lease 를
확보해야 함 (일종의 Lock)
• Client 는 주기적으로 Lease 를 갱신 해야 함
• Lease 를 주기적으로 보내지 못하면, Client 가 Fault 난
것으로 판단하여 Lease Recovery 를 시작함

File Operations
Rename/Delete
• Delete
o 파일을 읽거나 쓰고 있는 Client 가 있어도 삭제됨
• NameNode 는 Namespace 에서는 바로 지우지만, 할당된 Block들은 나중에
지운다.
• 쓰고 있던 Client 는 현재 Block에 더 쓰려고 할 때 또는 새로운 Block을
할당하려고 NameNode 에 접근할 때, I/O Exception 이 발생한다.
• Rename
o 파일을 쓰고 있는 Client 가 있으면,
다음 Block을 할당하려고 할 때 I/O Exception 발생
https://issues.apache.org/jira/secure/attachment/12370562/Appends.doc

Fault Recovery
• Lease Recovery
• Block Recovery
• Pipeline Recovery

Fault Recovery
Lease Recovery
• Client 가 Lease 를 얻은 후 갱신 시간 안에 갱신을 하지
않는 경우
o File 을 Close 한다.
o Lease 를 Release 한다.
• Lease 는 NameNode 의 Lease Manager 에 의해 관리됨
• Lease 갱신 시간 (변경 불가능)
o Soft Limit: 1 분
o Hard Limit: 1 시간
http://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-part-1/

Fault Recovery
Block Recovery
• Write 를 할 때, Pipeline 안의 모든 DataNode 에 block data
가 전달되지 않은 상태에서 Lease Recovery 를 해야 할 때,
Data 의 길이가 같을 수 있도록 보장해주는 동작
• Block Recovery 는 Lease Recovery 중에 발생한다.
• Lease Recovery 는 파일의 마지막 Block에서, 그 Block이
COMPLETE 상태가 아닐 때 Block Recovery 를 수행 시킨다.

Fault Recovery
Pipeline Recovery
• Pipeline 내 DataNode 에 쓰기 동작 수행 중, 특정 DataNode
에서 오류가 발생했을 때, 이로 부터 복구 하는 방법
• Pipeline 의 각 단계별 오류 복구.
o Setup
o Streaming
o Close

Install Hadoop
• Install packages (JDK, SSH)
# sudo apt-get install default-jdk
# sudo apt-get install ssh
• Create a new system user (hadoop)
# adduser hadoop
# su – hadoop
# ssh-keygen
# cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh localhost (Login without password query)
• Get & Decompress the hadoop (2.7.2)
# wget http://mirrors.sonic.net/apache/hadoop/common/hadoop-2.7.2/hadoop-2.7.2.tar.gz
# tar -zxf hadoop-2.7.2.tar.gz
# ln -s hadoop-2.7.2/ hadoop

Setup Hadoop
• Setup Environment
# vi .bashrc
# vi hadoop/etc/hadoop/hadoop-env.sh
# mkdir hadoop/tmp
# mkdir –p hadoop/store/hdfs/namenode
# mkdir –p hadoop/store/hdfs/datanode
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export HADOOP_INSTALL=/home/hadoop/hadoop
export PATH=$PATH:$HADOOP_INSTALL/bin
export PATH=$PATH:$HADOOP_INSTALL/sbin
export HADOOP_MAPRED_HOME=$HADOOP_INSTALL
export HADOOP_COMMON_HOME=$HADOOP_INSTALL
export HADOOP_HDFS_HOME=$HADOOP_INSTALL
export YARN_HOME=$HADOOP_INSTALL
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_INSTALL/lib/native
export HADOOP_OPTS="-Djava.library.path=$HADOOP_INSTALL/lib"
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

Setup Hadoop (cont’d)
# vi hadoop/etc/hadoop/core-site.xml
<configuration>
<property>
<name>hadoop.tmp.dir</name>
<value>/home/hadoop/hadoop/tmp</value>
<description>A base for other temporary directories.</description>
</property>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:54310</value>
<description>The name of the default file system. A URI whose
scheme and authority determine the FileSystem implementation. The
uri's scheme determines the config property (fs.SCHEME.impl) naming
the FileSystem implementation class. The uri's authority is used to
determine the host, port, etc. for a filesystem.</description>
</property>
</configuration>

# vi hadoop/etc/hadoop/hdfs-site.xml
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
<description>Default block replication.
The actual number of replications can be specified when the file is created.
The default is used if replication is not specified in create time.
</description>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/home/hadoop/hadoop/store/hdfs/namenode</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>file:/home/hadoop/hadoop/store/hdfs/datanode</value>
</property>
</configuration>

# cp hadoop/etc/hadoop/mapred-site.xml.template hadoop/etc/hadoop/mapred-site.xml
# vi hadoop/etc/hadoop/mapred-site.xml
• Format
# hadoop namenode –format
• Start services
# start-dfs.sh & start-yarn.sh
<configuration>
<property>
<name>mapred.job.tracker</name>
<value>localhost:54311</value>
<description>The host and port that the MapReduce job tracker runs
at. </description>
</property>
</configuration>

Web Interface
• http://nclab.nicesj.com:50070, http://nclab.nicesj.com:50090

Client Application
Development
• Java 소스코드 작성
• 컴파일
# hadoop com.sun.tools.javac.Main 소스파일.java
• Archive 파일 생성
# jar cf 파일이름.jar 소스파일.class
• 실행
# hadoop jar 소스파일.jar 클래스이름

Client Application
Development (cont’d)
https://tutorials.techmytalk.com/2014/08/16/hadoop-hdfs-java-api/

References
• Hadoop Official Page: http://wiki.apache.org/hadoop/
• Hadoop Distributed Filesystem Architectural Documentation:
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
• Install Hadoop on Ubuntu:
http://www.bogotobogo.com/Hadoop/BigData_hadoop_Install_on_ubuntu_single_node_cluster.php
• Where to get Hadoop: http://mirrors.sonic.net/apache/hadoop/common
• Java Client API: http://hadoop.apache.org/core/docs/current/api/
• Scalability of the HDFS: https://developer.yahoo.com/blogs/hadoop/scalability-hadoop-distributed-
file-system-452.html
• MapReduce Tutorial: https://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-
mapreduce-client-core/MapReduceTutorial.html
• Quorum Journal Manager: http://johnjianfang.blogspot.kr/2015/02/quorum-journal-manager-part-i-
protocol.html
• How to setup hadoop cluster with HDFS HA: http://www.edureka.co/blog/how-to-set-up-hadoop-
cluster-with-hdfs-high-availability/
• Recovery Process: http://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-
part-1/
• Konstantin Shvachko, “The Hadoop Distributed File System,”

Appendix
• 발표 시간에 맞춰 이 후 내용에 대해서는 발표 없이 참고
부탁 드립니다.
o Name Node
o HDFS High Availability
o File Operations
o Automatic Failover
o Fault Recovery

Name Node
Check Pointing
 Secondary NameNode (CheckpointNode)
 CheckPointing 실행 조건 확인
 최근 TxID 요청
 EditLog Roll 요청
 fsImage, editLog 를 받아옴
 최신 fsImage 생성
 결과 fsImage 파일 전송

Check Pointing
 StandBy NameNode
 Check Pointing 을 수행
 CheckPointing 실행 조건 확인
 공유 된 fsImage 와 editLog 로
최신 fsImage 생성
 NameNode 로 결과 fsImage 전송

With NFS
https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html
Name Node
(Active)
Name Node
(StandBy)
NAS
(Shared Directory)
NFS NFS
Updated fsImage

With NFS (cont’d)
• NAS 에 만든 폴더를 NFS 를 이용해 공유하자!
o 무엇을?
• NameNode 의 fsImage 와 editLog
• StandBy NameNode 는 공유 폴더의 fsImage 또는 editLog 가
변경되면, 해당 파일들을 로컬로 복사한다.
o fsImage 에 editLog 를 replay 하여 최신 fsImage 로 업데이트 한다.
o CheckPointing 조건에 맞을 때 수행!
https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html

With NFS (cont’d)
• NFS 로 공유를 하고 있을 때, 시스템에 하나의 Name Node
만 Active 상태로 남아 있는 것을 어떻게 보장하지?
o Active Name Node 가 고장이라고 판단 되었으나, 실제로는 계속 동작하면서 일부
Client 의 명령을 받고 있다면?
• Shared Storage 에 있는 editLog 가 계속 변하게 된다!!
• Fencing Method 를 이용해 이를 방지한다.

With NFS (cont’d)
• Fencing Method
o Failover 처리 중, System 에 두 개의 Active NameNode 가 있는 상황을 방지한다.
o Shell 또는 sshfence
• Shell : 외부 Shell Script 를 수행하여, Failover 중에 기존 Active NameNode 가
완전히 종료 될 수 있도록 처리
• sshfence : active name node 에 ssh 로 접속하여 NameNode 데몬을 강제 종료
시킨다.

With QJM
o Quorum Journal Manager
• https://issues.apache.org/jira/browse/HDFS-3077
• JournalNode 들을 통해 fsImage 와 editLog 공유
https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
Name Node
(Active)
Name Node
(StandBy)
Journal Node
Write Read
Updated fsImage
Journal Node Journal Node

With QJM (cont’d)
• JournalNode 데몬
o NameNode 또는 DataNode 에서 실행 될 수 있다.
• NFS 를 이용할 때와 같이 Fencing Method 가 필요 함

File Operations
• Read
• Write

File Operations
Read
• DistributedFileSystem 의 Open Method 를 통해 NameNode 에
Block 정보를 요청함
• NameNode 는 Replica 를 포함한 Block 목록과 인증키를 Client
에게 전달함
o DistributedFileSystem 는 FSDataInputStream 객체를 반환함
• FSDataInputStream 은 DFSInputStream 을 Wrapping 한 것
• Client 는 FSDataInputStream 객체를 통해 Read 요청을 함
o DFSInputStream 은 첫 번째 Block을 읽기 위해 가장 가까이에 있는 DataNode 에 접속한다.
• DataNode 로 부터 Data Stream 이 Client 로 전달된다.
• Block의 끝에 도달하면, DFSInputStream 은 현재 DataNode와의
연결을 끊고, 다음 Block이 있는 최적의 DataNode 를 찾는다.
o 다음 Block 목록을 가져오기 위해 NameNode 에 접속하기도 한다.
http://blogs.data-flair.com/hadoop-hdfs-data-read-and-write-operations/

File Operations
Write
• DistributedFileSystem 의 Create Method 호출
o DistributedFileSystem 은 NameNode 에 연결하여, 해당 파일에 대한 Metadata 를 생성함. (할당된
Block은 없다)
• 이 때, NameNode 는 실제 파일 존재 여부 및 생성 권한을 확인한다.
o FSDataOutputStream 객체를 반환
• FSDataOutputStream 객체를 통해 Write 를 수행하면, DFSOutputStream
은 해당 요청을 packet 으로 나눈다.
o Data Queue 에 Packet 을 넣는다.
• Data Queue 는 DataStreamer 에 의해 비워진다.
o DataStreamer 는 NameNode 에 새 Block 할당 요청
o 새 Block 할당 시 Pipeline 이 형성되며, DataStreamer 는 첫 번째 DataNode 에 packet
을 전송한다.
o 해당 Packet 은 pipeline 안에 있는 다음 DataNode 로 재전송 된다.
o Ack Queue 에 있는 패킷은 Pipeline 안에 있는 모든 DataNode 로 부터 Ack 를 받았을 때
지워진다.
• Close 를 하면, 남아 있는 모든 packet 을 DataNode Pipeline 으로 보내고,
응답 패킷을 기다린다. (이 후 NameNode 에 완료 시그널을 보낸다)
o NameNode 는 이미 Block 구성에 대해 알고 있기 때문에, Client 는 최소한의 block replica 가
구성되면 종료된다.
http://blogs.data-flair.com/hadoop-hdfs-data-read-and-write-operations/

Automatic Failover
• Failover 처리 자동화
• 자동화 하기 위한 데몬
o Zookeeper
o Zookeeper Failover Controller
• NameNode 에서 실행
o Zookeeper
o Zookeeper Failover Controller
• DataNode 에서 실행
o Zookeeper
http://www.edureka.co/blog/how-to-set-up-hadoop-cluster-with-hdfs-high-availability/

Fault Recovery
Lease Recovery
1. 파일의 마지막 Block을 가지고 있는 DataNode 검색
2. 검색된 DataNode 중 하나를 Primary 로 지정
3. NameNode 로 부터 새 Generation Timestamp 획득
4. 각 DataNode 들로 부터 Block 정보를 얻어온다.
5. 최소 Block 길이를 계산한다.
6. 유효한 Generation Timestamp 를 가진 DataNode 의 Block 정보를
최소 Block 길이와 새 Generation Timestamp 값으로 갱신한다.
7. NameNode 에 갱신 정보를 알린다.
8. NameNode 는 Block 정보를 갱신한다.
9. NameNode 는 파일에 대한 Lease 를 해제한다.
10. NameNode 는 변경 사항을 Edit Log 에 저장한다.

Fault Recovery
Pipeline Recovery
• Pipeline setup 단계의 오류로 부터 복구
o 새로운 Block을 쓰기 위한 경우에는
• 이전에 생성 요청했던 Block들을 모두 파기 시킴 (abandon)
• 새로운 Block으로 새로운 Pipeline setup 을 시작한다.
o Block을 추가 하기 위한 경우에는
• 정상적인 DataNode 들을 이용해 Pipeline 을 새로 구성한다.
o Block들의 GS 가 갱신된다.
• Data streaming 단계의 오류로 부터 복구
• Pipeline 안의 DataNode 가 오류를 인지 하면, 모든 TCP/IP connection 을 닫고 pipeline 에서 빠진다.
o 버퍼에 있는 Data 가 유효한 경우라면, 해당 Block 파일과 메타데이터 파일에 쓴다.
• Client 에서 오류를 인지하면, pipeline 으로 데이터를 보내는 것을 중단하고, 남아 있는 정상 DataNode
들을 이용해 pipeline 을 재구축한다. (Block들의 GS 가 갱신됨)
• Client 가 새로운 GS 로 전송을 재개 할 때, DataNode 중에 이미 해당 데이터를 받은 경우에는 다음
DataNode 로 재전송만 수행한다.
• Close 단계의 오류로 부터 복구
o 남아 있는 정상적인 DataNode 들로 pipeline 을 재구축한다. Block들의 GS 를 갱신하고, Replica 들의 FINALIZE
를 진행한다.
• 문제가 발생한 DataNode 를 제외시키고, Pipeline 을 새로 구축할 때,
Replica 개수를 유지하기 위한 새로운 DataNode 에 대해서는 어떻게
하는가?
 새로운 DataNode 를 할당할까? 무시할까?

Fault Recovery
Pipeline Recovery (cont’d)
• 문제가 발생한 DataNode 에 대한 처리 정책
o DISABLE: DataNode 를 교체하지 않고, 에러를 반환 (client)
o NEVER: DataNode 를 교체하지 않고 진행
o DEFAULT: 다음 조건에 따라 교체
• 설정된 replica 개수: r
• 현존하는 DataNode 들의 개수: n
• 만약 r >= 3 && (floor(r/2) >= n || (r > n && (hflushed || appended))) 이면 새로운
DataNode 넣는다.
o ALWAYS: DataNode 를 항상 넣는다. 못 넣는 경우 실패 처리

Fault Recovery
States of replica
• Data Node 상의 Block (replica) 들의 상태
o FINALIZED
• 쓰기가 끝남. 데이터는 고정됨 (수정불가)
o Replica Being Written
• 파일을 생성 또는 추가를 위해 다시 열었을 때
• 열린 파일의 마지막 Block
• Client들에게 노출됨 (접근 가능)
o Replica Waiting to be Recoverd
• DataNode 가 재시작되는 경우, 모든 RBW 는 RWR 로 변경됨
o Replica Under Recovery
• Lease Recovery 에 포함되는 Block 중, non-TEMPORARY Block 들은 RUR 로
변경됨
o TEMPORARY
• Replication 을 위해 일시적으로 생성된 Block. RBW 와 비슷하지만, Client에게
노출되지 않는다.

Fault Recovery
States of block
• Name Node 상의 Block (block) 들의 상태
o UNDER_CONSTRUCTION
• 열린 파일의 마지막 Block의 상태, 길이와 GS 는 변경 될 수 있다. 해당 Block의 Data
는 client 에 노출 될 수 있다.
• NameNode 에서 Write Pipeline 대상 Block임을 알 수 있음
o UNDER_RECOVERY
• 파일의 마지막 Block이 UNDER_CONSTRUCTION 상태로 Client 의 Lease 가 말소
되면, Block Recovery 를 시작할 때, UNDER_RECOVERY 상태로 변경된다.
o COMMITTED
• Block 데이터와 GS 는 변경 불가능한 상태
• 최소 Replica 개수를 만족하지 못하고 있는 상태
• Read 요청을 처리하기 위해서는 RBW replica 의 위치와 GS 및 Finalized replica 에
대한 정보를 알고 있어야 함
• UNDER_CONSTRUCTION 에서 COMMITED 로 전이하는 경우는, Client 가 해당
파일에 append 또는 Close 를 요청할 때임
o COMPLETE
• COMMITED 에서 COMPLETE 로 전이하기 위해서는 NameNode 가 최소한의
FINALZIED replica 개수가 만족 되었음을 알 때이다.
• 모든 Block이 COMPLETE 상태가 될 때 close 가 완료 될 수 있다.

Hadoop distributed file system rev3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Hadoop distributed file system rev3

Similar to Hadoop distributed file system rev3 (20)

Hadoop distributed file system rev3

Editor's Notes