노드 관리
노드 관리 (Node Management)
HBase 클러스터의 RegionServer 노드를 관리하는 방법을 설명하는 페이지예요. 노드 제외(decommission), 롤링 재시작, 새 노드 추가 등 운영 시 자주 겪는 작업을 다룹니다.
출처: 문서
본문
노드 관리 (Node Management)
노드 제외 (Node Decommission)
특정 노드의 HBase 디렉터리에서 다음 스크립트를 실행하면 개별 RegionServer를 중지할 수 있어요.
$ ./bin/hbase-daemon.sh stop regionserver
RegionServer는 먼저 모든 region을 닫은 뒤 스스로 종료돼요. 종료 시 RegionServer의 ZooKeeper 임시(ephemeral) 노드가 만료돼요. Master는 RegionServer가 사라진 것을 알아차리고 'crashed' 서버로 처리해요. RegionServer가 담당하던 노드(region)를 재할당해요.
노드를 제외하기 전에 로드 밸런서를 비활성화하세요 (Disable the Load Balancer before Decommissioning a node)
노드가 종료되는 동안 로드 밸런서가 실행되면 로드 밸런서와 Master가 방금 제외된 RegionServer를 복구하는 작업 사이에 경합이 발생할 수 있어요. 밸런서를 먼저 비활성화해서 문제를 피하세요. 아래 "Load Balancer" 정보 섹션을 참고하세요.
Kill Node Tool
hbase-2.0에서 bin 디렉터리에 considerAsDead.sh라는 스크립트를 추가했는데, 이것으로 regionserver를 죽일 수 있어요. 하드웨어 문제는 zookeeper 타임아웃이 만료되기 전에 특수 모니터링 도구로 감지될 수 있어요. considerAsDead.sh는 RegionServer를 죽은 것으로 표시하는 간단한 함수예요. 서버의 모든 znode를 삭제해 복구 프로세스를 시작해요. 더 빠른 장애 조치를 위해 이 스크립트를 모니터링/장애 감지 도구에 연결하세요. 이 파괴적인 도구를 어떻게 사용할지 주의하세요. hbase-2.0 이전 버전에서 사용해야 한다면 스크립트를 복사하세요.
위의 RegionServer 중지의 단점은 region이 꽤 오랫동안 오프라인일 수 있다는 것이에요. Region은 순서대로 닫혀요. 서버에 region이 많으면, 첫 번째로 닫히는 region은 모든 region이 닫히고 Master가 RegionServer의 znode가 사라진 것을 알아차릴 때까지 다시 온라인되지 않을 수 있어요. 노드가 점진적으로 로드를 떠넘기고 나서 스스로 종료하도록 graceful_stop.sh 스크립트를 사용할 수 있어요. 사용법은 다음과 같아요.
$ ./bin/graceful_stop.sh
Usage: graceful_stop.sh [--config
부하가 걸린 RegionServer를 제외하려면 다음을 실행하세요: $ ./bin/graceful_stop.sh HOSTNAME. 여기서 HOSTNAME은 제외하려는 RegionServer가 있는 호스트예요.
HOSTNAME에 관하여 (On HOSTNAME)
graceful_stop.sh에 전달하는 HOSTNAME은 hbase가 RegionServer를 식별하는 데 사용하는 호스트명과 일치해야 해요. HBase는 보통 fully-qualified domain name을 사용해요. master UI의 RegionServer 목록을 확인해 HBase가 서버를 어떻게 지칭하는지 보세요. HBase가 무엇을 사용하든, 그것을 graceful_stop.sh 제외 스크립트에 전달해야 해요. IP를 전달하면 스크립트는 아직 그것을 호스트명(또는 FQDN)으로 만들 만큼 똑똑하지 않아서, 서버가 현재 실행 중인지 확인할 때 실패해요. region의 우아한 언로드가 실행되지 않을 거예요.
graceful_stop.sh 스크립트는 region 변동(churn)을 최소화하기 위해 제외할 RegionServer에서 region을 한 번에 하나씩 이동해요. 새 위치에 region이 배포된 것을 확인한 뒤 다음 region을 이동하고, 이 과정을 제외할 서버가 0개 region을 담당할 때까지 반복해요. 이 시점에 graceful_stop.sh는 RegionServer에 stop을 알려요. master는 이 시점에 RegionServer가 사라진 것을 알아차리지만, 모든 region이 이미 재배포됐고 RegionServer가 깨끗하게 종료됐으므로 분할할 WAL 로그가 없어요.
Load Balancer
graceful_stop 스크립트가 실행되는 동안 Region Load Balancer는 비활성화되어 있다고 가정해요(그렇지 않으면 밸런서와 제외 스크립트가 region 배포를 두고 싸우게 돼요). 셸로 밸런서를 비활성화하세요.
hbase(main):001:0> balance_switch false true 0 row(s) in 0.3590 seconds
이렇게 하면 밸런서가 꺼져요(OFF). 다시 활성화하려면:
hbase(main):001:0> balance_switch true false 0 row(s) in 0.3590 seconds
graceful_stop은 밸런서를 확인하고 켜져 있으면 작업을 시작하기 전에 끄고, 오류로 조기 종료하면 밸런서를 재설정하지 않아요. 따라서 graceful_stop과 별개로 밸런서를 관리하고, graceful_stop을 끝낸 뒤 밸런서를 다시 활성화하는 것이 더 좋아요.
여러 RegionServer를 동시에 제외하기 (Decommissioning several Regions Servers concurrently)
대형 클러스터라면 여러 RegionServer를 우아하게(gracefully) 중지해 한 번에 두 대 이상의 머신을 제외하고 싶을 수 있어요. 동시에 여러 regionserver를 우아하게 비우려면 RegionServer를 "draining" 상태로 둘 수 있어요. 이것은 hbase_root/draining znode 아래 ZooKeeper에 항목을 만들어 RegionServer를 draining 노드로 표시함으로써 이루어져요. 이 znode는 hbase_root/rs znode 아래의 regionserver 항목과 같은 name,port,startcode 형식이에요.
이 기능이 없으면, 한 region server에서 비워지는 region이 비워지고 있는 다른 regionserver로 이동될 수 있으므로 여러 노드 제외가 최적이 아닐 수 있어요. RegionServer를 draining 상태로 표시하면 이를 방지해요. 자세한 내용은 이 블로그 글을 참고하세요.
불량 또는 고장난 디스크 (Bad or Failing Disk)
머신당 디스크 수가 꽤 있고 디스크가 완전히 죽는 경우를 대비해 dfs.datanode.failed.volumes.tolerated를 설정해 두면 좋아요. 하지만 보통 디스크는 "John Wayne"식으로 고장나요 — 즉 시간이 걸리며 dmesg에 오류를 뿜으며 죽어 가거나 — 어떤 이유로 컴패니언보다 훨씬 느리게 돌아요. 이 경우 디스크를 제외하고 싶을 거예요. 두 가지 옵션이 있어요. datanode를 제외하거나, 불량 디스크의 데이터만 재복제되는 덜 파괴적인 방법으로 datanode를 중지하고(디스크가 datanode에 사용되는 동안에는 umount할 수 없어요) 불량 볼륨을 마운트 해제한 뒤 datanode를 재시작할 수 있어요(dfs.datanode.failed.volumes.tolerated > 0을 설정했다고 가정). regionserver는 데이터를 어디서 가져올지 재조정하면서 로그에 일부 오류를 던지고 — WAL 로그를 롤링할 가능성이 높아요 — 일반적으로 일부 지연 시간 스파이크 외에는 계속 돌아갈 거예요.
Short Circuit Reads
short-circuit reads를 하고 있다면 datanode를 중지하기 전에 regionserver에서 region을 옮겨야 해요. short-circuit reading을 할 때는 chmod되어 regionserver가 접근할 수 없지만, 이미 파일을 열고 있으므로 datanode가 죽었어도 불량 디스크에서 파일 블록을 계속 읽을 수 있어요. datanode를 재시작한 뒤 region을 다시 옮기세요.
롤링 재시작 (Rolling Restart)
일부 클러스터 설정 변경은 변경 사항을 반영하기 위해 전체 클러스터나 RegionServer를 재시작해야 해요. 또한 마이너나 유지보수 릴리스로의 업그레이드, 가능하면 메이저 릴리스로의 업그레이드에도 롤링 재시작이 지원돼요. 업그레이드하려는 릴리스의 릴리스 노트를 참고해 롤링 업그레이드 수행 능력의 제한 사항을 확인하세요.
상황에 따라 클러스터 노드를 재시작하는 방법은 여러 가지가 있어요. 아래에 자세히 설명해요.
rolling-restart.sh 스크립트 사용 (Using the rolling-restart.sh Script)
HBase에는 전체 클러스터, master만, 또는 RegionServer만 롤링 재시작할 수 있는 bin/rolling-restart.sh 스크립트가 함께 제공돼요. 이 스크립트는 여러분의 스크립트를 위한 템플릿으로 제공되며 명시적으로 테스트되지는 않아요. 비밀번호 없는 SSH 로그인이 구성되어 있고 tarball로 배포했다고 가정해요. 스크립트는 실행하기 전에 일부 환경 변수를 설정해야 해요. 스크립트를 살펴보고 필요에 맞게 수정하세요.
rolling-restart.sh 일반 사용법 (rolling-restart.sh General Usage)
$ ./bin/rolling-restart.sh --help
Usage: rolling-restart.sh [--config
RegionServer만 롤링 재시작 (Rolling Restart on RegionServers Only)
RegionServer만 롤링 재시작하려면 --rs-only 옵션을 사용하세요. 개별 RegionServer를 재부팅해야 하거나, RegionServer에만 영향을 주고 다른 HBase 프로세스에는 영향을 주지 않는 설정 변경을 한 경우 필요할 수 있어요.
Master만 롤링 재시작 (Rolling Restart on Masters Only)
활성·백업 Master를 롤링 재시작하려면 --master-only 옵션을 사용하세요. 설정 변경이 Master에만 영향을 주고 RegionServer에는 영향을 주지 않는다는 것을 알거나, 활성 Master가 실행 중인 서버를 재시작해야 하는 경우 사용할 수 있어요.
우아한 재시작 (Graceful Restart)
--graceful 옵션을 지정하면 RegionServer가 bin/graceful_stop.sh 스크립트로 재시작되는데, 재시작 전에 RegionServer에서 region을 이동해요. 더 안전하지만 재시작을 지연시킬 수 있어요.
스레드 수 제한 (Limiting the Number of Threads)
롤링 재시작이 특정 수의 스레드만 사용하도록 제한하려면 --maxthreads 옵션을 사용하세요.
수동 롤링 재시작 (Manual Rolling Restart)
프로세스에 대한 더 많은 제어를 유지하려면 클러스터 전체에 걸쳐 수동으로 롤링 재시작을 하고 싶을 수 있어요. 이는 graceful-stop.sh 명령 decommission을 사용해요. 이 방법에서는 각 RegionServer를 개별적으로 재시작한 뒤 옛 region을 제자리로 옮겨 locality를 유지할 수 있어요. Master도 재시작해야 한다면 별도로 해야 하며, 이 방법으로 RegionServer를 재시작하기 전에 Master를 먼저 재시작해야 해요. 다음은 그러한 명령의 예시예요. 환경에 맞게 조정해야 할 수 있어요. 이 스크립트는 RegionServer만 롤링 재시작해요. region을 이동하기 전에 로드 밸런서를 비활성화해요.
$ for i in cat conf/regionservers|sort; do ./bin/graceful_stop.sh --restart --reload --debug $i; done &> /tmp/log.txt &
/tmp/log.txt 파일의 출력을 모니터링해 스크립트의 진행 상황을 따라가세요.
나만의 롤링 재시작 스크립트 만들기 로직 (Logic for Crafting Your Own Rolling Restart Script)
나만의 롤링 재시작 스크립트를 만들고 싶다면 다음 지침을 사용하세요.
-
새 릴리스를 추출하고 설정을 검증한 뒤
rsync,scp또는 다른 안전한 동기화 메커니즘으로 클러스터의 모든 노드에 동기화하세요. -
먼저 master를 재시작하세요. 업그레이드처럼 새 HBase 디렉터리가 옛것과 다르다면 이 명령을 수정해야 할 수 있어요.
$ ./bin/hbase-daemon.sh stop master; ./bin/hbase-daemon.sh start master
- Master에서 다음과 같은 스크립트로 각 RegionServer를 우아하게 재시작하세요.
$ for i in cat conf/regionservers|sort; do ./bin/graceful_stop.sh --restart --reload --debug $i; done &> /tmp/log.txt &
Thrift나 REST 서버를 실행 중이라면 --thrift나 --rest 옵션을 전달하세요. 다른 사용 가능한 옵션은 bin/graceful-stop.sh --help 명령을 실행하세요.
여러 RegionServer를 재시작할 때 HBase region을 천천히 비우는(drain) 것이 중요해요. 그렇지 않으면 여러 region이 동시에 오프라인이 되어 곧 오프라인이 될 수 있는 다른 노드에 재할당되어야 해요. 이는 성능에 부정적인 영향을 줄 수 있어요. 위 스크립트에 sleep 같은 셸 명령을 추가해 지연을 주입할 수 있어요. 각 RegionServer 재시작 사이에 5분을 기다리려면 위 스크립트를 다음과 같이 수정하세요.
$ for i in cat conf/regionservers|sort; do ./bin/graceful_stop.sh --restart --reload --debug $i & sleep 5m; done &> /tmp/log.txt &
- 죽은 서버 목록을 비우고 로드 밸런서를 다시 활성화하기 위해 Master를 다시 재시작하세요.
새 노드 추가 (Adding a New Node)
HBase에서 새 regionserver를 추가하는 것은 본질적으로 공짜예요. 다음과 같이 시작하기만 하면 master에 스스로 등록해요: $ ./bin/hbase-daemon.sh start regionserver. 이상적으로는 같은 머신에서 DataNode도 시작해서 RS가 결국 로컬 파일을 갖게 하는 게 좋아요. ssh에 의존해 데몬을 시작한다면 master의 conf/regionservers에 새 호스트명을 추가하는 것을 잊지 마세요.
이 시점에서 region server는 아직 region이 이동하지 않았으므로 데이터를 서빙하지 않아요. 밸런서가 활성화되어 있다면 새 RS로 region을 이동하기 시작해요. 소형/중형 클러스터에서는 많은 region이 동시에 오프라인이 될 수 있어 지연 시간에 매우 부정적인 영향을 줄 수 있어요. 따라서 노드를 제외할 때처럼 밸런서를 비활성화하고 region을 수동으로(또는 더 좋게, 하나씩 옮기는 스크립트로) 이동하는 것이 권장돼요.
이동된 region은 모두 0% locality를 가지며 캐시에 블록이 없어서 region server가 요청을 서빙하기 위해 네트워크를 사용해야 해요. 지연 시간이 높아지는 것 외에도 네트워크 카드의 용량을 전부 사용할 수도 있어요. 실용적으로 표준 1GigE NIC는 100MB/s 이상을 읽지 못한다고 간주하세요. 이 경우이거나 OLAP 환경에서 locality가 필요하다면 이동된 region을 major compact하는 것이 권장돼요.