일반적인 Elasticsearch 클러스터 분할-뇌 시나리오 문제 해결

분할 뇌는 Elasticsearch 실패 중에서도 극적으로 들리기 때문에 사람들이 이야기하지만, 유용한 질문은 더 실용적입니다: 클러스터의 두 부분 이상이 동시에 마스터 수준의 결정을 내릴 수 있습니까? 최신 Elasticsearch 버전은 과반수 기반 클러스터 조정을 통해 이를 방지하도록 설계되었습니다. 특히 잘못된 discovery.zen.minimum_master_nodes 설정을 가진 7.0 이전의 오래된 클러스터는 잘못 구성하기 더 쉬웠습니다.

따라서 이 문서는 종종 혼동되는 두 가지 상황을 구분합니다. 진정한 분할 뇌는 독립적인 파티션이 각각 마스터를 선출하거나 유지할 수 있음을 의미합니다. 마스터 선출 중단은 클러스터가 과반수를 확보하지 못해 마스터를 선출할 수 없음을 의미합니다. 첫 번째는 충돌하는 클러스터 상태와 데이터 불일치의 위험이 있습니다. 두 번째는 고통스럽지만 일반적으로 더 안전한 실패 모드입니다.

분할 뇌의 모습

건강한 클러스터에서 선출된 마스터 하나가 클러스터 상태(인덱스 생성, 샤드 할당 결정, 매핑, 노드 멤버십 및 유사한 메타데이터)를 관리합니다. 데이터 노드는 읽기와 쓰기를 처리할 수 있지만, 클러스터는 여전히 세계에 대한 단일 마스터 관점에 의존합니다.

분할 뇌 시나리오는 네트워크 파티션이나 잘못된 검색 설정으로 인해 두 노드 그룹이 각각 실제 클러스터인 것처럼 행동할 때 발생합니다. 한쪽은 인덱스에 대한 쓰기를 수락하는 반면 다른 쪽은 다른 쓰기를 수락할 수 있습니다. 연결이 복원되면 Elasticsearch는 텍스트 파일처럼 두 개의 충돌하는 기록을 간단히 병합할 수 없습니다.

최신 Elasticsearch에서 파티션에 마스터 자격이 있는 노드의 과반수가 없으면 마스터를 선출하지 않아야 합니다. 즉, 일부 노드는 경쟁 클러스터를 형성하는 대신 사용할 수 없게 될 수 있습니다. 이것이 원하는 동작입니다.

버전이 중요합니다

Elasticsearch 6.x 및 이전 버전의 경우 핵심 설정은 다음과 같습니다:

discovery.zen.minimum_master_nodes: 2

규칙은 마스터 자격이 있는 노드의 과반수였습니다: (N / 2) + 1, 1을 더하기 전에 정수 나눗셈으로 내림합니다. 세 개의 마스터 자격 노드가 있는 경우 2로 설정합니다. 다섯 개인 경우 3으로 설정합니다. 3노드 클러스터에서 1로 설정하면 분할 뇌가 가능해집니다.

Elasticsearch 7.x 이상에서는 discovery.zen.minimum_master_nodes가 사라졌습니다. 클러스터 조정이 변경되었고 Elasticsearch가 투표 구성을 관리합니다. 새 클러스터는 여전히 cluster.initial_master_nodes로 올바른 부트스트래핑이 필요하지만, 이 설정은 초기 클러스터 형성에만 사용됩니다. 클러스터가 형성된 후에는 구성에서 제거하십시오.

오래된 discovery.zen 설정을 추가하여 최신 클러스터를 "수정"하지 마십시오. 더 이상 제어 평면이 아닙니다.

일반적인 원인

가장 일반적인 트리거는 마스터 자격 노드 간의 네트워크 파티션입니다. 클라우드 측면에서는 보안 그룹 변경, 잘못된 라우트 테이블, 네트워크 ACL, 영역 수준 문제 또는 전송 포트 9300을 차단하는 방화벽 규칙일 수 있습니다. 베어 메탈 환경에서는 스위치, VLAN, DNS, MTU 또는 패킷 손실 문제일 수 있습니다.

또 다른 원인은 마스터 자격 노드가 너무 적게 실행되는 것입니다. 두 개의 마스터 자격 노드는 하나가 실패한 후 깔끔한 과반수가 없기 때문에 어색합니다. 프로덕션 클러스터는 일반적으로 세 개의 전용 마스터 자격 노드 또는 소규모 배포에서 세 개의 혼합 역할 노드를 사용합니다.

