스플릿 브레인 리커버리 NCache 100% 가동 시간을 위해
NCache 매우 빠르고 확장 가능한 .NET용 메모리 내 분산 캐시입니다. .NET Core. 대부분의 시간, NCache 미션 크리티컬 애플리케이션을 위한 프로덕션 환경에서 실행됩니다. 결과적으로, 고 가용성 100% 가동 시간은 매우 중요한 요구 사항입니다. NCache. 과, NCache 다양한 기능을 통해 이 분야에서 탁월합니다.
이러한 고가용성 기능 중 하나는 중단 시간을 방지하기 위한 스플릿 브레인 감지 및 복구입니다.
캐시 클러스터에서 스플릿 브레인이란 무엇입니까?
NCache ~을 창조하다 자가 치유 동적 캐시 클러스터 TCP를 통해 서로 통신하는 여러 서버로 구성됩니다. 모든 캐시 서버는 클러스터로 상호 연결되며 클러스터 멤버십은 런타임에 유지되며 모든 캐시 서버뿐만 아니라 모든 캐시 클라이언트에 전파됩니다.
그러나 모든 분산 시스템과 마찬가지로 NCache 클러스터는 하나 이상의 캐시 서버가 클러스터의 나머지 서버에서 연결이 끊겼지만 두 서버 세트가 계속 실행되는 상황에 직면할 수 있습니다. 이것은 일반적으로 네트워크 결함이나 문제로 인해 발생합니다.
이런 일이 발생하면 각 캐시 서버 세트는 자신을 원래 캐시 클러스터의 살아남은 서버로 간주하고 다른 캐시 서버 세트가 다운되었다고 가정합니다(따라서 의학적 용어로 분할 브레인이라는 용어는 두뇌의 왼쪽이 작동하지 않음을 의미합니다. 오른쪽 뇌에 대해 모른다). 캐시 클라이언트도 유사한 방식으로 분할되거나 원래 클러스터 구성원을 기반으로 모든 캐시 서버와 계속 통신할 수 있습니다.
캐시 클러스터의 스플릿 브레인
이것은 분명히 건강하고 정상적인 상태가 아니며 오류로 이어집니다. 캐시 작업 그리고 가장 중요한 것은 데이터 무결성 문제입니다. 이제 각 "분할 클러스터"에는 클라이언트가 독립적으로 업데이트하는 자체 데이터 복사본이 있습니다. 그리고 동기화 없이 업데이트되는 동일한 데이터의 두 개 이상의 복사본으로 끝납니다.
분할 뇌는 어떻게 감지됩니까?
NCache 스플릿 브레인이 발생하면 자동으로 감지하는 기능이 있습니다. 클러스터 구성원은 클러스터의 모든 캐시 서버에서 유지됩니다. 따라서 분할 브레인 상황으로 인해 클러스터가 두 개 이상의 하위 클러스터로 분할될 때마다 각 하위 클러스터는 살아남은 클러스터로 생각하고 데이터 작업을 계속합니다.
그러나 이와 동시에 비정상적인 방식으로 클러스터를 이탈한 다른 캐시 서버가 있음을 알고 있습니다. 정상적인 방법은 캐시 관리자가 NCache 수단 클러스터에서 캐시 서버를 제거합니다. 따라서 각 하위 클러스터는 "잃어버린 서버"와 계속해서 재연결을 시도합니다. 동시에 각 하위 클러스터 로그 이벤트 원래 구성원 중 일부가 떠났음을 나타내는 Windows 이벤트 로그에. 따라서 스플릿 브레인의 경우, NCache 관리자는 거의 모든 캐시 서버에 대해 "노드 왼쪽" 이벤트를 봅니다.
분할 하위 클러스터 간의 네트워크 연결이 복원되어야 분할 브레인이 실제로 발생한 사실을 알 수 있습니다. 이때까지 그들은 구성원 중 일부가 클러스터를 떠났다고 계속 믿고 있습니다.
스플릿 브레인이 발생했음을 인식하면 각 하위 클러스터는 Windows 이벤트 로그에 이벤트를 기록하고 다음을 통해 캐시 관리자에게 알릴 수도 있습니다. 이메일 알림 스플릿 브레인이 발생했다는 것입니다.
스플릿 브레인 자동 복구는 어떻게 작동합니까?
NCache 스플릿 브레인에서 자동 복구를 구성할 수 있습니다. 그렇게 하면 언제라도 NCache 스플릿 브레인을 감지하면 자동으로 복구합니다. 다음을 통해 스플릿 브레인 복구 활성화 config.ncconf 추가하여 아래에 태그 꼬리표. 그런 다음 활성화 플래그를 true로 변경하고 스플릿 브레인에 대한 감지 간격을 초 단위로 설정할 수 있습니다.
<cache-settings...>
<split-brain-recovery enable="True" detection-interval="60"/>
</cache-settings>클러스터가 둘 이상의 하위 클러스터로 분할된 후 네트워크 연결이 복원되면 마침내 스플릿 브레인이 발생했음을 알게 됩니다. 이 시점에서 사용자가 자동 복구를 구성한 경우 모든 하위 클러스터는 서로 협상하여 어느 하나의 하위 클러스터가 "마스터 클러스터"가 되고 나머지 하위 클러스터가 이 "마스터 클러스터"가 되어야 하는지 파악합니다. 데이터를 버리고 기존 클러스터에 합류하는 새로운 노드인 것처럼 행동함으로써 "클러스터"를 생성합니다.
"마스터"가 되어야 하는 하위 클러스터를 결정하는 데 사용되는 규칙은 간단합니다. 가장 많은 수의 구성원 노드가 있는 하위 클러스터입니다. 그리고, 여러 개의 하위 클러스터가 동일한 수의 구성원 노드를 가질 경우 코디네이터의 IP 주소가 가장 작은 하위 클러스터가 승리하여 "마스터 클러스터"가 됩니다. 그리고 나머지 하위 클러스터가 결합되고 최종 결과는 원래 클러스터의 크기와 동일한 하나의 큰 클러스터가 됩니다.