server 구성 블록

server 구성 블록 (Server Configuration Block)

이 페이지는 Nomad 에이전트 구성의 server 블록에서 Nomad 에이전트 서버 모드를 구성하는 방법에 대한 참조 정보를 제공해요. 서버 모드를 사용하면 에이전트가 스케줄링 결정에 참여하고, 서비스 디스커버리에 등록하며, 조인 실패를 처리할 수 있어요. 부트스트래핑, 권위 리전, 중복 영역, 데이터 디렉터리, Nomad 클러스터 동작, 클라이언트 하트비트 주기, 스케줄러, 가비지 컬렉션, Raft 로그 저장소 백엔드(BoltDB 또는 WAL), 워크로드 아이덴티티용 OIDC, 리더 플랜 거부를 구성하고, 작업 우선순위, 작업 소스 콘텐츠 크기, 추적 작업 버전도 구성해요.

출처: 문서

본문

server {
  enabled          = true
  bootstrap_expect = 3
  server_join {
    retry_join     = [ "1.1.1.1", "2.2.2.2" ]
    retry_max      = 3
    retry_interval = "15s"
  }
}

server 매개변수 (Parameters)

authoritative_region (string: "") — ACL 정책과 전역 ACL 토큰 같은 전역 구성에 대한 단일 진실의 원천(single source of truth)을 제공하는 권위 리전을 지정해요. 비권위 리전은 권위 리전에서 복제해 미러 역할을 해요. 기본적으로 로컬 리전이 권위 리전으로 가정돼요. authoritative_region을 설정하는 것은 권위 리전에서 ACL이 부트스트랩되었음을 가정해요. ACL 튜토리얼의 Configure for multiple regions를 참고해요.
bootstrap_expect (int: required) — 부트스트랩하기 전에 기다려야 하는 서버 노드 수를 지정해요. 이 값에는 클러스터 크기에 따라 홀수 정수 3 또는 5를 사용하는 것이 가장 일반적이에요. 값 1은 어떤 결함 허용성도 제공하지 않으므로 프로덕션 사용 사례에는 권장되지 않아요.
data_dir (string: "") — 복제된 로그를 포함한 서버별 데이터에 사용할 디렉터리를 지정해요. 이 매개변수가 비어 있으면 Nomad는 최상위 data_dir에 server를 붙여 경로를 생성해요. 예: "/opt/nomad/server". 이 값을 설정할 때도 최상위 data_dir은 설정되어야 해요. 절대 경로여야 해요. 에이전트 프로세스가 시작될 때 디렉터리가 존재하지 않으면 Nomad는 호스트에 디렉터리를 만들어요.
enabled (bool: false) — 이 에이전트가 서버 모드로 실행되어야 하는지 여부를 지정해요. 다른 모든 서버 옵션은 이 값이 설정되어야 해요.
enabled_schedulers (array<string>: []) — 이 서버가 처리하는 하위 스케줄러를 지정해요. 워커 스레드가 처리를 위해 큐에서 빼내는(dequeue) 평가를 제한하는 데 사용해요. Nomad는 빈 기본값을 ["service", "batch", "system", "sysbatch"]로 취급해요.
enable_event_broker (bool: true) — 이 서버가 이벤트 스트림에 대한 이벤트를 생성할지 여부를 지정해요.
encrypt (string: "") — Nomad 서버의 가십 네트워크 트래픽 암호화에 사용할 시크릿 키를 지정해요. 이 키는 RFC4648 "URL and filename safe" base64로 인코딩된 32바이트여야 해요. nomad operator gossip keyring generate 명령어로 적절히 형식화된 키를 생성할 수 있어요. 제공된 키는 데이터 디렉터리에 자동으로 영속화되고 에이전트가 재시작될 때마다 자동으로 로드돼요. 즉 Nomad 서버의 가십 프로토콜을 암호화하려면 이 옵션을 각 에이전트의 초기 시작 시퀀스에 한 번만 제공하면 돼요. 암호화 키로 초기화된 후에 제공되면 제공된 키는 무시되고 경고가 표시돼요. 이 옵션과 클러스터에 대한 그 영향에 대한 자세한 내용은 암호화 문서를 참고해요.
event_buffer_size (int: 100) — 서버가 생성한 이벤트 중 메모리에 보관할 수를 지정해요. 이 값을 늘리면 새 구독자가 처음 구독할 때 더 큰 되돌아보기 창을 가질 수 있어요. 줄이면 이벤트 버퍼에 사용되는 메모리 양이 낮아져요.
node_gc_threshold (string: "24h") — 노드가 가비지 컬렉션되고 시스템에서 제거되기 전에 terminal 상태에 있어야 하는 기간을 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요.
job_gc_interval (string: "5m") — 작업 가비지 컬렉션 사이의 간격을 지정해요. job_gc_threshold 이상 terminal 상태였던 작업만 수집돼요. 간격을 낮추면 더 빈번하지만 더 작은 컬렉션이 수행돼요. 간격을 높이면 덜 빈번하지만 한 번에 더 많은 작업을 수집해요. 태스크 처리량이 많아 죽은 작업이 많이 생기는 경우 이 간격을 줄이는 것이 유용해요. "30s" 또는 "3m" 같은 라벨 접미사로 지정돼요.
job_gc_threshold (string: "4h") — 작업이 가비지 컬렉션 대상이 되기 전에 terminal 상태에 있어야 하는 최소 시간을 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요.
eval_gc_threshold (string: "1h") — 평가가 가비지 컬렉션 대상이 되기 전에 terminal 상태에 있어야 하는 최소 시간을 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요. 배치 작업 평가는 batch_eval_gc_threshold로 제어된다는 점을 참고해 주세요. Nomad는 할당을 평가와 함께 가비지 컬렉션하므로, 이 필드는 할당의 서버 측 가비지 컬렉션도 제어해요. 비terminal 할당이 있는 평가는 가비지 컬렉션될 수 없어요.
batch_eval_gc_threshold (string: "24h") — 배치 작업에서 유래한 평가가 가비지 컬렉션 대상이 되기 전에 terminal 상태에 있어야 하는 최소 시간을 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요. 임계값은 수집에 필요한 조건이지만 충분하지는 않으며, 가장 최근 평가는 임계값을 위반하더라도 가비지 컬렉션되지 않는다는 점을 참고해 주세요. 할당은 평가와 함께 가비지 컬렉션되므로 이 필드는 할당의 서버 측 가비지 컬렉션도 제어해요. 비terminal 할당이 있는 평가는 가비지 컬렉션될 수 없어요.
deployment_gc_threshold (string: "1h") — 배포가 가비지 컬렉션 대상이 되기 전에 terminal 상태에 있어야 하는 최소 시간을 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요.
client_introduction (ClientIntroduction) — Nomad 서버가 새 클라이언트 도입(introduction) 요청을 처리하는 방법에 대한 구성이에요.
csi_volume_claim_gc_interval (string: "5m") — CSI 볼륨 클레임 가비지 컬렉션 사이의 간격을 지정해요.
csi_volume_claim_gc_threshold (string: "1h") — CSI 볼륨이 클레임을 가비지 컬렉션할 대상이 되기 전의 최소 나이를 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요.
csi_plugin_gc_threshold (string: "1h") — CSI 플러그인이 사용되지 않을 때 가비지 컬렉션 대상이 되기 전의 최소 나이를 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요.
acl_token_gc_threshold (string: "1h") — 만료된 ACL 토큰이 가비지 컬렉션 대상이 되기 전의 최소 나이를 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요.
default_scheduler_config (scheduler_configuration: nil) — 클러스터를 부트스트랩할 때 초기 기본 스케줄러 구성을 지정해요. 이 매개변수는 클러스터가 부트스트랩되거나 API 엔드포인트로 값이 업데이트되면 무시돼요. 자세한 내용은 예시 섹션을 참고해요.
heartbeat_grace (string: "10s") — 네트워크·처리 지연과 클럭 스큐를 고려해 클라이언트의 하트비트 TTL 이상으로 주어지는 추가 시간을 지정해요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요. 자세한 내용은 클라이언트 하트비트 섹션을 참고해요.
min_heartbeat_ttl (string: "10s") — 클라이언트 하트비트 사이의 최소 시간을 지정해요. 과도한 업데이트를 방지하기 위한 하한선으로 사용돼요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요. 클라이언트 하트비트 섹션을 참고해요.
failover_heartbeat_ttl (string: "5m") — 서버 리더 선거 후 모든 클라이언트가 하트비트를 보내야 하는 시간이에요. "30s" 또는 "1h" 같은 라벨 접미사로 지정돼요. 클라이언트 하트비트 섹션을 참고해요.
max_heartbeats_per_second (float: 50.0) — 초당 처리되는 하트비트의 최대 목표 속도를 지정해요. 이는 목표 속도를 충족하기 위해 TTL을 늘릴 수 있게 해요. 클라이언트 하트비트 섹션을 참고해요.
non_production (bool: false) — 이 클러스터가 비프로덕션 배포임을 지정해요. 설정되면 이 플래그는 라이선스 인스턴스화와 사용량 보고에 전달돼요. 유효한 비프로덕션 라이선스가 필요해요. 이 구성 옵션은 엔터프라이즈 전용이 아니에요. 하지만 이 플래그를 설정하는 것은 엔터프라이즈 기능에만 영향을 줘요.
non_voting_server (bool: false) — (Enterprise 전용) 이 서버가 읽기 확장성을 제공하기 위해 클러스터의 비투표 멤버로 작동할지 여부를 지정해요.
num_schedulers (int: [num-cores]) — 실행할 병렬 스케줄러 스레드 수를 지정해요. 코어당 최대 하나까지 가능하며, 0으로 설정하면 이 서버가 어떤 스케줄링 결정도 하지 못하게 해요. 기본값은 CPU 코어 수예요.
license_path (string: "") — Nomad Enterprise 라이선스를 로드할 경로를 지정해요. 절대 경로여야 해요(예: /etc/nomad.d/license.hclic). 라이선스는 NOMAD_LICENSE_PATH를 설정하거나 NOMAD_LICENSE를 전체 라이선스 값으로 설정해서도 지정할 수 있어요. license_path가 가장 높은 우선순위이고, 그 다음이 NOMAD_LICENSE, 그다음이 NOMAD_LICENSE_PATH예요. 이 구성은 IBM Passport Advantage Online (PAO)을 통해 얻은 Nomad 라이선스에도 적용돼요.
plan_apply_pipeline (int: 1) — 리더가 플랜을 평가할 때 Raft 쓰기를 기다리는 미결 플랜(plans)을 몇 개나 허용하는지 지정해요. 리더는 낙관적 스냅샷에서 플랜을 평가해요. 스케줄러 워커가 Raft 쓰기에 지연되고 있다면 파이프라인 크기를 늘려 스케줄링 처리량을 높일 수 있지만, 노드에 대한 동시 업데이트로 인해 플랜이 잘못 수락되고 전반적으로 Raft 대기 시간이 늘어날 위험이 있어요. "nomad.plan.outstanding_apply" 메트릭은 파이프라인 사용을 기록하며 최대 plan_apply_pipeline 값일 수 있어요. "nomad.plan.queue_depth" 메트릭은 플랜 애플라이러를 기다리는 스케줄된 플랜 수를 기록해요. 이 두 메트릭이 0에 가까우면 plan_apply_pipeline을 조정해도 처리량이 개선되지 않아요. plan_apply_pipeline을 늘리면 Raft 로그가 기록되기를 비동기로 기다리는 데 보낸 시간을 측정하는 "nomad.nomad.plan.apply" 메트릭이 증가해요. plan_apply_pipeline을 조정한다면 이 메트릭과 리더의 경고 수준 로그 "attempting to apply large raft entry"를 밀접하게 모니터링해 Raft 쓰기가 과도하게 느리지 않은지 확인해야 해요.
plan_rejection_tracker (PlanRejectionTracker) — Nomad 리더가 플랜 거부 이력을 추적하는 데 사용하는 플랜 거부 추적기에 대한 구성이에요.
raft_boltdb — Nomad v2.0.0에서 더 이상 사용되지 않아요. raft_logstore를 사용하세요. Raft의 BoltDB 기반 로그 저장소에 대한 옵션을 구성할 수 있는 중첩 객체예요.
- no_freelist_sync — Nomad v1.12.0에서 더 이상 사용되지 않아요. raft_logstore.boltdb.no_freelist_sync를 사용하세요. 이 값을 true로 설정하면 raft.db 파일 내 BoltDB freelist의 디스크 동기화를 비활성화해요. freelist를 디스크에 동기화하지 않으면 쓰기 작업에 필요한 디스크 I/O가 줄어들지만 서버 시작 시간은 길어져요.
raft_logstore — Raft의 로그 저장소 백엔드에 대한 옵션을 구성할 수 있는 중첩 객체예요. 더 이상 사용되지 않는 raft_boltdb 구성을 대체해요.
- backend (string: "boltdb") — 사용할 Raft 로그 저장소 백엔드를 지정해요. 유효한 값은 "boltdb"(기본값) 또는 "wal"(실험적)이에요. wal 백엔드는 쓰기 중심 워크로드에 더 나은 성능 특성을 제공할 수 있는 HashiCorp Raft WAL 로그 저장소를 사용해요. 백엔드가 선택되고 서버가 시작되면 다른 백엔드로 변경하려면 nomad operator raft migrate-backend 명령어로 마이그레이션해야 해요.
- boltdb — BoltDB 백엔드에 대한 구성 옵션(backend가 "boltdb"일 때 사용)이에요.
  - no_freelist_sync (bool: false) — 이 값을 true로 설정하면 raft.db 파일 내 BoltDB freelist의 디스크 동기화를 비활성화해요. freelist를 디스크에 동기화하지 않으면 쓰기 작업에 필요한 디스크 I/O가 줄어들지만 서버 시작 시간이 늘어날 수 있어요.