세 번째 원인은 오래되었거나 재사용된 데이터 디렉터리입니다. VM을 복제하거나 이전 클러스터의 디스크를 재사용하는 경우 노드가 의도하지 않은 클러스터 메타데이터를 전달할 수 있습니다. 이는 혼란스러운 조인 실패로 이어질 수 있으며, 최악의 경우 별도 클러스터의 우발적 형성으로 이어질 수 있습니다.

마지막으로, 압박 속에서 수동 복구는 문제를 악화시킬 수 있습니다. 임의의 노드를 재부팅하거나, 데이터 경로를 지우거나, 어떤 파티션이 권위적인지 알기 전에 안전하지 않은 할당을 강제하는 것은 복구 가능한 사고를 데이터 손실로 바꿀 수 있습니다.

사고 중 첫 번째 확인

도달 가능한 모든 노드에 무엇을 생각하는지 물어보는 것으로 시작하십시오:

curl -s "http://NODE:9200/_cat/master?v"
curl -s "http://NODE:9200/_cat/nodes?v&h=ip,name,roles,master,node.role"
curl -s "http://NODE:9200/_cluster/health?pretty"

가능하면 둘 이상의 노드에 대해 실행하십시오. 다른 노드가 다른 마스터나 다른 노드 멤버십을 보고하면 분할된 클러스터나 격리된 노드를 보고 있을 수 있습니다.

마스터 자격 노드의 로그에서 선거, 조인, 연결 해제 및 게시 실패에 대한 메시지를 확인하십시오. 유용한 검색어에는 master not discovered, elected-as-master, node-left, node-join, publication, connect_transport_exception 및 handshake가 포함됩니다.

그런 다음 HTTP뿐만 아니라 전송 연결을 테스트하십시오:

nc -vz node-1.example.internal 9300
nc -vz node-2.example.internal 9300
nc -vz node-3.example.internal 9300

노드 간에 이러한 테스트를 실행하십시오. 로드 밸런서나 배스천 호스트가 HTTP 포트 9200에 도달하는 것은 Elasticsearch 노드가 9300을 통해 클러스터를 형성할 수 있는지에 대해 거의 알려주지 않습니다.

검색 및 부트스트랩 구성 확인

Elasticsearch 7.x 이상에서 다음 설정을 검사하십시오:

cluster.name: my-cluster
discovery.seed_hosts:
  - node-1:9300
  - node-2:9300
  - node-3:9300

완전히 새로운 클러스터의 경우에만:

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

부트스트랩 이름은 node.name과 일치해야 합니다. 클러스터가 형성된 후 모든 노드에서 cluster.initial_master_nodes를 제거하십시오.

Elasticsearch 6.x 및 이전 버전에서 다음을 확인하십시오:

discovery.zen.minimum_master_nodes: 2

3개의 마스터 자격 노드 클러스터의 경우. 또한 모든 마스터 자격 노드가 일관된 검색 호스트와 클러스터 이름을 가지고 있는지 확인하십시오.

복구 원칙

진정한 분할 뇌가 의심되면 어느 쪽이 권위적인지 알 때까지 클러스터 API를 통해 변경을 중단하십시오. 가장 안전한 복구는 일반적으로 다음 순서를 따릅니다:

증거 보존: 각 파티션에서 로그, 노드 목록, 마스터 보기 및 인덱스 건강 상태를 수집합니다.
네트워크 연결 복원 또는 의도적으로 잘못된 쪽을 격리합니다.
과반수, 최신 유효 데이터 및 비즈니스 영향을 기반으로 권위적인 파티션을 선택합니다.
독립적인 파티션으로 계속되어서는 안 되는 노드에서 Elasticsearch를 중지합니다.
노드를 한 번에 하나씩 다시 시작하고 권위적인 클러스터에 조인하는지 확인합니다.
기본 샤드 기록이 손실되거나 일관성이 없는 경우 스냅샷에서 누락된 데이터를 복원합니다.

일상적인 분할 뇌 수정으로 트랜스로그 디렉터리를 삭제하지 마십시오. 그것은 위험한 조언입니다. 트랜스로그는 Elasticsearch 복구의 일부입니다. 데이터 경로 아래의 파일을 수동으로 제거하면 데이터 손실이 발생할 수 있으며 Elastic 지원의 버전별 지침에 따라 수행하거나 손실을 수락하고 재구축 계획이 있는 경우에만 수행해야 합니다.

두 파티션이 독립적으로 쓰기를 수락한 경우 완벽한 자동 병합이 없을 수 있습니다. 스냅샷에서 복원하거나, 소스 시스템에서 다시 인덱싱하거나, 애플리케이션 로그를 재생하거나, 한쪽의 데이터를 권위 있는 것으로 선택해야 할 수 있습니다.

