NCache 스플릿 브레인 복구 아키텍처 및 데모
NCache Split Brain Detection and Recovery라는 중요한 고가용성 아키텍처 기능을 제공합니다. 이 비디오를 보고 이 기능에 대해 배운 다음 실습 데모를 보십시오. NCache 분할 뇌 회복.
오늘은 NCache 스플릿 브레인 복구 아키텍처와 데모도 제공합니다.
NCache .NET용 메모리 내 분산 캐시이며 .NET Core 응용 프로그램. 또한 Java 및 Node.js 애플리케이션도 지원합니다. NCache 애플리케이션이 여러 애플리케이션 서버에서 실행되는 상위 트랜잭션 애플리케이션에서 사용됩니다. 웹 애플리케이션, 마이크로서비스 애플리케이션 또는 기타 서버 애플리케이션이 될 수 있습니다. 그리고, NCache 애플리케이션 계층과 데이터베이스 사이에 위치하며, SQL 서버 또는 Oracle 유형의 관계형 데이터베이스 또는 모든 NoSQL database CosmosDB, MongoDB 또는 레거시 메인프레임 데이터베이스 또는 데이터와 같은 그리고, NCache 일반적으로 클러스터에 XNUMX개 이상의 캐시 서버가 있으며 이 미션 크리티컬 애플리케이션 환경의 경우 NCache 고가용성을 제공하며 고가용성의 일부로 분할 브레인 감지 및 분할 브레인 복구라는 매우 중요한 기능이 있습니다.
동적 캐시 클러스터 아키텍처
스플릿 브레인(split-brain)에 대해 알아보기 전에 NCache 동적 캐시 클러스터링 아키텍처.
이것은 모든 서버가 TCP 소켓을 통해 다른 모든 서버에 연결되는 TCP 기반 아키텍처입니다. 자가 치유가 가능한 PXNUMXP 아키텍처입니다. 자가 치유는 변경 사항에 따라 자동으로 조정됨을 의미합니다. 그리고 PXNUMXP 아키텍처로 인해 단일 실패 지점이 없습니다. 주인도 없고 노예도 없다는 말이다. 일반적으로 클러스터에서 가장 오래된 노드인 클러스터 조정자 노드가 있습니다. 그러나 이것이 중단되면 다음으로 오래된 노드가 자동으로 후속 노드가 됩니다. 클러스터 조정자는 클러스터 관리를 담당합니다. 클러스터 구성원을 관리합니다. Partition 또는 Partition-Replica 토폴로지의 경우 데이터 분포 맵을 관리합니다. 또한 클러스터의 상태도 관리합니다.
이제 내가 말했듯이 이 클러스터의 모든 노드는 다른 모든 노드에 연결되며 해당 연결을 추적합니다. 그리고 해당 연결이 끊어지면 클러스터 내에 연결 장애 조치 기능이 있습니다. 즉, 해당 노드는 자동으로 재시도를 수행하고 구성 가능한 옵션인 여러 번 재시도하며 각 재시도에는 시간 초과가 있습니다. 또한 소켓 연결이 작동 중인지 확인하기 위해 구성 가능한 간격으로 하트비트를 계속 보내는 하트비트 기능도 있습니다. 이 모든 작업이 수행되는 이유는 대부분의 상황에서 연결 끊김을 자동으로 복원하거나 복구하는 데 충분하기 때문입니다. 그리고 그 이유는 캐시 서버가 일반적으로 동일한 데이터 센터, 실제로 동일한 서브넷에 배포되기 때문입니다. 따라서 이러한 캐시 서버 간의 연결은 일반적으로 매우 안정적입니다. 그리고 스플릿 브레인은 자주 발생하지는 않지만 가끔 발생합니다. 그리고 그렇게 되면 어떻게 관리하는지에 대해 이야기하겠습니다.
어쨌든 이 아키텍처를 사용하면 캐시나 애플리케이션을 중지하지 않고 런타임에 캐시 서버를 추가하거나 제거할 수 있습니다. 그리고 클러스터에 캐시 서버를 추가할 때마다 클러스터 조정자는 클러스터 멤버십 맵을 업데이트하고 이를 모든 캐시 서버에 동적으로 전파한 다음 모든 클라이언트에 동적으로 전파합니다. 그런 다음 유사하게 파티션 또는 파티션 복제본 토폴로지인 경우 데이터 배포 맵도 업데이트되고 다음으로 이동할 수 있습니다. NCache 이에 대한 자세한 내용은 아키텍처 비디오를 참조하십시오. 그러나 파티션 또는 파티션 복제 토폴로지에는 1000개의 버킷이 있습니다. 이 버킷은 기본적으로 분산 맵이며 맵은 서버에 각 서버에 어떤 버킷이 있는지, 클라이언트에게 언제 전송되는지 알려줍니다. 클라이언트는 데이터가 어디에 있는지 알고 있습니다. 이것이 동적 캐시 클러스터입니다.
동적 클라이언트 연결
이것의 두 번째 측면은 클러스터 내의 연결이 동적인 것처럼 클라이언트와 클러스터 간의 연결도 동적이라는 동적 클라이언트 연결입니다.
그리고 매우 가벼운 TCP 기반 연결입니다. 그리고 해당 연결이 끊어지면 다시 시도하고 시간 초과가 발생하는 연결 장애 조치 기능이 있습니다. 또한 클라이언트가 연결을 유지하기 위해 클러스터에 하트비트 유형의 메시지를 계속 보내는 연결 유지 기능도 있습니다. 실제로 클라이언트와 클러스터 간의 연결 끊김 가능성은 클러스터 자체 내보다 가능성이 높으며 그 이유는 클라이언트가 방화벽을 넘어도 별도의 서브넷에 배포될 수 있기 때문입니다. 따라서 이 모든 것은 일반적으로 소켓이 파손될 가능성을 높입니다. 따라서 이러한 일이 발생할 때마다 클라이언트는 다시 연결할 수 있습니다. 따라서 연결 장애 조치 기능이 있습니다.
이 전체 아키텍처를 사용하면 캐시나 애플리케이션을 중지하지 않고 런타임에 클라이언트를 추가하거나 제거할 수 있습니다. 그리고 클라이언트가 추가될 때마다 클라이언트는 클러스터에서 클러스터 구성원 정보를 얻은 다음 파티션 또는 파티션 복제본 토폴로지인 경우 클러스터에서 여기에 표시한 데이터 분포 맵도 가져옵니다. 그리고 이를 통해 클라이언트는 클러스터에 있는 서버의 수와 서버가 누구인지 자동으로 정확하게 알 수 있습니다. 따라서 파티션 또는 파티션 복제 토폴로지에서만 연결하고 데이터 배포 맵이 무엇인지 알 수 있습니다.
분할 뇌 감지
따라서 이러한 모든 아키텍처를 고려할 때 재시도 및 시간 초과를 통해 TCP 연결에 복원력이 구축되어 있음에도 불구하고 여전히 상황이 있지만 어떤 이유로 인해 실제로 캐시 서버 간에 연결이 실제로 끊어질 수 있습니다. 하드웨어적인 이유일 수 있습니다. 네트워크 드라이버 문제이거나 다양한 이유일 수 있습니다. 그럴 때마다 우리는 그것을 연결 끊김이라고 부릅니다.
따라서 캐시 클러스터링 아키텍처에서 클러스터의 모든 노드는 연결 끊김 여부를 계속 감지합니다. 즉, 재시도에도 불구하고 연결이 계속 끊어집니다. 연결이 끊길 때마다 각 노드는 다른 노드가 죽었다고 가정합니다. 따라서 다른 모든 노드와 계속 통신합니다. 예를 들어 여기에 서버가 있는 경우 이 노드는 이 세 가지 모두와 통신합니다. 따라서 이 노드가 다운될 수 있습니다. 따라서 이 노드는 이 세 가지와 통신할 수 있습니다. 그런 일이 발생하면 이 XNUMX개가 이제 XNUMX개의 클러스터이고 이 노드가 떠났다고 가정합니다. 그래서, 이와 같은 일이 발생했을 때, XNUMX개의 노드로 구성된 클러스터를 가정해 보겠습니다. 그리고 저는 연결이 끊어지는 예를 들어 그 중 XNUMX개가 서로 대화할 수 있는 방식으로 끊어집니다. 이 두 가지는 다음과 같습니다. 서로 대화할 수 있고 이 사람은 누구와도 대화할 수 없습니다.
따라서 이 노드가 모든 것을 감지할 때 그런 일이 발생하면 그들은 모두 다음과 같이 가정합니다. 저는 이 세 노드와 대화할 수 있고 내가 세 노드로 구성된 클러스터이고 내 노드 중 하나가 노드는 이미 클러스터 조정자가 될 수 있는 클러스터 조정자가 될 것입니다. 왜냐하면 그것이 아마도 가장 오래된 s1이고 여기에서 계속 클러스터 조정자가 되기 때문입니다. 그러나 두 개의 분할의 경우 s4가 이 클러스터의 새 클러스터 조정자가 됩니다. 그리고 split 3의 경우 유일한 노드인 s6도 조정자가 됩니다. 이제 이 상황에서 이 노드는 이 세 노드가 이 세 노드와 통신할 수 있음을 알고 있습니다. 그래서 나는 괜찮아, 다른 사람들은 죽었다고 말합니다. 이것 역시 같은 생각입니다. 나는 다른 사람들이 죽어서 좋습니다. 이들은 내가 괜찮다고 생각하고 다른 사람들은 죽었다.
그러나 그들은 또한 내가 XNUMX개의 노드로 구성된 클러스터여야 한다는 것도 알고 있습니다. 그래서 그들은 다시 돌아올지 여부를 확인하기 위해 다른 모든 노드에 ping을 계속 시도합니다. 그리고 구성 가능한 간격 동안 핑이 발생하고, 그 후에는 포기하고 이러한 노드가 영구적으로 다운되었고 나만 남은 것으로 가정합니다. 그러나 그 간격 내에서 연결이 있다고 가정하면 네트워크 연결이 복원되고 이제 이러한 노드가 서로 볼 수 있습니다. 이 예에서 그들 모두가 서로를 볼 수 있다고 가정해 봅시다. 그래서 이제 그들은 오, 우리가 세 개의 분리된 분할을 만들었지만 서로 대화할 수 있다는 것을 깨달았습니다.
그래서 이제 그들은 공식적으로, NCache 공식적으로 분할을 감지합니다. 연결이 끊어진 순간에 이별이 일어났지만, NCache 노드는 그들이 모두 죽었다고 생각했기 때문에 이것이 분할이라는 것을 알지 못했습니다. 그러나 해당 노드가 지정된 간격 내에 돌아오고 캐시 노드는 "좋아, 분할이 발생했으며 이제 분할 복구를 수행할 시간"이라고 말할 것입니다. 그리고 이렇게 하는 이유는 애플리케이션이 계속 작동하려면 정상적인 캐시 클러스터가 필요하고 분할이 정상적인 상황이 아니더라도 관리자 직원이 홀수 시간에 개입해야 하는 대신 자동으로 복구할 수 있다면 정상적인 캐시 클러스터가 필요하기 때문입니다. 낮이나 밤이나 주말. 그러면 삶이 편해진다. NCache 자동으로 정상 상태인 XNUMX개의 정상 클러스터로 돌아갑니다. 그러나 어떻게 그런 일이 일어납니까?
첫 번째는 연결이 복원되고 서로 볼 수 있는 경우에만 감지되는 것처럼 분할이 감지된다는 것입니다. 그때까지 그들은 다른 사람들이 죽었다고 가정합니다. 괜찮아? 이제 해당 분할이 감지되고 분할 복구가 시작됩니다.
스플릿 브레인 복구
분할 복구에는 무엇이 포함됩니까?
따라서 분할 복구에서는 두 개의 가장 큰 하위 클러스터 또는 두 개의 가장 큰 분할이 먼저 병합됩니다. 그리고 이 분할의 클러스터와 이 분할의 클러스터는 내가 둘 중 더 작고 여기의 크기는 각 클러스터의 노드 수를 기반으로 하기 때문에 괜찮다고 서로 조정합니다. 데이터의 양을 기준으로 할 수 있습니다. 활동량과 클라이언트 수를 기반으로 할 수 있었지만 가장 가능성이 높은 상황이기 때문에 노드 수를 선택했습니다. 대부분의 경우 해시 맵 배포로 인해 모든 노드에 거의 동일한 양의 데이터가 있기 때문입니다. 수천 개의 버킷이 고르게 배포되어 있기 때문입니다. NCache 균형을 벗어나면 노드 간에 데이터 균형을 다시 조정합니다.
따라서 이 모든 것은 모든 노드에 거의 동일한 양의 데이터가 있는 것이 가장 가능성이 높은 상황임을 의미합니다. 따라서 가장 많은 수의 노드는 가장 많은 양의 데이터를 의미합니다. 그래서 그것이 주인이 되는 것입니다. 그리고 이 다른 분할은 데이터를 이 클러스터에 포기하고 새로운 노드로 이 클러스터에 다시 가입해야 합니다. 그래서 가장 먼저 하는 일은 클라이언트를 포기하는 것입니다. 따라서 이 두 서버, 이 조정자는 다른 노드에 클라이언트를 포기하고 클라이언트에게 이 클러스터에 연결하도록 지시해야 한다고 알립니다. 따라서 가장 먼저 발생하는 것은 클라이언트가 새 클러스터로 이동하는 것입니다. 이것이 정상 상태이고 이것이 마스터 클러스터이기 때문입니다. 클라이언트가 여기로 이동하면 이제 이 클러스터가 데이터를 포기하고 기본적으로 재부팅되는 것을 볼 수 있습니다. 재부팅되지는 않지만 데이터를 포기하고 이 클러스터를 정상 노드로 다시 조인합니다.
이제 결과적으로 XNUMX분할과 XNUMX분할을 병합한 XNUMX노드 클러스터가 생겼습니다. 그래서, 그것이 끝나면 다음으로 가장 큰 분할로 가서 이것을 이것과 병합합니다. 이제 우리의 경우에는 세 개의 분할만 있었지만 세 개 이상을 가질 수 있으며 알고리즘은 가장 큰 것부터 시작하여 다음으로 큰 것과 다음으로 큰 것 등으로 병합하는 것입니다. 따라서 필요한 만큼 반복하지만 어느 시점에서든 두 개의 분할만 병합됩니다. 따라서 이 두 분할이 병합되는 동안 세 번째 분할은 독립적인 것으로 간주되며 분할이 병합되고 이제 이 병합이 발생할 때까지 작업을 계속 수행할 것입니다.
그리고 네 번째 분할이 있다면 이 분할 뒤에도 병합됩니다. 따라서 이 과정에서 얼마나 많은 노드가 데이터를 잃거나 포기했는지에 따라 데이터가 손실된다는 점에 유의하십시오. 따라서 예를 들어 이 경우 XNUMX개의 노드가 마스터가 되고 나머지 XNUMX개는 데이터를 잃게 됩니다. 파티션 복제본 토폴로지에서도 파티션당 하나의 복제본만 있습니다. 따라서 데이터가 손실되며 이는 이 상황의 일부일 뿐입니다. 그러나 이 현실의 다른 부분은 데이터 캐싱 상황의 경우 이 데이터가 이미 오고 있다는 것입니다. 데이터베이스에 이미 있습니다. 따라서 데이터를 잃지 않고 데이터베이스에서 다시 로드하기만 하면 됩니다. 애플리케이션 작업의 적중률을 기반으로 다시 로드할 수 있습니다. 읽음에 따라 다시 로드할 수도 있습니다. 의 캐시 새로 고침 기능을 기반으로 다시 로드할 수도 있습니다. NCache 그러나 어느 쪽이든 데이터는 손실되지 않습니다.
그러나 데이터가 세션 상태에 더 가깝다면 영구 저장소에 존재하지 않는 다른 임시 데이터는 손실된 데이터입니다. 따라서 이 경우 해당 세션을 다시 만들어야 합니다. 그러나 그 데이터 손실에도 불구하고 결국 네트워크 오류가 발생했기 때문에 여전히 더 나은 상황입니다. 따라서 결과가 있습니다.
다음 버전에서는 NCache, 캐시를 지속할 수 있는 지속성 기능을 제공할 예정입니다. 그리고 영구 캐시는 캐시에 있던 모든 것이 자체적으로 유지됨을 의미합니다. NCache의 고유한 지속성 저장소와 분할 브레인 복구에서 이러한 방식으로 일시적인 데이터도 손실되지 않습니다. NCache 영구 저장소에 복사본을 보관하고 있습니다. 그러나 해당 기능이 공개되면 이에 대해 설명하겠습니다. 그래서 이번에는 이것에 대해서만 이야기하려고 합니다.
실습 데모
따라서 이 아키텍처를 설명했으면 합니다. 이제 실제로 어떻게 할 수 있는지에 대한 데모를 보여 드리겠습니다. NCache. 따라서 XNUMX개의 캐시 서버가 있고 이 목록과 이 목록 사이에 분할을 생성할 예가 있습니다.
이 두 분할을 만들겠습니다. 분할 XNUMX에는 이 두 캐시 서버가 포함되고 분할 XNUMX에는 이 두 캐시 서버가 포함됩니다. 그리고 지금 제가 관리하고 모니터링하는 데 사용할 Windows 클라이언트가 하나 있습니다. 그리고 이 클라이언트에 대해 두 개의 선반이 열려 있는 Linux 클라이언트가 있습니다. 따라서 거기에서 두 개의 개별 클라이언트 응용 프로그램을 시작할 수 있습니다. 그래서 지금 이 클러스터를 실행하고 있습니다. 이 클러스터를 추가하는 방법을 보여주는 다른 비디오가 있기 때문에 이 클러스터를 추가하는 방법을 보여주지 않겠습니다. 저는 그 중 뇌가 분리된 부분만 보여드리겠습니다.
클러스터 상태 및 통계 모니터링
여기 XNUMX노드 클러스터가 있습니다. XNUMX노드 클러스터가 있습니다. 여기에서 실행 중인 XNUMX노드 클러스터가 있습니다. 알겠습니다. 통계를 열고 모니터도 열겠습니다. 그래서 내가 한 것은 두 개의 다른 NCache 관리자 창. 하나는 바로 여기에 있는 .97에 연결되고 하나는 바로 여기 .82에 연결됩니다. 그래서 이것은 .97이며 실제 관리자가 있습니다. 모니터도 있고 통계도 있어요. 그리고 두 번째 것은 .82이고 저는 이것을 다시 할 것입니다. 동일한 클러스터이지만 관리를 위해 다른 서버와 통신하고 있습니다. 나는 바로 여기에서 이 서버와 비교하여 이 서버에 대해 이야기하고 있습니다. 그리고, 이것에서, 나는 다시 통계를 할 것입니다. 그래서, 나는 활동을 볼 수 있습니다. 아직 실행 중인 클라이언트가 없기 때문에 현재 활동이 없습니다. 그리고 모니터도 열어봅니다.
그런데 왜 이 두 개를 열었을까? 왜냐하면 모니터링하고 싶고 이 노드에 연결하고 싶고 이 노드에 연결하고 싶기 때문입니다. 그래서 분할을 할 때 볼 수 있습니다. 왜냐하면 분할이 발생했을 때 내가 이것에만 연결되어 있다면, 내게 남은 서버가 두 개뿐이고 이 서버는 볼 수 없다는 것을 보여줄 것이기 때문입니다. 그래서 저는 이것을 두 가지 관점에서 보고 싶습니다. 왜냐하면 저는 방화벽 규칙을 통한 분할을 소개할 것입니다. 물론 귀하의 경우에는 방화벽 규칙을 사용하지 않을 것입니다. 일종의 네트워크 중단이 발생합니다. 그래서 방화벽 규칙을 통해 이를 도입하거나 시뮬레이트할 것입니다. 이제 관리 및 모니터링을 위해 이 노드에 연결하고 관리 및 모니터링을 위해 이 노드에 연결했습니다. 그리고, 저는 지금 여기에 올 것이고 저는… 오, 아직 아닙니다.
또한 이 명령줄을 사용하여 Get-Caches-Server를 호출하고 여기에서 .82와 이야기하겠습니다.
나는 82와 이야기하고 당신이 가지고 있는 모든 캐시에 대한 세부 정보를 알려줄 것입니다. 따라서 .82는 82개의 서버가 있는 democache라는 캐시가 있다고 말합니다. 102, 122, 97, 117 및 XNUMX. 현재 분할이 없기 때문에 XNUMX 서버 클러스터입니다.
다른 서버인 97로 이동하겠습니다.
저도 똑같이 물어보겠습니다. 당신의 서버를 나에게 주십시오. 82-서버 캐시가 있습니다. 102, 122, 97, 117 및 XNUMX, 현재. 따라서 XNUMX개의 서버 클러스터이며 분할이 없으며 모든 것이 좋습니다.
Test-Stress Powershell Cmdlet을 사용하여 스트레스 시뮬레이션
모든 것이 잘 작동합니다. 이제 응용 프로그램을 시작하겠습니다. PowerShell 창이 있습니다. 사실 여기가 리눅스 박스입니다. 여기서 무슨 일이 일어났는지 보여드리겠습니다. 어서 해봐요! PowerShell을 다시 열겠습니다. 죄송합니다. 이 모듈을 가져올 것입니다. NCache 관리 모듈. Linux에서만 그렇게 하면 됩니다. Windows에서는 이것을 가져올 필요가 없습니다. 그런 다음 나는 Test-Stress democache라고 말할 것입니다. 괜찮아. 이제 이 도구 중 하나를 실행했습니다. 여기서도 똑같이 할게요.
나는 Test-Stress democache라고 말할 것입니다. 나는 이 두 가지를 모두 가지고 있다. 이제 봐, 나는 활동을 하고 있다. 여기에서 볼 수 있듯이 97개 노드 모두에서 활동이 발생했습니다. 하나 둘 셋 넷 다섯. 97개 노드 모두에서 활동이 발생했습니다. 바로 여기, 나는 그것을 볼 수 있습니다. 여기도 마찬가지입니다. 노드가 XNUMX개 있습니다. 나는 다시 XNUMX을 말하고 있습니다. 이것은 지금 .XNUMX입니다.
여기에서도 같은 것을 볼 수 있는지 봅시다. 따라서 .82로 이동하여 XNUMX개의 노드 활동이 발생하는지 확인합니다. 통계 창에도 활동이 표시됩니다.
괜찮아! 따라서 모든 것이 잘 작동합니다. 일반적으로 나는 이것을 열지 않고 두 개의 다른 서버에서 캐시 관리자를 모니터링합니다. 내가 여는 이유는 내가 분할을 보여야 하고 분할이 발생하면 분할의 양쪽에서 무슨 일이 일어나고 있는지 보여줘야 하기 때문입니다.
네트워크 연결 끊기 유도
괜찮아! 이제 모든 것이 실행되었습니다. 지금부터 소개를 진행하겠습니다. 그래서 제가 할 일은 이 두 상자에 대해 방화벽 규칙을 사용하는 것입니다. 그래서 여기서는 방화벽을 사용하겠습니다. 여기서는 방화벽을 사용하겠습니다. 그래서 저는 이미 두 가지 규칙을 설정했습니다. 그래서 로그인을 하려고 합니다. 저는 여기에서 97에 로그인했습니다. 여기 규칙이 있습니다. 인바운드 규칙이 있다고 가정해 보겠습니다. 그것은 NCache, 방금 불렀어 NCache 분할 뇌. 이 규칙은 캐시인 78~7900 포트에서 연결을 차단하라는 것입니다.
NCache 모든 캐시에 대해 별도의 프로세스를 시작합니다. 따라서 해당 캐시 프로세스는 기본적으로 7800~7900 포트를 사용합니다. 구성 가능하지만. 따라서 이를 시뮬레이션하려면 포트를 차단해야 하는 다른 포트를 사용하고 있을 수 있습니다. 그리고 포트 8250은 관리 포트입니다.
스코프는 82, 102, 122에 대한 차단을 말하고 있습니다. 그래서 저는 이 세 상자가 당신에게 접근하는 것을 차단하라고 말하고 있습니다. 기본적으로 그것이 말하는 것입니다.
그래서 저는 이 포트를 가지고 있습니다. 나는 규칙 활성화라고 말하고 아웃바운드 규칙에 대해 동일한 포트를 가지고 있습니다. 그것은... 그래서, 그것은 아웃바운드를 차단하고 있습니다. 그리고 이제 1번으로 넘어가겠습니다.17 그것도 차단하세요. 117번으로 가겠습니다. 다시 말하지만, 바로 여기에 인바운드가 있습니다. 여기도 마찬가지입니다. 블록 연결, 포트, 78 79, 범위, 이 세 상자 모두. 괜찮아. 그래서, 나는 규칙을 활성화한다고 말할 것입니다. 활성화되었습니다. 저는 여기에서 규칙 활성화라고 말할 다른 곳으로 가겠습니다.
자, 이제 내가 한 일은 이 모든 것에서 방화벽을 켰습니다.
XNUMX개의 하위 클러스터 형성
이제 분할이 시작됩니다. 즉시 발생하지는 않지만 먼저 82에게 이것이 무엇인지 물어보면 알 수 있습니다. 캐시에 얼마나 많은 서버가 있습니까? 괜찮다고 합니다! 저는 82, 102, 122, 97, 117을 가지고 있습니다. 따라서 분할이 아직 일어나지 않았기 때문에 여전히 XNUMX가 모두 있습니다. 여전히 재시도 및 기타 모든 작업을 진행 중입니다. 다른 하나에게 물어보겠습니다. 서버가 몇 대입니까? 아직 하나, 둘, 셋, 넷, 다섯이 있습니다. 따라서 여전히 재시도 및 시간 초과가 발생하므로 분할이 아직 발생하지 않았습니다. 그러나 곧 분열이 일어날 것입니다.
나는 여기에 와서 몇 정거장이 보이기 시작하는지 볼 것입니다. 그래서 저는 여기서 97과 이야기하고 있습니다. 97은 XNUMX노드 클러스터 측입니다.
그래서 97은 보고만 있다고 하고.. 그래서 안본다는 102, 182, 82는 멈췄다고 하는데 97과 1은17 잘 실행되고 있습니다. 괜찮아! 상대방이 무엇을 보여주고 있는지 봅시다. 이 다른 쪽이었던 분할의 다른 쪽. 그래서, 저는 97과 이야기하고 있었습니다. 이제 82와 이야기를 하려고 합니다. 보시다시피 이것은 82입니다. 바로 여기에 82가 있습니다. IP 주소... 괜찮습니다! 102, 122라고 합니다. 따라서 122는 부분적으로 연결되어 있고 82는 완전히 연결되어 있습니다.
그것은 여전히 회복을 겪고 있습니다. 122가 다른 노드 중 일부와 통신할 수 없는 이 재시도 단계를 여전히 거치고 있지만 계속 진행되고 앞으로 일어날 일은 제가 빠르게 보여드리겠습니다…
클러스터에 부분적으로 연결된 노드가 있는 경우 클러스터에서 부분적으로 연결된 또는 부분적으로 연결된 노드를 제거하여 정상적인 클러스터를 생성하는 기능이 있습니다. 그래서, 그것은 바로 지금 일어나고 있는 것은 그것이 다른 클러스터, 부분적으로 연결된 노드인 다른 노드를 제거하고 있다는 것입니다. 이제 다시 여기로 와서 명령줄이 무엇을 말하는지 봅시다. 저는 82에 대해 이야기하고 있습니다. 이것은 제가 말했듯이 82노드 클러스터입니다. 그래서, 그것은... 몇 개가 있는지 볼까요? 죄송합니다. 97에는 하나, 둘, 셋, 넷이 있습니다. 그래서 97개가 있습니다. 아직 XNUMX개가 없습니다. XNUMX개가 있습니다. 그것은 여전히 진행 중입니다 ... 노드를 그대로 강제로 제거 할 것이고 이제 여기있는 XNUMX로 갈 것입니다. 괜찮습니다. 서버가 몇 대입니까? 그리고 XNUMX은 XNUMX개만 가지고 있습니다.
그래서 97은 이미 다른 셋을 볼 수 없다는 사실을 확인했다. 그래서 여기 있는 클러스터는 나뿐인 것 같습니다. 분할만 말했듯이 분할이 있는지는 모릅니다. NCache 이 연결이 복원될 때만 분할에 대해 알 수 있습니다. 따라서 지금은 다른 노드가 죽었다고 생각합니다. 이제 이 두 노드로 계속 진행하겠습니다. 그리고, 여기 다른 곳으로 가겠습니다. 그것이 무엇을 가지고 있는지 봅시다. 아, 그래요! 이제 이것도 XNUMX개 남았습니다. 그래서, 그것은 통과했고 또한 이것을 했습니다. 이제 정상적인 클러스터에 도달하기 위해 부분적으로 연결이 끊긴 노드를 제거했습니다. 하지만 노드가 XNUMX개뿐인 클러스터죠?
그래서 바로 여기 있는 서버 .82와 이야기했습니다. 캐시에 몇 대의 서버가 있는지 물었더니 97개라고만 나와 있습니다. XNUMX에게 캐시에 몇 대의 서버가 있는지 물었더니 XNUMX개만 있다고 합니다.
괜찮아! 그래서 분할이 발생했습니다. 분할의 일부로 지금까지 애플리케이션에서 예외가 발생하지 않았음을 알 수 있습니다. 즉, 데이터 손실 없이 분할이 발생했습니다. 이것은 아마도 응용 프로그램에서 발생하지 않았을 수 있지만 어떤 경우에는 몇 가지 예외가 발생합니다.
네트워크 복원 시 스플릿 브레인 감지 및 복구
괜찮아! 이제 내가 할 다음 단계는 분할 브레인을 시작하는 것입니다. 그래서 이제 스플릿 브레인이 감지되고 복구가 시작되도록 연결을 복원하고 싶습니다. 하지만 그 전에 여기에서 첫 번째 주제인 클러스터 설정으로 이동하면 캐시 구성에서, 맨 아래로 이동하면 이미 분할 뇌.
따라서 자동 복구를 활성화하면 NCache 스플릿 브레인을 감지하면 스플릿 브레인에서 자동으로 복구됩니다. 그리고 앞서 언급했듯이 연결이 복원되면 스플릿 브레인을 감지합니다.
자, 이제 97로 돌아가서 이 방화벽을 끄겠습니다. 그리고 먼저 97번으로 가겠습니다. 저는 여기에 와서 이 규칙을 비활성화하고 여기로 와서 이 규칙을 비활성화할 것이라고 말할 것입니다.
괜찮아! 다 했으니 이제 1번으로 가겠습니다17 여기서도 규칙을 비활성화하도록 하겠습니다. 규칙을 비활성화합니다. 규칙을 비활성화합니다. 괜찮아! 이제 규칙을 비활성화했습니다. 따라서 이 방화벽이 꺼져 있어 이제 서로 볼 수 있거나 곧 서로를 볼 수 있게 될 것입니다. 그것은 순식간에 일어나지는 않겠지만 그들은 서로를 볼 수 있을 것입니다. 그리고, 보시다시피…
그래서, 나는 실제로 다시 여기에 올 것이고 당신의 캐시를 보여주라고 말할 것입니다. 다시 말하지만, 이것을 내 앞에 두고 확실히 말할 것입니다. 지금 82와 이야기하고 있다고 말하고 82가 말하길, 82, 102, 122가 있다고 말합니다. 그래서, 그래서 아직까지는 97개의 캐시가 있습니다. 나머지 117개는 안보이네요. 나는 다른 사람에게 가서 당신의 캐시를 보여주라고 말할 것입니다. XNUMX번과 XNUMX번입니다. 지금까지 스플릿 브레인 복구는 시작되지 않았지만 시작될 것입니다. 재시도가 발생하는 데 약간의 시간이 걸리기 때문입니다. 여기에서 볼 수 있듯이 이미 하나 둘 셋 넷 다섯 서버를 보고 있습니다. 여기 하나 둘 셋 넷 다섯 서버가 있습니다.
하지만 다시 말하지만, 내 좋은 명령줄 PowerShell 도구에 의존할 것입니다. 캐시 호출을 받도록 하겠습니다. 나는 82에게 말을 걸어 당신이 가지고 있는 서버가 몇 개인지 보여주라고 말할 것입니다. 아직 하나 둘 셋 있습니다. 그리고 여기 있는 서버가 몇 개인지 보여주세요. 아직 하나 둘 있습니다. 그래서 또 하나 둘 하나 둘 셋. 따라서 연결이 되지 않았습니다. 따라서 분할 뇌는 아직 복구되지 않았습니다. 이것이 여전히 부분적으로 연결되고 부분적으로 연결되고 클라이언트가 계속 작동하는 이유입니다.
괜찮아! 다시 가자. 다른 작업을 해보자. 아직 완료되지 않았습니다. 괜찮아! 여기로 가십시오. 97.. 어서! 괜찮아! 이제 다른 노드가 보이기 시작합니다. 82, 102, 122 그리고 97이 바로 여기에 있습니다. 하지만 아직까지는 부분적입니다. 이 중 두 개를 볼 필요가 있고 파티션과 복제본이 모두 표시되어야 합니다. 그렇기 때문에 아직 97과 통신할 수 없을 것입니다. 왜냐하면... 좋아! 이제 82, 102, 122, 97, 다시 XNUMX개의 노드가 여기에 복원됩니다. XNUMX개 모두.
여기로 가자. 이 하나. 어떻게든... 어서! 여기서 바꾸겠습니다. 따라서 82 대신 97이라고 하겠습니다. 이제 그렇게 하세요. 97도 XNUMX개의 노드(하나 둘 셋 넷 XNUMX)를 보여주고 있음을 알 수 있습니다. 괜찮아. 따라서 XNUMX개의 노드가 모두 다시 연결됩니다.
여기로 가겠습니다. 이 모니터를 다시 시작하겠습니다. 나는 여기에 다시 올 것이다. 이 캐시, 통계를 말하겠습니다. 나는 XNUMX명이 모두 일하고 있고 고객들이 그들과 이야기하고 있는 것을 보았다. 따라서 클라이언트가 XNUMX개 모두와 통신하고 있다는 사실은 클라이언트 연결도 자동으로 복원된다는 것을 의미합니다. 그리고 모니터는 여기에 XNUMX가지 모두를 보여줄 것입니다. 따라서 완전히 연결된 것을 볼 수 있듯이 XNUMX개의 노드가 모두 연결됩니다.
괜찮아! 이제 다른 하나님께로 가겠습니다. 내가 다른데 갔나? 이 하나. 괜찮아! 나는 괜찮은 통계라고 말할 것이다. XNUMX개 모두는 제가 여기 XNUMX개 모두와 이야기하고 있다는 것입니다. 보시다시피, 그들 모두에서 활동이 일어나고 있으며 여기서 XNUMX개 모두가 일어나고 있다는 것을 모니터할 것입니다.
결론
따라서 우리는 건강한 클러스터를 갖는 것에서 분할을 갖는 것으로부터 다시 건강한 클러스터를 갖는 것으로 이동했습니다. 그리고 여기에서도 XNUMX노드 클러스터가 있음을 알 수 있습니다. 자, 이것으로 데모가 거의 끝났습니다. 앞으로 가서 놀아주세요 NCache 분할 브레인 복구를 통해 고가용성 기능을 추가할 수 있습니다.