impyla 등 클라이언트에서 질의를 던질 때 다음이 난다.
impala.error.OperationalError: Failed due to unreachable impalad(s): host.example.com:22000
주소 뒤의 포트가 22000 이라는 점이 중요하다. 클라이언트가 접속하는 포트(HS2 21050, Beeswax 21000) 가 아니라 impalad 끼리 통신하는 백엔드 포트다. 즉 클라이언트와 코디네이터 사이의 연결은 성공했고, 코디네이터가 실행 노드에 일을 나눠 주려다 실패한 것이다.
따라서 확인 대상은 클라이언트 쪽 설정이 아니라 해당 executor 노드의 impalad 상태와 노드 사이 통신이다.
impalad 가 살아 있는가.
ps -ef | grep [i]mpalad
systemctl status impala-server
CM 관리 클러스터라면 Impala 서비스의 Instances 탭에서 해당 호스트 역할의 상태를 본다.
백엔드 포트가 열려 있는가. 다른 코디네이터 노드에서 시험한다.
nc -vz host.example.com 22000
ss -lntp | grep -E '22000|21050|21000|27000'
방화벽이 켜졌거나 보안 그룹이 바뀌어 노드 사이 통신만 막히는 경우가 있다. 클라이언트에서는 잘 붙으므로 원인을 헤매기 쉽다.
이름이 풀리는가. impalad 는 다른 노드를 호스트명으로 부른다. 클러스터 안에서 그 이름이 해석되지 않으면 같은 오류가 난다.
getent hosts host.example.com
로그를 본다.
tail -200 /var/log/impala/impalad.ERROR
grep -iE 'bind|krpc|not ready|statestore' /var/log/impala/impalad.INFO | tail -50
BindException 은 포트를 다른 프로세스가 선점한 것이고, Connection refused 반복은 대상 프로세스가 죽은 것이며, statestore 관련 메시지가 이어지면 멤버십 문제다.
자원이 모자라지 않은가. 디스크가 가득 차거나 열린 파일 수 한도에 닿으면 impalad 가 기동하다 죽는다.
df -h /var/log /var/lib
free -m
ulimit -n
가장 흔한 것은 해당 노드의 impalad 가 OOM 이나 디스크 부족으로 죽은 경우다. 다음은 노드 추가·교체 후 방화벽 규칙이 빠진 경우이고, 그 다음이 statestore 와의 연결이 끊겨 멤버십에서 빠졌는데 코디네이터의 캐시가 아직 옛 목록을 들고 있는 경우다. 마지막 경우는 잠시 뒤 저절로 정리된다.
노드를 계획적으로 내릴 때는 갑자기 죽이지 말고 정상 종료 절차를 밟아 코디네이터가 멤버십을 갱신하게 한다.