기본 3노드 클러스터 구성 단계별 가이드

3노드 Elasticsearch 클러스터는 제가 실험실이 아닌 실제 클러스터로 간주하는 가장 작은 형태입니다. 과반수로 마스터를 선출하고, 복제본을 기본 샤드와 분리하며, 데이터와 역할이 적절히 구성된 경우 하나의 노드가 사라져도 생존할 수 있습니다. 하지만 여전히 마법은 아닙니다. 세 개의 작은 VM이 디스크가 가득 차 있다고 해서 단지 세 개라는 이유만으로 탄력적인 검색 플랫폼처럼 작동하지는 않습니다.

이 가이드는 기본적인 최신 Elasticsearch 레이아웃을 사용합니다. 세 개의 노드는 모두 마스터 자격이 있고 데이터를 처리할 수 있으며, 개인 네트워크 주소를 사용합니다. 이는 소규모 환경에 적합한 출발점입니다. 대규모 프로덕션 배포에서는 종종 전용 마스터 노드, 데이터 계층, 수집 노드, 머신 러닝 노드, 조정 전용 노드를 분리합니다. 여기서는 간단하게 시작하고, 워크로드가 정당화될 때 역할을 분할하세요.

예제는 Linux 호스트와 패키지 또는 아카이브 설치를 가정합니다. 환경에 맞게 서비스 명령을 조정하세요.

구성 편집 전

세 개의 개별 호스트 또는 VM이 필요합니다. 하나의 노트북에 세 개의 "노드"를 배치하고 고가용성이라고 부르지 마세요. 테스트 검색에는 유용할 수 있지만, 동일한 장애 도메인을 공유합니다.

각 호스트에는 다음이 필요합니다:

동일한 Elasticsearch 버전.
안정적인 개인 IP 또는 DNS 이름.
기본적으로 포트 9300에서 노드 간 전송 연결.
필요한 경우 관리 호스트 또는 로드 밸런서에서 포트 9200의 HTTP 액세스.
기본 및 복제본 샤드에 충분한 디스크 공간.
NTP 또는 유사한 서비스를 통한 시간 동기화.
안정적인 로컬 또는 연결된 스토리지에 구성된 데이터 경로.

최근 Elasticsearch 배포판에는 번들 JDK가 포함되어 있습니다. 패키징 또는 버전에서 외부 JDK가 필요한 경우, 추측하지 말고 해당 Elasticsearch 릴리스에 대해 지원되는 Java 버전을 사용하세요.

discovery.seed_hosts에서 개인 주소를 사용하세요. 매우 특정한 설계와 강력한 네트워크 제어가 없는 한 공용 IP를 피하세요.

이 가이드에서 노드는 다음과 같습니다:

node-1  10.0.10.11
node-2  10.0.10.12
node-3  10.0.10.13

공통 클러스터 설정 구성

모든 노드에서 elasticsearch.yml을 편집하세요. 파일 위치는 설치 방법에 따라 다릅니다. 패키지 설치는 일반적으로 /etc/elasticsearch/elasticsearch.yml을 사용하고, 아카이브 설치는 추출된 디렉토리 아래의 config/elasticsearch.yml을 사용합니다.

세 노드 모두에 동일한 클러스터 이름을 설정하세요:

cluster.name: my-three-node-cluster

세 노드 모두에 검색 시드 호스트를 설정하세요:

discovery.seed_hosts:
  - 10.0.10.11:9300
  - 10.0.10.12:9300
  - 10.0.10.13:9300

첫 번째 부트스트랩에만 초기 마스터 노드를 설정하세요:

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

값은 IP 주소가 아닌 node.name과 일치해야 합니다(노드 이름이 IP와 유사한 문자열이 아닌 경우). 이 설정은 새로운 클러스터를 형성할 때만 사용됩니다. 클러스터가 성공적으로 형성된 후에는 모든 노드에서 cluster.initial_master_nodes를 제거하고 향후 재시작 시 유지하지 마세요. 그대로 두면 재해 복구 또는 우발적인 재부트스트랩 시도 중에 혼란을 초래할 수 있습니다.

