[hadoop] Namenode Federation 훑어 보기

hdfs federation

hadoop에서 가장 중요한 노드를 꼽으라면 당연 네임노드가 가장 중요한 노드라고 할 수 있다. 모든 사용자는 hdfs에서 접근하기 위해서 네임노드를 통해서 데이터 노드 위치를 확인하여 데이터 노드에 데이터를 읽거나 쓸 수 있다.

이렇게나 중요한 네임노드는 HA를 위해서 Active, Stand by 노드로 2개 이상 노드로 구성하지만 실질적인 쓰기 작업에는 Active 네임 노드만을 사용한다.(옵저버 네임노드를 사용하면 데이터 읽기는 네임 노드 부하 분산 가능) 그렇기에 Active 네임노드에 문제가 발생하면은 hdfs 자체를 사용할 수 없는 SPOF(단일 장애 지점)이다. 

 

적재되는 데이터 수가 작다면은 생성되는 파일 갯수가 적어 네임노드가 관리해야할 메타 데이터 적어서 괜찮지만, 데이터 수가 많아지면 파일 수도 자연스레 증가하여 네임노드가 관리해야할 메타 정보가 매우 많아져 많은 문제를 유발 한다.

 

추가적으로 많은 부하로 인하여 기존에 Active 네임노드가 failover되어 Stand by 네임 노드가 Active로 전환되어도 메타 데이터 수는 동일하기 때문에 근본적으로 해결할 수 없다. 그리고 Heap 크기를 계속 키우는 것도 GC로 인한 중단 오버헤드와 확장성을 고려하였을 때 좋은 선택지는 아니다.

 

그래서, 너무 많은 메타 데이터로 인한 네임 노드 부하를 분산 시키고자 우리는 federation 적용을 검토할 수 있다.

 

federation은 간단하게 생각해서 작은 하둡 클러스터 여러 개를 하나의 큰 하둡 클러스터로 만든다고 생각할 수 있다. 각 작은 하둡 클러스터는 관리하는 네임 스페이스를 구분하여 자신이 담당하는 네임스페이스의 메타 데이터만을 관리한다.

 

사용자는 하나의 클러스터라고 생각하지만, 내부적으로 여러 클러스터이고 하나의 작은 클러스터에 문제가 발생하더라도 다른 클러스터에는 문제 없이 사용 가능하기 때문에 HA면에서도 좋은 선택지가 될 수 있다.

 

이러한 Federation은 크게 Viewfs를 사용한 방식과 RBF 방식으로 2가지가 존재한다.

 

Overview  

• 네임 노드는 파일 정보 메타 데이터를 메모리에서 관리
• 파일 많아지게 되면 그에 따라서 메타 데이터가 많아져 메모리 사용률 증가
• HDFS Federation은 디렉터리 단위로 네임 노드를 등록하여 사용
• HDFS에서 네임 노드는 단일 실패 지점으로 네임노드에 문제 발생시 모든 작업 중지
• 네임 스페이스 별로 네임 노드를 생성하여 메타 데이터 관리 부하를 분산
• 이를 통하여 특정 네임 노드가 다운되더라도 해당 네임 스페이스에만 영향
  • 다운되지 않은 네임 노드들은 정상적으로 사용 가능

Viewfs 방식

• 일반적인 Federation은 파일 시스템을 하위 클러스터로 분할하고 ViewFS를 통해 하나의 View로 제공
  • 해당 방식의 문제는 사용자가 해당 하위 클러스터에 대한 폴더/파일  할당을 강제하여 분할을 유지
• 각 네임 서비스마다 독립적인 네임스페이스 view를 생성
• 위 이미지에서 4개의 독립적인 네임스페이스 볼륨을 하나로 마운트하는 테이블 표현

viewfs 구조

• 데이터 노드들 공유해도 되고 공유하지 않아도 됨 (그림에서는 공유하는 방식)
• 네임 서비스(네임 노드)에 따라서, 데이터 접근하는 경로가 변경
• hdfs:// 사용 대신 viewfs:// 를 사용해야함
  • hdfs://을 사용하고자 한다면 하위 클러스터로 중에 하나로만 접근 가능

 

Router-based Federation(RBF)

