[발 번역] HA Namenode for HDFS with Hadoop 1.0 – Part 1

해당 블로그는 KT UCloud의 지원을 받고 있습니다.

해당 글은 http://hortonworks.com/blog/ha-namenode-for-hdfs-with-hadoop-1-0-part-1/ 을 발 번역한 것입니다. 이전까지 하둡의 가장 큰 문제점은 NameNode의 SPOF였습니다. 쉽게 장애가 나지는 않지만, 장애가 나면, 그걸로 복구가 될 때까지는 서비스가 완전히 중단이 되어버리는 문제가 있습니다. 그래서 페이스북의 아바타 노드라든지(이것도 중간의 NFS 계층등에서 문제의 SPOF가 여전히 증가하는…) 이런 이슈들이 있습니다. 사실 Hadoop 1.0에서 추가된 HA라는게 아바타 노드랑 거의 동일한 기능이라 이걸 아시는 분들은 크게 관심을 안가지셔도 될듯 합니다. 그럼 오역에 주의하세요.

HA Namenode for HDFS with Hadoop 1.0 – Part 1

August 28th, 2012

Introduction

HDFS를 위한 HA NameNode 는 작년 부터 개발중이었습니다. 그리고 그 노력은 주로 하둡 2.0의 NameNode의 자동 Failover에 주로 집중되었습니다. 그 기간동안 우리는 두 가지를 깨달았습니다.

첫번째로, HA 문제에 대해서 외부에서 내부로의 접근 방법을 이용할 수 있다는 것입니다. 전체적인 하둡 시스템의 HA 디자인으로 부터 시작하고, 그리고 개별 컴포넌트의 기능에 대해서 집중하는 것입니다. 해당 노력은 Full Stack HA Architecture 로 이어졌습니다.

두번째로, Linux HA 와 vSphere 같은 이미 필드에서 검증된 솔루션을 이용해서 하둡 1.0에 NameNode의 HA를 구축할 수 있다는 것입니다. 이것은 하둡 2에서 HDFS가 겨우 베타 테스트 단계인 것에 비해서 하둡 1의 HDFS는 안정적이고 신뢰할 만하다는 것이 이미 검증되었다는 면에서 중요합니다. 해당 포스트에서는 하둡 1에서의 HDFS NameNode HA 의 몇 가지 기술적인 상세한 부분에 대해서 설명합니다. 차후에는 Full Stack HA 의 좀 더 상세한 부분에 대해서 논의하도록 하겠습니다.

사용자들에게 가장 중요한 질문은 “하둡 1과 하둡 2의 HA 는 무엇이 다른가?” 입니다. 동료 Suresh 와 나는 하둡 2를 위한 기본 디자인을 작성했습니다. 그리고 구현에 대해서 커뮤니티를 통해 가깝게 일했습니다. 하둡 1에서의 HA는 해당 작업 동안의 우리의 경험의 직접적인 결과물입니다.

하둡 2 HA에서는 다음 세 가지에 초점을 맞추고 있습니다.

  • Hot failover: Failover 동안에 몇가지 작은 차이점이 있습니다. 작은 규모와 중간 규모의 클러스터를 위해서 cold 와 hot failover 가 있는데, 하둡 1에서는 cold Failover를 사용합니다.
  • Automatic failover: 하둡 2에서 Failover 컨트롤러를 사용하는 반면에 하둡 1에서는 이미 필드에서 검증된 HA 프레임워크를 이용합니다. 아래 그림에서 설명되듯이, 하둡 1에서의 NameNode HA 는 Linux HA를 사용합니다.
  • Remove dependency on shared storage: 이 부분은 trunk[6]의 Journal 데몬을 위해서 작업 중입니다. 하둡 1과 하둡 2 모두에서 공유 스토리지를 사용합니다.

요약하면, 하둡 1 HA는 cold failover 이고, 표준적인 HA 프레임워크들을 이용합니다. 이 차이점들에 대해서 자세히 살펴보기로 하겠습니다.

Failover Times and Cold versus Hot Failover

Active-Passive failover 형태의 HA 시스템에서의 Failover 동안에는 Active 서비스가 장애라는 것을 발견하는 시간이 들어가고, 리더를 선출하거나, failover를 결정하고 다른 것들과 커뮤니케이션 하는 시간도 들어가며, 대기중인 서비스를 active로 변환하는 시간도 필요합니다.