개인 인터페이스 또는 안전한 호스트 값에 바인딩하세요:

network.host: 10.0.10.11
http.port: 9200
transport.port: 9300

각 노드의 자체 IP를 network.host에 사용하세요. 0.0.0.0은 예제에서 편리하지만, 프로덕션에서는 의도하지 않은 인터페이스에 Elasticsearch를 노출할 수 있습니다. 사용 중인 버전에서 보안 자동 구성이 활성화된 경우 TLS 인증서, 등록 및 인증도 고려해야 합니다.

각 노드 이름 구성

노드 1:

node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

노드 2:

node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

노드 3:

node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

테스트를 위해 한 머신에서 여러 노드를 실행하는 경우 별도의 path.data 및 path.logs 값을 사용하세요. 실제 클러스터의 경우 일반적으로 호스트당 하나의 노드가 더 깔끔한 모델입니다.

노드 역할 선택

소규모 3노드 클러스터의 경우 세 노드 모두 표준 역할을 수행할 수 있습니다:

node.roles: [ master, data, ingest, remote_cluster_client ]

이렇게 하면 마스터 자격이 있는 노드가 세 개가 되어 마스터 선거가 과반수로 작동합니다. 마스터 자격이 있는 노드가 세 개인 경우 클러스터는 하나를 잃어도 마스터를 선출하거나 유지할 수 있습니다. 두 개가 사라지면 클러스터 상태 결정을 안전하게 내릴 수 없습니다.

대규모 클러스터의 경우 전용 마스터 자격 노드가 더 나은 경우가 많습니다. 이는 데이터 또는 수집 작업이 마스터 작업을 굶주리게 할 수 없기 때문입니다. 이는 이 기본 설정의 요구 사항이 아니라 확장 개선 사항입니다.

OS 및 네트워크 기본 사항 확인

Elasticsearch를 시작하기 전에 모든 노드 쌍 간의 전송 연결을 테스트하세요:

nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300

가능하면 각 노드에서 실행하세요. 방화벽과 클라우드 보안 그룹은 노드 간 전송 트래픽을 허용해야 합니다. HTTP 포트 9200은 클라이언트 및 관리 호출용이고, 전송 포트 9300은 클러스터 노드가 서로 통신하는 데 사용됩니다.

또한 데이터 및 로그 디렉토리의 파일 소유권을 확인하세요. Elasticsearch 프로세스는 둘 다에 쓸 수 있어야 합니다.

노드 시작

systemd를 사용한 패키지 설치의 경우:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

테스트 중 아카이브 설치의 경우:

bin/elasticsearch

세 노드를 모두 시작하세요. 완벽한 순서로 시작할 필요는 없지만 로그를 주시하세요. 클러스터가 한 번 형성되고 노드가 합류하는 것을 확인하고 싶습니다. 노드가 마스터를 찾을 수 없다고 말하면 node.name, cluster.name, discovery.seed_hosts, 전송 연결 및 TLS/보안 설정에 집중하세요.

클러스터가 형성되면 모든 노드의 구성에서 cluster.initial_master_nodes를 제거하고 필요하면 계획된 유지보수 기간 동안 나중에 다시 시작하세요. 처음 부트스트랩을 시도하는 동안에는 제거하지 마세요.

클러스터 상태 확인

포트 9200에 도달할 수 있는 호스트에서:

curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

사용자 인덱스가 없는 새로운 클러스터는 샤드가 0개인 녹색 상태를 표시할 수 있습니다. 확인할 필드는 status, number_of_nodes, number_of_data_nodes입니다.

간결한 보기:

curl -s "http://10.0.10.11:9200/_cat/health?v"

