Secondarynamenode(SNN), fsimage, HDFS Balancer

세컨더리네임노드(SNN)

namenode는 파일시스템에 대한 이미지 관리를 fsimage라는 이름으로, Namenode가 떠있는 디스크에 얘를 저장하게 되어있음.

fsimage는 일종의 스냅샷형태로 관리함. 이 로그는 edits에 저장됨

namenode가 처음 구동되면 fsimage를 쭉~ 읽고, 메모리에다가 스냅샷을 구성함.
그 다음에 edits로그를 다 읽고 변경된 내용을 메모리에 반영함.

Edits로그를 병합해줘야하지 않을까?

파일시스템에서 활동,변경한 내역로그는 모두 edits에 저장되는데 나중을 위해서 edits로그를 병합해줘야한다
어디서 해야할까?

namenode에서는 직접병합을 하지않고, SNN에서 병합을 한다음에, 이를 fsimage스냅샷으로 만들고, 원본 fsimage와 바꿔치기한다

SNN이장애가 난다면 언제 문제가될까?

edits로그가 무한히 길어지게되는데, namenode를 리스타트하는 경우에 edits로그가 너무길어서 → 반영하지 못해서 → outofmemory가 일어난다

Hadoop 2.0

기존(1.0) 버전에서 해결하지 못한 Master 서버의 장애를 해결하기 위한 부분이 가장 큰 변화포인트

StandbyNamenode와 ActiveNamenode(기존의 namenode) 로 이중화구성을진행함

namenode가 죽었을때를 대비해서 standbynamenode로 이중화 구성을 진행했다는게 가장 크다.

이중화를 진행하다보니 fsimage, edit logs를 어떻게 해야할까? 에 대한 고민을 하게됨

HDFS Balancer

하둡클러스터의 확장방식은 Scale up이 아니라, Scale out이다
따라서, 데이터노드의 노드갯수를 늘리는 방식으로 진행되는데 매번 동일한 스펙의 노드를 늘릴수는 없다

클러스터를 구성하는 노드의 성능이 각기 다를수밖에 없으므로, 디스크간의 크기가 다르고, 성능이 달라서
전체데이터가 밸런싱 되지 않을수 있다

이때는 HDFS Balancer가 데이터적재량이 적은 노드를 우선적으로 선정하여 BLOCK을 추가하는게 일반적인데, 이때 특정 노드에 부하가 몰릴수 있음

관련 옵션

• dfs.datanode.balance.max.concurrent.moves : 얼마나 빨리 복사할거냐
• dfs.datanode.balance.bandwidthPerSec : 데이타노드의 bandwidth를 얼마나 줄꺼냐.
  최대한보수적으로 설정하는게 국룰이다.