[빅데이터 전문가의 하둡관리] 4. 완전 분산 클러스터 계획하고 만들기

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788931555752

빅데이터 전문가의 하둡 관리 - 교보문고

위 책의 내용을 읽으며 공부한 내용을 요약 및 정리한 글입니다. 자세한 내용은 위 책에서 알 수 있습니다.

하둡 클러스터 계획하기

클러스터를 계획할 때 일반적으로 고려해야 할 것들

마스터 서비스는 네임노드, 리소스매니저, 저널노드 그리고 잡히스토리서버들이다. 저널노드는 높은 가용성 아키텍처에서만 사용된다. 

주키퍼는 최소 정족수를 갖춘 서비스로 운영하기 위해 최소 3개의 노드가 필요하고, 네임노드에 고가용성 특징을 활용하기 위해서도 3개의 노드가 필요하다.

마스터 노드1	마스터 노드 2	마스터 노드 3
액티브 네임노드	스탠바이 네임노드	리소스 매니저
주키퍼	주키퍼	주키퍼
저널노드	저널노드	저널노드

노드를 선택하는 시준

클러스터에 사용될 서버 타입을 결정하는 주요 요소는 비용이다

데스크톱 수준의 컴퓨터를 권하지 않는다. 서버당 36 ~ 48TB 정도의 적당한 스토리지 용량의 중간 수준 인텔 서버를 선택해야 한다.

싱글 랙에서 멀티 랙으로 가기

단일 랙에서 벗어나 더 큰 클러스터를 다루게 될 때, 클러스터에 간단히 랙을 추가하고 각 랙에 10GbE 스위치를 사용해 연결할 수 있다.

마스터 노드와 여러 워커 노드가 각 랙에 나눠 실행되는 것은 실제 업계에서 가장 일반적으로 쓰이는 아키텍처다.

100여 대의 노드로 구성된 클러스터까지는 이 아키텍처를 이용해 클러스터에 새로운 노드를 추가하는 방식으로 사용할 수 있다. 더 큰 클러스터에는 네트워크 아키텍처가 훨씬 복잡해진다. 더 큰 스위치가 필요하다.

하둡 클러스터 크기 결정하기

3TB 디스크, 96 램, 8 ~12 코드를 가진 서버를 사용하는 것이 기본.

CPU, 메모리 그리고 스토리지를 결정하는 일반적인 원칙들

• 예상되는 클러스터 작업 종류
• 예상되는 데이터 스토리지 사이즈
• 예상되는 데이터 증가 패턴

하둡 환경에서 가상화와 블레이드 서버의 사용에 대한 생각

• 가상화는 테스트나 클러스터 POC에 사용하기에 최고의 방법. 그러나 네트워크 집중과 같은 물리적 호스트에 모든 복사본이 위치할 가능성 때문에 클러스터 가상화를 사용하면 큰 비용을 지불해야 할 수도 있다.
• 블러스터 자체가 고장나면 한 번에 다수의 데이터노드를 사용할 수 없게 된다. 최상위 네트워크 스위치와 블레이드의 네트워크 사이에 네트워크 병목이 잠재적으로 있을 수 있고, 매우 많은 프로세싱을 하기에는 블레이드의 디스크 크기와 램이 부족할 수 있다.

디스크 크기와 설정

디스크 속도의 경우, 7200RPM 드라이브 정도면 적당하다. 큰 용량의 디스크보다는 작지만, 많은 디스크가 더 유리하다.

 

참고: 데이터 노드별로 36TB 이상의 데이터를 할당하면, 데이터노드가 죽거나 하둡이 클러스터에 데이터의 복사본을 강제로 만들 때 네트워크 트래픽 문제가 발생하다.

 

RAID 구성은 불필요하다. 네임노드 서버와 같이 중요한 서버의 경우, RAID를 사용할 것을 추천한다(RAID-1 미러링).

이론적으로 3TB 디스크와 대략 12개의 디스크로 구성된 클러스터 노드를 만들어야 한다.

 

노드의 디스크 수가 증가함에 따라 디스크가 고장 날 확률도 할께 증가한다. 따라서 I/O 노드를 공유하기 위해 서버당 2개의 컨트롤러를 사용하는 것을 고려.

메모리 사이징