- wal — WAL 백엔드에 대한 구성 옵션(backend가 "wal"일 때 사용)이에요.
  - segment_size_mb (int: 64) — 각 WAL 세그먼트 파일의 크기(MB)를 지정해요. 기본값은 64MB예요. 더 큰 세그먼트 크기는 쓰기 중심 워크로드의 성능을 개선할 수 있지만 필요한 최소 디스크 공간을 늘려요.
  - disable_log_cache (bool: false) — 최근 Raft 로그용 인메모리 캐시를 비활성화해요. 캐시를 비활성화하면 메모리 사용이 줄어들 수 있지만 로그 작업의 디스크 읽기가 늘어나요.
- verification — Raft 로그 저장소 검증(디버깅 기능)에 대한 구성 옵션이에요.
  - enabled (bool: false) — 디버깅 목적으로 Raft 로그 저장소의 상세 검증 로깅을 활성화해요. 활성화되면 서버는 BoltDB와 WAL 백엔드 모두에 대해 상세한 Raft 관련 정보를 가진 디버그 수준 로그를 내보내요. 이는 문제 해결을 위한 것이며, Raft 문제를 적극적으로 디버깅하지 않는 한 프로덕션 환경에서는 활성화하면 안 돼요.
  - interval (string: "5m") — 검증이 활성화되었을 때 검증 검사가 수행되는 간격을 지정해요. "30s" 또는 "5m" 같은 라벨 접미사로 지정돼요.
