2.X/7. Administration Monitoring Deployment

7-3-5. Rolling Restarts

drscg 2017. 9. 23. 11:57

There will come a time when you need to perform a rolling restart of your cluster—keeping the cluster online and operational, but taking nodes offline one at a time.

cluster를 차례대로 재 시작(cluster는 온라인이고 동작을 하는 상태로 유지하면서, node를 차례로 오프라인으로 하는)해야 할 경우가 있을 것이다.

The common reason is either an Elasticsearch version upgrade, or some kind of maintenance on the server itself (such as an OS update, or hardware). Whatever the case, there is a particular method to perform a rolling restart.

일반적인 이유는 Elasticsearch의 버전 업그레이드나 서버 자체의 유지보수(OS 업데이트, H/W 등) 등이다. 어떤 경우이든, 규칙적인 재 시작에는 특정한 방법이 있다.

By nature, Elasticsearch wants your data to be fully replicated and evenly balanced. If you shut down a single node for maintenance, the cluster will immediately recognize the loss of a node and begin rebalancing. This can be irritating if you know the node maintenance is short term, since the rebalancing of very large shards can take some time (think of trying to replicate 1TB—even on fast networks this is nontrivial).

본질적으로, Elasticsearch는 데이터를 완벽하게 복제하고 고르게 균형을 유지하려 한다. 유지보수를 위해, 특정 node를 내리면, cluster는 즉시 node의 손실을 알고, 재 조정을 시작한다. 아주 큰 shard(1 TB를 복제한다고 생각해 보자. 빠른 네트워크라 하더라도 이것은 사소한 문제가 아니다.)의 균형을 맞추는 것은 약간의 시간이 소요될 수 있기 때문에, node 유지보수가 짧은 시간이라도, 거슬릴 수도 있다.

What we want to do is tell Elasticsearch to hold off on rebalancing, because we have more knowledge about the state of the cluster due to external factors. The procedure is as follows:

Elasticsearch에 적용하려는 것은 재조정(rebalancing)을 보류하는 것이다. 왜냐하면, cluster의 상태가 특정한 외부 요인에 의한 것이라는 것을 알고 있기 때문이다. 절차는 다음과 같다.

  1. If possible, stop indexing new data and perform a synced flush. This is not always possible, but will help speed up recovery time. A synced flush request is a “best effort” operation. It will fail if there are any pending indexing operations, but it is safe to reissue the request multiple times if necessary.

    가능하다면, 새로운 data의 색인을 중지하고, synced flush를 수행한다, 이것이 항상 가능한 것은 아니지만, 복구 시간을 더 빠르게 할 것이다. synced flush request는 “best effort” operation이다. pending된 색인 연산이 있다면 실패한다. 그러니, 필요하다면 여러번 request하는 것이 안전하다.

  2. PUT /_flush/synced

  3. Disable shard allocation. This prevents Elasticsearch from rebalancing missing shards until you tell it otherwise. If you know the maintenance window will be short, this is a good idea. You can disable allocation as follows:

    shard 할당을 비활성화한다. 이것은, 다시 하라고 할 때까지, Elasticsearch가 잃어버린 shard를 다시 재 조정하는 것을 막는다. 유시보수 시간이 짧다면, 좋은 생각이다. 다음과 같이 할당을 해제할 수 있다.

    PUT /_cluster/settings
    {
        "transient" : {
            "cluster.routing.allocation.enable" : "none"
        }
    }
  4. Shut down a single node.

    단일 node를 shut down 한다.

  5. Perform a maintenance/upgrade.

    유지보수와 업그레이드를 한다.

  6. Restart the node, and confirm that it joins the cluster.

    node를 재 시작하고, cluster에 조인되는지를 확인한다.

  7. Reenable shard allocation as follows:

    다음과 같이 shard 할당을 다시 활성화한다.

    PUT /_cluster/settings
    {
        "transient" : {
            "cluster.routing.allocation.enable" : "all"
        }
    }

    Shard rebalancing may take some time. Wait until the cluster has returned to status greenbefore continuing.

    shard 재 조정은 약간이 시간이 소요될 수 있다. 계속하기 전에. cluster의 상태가 green 이 될 때까지 기다리자.

  8. Repeat steps 2 through 6 for the rest of your nodes.

    나머지 node에 대해 2 ~ 6까지의 과정을 반복하자.

  9. At this point you are safe to resume indexing (if you had previously stopped), but waiting until the cluster is fully balanced before resuming indexing will help to speed up the process.

    이 시점에서, (색인을 이미 멈추었다면) 색인을 다시 시작해도 안전하지만, 색인을 다시 시작하기 전에, cluster가 완전히 재 조정될 때까지 기다리는 것이, 프로세스를 더 빠르게 하는데 도움이 될 것이다.