노드에서 처리할 작업의 양은 서버에 할당된 램의 크기에 좌우된다.

각 하둡 잡은 자식 태스크를  만들고, 각각의 태스크는 컨테이너라 불리는 논리적인 단위로 실행된다. 컨테이너의 크기는 램의 크기로 정해진다.

256GB를 권장. 임팔라, 스파크를 사용하는 경우 512GB도 고려.

 

네트워크에서 고려한 점들

클러스터에 매우 큰 데이터를 저장해야 한다거나 맵리듀스 잡에서 큰 중간 데이터를 만들어야 한다면, 매우 큰 대역폭을 가진 네트워크가 필요하다. 10GB/초 속도를 갖는 네트워크를 찾아야 한다. 클러스터는 랙당 2*10G의 연결을 사용해 중앙 스위치에 페어로 연결한다.

 

가상 회로를 만드는 것보다 전용 스위치를 만드는 것이 좋다.

 

마스터 노드에 대해 특별히 고려해야 하는 점

• 일반적인 하드웨어보다는 좋은 품질의 하드웨어를 사용.
• SATA보다는 SAS를 사용.
• 하드웨어 RAID나 네트워크 스토리지 사용.
• 서비스 중단을 최소화하기 위해 RAID 디스크에 대해 온-사이트 디스크 교체 서비스 옵션 사용.
• CPU 코어를 늘리기.
• 많은 램 사용. 네임노드와 세컨더리 네임노드는 동작중에 처리하는 HDFS 메타데이터를 RAM에 저장.
• 많은 네트워크 포트와 높은 대역폭(10GbE)을 갖는 스위치 사용.
• 듀얼 파워 서플라이와 듀얼 이더넷 카드 사용.

서버 사이즈에 대한 추천

• 마스터 노드
  • 프로세서: 6 ~ 8개의 코어가 있는 CPU 코어 하나
  • 메모리: 24 ~ 96GB 램
  • 스토리지: 1 ~ 2TB의 로컬 스토리지. RAID-1 구성으로 SAS 디스크 사용.
• 데이터노드
  • 프로세서: 4 ~ 8개의 코어가 있는 CPU 2개. 기호에 따라 CPU 하나를 사용하거나 더 추가. 하이퍼 스레딩과 QPI 기능은 사용.
  • 메모리: 24 ~ 96GB 램.
  • 스토리지: 2 ~3TB 디스크 6 ~ 12개. RAID는 필요없고, 로그파일 저장을 위한 공간은 RAID 구성 추천.
  • 네트워크: 랙 내부의 연결은 1GbE, 랙 사이는 10GbE로 연결.

클러스터 확장하기

노드 추가나 서버 랙 추가.

큰 규모의 클러스터를 위한 가이드 라인

아파치 하둡 자체는 클러스터를 구성하는 다양한 서비스에 대한 특별한 레이아수을 요구하고 있지는 않다.

중간 크기의 클러스터에서 큰 규모의 클러스터에 이르기까지 주요 서비스들의 위치와 관련된 가이드라인이다.

• 리소스매니저: 리소스매니저는 리소스를 많이 사용하는 서비스다.  50개 노드 이상의 큰 클러스터의 경우, 주키퍼 서비스가 동작하고 있는 노드에서 리소스매니저 서비스를 동작시키지는 말아야 한다. 매우 작은 클러스터가 아니라면 전용 노드에서 리소스매니저 서비스를 실행한다.
• 네임노드 서비스: 반드시 네임노드 서비스를 전용 노드에서 실행해야 한다. 성능을 위해서도 그렇고 가용성을 위해서도 전용 서버가 필수적이다. 가용성을 위해서는 RAID-1을 구성한다.
• 저널노드: 저널노드는 네임노드나 리소스매니저와 같은 하둡 마스터 서비스가 실행되는 서버에 실행돼야 한다.
• 잡히스토리서버: 저널노드처럼 잡히스토리서버도, 마스터노드에서 실행된다.
• 데이터노드와 노드매니저 서비스: 노드매니저는 모든 데이터노드에서 실행된다. 노드매니저와 주키퍼 서비스를 같은 노드에 위치시킬 때, 노드매니저에 할당하는 메모리를 최소화시켜야 한다. 데이터노드 데몬은 모든 데이터노드마다 실행돼야 한다.
• MySQL 데이터베이스: 하이브, 우지 등의 메타데이터 저장용으로 사용한다.
• 주키퍼: 네임노드의 높은 가용성을 유지시키기 위해 최소 3개의 인스턴스에 홀수 개의 주키퍼 서비스를 실행해야 한다. 매우 가벼운 인스턴스이기 때문에 마스터노드와 같은 노드에서 실행할 수 있다.