그런 다음 노드 멤버십을 확인하세요:

curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"

세 노드가 모두 표시되어야 합니다. 하나의 노드에는 선출된 마스터 표시가 있습니다. 세 노드 모두 예상한 역할을 표시해야 합니다.

복제본이 있는 테스트 인덱스 생성

샤드 배치를 확인하기 위해 테스트 인덱스를 생성하세요:

curl -X PUT "http://10.0.10.11:9200/test-data-index?pretty"   -H 'Content-Type: application/json'   -d '{
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }'

샤드 확인:

curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"

세 개의 기본 샤드와 하나의 복제본이 있으면 노드에 분산된 6개의 샤드 복사본이 표시되어야 합니다. Elasticsearch는 복제본을 기본 샤드와 동일한 노드에 배치하지 않습니다.

클러스터가 노란색이면 이유를 물어보세요:

curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty"   -H 'Content-Type: application/json'   -d '{}'

일반적인 원인은 충분한 데이터 노드 자격이 없거나, 디스크 워터마크, 할당 비활성화, 또는 노드 속성과 일치하지 않는 할당 인식 규칙입니다.

단일 노드 장애 동작 테스트

비프로덕션 테스트에서 하나의 노드를 중지하세요:

sudo systemctl stop elasticsearch

다른 노드에서 상태를 확인하세요:

curl -s "http://10.0.10.12:9200/_cluster/health?pretty"

마스터 자격이 있는 노드 세 개 중 두 개가 남아 있으므로 클러스터는 여전히 마스터가 있어야 합니다. 타이밍, 샤드 재배치 및 복제본 배치에 따라 Elasticsearch가 반응하는 동안 상태가 녹색 또는 노란색일 수 있습니다. 노드를 다시 시작하고 복구를 확인하세요:

sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"

이 테스트는 클러스터가 중요해지기 전에 수행할 가치가 있습니다. 정상적인 복구가 어떻게 보이는지 알려주므로 실제 장애가 발생했을 때 덜 놀라게 됩니다.

몇 가지 프로덕션 가드레일

Elasticsearch 버전에 대한 보안을 활성화하고 이해하세요. 인증되지 않은 HTTP API를 인터넷이나 광범위한 내부 네트워크에 노출하지 마세요.

클러스터에 의존하기 전에 스냅샷을 생성하세요. 복제본은 노드 손실을 보호하고, 스냅샷은 삭제, 손상 및 운영 실수로부터 보호합니다.

디스크 사용량, JVM 힙 압력, 노드 수, 클러스터 상태, 보류 중인 작업 및 스냅샷 성공을 모니터링하세요. 3노드 클러스터는 복구할 충분한 용량이 있는 경우에만 탄력적입니다.

샤드 수를 적당히 유지하세요. 많은 작은 샤드는 오버헤드를 만듭니다. 기본 클러스터는 데이터 양이 많지 않더라도 수천 개의 작은 인덱스로 압도될 수 있습니다.

마지막으로, 부트스트랩 설정을 문서화하고 형성 후 cluster.initial_master_nodes를 제거하세요. 대부분의 3노드 설정 문제는 작은 불일치에서 비롯됩니다: 부트스트랩 이름과 일치하지 않는 노드 이름, 차단된 전송 포트, 이전 클러스터의 재사용된 데이터 디렉토리, 또는 보안 기본값에 대한 가정. 더 특이한 설정을 변경하기 전에 먼저 확인하세요.

일반적인 시작 실패

노드가 클러스터를 형성하지 않으면 먼저 간단한 것들을 확인하세요.

cluster.name은 모든 노드에서 일치해야 합니다. 다른 클러스터 이름을 가진 노드는 시드 호스트 목록에 나타난다고 해서 조인하지 않습니다.

node.name은 첫 번째 부트스트랩 중 cluster.initial_master_nodes에 사용된 값과 일치해야 합니다. 구성이 node-1이라고 말하지만 부트스트랩이 es-node-1을 나열하면 검색이 중단될 수 있습니다.

