HDFS Federation

xlos
개발관련팁/Hadoop
2012. 1. 12.

Hug - March - HDFS Federation

View more presentations from Yahoo! Developer Network

Hadoop World 2011에서 발표되었던 HDFS Federation 요약

video를 보고 이해한 거 + 대략적인 소스 분석을 토대로 한 거라 틀린 부분이 있을 수도 있음

한 마디로 요약하면? 하나의 cluster에서 여러 namespace (namenode)를 쓸 수 있도록 한 것! 왜 이런 걸 했는지, 어떻게 했는지, 그리고 앞으로는 어떻게 발전할 것인지에 대해 소개함.

현재 HDFS Architecture에 대한 요약 : 자세한 내용은 여기 참조
1. Namespace와 Block Storage의 조합
2. Namespace : directory, file, block으로 구성 / file 및 directory에 대한 create, delete, modify, list를 지원
3. Block Storage : Datanode membership 관리 / block에 대한 create, delete, modify, get 을 지원 / 복제 계수 관리
4. 현재는 cluster 전체에 하나의 Namespace Volume이 존재, namespace는 하나의 namenode에 올라감
  1. 전체 namespace는 namenode의 메모리에 올라가며, block file들은 datanode의 local file system에 저장됨
무엇이 문제인가?
1. Scalability : datanode만 추가하면, 용량은 쉽게 증가하지만, namespace자체는 그렇지 않음
  1. 메모리의 한계로, namespace의 file와 directory 개수에 제한이 있음
    1. 64 GB 메모리에 약 2억 5천 만개의 파일과 block들이 저장
  2. 여전히 매우 큰 클러스터라고 할 수 있지만.. (Facebook은 약 70 PB를 저장함)
2. Performance : namenode가 하나이므로, 당연히 throughput에 제약이 있음 (한 대가 아무리 좋아 봐야 몰리면.. 뭐..)
  1. 120,000 read ops / sec & 6,000 write ops / sec (write를 할 때는 file로 edit log를 떨궈야 하기 때문에 느림)
  2. 코드 최적화를 통해 20,000 write ops / sec 정도까지는 쉽게 올릴 수 있음
  3. 아무리 최적화를 하더라도, 한 대로 서비스를 하면 bottleneck이 생길 수 밖에 없음
3. Poor Isolation : 모든 사람/application이 하나의 namespace를 쓰는 문제
  1. 최적화가 덜된 실험적인 job과 상용 job이 하나의 namespace를 사용하는 것은 문제
  2. production cluster에서 하나의 테스트 job이 파일을 어마어마하게 생산하고 지우는 무식한 작업을 한다면, 다른 중요한 job들이 실행되는데도 영향을 끼침
4. Tight Coupling : 따지고 보면, Namespace와 Block 관리는 서로 다른 분리된 서비스들임. 그런데 엮여 있다 보니 scaling하기 복잡함.
  1. 현재는 모두 namenode 관련 코드로 묶여있음
  2. 두 가지를 분리하여, block 관리도 단순화하고, namespace도 단순화하자!
  3. 궁극적으로 Block Storage 서비스를 일반화 하자.
    1. 이 경우, namespace는 block storage를 사용하는 하나의 어플리케이션이 되는 것
    2. 그 외 HBase 등도 block storage 서비스를 사용할 수 있음
사실 scaling 보다는 isolation이 더 문제임
1. namenode에 64 GB 메모리만 꼽으면, 대부분의 cluster에서는 큰 문제가 안됨 (HDFS 특성 상 2억 개를 넘는 file을 저장할 일이 있을까?)
2. 하지만, 다른 종류의 application들에게 독립적인 namespace를 제공해주는 것은 cluster의 크기가 작더라도 필요함
HDFS Federation
1. 하나의 cluster에 여러 개의 독립된 namenode들과 namespace volume이 존재
2. Block Storage는 일반적인 storage service 처럼 사용됨
  1. 1423 번 block에 xxx~~라는 내용을 저장하고, 이 block을 세 개 정도 안전하게 복사해주세요!
  2. 가장 가까이 있는 서버에서 2698 번 block을 읽고 싶어요!
  3. 이런 느낌?
