오늘날의 애플리케이션은 트랜잭션이 많으며 로드 밸런싱된 다중 서버 배포에서 실행하여 높은 트랜잭션에 맞게 확장할 수 있습니다. 동시에 이러한 애플리케이션 중 다수는 여러 데이터 센터에서 실행되어야 합니다. 이것은 하나의 활성 데이터 센터가 일반적으로 다른 지리적 위치에 있는 패시브 데이터 센터로 재해 복구를 갖는 재해 복구를 위해 수행될 수 있습니다. 또 다른 이유는 이 애플리케이션의 사용자가 지리적으로 분산되어 있으면 해당 지역의 자체 데이터 센터에 동시에 액세스하므로 응답 시간이 더 빨라지기 때문입니다.
NCache 세부 정보 WAN 복제용 브리지 NCache 기술 문서
캐시는 데이터베이스와 마찬가지로 WAN 복제가 필요합니다.
여러 데이터 센터에서 애플리케이션을 실행하는 경우 캐시를 복제해야 합니다. 이는 캐시가 일시적인 데이터를 유지하고 캐시가 다운되면 데이터가 손실되기 때문입니다. 임시 데이터는 ASP.NET 세션, 응용 프로그램에서 생성된 임의 데이터 또는 집계 데이터일 수 있습니다. 그러나 임시 데이터는 영구적이지 않으므로 데이터베이스에 저장되지 않고 캐시만 됩니다.
기타 데이터 NCache 성능상의 이유로 유지하는 것은 응용 프로그램 데이터입니다. 이 데이터가 손실되면 데이터베이스에서 다시 로드되어 성능이 저하됩니다. 많은 기업이 높은 애플리케이션 트래픽으로 인해 이를 처리하기를 원하지 않습니다.. 그렇기 때문에 다중 데이터 센터 배포가 있는 경우 응용 프로그램 데이터도 WAN을 통해 복제되어야 합니다.
NCache 세부 정보 WAN 복제 NCache 기술 문서
해결 방법 : NCache 브리지를 통한 WAN 복제
위의 상황에 대처하기 위해, NCache 브리지를 통한 WAN 복제 기능을 제공합니다. 이렇게 하면 배포할 수 있습니다. NCache 활성-수동, 활성-활성, 3개 이상의 데이터 센터 활성-활성 구성으로 여러 데이터 센터에 걸쳐 있습니다.
2사이트 액티브-패시브
능동-수동 구성에서, NCache 활성 사이트와 수동 사이트 모두에 배포되어 활성 사이트에 브리지 토폴로지를 생성합니다. 그림 1은 능동-수동 구성에서 이것이 어떻게 배치되는지 보여줍니다. 모든 애플리케이션 업데이트는 활성 사이트의 캐시에서 브리지로 전송되며 브리지는 비동기식으로 밀리초 내에 수동 사이트로 전송합니다. 여기서 유일한 지연은 데이터 센터가 멀리 떨어져 있는 경우 데이터 센터 간의 대기 시간입니다. 따라서 비동기 대기열 매커니즘이 있는 브리지 토폴로지를 사용하면 오버플로 없이 이러한 모든 업데이트가 발생할 수 있습니다.
NCache 세부 정보 캐시 동기화 모드 NCache 기술 문서
2사이트 활성-활성
또 다른 구성은 NCache 지원은 두 사이트가 모두 활성인 활성-활성입니다. 하나는 캐시 및 브리지 토폴로지를 보유하고 다른 하나는 캐시만 보유합니다. 그림 2는 이것이 어떻게 수행되는지 보여줍니다. 활성-수동과 유사하게 활성-활성에서 캐시는 업데이트를 브리지로 보내고 브리지는 이를 다른 캐시로 보냅니다. 그러나 이제는 차이가 있습니다. 동일한 항목이 양쪽에서 동시에 업데이트되면 충돌이 발생할 수 있습니다. 이는 브리지가 각 활성 사이트의 캐시 성능에 부정적인 영향을 주지 않도록 두 사이트의 업데이트를 조정하고 비동기적으로 충돌을 해결해야 함을 의미합니다.
NCache 세부 정보 다중 데이터 센터 WAN 복제 NCache 기술 문서
3+ 사이트 활성-활성
세 번째 상황에는 3개 이상의 활성 데이터 센터가 있습니다. 여기서 활성 사이트 중 하나에는 캐시와 브리지가 있고 다른 모든 사이트에는 캐시만 있습니다. 즉, 브리지는 사이트 중 하나에 대해 로컬이지만 다른 두 사이트는 브리지에 원격으로 액세스합니다. 활성-활성 시나리오와 유사하게 이 3+ 활성-활성 시나리오에서 모든 캐시는 브리지에 업데이트를 보내고 브리지는 연결된 모든 캐시에 업데이트를 전파합니다. 동시에 캐시에서 업데이트된 동일한 데이터가 데이터 무결성 위반을 일으키지 않도록 충돌 해결을 수행합니다.
NCache 세부 정보 브리지 토폴로지 NCache 기술 문서
그림 3은 XNUMX개의 활성-활성 데이터 센터를 보여줍니다. NCache 매우 매끄럽고 비동기적인 캐시 복제가 가능합니다. 애플리케이션 코드 변경 없음. 애플리케이션은 캐시가 복제되고 있다는 사실조차 알지 못하지만 데이터 센터의 WAN을 통해 비동기식으로 복제됩니다.
병렬 및 대량 비동기 WAN 복제
캐시에 대한 모든 업데이트는 비동기식입니다. 비동기식인 이유는 여러 데이터 센터 간의 거리 때문입니다. 이 거리는 대기 시간으로 인해 성능이 저하될 수 있습니다. 애플리케이션이 동일한 데이터 센터에 캐싱되면 서버 간 액세스 시간이 매우 빨라집니다. 그러나 WAN에서는 일반적으로 매우 느립니다. 따라서 비동기식 업데이트를 수행하지 않으면 업데이트 요청을 하는 사람은 업데이트가 완료될 때까지 기다려야 합니다. 즉, 동기식 업데이트로 인해 애플리케이션 속도가 느려집니다.
그러나 비동기식 복제는 각 사이트의 애플리케이션과 캐시가 해당 데이터가 다른 데이터 센터에 복제될 때까지 기다리지 않는다는 것을 의미합니다. 데이터는 다리. 브리지 자체는 모든 캐시의 모든 업데이트 요청을 대기시키는 XNUMX노드 클러스터입니다. 능동-수동의 경우 요청은 대기중인 활성 캐시에서만 사용하고 수동 캐시에는 비동기적으로 적용됩니다. XNUMX개 이상의 데이터 센터가 있는 경우 브리지는 업데이트를 여러 활성 사이트에 병렬로 적용합니다.
또한 브리지는 대량 업데이트를 수행합니다. 즉, 여러 데이터 항목을 단일 요청으로 결합하고 다른 사이트에 단일 대량 요청으로 보낼 수 있으므로 네트워크 이동이 크게 줄어듭니다. 따라서 이 강력한 병렬, 대량 및 비동기 복제 조합은 여러 데이터 센터에서 캐시를 복제하면서 성능을 향상시킵니다.
NCache 세부 정보 WAN 복제 토폴로지 NCache 기술 문서
갈등 해결
활성 사이트가 여러 개인 경우 각 사이트에서 동일한 데이터를 동시에 업데이트할 수 있습니다. 로컬 컴퓨터가 현지 시간대와 동기화되어 있는지 확인하십시오. 물론 동시에 갱신하지 않아도 문제는 없다. T1 시간에 항목 1을 업데이트하고 T2 시간에 항목 2를 업데이트한다고 가정합니다. T2 시간의 업데이트가 적용된 마지막 업데이트입니다. 그러나 두 업데이트가 동시에 발생하면 다리 두 가지 방법 중 하나로 갈등을 해결해야 합니다.
-
기본 "마지막 업데이트 승리" 논리: 브리지는 각 캐시에서 타임스탬프를 자동으로 검색하고 모든 캐시는 시계가 동기화되어 동일한 시간을 갖습니다. 브리지는 각 캐시에서 업데이트 시간을 수신하고 최신 업데이트가 모든 캐시에 적용됩니다. 다시 말하지만, 충돌 해결의 목적은 데이터 무결성 문제를 피하기 위해 모든 캐시에 동일한 버전 업데이트를 적용하는 것입니다.
-
충돌 해결 핸들러: 브리지가 충돌을 해결하는 또 다른 방법은 업데이트 분석을 위한 논리에 따라 충돌 해결 처리기를 제공할 수 있다는 것입니다. 이 리졸버는 NCache, 브리지는 개체의 두 복사본을 모두 제공하고 리졸버는 제공된 논리에 따라 어떤 버전이 더 나은지 분석합니다. 이렇게 하면 최종 버전이 브리지로 반환되고 이 업데이트가 모든 캐시에 적용됩니다.
다음 코드 조각은 캐시에 배포되는 충돌 해결 프로그램 구현의 샘플을 제공합니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public class Resolver : IBridgeConflictResolver { public void Init(System.Collections.IDictionary parameters) {. . .} public ConflictResolution Resolve(ProviderBridgeItem oldEntry, ProviderBridgeItem newEntry) { var conflictResolution = new ConflictResolution(); switch (oldEntry.BridgeItemVersion) { case BridgeItemVersion.OLD: { /* Replace item with new entry */ } break; case BridgeItemVersion.LATEST: { /* Keep old entry */ } break; case BridgeItemVersion.SAME: { /* Your logic to replace entry if needed */ } break; } return conflictResolution; // Configure this implementation on cache } public void Dispose() {. . .} } |
따라서 분쟁 해결 메커니즘을 NCache, 캐시가 동기화되지 않을 것이라고 확신합니다. 서로 다른 두 가지 버전의 데이터 업데이트는 없으며 여러 데이터 센터에서 항상 일관성을 유지합니다.
런타임 시 재해 처리
이제 한 사이트가 다운되는 재난 상황이 발생하면 어떻게 되는지 이야기해 봅시다.
능동 수동
사례 1: 패시브 사이트가 다운됨
능동-수동 구성은 재해 복구 사이트 역할을 합니다. 따라서 패시브 측이 다운되더라도 액티브 측은 계속 작동하고 애플리케이션은 계속 실행됩니다. 수동 사이트를 복원하기 위해 개입할 때까지 브리지는 수동 사이트에 데이터를 복제할 수 없습니다. 패시브 사이트를 되돌리면 브리지에 다시 연결되고 재동기화되므로 기존 캐시가 삭제되고 브리지를 통해 액티브 사이트 캐시의 전체 복사본을 효율적으로 가져옵니다. 동기화가 완료되면 일반 WAN 복제 모드로 전환됩니다.
NCache 세부 정보 동기화 브리지 캐시 액티브-패시브 캐시
사례 2: 활성 사이트가 다운됨
활성 사이트가 다운되면 브리지가 다운되고 응용 프로그램이 다운될 수 있기 때문에 일종의 재해가 발생했음을 의미합니다. 이제 모든 트래픽을 패시브 사이트 이제 활성화됩니다. 모든 데이터는 사용자 중단 없이 원래 활성 사이트에서 원래 수동 사이트로 복제됩니다. 원래 패시브 사이트는 이제 활성 상태이므로 모든 업데이트가 여기에서 발생하지만 사용자에게는 중단이 표시되지 않습니다.
그러나 원래 활성 사이트가 다시 가동되면 새로운 활성 사이트(원래 수동 사이트)에 연결되고 동기화 완전히. 동기화가 완료되면 모든 트래픽이 원래 수동 사이트로 이동하더라도 둘 다 활성-활성입니다. 모든 트래픽을 원래 활성 사이트로 오프로드하고 브리지에서 활성-활성 사이트의 상태를 다시 수동으로 변경할 수 있는 유연성이 있습니다. NCache 활성-수동 재해의 경우 중단 없이 런타임에 이 모든 작업을 수행할 수 있습니다.
액티브-액티브
브리지가 있는 활성 사이트가 다운되면 브리지가 다운되기 때문에 WAN 복제가 중지됩니다. 그러나 다른 활성 사이트는 계속 작동하며 모든 트래픽은 해당 사이트로 라우팅됩니다. 다운 사이트를 가동하면 브리지를 시작하고 활성 사이트를 브리지에 연결할 수 있으므로 두 사이트가 동기화됩니다. 이 작업은 모두 런타임에 수행되므로 다운타임이 필요하지 않습니다. 브리지가 동기화되면 두 사이트가 서로에게 업데이트를 푸시할 수 있습니다. NCache 따라서 내결함성을 제공합니다.
NCache 세부 정보 캐시 동기화 모드 NCache 기술 문서
활성 사이트 3개 이상
세 번째 상황은 한 사이트에는 브리지가 있고 다른 사이트에는 없는 활성 사이트가 3개 이상 있는 경우입니다. 이 경우 언급한 대로 두 가지 시나리오가 발생할 수 있습니다.
사례 1: 브리지가 아닌 활성 사이트가 다운됨
이 경우 다른 사이트는 서로를 계속 복제하고 이 사이트의 트래픽은 사용자를 방해하지 않고 연결된 다른 사이트로 다시 라우팅됩니다. 사이트가 가동되면 브리지에 다시 연결하고 재동기화하여 캐시의 최신 복사본을 가져옵니다. 이것은 트래픽을 정상화하라는 신호입니다.
NCache 세부 정보 캐시 동기화 모드 변경 브리지 토폴로지
사례 2: 브리지가 있는 활성 사이트가 다운됨
브리지가 작동하지 않는 경우 다른 두 활성 사이트는 계속 작동하지만 브리지가 없기 때문에 업데이트를 서로 복제할 수 없습니다. 따라서 현재 할 수 있는 작업은 다른 두 활성 사이트 중 하나에서 브리지를 시작하는 것입니다.
브리지를 시작하려면 하나의 노드로 두 개의 노드가 필요합니다. 클러스터. 이상적으로는 다음을 위한 전용 서버 집합이 있어야 합니다. 브리지 토폴로지 해당 사이트에 있지만 일시적일 가능성이 높으므로 두 개의 캐시 서버를 클러스터로 사용할 수도 있습니다. 그러나 이제는 브리지가 CPU 및 메모리와 같은 리소스도 소비하기 때문에 해당 캐시 서버의 성능에 약간의 영향을 미칠 수 있습니다.
당신은해야 다리를 시작하다 두 활성 사이트가 이미 실행 중인 활성 사이트 중 하나에서. 실행 중인 캐시는 이제 브리지에 연결할 수 있습니다. 따라서 둘 다 브리지에 연결하고 모든 업데이트를 서로 복제하여 동기화합니다. 두 사이트가 동기화되고 서로 업데이트를 전파하므로 사용자는 중단을 경험하지 않습니다. 따라서 사이트가 다운되더라도 데이터가 손실되지 않습니다.
NCache 세부 정보 클러스터된 캐시 추가 교량 관리
이제 브리지가 있는 원래 사이트가 복구되면 다음과 같이 간단하게 수행할 수 있습니다.
- 임시 사이트에서 다리를 내립니다.
- 다리 제거 기존 캐시에서.
- 다리를 원래 위치에 올리십시오.
- 모든 캐시를 이 새 브리지에 연결합니다.
런타임에 캐시를 브리지에 연결할 수 있으므로 NCache 스크립팅을 통해 이 모든 작업을 자동화할 수 있으므로 브리지 사이트가 다운되어 다시 복구해야 하는 상황을 원활하게 처리할 수 있습니다.
결론
NCache 다양한 고급 시나리오를 처리할 수 있는 강력한 WAN 복제 메커니즘을 제공합니다. 또한 빠르고 효율적인 방식으로 WAN 복제를 수행하고 활성-수동, 활성-활성 또는 XNUMX개 이상의 활성-활성 데이터 센터를 처리합니다.