분할 및 분할 복제본 토폴로지
주의 사항
분할된 토폴로지는 다음에서도 지원됩니다. NCache Professional.
클러스터에서 모든 서버 노드에 동일한 데이터 복사본이 있으면 해당 데이터의 고가용성이 제공됩니다. 즉, 클러스터는 데이터 손실 없이 몇 가지 노드 오류에도 살아남을 수 있습니다. 그러나 이는 확장성을 제공하지 않습니다. 데이터가 엄청나게 증가하기 시작하면 복제 범위를 줄이고 데이터 분할을 시작하도록 설계해야 합니다.
파티셔닝은 읽기 및 쓰기 데이터 로드가 모두 분산되도록 여러 노드 간에 데이터를 분산해야 함을 의미합니다. 데이터가 증가함에 따라 클러스터에 더 많은 서버 노드를 추가하여 더 많은 데이터를 보관할 수 있습니다. 클러스터의 각 서버 노드를 파티션이라고 합니다.
데이터를 분할하면 확장성을 얻을 수 있지만 이제 문제는 해당 데이터를 어떻게 분할하느냐입니다. 간단한 해결책은 라운드 로빈 방식으로 파티션에 데이터를 할당하는 것입니다. 하지만 저장소에 추가된 특정 데이터 조각을 어떻게 찾을 수 있을까요?
라운드 로빈을 통해 데이터 위치를 추적하는 기능을 잃게 됩니다. 우리에게는 데이터의 균등한 배포뿐만 아니라 빠른 검색 능력을 보장하는 더 나은 데이터 배포 방법이 필요합니다.
주의 사항
Partitioned 토폴로지와 Partition-Replica 토폴로지의 유일한 차이점은 전자에는 복제본 캐시가 없기 때문에 데이터 손실이 발생하기 쉽다는 것입니다.
해시 기반 데이터 파티셔닝
NCache 데이터를 여러 청크로 나누고 이러한 청크를 서로 다른 파티션에 배치합니다. 이러한 청크를 버킷이라고 합니다. 클러스터의 노드 간에 균등하게 나누어지는 총 1000개의 버킷이 있습니다. 여기서 아이디어는 항목 키에 해시 함수를 적용하고 총 버킷 수(이 경우 1000)로 모드를 조정하여 이 데이터에 대한 소유자 버킷을 얻는 것입니다.
분포도
클러스터의 코디네이터 서버는 버킷 배포가 포함된 맵을 생성하는 역할을 합니다. 이 맵을 분포 맵이라고 합니다. 코디네이터 서버는 이 배포 맵을 클러스터의 나머지 파티션 및 연결된 클라이언트와 공유합니다. 이 방법은 클러스터의 서버 수에 관계없이 항상 항목에 대해 동일한 버킷 주소를 제공합니다. 버킷이 어떤 단계에서든 한 파티션에서 다른 파티션으로 이동할 수 있더라도 항목의 버킷은 절대 변경될 수 없습니다. 즉, 버킷이 이동하면 모든 데이터도 함께 이동됩니다.
분포도에 따른 데이터 분포
단일 파티션으로 캐시 클러스터를 시작하면 1000개의 모든 버킷이 이 노드에 할당됩니다. 즉, 모든 데이터가 이 파티션으로 이동합니다. 클러스터에서 다른 노드를 시작하면 각각 500개의 버킷이 있는 두 파티션 사이에 버킷이 균등하게 분배됩니다. 마찬가지로 클러스터에 세 번째 노드를 추가하면 버킷이 다시 redis공물. 이 경우 333개의 노드에는 각각 333, 334 및 XNUMX개의 버킷이 있습니다.
마찬가지로 파티션이 클러스터를 떠나면 버킷 분포가 변경됩니다. 예를 들어 파티션이 333노드 클러스터를 벗어나면 해당 파티션이 소유한 334 또는 XNUMX 버킷은 다음과 같습니다. redis나머지 두 노드 사이에 할당됩니다. 분포에 변화가 있을 때마다 버킷 분포에 따라 노드 간 데이터의 균형을 재조정하기 위해 상태 전송을 트리거합니다.
데이터의 무작위 분포
이 분할 방법은 데이터가 버킷과 파티션 간에 균등하게 분할되도록 상당한 양의 무작위성을 제공합니다. 그러나 이 분할 방법을 사용하면 어떤 데이터를 어떤 파티션에 할당해야 하는지 제어할 수 없습니다. 대부분의 경우 데이터가 어디로 가는지 신경 쓰지 않을 것입니다. 그러나 경우에 따라 관련 데이터를 같은 위치에 배치할 수도 있습니다. 이를 위해 전체 키 대신 키의 일부에 해시 함수가 적용되는 위치 친화성을 사용할 수 있습니다.
데이터의 균형 잡힌 배포
버킷이 있을 때마다 redis노드 사이에 공물, NCache 버킷이 redis각 파티션이 수신하는 데이터의 크기가 거의 동일하도록 할당됩니다. 각 파티션은 구성 가능한 간격으로 자신이 소유한 버킷의 통계를 클러스터의 다른 파티션과 공유합니다. 이는 필요할 때 각 파티션이 얻는 데이터 측면에서 공평한 균형 잡힌 분포 맵을 생성하는 데 도움이 됩니다. 밸런싱은 항목 수 대신 데이터 크기를 기준으로 이루어집니다. 이러한 균형은 일반적으로 버킷 시점에 보장됩니다. redis노드가 떠나거나 합류한 결과로 인한 분포.
자동 및 수동 데이터 로드 밸런싱
그러나 클러스터에서 하나 이상의 파티션이 왜곡되어 나머지 파티션보다 더 많은 로드를 수신할 가능성이 약간 있습니다. 이 경우 특정 노드의 데이터 균형을 수동으로 조정하여 해당 노드의 데이터가 각 파티션이 수신하는 데이터의 평균 크기와 같도록 하는 옵션이 있습니다. 그런 다음 백그라운드에서 자동으로 작업을 수행하는 '자동 데이터 로드 밸런싱'이라는 기능도 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다. 주의 없이 사용하면 버킷이 자주 발생할 수 있기 때문입니다. redis트리뷰션, 따라서 파티션 간에 원치 않는 상태가 전송됩니다.
파티션당 데이터 크기
각 파티션이 보유할 수 있는 데이터의 크기는 구성된 캐시 크기와 같습니다. 예를 들어 구성된 캐시 크기가 2GB이고 클러스터 크기가 6개의 파티션으로 구성된 경우 이 클러스터의 총 캐시 크기는 XNUMXGB입니다.
따라서 이 토폴로지를 사용하면 서버 간에 읽기 및 쓰기 로드를 분산할 뿐만 아니라 클러스터에 추가되는 모든 새 서버에 따라 용량도 증가합니다.
파티션-복제본
이제 Partition-Replica 토폴로지가 트랜잭션 로드 및 스토리지 용량을 확장하는 방법을 다루었습니다. 고가용성을 처리하는 방법에 대해 이야기해 보겠습니다. 클러스터의 각 노드에는 복제본이라는 수동 파티션 역할을 하는 다른 파티션의 백업이 있습니다. 노드 오류의 경우 캐시 클러스터는 손실된 파티션이 소유한 데이터가 복제본에서 계속 사용 가능하다는 것을 알고 있습니다. 따라서 손실된 파티션이 소유한 데이터가 이 복제본을 통해 클러스터에서 계속 제공되므로 클라이언트 애플리케이션은 계속 원활하게 실행됩니다.
클라이언트 응용 프로그램은 활성 파티션과만 직접 통신합니다. 그러면 각 파티션은 해당 데이터를 해당 복제본에 복제합니다.
이 토폴로지의 복제 수준은 복제된 토폴로지, 적어도 하나의 백업이 있으면 노드 오류가 발생하더라도 데이터가 여전히 안전하다는 것을 보장할 수 있습니다. 동시 노드 오류가 발생하지 않는 한 이 토폴로지의 데이터는 안전하며 대부분의 시나리오를 포괄합니다.
모든 클러스터 노드에는 활성 및 복제본이 있으며 활성 및 복제본 인스턴스는 모든 클러스터 노드의 동일한 캐시 프로세스에 존재합니다.
모든 캐시 노드에 복제본 인스턴스가 존재하기 때문에 활성 캐시 인스턴스와 동일한 메모리 크기가 필요합니다. 즉, 모든 파티션 복제본 캐시 노드에는 구성된 캐시 크기에 비해 두 배의 메모리가 필요합니다.
클라이언트가 추가한 모든 데이터는 활성 노드에 저장되며 여기에서 클러스터의 다른 노드에 있는 전용 복제본으로 복제됩니다. 이러한 복제 노드 배열은 활성 노드가 다운될 때 데이터가 손실되지 않도록 합니다.
복제본 선택 전략
NCache 노드가 캐시 클러스터에 합류하는 순서에 따라 복제본 노드를 자동으로 선택합니다. 첫 번째 노드의 복제본은 첫 번째 노드 이후에 클러스터에 합류한 서버 노드에 존재하는 식으로 계속됩니다. 그리고 마지막 노드의 복제본은 캐시 클러스터의 첫 번째 서버 노드(코디네이터 서버)에 배치됩니다.
이 전체 복제본 선택 프로세스는 자동입니다. 서버 노드가 캐시 클러스터를 떠나거나 새 노드가 캐시 클러스터에 합류할 때마다 업데이트된 멤버십 맵에 따라 복제본도 재할당됩니다.
단일 노드 메모리 소비
각 서버 노드(활성 및 복제본)는 구성된 캐시 크기의 기록을 유지하고 저장된 데이터가 지정된 메모리 제한을 초과하지 않도록 합니다. 이 메모리 제한 검사가 다르게 작동하는 두 가지 특별한 시나리오가 있습니다. 아래에 설명되어 있습니다.
- 노드 XNUMX개만 실행 중인 상태이며, 여기에 데이터가 추가되고 있습니다. 활성 캐시 인스턴스는 복제본이 쓸모가 없으므로 지정된 캐시 크기의 두 배를 사용하여 데이터를 보관할 수 있습니다.
- 다중 노드 클러스터에서 다른 모든 노드가 클러스터를 떠나고 하나의 노드만 활성 상태로 남아 있으면 복제본 캐시 인스턴스의 데이터가 활성 캐시 인스턴스로 전송됩니다. 그런 다음 복제본에서 받은 데이터를 수용하기 위해 활성 캐시에서 복제본의 여유 메모리를 사용합니다.
복제 전략
파티션-복제본 토폴로지에는 활성 서버 노드에서 복제본 노드로 데이터를 복제하는 두 가지 복제 전략이 있습니다.
비동기 복제: 이 모드에서는 클라이언트 작업을 차단하지 않고 데이터를 복제하는 데 백그라운드 큐가 사용됩니다. 모든 쓰기 작업이 대기열에 추가되고 전용 백그라운드 스레드가 이 대기열에서 데이터를 청크로 선택하여 복제본 인스턴스에 복제합니다. 이 복제 전략은 쓰기를 자주 수행하는 경향이 있지만 다음 캐시 작업 전에 복제가 완료될 때까지 기다리기를 원하지 않는 애플리케이션에 적합합니다. 그러나 노드가 갑자기 떠나면 데이터가 손실될 가능성이 있습니다. 이 경우 복제되지 않은 대기 작업은 손실됩니다.
동기화 복제: 동기 복제 모드를 사용하면 클라이언트의 모든 쓰기 작업이 클라이언트 애플리케이션에 제어를 반환하기 전에 복제본으로 복제됩니다. 이 복제 모드는 활성 캐시 인스턴스와 복제본 캐시 인스턴스가 사용자 데이터의 동일한 복사본을 갖도록 합니다. 복제본 인스턴스에서 복제가 실패하면 해당 항목이 활성 및 복제본 캐시 인스턴스에서 제거됩니다.
작업 동작
퇴거, 만료, 의존성, 쓰루/뒤에 쓰기등은 활성 노드에 의해 제어됩니다. 활성 노드가 언급된 기능을 기반으로 항목을 제거할 때마다 복제본에 복제하여 이전에 저장된 데이터를 제거합니다. 비슷하게, 쓰루/뒤에 쓰기 작업은 활성 캐시에서만 수행됩니다.
파티션-복제 토폴로지에서 클라이언트는 각 서버 노드와 직접 연결되지만 활성 파티션/인스턴스와만 연결됩니다. 그럼에도 불구하고 클라이언트가 클러스터 호출을 통해 일시적으로 복제본 인스턴스와 상호 작용하는 몇 가지 상황이 있습니다. 아래에 설명되어 있습니다.
- 상태 전송 중에 노드가 클러스터를 떠날 때 떠나는 노드를 위한 클라이언트 작업은 해당 복제본에서 제공됩니다.
- 클러스터가 유지 관리 모드에 있으면 유지 관리 중인 노드에 대한 모든 작업은 유지 관리 기간 동안 해당 복제본에서 제공됩니다.
국가 이전
상태 전송은 캐시 노드 간에 데이터를 자동 전송/복사하는 프로세스입니다. 상태 전송은 새 노드가 클러스터에 합류하거나 현재 노드가 클러스터를 떠날 때 트리거됩니다. 노드 탈퇴/가입은 클러스터의 구성원 자격도 변경합니다.
노드가 업데이트된 정보를 수신할 때 분포도, 로컬 환경에 할당된 버킷이 있는지 확인합니다. 노드의 로컬 환경에 존재하지 않는 할당된 버킷은 다른 노드에서 하나씩 가져옵니다. 따라서 캐시 클러스터의 서버 노드 수에 따라 상태 전송 중에 여러 버킷이 전송됩니다.
상태 이전은 다음 세 가지 주요 시나리오에서 트리거됩니다.
노드 조인 시
새 노드가 캐시 클러스터에 가입하면 코디네이터 서버는 새 배포 맵을 생성하여 현재 노드에서 새로 가입한 노드로 버킷을 배포합니다. 그리고, 분포 맵을 받은 후 새로 합류한 노드는 현재 노드에서 버킷을 가져옵니다. 이 상태 전송 중에 새로 조인된 노드는 한 번에 하나의 버킷을 가져옵니다. 하나의 버킷을 수신한 후 분포 맵에 따라 다른 노드에서 할당된 모든 버킷을 가져올 때까지 다음 버킷을 가져옵니다.
노드 이탈 시
마찬가지로 캐시 노드가 캐시 클러스터를 떠날 때 상태 전송이 트리거됩니다. 코디네이터 서버 redis클러스터의 활성 노드 간에 버킷을 제공합니다. 이 경우 활성 노드는 떠나는 노드의 복제본에서 데이터를 가져옵니다.
주의 사항
이미 상태 전송이 진행 중인 상태에서 둘 이상의 노드가 동시에 또는 하나씩 클러스터를 떠나면 데이터 손실이 발생할 수 있습니다.
자동 데이터 로드 밸런싱에서
파티션 복제본 토폴로지에는 다음과 같은 기능이 있습니다. 자동 데이터 로드 밸런싱 클러스터 노드 간의 데이터 분포를 지속적으로 모니터링합니다. 그리고 데이터 분포가 예상 분포 범위(60~40%)를 벗어나면 자동으로 자동 데이터 로드 밸런싱이 실행됩니다. 이 경우 코디네이터 서버는 새로운 분포 맵을 재생성하고 redis모든 클러스터 노드가 동일한 크기의 데이터를 갖도록 버킷을 제공합니다.
주의 사항
데이터 로드 밸런싱도 수행할 수 있습니다. 수동으로 인사말 NCache 관리센터.
상태 이전의 이유가 무엇이든 이 전체 프로세스는 자동으로 원활하게 진행됩니다. 그리고 상태 전송 중, 특히 서버 노드가 캐시 클러스터를 떠날 때 떠나는 노드를 대상으로 했던 모든 클라이언트 작업은 클러스터 작업을 통해 해당 복제본에서 제공됩니다.
또한 복제본은 다른 활성 노드와 마찬가지로 활성 노드에서 상태 전송을 수행합니다. 복제본은 활성 노드에서 할당된 버킷을 가져와 상태 전송 시 데이터 복사본을 가져옵니다. 그러나 이 상태 전송은 버킷 재할당 시에만 발생합니다. 그렇지 않으면 데이터가 복제 메커니즘을 통해 복제본에 복제됩니다.
상태 전송을 모니터링하는 다양한 방법
NCache 캐시 클러스터에서 상태 전송을 모니터링하는 여러 방법을 제공합니다. 아래에 설명되어 있습니다.
- 캐시 로그: 상태 전송이 트리거되고 중지될 때마다 클러스터의 캐시 로그에 기록됩니다. 캐시 로그는 다음 위치에 있습니다. %NCHOME%/bin/로그 폴더에 있습니다.
- 맞춤 카운터: NCache 또한 Windows 및 Linux에서 볼 수 있는 사용자 지정 카운터를 게시합니다.
- 성능 기반 카운터: Windows의 경우, NCache 또한 Windows Perfmon 도구를 통해 상태 전송 카운터를 게시합니다.
- Windows 이벤트 로그: 상태 전송 관련 정보/이벤트는 Windows 이벤트 로그에도 게시됩니다.
- 이메일 알림 : 상태 전송 관련 이메일 알림은 시작 및 중단 시 구성될 수 있습니다.
클라이언트 연결
파티셔닝에서 설명한 것처럼 데이터는 클러스터의 모든 서버에 분산됩니다. 다른 토폴로지와 달리 분할된 토폴로지용 클라이언트는 각 파티션에 전체 데이터의 하위 집합이 포함된 모든 파티션과 연결해야 합니다.
클라이언트는 연결 호출에서 배포 맵을 수신하여 클라이언트에게 실행 중인 서버 노드와 해당 노드에 대해 교육합니다. 해시 기반 배포. 클라이언트는 모든 서버 노드에 연결하여 캐시에서 완전한 데이터를 가져옵니다. 클라이언트는 업데이트된 지도 연결을 유지하기 위해 모든 클러스터 구성원이 변경될 때마다. 클라이언트는 또한 회원 탈퇴/가입에 대한 알림을 수신하고 수신된 내용에 따라 연결을 재설정합니다. 지도.
클라이언트는 키가 포함된 서버 노드에서 직접 읽기/쓰기 작업을 지능적으로 수행합니다. 해시 기반 분포 맵 그것은 받는다. 다음과 같이 키를 알 수 없는 모든 작업에 대해 SQL 검색, GetByTags등을 통해 클라이언트는 요청을 모든 서버 노드에 브로드캐스팅하고 각각의 응답을 결합합니다.
어떤 경우든 클라이언트가 클러스터의 서버 노드에 연결하지 못한다고 해서 해당 서버 노드에서 정보를 쓰고 검색하는 데 실패하는 것은 아닙니다. 이를 위해 연결된 다른 서버 노드를 사용하며, 대신 연결할 수 없는 서버 노드가 작업을 수행하도록 요청합니다. 예를 들어, 클라이언트가 node1과의 연결에 실패하고 node1에 있는 키를 얻으려는 경우 node2로 요청을 보내고 node1는 nodeXNUMX로 다시 라우팅하고 응답을 반환합니다.
유지 관리 모드
하드웨어/소프트웨어 패치 또는 업그레이드가 필요한 경우 NCache 서버에서는 애플리케이션 다운타임이 발생하지 않을 수 있습니다. 그러나 캐시 노드를 중지하면 국가 이전 전체 캐시 클러스터 내에서 네트워크, CPU 및 메모리와 같은 리소스를 과도하게 사용합니다. 이것 국가 이전 캐시 데이터 및 클러스터의 크기에 따라 프로세스 비용이 많이 들 수 있습니다. 일반적인 업그레이드 작업 흐름에는 한 번에 캐시 노드를 다시 시작하는 작업이 포함되며, 이를 위해서는 두 가지 상태 전송(노드 탈퇴 시 하나, 노드 가입 시 하나)이 필요합니다.
유지 관리 모드 캐시 서버 유지 관리 중에 비용이 많이 드는 상태 전송을 방지하기 위해 도입되었습니다. 지정된 시간 동안 유지 관리를 위해 캐시 서버가 중지되면 유지 관리 중인 노드의 복제본이 일시적으로 활성화되어 클라이언트 요청을 받기 시작합니다. 유지보수 중이던 노드가 지정된 시간 내에 유지보수가 종료된 후 재가입하는 경우, 국가 이전 캐시 클러스터와 동기화하기 위해 이 노드에 대해 시작됩니다.
클러스터가 종료됩니다. 유지 관리 모드 세 가지 다른 주에서. 유지 관리 노드가 지정된 시간 내에 캐시 클러스터에 합류하면 국가 이전 클러스터 상태를 동기화하기 위해 시작되고 클러스터는 종료됩니다. 유지 관리 모드. 유지 관리 노드가 지정된 시간 내에 캐시 클러스터에 다시 참여하지 못하면 클러스터는 해당 노드가 다운된 것으로 간주하고 클러스터를 종료합니다. 유지 관리 모드, 새로운 생성 지도, 그리고 시작합니다 국가 이전. 성공과 실패 외에 또 하나의 변칙이 존재한다. 유지 관리 모드즉, 노드가 떠날 때입니다. 클러스터가 유지 관리 모드 유지 관리 노드를 제외한 모든 노드가 떠나면 클러스터도 종료됩니다. 유지 관리 모드, 데이터가 손실될 수 있습니다.
스플릿 브레인 복구
용어 스플릿 브레인 하나의 캐시 클러스터가 여러 개의 하위 클러스터로 분할된 상태를 나타냅니다. 클러스터의 캐시 서버는 TCP를 통해 통신합니다. 따라서 네트워크 결함이나 문제로 인해 클러스터에 있는 서버 간의 통신이 끊길 수 있습니다. 서버간 통신 단절이 일정 시간 이상 지속되는 경우, 서버간 연결에 따라 멤버십 맵이 변경됩니다. 그 결과 여러 하위 클러스터가 형성됩니다. 이러한 하위 클러스터를 분할이라고 합니다. 우리는 그것을 호출 분할 뇌 하위 클러스터는 서로 통신할 수 없기 때문에 분할 뇌 증후군에서 뇌의 반쪽이 서로 통신할 수 없는 것과 유사합니다.
모든 하위 클러스터가 정상이며 포함된 데이터를 처리합니다. 또한 클라이언트는 추가 읽기/쓰기 작업을 위해 이러한 하위 클러스터에 연결할 수 있습니다. 클라이언트는 클러스터 서버로부터 멤버십 맵을 수신하여 연결을 업데이트합니다. 여기서 클라이언트는 수신된 첫 번째 맵에 따라 모든 하위 클러스터에 연결할 수 있습니다.
스플릿 브레인 서버 간 통신이 재개될 때만 감지되고 모든 서버가 작동 중이지만 단일 클러스터의 일부가 아닌 것으로 감지됩니다. 서버 간의 통신 손실에 따라 둘 이상의 분할이 가능합니다. 한번 분할 뇌 감지되면 복구 프로세스가 시작됩니다. 모든 분할은 모든 하위 클러스터가 병합될 때까지 하나씩 복구됩니다.
XNUMXD덴탈의 분할 뇌 복구 프로세스는 감지 직후에 시작됩니다. 두 번의 정상 분할이 필요하고 코디네이터 서버를 식별하고 클러스터 크기를 기준으로 승자와 패자 분할을 결정하고 패자 분할에 대한 잠금을 획득하여 해당 클러스터의 클라이언트 활동을 제한하고 클러스터 멤버십을 변경합니다. 이후 모든 클라이언트는 승자 클러스터 분할로 리디렉션되고 패자 분할의 모든 노드는 승자 클러스터에 합류하기 위해 하나씩 다시 시작됩니다. 모든 패자 분할은 동일한 방식으로 승자 클러스터 분할과 병합되고 클러스터는 다시 정상 상태가 됩니다.
에 데이터 손실이 예상됩니다. 분할 뇌 클러스터가 여러 하위 클러스터로 분할될 때 복구할 때 클러스터의 여러 노드가 동시에 떠나기 때문에 데이터 손실이 발생합니다. 하위 클러스터는 다음 상태에서 클라이언트 요청을 수용할 수 있습니다. 분할 뇌, 클라이언트가 연결된 스플릿이 주 클러스터에 합류하기 위해 다시 시작되는 패자 스플릿인 경우 이러한 작업이 손실될 수 있습니다.