회사에 다니면서 많이 다뤄봤지만 기본적인 개념이 많이 부족한 것 같아 정리해본다.

하둡 분산형 파일시스템(Hadoop Distributed FileSystem, HDFS)

Hadoop Architecture

하둡 클러스터는 하나의 마스터 노드와 여러개의 데이터노드로 구성

NameNode(Master)

• 클라이언트로부터 파일접근 요청에 응답 및 관리 역할

• Hadoop 내 존재하는 파일 및 디렉토리에 대한 "메타데이터" 관리

• 모든 변경사항 기록(NameNode가 동작하는 OS의 로컬 파일 시스템에 기록)

  • 파일변경 사항(트랜잭션 로그) EditLog
  • 전체 이미지 정보는 FsImage
  • 해당 파일들은 클러스터 장애로 인해 재기동 시 복구에 사용!!
    

EditLog와 FsImage. 클라이언트가 NameNode로 명령을 내리면 NameNode는 파일 변경 사항을 EditLog 파일에 기록한다. NameNode가 재시작 되면 네임스페이스를 복구하기 위해 FsImage를 먼저 읽어들인 후 EditLog의 내용을 차례로 병합하여 기동한다. EditLog 수가 늘어날 수 록 기동 시간은 늘어나게 된다.

• 고가용성 설정을 통해 장애발생에 대응 가능(상세하게 추가 정리예정)
  NameNode 장애발생으로 프로세스나 노드 다운 시, 단일 마스터 노드인 NameNode가 중지되는 즉시 HDFS는 사용할 수 없는 상태가 된다. 특히 NameNode에 디스크 장애가 발생한다면, 로컬 파일 시스템에 저장되어 있는 FsImage와 EditLog 모두 유실될 수 있는데 이를 해결할 수있는 고가용성(HA, High Availability) 기능이 제공된다. Active-Standby 두 개의 NameNode를 구성함으로서 NameNode 장애를 막을 수 있다.

Secondary NameNode

• NameNode의 FsImage와 EditLog를 주기적으로 폴링하여 백업하고, 쌓여있는 EditLog를 FsImage에 병합(merge)하는 역할
• 병합완료 시 변경 사항은 다시 NameNode로 전달하여 동기화(체크포인트라고 불림)
• CPU와 IO가 많이 필요한 작업이기 떄문에 별도의 노드에서 수행하는 것이 좋음
• Hadoop2에서도 HA 구성을 활성화 하지 않으면 Secondary NameNode를 FsImage와 EditLog의 백업 및 병합 용도로 사용할수 있음
  

Standby NameNode

H/A 구성 시 NameNode를 Active/Standby 상태를 갖게 하는데, 두 NameNode는 FsImage와 EditLog 저장을 위해 NFS와 같은 공유 저장소를 설정한다. Active 노드가 파일을 변경하면, Standby 노드가 감시(watch)하고 있다가 변경 사항을 자신의 네임스페이스에 똑같이 적용한다. 이렇게 동기화된 상태의 네임스페이스를 유지하여, Active 노드에 장애가 발생했을 때 Standby 노드가 Active 노드의 역할을 곧바로 수행한다. 이로서 SPOF 문제를 해결할 수 있다.

체크포인트는 Secondary NameNode에서 수행하는 것 보다 간결해졌다. Standby 노드는 공유 저장소의 EditLog를 계속해서 본인의 네임스페이스에 적용하므로, 네임스페이스를 새로운 FsImage로 저장하고 Active 노드에게 새로운 FsImage를 사용하도록 함으로서 완료된다.

JournalNode

공유 저장소 자체가 HA 구성이 되어있지 않으면 이 저장소가 SPOF가 될 수 있고 이로인해 전체 클러스터의 장애로 이어진다.
이 문제를 해결하기 위해 단일 공유 저장소 대신 NameNode에 JournalManager를 두고 JournalNode로 이루어진 분산 저장소에 FsImage와 EditLog를 저장하고 동기화하여 완벽히 HA를 보장할 수 있게 되었다.

DataNode(Slave)

단일 디스크 파일 시스템의 기본 블록 크기가 4KB 정도 인것에 비해

DataNode에 저장되는 블록의 크기는 64MB~128MB의 크기를 가진다. HDFS가 저장하고 처리하고자 하는 파일 하나의 크기가 작게는 수 백 메가바이트에서 크게는 테라, 페타 바이트 만큼 크기 때문이다
단일 디스크 파일 시스템과는 다르게, 블록 크기보다 작은 파일이 전체 블록 크기만큼의 공간을 차지하지는 않는다. 하지만 NameNode는 파일 시스템의 메타데이터를 전부 메모리에 관리하기 때문에 블록 크기 보다 작은 많은 수의 파일을 HDFS에 저장하는 것은 NameNode에 부담을 주고, 따라서 HDFS에 적합하지 않다.

HDFS의 NameNode가 여러가지 보조 장치를 통해 파일 시스템의 네임스페이스와 메타 데이터를 유실하지 않도록 발전한것 처럼, DataNode도 이러한 분산 환경에서 파일 블록이 언제든 유실되거나 접근할 수 없는 상황을 가정하고 설계되었는데, 분산된 노드에 파일 블록의 복제본을 두는 방식이다. HDFS에서는 기본적으로 세 개의 파일 블록 복제본을 서로 다른 DataNode에서 보관하도록 처리한다. 하나의 DataNode 데이터가 모두 유실되더라도 다른 DataNode에 저장된 복제본 블록에 접근해서 온전한 파일을 읽을 수 있다.

HDFS File Read & Write

클라이언트는 HDFS의 파일을 읽거나 쓸때, 먼저 NameNode로부터 파일 블록들의 위치를 응답받은 다음, 그 정보를 가지고 DataNode로 직접 읽거나 쓰기 요청을 한다. NameNode는 파일의 IO에 직접적인 관여를 하지 않고 분산되어 있는 파일 블록들을 병행(parallel)해서 읽어들인다. 만액 어떤 파일의 읽기 요청이 많이 몰린다면, 이 파일 혹은 디렉토리에 대해 복제 계수(replication factor)를 기본 값보다 늘려서 파일 블록을 더 많은 노드에 분산시킬 수 있다. 블록이 여러 노드에 위치하기 때문에 읽기 요청에 대한 부하를 나눌 수 있는 것이다.

DistributedFileSystem가 NameNode로 RPC 통신을 하고, FSDataInputStream는 파일을 읽어들인다.

HDFS에 파일을 읽고 쓰는 클라이언트는 일반적으로 하둡의 MapReduce 애플리케이션과 같이 하둡 클러스터의 워커 노드(DataNode)에서 동작하는 프로그램이다.
하둡 2 부터는 하둡 클러스터 위에서 동작하는 애플리케이션을 YARN이 관리하는데, 이때 처리하려는 파일 블록의 위치에 따라 그 블록이 위치한 노드에서 애플리케이션이 실행될 수 있도록 자원을 할당한다