raft_protocol (int: 3) — 다른 Nomad 서버와 통신할 때 사용할 Raft 프로토콜 버전을 지정해요. 이것은 사용 가능한 Autopilot 기능에 영향을 주며, 에이전트가 내부적으로 최신 버전을 알기 때문에 일반적으로 필요하지 않지만 일부 업그레이드 시나리오에서 유용할 수 있어요. Nomad v1.4 이상에서는 3이어야 해요.
raft_multiplier (int: 1) — Nomad 서버가 핵심 Raft 타이밍 매개변수를 확장하는 데 사용하는 정수 배수예요. 이 값을 생략하거나 0으로 설정하면 다음 단락에서 설명하는 기본 타이밍을 사용해요. 더 낮은 값은 타이밍을 조이고 감도를 높이는 데 사용되며, 더 높은 값은 타이밍을 완화하고 감도를 낮춰요. 이 값을 조정하면 Nomad가 리더 장애를 감지하고 리더 선거를 수행하는 데 걸리는 시간에 영향을 주며, 더 나은 성능을 위해 더 많은 네트워크와 CPU 리소스가 필요해요. 허용되는 최대 값은 10이에요. 기본적으로 Nomad는 이 값을 1로 설정한 것과 현재 동등한 최고 성능 타이밍을 사용해요. 타이밍을 늘리면 네트워킹 문제나 리소스 부족 기간 동안 리더 선거가 발생할 가능성이 낮아져요. 리더 선거는 Nomad의 정상 작업을 일시 중지하므로, 느리거나 불안정한 네트워크에서는 새 리더를 선출하기 전에 더 오래 기다리는 것이 유리할 수 있어요. 이 값을 올릴 때의 트레이드오프는 네트워크 파티션 같은 이벤트(서버 충돌) 동안 리더가 손실되면 Nomad가 기본값보다 더 오랜 기간 동안 새 리더를 선출하지 않는다는 것이에요. nomad.nomad.leader.barrier와 nomad.raft.leader.lastContact 메트릭은 리더 선거가 얼마나 자주 발생하는지와 Raft 대기 시간의 좋은 지표예요.
raft_snapshot_threshold (int: "8192") — 노드가 스냅샷을 찍을 수 있기 전에 디스크에 기록되어야 하는 최소 Raft 로그 수를 지정해요. 이는 스냅샷 생성의 빈도와 영향을 줄여요. 노드 시작 중에 Raft는 최신 스냅샷을 복원한 다음 개별 로그를 적용해 노드를 마지막으로 알려진 상태에 맞춰요. 이 값은 핫 구성 리로드로 작동 중에 조정할 수 있어요.
raft_snapshot_interval (string: "120s") — Raft가 스냅샷을 수행해야 하는지 검사하는 사이의 최소 시간을 지정해요. Raft 라이브러리는 전체 클러스터가 한 번에 스냅샷을 수행하지 않도록 이 값과 그 두 배 사이에서 무작위로 시간을 분산해요. 노드는 raft_snapshot_threshold를 초과하면 스냅샷 대상이 돼요. 이 값은 핫 구성 리로드로 작동 중에 조정할 수 있어요.
raft_trailing_logs (int: "10240") — 스냅샷 후 보존되는 로그 수를 지정해요. 이 로그는 Raft가 팔로워에 전체 스냅샷을 보내도록 강제받는 대신 로그를 빠르게 재생할 수 있도록 사용돼요. 이 값은 핫 구성 리로드로 작동 중에 조정할 수 있어요.
redundancy_zone (string: "") — (Enterprise 전용) Autopilot 관리를 위해 이 서버가 속하게 될 중복 영역을 지정해요. 자세한 내용은 Autopilot 가이드를 참고해요.
rejoin_after_leave (bool: false) — Nomad가 이전 leave를 무시하고 시작 시 클러스터에 다시 조인하려고 시도할지 여부를 지정해요. 기본적으로 Nomad는 leave를 영구적인 의도로 취급하고 시작 시 클러스터에 다시 조인하지 않아요. 이 플래그는 이전 상태를 사용해 클러스터에 다시 조인할 수 있게 해요.
root_key_gc_interval (string: "10m") — 암호화 키 메타데이터 가비지 컬렉션 사이의 간격을 지정해요.
root_key_gc_threshold (string: "1h") — root_key_rotation_threshold가 지난 후 암호화 키가 가비지 컬렉션 대상이 되기 전에 존재해야 하는 최소 시간을 지정해요.
root_key_rotation_threshold (string: "720h") — 활성 암호화 키의 수명으로, 이후 다음 가비지 컬렉션 간격에서 자동으로 회전돼요. Nomad는 root_key_rotation_threshold 시간의 절반에 교체 키를 사전 게시해, 워크로드 아이덴티티의 외부 소비자가 키가 사용되기 전에 JWKS URL에서 새 공개 키를 얻을 시간을 갖게 해요.
server_join (server_join: nil) — Nomad 서버가 다른 Nomad 서버에 연결하는 방법을 지정해요. retry_join 필드는 서버 주소를 직접 지정하거나 자동 발견을 위해 go-discover 구문을 사용할 수 있어요. 자세한 내용은 server_join 문서를 참고해요.
start_timeout (string: "30s") — 서버 설정 및 시작 프로세스에 적용되는 타임아웃이에요. 이러한 프로세스들(키링 복호화)은 서버가 정상으로 간주되기 전에 완료되어야 하며, 완료되기 전에 타임아웃에 도달하면 서버가 종료돼요. 이것이 없으면 서버가 이를 기다리며 무기한 중단될 수 있어요.
upgrade_version (string: "") — Autopilot에서 커스텀 업그레이드가 활성화되었을 때 Nomad 버전 대신 사용할 X.Y.Z 형식의 커스텀 버전이에요. 자세한 내용은 Autopilot 가이드를 참고해요.
search (search: nil) — Nomad 검색 API에 대한 구성 매개변수를 지정해요.
job_max_priority (int: 100) — 작업에 할당할 수 있는 최대 우선순위를 지정해요. 유효한 값은 100과 32766 사이여야 해요.
job_default_priority (int: 50) — 작업에 할당되는 기본 우선순위를 지정해요. 유효한 값은 50과 job_max_priority 사이여야 해요.
job_max_count (int: 50000) — 태스크 그룹 count 필드의 합으로 나타낸 작업의 최대 할당 수를 지정해요. type이 system인 작업은 이 값을 무시해요. 디스패치된 배치 작업이나 주기적 작업의 자식 작업은 부모 작업과 별도로 집계돼요. 이 값은 음수가 아니어야 해요. 0으로 설정하면 아무 제한도 적용되지 않아요. 이 값은 작업이 제출되거나 확장될 때 적용되며, 값을 업데이트해도 기존 작업에는 영향이 없어요.
job_max_source_size (string: "1M") — 작업 등록 시 연관된 작업 소스 콘텐츠의 크기 제한을 지정해요. 참고로 이것은 작업의 실제 크기 제한이 아니에요. 제한을 초과하면 원본 소스가 단순히 버려지고 작업 API에서 오류가 반환되지 않아요.
job_tracked_versions (int: 6) — 보관되는 이전 작업 버전의 수를 지정해요.
oidc_issuer (string: "") — 워크로드 아이덴티티 JWT에 대한 Issuer URL을 지정해요. 예: "https://nomad.example.com". 설정되면 제3자가 Nomad의 OIDC 구성을 발견할 수 있도록 /.well-known/openid-configuration HTTP 엔드포인트가 활성화돼요. 한 번 설정되면 oidc_issuer는 이전 발급자 클레임이 있는 워크로드 아이덴티티를 무효화하지 않고는 변경할 수 없어요. 이러한 이유로 oidc_issuer를 Nomad HTTP API 앞의 프록시로 설정해 잠재적으로 일시적인 Nomad 서버 IP 대신 안정적인 DNS 이름을 사용할 수 있도록 하는 것이 좋아요.

