행복한디벨로퍼

HDFS에서 데이터가 어떻게 쓰여지는지에 대한 프로세스에 대해서 정리하도록 하겠습니다.

해당 내용은 '하둡 완벽 가이드(4판)'을 정리한 내용입니다.

[ HDFS 파일 쓰기 상세 ]

1. 클라이언트는 DistributedFileSystem의 create()를 호출하여 파일을 생성합니다.

2. DistributedFileSystem은 파일시스템의 네임스페이스에 새로운 파일을 생성하기 위해 네임노드에 RPC 요청을 보냅니다. 이때 블록에 대한 정보는 보내지 않습니다. 네임노드는 요청한 파일과 동일한 파일이 이미 존재하는지, 클라이언트가 파일을 생성할 권한을 가지고 있는지 등 다양한 검사를 수행합니다. 검사를 통과하면 네임노드는 새로운 파일의 레코드를 만들고, 그렇지 않으면 파일 생성은 실패하고 클라이언트의 IOException이 발생합니다. DistributedFileSystem은 데이터를 쓸 수 있도록 클라이언트에 FSDataOutputStream을 반환하고 읽을 때와 마찬가지로 FSDataOutputStream은 데이터노드와 네임노드의 통신을 처리하는 DFSOutputStream으로 래핑됩니다.

3. 클라이언트가 데이터를 쓸 때 DFSOutputStream은 데이터를 패킷으로 분리하고, 데이터 큐라 불리는 내부 큐로 패킷을 보냅니다.  DataStreamer는 데이터 큐에 있는 패킷을 처리하고 먼저 네임노드에 복제본을 저장할 데이터노드의 목록을 요청합니다. 데이터노드 목록에 포함된 노드는 파이프라인을 형성하는데, 복제 수준이 3이면 세 개의 노드가 파이프라인에 속하게 됩니다.

4. Datastreamer는 파이프라인의 첫 번째 데이터노드로 패킷을 전송하고 첫 번째 데이터 노드는 각 패킷을 저장하고 파이프라인의 세 번째(마지막) 데이터노드로 전달합니다.

5. DFSOutputStream은 데이터노드의 승인 여부를 기다리는 ack큐라 불리는 내부 패킷 큐를 유지하고 ack큐에 있는 패킷은 파이프라인의 모든 데이터노드로부터 ack 응답을 받아야 제거됩니다. 

6. 데이터 쓰기를 완료할 때 클라이언트는 스트림에 close() 메서드를 호출합니다. 이 메서드는 데이터노드 파이프라인에 남아 있는 모든 패킷을 플러시(flush)하고 승인이 나기를 기다립니다.

7. 모든 패킷이 완전히 전송되면 네임노드에 '파일 완료' 신호를 보냅니다. 네임노드는 DataStreamer를 통해 블록 할당 요청을 받았기 때문에 파일의 블록이 어떻게 구성되어 있는지 이미 알고 있으며, 최소한의 블록 복제가 완료되기를 기다렸다가 최종적으로 성공 신호를 반환합니다. 

[ 데이터를 쓰는 도중 데이터노드 장애 발생시 ]

1. 파이프라인이 닫히고 ack큐에 있는 모든 패킷은 데이터 큐 앞쪽에 다시 추가됩니다.

2. 이렇게 하면 다운스트림(downstream)노드가 실패해도 패킷이 하나도 유실되지 않고 정상 데이터노드는 네임노드로 부터 새로운 ID를 다시 받습니다.

3. 장애가 발생한 데이터노드가 나중에 다시 복구되면 불완전한 블록은 삭제됩니다. 

4. 장애 데이터노드는 파이프라인에서 제거되고, 정상인 나머지 두 데이터노드로 새로운 파이프라인을 구성하고 블록의 남은 데이터는 파이프라인의 정상 데이터노드로 전송됩니다.

5. 네임노드는 해당 블록이 불완전 복제(under-replicated)라는 것을 인식하고 있으므로 나중에 다른 노드에 복제본이 생성되도록 조치하고 후속 블록을 정상적으로 처리합니다. 

감사합니다. 포스팅을 마치도록 하겠습니다:)

오늘은 HDFS 고가용성에 대해서 포스팅 정리~!

해당 내용은 '하둡 완벽 가이드(4판)'에 대한 정리 내용입니다.

[ HDFS 고가용성 ]

데이터 손실을 방지하기 위해 네임노드 메타데이터를 다수의 파일시스템에 복제하는 방식과 보조 네임노드를 사용하여 체크포인트를 생성하는 방식을 조합해서 활용할 수 있다. 그러나 이러한 방법도 파일시스템의 고가용성을 궁극적으로 보장하지는 않는다. 네임노드는 여전히 단일 고장점(SPOF, Single Point Of Failure)이다. 네임노드에 장애가 발생하면 맵리듀스 잡을 포함하여 모든 클라이언트가 파일을 읽거나 쓰거나 조회할 수 없게 된다. 네임노드는 메타데이터와 파일 블록의 매핑 정보를 보관하는 유일한 저장소이기 때문이다. 

[ HDFS 네임노드가 장애났을 경우 새로운 네임노드로 재구동 과정 - HA 구성 아닌 경우 ]

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

1. 새로운 네임노드는 네임스페이스 이미지를 메모리에 로드한다.

