노드 추가(부트스트랩), 교체, 이동, 제거

출처: 문서

본문

부트스트랩 (Bootstrap)

새 노드를 추가하는 것을 "부트스트래핑(bootstrapping)"이라고 해요. num_tokens 파라미터는 부트스트랩 중에 조인하는 노드에 할당될 가상 노드(토큰)의 수를 정의합니다. 토큰은 노드가 담당하게 될 링의 구간(token range)을 정의해요.

토큰 할당

기본 토큰 할당 알고리즘으로 새 노드는 담당할 num_tokens개의 랜덤 토큰을 고릅니다. 토큰이 랜덤하게 분포되므로 가상 노드 수가 많을수록 부하 분포가 개선되지만, 토큰 관리 오버헤드도 늘어나요. 기본값 256개의 가상 노드는 허용 가능한 오버헤드로 합리적인 부하 균형을 제공해야 합니다.

3.0 이상에서는 주어진 키스페이스에 대해 기존 가상 노드의 부하에 기반해 토큰을 할당하는 새 토큰 할당 알고리즘이 도입되어, 더 적은 수의 토큰으로 개선된 부하 분포를 얻을 수 있어요. 이 방식을 사용하려면 새 노드를 JVM 옵션 -Dcassandra.allocate_tokens_for_keyspace=<keyspace>와 함께 시작해야 합니다. 여기서 <keyspace>는 알고리즘이 토큰 할당을 최적화할 부하 정보를 찾을 수 있는 키스페이스예요.

수동 토큰 할당

cassandra.yaml의 initial_token 파라미터로 쉼표로 구분된 토큰 목록을 수동으로 지정할 수 있어요. 이를 지정하면 Cassandra는 토큰 할당 과정을 건너뜁니다. 이는 외부 도구로 토큰 할당을 하거나 이전 토큰으로 노드를 복원할 때 유용할 수 있어요.

범위 스트리밍 (Range streaming)

토큰이 할당된 뒤, 조인하는 노드는 담당하게 될 토큰 범위의 현재 리플리카를 골라 데이터를 스트리밍합니다. 기본적으로 각 토큰 범위의 기본 리플리카(primary replica)에서 스트리밍해, 새 노드의 데이터가 현재 상태와 일관됨을 보장합니다.

사용 불가능한 리플리카가 있는 경우 일관성 있는 부트스트랩 프로세스는 실패합니다. 이 동작을 재정의하고(사용 불가능한 리플리카의 데이터를 놓칠 수 있음) JVM 플래그 -Dcassandra.consistent.rangemovement=false를 설정할 수 있어요.

실패/중단된 부트스트랩 재개

2.2 이상에서 부트스트랩 프로세스가 실패하면 nodetool bootstrap resume을 호출해 이전 저장 상태에서 부트스트랩을 재개할 수 있어요. 어떤 이유로 부트스트랩이 중단되거나 멈추면 노드를 단순히 다시 시작해도 재개될 수 있습니다. 부트스트랩 상태를 정리하고 새로 시작하려면 JVM 시작 플래그 -Dcassandra.reset_bootstrap_progress=true를 설정할 수 있어요.

낮은 버전에서는 부트스트랩 프로세스가 실패하면 노드를 정리(모든 데이터 제거)하고 부트스트랩 프로세스를 다시 시작하는 것을 권장합니다.

수동 부트스트래핑

은닉 파라미터 auto_bootstrap: false를 설정하면 부트스트래핑 과정을 완전히 건너뛰고 바로 링에 조인할 수 있어요. 이는 백업에서 노드를 복원하거나 새 데이터센터를 만들 때 유용할 수 있습니다.

노드 제거

nodetool decommission(라이브 노드에서)으로 노드를 클러스터에서 빼내거나, nodetool removenode(다른 머신에서)로 죽은 노드를 제거할 수 있어요. 이 작업은 옛 노드가 담당하던 범위를 다른 노드에 할당하고 적절한 데이터를 거기에 복제합니다. decommission을 사용하면 데이터는 해임된 노드에서 스트리밍됩니다. removenode를 사용하면 데이터는 남아 있는 리플리카에서 스트리밍됩니다.

해임되는 노드에서 데이터가 자동으로 제거되지는 않으므로, 노드를 링의 다른 토큰에서 다시 서비스에 투입하려면 수동으로 제거해야 합니다.

노드 이동

num_tokens: 1일 때 nodetool move로 링에서 노드 위치를 옮길 수 있어요. 이동은 decommission + bootstrap보다 편리하고 더 효율적입니다. 노드를 이동한 뒤에는 불필요한 데이터를 제거하기 위해 nodetool cleanup을 실행해야 합니다.

죽은 노드 교체

죽은 노드를 교체하려면 JVM 시작 플래그 -Dcassandra.replace_address_first_boot=<dead_node_ip>와 함께 cassandra를 시작하세요. 이 속성이 활성화되면 노드는 하이버네이트 상태로 시작하고, 그 동안 다른 모든 노드는 이 노드를 DOWN(DN)으로 보지만 이 노드는 스스로를 UP(UN)으로 봐요. 정확한 교체 상태는 nodetool netstats에서 확인할 수 있습니다.

교체하는 노드는 이제 클러스터의 나머지 노드에서 데이터를 부트스트랩하기 시작합니다. 교체 노드는 교체 대상인 노드와 다른 IP 주소를 가진 경우에만 부트스트래핑 단계에서 쓰기를 받아요. (CASSANDRA-8523과 CASSANDRA-12344 참고)

부트스트래핑이 완료되면 노드는 "UP"으로 표시됩니다.

다음 경우 중 하나라도 해당되면, 부트스트랩 중/이전에 진행 중인 쓰기를 놓쳤으므로 교체된 노드를 다시 일관성 있게 만들기 위해 반드시 repair를 실행해야 합니다. 교체 기간은 노드가 처음 죽은 시점부터 새 노드가 교체 프로세스를 완료할 때까지의 기간을 말해요.

노드가 교체되기 전에 max_hint_window보다 오래 다운된 경우

죽은 노드와 동일한 IP 주소로 교체하고 있고, 교체가 max_hint_window보다 오래 걸리는 경우

진행 상황 모니터링

부트스트랩, 교체, 이동, 제거 진행 상황은 nodetool netstats로 모니터링할 수 있으며 스트리밍 작업의 진행 상황을 보여줘요.

범위 이동 후 데이터 정리

안전 조치로 Cassandra는 범위 이동 작업(부트스트랩, 이동, 교체)으로 인해 토큰 범위의 일부를 "잃는" 노드에서 데이터를 자동으로 제거하지 않아요. 새 노드가 가동되고 잘 작동한다고 확신되면 범위를 잃은 노드에서 nodetool cleanup을 실행하세요. 이렇게 하지 않으면 옛 데이터가 여전히 해당 노드의 부하로 계산됩니다.

노드 추가(부트스트랩), 교체, 이동, 제거