더 이상 사용되지 않는 매개변수 (Deprecated Parameters)

retry_join (array<string>: []) — 첫 번째 시도가 실패하면 조인을 재시도할 서버 주소 목록을 지정해요. start_join과 유사하지만 초기 조인 시도가 실패한 경우에만 호출돼요. 주소 목록은 하나가 성공할 때까지 지정된 순서로 시도돼요. 하나가 성공한 후에는 더 이상 주소에 접촉하지 않아요. 이는 주소가 결국 사용 가능해질 것임을 알 때 유용해요. 배열과 함께 retry_join을 start_join의 대체로 사용하고, 두 옵션을 함께 사용하지 마세요. 문자열의 형식에 대한 자세한 내용은 server_join 섹션을 참고해요. 이 필드는 server_join 블록을 위해 더 이상 사용되지 않아요.
retry_interval (string: "30s") — 재시도 조인 시도 사이에 기다리는 시간을 지정해요. 이 필드는 server_join 블록을 위해 더 이상 사용되지 않아요.
retry_max (int: 0) — 반환 코드 1로 종료하기 전에 만들 최대 조인 시도 횟수를 지정해요. 기본적으로 0으로 설정되며 이는 무한 재시도로 해석돼요. 이 필드는 server_join 블록을 위해 더 이상 사용되지 않아요.
start_join (array<string>: []) — 시작 시 조인할 서버 주소 목록을 지정해요. Nomad가 지정된 주소 중 어느 것과도 조인할 수 없으면 에이전트 시작이 실패해요. 문자열의 형식에 대한 자세한 내용은 서버 주소 형식 섹션을 참고해요. 이 필드는 server_join 블록을 위해 더 이상 사용되지 않아요.