• 네임스페이스 페더레이션을 위한 새로운 소프트웨어 계층(router) 도입
• 이 해당 Router가 모든 하위 클러스터에 투명한 접근을 제공
  • 데이터노드를 공유하지 않음
• 하위 클러스터가 독립적으로 블록 풀을 관리하게 함
• 라우터 
  • 클라이언트 요청에 대한 인터페이스 역할
  • 네임노드와 유사
  • 상태 저장소에 의해 제공된 정보를 통해서 클라이언트 요청을 적절한 하위 클러스터로 전달
• 상태 저장소 (state router)
  • 클라이언트 요청의 라우팅과 연합 관리에 필요한 중요 정보를 유지
  • 두 가지 소스에서 데이터를 결합
  • 원격 마운트 테이블
    • ViewFS와 유사하지만 클라이언트 간에 공유되는 테이블
    • 논리적 경로와 해당 경로에 책임임이 있는 하위 클러스터 간의 매핑 정보 저장
  • 이용 정보
    • 하위 클러스터의 부하 및 용량 지표를 포함
    • 데이터 라우팅과 부하 분산에 대한 정보로 연합 계층에 능동적인 결정하는데 사용
• 하위 클러스터
  • 개별 HDFS 클러스터
  • 자체 블록풀을 독립적으로 관리
  • 확장성과 내결함성을 갖음
• 다중 서브클러스터 마운트 포인트
  • 여러 서버 클러스터들 하나의  마운트 지점으로 설정 가능
    • 마운트 설정을 통해 하위 클러스터로 파일과 디렉터리를 분산

[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /data ns1,ns2 /data -order SPACE

• 위 명령어는 '/data' 경로를 ns1과 ns2 네임스페이스에 분산
• 분산 전략에 따라서, 여러 네임노드에 고르게 분산
  • HASH: 첫 번째 레벨에서 일관된 해싱
  • HASH_ALL: 모든 레벨에서 일관된 해싱
  • LOCAL: 로컬 서브클러스터에 데이터 쓰기 시도
  • RANDOM: 임의의 서브클러스터를 선택(폴더는 모든 서브클러스터에 생성)
  • SPACE: 가장 많은 여유 공간을 가진 서브클러스터에 쓰기(폴더는 모든 서브클러스터에 생성)

Router-based Federation 구조

• 라우터가 사용자에게 어떤 네임 서비스로 가야하는 알려줌
• 하위 클러스터 구성은 자유롭게 가능
  • 데이터 센터간에 클러스터링도 가능
• 같은 Path에 대해서도 여러 클러스터 마운트 가능
  • viewfs 방식에서는 같은 path로 마운트 불가능
• 기존과 동일하게 hdfs:// 방식 사용 가능
• 실제 많은 대규모 빅데이터 운용하는 회사에서 채택하는 방법
  • 트위터(현 X), 야후, 라인, 링크드인....

비교

	viewfs	RBF(Router Based Federation)
데이터노드 공유	데이터 노드를 공유 / 분리 가능	데이터 노드 분리
통합 네임스페이스	네임스페이스 통합 가능	네임스페이스 통합 가능
확장성	제한적	확장성 높음
다중 서브클러스터 마운트 포인트	동일한 경로에 대해서 한 클러스터만 사용 가능	동일한 경로에 대해서 여러 클러스터에 분산  사용 가능
설정 복잡성	낮음	복잡
hdfs:// 경로 사용	불가능 (viewfs:// 로 변경 필요)	hdfs:// 사용 가능
Mount table 변경	재기동 필요	온라인 변경 가능

 

마무리

회사 업무겸 혼자 정리한 내용이니 너무 신뢰하지는 마시고, 이상하다 싶으면은 댓글 남겨주세요. 🫠

참고 자료

1. https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/Federation.html
2. https://haejun-kim.tistory.com/64
3. https://innovation.ebayinc.com/tech/engineering/enabling-hdfs-federation-having-1b-file-system-objects/
4. https://blog.x.com/engineering/en_us/a/2015/hadoop-filesystem-at-twitter
5. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/ViewFs.html
6. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs-rbf/HDFSRouterFederation.html
7. https://bloodguy.tistory.com/entry/Hadoop-HDFS-Federation-NameNodeHA

[Hadoop] HDFS Federation + NameNodeHA