현실적인 예

세 개의 개인 서브넷에 걸친 3노드 클러스터를 상상해 보십시오. 방화벽 변경으로 인해 노드 1과 노드 2 및 3 간의 전송 트래픽이 실수로 차단됩니다. 노드 2와 3은 여전히 서로를 볼 수 있으므로 마스터를 유지하거나 선출합니다. 노드 1은 과반수를 볼 수 없습니다. 현대적이고 올바르게 구성된 클러스터에서 노드 1은 자체적으로 경쟁 마스터를 형성해서는 안 됩니다. 노드 1을 사용하는 클라이언트는 실패할 수 있지만 클러스터는 충돌하는 마스터를 피합니다.

이제 discovery.zen.minimum_master_nodes: 1로 설정된 세 개의 마스터 자격 노드가 있는 오래된 6.x 클러스터를 상상해 보십시오. 노드 1은 자체적으로 선출할 수 있는 반면, 노드 2와 3은 다른 마스터를 선출합니다. 이것이 고전적인 분할 뇌 위험입니다. 수정은 네트워크를 다시 연결하는 것만이 아닙니다. 또한 쿼럼 구성을 수정하고 잘못된 쪽에서 수락된 쓰기를 처리하는 방법을 결정해야 합니다.

예방

중소 규모 클러스터에는 세 개의 마스터 자격 노드를 사용하십시오. 더 큰 클러스터의 경우 검색 및 인덱싱 부하가 클러스터 조정을 방해하지 않도록 전용 마스터 노드로 만드십시오.

마스터 자격 노드를 패킷 손실이 적은 안정적인 네트워크에 유지하십시오. 영역 간에 노드를 분산하면 가용성에 도움이 될 수 있지만, 영역 간 네트워크가 신뢰할 수 있고 쿼럼 설계가 여전히 의미 있는 경우에만 가능합니다.

마스터 변경을 모니터링하십시오. 계획된 유지 관리 중 마스터 선거는 정상입니다. 정상 트래픽 중 빈번한 선거는 경고 신호입니다.

HTTP 가동 시간뿐만 아니라 전송 연결을 모니터링하십시오. 노드는 9200에 응답할 수 있지만 전송 트래픽이 차단되면 클러스터에 올바르게 참여하지 못할 수 있습니다.

정기적으로 스냅샷을 찍고 복원을 테스트하십시오. 복제본은 심각한 사고 중 잘못된 삭제, 손상된 데이터 또는 충돌하는 쓰기로부터 보호하지 않습니다.

부트스트랩 설정에 주의하십시오. 최신 클러스터에서 cluster.initial_master_nodes는 일상적인 검색 설정이 아닙니다. 새 클러스터를 만드는 데 사용한 다음 제거하십시오.

최고의 분할 뇌 복구는 결코 필요하지 않은 것입니다: 과반수 기반 마스터 자격, 올바른 버전별 검색 설정, 지루한 네트워크 규칙 및 테스트된 스냅샷 계획.

분할 뇌와 정상 선거를 구별하는 방법

마스터 선거는 자동으로 분할 뇌가 아닙니다. 롤링 재시작, 네트워크 플랩 또는 마스터 노드 장애 중에 Elasticsearch는 새 마스터를 선출할 수 있습니다. 클러스터가 하나의 권위적인 마스터를 유지하고 이전 마스터가 물러나면 이는 정상적인 분산 시스템 동작입니다.

경고 신호는 다른 노드의 다른 보기입니다. 노드 A가 자신을 마스터로 보고하는 반면 노드 B는 노드 C를 마스터로 보고하면 중지하고 조사하십시오. 두 노드 그룹이 연결이 끊긴 동안 클러스터 상태 변경을 모두 수락하면 짧은 선거보다 훨씬 더 심각한 상황입니다.

또한 클라이언트 동작을 관찰하십시오. 격리된 노드에 고정된 클라이언트는 과반수 측이 건강한 경우에도 실패를 볼 수 있습니다. 이것이 과반수 클러스터가 손상되었다는 의미는 아닙니다. 클라이언트 연결 전략이나 로드 밸런서가 여전히 참여할 수 없는 노드로 트래픽을 보내고 있음을 의미할 수 있습니다.

로드 밸런서 및 클라이언트 라우팅

Elasticsearch 전송 검색은 클라이언트 HTTP 라우팅과 동일하지 않습니다. 마스터 검색을 일반 HTTP 로드 밸런서 뒤에 두고 클러스터 멤버십을 해결할 것으로 기대하지 마십시오. 노드는 서로 전송 연결이 필요합니다.

