Raft 구성 매개변수

Raft 구성 매개변수 (Raft Configuration Parameters)

이 문서는 Consul 에이전트 구성 파일의 Raft 매개변수에 대한 참조 정보를 제공해요. raft_logstore, raft_protocol, raft_snapshot_threshold 등의 설정을 설명할게요.

출처: 문서

본문

이 페이지는 Consul 에이전트 구성 파일의 Raft 매개변수에 대한 참조 정보를 제공합니다.

Raft 매개변수 (Raft parameters)

  • raft_logstore - 쓰기 중 로그와 중요한 Raft 상태를 디스크에 영구 보존하는 데 사용되는 Raft의 LogStore 구성 요소에 대한 옵션을 구성할 수 있는 중첩 객체입니다. 이것은 Consul v1.15.0에서 추가되었습니다.
    • backend - 로그를 영구 보존하는 데 사용할 저장 엔진을 지정합니다. 유효한 옵션은 boltdb 또는 wal입니다. 기본값은 wal입니다. 0.21 이전의 Consul 버전에서는 기본값이 boltdb였습니다. 자세한 내용은 WAL LogStore 백엔드를 참조하세요.
    • disable_log_cache - 최근 로그에 대한 인메모리 캐시를 비활성화합니다. 캐시가 비활성화되었을 때 측정된 상당한 개선이 없으므로 성능 테스트 목적으로 사용할 것을 권장합니다. 인메모리 로그 캐시는 이론적으로 최근 로그에 대한 디스크 읽기를 방지하지만, 최근 로그는 OS 페이지 캐시에도 저장되므로 boltdb나 wal 백엔드의 읽기 능력을 느리게 하지 않습니다.
    • verification - LogStore의 온라인 검증을 구성할 수 있는 중첩 객체입니다. 검증은 LogStore 백엔드가 데이터를 올바르게 저장하고 있는지에 대한 추가 보증을 제공합니다. 서버에 낮은 오버헤드를 부과하며 프로덕션에서 실행해도 안전합니다. 새 백엔드 구현을 평가할 때 가장 유용합니다. 검증은 리더에서 활성화해야 효과가 있으며 어떤 백엔드와도 사용할 수 있습니다. 활성화되면 리더는 마지막 체크포인트 이후 Raft에 기록된 모든 로그 항목의 체크섬을 포함하는 특별한 "체크포인트" 로그 메시지를 주기적으로 작성합니다. 검증이 활성화된 팔로워는 각 체크포인트에 대해 LogStore에서 모든 로그를 직접 읽은 다음 체크섬을 다시 계산하는 백그라운드 작업을 실행합니다. 각 체크포인트에 대한 보고서가 INFO 수준 로그로 출력됩니다. 체크섬 실패는 절대 발생하지 않아야 하며 해당 서버에서 복구할 수 없는 손상을 나타냅니다. 올바른 대응은 서버를 중지하고 데이터 디렉터리를 제거한 후 재시작하여 올바른 서버로 다시 따라잡는 것입니다. 하드웨어와 워크로드에 대한 자세한 내용을 포함한 검증 실패를 GitHub 이슈로 보고해 주세요. 자세한 내용은 Experimental WAL LogStore 백엔드를 참조하세요.
      • enabled - true로 설정하면 이 Consul 서버가 리더로 선출되었을 때 로그 검증 체크포인트를 작성·검증할 수 있게 합니다.
      • interval - 체크포인트 사이의 시간 간격을 지정합니다. 기본값은 없습니다. 간격을 제대로 활성화하려면 interval을 구성하고 enabled를 true로 설정해야 합니다. 30s에서 5m 사이의 간격을 권장합니다. 간격이 5m 이하로 설정되면 성능 오버헤드는 무시할 수 있습니다.
    • boltdb - Raft의 boltdb 백엔드에 대한 옵션을 구성하는 객체입니다. backend가 boltdb가 아니면 효과가 없습니다.
      • no_freelist_sync - true로 설정하면 BoltDB의 freelist를 raft.db 파일 내 디스크에 저장하는 것을 비활성화합니다. freelist 동기화를 비활성화하면 쓰기 작업에 필요한 디스크 IO를 줄일 수 있지만, Consul이 파일 내 여유 공간을 찾기 위해 데이터베이스를 스캔해야 하므로 시작 시간이 늘어날 수 있습니다.
    • wal - wal 백엔드를 구성하는 객체입니다. 자세한 내용은 Experimental WAL LogStore 백엔드를 참조하세요.
      • segment_size_mb - 새 세그먼트로 롤링하기 전 각 세그먼트 파일의 MB 단위 목표 크기를 나타내는 정수 값입니다. 기본값은 64이며 대부분의 배포에 적합합니다. 더 작은 값은 오래된 세그먼트를 더 빨리 삭제하여 공간을 회수할 수 있어 디스크 공간을 덜 사용할 수 있지만, 더 자주 안전하게 새 파일로 회전하면 꼬리 지연 시간(tail latencies)에 영향을 줄 수 있어 성능에 영향을 줄 수 있습니다. 더 큰 값이 성능을 크게 개선할 가능성은 낮습니다. 이 구성을 성능 테스트 목적으로 사용할 것을 권장합니다.
  • raft_protocol - -raft-protocol 명령줄 플래그와 동일합니다.
  • raft_snapshot_threshold - 디스크에 저장되는 스냅샷 사이의 최소 raft 커밋 항목 수를 제어합니다. 이는 거의 변경할 필요가 없는 저수준 매개변수입니다. 과도한 디스크 IO를 겪는 매우 바쁜 클러스터는 이 값을 높여 디스크 IO를 줄이고 모든 서버가 동시에 스냅샷을 찍을 가능성을 최소화할 수 있습니다. 이를 늘리면 로그가 훨씬 커지고 raft.db 파일의 공간을 다음 스냅샷까지 회수할 수 없으므로 디스크 IO를 디스크 공간과 맞바꿉니다. 이 값을 크게 높이면 재생해야 할 로그가 더 많아져 서버가 충돌이나 장애 조치에서 복구하는 데 더 오래 걸릴 수 있습니다. Consul 1.1.0 이상에서는 기본적으로 16384이며, 이전 버전에서는 8192로 설정되었습니다. Consul 1.10.0부터 consul reload 또는 서버에 SIGHUP을 보내 재로드할 수 있어 비상 상황에서 롤링 재시작 없이 스냅샷 활동을 조정할 수 있습니다.
  • raft_snapshot_interval - 서버가 스냅샷을 디스크에 저장해야 하는지 확인하는 빈도를 제어합니다. 이는 거의 변경할 필요가 없는 저수준 매개변수입니다. 과도한 디스크 IO를 겪는 매우 바쁜 클러스터는 이 값을 높여 디스크 IO를 줄이고 모든 서버가 동시에 스냅샷을 찍을 가능성을 최소화할 수 있습니다. 이를 늘리면 로그가 훨씬 커지고 raft.db 파일의 공간을 다음 스냅샷까지 회수할 수 없으므로 디스크 IO를 디스크 공간과 맞바꿉니다. 이 값을 크게 높이면 재생해야 할 로그가 더 많아져 서버가 충돌이나 장애 조치에서 복구하는 데 더 오래 걸릴 수 있습니다. Consul 1.1.0 이상에서는 기본적으로 30s, 이전 버전에서는 5s로 설정되었습니다. Consul 1.10.0부터 consul reload 또는 서버에 SIGHUP을 보내 재로드할 수 있어 비상 상황에서 롤링 재시작 없이 스냅샷 활동을 조정할 수 있습니다.
  • raft_trailing_logs - 스냅샷 후 디스크의 로그 저장소에 남겨지는 로그 항목 수를 제어합니다. 이는 팔로워가 매우 큰 스냅샷 크기와 높은 쓰기 처리량으로 인해 로그 잘림이 스냅샷이 팔로워에 완전히 설치되기 전에 발생하여 리더를 따라잡지 못할 때만 조정해야 합니다. 이것을 사용해 클러스터를 복구해야 한다면, 쓰기 처리량이나 Consul에 저장된 데이터 양을 줄이는 것을 고려하세요. 설계된 부하가 아닐 가능성이 높기 때문입니다. 기본값은 10000이며 모든 정상 워크로드에 적합합니다. Consul 1.5.3에서 추가되었습니다. Consul 1.10.0부터 consul reload 또는 서버에 SIGHUP을 보내 재로드할 수 있어 팔로워가 따라잡지 못할 때 가동 중지 없이 복구할 수 있습니다.
  • raft_boltdb 이 필드는 Consul v1.15.0에서 더 이상 권장되지 않습니다. 대신 raft_logstore를 사용하세요. Raft의 BoltDB 기반 로그 저장소에 대한 옵션을 구성할 수 있는 중첩 객체입니다.
    • NoFreelistSync 이 필드는 Consul v1.15.0에서 더 이상 권장되지 않습니다. 대신 raft_logstore.boltdb.no_freelist_sync 필드를 사용하세요. true로 설정하면 BoltDB freelist를 raft.db 파일 내 디스크에 동기화하는 것을 비활성화합니다. freelist를 디스크에 동기화하지 않으면 파일 내 여유 공간이 어디에 있는지 찾기 위해 db를 스캔해야 하므로 시작 시간이 늘어날 수 있는 대가로 쓰기 작업에 필요한 디스크 IO가 줄어듭니다.

더 알아보기 (Learn more)