엘라스틱서치(ES) 클러스터 재시작 혹은 업그레이드 Tip
개요
ES를 운영하다보면 버전 업그레이드나 플러그인 설치 혹은 elasticsearch.yml 변경으로 인해 노드들을 재시작 할 필요성이 있다. 상용환경에서 ES를 운영하면 클러스터에 속한 노드가 2대 이상일 가능성이 있고 이 클러스터가 상용 트래픽을 받으며 재시작을 하려면 순차적 재시작(Rolling Restart)를 수행해야 한다. 이때 유의할 점을 TODO 리스트로 정리하여 포스팅 한다.
아래 포스팅에서 ES에 쿼리를 날리는 부분은 Sense를 이용한 버전과 CURL을 이용한 버전을 같이 첨부한다.
TODO 리스트
샤드 할당 비활성화
ES 입장에서는 클러스터에 속한 노드중 한대가 중지되면 그 노드에 속한 프라이머리 샤드나 레플리카 샤드를 다른 노드로 옮기려는 샤드 할당(Shard Allocation) 작업을 수행한다. 이는 클러스터의 특정 노드가 장애상황일 때 이부분에 대한 Fail Over가 동작하는 과정이다. 그러나 순차적 재시작 case에서는 이 과정이 오히려 오버헤드(overhead)로 동작하기 때문에 재시작 전 클러스터의 샤드 할당 기능을 꺼두어 샤드 할당이 다시 일어나는 것을 미연에 방지한다.
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.enable": "none"
}
}
curl -XPUT 'localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
"transient": {
"cluster.routing.allocation.enable": "none"
}
}
'Synced Flush
Synced Flush를 수행하면 flush 수행후 존재하는 모든 샤드마다 유니크한 sync-id를 발급하여 샤드간의 비교(서로 동일한 샤드인지) sync-id만으로 비교가 가능하게 만든다. 링크의 문서에 의하면 샤드 비교는 recovery나 재시작 시 가장 비용(cost) 소모가 심한 작업으로 적혀있다. (따라서 필자의 생각은 이부분이 sync-id로 대체가 되면 recovery나 재시작 시 훨씬 효율적일듯 하다.)
POST _flush/synced
curl -XPOST 'localhost:9200/_flush/synced?pretty'재시작 수행
재시작 수행은 따로 언급하지 않는다.
노드상태 보기
재시작 후 로그 파일이나 노드의 상태를 관찰하여 이상이 없는지 모니터링 한다.
GET _cat/nodes
curl -XGET 'localhost:9200/_cat/nodes?pretty'
샤드 할당 활성화
샤드 할당을 다시 활성화 한다.
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.enable": "all"
}
}
curl -XPUT 'localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
"transient": {
"cluster.routing.allocation.enable": "all"
}
}
'클러스터 헬스 체크
노드가 정상화 되었는지 헬스체크를 통해 확인한다.
GET _cat/health
curl -XGET 'localhost:9200/_cat/health?pretty'버전 업그레이드시 유의 할 점
롤링 업그레이드 동안 신규 버전에 속한 프라이머리 샤드는 레플리카 샤드를 하위 버전 노드로 복사하지 않는다. 이유는 신규버전의 데이터 포맷은 하위버전과 다를수 있기 때문이다.
만약 타이밍적으로 신규버전으로 업그레이드 된 노드가 1대 뿐이라면 레플리카 샤드는 존재하지 않기 때문에 클러스터 상태는 yellow상태이다.
업그레이드가 점점 진행됨에 따라(신규버전 노드가 복수대로 바뀜에 따라) 레플리카 샤드가 생겨나므로 클러스터 상태는 다시 green으로 바뀔 것이다.
