아파치 하둡을 위한 하드웨어 추천[번역본]
아파치 하둡을 위한 하드웨어 추천
하둡과 HBase workloads(이하 워크로드)는 너무나 다양한 형태들이 있어서 여러 가지 작업들에 필요한 저장량이나 프로세싱 파워, 인터노드 커뮤니케이션 등을 정확하게 예상하는 데에는 시간이 걸린다.
이 문서는 비용과 성능의 최적 조화를 위한 적절한 하드웨어 구성을 고르는데 필요한 지식을 제공할 것이다.
이 섹션에는 :
오버뷰
전형적인
하둡 클러스터
전형적인
하둡 워크로드 패턴
발란스드
워크로드 디플로이먼트(배치)
서버
노드 하드웨어 추천
HBase를 위한 하드웨어 결정
다른
이슈들
결론
더
읽을 거리
#### 오버뷰
하둡은 거대한 스케일의 분배 데이터 분석을 지원하는 소프트웨어 프레임워크이다.
Hortonworks(이하 호톤웍스)는 오픈 소스 운동(아파치
하둡, HDFS, 피그, 하이브, HBase, 주키퍼)의 가장 큰 공헌자이며, 하둡 클러스터 프로덕션 레벨을 운영하는 것에 대한 많은 경험을 가지고 있다.
호톤웍스는 드라이브를 크게 더 나아가 하이퍼 스케일로 디플로이할 디자인 원칙을 추천한다. 하둡이나 H베이스 클러스터를 위해,
사이즈, 타입, 프리퀀시(주파수), latency(잠복, 잠재) 등을 정확하게 예측하는 것은 분석 작업을 위해 매우 중요한 일이다. 하둡과 HBase를 시작할 때, 첫 프로젝트 동안 정확한 워크로드를 측정하면서
경험을 축적해봐라. 그러면서 당신은 서버, 소프트웨어, 디플로이먼트 전략과 네트워크 등을 크게 건드리지 않고도 사용자 환경을 조정할 수 있게 될 것이다.
#### 전형적인 하둡 클러스터
하둡과 HBase 클러스터는 두 가지 타입의 머신을 가지고 있다 : 마스터(HDFS 네임노드, 맵리듀스 JobTracker, HBase 마스터) 와 슬레이브(HDFS 데이터노드, 맵리듀스
TaskTrackers, HBase 지역서버)가 그것이다.
데이터노드, 테스크츄레커(일 사냥꾼), HBase 지역서버는 연결되어있거나 혹은 최적 데이터 분배를 위해 협력 배치(co-deployed) 되어 있다.
덧붙여, HBase는 자신의 클러스터를 운영하기 위해 독립적인 구성물
– 주키퍼 – 의 사용을 필요로 한다.
호톤웍스는 마스터와 슬레이브 노드를 분리할 것을 추천하는데 이유는 다음과 같다
:
– 슬레이브 노드의 테스크 워크로드는 마스터로부터 고립되어야만 하기
때문.
– 슬레이브 노드는 유지보수를 위해 자주 퇴역되기 때문.
평가 목적을 위해 당신은 싱글 노드 인스톨레이션을 이용하여 (모든
마스터와 슬레이브 프로세스는 머신 안에 그대로 있는 채로) 하둡 디플로이를 선택할 수 있다. 작은 클러스터(노드 2개)를 세팅하는 것은 매우 간단한 일이다. 한 노드는 네임노드와 잡츄레커
역할을 하고 다른 한 노드는 데이터노드와 테스크츄레커 역할을 하면 된다. 셋 이상의 클러스터는 전형적으로
전문 네임노드/잡츄레커를 사용하며 다른 노드들은 슬레이브 노드가 된다.
전형적으로 두세 층의 구조로 구성된 중대형 하둡 클러스터는 렉마운티드(rackmounted)
서버를 이용하여 빌트된다. 각각의 렉서버들은 1 기가비트
이더넷(GbE) 스위치를 통해 상호 연결된다.
각각의 렉레벨 스위치는 클러스터 레벨 스위치(이것은 보통 포트덴시티(밀집도) 10GbE 스위치이다. )와
연결되어있다.
이 클러스터 레벨 스위치들은 또한 다른 클러스터 레벨 스위치와 상호연결 되어 있고 심지어 스위칭 장비의 다른
레벨로 업링크 할 수도 있다.
그림
#### 전형적인 하둡 워크로드 패턴
디스크 공간이나 I/O 대역폭 (하둡에
의해 요구되는), 그리고 계산을 위한 전력(맵리듀스를 위해
요구되는)은 정확한 하드웨어 사이징을 위한 가장 중요한 매개변수이다.
덧붙여, 만약 당신이 HBase를 깐다면, 당신은 또한 당신의 어플리케이션과 그 어플의 메모리 요구사항을 분석해야 한다.
HBase는 메모리에 민감하다.
전형적인 하둡 사용 케이스에 근거하여 아래의 워크로드 패턴들이 프로덕션 환경에서 보통 사용된다.
발란스드(균형잡힌) 워크로드
만약 당신의 일이 여러가지 잡 타입들(CPU 바운드, 디스크 I/O 바운드, 네트워크 I/O 바운드)을 공평하게 분배해야 하는 것이라면, 당신의 클러스터는 발란스드 워크로드 패틴이 적합하다. 이것은 워크로드의
내용을 모를 때도 유용한 디폴트 패턴이다.
컴퓨트 인텐시브(컴퓨터 친화적인)
이 패턴은 CPU 바운드이고 여러 개의 CPU와 프로세스 데이터를 저장하기 위한 큰 용량의 메모리에 대한 요구 때문에 만들어 졌다. (이 사용 패턴은 자연언어(컴퓨터 언어가 아닌 언어: 역주) 프로레싱이나 HPCC 워크로드에
적합하다.)
I/O 인텐시브(I/O 친화적인)
전형적인 맵리듀스 잡(예컨더 솔팅)은
계산 전력은 아주 작게 요구하지만 클러스터의 I/O 바운드 용량은 크게 요구한다. (예컨데 당신이 콜드 데이터(사용빈도가 낮은 데이터: 역주)를 많이 가지고 있는 경우)
하둡 클러스터는 그런 워크로드를 보통 I/O 인텐시브로 활용한다. 이 타입의 워크로드로 우리는 더 많은 박스 당 디스크(disks per box)를
조사할 수 있다.
알려지지 않은 혹은 조금씩 알려지고 있는 워크로드 패턴
하둡 클러스터를 빌드하려는 대부분의 팀들은 그들의 워크로드 패턴이 무엇인지 모르는 경우가 많다. 또한 하둡을 쓰다 보면 설정과 프로덕션 환경의 실제 일이 너무나 다르다는 것을 느끼게 된다. 그러므로 호톤웍스는 당신이 발란스드 워크로드 설정을 사용하든지, 아니면
하둡 클러스터도움말을 참조해서 당신에 환경에 맞는 워크로드 패턴을 분석하기를 추천한다.
#### 발란스드 워크로드 디플로이먼트
하둡이나 HBase를 처음 시작한 팀은 견본 프로젝트 동안 실제 워크로드를
측정하면서 조금씩 경험을 쌓아나간다. 우리는 발란스드 워크로드로 작은 견본 클러스터부터 시작할 것을
추천한다.
파일럿 디플로이먼트(견본 배치)를
할 때, 당신은 1U/머신으로 시작할 수 있으며, 아래의 추천을 참고하기 바란다 :
두 개의 쿼드(4를 의미: 역주) 코어 CPU | 12 GB에서
24 GB 메모리 | 4개에서 6개 정도의 2테라 디스크 드라이브 용량
네트워크를 위한 미니멈 요구사항은 1GigE이며, 기가빗 이더넷 스위치로 모든 당신의 노드를 연결하면 쉽게 해결된다. CPU를
추가하기 위하여 여분의 소킷을 이용하려면, 당신은 6코어나 8코어 CPU를 써야 한다.
중소형의 HBase 클러스터는
1GB 램의 주키퍼 서버를 제공해라.
점프스타트 – 하둡 클러스터
단시간에 하둡 클러스터를 디플로이하는 방법은 “클라우드 트라이얼”을 선택하거나 버츄얼 인프라스트럭쳐를 이용하는 것이다. 호톤웍스는
호톤웍스 데이터 플랫폼(HDP)를 통해 배포하고 있다. HDP는
공적 클라우드에 쉽게 인스톨 할 수 있으며 Whirr, MS Azure, 아마존 웹서비스 등의 사설
클라우드에도 인스톨 가능하다. 상세한 내용은 호톤웍스 서포트 팀에게로.
어쨌든 클라우드 서비스와 버츄얼 인프라는 하둡을 위해 설계된 것이 아니다. 하둡과 HBase 디플로이먼트는 이 경우 가상화와 차선 I/O 아키텍쳐 때문에
좋지 않은 퍼포먼스를 경험할 것이다.
파일럿 디플로이먼트를 위한 츄레킹 리소스 사용법
호톤웍스는 당신이 Ganglia, Nagios나 다른 퍼포먼스 모니터링
프레임워크(당신의 데이터 센터에 사용되고 있는)를 이용하여
당신의 파일럿 클러스터를 모니터 하기를 추천한다. 당신은 또한 아래의 가이드라인을 참고하여 당신의 하둡과 HBase 클러스터들을 모니터 할 수 있다.
–
CPU, RAM, Disk I/O의 초당 계산력(IOPS)을 측정하라 그리고 네트워크 패킷
송수신을 측정하라. 필요한 쿼리문이나 분석 기법을 돌려봐라.
– 당신의 파일럿 클러스터의 크기에 당신의 데이터 서브 세트가 맞는지
확인하라.
– 자원 포화도를 모니터링하라. 이
분석을 기반으로 당신은 CPU bound, Disk I/O bound, 네트워크 I/O Bound 등을 카테고리화 할 수 있다.
$$$ 참고 : 대부분의
자바 어플리케이선들은 램 사용량을 맥시멈까지 확장한다. 그런 방법은 스와핑이 일어나지 않는 한, 혹은 JVM이 풀 메모리 쓰레기 모으기 이벤트를 경험하지 않는 한
메모리 바운드로 분석되어서는 안 된다. (풀 메모리 쓰레기 모으기 이벤트는 노드가 모든 유용한 일을
몇 분간 안 하는 것처럼 보일 때 전형적으로 발생한다.)
– 선택사항인데, 리소스의
균형을 위해 당신의 잡 파라메터나 하드웨어 혹은 네트워크 환경설정을 커스터마이즈 할 수 있다. 당신의
일이 다양한 워크로드 패턴에 공평하게 분배되어야 한다면, 당신은 잡 파라메터를 조작하는 작업으로 하드웨어
초이스를 “balanced”에 유지할 수 있다.
– HBase 클러스터를 위해, 당신은
또한 주키퍼를 조사해야만 한다. 왜냐하면 HBase를 위한
네트워크와 메모리 문제가 종종 주키퍼에서 먼저 발견되기 때문이다.
호톤웍스 데이터 플랫폼(HDP) 모니터링 데시보드 이용하기
당신은 또한 키 메트릭(metric)을 모니터해서 당신의 하둡 클러스터에게
경고해 줄 수 있는 HDP 모니터링 데시보드를 이용할 수 있다.
HDP 모니터링 데시보드는 Ganglia와 Nagios의
통합 상자를 제공한다. 상세한 내용은 호톤웍스 데이터 플랫폼을 보시오.
도전 – 잡 캐릭터리스틱스를 리소스 용법으로 튜닝하기
잡 캐릭터리스틱스를 리소스 용법으로 바꾸는 일은 여러 가지로 까다로운 일이어서 우리는 간단하게만 짚어보기로 한다. 잡이 코드되어 있거나 잡 데이터가 묘사되어 있는 경우에 이 방법은 리소스 발란스에 큰 임팩트를 줄 수 있다. 예컨데, 리소스 코스트는 압축 스키마나 파싱 포멧의 선택을 통해서
디스크 IOPS와 CPU 사이를 쉬프트 할 수 있게 된다. 혹은 per-node CPU와 디스크 엑티비티는 맵리듀스 전략의
이행을 이용해 인터 노드 대역폭을 위해서 트레이드 될 수 있다.
더 나아가 Amdahi의 법칙은 어떻게 리소스 용법이 변경 요구를
극도로 탈선형화 된 방법으로 바꿀 수 있는지를 보여준다. 그 변화는 계산 부하를 50프로 줄여줄 수 있을 것으로 기대되는 것이며, 넷 퍼포먼스에서 90%를 바꾸어야 할 비용을 10%로 줄여주는 것이다.
파일럿 머신 재활용
파일럿 클러스터가 자리를 잡았을 때, CPU와 I/O 장애를 확인하기 위한 워크로드 패턴 분석을 시작하라. 당신이 (특히 그들이 용량에 있어 변화가 진행중인 이상에는) 다양한 종류의
하둡 클러스터를 가지는 것은 당연한 일이다. 당신의 워크로드에 적합하지 않은 머신에서부터 시작하는 것은
당신의 재활용 능력을 향상시켜 주지 못할 것이다. 왜냐하면 이 머신들은 프로덕션 클러스터에서 재활용
될 수 있기 때문이다.
조사에서 긍정적인 리턴(ROI)을 얻기 위해서, 당신의 파일럿 클러스터에 있는 머신들이 당신의 프로덕션 클러스터에 있는 머신들의 10%를 넘기지 않도록 유의하라.
#### 서버 노드 하드웨어 추천
아래의 추천들은 노드의 개수, 노드 당 저장 옵션(디스크의 숫자, 디스크의 용량,
MTBF, 디스크 실패에 대한 복제 비용), 노드 당 계산 전력(소킷, 코어, 클락 스피드), 노드 당 램 그리고 네트워크 능력(숫자, 포트 스피드) 등을 결정하는데 최고의 통찰력을 제공해 줄 것이다.
이 섹션 전체의 하드웨어 고려는 하둡과 HBase 클러스터에 보편적으로
적합한 것인 반면에 여기서의 중점은 슬레이브 노드(데이터 노드, 테스크츄레커, 리전서버)이다. 슬레이브
노드는 인프라스트럭쳐의 대부분을 차지한다. (이 섹션은 프로덕션 환경에서 슬레이브 노드에어 발란스드
워크로드가 실현되기 위해서 보편적인 가이드라인을 제공할 것이다.)
$$$ 참고 : 하둡 클러스터
노드는 엔터프라이즈 데이터 센터 서버에서 보통 발견되는 많은 피쳐들을 요구하지 않는다.
슬레이브 노드(데이터 노드, 테스크츄레커, 지역서버)를 위한 하드웨어 선택
아래의 추천은 프로덕션 데이터 센터에서 얻어진 호톤웍스의 경험을 배경으로 하고 있다.
서버 플랫폼 고르기
보통 듀얼 소켓 서버는 하둡 디플로이먼트에 최적이다. 중대형 클러스터를
위해 이 서버들을 이용하는 것은 초보들에게는 최고의 선택인데 왜나하면 로드 발란스와 평행화(parallelization)
능력 때문이다. 밀도의 문제에 있어서 랙 유닛의 로 넘버에 맞는 서버 하드웨어를 선택하는
것이 추천된다. 보통은 1U 혹은 2U 서버가 19” 렉이나 케비넷에 쓰인다.
스토리지 옵션
하둡 어플리케이션의 보편적 목적을 고려한다면 우리는 서버당 비교적 많은 수의 하드드라이브를 쓰는 것을 추천한다. (보통 사타 LFF 드라이브 8에서 12대 정도) 이 글이 읽힐 시점이면, 프로덕션 환경의 전형적인 용량이 드라이브당 2TB쯤 됐을 것이다. 우리 경험에 의하면 높은 I/O 친화적인 환경은 12 * 2 테라 사타 드라이브를 써야 한다. 비용과 퍼포먼스의 최적
발란스는 7200 RPM 사타 드라이브 정도이다. 만약 당신의
장래의 저장공간이 늘어날 것 같으면 3테라바이트 디스크를 쓰는 것도 고려해봐야 한다.
SFF 디스크는 더 나은 디스크 대역폭을 위한 환경설정에서 채택된바
있다. 어쨌든 우리는 당신이 장래의 디스크 실패를 대비하여 당신의 클러스터를 모니터 할 것을 추천한다. 디스크가 많으면 디스크 실패의 확률도 올라가기 때문이다. 만약 당신이
서버당 대량의 디스크를 보유하고 있다면 당신은 두 개의 디스크 컨트롤러를 쓸 수도 있다. 그러면 I/O 로드가 여러 개의 코어로 분산 될 수 있다. 호톤웍스는 사타나 SAS 인터커넥트만 쓰기를 강력하게 추천한다.
당신이 낮은 비용의 믿을 만한 저장 옵션으로 HDFS 클러스터의 셋업을
마쳤다면, 당신은 올드 데이터가 클러스터에 무기한으로 머물러 있는 것을 관찰할 수 있을 것이고, 저장 공간의 필요가 빠르게 올라갈 것이다. 12 드라이브 시스템이라면
당신은 보통 노드당 24TB 혹은 34TB 정도 확보한다. 노드의 이 저장공간의 이용은 하둡 1.0.0 혹은 그 뒤에나 가능해
질 것이다. (그때 쯤이면 실패들이 수정되어서 머신들이 그들의 온전한 여분의 디스크로 계속 서빙하는
것을 허용해 줄 수 있기 때문이다.)
하둡이 저장 공간 친화적이며 검색 효율적이지만 빠르고 비싼 하드 드라이브를 요구하지는 않는다는 것을 반드시 기억해야
한다. 만약 당신의 워크로드 패턴이 I/O 친화적이지 않다면
네 개에서 여섯 개의 노드당 디스크를 추가하는 것은 안전하다. 파워 비용은 바이트 수가 아니라 디스크
수에 비례한다는 것을 기억하라. 우리는 그러므로 검색을 위한 추가 보다는 저장을 위한 디스크 추가를
추천한다.
RAID vs. JBOD
하둡 슬레이브 머신에 RAID를 이용하는 것은 추천되지 않는다. 왜냐하면 하둡은 데이터를 슬레이브 노드에서 중복삭제 하기 때문이다. 그래서 RAID를 하둡 마스터 머신에 쓰는 것이 강하게 추천된다. (특히
네임노드 서버)
마지막 고려로서 우리는 MTBF 숫자가 좋은 디스크 드라이브를 구매할
것을 추천한다. 왜냐하면 하둡의 슬레이브 노드는 고정적 확율로 실패를 거듭하기 때문이다.
당신의 슬레이브 노드는 2시간 내의 디스크 교체 등의 값비싼 지원
계약을 필요로 하지 않는다. 하둡은 슬레이브 노드의 디스크 실패를 고려하여 디자인 되었으며 그러므로
당신은 당신의 유지를 긴급상황보다는 현재의 업무를 고려해 세팅하면 된다
서버를 렉으로부터 꺼내지 않고 디스크를 교체할 수 있다는 것은 아주 유용하다.
마스터의 SSD 디스크를 사용하는 것은 당신의 현재 저장공간을 위한 비용을 증가시킬 수
있다. 이 디스크들의 비용을 낮추면 미래의 기회를 높일 수 있을 것이다.
메모리 사이징
하둡 클러스터에서 논 스텐더드 마더보드를 위한 비용 부담이나 교체 없이 프로세서들이 잘 돌아가도록 할 충분한
메모리를 제공하는 것은 매우 중요한 일이다. 코어의 수에 따라서 당신의 슬레이브 노드들은 보통 24기가에서 48기가의 램을 하둡 어플리케이션을 위해 필요로 한다. 대형 클러스터를 위해 이 메모리 용량은 여분의 램(대략 4기가)을 하둡 프레임워크와 쿼리,
분석 프로세스(HBase / 맵리듀스)등에 제공한다.
열역학 효과와 복사선 때문에 발생하는 단기적이고 우발적인 에러를 발견하고 수정하기 위해, 우리는 에러 수정 코드 메모리(ECC)를 사용할 것을 강력하게 추천한다. 에러 수정 랩은 당신이 당신의 컴퓨터시스템의 질을 신뢰할 수 있게 해준다. 어떤
파트는 전통적인 디자인보다 더 나은 보호를 보여준다. 비트 에로의 재발이 훨씬 줄어든 것이다. (DRAM Errors in the Wild… 이하생략… 을 참조하라.)
만약 당신이 미래에 당신이 서버에 더 많은 메모리를 추가하려는 옵션을 유지하고 싶다면 초기 메모리 모듈과 함께
이것을 할 수 있는 공간이 있는지를 확인하라.
메모리 대비
메모리는 또한 로 엔드 서버 마더보드에 소모품으로 비치가 되어 있어야 한다. 사용되지
않는 램은 당신의 하둡 어플리케이션(보통 2개 이상의 프로세르를
돌릴 때)이나 인프라스트럭쳐(퍼포먼스를 향상시키기 위해 캐칭
디스크 데이터를 쓸 때)에 의해서 소비될 것이다.
프로세서
당신의 워크로드 패턴에 따라서 달라질 문제이기는 하지만, 우리는 대부분의
시스템에서 두 개 이하의 소켓을 쓰는 중형 클락 스피드 프로세서를 쓰는 것을 추천한다. 대부분의 워크로드에서
노드당 추가 퍼포먼스는 비용 효율적이지 않다. 대형 클러스터를 위해 슬레이브 머신당 적어도 2개의 쿼드(4) 코어 CPU를
사용해라.
전원 고려
전원은 하둡 클러스터를 디자인할 때 가장 중요한 고려사항이다. 가장
크고 빠른 노드를 구입하는 것 보다 현존하는 하드웨어를 위한 전원 유틸리제이션을 분석하는 것이 더 중요하다. 우리는
가장 빠른 CPU나 과용량의 파워 서플라이 등을 피하는 것이 전력과 비용을 현격하게 낮추는 것을 관찰해왔다.
오늘날, 회사들은 비용과 전력을 줄이기 위해 디자인된 클라우드 데이터
센터를 위한 머신을 만들고 있다. 그리고 그 머신들은 가볍다. 슈퍼마이크로, 델 그리고 HP 모두들 그런 클라우드 제공자를 위한 생산 라인을
갖추었다. 그래서 만약 당신이 대형 볼륨을 사려고 한다면 우리는 군살을 모두 제거한 “클라우드 서버”를 평가해보기를 추천한다.
슬레이브 노드를 위해서 싱글 파워 서플라이 유닛(PSU)은 충분하다. 그러나 마스터는 여분의 SU들을 사용할 필요가 있다. 인접 서버를 통해 PSU를 공유하는 서버 디자인은 비용 상승 없이도
믿을 만한 성능 향상을 보여준다.
어떤 코로케이션 사이트들은 실제 필요량이 아닌 최고 가능 전력을 기반으로 필요량을 청구한다. 그것은 최근 CPU들이 전력 절약 기능의 이득을 완전하게 실현하지
못하는 것이다. 우리는 그러므로 앞으로 사이트의 파워 필요량 옵션을 체크해보는 것을 추천한다.
클러스터의 전력 소모
모던 데이터 센터에서 장비의 가용기간 중 전기와 쿨링에 33프로에서 50프로 정도의 비용이 소모된다는 것이 밝혀졌다.
네트워크
이것은 하둡 워크로드가 너무나 다양하기 때문에 평가하기가 가장 어려운 변수일 것이다. 가장 중요한 것은 합리적인 속도로 모든 클러스트의 노드들이 통신할 수 있을 만큼의 충분한 공간을 합리적인 비용을
들여 구매하는 것일 테다. 대형 클러스트는 주로 듀얼 1기가
링크를 모든 노드(20 노드 렉과 렉 당 2*10 기가바이트
인터커넥트 링크 – 이것은 두 개의 중앙 스위치 가까이 있다.) 에
쓴다.
훌륭한 네트워크 디자인은 실제 노드에서 중요한 시기에 예상치 못한 혼잡의 가능성을 사전에 고려할 것이다. 보통 수용 가능한 초과 비율은 서버 엑세스 레이어에서 약 4:1, 엑세스
레이어와 집합 레이어 혹은 코어 사이에서 약 2:1 정도이다. 더
고급의 퍼포먼스에서는 그것보다 더 낮은 초과 비율이 요구될 것이다. 덧붙여 우리는 또한 렉들 사이에 1GE 오버서브스크립션을 가지기를 추천한다.
존재하는 스위치들에서 VC를 할당하는 것(하둡 클러스터의 부하는 스위치의 나머지 유저들에게 영향을 줄 것이다.) 대신에
클러스터를 위한 전용 스위치를 가지는 것은 매우 중요하다. 비슷하게 중요한 것으로 스위치가 하둡과 모니터링
장비 둘 다에게 적합한 것인지 확인하는 것이 있다.
하둡 / HBase 서버에 렉을 추가하기 위한 옵션을 유지하기 위해서
네트워킹을 디자인하라. 네트워크 실패는 엄청난 비용을 초래한다. 스위치에
적힌 대역폭은 자동차의 연비와 유사하다.(잘 안맞는 다는 이야기: 역주) “깊은 버퍼링”은 스위치의 로 레이턴시를 선호한다. 클러스터 사이에서 점보 프레임을 활성화 하는 것은 더 나은 계산합계를 통해 대역폭을 향상시키며 패킷 최적화
또한 가능케 한다.
당신의 하둡 클러스터를 위한 네트워크 전략
네트워크 / 컴퓨터 비용 비율을 분석해보라. 네트워크 비용은 항상 토탈 비용의 20퍼센트 정도로 유지하라. 네트워크 코스트는 네트워크, 코어 스위치, 렉 스위치, 필요한 네트워크 카드 등을 포함하는 것이다. 하둡은 범용화와 함께 성장했음을 있지 마라.
마스터 노드(네임노드, 잡츄레커, HBase 마스터)를 위한 하드웨어 선택
마스터 노드는 유니크 하므로 슬레이브와는 전혀 다른 저장공간과 메모리를 필요로 한다.
스토리지 옵션
우리는 듀얼 네임노드 서버를 추천한다. 하나는 프라이머리이고 하나는
세컨더리이다. 두 네임노드 서버는 그들의 네임스페이스 저장공간과 에디티로그 저널링을 위한 고도로 신뢰할
수 있는 저장공간을 확보해야한다. 보통, 하드웨어 RAID 혹은 확실한 네트워크 용량은 이유가 있는 옵션이다.
마스터 서버는 적어도 네 개의 충분한 저장 볼륨(몇 개는 로컬 몇
개는 네트워크)을 확보해야 하며, 그러나 각각은 보통 1테라 정도로 비교적 작아도 상관없다.
마스터 노드의 RAID 디스크는
A/S 계약이 요구된다. 우리는 당신이 A/S 계약에
온 사이트 디스크 교체 옵션을 포함할 것을 추천하는데 그래야 실패한 RAID 디스크가 재빨리 교체될
수 있기 때문이다.
많은 회사들이 NAS 소프트웨어를 팔고 있다. 당신이 NAS 소프트웨어를 사기 전에 그들의 스팩을 반드시 체크해봐라.
잡츄레커 서버를 위한 스토리지 옵션
잡츄레커 서버는 레이드 스토리지를 필요로 하지 않는다. 왜냐하면 그들은
그들의 끈질긴 HDFS 상태를 절약하고 잡츄레커 서버는 여분의 램으로 실제로는 슬레이브 노드에서 운영되기
때문이다. 어쨌든, 네임노드 서버로 똑 같은 스팩의 하드웨어를
이용하는 것은 네임노드가 실패했을 시 잡츄레커로 같은 서버에 네임노드를 이주시키는 계획을 짤 수 있게 해주며 동시에 네임노드의 상태의 카피가 네트워크
스토리지에 저장 될 수 있게 해 준다.
메모리 사이징
마스터 노드에 요구되는 메모리 양은 네임노드에 의해 창조되고 추적되는 시스템 오브젝트 파일(파일과 블록 리플리카)의 개수에 의해 결정된다. 64기가 램은 대략 100만 파일을 지원한다. 어떤 사이트는 더 큰 네임스페이스를 위해 128기가 램을 실험하고
있다.
프로세서들
네임노드와 그들의 클라이언트들은 매우 수다스럽다. 우리는 그래서 마스터
노드의 트래픽을 감당하기 위해 16 혹은 24 CPU 코어를
추천한다.
네트워크
멀티 네트워크 포트와 10기가 대역폭 스위치를 제공하는 것이 가능하다. (스위치가 버틸 수만 있다면)
#### HBase를 위한 하드웨어 선택
에이치베이스는 메모리를 채우기 위해서 다른 종류의 캐시를 쓴다. 그리고
보통 에이치베이스가 더 많은 메모리를 가질수록 그것은 더 나은 캐시 읽기 요청을 할 수 있게 된다. 에이치베이스
클러스터(리전 서버)에 각각의 슬레이브 노드들은 많은 수의
리전(리전이란 메모리의 데이터 덩어리를 의미한다.)을 확보하고
있다. 대형 클러스터는 에이치베이스 마스터와 네임노드가 각각 다른 서버머신으로 운영되는 것이 매우 중요하다. 대형 스케일 디플로이먼트의 경우에 주키퍼 노드는 하둡/에이치베이스
슬레이브 노드와 코–디플로이(협력 배치) 되지 않는다는 것을 명심하라.
스토리지 옵션 고르기
분산 셋업에서 에이치베이스는 자신의 데이터를 하둡 데이터노드에 저장한다. 멕시멈
읽기/쓰기 집약을 위하여 에이치베이스 리전서버과 데이터노드는 같은 머신에 코–디플로이(협력 배치)된다. 그러므로 모든 데이터노드/테스크츄레거 하드웨어 셋업을 위한 추천은
리전 서버에도 똑같이 추천된다. 당신의 에이치베이스 어플리케이션이 읽기/쓰기 용도인지 프로세싱 용도인지에 따라서 당신은 이용 가능한 CPU코어의
수와 디스크의 수를 조절해야 한다. 보통 당신은 디스크 당 최소 1코어
정도는 확보해야 한다.
메모리 사이징
에미치베이스 마스터 노드는 보통의 리전서버나 네임노드 서버처럼 계산 친화적이지 않다. 그러므로 에이치베이스 마스터를 위해서는 보다 신중한 메모리 세팅이 필요하다.
리전서버 메모리 요구사양은 당신은 에이치베이스 클러스터의 워크로드 특성에 강하게 연관되어 있다. 대용량의
힙 사이즈로 모든 워크로드 패턴의 메모리 수익을 대비하고서도 자바의 “stop-the-world GC
pauses”는 문제를 일으킬 것이다.
덧붙여, 하둡 코어로 에이치베이스 클러스터를 운영할 때, 당신은 당신의 하둡 맵리듀스를 위한 대비 메모리를 에이치베이스 메모리의 탑에서 적어도 테스크 당 1기가에서 2기가 정도 초과 확보해야만 함을 잊지마라.
#### 다른 이슈들
무게
최신 세대의 서버들의 저장공간 밀도는 렉의 무게가 계산되어야 함을 시사하고 있다. 당신은 렉의 무게가 데이터센터의 바닥의 임계치 보다 더 나가지 않는가 확인해야 한다. (실제 무게를 이야기하는 것 같음: 역주)
확장을 위한 계획
하둡 클러스터에 새 서버를 추가하거나 전체 서버 렉을 클러스터에 추가하거나 추가적인 로드를 감당하기 위해 마스터
노드에 메모리를 늘리는 것은 어려운 일이 아니다. 이것은 처음에 “재균형
트래픽”을 야기할 것이다. 그러나 그 뒤에는 추가 저장공간과
계산량을 가져다 줄 것이다. 마스터 노드는 항상 과사용 된다. 그래서
우리는 마스터 노드에 추가적인 비용을 지불하라고 추천하는 것이다.
이 방법으로 클러스터를 확장할 수 있으려면 아래를 보자.
– 하둡 클러스터 근처에 데이터 센터에 공간(실제 공간을 의미: 역주)이
있는지 확인하자. 이 공간은 더 많은 렉을 위한 파워 버짓이 들어설 자리이다.
– 추가 서버를 대처할 네트워크 계획을 세워라.
– 현존 서버에 디스크와 램과
CPU를 추가하는 것은 서버들이 여분의 소켓을 가지고 있을 때 가능하다. 이것은 렉 추가나
네트워크 변경 없이 클러스터 확장을 가능케 한다.
– 라이브 클러스터에 이 하드웨어 업그레이드를 실행하는 것은 시간과
노력이 요구될 것이다. 그래서 우리는 당신이 한 번에 한 서버에서만 확장을 시도하기를 추천한다.
– CPU 파트는 판매자의 가격 리스트에 영원히 남겨지지 않는다. 만약 당신이 두 번째 CPU를 추가할 계획이라면 당신의 판매대행자에게
당신이 가지고 있는 CPU의 가격이 얼마인지 물어보고 그 판매자가 당신의 CPU의 가격을 떨어뜨려서 이야기한다면 그때 CPU를 사서 추가하면
된다.(일종의 유머임: 역주) 보통 대략 18개월 정도의 시간이 걸린다.
– 당신은 마스터 서버에 더 많은 메모리를 필요로 할 것이 뻔하다. (그러니 처음부터 마스터는 넉넉히 하라는 뜻: 역주)
지원 계획
여기서 머리에 기억해야 할 격언은 “마스터 노드는 껴안고, 슬레이브 노드는 지켜보기만 하자”이다. 당신은 전통적인 엔터프라이즈 클래스 A/S 계약 – 클러스터의 대부분의 노드를 위한 – 을 필요로 하지 않는다. 클러스터의 보통 노드의 실패는 재난이라기 보다는 통계에 불과한 것이다. A/S 계약을 위한 돈을 아껴서 차라리 슬레이브 노드를 더 사는 것이
낫다.
커미셔닝
호톤웍스는 장래에 나올 문서에서 하둡 클러스터를 위한 최고의 실제 커미셔닝을 제공할 계획이다. 지금은 테라소트에 의해 뒤이어진 “스모크 테스트”가 좋은 초기 테스트인 것 같다. 어떤 메이져 서버 판매자들은 추가적인
대금을 발생시키는 하둡 클러스터의 공장 커니셔닝을 제공하고 있다. 이것은 당신이 그것을 구매하기 전에
클러스터가 정상 작동하는 것을 확인할 수 있는 직접적 장점이 있다. 간접적 장점은 만약 테라소트 퍼포먼스가
공장에서보다 사이트에서 저조하다면, 네트워크의 원인임을 짐작하고, 문제를
더 빨리 해결하는 것이 가능하다는 점이다.
#### 결론
하둡 실행으로부터 최적 결과를 얻는 것은 하드웨어와 소프트웨어 스택을 잘 고르는 것에서부터 시작된다. 계획 단계에서의 노력은 환경에 걸맞는 전체 비용과 드라마틱한 퍼포먼스를 통해 보답될 것이다. 덧붙여 다음의 조합 시스템 스택 추천은 계획 단계에서의 최선 조합을 만드는데 도움을 줄 것이다.
아래 도표