멀티노드 클러스터 만들기

가상분산클러스터와의 중요한 차이는 HDFS 데이터 블록이 복제된다는 점이다.

테스트 클러스터를 만드는 방법

3개의 노드로 주키퍼를 사용한다는 가정하에 클러스터를 설치한다.

이전과 달리 여러 서버를 설정해야 하기 때문에 몇 가지 다른 설정을 해야 한다.

노드 1: 네임노드, 잡히스토리서버

노드 2: 스탠바이 네임노드, 리소스 매니저

노드 3: 순수 워커 노드

pdsh 설치

전체 클러스터에 명령을 실행하기 위해 pdsh를 사용하면 쉽게 클러스터를 관리할 수 있다. pdsh 유틸리티는 rsh 명령의 변종으로, 일종의 높은 성능을 가진 병렬 셸이라고 할 수 있다. rsh가 원격 호스트에 명령을 실행할 수 있다면, pdsh는 다수의 서버에 동시에 명령을 실행할 수 있다. 같은 명령어를 모두 실행해야 할 때, pdsh를 이용해 한 노드에서 명령을 실행하기만 하면 된다.

yum install pdsh

모든 클러스터 노드에 pdsh 유틸리티를 설치해야 한다. pdsh를 이용해 원격으로 명령을 실행할 수 있다. 다음은 명령을 한 노드에서 실행하면 클러스터의 모든 노드의 날짜를 확인할 수 있는 예제이다.

pdsh -w "all_nodes" date

예제에서 all_nodes라고 지정한 매개변수는 파일로 클러스터의 모든 노드를 기록한 파일이다. pdsh 명령 대상이 되는 서버를 제외시키는 것도 가능하다.

클러스터 사이의 암호 없이 SSH가 연결되도록 설정하기

ssh-keygen -t rsa

모든 값을 기본값으로 설정하고, 암호를 설정하지 않으면 ssh로 직접연결하거나 다른 명령을 통해 원격으로 클러스터 노드에 접근할 때 암호를 입력하는 메세지가 나오지 않게 된다. 키를 생성하면 콩개를 복사해야 한다. 클러스터의 노드가 많지 않으면 간단히 클러스터 노드에 공개키를 직접 복사할 수 있다. 큰 규모의 클러스터라면 ssh-copy-id 명령을 사용해 공개 키를 모든 호스트에 복사하고, .ssh/knownhosts 파일에 등록할 수 있다.

/etc/hosts 파일 수정

하둡 설정 파일 수정하기

HDFS 설정 변경(hdfs-site.xml)

dfs.block.size

블록 사이즈를 설정.

 

dfs.datanode.du.reserved

HDFS 파일 스토리지에 사용되지 않는 여분의 공간 사이즈를 지정. 기본적으로 이 값은 0으로 설정돼 있으므로 데이터노드의 모든 공간을 HDFS 스토리지로 사용할 수 있도록 한다. 각 볼륨의 20%정도를 HDFS 이외의 공간으로 남겨둔다.

HDFS 매개변수 수정하기

• dfs.replication: 복제 개수
• dfs.name.node.dir: 이 값은 로컬 파일 시스템에서 네임노드가 저장하는 fsimage 파일의 위치를 지정한다. 콤마를 사용해 디렉토리 목록을 입려하면 fsimage 파일이 지정된 모든 디렉토리에 복제된다. 이 설정값이 최소 2개의 별도 디스크를 경로 지정하거나 RAID 볼륨을 지정해야 한다. 그렇지 않으면 데이터가 모두 손실될 수도 있는 재앙에 빠질 수 있다. 네임노드와 세컨더리 네임노드를 사용하고 있다면, 네임노드에 대해 고가용성을 보장할 수 없다. 스탠바이 네임노들르 사용해 고가용성을 갖는 HDFS 네임노드를 설정할 수 있다.
• dfs.datanode.data.dir: 노드의 데이터 디렉토리를 설정.
• dfs.permissions.superusergroup: HDFS 수퍼 유저들을 갖고 있는 그룹을 지정한다. 네임노드를 실행한 사용자를 HDFS 수퍼유저로 간주한다.