2.에디트 로그를 갱신한다.

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

이러한 과정을 거치는데 많은 파일 블록과 대형 클러스터에서 새로운 네임노드 재구성 까지는 30분 이상 걸리는 경우도 있다. (즉, 이런 장애 복구에 걸리는 시간을 감안할 수 있다면 이것도 하나의 방법이 될 수 있다.) 사실 네임노드의 갑작스런 장애는 거의 발생하지는 않는다. 

[ HDFS 고가용성(HA, High availability) - 하둡 2.x 릴리즈부터 ]

위와 같이 재구성하는데 오래걸리는 문제를 해결하기 위해 하둡 2.x릴리즈부터 hdfs의 고가용성을 지원한다. 

고가용성은 활성대비(active-standby)상태로 설정된 한 쌍의 네임노드로 구현된다. 활성 네임노드(active namenode)에 장애가 발생하면 대기 네임노드(standby namenode)가 그 역할을 이어받아 큰 중단 없이 클라이언트 요청을 처리한다. 이러한 방식을 지원하기 위해 HDFS의 구조를 일부 변경했다.

• 네임노드는 에디트 로그를 공유하기 위해 고가용성 공유 스토리지를 반드시 사용해야 한다. 대기 네임노드가 활성화되면 먼저 기존 활성 네임노드의 상태를 동기화하기 위해 공유 에디트 로그를 읽고, 이어서 활성 네임노드에 새로 추가된 항목도 마저 읽는다.
• 데이터노드는 블록 리포트를 두 개의 네임노드에 보내야 한다. 블록 매핑 정보는 디스크가 아닌 네임노드의 메모리에 보관되기 때문이다.
• 클라이언트는 네임노드 장애를 사용자에게 투명한 방식으로 처리할 수 있도록 구성해야 한다.
• 대기 네임노드는 보조 네임노드의 역할을 포함하고 있으며, 활성 네임노드 네임스페이스의 체크포인트 작업을 주기적으로 수행한다.

고가용성 공유 스토리지를 위해 NFS 필러나 QJM(quorum journal manager) 중 하나를 선택할 수 있다. QJM은 HDFS 전용 구현체로, 고가용성 에디트 로그를 지원하기 위한 목적으로 설계되었고 HDFS의 권장 옵션이다. QJM은 저널 노ㅓ드 그룹에서 동작하며, 각 에디트 로그는 전체 저널 노드에 동시에 쓰여 진다.

활성 네임노드에 장애가 발생하면 대기 네임노드는 매우 빠르게(수십초 이내) 기존 네임노드를 대체할 수 있다. 활성과 대기 네임노드는 모두 최신 에디트 로그와 실시간으로 갱신되는 블록 매핑 정보를 메모리에 유지하고 있기 때문이다. 하지만 실제로 장애 복구 시간을 보면 1분 정도 걸리는데, 시스템이 활성 네임노드에 장애가 발생했다고 판단하는 것은 매우 신중해야 하기 때문이다. 

안녕하세요 오늘은 하둡의 네임노드와 데이터노드에 대해서 정리해 보도록 하겠습니다.

해당 내용은 '하둡 완벽 가이드(4판)'에 대한 정리 내용입니다. 

[ HDFS 클러스터 구성 방식 ]

HDFS 클러스터는 마스터-워커(master-worker) 패턴으로 동작하는 두 종류의 노드(마스터인 하나의 네임노드(namenode)와 워커인 여러 개의 데이터노드(datanode)로 구성되어 있다. HDFS 클라이언트가 사용자를 대신해서 네임노드와 데이터노드 사이에서 통신하고 파일시스템에 접근한다. HDFS 클라이언트는 POXIS(Portable Operation System Interface)와 유사한 파일시스템 인터페이스를 제공하기 때문에 사용자는 네임노드와 데이터노드에 관련된 함수를 몰라도 코드를 작성할 수 있다.

[ 네임노드(NameNode) ]

네임노드(namenode)는 파일시스템의 네임스페이스를 관리한다. 네임노드는 파일시스템 트리와 그 트리에 포함된 모든 파일과 디렉터리에 대한 메타데이터를 유지한다. 이 정보는 네임스페이스 이미지(namespace image)와 에디트 로그(edit log)라는 두 종류의 파일로 로컬 디스크에 영속적으로 저장된다. 네임노드는 또한 파일에 속한 모든 블록이 어느 데이터노드에 있는지 파악하고 있다. 하지만 블록의 위치 정보는 시스템이 시작할 때 모든 데이터노드로부터 받아서 재구성하기 때문에 디스크에 영속적으로 저장하지는 않는다. 

[ 데이터노드(DataNode) ]

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

[ 네임노드의 중요성 ]

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

[ 네임노드 장애복구를 위한 하둡 메커니즘 ]

1. 네임노드 로컬 디스크와 원격의 NFS 마운트 두 곳에 동시에 백업하는 것이다.

파일시스템의 메타데이터를 지속적인 상태로 보존하기 위해 파일로 백업해야한다. 

2. 보조 네임노드(Secondary namenode)를 운영

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

결과적으로 안전한 하둡운영을 위해서는 네임노드의 메타데이터를 원격 NFS도 저장하고 보조 네임노드도 운영하는 것이라고 볼 수 있을 것 같다.