client_introduction 매개변수 (Parameters)

client_introduction 블록은 Nomad 서버가 새 클라이언트용 도입 토큰을 생성하는 방법과 새 클라이언트가 서버에 등록하려고 할 때 적용할 강제(내용)을 제어해요.

enforcement (string: "warn") — 서버가 새 클라이언트 등록 요청을 처리하는 방법을 지정해요. 유효한 옵션은 none, warn, strict예요.
- none : 서버가 어떤 클라이언트 등록 동작도 강제하지 않아요.
- warn : 클라이언트가 도입 토큰 없이 등록을 시도하면 서버가 경고 메시지를 기록하고 텔레메트리 메트릭을 내보내요. 하지만 등록은 계속 진행되도록 허용해요.
- strict : 서버가 유효한 도입 토큰을 포함하지 않는 모든 클라이언트 등록 시도를 거부해요. 서버는 또한 경고 메시지를 기록하고 텔레메트리 메트릭을 내보내요.
default_identity_ttl (string: "5m") — 호출자가 TTL을 지정하지 않을 때 생성된 클라이언트 도입 토큰에 할당되는 기본 TTL이에요. 이 값을 "30s" 또는 "1h" 같은 라벨 접미사로 지정해요. max_identity_ttl보다 작아야 해요.
max_identity_ttl (string: "30m") — 호출자가 클라이언트 도입 토큰을 생성할 때 요청할 수 있는 최대 TTL이에요. 이 값을 "30s" 또는 "1h" 같은 라벨 접미사로 지정해요. default_identity_ttl보다 커야 해요.