첫번째나, 두번째 항목은 cold나 hot failover 에서 공통적으로 필요합니다. 둘 다 heartbeat 타임아웃에 의존해서, 타임아웃을 모니터링 하거나등의 방법을 이용합니다. 장애 감지를 위한 시간과 장애의 종류에 따라서 Active 서버나 서버의 운영체제에 장애가 있을 때 일반적으로 30초 부터 2.5분 까지 다양한 리더 선출 과정 시간을 관찰했습니다.  행이 걸린 프로세스는 가비지 콜렉션에 의해서 블록된 것이 아닌지에 대한 확인할 수 있는 시간이 필요하므로 더욱 더 시간이 걸립니다.

세번째 항목의 경우, standby 에서 active 로 넘어가는 시간은 하둡 1에서는 세컨드 NameNode를 실행하고 NameNode가 safe mode에서 빠져나오는데 걸리는 시간입니다. 경험상 다음과 같은 시간이 걸렸습니다.

  • 300TB의 스토리지를 사용하고 6백만 개의 블럭을 가지고 십만개의 파일을 가지는 60개의 노드로 구성된 클러스터에서 30초가 걸렸습니다. 그리고 총 Failover 시간은 1~3분 정도 걸렸습니다.
  • 2천만개의 블러과 1PB의 스토리지 백만개의 파일을 가진 200 노드로 구성된 클러스터에서는 110초가 걸렸습니다. 그래서 총 Failover 시간은 4.5분 정도 였습니다.

Industry Standard HA Frameworks

하둡 HDFS NameNode HA 디자인 문서에서 얘기했듯이,  NameNode 외부에 Failover 컨트롤러를 가진다는 아이디어는Linux HA[1] 와 RedHat HA[2], 그리고 Veritas Cluster[4,5] 등의 프레임워크 같은 것들로 부터 영향을 받았습니다. 하둡 커뮤니티의 결정의 일부로, 하둡 외부에서 솔루션 형태로 제공하는 것이 유용하다고 느껴기 때문에 자체 Failover 컨트롤러를 만들기로 했습니다. Linux HA는 GPL이 되어야 했기 때문에, 사용할 수 없었습니다.

하둡 1에는 trunk 로 부터 failover 컨트롤러를 백포트 하지 않기로 결정했습니다. 대신에 필드에서 표준적인 솔루션을 쓰기로 했습니다. 왜일까요?

가능한한 위험이 없는 방식으로 현재 안정적인 하둡에 HA를 추가하길 바랬기 때문에, 모니터링 타임아웃, 서비스 시작 타임아웃, 종료 타임 아웃, 반복되는 장애를 다루는 검증되고 안전한 방식을 사용했습니다. 전원 관련 솔루션을 포함해서 여러가지 대안 솔루션을 제공했습니다.

이 같은 프레임워크는 Job-Tracker 같은 다른 하둡 서비스의 Failover에도 사용될 수 있습니다. 이미 HA Job-Tracker 를 만드는 작업을 시작했고, HA NameNode 를 위한 장비들을 위한 공통 pool로 공유될 수 있는 기능을 제공했습니다. JobTracker 와 다른 마스터 데몬들은 N-N, N-on-N, N+K Failover를 허용합니다. 최종적으로 수동으로 전환할 수 있는 기능을 제공했고, NameNode 중에 하나가 다운되거나 정지하도록 조정가능합니다.

많은 고객들은 이미 이런 HA 프레임워크를 경험했습니다. Namenode IP 주소를 일정하게 유지하는 Failover 솔루션을 이용해서 사용자와 webHDFS를 통해 어플리케이션도 웹 인터페이스를 통해서 Failover 를 보장합니다. 서비스가 어디서 동작하는지에 상관없이 URL은 서비스에게 맞게 적용될 것입니다. 성숙한 IP failover 기반 솔루션을 사용하는 것은 Failover 솔루션의 복잡도를 줄여주고, 하둡 Core에 적은 수정과 위험만을 가지고 안정적인 하둡 1.0에 HA를 구현하는 것을 가능하게 만들어주었습니다.

최근에, Symantec 에서 독립적으로 Veritas Cluster[5]를 이용해서 NameNode를 어떻게 HA 하도록 만들 것인가에 대해서 발표했습니다. 위에서 하둡 1에서의 LinuxHA를 이용한 NameNode HA를 설명했고 vSphere HA를 이용한 유사한 솔루션이 사용가능할 것입니다.

FAQ

    • cold failover만 이용하므로 실용적이지 못해요.

HDFS 2.0 HA 디자인은 야후나 페이스북등의 매우 큰 클러스터의 필요성에 의해서 나오게 되었습니다. 중소규모의 클러스터의 경우 cold failover는 위에서 얘기한 것과 같이 30에서 120초 가량 느립니다.

    • Linux HA를 이용해서 Failover 하는 것이 그렇게 쉽다면, 왜  HDFS 커뮤니티는 좀 더일찍 Linux HA나 다른 툴을 이용해서 Failover 작업을 하지 않았나요?

