이 글은 etcd 공식 블로그에 최근 게시된 원본 글을 미러링한 것입니다. 핵심 내용은 무엇일까요? v3.6으로 이동하기 전에 항상 etcd v3.5.26 이상으로 업그레이드하세요. 이렇게 하면 클러스터가 자동으로 복구되고 좀비 멤버를 피할 수 있습니다.
문제 요약
최근 etcd 커뮤니티는 사용자들이 v3.5에서 v3.6으로 업그레이드할 때 발생할 수 있는 문제를 해결했습니다. 이 버그로 인해 클러스터는 "좀비 멤버"를 보고할 수 있습니다. 좀비 멤버는 한동안 데이터베이스 클러스터에서 제거되었지만 다시 나타나 데이터베이스 합의에 참여하는 etcd 노드입니다. 이 좀비 멤버가 제거될 때까지 etcd 클러스터는 작동 불능 상태가 됩니다.
etcd v3.5 및 이전 버전에서는 v3store도 존재했지만 v2store가 멤버십 데이터의 진실의 원천(source of truth)이었습니다. v2store 사용 중단 계획의 일환으로, v3.6에서는 v3store가 클러스터 멤버십의 진실의 원천이 됩니다. 버그 보고서를 통해 일부 오래된 클러스터에서 v2store와 v3store가 불일치할 수 있다는 사실을 알게 되었습니다. 이러한 불일치는 업그레이드 후에 이전에 제거된 "좀비" 클러스터 멤버가 클러스터에 다시 나타나는 형태로 나타납니다.
해결책 및 업그레이드 경로
저희는 etcd v3.5.26에 메커니즘을 추가하여 v2store에서 v3store를 자동으로 동기화하고, v3.6.x로 업그레이드하기 전에 영향을 받는 클러스터가 복구되도록 했습니다.
현재 v3.6으로 업그레이드하는 많은 사용자를 지원하기 위해, 다음 안전한 업그레이드 경로를 제공합니다:
- 클러스터를 v3.5.26 이상으로 업그레이드합니다.
- 업데이트 후 모든 멤버가 정상(healthy)인지 확인합니다.
- v3.6으로 업그레이드합니다.
v3.5.26으로 업데이트하는 데 장애물이 있는 사용자를 위한 안전한 임시 해결책(workaround) 경로는 제공할 수 없습니다. 따라서 v3.5.26이 패키징 소스나 벤더에서 제공되지 않는 경우, 제공될 때까지 v3.6으로의 업그레이드를 연기해야 합니다.
추가 기술 정보
아래 정보는 참고용으로만 제공됩니다. 사용자는 다음 세부 사항을 알지 못해도 안전한 업그레이드 경로를 따를 수 있습니다.
이 문제는 etcd v3.5.25 이하 버전에서 프로덕션 환경에서 실행된 클러스터에서 발생합니다. 이는 클러스터에서 멤버를 추가하거나 제거하거나, 클러스터 실패로부터 복구하는 과정의 부작용입니다. 즉, etcd 클러스터가 오래될수록 이 문제가 발생할 가능성이 높지만, 클러스터의 사용 기간과 관계없이 모든 사용자에게 발생할 수 있습니다.
etcd 관리자들은 문제 보고자들과 협력하여 증상과 etcd 코드 및 로그 분석을 바탕으로 이 문제의 세 가지 가능한 원인(trigger)을 발견했습니다:
etcdctl snapshot restore버그 (v3.4 및 이전 버전):etcdctl snapshot restore를 사용하여 스냅샷을 복원할 때, etcdctl은 새로운 멤버를 추가하기 전에 기존 멤버를 제거해야 했습니다. v3.4에서는 버그로 인해 이전 멤버가 제거되지 않아 좀비 멤버가 발생했습니다. etcdctl에 대한 이 코멘트를 참조하세요.- v3.5 및 이전 버전의
--force-new-cluster: 드문 경우지만, 새로운 단일 멤버 클러스터를 강제로 생성할 때 이전 멤버가 완전히 제거되지 않아 좀비가 남았습니다. 이 문제는 v3.5.22에서 해결되었습니다. 자세한 기술 정보는 Raft 프로젝트의 이 PR을 참조하세요. --unsafe-no-sync활성화:--unsafe-no-sync가 활성화된 경우, 드물게 etcd가 v3store에 멤버십 변경 사항을 유지하지만 WAL에 기록하기 전에 크래시되어 v2store와 v3store 간의 불일치가 발생할 수 있습니다. 이는 단일 멤버 클러스터에서 문제입니다. 다중 멤버 클러스터의 경우, 크래시된 노드의 데이터로 새로운 단일 멤버 클러스터를 강제로 생성하면 좀비 멤버가 발생할 수 있습니다.
[!NOTE]
--unsafe-no-sync는 합의 프로토콜이 제공하는 보장을 깨뜨릴 수 있으므로 일반적으로 권장되지 않습니다.
중요한 점은 v2store와 v3store 멤버십 데이터가 불일치하게 되는 다른 원인이 아직 발견되지 않았을 수도 있다는 것입니다. 이는 위 세 가지 작업을 수행하지 않았다고 해서 안전하다고 가정할 수 없다는 의미입니다. 사용자가 etcd v3.6으로 업그레이드되면 v3store가 멤버십 데이터의 진실의 원천이 되므로, 추가적인 불일치는 더 이상 발생하지 않습니다.
v2store와 v3store 간의 일관성을 확인하려는 고급 사용자는 이 코멘트에 설명된 단계를 따를 수 있습니다. 이 확인은 문제를 해결하는 데 필수적이지 않으며, SIG etcd는 확인 결과와 관계없이 v3.5.26 업데이트를 우회하는 것을 권장하지 않습니다.
핵심 요약
v3.6으로 이동하기 전에 항상 v3.5.26 이상으로 업그레이드하세요. 이렇게 하면 클러스터가 자동으로 복구되고 좀비 멤버를 피할 수 있습니다.
감사의 말씀
Christian Baumann님께서 오랫동안 지속된 이 업그레이드 문제를 보고해주신 것에 대해 감사드립니다. 그의 보고와 후속 작업 덕분에 저희가 이 문제를 인지하고 상류(upstream)에서 조사 및 해결할 수 있었습니다.