이번에는 Search Head 클러스터링에서 캡틴 선출 과정에 대해 확인한다.
이번 시간에는 SH 클러스터링이 이미 갖춰져 있다는 가정하에 진행한다. 클러스터링 환경을 갖추지 못한 사람은 Step5. Splunk Search Head Clustering & Deployer 구성 부분을 참고하면 된다.
이번에는 4개의 서치헤더가 하나의 클러스터링을 이루고 있다.
1. Captain Election Work
1) 캡틴 선출이 일어나는 Trigger
일반적으로 서치 헤더 클러스터링을 구성하게 되면, 이때 캡틴을 먼저 선정하게 되는데 이 이후로 Trigger가 없을 경우 캡틴은 계속 유지된다. 그 이후에 캡틴이 발생하는 조건은 아래와 같은 경우에 일어나게 된다.
- 현재의 캡틴이 다운된다.
- 네트워크 파티션 문제로 인해 하나 혹은 그 이상의 검색 헤드가 네트워크에서 제외된다. 이후 네트워크 파티션이 치유되면 또 다른 별도의 캡틴 Election이 시작된다.
- 현재 캡틴은 검색 헤드가 다운됐을 때, 과반수의 구성원이 클러스터에 참여하고 있음을 확인하지 못하게 되기 때문에 캡틴을 내려놓게 된다.
2) 캡틴 선출이 일어나지 않는 Trigger
- 네트워크 파티션이 없는 비캡틴 멤버의 다운
공식 문서에 네트워크 파티션이 발생한다는 것이 전제로 나와있는데, 이 경우가 정확히 어떤 케이스인지 혼란스러웠다.
Chat GPT에게 물어보니"네트워크 파티션"은 클러스터의 노드 간 통신이 끊어지거나 분리된 상태를 나타냅니다. 네트워크 파티션이란 간단히 말해 클러스터 내의 일부 노드가 나머지 노드와 통신할 수 없는 상태입니다. 이는 네트워크 문제, 하드웨어 장애 또는 다른 이유로 인해 발생할 수 있습니다.라고 한다. 무조건 정답일 수는 없지만, 맥락상 네트워크 문제라고 해석해도 될 것 같다.
2. Captain Election Work 실습
4대의 검색헤드로 이뤄진 클러스터 환경에서 캡틴 선출 Trigger를 시켜,
1) Captain Down
- 최초의 클러스터 환경
- 캡틴이 다운
이때 다른 검색 헤드에서 검색헤드 클러스터링의 정보를 조회하려고 하면 아래와 같이 나온다.
캡틴이 Down 되어서 통신이 안되기 때문에 클러스터 정보를 가져올 수 없는 상태이다.
2) Captain Election
1) 의 과정이 지나면 바로 현재 Up되어있는 검색헤드들 사이에서 캡틴 선출이 일어난다. 그림으로 표현하면 다음과 같다.
- 캡틴 다운
- 남은 검색헤드 사이에서 Timer 설정
- 남은 검색 헤드들 사이에서 랜덤으로 타이머가 설정된다.
- 그림 상으로 보면 4번 검색 헤드가 가장 시간이 적게 남아 먼저 캡틴을 하겠다고 손을 든다.
- 새로운 캡틴 선정
-
남은 검색 헤드 1번과 3번, 4번으로부터 투표를 얻어 과반수의 원칙을 충족시킨 후 4번 검색헤드가 캡틴이 된다. (후보자는 항상 자기 자신에게 투표한다)
실제로 4번이 캡틴으로 선정된 모습이다.
-
- Down 된 (구) 캡틴 복귀
- 이후 2번 검색헤드(구캡틴)이 복귀했으나 여전히 캡틴은 4번 검색헤드로 유지되고 있다.
- 이후 2번 검색헤드(구캡틴)이 복귀했으나 여전히 캡틴은 4번 검색헤드로 유지되고 있다.
3) Captain Election Failed
2번 구성원 외에 추가 구성원이 Down 되었을 때에는 어떻게 되는가? 즉, Down 후 클러스터 내에 과반수의 원칙이 충족되지 않을 만큼의 검색헤드가 남게 되었을 때의 경우를 나타낸다.
-
검색헤드 2 다운
-
검색헤드 3 다운
-
Majority Failed
2대가 다운된 후 클러스터 상태를 살펴보면 다음과 같다.
과반수의 원칙을 충족하지 않기 때문에 캡틴 선출이 실패되었다. -
다시 검색헤드 3 UP
과반수의 원칙을 충족하게끔 검색 헤드를 UP했을 때 다시 캡틴이 선출된 모습이다.
실제 운영환경에서는 낮은 확률이지만 위와 같은 과반수의 원칙을 충족하지 못하는 케이스가 발생할 수 있는데, 이럴 경우를 대비해 정적 캡틴을 설정하기도 한다.
정적캡틴의 내용은 다음 시간에 포스팅 하도록 하겠다.
오늘은 끝이다.