내보내지는 클라이언트 도입 메트릭에 대한 자세한 내용은 Monitor Nomad 가이드의 Client introduction 섹션을 참고해요.

plan_rejection_tracker 매개변수 (Parameters)

리더 플랜 거부 추적기는 예상치 못한 문제가 있을 수 있는 클라이언트에 항상 스케줄링되어 평가가 고착되는 것을 방지하도록 조정할 수 있어요. 자세한 내용은 Monitoring Nomad를 참고해요.

enabled (bool: false) — 플랜 거부를 추적할지 여부를 지정해요.
node_threshold (int: 100) — node_window 내 노드에 대한 플랜 거부 수로, 클라이언트를 부적격(ineligible)으로 설정하도록 촉발해요.
node_window (string: "5m") — 노드에 대한 플랜 거부를 고려해야 하는 시간 창이에요.

너무 많은 오탐(문제를 보이지 않는데도 클라이언트가 부적격으로 표시됨)을 관찰한다면 node_threshold를 늘리고 싶을 수 있어요.

또는 같은 node_id에 대한 플랜 거부로 인해 작업이 스케줄링되지 않는데 클라이언트가 부적격으로 설정되지 않는 것을 발견하면 node_window를 늘려 더 많은 이력 거부가 고려되도록 시도할 수 있어요.

