한 번/etc/hosts 권한 오류로 인한es 집단 오류

먼저 환경을 말씀드리자면: 시스템에서 사용하는 CentOS7.5,elasticsearch 버전은 5.4.0입니다.제품 집단은 세 개의elasticsearch 노드로 구성된 집단을 포함한다.두 세트의 테스트 그룹을 배치했는데 설정이 기본적으로 유사합니다.elasticsearch 프로필에 호스트 이름을 사용합니다.어떤 테스트가 끝난 후, 집단에 있는elasticsearch가 오류를 보고하기 시작해서 서비스를 제공할 수 없습니다.로그를 보니 elasticsearch에서 UnknownHostException 이상을 던져 다른 두 노드와 통신할 수 없습니다.창고 정보에 따르면, 이 이상은 다른elasticsearch 노드의 도메인 이름을 해석할 때 InetAddress를 호출하는 것입니다.getAllByName()에서 내보냈습니다.다른 집단의 유사한 설정은 그것의elasticsearch 서비스는 매우 정상적이다.유일한 차이점은 문제가 발생한 집단이 임시로 DNS 서비스를 구성했다는 것이다.정상적인 상황에 따라elasticsearch가 도메인 이름을 해석하는 방식은/etc/hosts에서 먼저 가져오고 가져오지 못하면 DNS를 조회해야 한다.elasticsearch 서비스 노드의 호스트 이름, IP는/etc/hosts에 설정되어 있습니다.따라서 한 세트가 DNS를 설정하고 다른 세트가 없더라도elasticsearch가 도메인 이름을 해석할 수 없는 문제가 발생해서는 안 된다.
도메인 이름 해석 오류의 원인을 찾기 위해elasticsearch가 도메인 이름을 해석하는 과정을 추적하기로 했습니다. 사용하는 도구는strace입니다.strace 명령은 프로세스의 시스템 호출을 추적할 수 있습니다.설치 과정은 매우 간단하다.

yum -y install strace

다음은elasticsearch의 실행 스크립트를 수정합니다. 일반적인 경로는/usr/share/elasticsearch/bin/elasticsearch입니다.이 스크립트의 마지막 몇 줄에 exec 후strace 명령 strace -o /tmp/es.strace.log -f 을 추가합니다. 아래와 같습니다.

if [ -z "$daemonized" ] ; then
    exec strace -o /tmp/es.strace.log -f "$JAVA" $ES_JAVA_OPTS -Des.path.home="$ES_HOME" -cp "$ES_CLASSPATH" \
          org.elasticsearch.bootstrap.Elasticsearch "$@"
else
    exec "$JAVA" $ES_JAVA_OPTS -Des.path.home="$ES_HOME" -cp "$ES_CLASSPATH" \
          org.elasticsearch.bootstrap.Elasticsearch "$@" 

-o 매개 변수는strace의 출력을 파일/tmp/es에 저장합니다.strace.log, -f 매개 변수는 프로세스를 추적하는 모든 하위 프로세스의 시스템 호출을 나타냅니다.두 집단의elasticsearch 노드가 모두 이 스크립트를 수정하여 서비스를 다시 시작한 후에 비교해 보았습니다.이 출력 파일을 비교하여 마침내 실마리를 발견하였다.우선,elasticsearch에서 호출된 getallByName () 은/etc/hosts 파일을 먼저 보았지만, 권한이 부족하여 이 파일에 접근할 수 없습니다.이것은 문제가 있다. 우선 이 파일은 읽을 수 있어야 하고 권한이 부족한 문제가 있어서는 안 된다. 둘째, 두 집단 모두 이 파일에 접근할 수 없지만 왜 하나는 도메인 이름을 해석할 수 있고 다른 하나는 할 수 없는가.이어서 아래로 비교해 보면 문제가 발생한 엘라스틱 검색 프로세스가 이때/etc/resovl로 검사됩니다.conf 파일이 이미 설정되어 DNS 서버에 조회를 보냈습니다.DNS가 해결되지 않아 UnknownHostException 이상이 발생했습니다.한편, 문제가 없는elasticsearch 프로세스가/etc/resovl로 검사되었습니다.conf가 설정되지 않았습니다. 이때 특별한 조작을 했습니다. 주소족을 만들었습니다. AF_NETLINK의 원래 소켓은 이 소켓 조회를 통해 도메인 이름에 대응하는 IP 주소를 얻었다.시스템에 액세스하는 ARP 정보일 수 있습니다.DNS 문제니까 문제가 생긴/etc/resolv.conf의 DNS 구성 삭제는?서비스를 다시 시작한 후에elasticsearch 서비스는 여전히 이상을 던졌습니다. 로그를 보면 프로세스가/etc/resolv를 건너뛰었습니다.conf, 그러나 로컬 DNS 포트 53 (UDP) 에 접근하기 시작했습니다. 아마도 이것은 자바의 마지막 해석 시도일 것입니다.마침 이 노드에 rpcbind 서비스가 설치되었는데 이 서비스는 53개의 포트를 감청했다. 그 결과 DNS를 통해 해석할 수 없었고 자바는 화려하게 이상을 던졌다.
문제의 근본적인 원인은/etc/hosts 파일을 읽을 수 없기 때문입니다. 이 파일을 볼 수 있는 권한은 600입니다. 즉, 루트 사용자만 읽을 수 있고 다른 사용자는 읽을 수 있는 권한이 없습니다. 읽는 것을 포함합니다.elasticsearch 서비스에서 사용하는 elasticsearch 사용자이기 때문에 당연히 읽기가 금지됩니다.다른 검색을 통해 서비스 프로세스가 이hosts 파일을 계속 업데이트하는 것을 발견했습니다. 업데이트 방식은 임시 파일을 먼저 만든 다음에rename는hosts 파일로 만듭니다. 임시 파일의 기본 권한은 600이기 때문에hosts 파일의 권한은 마지막에 600이 됩니다.이로써 전체 문제의 원인은 이미 명백해졌다.hosts 권한의 오류로 인해elasticsearch는 DNS를 통해 도메인 이름을 분석합니다. 마침 DNS 해석이 잘못되었습니다. ARP를 통해 도메인 이름을 분석하지 않았습니다.또한 이 일에서 자바 해석 도메인 이름의 루트를 볼 수 있습니다. 먼저/etc/hosts 파일, 이어서 DNS, 먼저 원격 DNS, 그리고 로컬 DNS를 볼 수 있습니다. 마지막으로 로컬 ARP 캐시에서 해석을 시도합니다. 중간에 하나의 과정이 이상을 던졌을 때 해석에 실패합니다.