(하둡) HDFS의 개념

1. 블록

물리적인 디스크에는 블록크기란 개념이있다. 블록 크기는 한번에 읽고 쓸 수 있는 데이터의 최대량이다.
단일 디스크를 위한 파일시스템은 디스크 블록 크기의 정배수인 파일시스템 블록 단위로 데이터를 다룬다.
파일시스템의 블록크기는 보통 수 킬로바이트이고, 디스크 블록크기는 기본적으로 512바이트이다.
사용자는 파일크기에 관계없이 파일을 읽고 쓸 수 있으며, 특정 파일 시스템에 구애받지도 않는다.

HDFS도 기본적으로 블록개념을 가지고 있다. 그러나 HDFS블록은 기본적으로 128MB와 같이 굉장히 큰 단위이다. HDFS의 파일은 단일 디스크를 위한 파일시스템처럼 특정 블록 크기의 청크(chunk)로 쪼개지고 각 청크는 독립적으로 저장된다.
단일 디스크를 위한 파일시스템은 디스크 블록 크기보다 작은 데이터라도 한 블록 전체를 점유하지만, HDFS파일은 블록크기보다 작은 데이터일 경우 전체 블록크기에 해당하는 하위 디스크를 점유하지 않는다.

예를들어, HDFS의 블록크기가 128MB고 1MB 크기의 파일을 저장한다면 128MB의 디스크를 사용하는 것이아니라 1MB크기만 사용한다.

분산파일 시스템에서 블록 추상화의 개념을 도입하면서 얻게 된 몇몇 이득이 있다.
첫번쨰 이득은 파일하나의 크기가 단일디스크 용량보다 더 커질수 있다는 것이다. 하나의 파일을 구성하는 여러개의 블록들이 동일한 디스크에만 저장될 필요가 없으므로 클러스터에 있는 어떤 디스크에도 저장될 수 있다.

두번째 이득은 파일단위보다 블록 단위로 추상화를 하면 스토리지의 서브 시스템을 단순하게 만들 수 있다는 것이다.

2. 네임노드와 데이터노드

HDFS 클러스터는 마스터-워커 패턴으로 동작하는 두 종류의 노드(마스터인 하나의 네임노드와 여러개의 데이터노드로 구성되어 있다.)
네임노드는 파일시스템의 네임스페이스를 관리한다. 네임노드는 파일시스템 트리와 그 트리에 포함된 모든 파일과 디렉토리에 대한 메타데이터를 유지한다.
이 정보는 네임스페이스 이미지와 에디터로그라는 두 종류의 파일로 로컬 디스크에 영속적으로 저장한다.
네임노드는 또한 파일에속한 모든 블록이 어느 데이터노드에 있는지 파악하고 있다.
하지만 블록의 위치정보는 시스템이 시작할 떄 모든 데이터노드로부터 받아서 재구성하기 때문에 디스크에 영속적으로 저장하지 않는다.

HDFS 클라이언트는 사용자를 대신해서 네임노드와 데이터노드 사이에서 통신하고 파일시스템에 접근한다.

데이터노드는 파일시스템의 실질적인 일꾼이다. 데이터노드는 클라이언트나 네임노드의 요청이 있을 때, 블록을 저장하고 탐색하며, 저장하고 있는 블록의 목록을 주기적으로 네임노드에 보고한다.

네임노드가 없으면 파일시스템은 동작하지 않는다.
네임노드를 실행하는 머신이 손상되면 파일시스템의 어떤 파일도 찾을 수 없다. 데이터노드에 블록이 저장되어 있지만 이러한 블록정보를 이용하여 파일을 재구성 할 수 없기 때문이다.
따라서 네임노드의 장애복구 기능은 필수적이며, 하둡은 이를 위해 두가지 메커니즘을 제공한다.

첫번째는 파일시스템의 메타 데이터를 지속적인 상태로 보존하기 위해 파일로 백업하는 것이다.
네임노드가 다수의 파일시스템에 영구적인 상태를 저장하도록 하둡을 구성할 수 있다.
백업은 동기화되고 원자적으로 실행된다. 주로 권장하는 방법은 로컬 디스크와 원격의 NFS 마운트 두 곳에 동시에 백업하는 것이다.