server 예시 (Examples)

일반 설정 (Common Setup)

이 예시는 일반적인 Nomad 에이전트 서버 구성 블록을 보여줘요. 두 IP 주소는 DNS일 수도 있으며, 클러스터의 다른 Nomad 서버를 가리켜야 해요.

server {
  enabled          = true
  bootstrap_expect = 3

  server_join {
    retry_join     = [ "1.1.1.1", "2.2.2.2" ]
    retry_max      = 3
    retry_interval = "15s"
  }
}

데이터 디렉터리 구성 (Configuring Data Directory)

이 예시는 서버 데이터에 대한 커스텀 데이터 디렉터리를 구성하는 방법을 보여줘요.

server {
  data_dir = "/opt/nomad/server"
}

자동 부트스트래핑 (Automatic Bootstrapping)

Consul이 구성되어 있으면 Nomad 서버는 자동으로 부트스트랩할 수 있어요. 더 자세한 설명은 자동 Nomad 부트스트래핑 문서를 참고해요.

스케줄러 제한 (Restricting Schedulers)

이 예시는 활성화되는 스케줄러와 스케줄링 결정에 참여할 때 활용할 최대 코어 수를 제한하는 방법을 보여줘요.

server {
  enabled            = true
  enabled_schedulers = ["batch", "service"]
  num_schedulers     = 7
}

Raft 로그 저장소 구성 (Configuring Raft Log Store)

이 예시는 쓰기 성능 개선을 위해 freelist 동기화를 비활성화한 BoltDB 백엔드(기본값)로 Raft 로그 저장소를 구성하는 방법을 보여줘요.

server {
  enabled = true

  raft_logstore {
    backend = "boltdb"
    boltdb {
      no_freelist_sync = true
    }
  }
}

이 예시는 쓰기 중심 워크로드에서 쓰기 성능 개선을 위해 실험적 WAL 백엔드를 구성하는 방법을 보여줘요.

server {
  enabled = true

  raft_logstore {
    backend = "wal"
    wal {
      segment_size_mb = 64
    }
  }
}

경고 — WAL 백엔드는 실험적이에요. BoltDB에서 WAL 백엔드로 마이그레이션하려면 nomad operator raft migrate-backend 명령어가 필요해요. 서버 상태를 지워 피어에서 스냅샷을 로드하지 않으면 WAL에서 BoltDB로 마이그레이션하는 것은 불가능해요.

이 예시는 디버깅 목적으로 Raft 로그 저장소 검증을 활성화하는 방법을 보여줘요.

server {
  enabled = true

  raft_logstore {
    verification {
      enabled  = true
      interval = "60s"
    }
  }
}

참고 — Raft 로그 저장소 검증은 상세한 디버그 수준 로그를 생성하므로 Raft 문제를 적극적으로 디버깅할 때만 활성화해야 해요.

커스텀 스케줄러 구성으로 부트스트래핑 (Bootstrapping with a Custom Scheduler Config)

클러스터를 부트스트랩하는 동안 default_scheduler_config 블록을 사용해 클러스터를 SchedulerConfig로 초기화할 수 있어요. 스케줄러 구성은 어떤 스케줄링 알고리즘(spread 스케줄링 또는 binpacking)이 구성되는지와 어떤 작업 유형이 선점 대상인지 결정해요.

경고 — 클러스터가 부트스트랩되면 update scheduler configuration API를 사용해 이 구성을 해야 해요. 이 옵션은 부트스트랩 중에만 참조돼요.

구조는 캐노니컬 문서를 위해 참조해야 하는 Update Scheduler Config API 엔드포인트와 일치해요. 하지만 속성 이름은 camel case가 아닌 snake case 표현을 사용해 HCL 구문에 맞춰야 해요.

이 예시는 spread 스케줄링을 구성하고 모든 작업 유형 스케줄러에 대해 선점을 활성화하는 방법을 보여줘요.

server {
  default_scheduler_config {
    scheduler_algorithm             = "spread"
    memory_oversubscription_enabled = true
    reject_job_registration         = false
    pause_eval_broker               = false

    preemption_config {
      batch_scheduler_enabled    = true
      system_scheduler_enabled   = true
      service_scheduler_enabled  = true
      sysbatch_scheduler_enabled = true
    }
  }
}

클라이언트 하트비트 (Client Heartbeats)

