워크로드 마이그레이션

워크로드 마이그레이션 (Migrate workloads)

워크로드를 마이그레이션하고 노드를 폐기하는 것은 다양한 이유(서버 유지보수, 운영체제 업그레이드 등)로 인한 클러스터 운영의 정상적인 부분이에요. Nomad는 드레이닝 중인 노드에서 실행 중인 잡을 마이그레이션하는 방법을 제어하는 여러 매개변수를 제공해요.

출처: 문서

본문

잡이 마이그레이션되는 방식 정의 (Define how your job is migrated)

Nomad 0.8에서 잡에 migrate 스탠자가 추가되어 드레이닝 중인 노드에서 잡의 할당을 마이그레이션하는 방법을 제어할 수 있게 됐어요. 아래는 웹 서비스를 실행하고 Consul 헬스 체크가 있는 예시 잡이에요:

job "webapp" {
  datacenters = ["dc1"]

  migrate {
    max_parallel = 2
    health_check = "checks"
    min_healthy_time = "15s"
    healthy_deadline = "5m"
  }

  group "webapp" {
    count = 9

    network {
      port "http" {
        to = 5678
      }
    }

    task "webapp" {
      driver = "docker"
      config {
        image = "hashicorp/http-echo:0.2.3"
        args  = ["-text", "ok"]
        ports = ["http"]
      }

      service {
        name = "webapp"
        port = "http"
        check {
          name = "http-ok"
          type = "http"
          path = "/"
          interval = "10s"
          timeout  = "2s"
        }
      }
    }
  }
}

위의 migrate 스탠자는 노드 드레인 중에 한 번에 2개의 할당만 중지해 마이그레이션하도록 보장해요. 이 잡에 대한 할당을 실행하는 여러 노드가 동시에 드레이닝 중이더라도 한 번에 2개의 할당만 마이그레이션돼요.

잡이 실행되면 여러 노드에 배치될 수 있어요. 다음 예시에서 9개의 webapp 할당이 2개 노드에 걸쳐 분산돼 있어요:

$ nomad run webapp.nomad.hcl
==> Monitoring evaluation "5129bc74"
    Evaluation triggered by job "webapp"
    Allocation "5b4d6db5" created: node "46f1c6c4", group "webapp"
    Allocation "670a715f" created: node "f7476465", group "webapp"
    Allocation "78b6b393" created: node "46f1c6c4", group "webapp"
    Allocation "85743ff5" created: node "f7476465", group "webapp"
    Allocation "edf71a5d" created: node "f7476465", group "webapp"
    Allocation "56f770c0" created: node "46f1c6c4", group "webapp"
    Allocation "9a51a484" created: node "46f1c6c4", group "webapp"
    Allocation "f6f6e64c" created: node "f7476465", group "webapp"
    Allocation "fefe81d0" created: node "f7476465", group "webapp"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "5129bc74" finished with status "complete"

그 노드 중 하나를 폐기해야 한다면(아마 하드웨어 문제로), 운영자는 노드 드레인을 실행해 할당을 마이그레이션할 거예요:

$ nomad node drain -enable -yes 46f1
2018-04-11T23:41:56Z: Ctrl-C to stop monitoring: will not cancel the node drain
2018-04-11T23:41:56Z: Node "46f1c6c4-a0e5-21f6-fd5c-d76c3d84e806" drain strategy set
2018-04-11T23:41:57Z: Alloc "5b4d6db5-3fcb-eb7d-0415-23eefcd78b6a" marked for migration
2018-04-11T23:41:57Z: Alloc "56f770c0-f8aa-4565-086d-01faa977f82d" marked for migration
2018-04-11T23:41:57Z: Alloc "56f770c0-f8aa-4565-086d-01faa977f82d" draining
2018-04-11T23:41:57Z: Alloc "5b4d6db5-3fcb-eb7d-0415-23eefcd78b6a" draining
2018-04-11T23:42:03Z: Alloc "56f770c0-f8aa-4565-086d-01faa977f82d" status running -> complete
2018-04-11T23:42:03Z: Alloc "5b4d6db5-3fcb-eb7d-0415-23eefcd78b6a" status running -> complete
2018-04-11T23:42:22Z: Alloc "78b6b393-d29c-d8f8-e8e8-28931c0013ee" marked for migration
2018-04-11T23:42:22Z: Alloc "78b6b393-d29c-d8f8-e8e8-28931c0013ee" draining
2018-04-11T23:42:27Z: Alloc "78b6b393-d29c-d8f8-e8e8-28931c0013ee" status running -> complete
2018-04-11T23:42:29Z: Alloc "9a51a484-8c43-aa4e-d60a-46cfd1450780" marked for migration
2018-04-11T23:42:29Z: Alloc "9a51a484-8c43-aa4e-d60a-46cfd1450780" draining
2018-04-11T23:42:29Z: Node "46f1c6c4-a0e5-21f6-fd5c-d76c3d84e806" has marked all allocations for migration
2018-04-11T23:42:34Z: Alloc "9a51a484-8c43-aa4e-d60a-46cfd1450780" status running -> complete
2018-04-11T23:42:34Z: All allocations on node "46f1c6c4-a0e5-21f6-fd5c-d76c3d84e806" have stopped.