두번째는 보조네임노드를 운영하는 것이다. 보조 네임노드는 주 네임노드와 다르게 조금 다르게 동작한다.
보조네임노드의 주 역할은 에디트 로그가 너무 커지지 않도록 주기적으로 네임스페이스 이미지를 에디트 로그와 병합하여 새로운 네임스페이스 이미지를 만드는 것이다.
병합작업을 수행하기 위해서는 보조 네임노드는 충분한 CPU와 네임노드와 비슷한 용량의 메모리가 필요하므로 별도의 물리머신에서 실행되는 것이 좋다.
또한 보조 네임노드는 주 네임노드에 장애가 발생할 것을 대비해서 네임스페이스 이미지의 복제본을 보관하는 역할도 맡는다.
하지만 주네임노드의 네임스페이스 이미지는 약간의 시간차를 두고 보조 네임노드로 복제되기 떄문에 주 네임노드에 장애가 발생하면 어느 정도의 데이터 손실은 불가피하다.
이럴때 일반적인 복구방식은 NFS에 저장된 주 네임노드의 메타데이터 파일을 보조 네임노드로 복사하여 새로 병합된 네임스페이스 이미지를 만들고 그것을 새로운 주 네임노드에 복사한 다음 실행하는 것이다.

참고 : https://stackoverflow.com/questions/26943161/namespace-image-and-edit-log

3. 블록캐싱

데이터노드는 디스크에 저장된 블록을 읽는다.

4. HDFS 페더레이션

네임노드는 파일시스템의 모든 파일과 각 블록에 대한 참조 정보를 메모리에서 관리한다.

따라서 파일이 매우 많은 대형 클러스터에서 가장 큰 걸림돌이 되는 것은 바로 메모리이다.

이러한 네임노드의 확장성 문제를 해결하기 위해 2.x .릴리즈 부터 HDFS페더레이션을 지원하고 있다.

HDFS페더레이션을 활용하면 각각의 네임노드가 파일시스템의 네임스페이스 일부를 나누어 관리하는 방식으로 새로운 네임노드를 추가할 수 있다.

예를들어 어떤 네임노드는 /user 디렉토리 아래의 모든 파일을 관리하고 다른 네임노드는 /share 디렉토리 아래의 파일을 관리한다

HDFS페더레이션을 적용하면 각 네임노드는 네임스페이스의 메타데이터를 구성하는 네임스페이스 볼륨과 네임스페이스에 포함된 파일의 전체블록을 보관하는 블록 풀을 관리한다.

네임스페이스 볼륨은 서로 독립되어 있으며, 따라서 네임노드는 통신할 필요가 없고, 특정 네임노드에 장애가 발생해도 다른 네임노드가 관리하는 네임스페이스의 가용성에 영향을 주지 않는다.

하지만 블록풀의 저장소는 분리되어 있지않다. 

모든 데이터 노드는 클러스터의 각 네임노드마다 등록되어있고, 여러 블록풀로 부터 블록을 저장한다

HDFS 페더레이션 클러스터에 접근하기 위해 클라이언트는 파일 경로와 네임노드를 매핑한 클라이언트 측 마운트 테이블을 이용한다.

환경설정에서 ViewFileSystem과 viewfs://URI를 사용하여 관리할 수 있다

5. HDFS고강용성

데이터 손실을 방지하기 위해 네임노드 메타데이터를 다수의 파일시스템에 복제하는 방식과 보조 네임노드를 사용하여 체크포인트를 생성하는 방식을 조합해서 활용할 수 있다.

이러한 방법도 파일시스템의 고가용성을 궁극적으로 보장하지 않는다. 

네임노드는 여전히 단일고장점(SPOF) - Single Point of Failure 이다. 네임노드에 장애가 발생하면 맵리듀스 잡을 포함하여 모든 클라이언트가 파일을 읽거나 쓰거나 조회할 수 없게 된다.

네임노드는 메타데이터와 파일 블록의 매핑 정보를 보관하는 유일한 저장소이기 때문이다. 이러한 상황이 발생하면 새로운 네임노드가 투입될 때 까지 하둡 시스템 전체는 먹통이된다.

네임노드의 장애를 복구하기 위해 관리자는 파일시스템 메타데이터 복제본을 가진 새로운 네임노드를 구동하고 모든 데이터노드와 클라이언트에 새로운 네임노드를 사용하도록 알려주면 된다.

하지만 새로운 네임노드는 

1)  네임스페이스 이미지를 메모리에 로드하고

2) 에디트 로그를 갱신하고 

3) 전체 데이터 노드에서 충분한 블록 리포트를 받아 안전 모드를 벗어날 때까지 그 어떤 요청도 처리하지 못한다.

많은 파일과 블록이 있는 대형 클러스터에서 네임노드를 재구동할 때 30분 이상 걸리는 경우도 있다.

일상적인 유지 관리에서 재가동 시간이 오래 걸리는 것은 당연히 문제가 된다. 사실 네임노드의 갑작스런 장애는 거의 발생하지 않으며, 실무에서는 계획된 정지시간이 더 중요할 수도 있다.

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

고가용성은 활성대기 상태로 설정된 한 쌍의 네임노드로 구현된다. 활성 네임노드에 장애가 발생하면 대기 네임노드가 그역할을 이어받아 큰 중단없이 클라이언트의 요청을 처리한다. 

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