이것은 고급 주제예요. 1,000개 이상의 노드가 있거나 네트워크나 노드가 불안정한 클러스터(예: 일부 엣지 배포)에 가장 유용해요.

Nomad 클라이언트는 정상 작동 중인지 확인하기 위해 주기적으로 Nomad 서버에 하트비트를 보내요. 지정된 시간 내에 하트비트를 보내지 않는 Nomad 클라이언트는 다운된 것으로 간주되고, 그 할당은 손실 또는 연결 끊김(disconnect.lost_after가 설정된 경우)으로 표시되어 교체돼요.

다양한 하트비트 관련 매개변수를 사용하면 다음 트레이드오프를 조정할 수 있어요.

하트비트 주기가 길수록 Nomad가 다운된 클라이언트의 워크로드를 교체하는 데 걸리는 시간이 길어져요.
하트비트 주기가 짧을수록 일시적인 네트워크 문제, 리더 선거, 기타 일시적 문제로 인해 완벽하게 기능하는 클라이언트와 그 워크로드가 다운된 것으로 표시되고 교체될 가능성이 높아져요.

Nomad 클라이언트는 어떤 서버에도 연결할 수 있지만, 모든 하트비트는 처리를 위해 리더로 전달돼요. 이 하트비트 처리는 리소스를 소비하므로, Nomad는 클러스터 크기에 따라 클라이언트가 하트비트를 보내는 속도를 조정해요. 목표는 클러스터 크기와 관계없이 하트비트 처리의 리소스 비용을 일정하게 유지하려는 것이에요.

클라이언트가 하트비트를 보내야 하는 빈도를 결정하는 기본 공식은 다음과 같아요.

<number of Clients> / <max_heartbeats_per_second>

다른 요소들이 이 기본 TTL을 수정해요.

정확히 같은 시간에 많은 수의 클라이언트가 하트비트를 시도하는 선더링 허드(thundering herd) 문제를 방지하기 위해 기본 TTL에 최대 2배까지의 무작위 요소가 추가돼요.
min_heartbeat_ttl은 소규모 클러스터가 과도한 하트비트를 보내는 것을 방지하기 위한 하한으로 사용돼요.
heartbeat_grace는 리더가 기본 하트비트 이상으로 기다릴 추가 시간이에요.
리더 선거 후 모든 클라이언트에는 성공적으로 하트비트를 보낼 수 있는 failover_heartbeat_ttl까지의 시간이 주어져요. 이는 클라이언트가 직접 연결했던 리더가 충돌한 경우 기능하는 서버를 발견할 시간을 주기 위한 것이에요.

예를 들어 하트비트 매개변수의 기본값이 주어지면, 다른 크기의 클러스터는 하트비트에 대해 다음 TTL을 사용해요. 서버 TTL은 클라이언트에게 주어진 TTL에 heartbeat_grace 매개변수를 단순히 더한 것임을 참고해 주세요.

클라이언트 수 (Clients)	클라이언트 TTL (Client TTL)	서버 TTL (Server TTL)	선거 후 안전 (Safe after elections)
10	10s - 20s	20s - 30s	예
100	10s - 20s	20s - 30s	예
1000	20s - 40s	30s - 50s	예
5000	100s - 200s	110s - 210s	예
10000	200s - 400s	210s - 410s	아니요

크기와 관계없이 모든 클라이언트는 리더 선거 후 failover_heartbeat_ttl의 서버 TTL을 가져요. 살아있는 클라이언트가 다운으로 표시되는 것을 방지하려면 항상 클러스터 크기의 최대 클라이언트 TTL보다 커야 해요.

5,000개를 넘는 클라이언트의 클러스터에서는 다음 공식으로 failover_heartbeat_ttl을 늘려야 해요.

(2 * (<number of Clients> / <max_heartbeats_per_second>)) + (10 * <min_heartbeat_ttl>)

# For example with 6000 Clients:
(2 * (6000 / 50)) + (10 * 10) = 340s (5m40s)

이렇게 하면 최대 간격 후에 하트비트를 보내라고 지시받았더라도 클라이언트가 페일오버할 추가 시간을 갖게 돼요.

실제 사용 값은 시스템이 충돌한 클라이언트를 인지하는 데 있어 얼마나 많은 허용 오차를 갖는지 고려해야 해요. 예를 들어 failover_heartbeat_ttl이 30분이면 가장 큰 클러스터의 가장 느린 클라이언트도 선거 후 하트비트를 보낼 충분한 시간을 가질 수 있어요. 하지만 선거가 클라이언트에 영향을 주는 데이터센터 전체 장애 때문이라면, Nomad가 그들이 다운되었음을 인지하고 교체하기까지 30분이 걸릴 거예요.

server 구성 블록