클라이언트의 경우 여러 HTTP 엔드포인트를 사용하거나 비정상 노드를 신속하게 제거하는 로드 밸런서를 사용하십시오. 마스터를 잃은 노드는 짧은 시간 동안 프로세스가 수신 대기 중일 수 있지만 쓰기에 좋은 대상이 아닙니다. 상태 확인은 "포트 9200이 열려 있음"보다 더 의미 있어야 합니다.

실용적인 HTTP 상태 확인은 로컬에서 클러스터 건강 상태를 쿼리하고 발견된 마스터가 없는 노드를 거부할 수 있습니다. 정확한 접근 방식은 클라이언트와 인프라에 따라 다르지만 원칙은 간단합니다: 격리된 노드에 계속 쓰기를 보내지 마십시오.

사후 정리

클러스터가 안정화된 후 인덱스 건강 상태, 문서 수 및 애플리케이션 수준의 진실 공급원 수를 비교하십시오. 쓰기가 다른 파티션에 도달할 가능성이 있는 경우 Elasticsearch 건강 상태만으로는 데이터가 의미상 올바르다는 것을 증명할 수 없습니다.

타임라인을 검토하십시오. 어떤 노드가 먼저 연결을 잃었습니까? 사건 전에 어떤 노드가 마스터였습니까? 클라이언트가 계속 쓰기를 수행했습니까? 스냅샷이 최신이었습니까? 사용자가 알아차리기 전에 알림이 발생했습니까? 이러한 세부 사항은 네트워크 수정만 필요한지 아니면 데이터 조정 계획이 필요한지 결정합니다.

이전 클러스터의 경우 버전 및 검색 설정 작업을 예약하십시오. 여전히 discovery.zen.minimum_master_nodes에 의존하는 버전을 실행 중인 경우 오늘 올바른지 확인한 다음 업그레이드 경로를 계획하십시오. 분할 뇌 예방은 일회성 런북 단계가 아닙니다. 클러스터 수명 주기 관리의 일부입니다.

패닉 중 피해야 할 구성 변경

노드가 조인하도록 cluster.name을 변경하지 마십시오. 이는 다른 클러스터 ID 문제를 만듭니다.

의도적으로 노드의 로컬 샤드 복사본을 폐기하고 클러스터에 다른 곳에 유효한 복사본이나 스냅샷이 있는지 확인하지 않는 한 데이터 경로를 지우지 마십시오.

일반적인 재시작 수정으로 기존 최신 클러스터에 cluster.initial_master_nodes를 다시 추가하지 마십시오. 이 설정은 초기 부트스트랩을 위한 것이지 일상적인 검색을 위한 것이 아닙니다.

가용성을 복원하기 위해 이전 클러스터에서 쿼럼 스타일 보호를 낮추지 마십시오. 소수 파티션을 쓰기 가능하게 만드는 것은 진전처럼 느껴질 수 있지만, 정확히 충돌하는 마스터가 가능해지는 방법입니다.

어색한 장애 도메인을 위한 설계

세 개의 마스터 자격 노드는 단일 인프라 이벤트가 그중 두 개를 제거할 수 없을 때 가장 잘 작동합니다. 3영역 클라우드 리전에서 영역당 하나의 마스터 자격 노드는 일반적인 패턴입니다. 2영역 환경에서는 한 영역에 두 개의 투표가 포함될 수 있으므로 배치가 더 어렵습니다. 더 큰 영역이 실패하면 나머지 단일 투표는 안전하게 마스터를 선출할 수 없습니다. 이는 Elasticsearch가 취약해서가 아니라 과반수 수학 때문입니다.

실패 모드를 고려하지 않고 짝수 개의 투표 노드를 추가하여 이 문제를 해결하지 마십시오. 네 개의 마스터 자격 노드도 여전히 과반수가 필요하며, 2대2 파티션은 안전하게 한쪽을 선택할 수 없습니다. 전용 투표 전용 노드는 일부 설계에서 도움이 될 수 있지만 원칙은 동일합니다: 클러스터는 클러스터 상태 결정을 내리기 위해 신뢰할 수 있는 과반수가 필요합니다.

이것을 아키텍처 노트에 기록하십시오. 중단 중에 사람들은 종종 생존 노드나 생존 영역이 계속 쓰기를 제공할 수 없는 이유를 묻습니다. 사고 전에 답이 명확해야 합니다: 과반수 없이 쓰기를 수락하면 충돌하는 기록의 위험이 있습니다.