전송 포트는 노드 간에 연결 가능해야 합니다. 9200의 HTTP 액세스만으로는 충분하지 않습니다. 필요한 경우 nc, 보안 그룹 검사 또는 패킷 캡처를 사용하세요.

데이터 디렉토리에는 해당 클러스터에 다시 조인하려는 의도가 없는 한 이전 클러스터의 메타데이터가 포함되어서는 안 됩니다. 이전 테스트의 디스크를 재사용하면 클러스터 UUID 또는 안전하지 않은 부트스트랩에 대한 혼란스러운 오류가 발생할 수 있습니다.

루프백이 아닌 주소에 바인딩할 때 메모리 및 부트스트랩 검사가 중요합니다. Elasticsearch는 파일 디스크립터, 가상 메모리, 메모리 잠금 및 검색 구성에 대한 검사를 시행할 수 있습니다. 맹목적으로 재시도하지 말고 시작 로그를 읽으세요.

클러스터가 작동한 후

클러스터가 중요한 데이터를 전달하기 전에 스냅샷 저장소를 생성하세요. 복제본은 백업이 아닙니다. 잘못된 삭제, 매핑 실수 또는 애플리케이션 버그는 모든 복사본에 빠르게 복제됩니다.

운영 문서에 노드 이름, IP, 역할, 데이터 경로, 인증서 위치 및 부트스트랩 기록을 기록하세요. 장애 발생 시 아무도 node-2가 마스터 자격이 있어야 하는지 역설계하고 싶지 않습니다.

노드 손실, 빨간색 상태, 긴 노란색 상태, 디스크 워터마크, JVM 힙 압력, 실패한 스냅샷 및 빈번한 마스터 선거에 대한 알림을 설정하세요. 3노드 클러스터는 하나의 장애를 견딜 수 있는 여유를 제공하지만, 두 번째 장애 전에 이를 인지하고 복구해야만 가능합니다.

복구를 고려하여 용량을 계획하세요. 각 노드가 매우 높은 디스크 사용량으로 실행되는 경우 하나의 노드를 잃으면 복제본이 재구축될 공간이 너무 적을 수 있습니다. 건강한 클러스터에는 오늘의 기본 샤드에 충분한 공간뿐만 아니라 여유 용량이 필요합니다.

롤링 재시작 연습

패키지 업그레이드가 필요하기 전에 롤링 재시작을 연습하세요. 하나의 노드를 재시작하고, 다시 조인할 때까지 기다린 후, 상태와 복구를 확인하고, 다음 노드로 이동하세요. 의도적으로 전체 클러스터를 종료하지 않는 한 세 노드를 모두 한 번에 재시작하지 마세요.

간단한 순서는 다음과 같습니다:

sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

클러스터에 큰 샤드가 있는 경우 계획된 재시작 전에 지연 할당을 조정해야 하는지 고려하세요. 목표는 노드가 몇 분 안에 돌아올 때 불필요한 복제본 재구축을 피하는 것입니다. 유지보수 후 할당이 활성화되고 임시 설정이 제거되었는지 확인하세요.

또한 클라이언트 동작을 테스트하세요. 애플리케이션은 둘 이상의 Elasticsearch 엔드포인트 또는 실패한 노드를 제거하는 로드 밸런서를 사용해야 합니다. 3노드 클러스터는 하나의 노드가 다운되었을 때 클라이언트가 나머지 정상 노드에 도달할 수 있는 경우에만 도움이 됩니다.

마지막으로 도움이 되는 습관: 각 노드의 최종 elasticsearch.yml 사본을 구성 관리에 보관하세요. 설정 중에 수동 편집은 표류하는 경향이 있으며, 표류는 다음 노드 교체를 필요 이상으로 어렵게 만드는 원인입니다.