3. Block Pool
  1. 하나의 namespace는 하나의 block pool을 가짐
  2. 이전에는 datanode에게 1234 번 block에 저장해주세요~ 라고 요청했다면, 이제는 9876번 block pool (namespace 별로 unique하게 생성됨)에 1234번 block에 저장해주세요~ 라고 변경됨
    1. 즉, namenode와 datanode 사이에 block pool이라는 layer가 하나 더 생긴 것
  3. 기존의 block은 block id (long)로 구분되지만, block pool에서 사용되는 ExtendedBlock은 pool id (string)와 block id (long)로 구분됨
    1. pool id는 "BP-" + rand + "-"+ ip + "-" + System.currentTimeMillis(); 와 같이 생성되며 (NNStorage.java의 newBlockPoolID() 참조), 하나의 namespace가 고유의 block pool id를 가짐
  4. datanode들은 모든 namenode의 namespace에 소속되며, (몇 개의 datanode가 하나의 namenode에 종속되는 개념이 아님) 모든 namespace의 block들을 독립적으로 저장.
    1. 이전 : /dfs/data/current/blk_-291620265307745070 와 같이 저장
    2. 0.23이후 : /dfs/current/block_pool_id/current/blk_-291620265307745070 와 같이 저장 (수정필요)
좋은 점은?
1. 분산된 namespace : 여러 개의 namenode들로 분산됨
  1. 독립된 master (namenode)구조이므로 단순하고 robust함
  2. namenode code는 거의 고치지 않았으므로, 이전의 namenode 안정성을 그대로 유지
2. Block Pool이 하나의 일반적인 storage service로 제공됨
  1. 각각의 namespace volume은 독립적임 (하나의 namenode가 죽어도, 다른 namenode에는 영향이 없음)
  2. 새로운 innovation와 빠른 발전을 가져올 것임
    1. 예컨대, 다양한 garbarge collection scheme이 적용된 tmp storage 라던가
    2. 좀 더 효율적인 distributed cache 라던가
    3. small object storage 등등..
좀 더 상세한 사항
1. Namenode code는 거의 안 고치고, 대부분 datanode code와 config, tool code들이 수정됨
2. core 개발은 4개월 만에 끝남
3. namespace와 block management는 여전히 namenode에 남아 있음
  1. 미래에는 block management 부분은 namenode 밖으로 나갈 수도 있음
4. 현존하는 cluster 배포에도 큰 영향이 없도록, 예전 설정으로도 동작이 가능함
5. Cluster Web UI가 multi namespace를 지원할 수 있도록 수정됨
6. 각종 tool들이 수정됨
  1. datanode들이 여러 namespace에서 decommission이 가능하도록 변경
  2. balancer가 여러 namespace에서 동작하도록 변경
    1. datanode들의 저장용량 뿐만 아니라, block pool storage에서도 balancing 이 가능
7. federated cluster에서 namenode를 추가/삭제할 때, 전체 cluster 재시작 없이 가능
8. 하나의 설정 파일로 namenode와 datanode 모두에 적용
Namespace 관리
1. /data/test.txt 파일은 어느 namespace를 봐야 할까?
2. global namespace는 존재하지 않음
3. client에 mount table이 존재함
  1. e.g.) /data/ –> NS1
    /project/ –> NS2
    /home/ –> NS3
    위와 같은 mount table이 설정 파일로 존재
Next Step
1. namespace와 block management layer의 완전한 분리
2. 좀 더 나은 scalability를 위해 namespace에서 부분적인 내용 (e.g. 자주 access되는 file)만 memory에 올리고 나머지는 파일로 저장
3. 실제 data copy (datanode들 사이의 block copy)없이 하나의 namespace를 다른 namespace로 이동