이것은 원래 HDFS 팀에서 cold failover 가 실용적이지 못한 매우 큰 규모의 클러스터에만 집중해서 그렇습니다. 하둡에 자체적인 솔루션이 있어야 한다고 생각했고, 해당 기술만 개발 하였습니다.  그러나, 고객들은 직접적으로 HA 솔루션은 복잡하고, 고객들은 이미 존재하고 잘 이해할 수 있는 솔루션을 선호한다고 말해주었습니다.

    • 하둡 2의 HA에서는 다른 방법을 사용하지 않나요?

사실이 아닙니다. 둘 다 같은 디자인 원칙에 기반하고 있습니다. 단지 차이는 warm failover 대신에 cold failover에 초점을 맞찬다는 것 뿐입니다. 게다가, 해당 작업은 무료입니다. 하둡 1.0 코드의 모든 작업은 하둡 2.0 코드에 역시 반영되었습니다.

    • Linux HA 나 다른 프레임워크를 사용해보고 싶은데, 그거 어려운가요?

대다수의 하둡 상요자들은 이미 Linux HA, RedHat HA, Veritas Cluster 나 vSphere HA등의 솔루션을 그 들의 데이터 센터 안에서 사용하고 있습니다. Linux HA는 공짜로 이용가능하고, RedHat의 HA 솔루션은 가격이 쌉니다.

    • Full Stack HA는 오직 하둡 1의 일부분인건가요?

아닙니다. Full Stack HA는 NameNode나 JobTracker(this post) 등의 특정 컴포넌트의 Failover를 지원하기 위한 것입니다. Stack의 나머지 부분을 일시적인 장애에 안정적으로 만드는 것은 Stack 전체를 발전시킵니다. 다음번 포스트에서 Full Stack HA에 대해서 더욱 상세하게 다루도록 하겠습니다.

    • vSphere HA는 서비스 장애가 아닌 VM 장애를 다루기 위한 것 아닌가요?

vSphere는 어플리케이션 레벨의 헬쓰 체크도 지원합니다. NameNode를 위한 어플리케이션 레벨의 모니터를 추가하면 됩니다. 비슷하게 JobTracker 를 위한 모니터도 금방 이용할 수 있을 것입니다.

    •  NameNode 와 Job Tracker를 vSphere VM 에서 사용하는 것은 성능이나 확장에 제한을 주지 않나요?

소규모 클러스터에서, vSphere VM 에 마스터 서비스를 운영하는 것은 매우 효율적인 디자인입니다. vSphere 는 각각의 VM을 독립적으로 모니터링 하고 관리하기 때문에, vSphere 서버는 NameNode, JobTacker 다른 마스터 서비스들을 독립적으로 운영할 수 있습니다. 만약 하나의 서비스가 장애가 나면, 다른 VM들이 중단되지 않고 진행되는 동안에, 장애난 VM만 종료되고 재시작됩니다. VM이 제공하는 롤백과 유지의 편이성을 얻을 수 있습니다.

Status

모든 패치가 Apache Hadoop trunk 와 1.1 브랜치의 core hadoop에 적용되었고, Hortonworks HDP 1과 HDP 1.1에도 포함되어 있습니다. 이것들은 Hadoop 2-alpha에도 적용될 계획입니다.

모니터링 코드는 아직 인큐베이팅 중인 Ambari project 에 포함되는 것을 목표로 하고 있고, 패치[8] 는 이미 제출되었습니다.

vSphere 와 RedHat HA 에서 하둡 1 설정을 위한 문서는 웹사이트에서 이용가능합니다.

Future Outlook

현재 베타 테스팅에 들어가 있고, 하둡 2의 HA(Hot Failover, failover controller 등등) 에 들어갈 HDFS2 를 안정화하기 위한 작업은 계속 진행중입니다. 다른 하둡 컴포넌트에 Failover를 제공하기 위한 노력도 계속 진행중입니다.(예를 들어, 하둡 1의 JobTracker)

마지막으로, 잘 관리되는 하둡 클러스터에서는 어떤 종류의 마스터 장애라도 잘 발생하지 않는 다는 것을 기억해둘만한 가치가 있습니다. 정기적인 시스템 유지보수는 클러스터를 안정적으로 컨트롤 할 수 있는 방법이기 때문에, 정기적으로 클러스터를 오프라인으로 만들어서 점검하고 있습니다.

References

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s