출력에서 주목할 몇 가지 중요한 이벤트가 있어요. 먼저 처음에는 두 할당만 마이그레이션돼요:

2018-04-11T23:41:57Z: Alloc "5b4d6db5-3fcb-eb7d-0415-23eefcd78b6a" marked for migration
2018-04-11T23:41:57Z: Alloc "56f770c0-f8aa-4565-086d-01faa977f82d" marked for migration

이것은 잡 스펙의 max_parallel = 2 때문이에요. 드레이닝 중인 노드의 다음 할당은 마이그레이션되기를 기다려요:

2018-04-11T23:42:22Z: Alloc "78b6b393-d29c-d8f8-e8e8-28931c0013ee" marked for migration

이것은 초기 마이그레이션 후 25초 후에 발생한다는 점에 유의하세요. 25초 지연은 교체 할당이 healthy가 되는 데 10초가 걸렸고 그 다음 min_healthy_time = "15s" 때문에 노드 드레인이 추가로 15초를 기다렸기 때문이에요. 그 시간 안에 교체 할당이 실패했다면 교체가 성공적으로 만들어질 때까지 노드 드레인이 계속되지 않았을 거예요.

드레이닝된 노드의 스케줄링 적격성 확인 (Verify drained node's scheduling eligibility)

이제 예시 드레인이 끝났으니 드레이닝된 노드의 상태를 검사할 수 있어요:

$ nomad node status
ID        DC   Name     Class   Drain  Eligibility  Status
f7476465  dc1  nomad-1  <none>  false  eligible     ready
96b52ad8  dc1  nomad-2  <none>  false  eligible     ready
46f1c6c4  dc1  nomad-3  <none>  false  ineligible   ready

노드 46f1c6c4의 Drain = false이지만 Eligibility = ineligible인 것에 주목하세요. 노드 스케줄링 적격성은 Nomad 0.8의 새 필드예요. 노드가 스케줄링에 부적격하면 스케줄러는 새 배치를 위해 그 노드를 고려하지 않아요.

드레이닝 중에는 노드가 항상 스케줄링에 부적격해요. 드레이닝이 완료되면 새로 드레이닝된 노드가 다시 채워지는 것을 방지하기 위해 계속 부적격으로 남아요.

그러나 기본적으로 -disable 옵션으로 드레인을 취소하면 노드가 스케줄링에 적격하도록 재설정돼요. 드레인을 취소하면서 노드의 부적격 상태를 유지하려면 -keep-ineligible 옵션을 사용하세요.

스케줄링 적격성은 nomad node eligibility 명령으로 노드 드레인과 독립적으로 전환할 수 있어요:

$ nomad node eligibility -disable 46f1
Node "46f1c6c4-a0e5-21f6-fd5c-d76c3d84e806" scheduling eligibility set: ineligible for scheduling

드레인 deadline으로 완료 강제 (Use a drain deadline to force completion)

때로는 드레인이 정상적으로 진행·완료되지 못할 수 있어요. 이것은 드레이닝된 할당을 교체할 충분한 용량이 클러스터에 없거나 교체 할당이 제때 성공적으로 시작하지 못해서일 수 있어요.

운영자는 노드 드레인을 활성화할 때 deadline을 지정해 드레인이 끝나지 않는 것을 방지할 수 있어요. deadline에 도달하면 migrate 스탠자 매개변수와 무관하게 노드의 모든 남은 할당이 중지돼요.

기본 deadline은 1시간이며 -deadline 커맨드 라인 옵션으로 변경할 수 있어요. -force 옵션은 즉시 deadline이에요. 모든 할당이 즉시 중지돼요. -no-deadline 옵션은 deadline을 비활성화해 드레인이 무기한 계속될 수 있게 해요.

다른 모든 드레인 매개변수처럼 드레인의 deadline은 업데이트된 값으로 후속 nomad node drain ... 호출을 하여 업데이트할 수 있어요.

batch 및 system 잡을 위한 드레인 전략 계획 (Plan a drain strategy for batch and system jobs)

지금까지는 service 잡에서 드레이닝이 어떻게 동작하는지만 봤어요. batch와 system 잡은 노드 드레인 중 서로 다른 동작을 해요.

batch 잡 드레이닝 (Drain batch jobs)

노드 드레인은 드레인의 deadline에 도달한 후에만 batch 잡을 마이그레이션해요. deadline이 없는 노드 드레인의 경우 노드의 모든 batch 잡이 완료(또는 실패)될 때까지 드레인이 완료되지 않아요.

이 동작의 목표는 batch 잡이 일찍 종료되도록 강제함으로써 잡이 만든 진행 상황을 잃는 것을 피하는 것이에요.

system 잡 계속 실행 (Keep system jobs running)

노드 드레인은 다른 모든 할당이 종료된 후에만 system 잡을 중지해요. 이렇게 하면 로그 전송 데몬이나 메트릭 수집기를 system 잡으로 실행 중인 노드가 다른 할당이 실행 중인 동안 계속 실행될 수 있어요.

-ignore-system 옵션은 다른 모든 할당이 종료된 후에도 system 잡을 계속 실행 되게 둬요. system 잡이 Nomad 또는 노드 자체를 모니터링하는 데 사용될 때 유용해요.

여러 노드 드레이닝 (Drain multiple nodes)

한 번에 전체 노드 클래스를 폐기하는 것은 일반적인 작업이에요. Nomad 0.7 이전에는 이것이 문제가 되는 작업이었어요. 드레이닝을 시작하는 첫 번째 노드가 모든 할당을 곧 드레이닝될 다음 노드로 마이그레이션할 수 있었기 때문이에요. 병적인 경우 이는 드레이닝될 각 노드에서 반복되어 할당이 반복적으로 재스케줄링될 수 있어요.

Nomad 0.8부터 운영자는 nomad node eligibility 명령을 사용해 노드를 드레이닝하기 전에 스케줄링에 부적격으로 표시해 이 변동을 피할 수 있어요.

-disable 플래그로 노드를 스케줄링에 부적격으로 표시하세요.

$ nomad node eligibility -disable 46f1
Node "46f1c6c4-a0e5-21f6-fd5c-d76c3d84e806" scheduling eligibility set: ineligible for scheduling

$ nomad node eligibility -disable 96b5
Node "96b52ad8-e9ad-1084-c14f-0e11f10772e4" scheduling eligibility set: ineligible for scheduling

노드 상태를 확인해 적격성을 확인하세요.

$ nomad node status
ID        DC   Name     Class   Drain  Eligibility  Status
f7476465  dc1  nomad-1  <none>  false  eligible     ready
46f1c6c4  dc1  nomad-2  <none>  false  ineligible   ready
96b52ad8  dc1  nomad-3  <none>  false  ineligible   ready

이제 nomad-2와 nomad-3이 모두 스케줄링에 부적격이므로, 곧 드레이닝될 노드에 할당을 배치할 위험 없이 드레이닝할 수 있어요.

스케줄링 적격성 전환은 드레이닝과 완전히 독립적으로 수행할 수 있어요. 예를 들어 운영자가 새 할당이 스케줄링되고 노드 상태가 바뀌는 위험 없이 노드에서 현재 실행 중인 할당을 검사하려 할 때요.

현재 노드를 스케줄링에 부적격으로 만드세요.

$ nomad node eligibility -self -disable
Node "96b52ad8-e9ad-1084-c14f-0e11f10772e4" scheduling eligibility set: ineligible for scheduling

-enable 플래그로 현재 노드를 다시 스케줄링에 적격하게 만드세요.

$ nomad node eligibility -self -enable
Node "96b52ad8-e9ad-1084-c14f-0e11f10772e4" scheduling eligibility set: eligible for scheduling

예시: 데이터센터 마이그레이션 (Example: migrating datacenters)

여러 노드를 드레이닝하는 더 완전한 예시는 이전 데이터센터(dc1)에서 새 데이터센터(dc2)로 마이그레이션할 때예요:

$ nomad node status -allocs
ID        DC   Name     Class   Drain  Eligibility  Status  Running Allocs
f7476465  dc1  nomad-1  <none>  false  eligible     ready   4
46f1c6c4  dc1  nomad-2  <none>  false  eligible     ready   1
96b52ad8  dc1  nomad-3  <none>  false  eligible     ready   4
168bdd03  dc2  nomad-4  <none>  false  eligible     ready   0
9ccb3306  dc2  nomad-5  <none>  false  eligible     ready   0
7a7f9a37  dc2  nomad-6  <none>  false  eligible     ready   0

마이그레이션 전에 dc1의 모든 잡이 datacenters = ["dc1", "dc2"]를 갖도록 보장하세요. 그런 다음 드레이닝하기 전에 dc1의 모든 노드를 스케줄링에 부적격으로 표시하세요.

셸 스크립팅은 한 번에 여러 노드를 조작하는 데 자동화를 도울 수 있어요.

$ nomad node status | awk '{ print $2 " " $1 }' | grep ^dc1 | awk '{ system("nomad node eligibility -disable "$2) }'
Node "f7476465-4d6e-c0de-26d0-e383c49be941" scheduling eligibility set: ineligible for scheduling
Node "46f1c6c4-a0e5-21f6-fd5c-d76c3d84e806" scheduling eligibility set: ineligible for scheduling
Node "96b52ad8-e9ad-1084-c14f-0e11f10772e4" scheduling eligibility set: ineligible for scheduling

상태를 확인해 부적격임을 확인하세요.

$ nomad node status
ID        DC   Name     Class   Drain  Eligibility  Status
f7476465  dc1  nomad-1  <none>  false  ineligible   ready
46f1c6c4  dc1  nomad-2  <none>  false  ineligible   ready
96b52ad8  dc1  nomad-3  <none>  false  ineligible   ready
168bdd03  dc2  nomad-4  <none>  false  eligible     ready
9ccb3306  dc2  nomad-5  <none>  false  eligible     ready
7a7f9a37  dc2  nomad-6  <none>  false  eligible     ready

그런 다음 dc1의 각 노드를 드레이닝하세요.

$ nomad node drain -enable -yes -detach f7476465
Node "f7476465-4d6e-c0de-26d0-e383c49be941" drain strategy set

-enable -yes -detach 플래그와 함께 각 노드의 ID를 전달해 드레인을 시작하세요.

$ nomad node drain -enable -yes -detach 46f1c6c4
Node "46f1c6c4-a0e5-21f6-fd5c-d76c3d84e806" drain strategy set

이 예시에서는 드레이닝 중인 마지막 노드만 모니터링해요. nomad node status -allocs를 보는 것도 드레인 상태를 모니터링하는 좋은 방법이에요.

$ nomad node drain -enable -yes 9ccb3306
2018-04-12T22:08:00Z: Ctrl-C to stop monitoring: will not cancel the node drain
2018-04-12T22:08:00Z: Node "96b52ad8-e9ad-1084-c14f-0e11f10772e4" drain strategy set
2018-04-12T22:08:15Z: Alloc "392ee2ec-d517-c170-e7b1-d93b2d44642c" marked for migration
2018-04-12T22:08:16Z: Alloc "392ee2ec-d517-c170-e7b1-d93b2d44642c" draining
2018-04-12T22:08:17Z: Alloc "6a833b3b-c062-1f5e-8dc2-8b6af18a5b94" marked for migration
2018-04-12T22:08:17Z: Alloc "6a833b3b-c062-1f5e-8dc2-8b6af18a5b94" draining
2018-04-12T22:08:21Z: Alloc "392ee2ec-d517-c170-e7b1-d93b2d44642c" status running -> complete
2018-04-12T22:08:22Z: Alloc "6a833b3b-c062-1f5e-8dc2-8b6af18a5b94" status running -> complete
2018-04-12T22:09:08Z: Alloc "d572d7a3-024b-fcb7-128b-1932a49c8d79" marked for migration
2018-04-12T22:09:09Z: Alloc "d572d7a3-024b-fcb7-128b-1932a49c8d79" draining
2018-04-12T22:09:14Z: Alloc "d572d7a3-024b-fcb7-128b-1932a49c8d79" status running -> complete
2018-04-12T22:09:33Z: Alloc "f3f24277-4435-56a3-7ee1-1b1eff5e3aa1" marked for migration
2018-04-12T22:09:33Z: Alloc "f3f24277-4435-56a3-7ee1-1b1eff5e3aa1" draining
2018-04-12T22:09:33Z: Node "96b52ad8-e9ad-1084-c14f-0e11f10772e4" has marked all allocations for migration
2018-04-12T22:09:39Z: Alloc "f3f24277-4435-56a3-7ee1-1b1eff5e3aa1" status running -> complete
2018-04-12T22:09:39Z: All allocations on node "96b52ad8-e9ad-1084-c14f-0e11f10772e4" have stopped.

노드 96b52ad8가 드레이닝을 시작하고 첫 할당이 마이그레이션되기까지 15초 지연이 있었다는 점에 유의하세요. 지연은 같은 잡의 2개 할당이 이미 다른 노드에서 마이그레이션되고 있었기 때문이에요. 잡의 9개 할당 중 적어도 8개가 실행되면 또 다른 할당이 드레이닝을 시작할 수 있었어요.

마지막 노드 드레인 명령은 drain complete 메시지 후 6초가 지나서야 종료됐는데, 커맨드 라인 도구가 노드의 모든 할당이 중지될 때까지 블로킹하기 때문이에요. 이렇게 하면 운영자가 드레인 명령이 종료되면 노드 종료를 스크립트로 작성하고 모든 서비스가 이미 종료되었음을 알 수 있어요.

더 알아보기 (Learn more)

• Migrate 블록
• nomad node drain 명령
• nomad node eligibility 명령