얀 설정 수정

• yarn.nodemanager.aux-services: 이 매개변수를 'mapreduceshuffle'로 수정한다.
• yarn.nodemanager.aux-services.mapreduce.shuffle.class: 이 값을 yarn.nodemanager.aux-services.mapreduce.shuffle.class로 설정

메모리와 관련된 매개변수 설정하기

하둡을 효율적으로 동작시키기 위해 조정한다. yarn.xml 파일에 있는 다음과 같은 얀 매개변수를 설정해준다.

• yarn.nodemanager.resource.memory-mb: 노드가 96GB의 RAM을 가지고 있다면, 70%인 68GB를 YARN에서 할당한다. 이 매개변수의 기본값은 8GB이다.
• yarn.nodemanager.resource.cpu-vcores: 얀 컨테이너에서 할당할 수 있는 CPU 코어 수정을 지정한다. 기본값은 8이다. 노드의 물리적 코어개수보다는 작거나 같은 값을 설정해야 한다.
• mapreduce.map.memory.mb와 mapreduce.reduce.memory.mb: 이 두 매개변수는 맵과 리듀스 태스크에 할당할 수 있는 메모리를 지정한다. 1GB가 기본값이며, 2~4GB값을 보통 설정한다.
• mapreduce.map.java.opts와 mapreduce.reduce.java.opts: 맵퍼와 리듀서 프로세스는 JVM 위에서 실행된다. 맵과 리듀스에 할당한 메모리 중 일부는 메모리와 관련된 다른 작업을 한다. 이렇게 달리 사용되는 메모리를 '프로세싱의 오버헤드'라고 한다. JVM이 태스크에 모든 메모리를 할당하지 못하도록 하기 위해 mapreduce.map.java.opts와 mapreduce.reduce.java.opts를 이훃새 맵퍼와 리듀서에 할당할 수 있는 자바 힙 메모리 사이즈를 제한. mapreduce.map.memory.mb, mapreduce.reduce.memory.mb에 지정한 값의 70~75% 할당하는 것이 적합. 위 설정은 맵리듀스 태스크에서 사용할 물리적 메모리의 최댓값을 설정한 것이다. 각 태스크에 대한 가상 메모리에 대한 설정은 얀의 yarn.nodemanager.vmem-pmem-ratio 설정으로 가상 메모리 비율을 설정할 수 있다. 맵과 리듀스의 컨테이너의 크기는 mapreduce.map.memory.mb와 mapreduce.reduce.memory.mb로 결정한다.

로깅과 관련된 매개변수

• yarn.log.aggregation-enable: 각 데이터노드의 노드매니저가 보는 값으로, 애플리케이션 로그들을 수집할지 결정하는 데 사용.
• log-aggregation.retain.seconds: 하둡이 애플리케이션 로그를 언제까지 HDFS에 유지시킬지 결정.
• yarn-nodemanager.remote-apps-log-dir: 이 매개변수는 애플리케이션의 로글르 HDFS의 어떤 디렉토리에 저장할지 지정한다.
• yarn.nodemanager.log-dir: 얀이 보내는 애플리케이션 로그 파일을 리눅스 파일 시스템의 어디에 저장할지 지정.
• yarn.nodemanager.local-dir: 얀은 맵리듀스에서 생성되는 중간 결과물을 로컬 파일 시스템에 저장해야 할 때, 지정.
• yarn.application.classpath: 하둡을 저장하고 있는  로컬 파일 시스템을 지정.

맵리듀스 설정 변경하기

운영 수준의 클러스터 환경에서 mapreduce-site.xml에 매개변수 설정

