11.1 HDFS

11.1.1 영속적인 데이터 구조

네임노드 디렉터리 구조

VERSION 파일

• in_use.lock 네임노드가 스토리지 디렉토리를 잠그기 위해 사용하는 lock 파일. 다른 네임노드 인스턴스가 같은 스토리지 디렉토리를 가지고 동시에 작업하는 것을 막기 위는 역할을 함.
• clusterID 는 HDFS 클러스터 전체의 유일한 식별자 → HDFS 페더레이션 때에 중요한 역할을 함. HDFS 페더레이션을 사용하는 경우, 그 클러스터는 여러 개의 네임스페이스로 구성되며, 각 네임스페이스는 하나의 네임노드가 관리

파일시스템 이미지와 에딧 로그

• 네임노드는 FS 메타데이터를 인메모리(파일과 메모리 양 쪽에 데이터를 유지하는 방식)로 관리하는데, 에딧 로그를 먼저 변경한 후, 메모리상의 메타데이터도 변경한다.
  • 클라이언트가 쓰기 동작을 하면 이는 에딧 로그에 내역이 기록됨
  • 클라이언트의 읽기 요청에는 인메모리 메타데이터만 활용된다.
• 에딧 로그는 로지컬하겐 하나지만, 디스크에선 여러 파일로 관리되는데, 이 파일 각각을 “세그먼트”라고 함.
  • 접두사 edits와 트랜잭션 ID를 의미하는 접미사로 구성됨.
  • 네임노드는 쓰기 작업이 끝날 때마다 성공했다는 결과를, 클라에 알려주기 전에 에딧 로그를 flush 해서 먼저 동기화한다. (모든 디렉토리의 에딧 로그에 반영)
• fsimage는 파일시스템 메타데이터의 완전하고 영속적인 체크포인트이다.
  • 그러나 쓰기 동작이 있다고 해서 무조건 fsimage를 변경하지는 않는데, fsimage가 GB 단위로 커지면 성능이 매우 저하되기 때문이다.
  • 그리고 복구할 때도, fsimage를 먼저 메모리 로드한 후에, fsimage 시점 이후의 내용은 에딧 로그에서 가져와서 복원한다.
  • 각 fsimage 파일은 파일시스템에 존재하는 모든 디렉터리와 파일 의 inode 정보를 직렬화한 파일이다.
    • 각 inode는 파일이다 디렉터리 메타데이터의 내부 구조를 나타내며, 파일 복제 수준, 변경 및 접근 시간, 접근 권한, 블록 크기, 파일 구성하는 블록 집합과 같은 정보를 갖고 있다.
    • 블록이 실제 저장된 데이터노드 정보는 fsimage에 기록하지 않는다. 대신 네임노드는 매핑 정보를 메모리에서 따로 관리한다.
• 에딧 로그가 너무 커지면 복구에 오랜 시간이 걸린다. → 이를 해결하기 위해 세컨더리 네임노드를 둔다.
  • 세컨더리 네임노드 용도는 주 네임노드의 메모리에 있는 fs metadata의 체크포인트를 만드는 것이다.

1. 세컨더리 네임노드는 주 네임노드에게 ‘사용 중인 edits 파일을 이터레이팅 할 것을 요청한다.’ 이제부터 새로 발생하는 edits 로그는 새로운 파일에 저장된다. 주 네임노드는 모든 저장소 디렉터리의 seen_txid 파일을 변경한다.
2. 세컨더리 네임노드는 HTTP GET 방식으로 주 네임노드에 있는 최신 fsimage와 edits 파일을 가져온다.(결국 에딧로그 하나하나를 의미)
3. 세컨더리 네임노드는 fsimage 파일을 메모리에 올리고 edits 파일의 각 변경 내역을 적용한다. 그리고 병합된 새로운 fsimage 파일을 생성한다.
4. 세컨더리 네임노드는 이 fsimage 파일을 HTTP PUT 방식으로 주 네임노드에 전송하고, 주 네임노드는 이 받은 파일을 .ckpt 확장자를 가진 임시 파일로 저장한다.
5. 주 네임노드는 임시 저장한 fsimage 파일의 이름을 변경해서 사용 가능하게 만든다.

→ 세컨더리 네임노드가 주 네임노드와 비슷한 메모리 용량이 필요한 이유이기도 함. (fsimage 파일을 메모리에 올려야 하기 때문)