[Elasticsearch] 엘라스틱서치 클러스터 구성해보기
안녕하세요.
지난 포스팅에서는 엘라스틱서치를 설치하고 환경설정하여 Bootstrap Checks 까지 넘어가보는 예제를 구성해보았는데요.
- 엘라스틱서치 환경설정(Bootstrap Checks)
이번 포스팅에서는 구성한 Bootstrap Checks를 통과한 하나의 노드서버를 기준으로 2개의 노드서버를 추가하여 노드 클러스터링을 진행해보겠습니다.
우선 1번 노드를
https://sas-study.tistory.com/494
[GCP] VM 인스턴스 이미지 만들기(머신 복제)
안녕하세요. 오늘은 VM 인스턴스의 머신 이미지를 복사하여 같은 환경의 VM 인스턴스를 만드는 과정을 공유하고자 합니다. 우선 제가 이 행위에 대해서 왜 하고 왜 필요한지에 대해서 먼저 설명
sas-study.tistory.com
아래의 vm 인스턴스 혹은 aws로 진행하시는 경우 aws에서 제공하는 스냅샷 기능을 통해서 복사한 후 2개의 서버를 만들어주세요. 하나의 서버에서 세개의 엘라스틱서치를 실행해도 괜찮지만 이해도 높은 실습을 위해서는 한 서버에서 여러 노드가 동작하기보다 하나의 서버에서 하나의 노드만 동작하고 해당 노드서버들이 클러스터가 구성되는 과정을 이해하기 위해서는 여러 서버로 구성하는 편이 훨씬 좋습니다.
해당 서버가 준비되었다면 우선 세 서버를 접속합니다.
우선 세 노드 서버의 config 디렉토리 아래에 있는 elasticsearch.yml 파일이 1번 노드와 동일하게 적혀져 있을 겁니다. 이 부분을 각각 노드서버에 맞게 수정해줍니다.
변경사항을 하나씩 설명드리겠습니다.
- cluster.name : 해당 속성으로 클러스터 명이 설정되며 각 노드간의 클러스터 가입이 해당 값이 같은 값을 기준으로 클러스터링 됩니다. 각 노드간 동일한 값으로 설정해야하니 따로 건드리지는 않겠습니다.
- node.name : 각 노드의 이름입니다. 각 노드간 자신들이 통신해야될 노드명과 호스트는 알아야만 통신할 수 있어서 각각 넘버링에 맞게 정의해주었습니다.
- network.host : 해당 값은 기존의 1번 노드의 내부IP 값으로 설정되었을텐데요. 이를 환경변수를 활용해서 _local_, _site_로 수정해줍니다. _local_은 내부 루프백 주소(localhost/127.0.0.1) 과 같습니다. _site_는 1번 노드는 기존 gcp 내부 IP 값과 동일할테지만 각각 2,3번 노드는 자신들이 설치된 노드 서버의 내부IP 값이 설정되게 됩니다. (머신 이미지 만들때 이부분을 해놓을껄.. 하고 후회중입니다.)
- discovery.seed_hosts : 각 노드가 클러스터를 구성하기 위해서 마스터 노드를 선출하기 위해 노드들을 탐색하는 과정을 디스커버리라고 합니다. 그때 대상 호스트를 알아야 하기 때문에 여기서는 1,2,3번 노드의 host 명을 적어주겠습니다. 근데 여기서 host는 서버 주소여야하는데 이 다음에 호스트 파일을 수정하여 각각 IP를 등록하여 해당 문자열을 인식했다고 생각해주시면 되겠습니다.
- cluster.initial_master_nodes : 마스터 노드로 선출될 수 있는 후보 노드들을 지정해주는 곳입니다. 세 노드를 모두 기재해주겠습니다.
호스트 파일 수정
우선 위에서 discovery.seed_hosts 설정에서 호스트 ip 주소가 아닌 문자열이 들어간 것을 확인할 수 있습니다. gcp에서 정해준 host로 찾아간다고 생각하실 수 있겠지만 gcp 이전에는 해당 서버는 단순 물리 서버이기 때문에 기똥차게 무언가를 찾아내거나 gcp에서 해당 기능을 제공한다고 생객해서는 안됩니다. 그래서 host 파일을 수정해서 우리가 정해놓은 호스트명에 ip를 대칭시켜주는 작업을 진행하겠습니다.
호스트 파일의 경로는 /etc/hosts 이고 해당 파일은 관리자 권한이기 때문에 sudo 명령어를 사용합니다.
sudo vi /etc/hosts
해당 파일에 아래와 같이 기재해주겠습니다.
10.178.0.9 blackdog-elastic-1
10.178.0.10 blackdog-elastic-2
10.178.0.11 blackdog-elastic-3
1번 노드의 ip(10.178.0.9) 를 blackdog-elastic-1로
2번 노드의 ip(10.178.0.10) 를 blackdog-elastic-2로
3번 노드의 ip(10.178.0.11) 를 blackdog-elastic-3로 매핑해주었습니다.
이는 1번 노드에서만 해당하기 때문에 이를 2번, 3번 노드에도 그대로 설정해줍니다.
이렇게하면 노드간의 통신할때, curl 명령어로 예를 들자면
curl 10.178.0.9:9200
curl blackdog-elastic-1:9200
이 두가지를 모두 인식하게 됩니다. 따라서 discovery.seed_hosts 속성에서 지정해놓은 값은 단순 host 앨리야스라고 생각하시면 될것 같습니다.
방화벽 추가 설정
이제 노드간 클러스터링을 위해서 설정은 마무리가 되었습니다. 하지만 엘라스틱서치 관점에서의 설정이고 물리적 서버 관점에서는 아직 엘라스틱서치간의 통신이 되지 않습니다. 왜냐하면 노드간 내부통신을 할때 사용하는 9300 번 포트를 gcp 방화벽에서 설정해주지 않았기 때문입니다.
우선 저는 1번 노드만이 외부 클라이언트(개인 맥북)와의 통신으로 노드 정보를 확인할 수 있게하고, 2/3번 노드는 외부와의 9200 포트를 닫아놓고자 합니다.
또한 9300 번 포트는 각 노드의 서버에서만 통신이 되며 외부와의 통신은 단절되도록 셋팅하겠습니다.(개인 맥북으로는 9300으로 요청이 안되도록 하겠음)
다시 gcp의 vm 인스턴스에서 방화벽 규칙 추가로 돌아가보겠습니다.
방화벽 규칙 명은 blackdog-elastic-internal로 지정해주겠습니다.
이제 여기가 제일 중요한데요. 저는 대상을 지정된 대상 태그(태그가 붙어있는 곳에 방화벽을 적용하겠다는 것.)를 이용하여 방화벽규칙과 동일한 태그를 추가한 서버만이 9200, 9300 번 포트를 오픈하도록 합니다.
그리고 소스필터는 소스태그로 지정하여 방화벽 규칙명과 동일한 태그를 추가한 서버에서만 트래픽을 허용하도록 하겠습니다.
방화벽 규칙을 만들어줍니다!
여기서 약간 헷갈릴 수 있는데
대상태그 : 해당 방화벽을 태그를 지정하여 적용하겠다는 것.
소스태그 : 요청을 받을 ip를 태그를 지정한 서버에서만 받겠다는 것.
그래서 1번, 2번, 3번 노드에 해당 방화벽 규칙을 추가하게 된다면
태그조건때문에 1번 노드는 9200, 9300 번 포트를 오픈하면서 2/3번 노드 서버에서만 해당 포트의 트래픽을 허용합니다. 2번은 1/3번 3번은 1/2번 동일하게 적용됩니다.
다만 1번은 9200 포트를 외부 클라이언트와 통신용으로 열어두었기 때문에 9200 포트는 모두에게 public 하게 열려있게 됩니다. 이를 잘 이해하셔야 합니다.
따라서 해당 방화벽을 모든 서버에 적용해주겠습니다.
방화벽 적용
아래와 같이 인스턴스 수정으로 접근하여 네트워크 태그를 추가해줍니다.
위와 같이 방화벽을 모두 적용해주었습니다.
클러스터 구성 확인
이제 각 노드서버에 접근하여 엘라스틱서치를 실행해주겠습니다. 우선 기존 노드에 실행이력이 있는 data 디렉토리를 삭제해주겠습니다. 해당 data 디렉토리에 있는 실행이력때문에 클러스터링이 잘 진행되지 않았기에 혹시나 원하시는 결과가 안나오신다면 엘라스틱서치 루트 디렉토리에 있는 data 디렉토리를 삭제해주세요.
rm -rf data
이제 각각의 엘라스틱서치를 실행해보겠습니다.
bin 폴더 아래 elasticsearch 를 실행하였고 문제없이 started가 되어있습니다. 로그로 클러스터가 구성된 부분을 확인할 수 있겠지만 조금 많기에 curl 명령어로 1번 노드에 요청을 하나 넣어보겠습니다.
curl "http://{1번노드IP}:9200/_cat/nodes?v"
해당 명령어를 실행해보면 아래와 같이 클러스터가 구성된 노드들을 확인할 수 있습니다.
디스커버리를 원활하게 수행한 것을 확인되고 2번 노드가 마스터 노드로 선출된 것을 확인하실 수 있으실겁니다. 또한 name쪽도 제가 작성한 노드의 이름으로 설정된 것을 확인할 수있었습니다.
감사합니다.