• yarn.app.mapreduce.am.staging-dir: 이 매개변수는 잡을 서밋하는 데 사용되는 스테이징 디렉토리로 사용.
• mapreduce.jobhistory.address: 잡히스토리서버는 이 매개변수의 지정된 주소/포트 값이 이용해 내부 통신을 한다.
• mapreduce.jobhistory.webapp.address: 잡히스토리서버는 웹 UI에 접근하는 액세스 포인터로, 이 매개변수의 주소/포트를 사용한다.
• mapreduce.jobhistory.intermediate-done-dir: 맵리듀스 잡은 이 매개변수에 지정된 디렉토리에 히스토리 파일을 저장한다.
• mapreduce.jobhistory.don-dir: 잡히스토리서버가 히스토리 파일을 관리하는 곳.

클러스터 시작하기

가상 분산 클러스터에 했던 것과 같은 명령으로 얀과 하둡 서비스를 실행할 수 있다. 클러스터를 처음으로 시작하기 전에 네임노드를 포맷하는 것을 잊지 말아야 한다.

su - hdfs
/opt/yarn/hadoop2-6-0/bin/namenode -format

네임노드 포맷 후에 노드1에서 다음 명령어로 서비스 시작.

./hadoop-daemon.sh start namenode #1(HDFS를 관리하는 네임노드)
./yarn-daemon.sh start resourcemanager #2(YARN의 리소스 할당을 관리하는 리소스매니저)

노드2에서 다음과 같은 서비스를 시작.

./hadoop-daemon.sh start secondarynamenode #3(세컨더리 네임노드)
./mr-jobhistory-daemon.sh start historyserver #4(YARN 잡히스토리서버 서비스)

노드1, 노드2, 노드3 서버에서 다음과 같은 서비스를 시작.

./hadoop-daemon.sh start datanode 1#(데이터노드 서비스)
./yarn-daemon.sh start nodemanager 2#(데이터노드가 실행되는 모든 노드에서 실행되는 노드매니저 서비스)

스크립트로 클러스터 시작하고 종료하기

여러 노드에서 많은 프로세스를 시작 종료하기 위해서 스크립트를 만들어 놓는다.

모든 클러스터 서비스를 시작하는 간단한 스크립트

vi startcluster.sh
#!/bin/bash

ssh hdfs@hadoop1 'hadoop-daemon.sh start namenode'
ssh hdfs@hadoop2 'hadoop-daemon.sh start standbynamenode'
ssh hdfs@hadoop1 'hadoop-daemon.sh start datanode'
ssh hdfs@hadoop2 'hadoop-daemon.sh start datanode'
ssh hdfs@hadoop3 'hadoop-daemon.sh start datanode'
ssh yarn@hadoop2 'yarn-daemon.sh start resourcemanager'
ssh yarn@hadoop1 'yarn-daemon.sh start nodemanager'
ssh yarn@hadoop2 'yarn-daemon.sh start nodemanager'
ssh yarn@hadoop3 'yarn-daemon.sh start nodemanager'
ssh mapred@hadoop2 'mr-jobhistory-daemon.sh start historyserver'

모든 클러스터 서비스를 종료하는 스크립트

vi stopcluster.sh
#!/bin/bash

ssh hdfs@hadoop1 'hadoop-daemon.sh stop namenode'
ssh hdfs@hadoop2 'hadoop-daemon.sh stop standbynamenode'
ssh hdfs@hadoop1 'hadoop-daemon.sh stop datanode'
ssh hdfs@hadoop2 'hadoop-daemon.sh stop datanode'
ssh hdfs@hadoop3 'hadoop-daemon.sh stop datanode'
ssh yarn@hadoop2 'yarn-daemon.sh stop resourcemanager'
ssh yarn@hadoop1 'yarn-daemon.sh stop nodemanager'
ssh yarn@hadoop2 'yarn-daemon.sh stop nodemanager'
ssh yarn@hadoop3 'yarn-daemon.sh stop nodemanager'
ssh mapred@hadoop2 'mr-jobhistory-daemon.sh stop historyserver'

새로운 클러스터 파일 시스템을 빠르게 점검하기

2개의 하둡 명령으로 클러스터의 상태를 점검할 수 있다. hdfs fsck 명령을 HDFS 루트 디렉토리에 다음과 같이 실행한다.

hdfs fsck /

hdfs dfsadmin -report 옵션을 추가하면 HDFS 파일 시스템에 설정한 내용을 확인할 수 있다.

hdfs dfsadmin -report

hdfs dfsadmin 유틸리티는 HDFS 파일 시스템의 정보를 보여주는 것 이외에도 많은 기능을 갖고 있다.