다중 데이터 센터 배포를 위한 WAN 복제 NCache

녹화된 웨비나
론 후세인(Ron Hussain)과 잭 칸(Zack Khan)

이 웨비나는 당신이 알아야 할 모든 것을 보여줄 것입니다. NCache 데이터 센터 간 캐시의 WAN 복제를 위한 브리지 기능.

이 웨비나에서 다루는 내용은 다음과 같습니다.

NCache의 WAN 복제를 위한 브리지 기능
NCache 브리지 토폴로지(능동-능동, 능동-수동, 3개 이상의 능동-능동 데이터 센터)
고급 브리지 기능:
- 고가용성 및 장애 조치 연결
- 동적 충돌 해결사
- 병렬 및 대량 비동기 복제
- 대기열 최적화
대기열 다중 사이트 세션 기능
브리지 성능/디버깅 모니터링 옵션

오늘의 웨비나 주제는 다음을 사용하는 다중 데이터 센터 배포를 위한 WAN 복제입니다. NCache. 오늘 웨비나에서 다룰 내용은 NCache의 브릿지 기능입니다. 또한 다음을 포함합니다. NCache의 브리지 토폴로지, 고급 브리지 기능 NCache 다중 사이트 세션을 대기열에 넣고 브리지 성능 및 디버깅 모니터링 옵션을 제공합니다.

오늘 우리는 매우 중요한 주제를 정리했습니다. 특히, 여러 데이터 센터에 배포된 애플리케이션의 경우. 여러 가지 이유가 있을 수 있습니다. 예를 들어 DR 사이트가 필요하거나 활성-활성 다중 데이터 센터 배포가 필요하거나 필요한 데이터의 동쪽에서 서쪽으로 마이그레이션이 필요할 수 있습니다.

그래서, 우리는 WAN 복제 기능 브리지 토폴로지의 도움으로 사용할 수 있으며 모든 세부 사항을 다룰 것입니다. WAN 복제가 켜져 있는 동안 개체 캐싱을 사용하는 방법. 활성-수동, 활성-활성 및 다중 활성-활성 데이터 센터 배포에 사용합니다. 그래서 우리는 덮을 것이 많습니다. 모든 사람이 내 화면을 보고 잘 들을 수 있다고 믿습니다. GoTo Meeting 질문 및 답변 탭을 통해 빠른 확인을 받을 수 있다면 정말 좋을 텐데 빠르게 프레젠테이션을 시작하겠습니다. 따라서 모든 사람이 우리 화면을 볼 수 있고 문제 없이 여기 있는지 확인하십시오.

장점 소개 NCache

따라서 다음과 같은 분산 캐싱 시스템이 필요한 이유에 대한 매우 기본적인 정보부터 시작하겠습니다. NCache? 따라서 일반적으로 문제를 허용하는 것은 애플리케이션 성능 및 확장성 병목 현상으로 인해 애플리케이션이 더 빠르고 안정적인 방식으로 수행되도록 제한합니다.

애플리케이션 계층은 확장성이 뛰어납니다. 웹 애플리케이션 또는 백엔드 애플리케이션을 가질 수 있습니다. 애플리케이션을 여러 서버에 배포할 수 있는 웹 팜 또는 애플리케이션 서버 팜을 언제든지 생성할 수 있습니다. 부하를 분산할 수 있습니다. 여러 서버는 이러한 모든 응용 프로그램 요청을 서로 조합하여 병렬로 처리하는 데 도움이 되지만 이러한 모든 응용 프로그램은 백엔드 데이터베이스와 통신해야 하며 일반적으로 이것이 경합의 원인입니다. 데이터베이스 서버와 매우 값비싼 리소스를 확장할 수 없기 때문에 데이터베이스는 애플리케이션의 성능 및 확장성 병목 현상이 됩니다. 따라서 항상 확장할 수 있지만 데이터베이스 서버를 확장할 수 있는 범위에는 제한이 있습니까? NoSQL 응용 프로그램을 다시 설계해야 하기 때문에 일반적으로 이에 대한 답이 아닙니다. 관계형 데이터베이스 사용을 중단하고 사용을 시작해야 합니다. NoSQL 그것을 사용하기 위한 데이터 소스와 우리는 또한 NosDB 이는 인 NoSQL database 하지만 분산 캐싱 시스템을 통해 이를 처리하는 다른 방법을 계획하고 있습니다.

따라서 우선 이 확장성 문제에 대한 솔루션은 메모리 내 분산 캐싱 시스템을 사용하기 시작하는 매우 간단합니다. 디스크에 비해 인메모리이기 때문에 매우 빠릅니다. 따라서 플러그인을 설치하는 즉시 애플리케이션의 성능이 향상될 것입니다. NCache.

둘째, 서버 팀입니다. 캐시 클러스터입니다. 데이터베이스와 같은 단일 소스가 아닙니다. 캐시 클러스터에 여러 서버가 가입되어 있습니다. 따라서 추가하도록 선택할 수 있는 많은 서버에서 풀링되는 논리적 스토리지입니다. 따라서 관계형 데이터베이스에 비해 확장성이 뛰어납니다. 2개의 서버로 시작할 수 있으며 런타임에 더 많은 서버를 추가할 수 있습니다. 따라서 더 많은 서버를 추가할 수 있고 결과적으로 요청 처리 용량을 계속해서 늘릴 수 있는 선형 확장성을 제공합니다. NCache. 좋은 점 NCache 관계형 데이터베이스인 백엔드 데이터베이스와 함께 사용한다는 것입니다. 백엔드 데이터베이스에서 가져온 데이터 사용을 보완하는 많은 기능이 있습니다. 그래서, 당신은 항상 사용할 수 있습니다 NCache 관계형 데이터베이스와 함께. 관계형 데이터 원본을 대체하지 않습니다. 일부 확장성 수치.

NCache 더 많은 서버를 추가함에 따라 매우 확장 가능합니다. NCache 점점 더 많은 요청을 처리할 수 있습니다. NCache 무리. 최근에 QA 환경에서 이러한 테스트를 수행했습니다. 우리는 계속해서 부하를 늘리고 계속해서 더 많은 서버와 최대 5개의 서버를 추가하는 AWS 랩을 사용합니다. NCache 분산 캐시에 대한 매우 일반적인 구성입니다. 우리는 초당 2만 요청을 달성할 수 있었고 이는 서버를 추가할 때마다 캐시 클러스터에 더 많은 용량을 추가하는 증가 추세였습니다. 평균 1킬로바이트 개체 크기를 사용하면 이러한 성능을 기대할 수 있습니다. NCache 더 나은 하드웨어를 사용하면 이러한 숫자를 늘릴 수 있고 더 나은 성능 처리량을 얻을 수 있습니다. NCache. 참고로 이 벤치마크에는 백서 및 비디오 우리 웹 사이트에도 게시 된 데모. 따라서, 당신은 또한 그것을 볼 수 있습니다.

일부 배포 세부 정보. 일반적인 배포 방법은 NCache 처럼 보일 것입니다.

다음은 단일 사이트 배포입니다. NCache. 보시다시피, 우리는 단일 사이트를 보유하고 있으며 귀하의 경우 WAN 복제 측면에 대해 이야기하고 있습니다. 분명히 우리는 별도의 데이터 센터가 있는 둘 이상의 배포가 있을 것이며 여기에도 NCache 및 배포된 애플리케이션.

따라서 다이어그램에 표시된 것처럼 분산 캐시 배포를 사용하여 일반적인 배포가 어떻게 보이는지 이야기해 보겠습니다. 그래서 우리는 다시 서버 팀을 갖게 되었습니다. 다이어그램에 4~5개의 서버가 표시되어 있습니다. 캐시 클러스터가 호스팅되는 곳이며 보시다시피 애플리케이션과 데이터베이스 사이에 있습니다. 여기서 아이디어는 개체 캐싱의 경우 이러한 소스를 서로 조합하여 사용하지만 세션 캐싱의 경우 캐시가 주요 데이터 소스가 된다는 것입니다. 따라서 모든 세션을 다음 위치에 저장할 수 있습니다. NCache 그리고 당신은 다른 곳으로 갈 필요가 없습니다. 매우 유연한 배포 모델을 사용할 수 있습니다. NCache 온프레미스에서 호스팅할 수 있습니다. 물리적 또는 가상 상자일 수 있습니다. 클라우드에서도 가능합니다. 퍼블릭 또는 프라이빗 클라우드일 수 있습니다. Azure AWS에도 있을 수 있습니다. 이 두 클라우드 공급업체에서 사용할 수 있는 마켓플레이스 이미지가 있기 때문입니다. 그러나 일반적으로 Windows 또는 Linux가 있고 전제 조건이 있는 모든 서버는 NCache .NET 또는 .NET Core 뼈대. 따라서 이것들은 전제 조건입니다. 그것은 단지 .NET이고 .NET Core 어느 NCache 전제 조건으로 필요합니다. 그것이 가능하다면, NCache Windows 및 Linux 환경에 배포하기에 매우 유연하며 모든 환경에서도 가능하다고 말했듯이 Docker를 사용할 수 있고 호스트할 수도 있습니다. NCache Kubernetes 클러스터에서 다른 많은 플랫폼을 엽니다. OpenShift에서 사용할 수 있습니다. Azure Kubernetes 서비스에서 사용할 수 있습니다. Elastic Kubernetes 서비스도 알고 있습니다. 따라서 플랫폼이 모두 갖추어져 있고 NCache 이러한 모든 플랫폼에 배포할 수 있습니다.

두 가지 배포 옵션이 있습니다. 하나는 다이어그램에 표시된 대로 전용 캐시 계층을 사용하고 두 번째 계층은 전용 캐시 계층으로 이동하며 전용에서는 애플리케이션이 별도의 상자에서 실행되고 NCache 별도의 전용 계층에서 실행됩니다. 우리는 또한 공유 계층을 가지고 있으며 접근 방식도 사용할 수 있습니다. NCache 신청서 상자 옆에. 따라서 애플리케이션이 호스팅되는 모든 곳에서 NCache 그 위에 호스팅 될 수 있습니다. 그래서 저는 이것이 매우 간단하다고 믿습니다. 다중 데이터 센터 배포에서는 둘 이상의 데이터 센터가 있고 동일한 배포가 있습니다. NCache 다음 슬라이드에서 다룰 다른 데이터 센터에도 있습니다. 질문이 있는 경우 질문 및 답변 탭에 언제든지 해당 질문을 게시할 수 있습니다. Zack과 저는 계속 게시될 모든 질문에 주의를 기울이면 모든 질문에 기꺼이 답변해 드리겠습니다. 질문에 대해 말하자면, 당신이 방금 언급한 이후로 제가 꺼내고 싶은 것이 있습니다. 지금 Kubernetes를 언급하는 것은 매우 간단하다는 것입니다. 따라서 문제는 브리지에 대해 이야기할 것이고 일반적으로 이 모든 것에 대한 운영 체제 요구 사항이 있습니까? 이것을 Linux에서 실행할 수 있습니까? 전적으로. NCache 매우 유연합니다. 보시다시피 배포 다이어그램에서도 볼 수 있습니다. 너는 볼 수있어 NCache Windows 및 Linux 서버에서 지원됩니다. 따라서 Linux 서버에서는 .NET Core 방출 NCache 이를 위한 서버와 클라이언트가 있습니다. 따라서 달리고 싶다면 NCache Linux의 .NET 서버 .NET Core 그것이 가능하며 귀하의 애플리케이션은 항상 당사의 .NET Core Linux뿐만 아니라 Windows에도 배포하고 배포할 수 있습니다. 대박. 나머지는 실제로 진행하도록 하고 나중에 질문을 제기하겠습니다.

다중 데이터 센터 배포 NCache

따라서 다음은 다중 데이터 센터 배포에 대해 설명하겠습니다. NCache. 이제 애플리케이션이 여러 데이터 센터에 배포된 경우 또는 하나의 활성 사이트가 있고 DR 시나리오를 위한 수동 사이트가 있을 수 있습니다. 예를 들어, 활성 사이트가 다운되고 애플리케이션은 항상 가동되어 실행되어야 합니다. 미션 크리티컬 애플리케이션이라면 비즈니스에 중요합니다. 사이트 수준에서 다운타임이 발생하면 비즈니스에 영향을 미칠 수 있습니다.

NCache 클러스터는 이미 고가용성 및 데이터 안정성 기능을 갖춘 방식으로 설계되었습니다. 따라서 단일 사이트 수준에서 하나 또는 두 개의 서버가 다운되는 경우(예: 서버를 분실한 경우) NCache 문제 없이 해당 중단을 처리할 수 있습니다. 하지만 오늘은 사이트 수준 중단이 발생하면 어떻게 됩니까? 또는 유지 관리를 위해 사이트 전체를 다운시켜야 합니다. 그래서 모든 서버가 다운되었습니다. NCache 은(는) 해당 시나리오를 처리할 수 있는 장비도 갖추고 있으며 오늘 다룰 계획입니다. 그렇다면 WAN 복제가 필요한 이유에 대해 이야기해 보겠습니다.

일반적으로 애플리케이션에 고가용성이 필요한 경우 단일 사이트가 단일 실패 지점이 될 수 있습니다. 사이트가 다운되면 모든 데이터가 손실되고 잠재적으로 애플리케이션 사용자에게 다운타임이 발생하여 비즈니스에 영향을 미칠 수 있다는 사실을 이미 확인했습니다. 다중 지역 앱은 WAN을 통해 서로 통신해야 하는 경우 속도가 느립니다. 예를 들어, 하나의 데이터 센터가 배포되어 있고 애플리케이션이 미국 지역에 있는 하나의 데이터 센터에 배포된 다음 유럽 또는 기타 아시아 지역(예: 아시아 지역)에 배포된 다른 애플리케이션이 있습니다. 따라서 이 경우 응용 프로그램 데이터베이스가 데이터 센터 중 하나에 있는 경우 원격 사이트는 네트워크를 통해 이동해야 합니다. 따라서 네트워크 속도는 다른 사이트의 대기 시간에 영향을 미칩니다. 해당 시나리오를 처리하기 위해 일반적으로 WAN을 통해 데이터 원본을 복제하며 이것이 우리가 권장하는 것입니다. NCache 뿐만 아니라, 그 NCache 복제해야 합니다. 그러나 공통 데이터 소스가 있다는 점을 고려할 때 원격 사이트는 WAN을 통해 이동해야 하며 데이터가 해당 사이트의 로컬 데이터가 아니기 때문에 잠재적으로 성능에 영향을 줄 수 있으며 데이터 센터 간의 거리도 처리량에 영향을 미칠 수 있습니다. . 사이트 간에 전송할 수 있는 데이터가 너무 많습니다. 따라서 요청 처리 용량을 제한할 수 있습니다.

따라서 다중 지역 앱이 있고 두 앱이 모두 활성 상태인 경우 이 두 가지 문제가 발생합니다. 요청 수준에서 데이터 복제도 비용이 많이 듭니다. 예를 들어 전체 데이터베이스를 복제하지 않고 하나의 데이터 센터에 데이터 원본이 있습니다. 이제 원격 위치, 원격 지리적 위치에서 데이터베이스로 이동하는 요청입니다. 모든 데이터에 대한 요청 수준 복제, 즉 우리 데이터 소스에 오는 요청 단위는 매우 비용이 많이 들고 많은 대역폭과 리소스를 소모하게 됩니다. 따라서 로컬에서 사용할 수 있는 데이터가 있고 캐시의 WAN 복제가 필수로 필요한 활성 메커니즘이 필요합니다. 따라서 한 데이터 센터의 데이터가 네트워크를 통해 다른 사이트로 복제됩니다.

일부 사용 사례. 정확히 어디에서 WAN 복제를 사용할 수 있습니까?

우리가 접하는 가장 일반적인 것은 재해 복구 사이트입니다. 주요 비즈니스 사용 사례를 제공하는 활성 사이트가 있습니다. 트래픽이 생성되고 처리되는 곳입니다. 사이트 전체가 다운된다면? 대체 옵션이 필요합니다. 맞습니다. 따라서 해당 DR 사이트에는 이미 사용 가능한 데이터가 있어야 합니다. 그렇지 않으면 이미 다운된 사이트로 돌아가야 하는 경우 데이터 요구 사항이 처리되지 않습니다. 따라서 DR 사이트에서 사용할 수 있는 데이터가 필요하므로 이미 가동되어 실행 중입니다. 트래픽을 해당 DR 사이트로 이동하기만 하면 됩니다. 다른 작업은 하지 말고 트래픽을 재해 복구 사이트로 라우팅하기만 하면 활성 사이트에서와 동일한 성능 값, 동일한 성능 매트릭스로 작동해야 합니다. 따라서 장애 발생시 100% 데이터 복구가 가능합니다. NCache WAN 복제.

다중 지역 응용 프로그램은 로드뿐만 아니라 데이터를 공유할 수 있습니다. 이제 Active-Active 사이트를 사용하여 미국에 한 지역이 있고 유럽이나 아시아와 같이 세계의 다른 지역에 지역이 있는 경우. 원하는 경우 위치 선호도에 따라 데이터 센터를 처리해야 하는 요청을 달성할 수 있습니다. 이제 아시아의 사용자는 해당 지역 내에서 해당 지역과 가장 가까운 사이트에 연결할 수 있으며 그곳에서도 캐시를 사용할 수 있으며 해당 캐시는 미국 지역에 있는 다른 캐시와 동기화됩니다. 따라서 반송되는 모든 사용자. 예를 들어 오버플로를 관리하거나 용량을 분산해야 합니다. 일부 사용자는 이제 아시아 지역이 완전히 막혀서 미국 지역으로 바운스해야 하므로 항상 그렇게 할 수 있습니다. 따라서 사이트 수준에서 해당 시점과 해당 시점에서 사이트가 처리하는 용량을 기반으로 요청의 로드 밸런싱을 수행할 수 있습니다. 캐시 데이터는 이미 여러 데이터 센터에 복제되어 있으므로 이를 달성하는 방법에 대해 설명하겠습니다. 따라서 다중 지역 애플리케이션은 효율적으로 애플리케이션 데이터를 공유하고 요청 로드를 공유할 수 있으며 동일한 로드 공유도 가질 수 있습니다. . 중복 데이터 마이그레이션은 수행되지 않습니다. 한 데이터 센터에서 다른 데이터 센터로 수신 거부되는 요청을 기반으로 하며 이미 연결된 캐시에서 해당 데이터를 항상 가져올 수 있습니다.

동쪽에서 서쪽으로의 애플리케이션 데이터 마이그레이션은 또 다른 사용 사례입니다. 예를 들어 아시아 시장은 서양 시장보다 일찍 시작합니다. 따라서 데이터 추세는 일반적으로 동쪽에서 서쪽으로 따릅니다. 따라서 동부 사이트는 캐시를 설정할 수 있으며 시간대에 따라 데이터 센터 간에 데이터가 서부 지역으로 이동하고 서부 지역에 도달할 수 있습니다. 따라서 데이터 센터 간에 복제된 데이터가 있는 경우 캐시 데이터인 서부 지역은 동부 지역에서 제공되는 모든 데이터를 활용할 수 있습니다. 따라서 동쪽에서 서쪽으로의 데이터 마이그레이션을 사용할 수 있으며 유지 관리 사용 사례는 세 번째 사례입니다.

넷째, 다운타임 없이 업그레이드를 배포하고 유지 관리할 수 있습니다. 이는 매우 시급한 사용 사례가 되고 있습니다. NCache 또한. 즉, 업그레이드할 계획이라면 브리지 토폴로지를 사용하여 이전 버전과 최신 버전 간에 업그레이드할 수 있습니다. 이전 데이터의 경우 라이브 업그레이드 기능을 사용하여 버전 데이터를 최신 버전으로 전송할 수 있습니다. 사이트 간에 있을 수 있습니다. 예를 들어 한 사이트를 사용하고 수동 사이트에 능동적으로 데이터를 복제할 수 있으며 활성 사이트에서 업그레이드, 새 코드 배포, 성능 유지, 유지 관리를 수행할 수 있으며 모든 데이터를 사용할 수 있으며 트래픽은 해당 문제에 대해 수동 사이트로 라우팅될 수 있습니다. 따라서 두 사이트 모두 가동 중지 시간과 애플리케이션 데이터 손실 없이 항상 가동 및 실행될 수 있습니다.

NCache WAN 복제용 브리지

그럼 대처법에 대해 알아볼까요? 기능의 이름은 NCache 다리. 동일한 제품의 일부입니다. 별도의 설치가 필요하지 않습니다. NCache Enterprise 갖추고있다 NCache 브리지 토폴로지 그리고 그것에 대해 이야기합시다.

그래서 우리의 캐시는 NCache 브리지 기능을 사용하면 데이터 센터 간에 캐시를 복제할 수 있습니다.

비동기 복제 모델을 기반으로 합니다. 애플리케이션 측면에서 성능 저하를 일으키지 않습니다. 캐시 응용 프로그램은 한 데이터 센터의 캐시에 활성 상태로 연결되어 있습니다. 예를 들어 여기에 클라이언트가 있는 경우 활성-수동 대기열이기도 하고 다른 사이트에 비동기적으로 데이터를 전송하는 브리지를 생성할 수 있습니다.

따라서 비동기 복제를 기반으로 하므로 데이터 복제 시 성능 저하가 없습니다. 그것은 매우 신뢰할 수 있습니다. 내결함성입니다. 연결 실패를 자동으로 감지합니다. 자동으로 다시 연결됩니다. 자동 재시도 옵션을 사용할 수 있으므로 브리지도 활성-수동 대기열에 백업됩니다.

따라서 Active Bridge 서버가 있고 Passive Bridge 서버도 있습니다. Active Bridge 서버가 다운되면 Passive는 지연 없이 모든 복제 작업을 선택하고 시작합니다. 설정이 매우 쉽고 코드 변경이 필요하지 않으며 추가 설치가 필요하지 않습니다. 동일한 제품인 Enterprise의 일부이며 동일한 제품에 통합된 자체 모니터링 및 관리 지원을 제공합니다. NCache Enterprise 이 제품은 다음에 다루게 될 여러 토폴로지를 지원합니다.

따라서 세 가지 주요 토폴로지가 있습니다.

액티브-패시브가 있습니다. 활성 사이트가 있는 경우 수동 사이트가 있습니다. 수동 사이트도 클라이언트 요청을 받지만 데이터 흐름은 활성에서 수동으로 진행됩니다. 따라서 DR 사이트 요구 사항이 있는 경우 한 사이트를 활성으로 사용하고 브리지에 연결한 다음 다른 사이트를 수동으로 사용할 수 있습니다. 능동 사이트는 수동 사이트로 데이터를 전송합니다. 따라서 단방향 전송입니다. 패시브라는 용어는 본질적으로 패시브 사이트가 데이터를 액티브로 다시 전송하지 않는다는 것을 의미합니다. 여전히 실행 중이며 클라이언트 응용 프로그램에서 이를 활용하고 있습니다. 따라서 그것은 어떤 방법으로든 중단된 것이 아닙니다. 능동 수동으로 동쪽에서 서쪽으로 마이그레이션할 수 있습니다. 활성-수동의 도움으로 유지 관리 및 업그레이드 사용 사례를 처리할 수 있습니다.

활성-활성 토폴로지는 두 개의 서로 다른 지리적 위치에 하나의 애플리케이션을 배포하고 사이트 1의 데이터를 사이트 2에서 사용 가능하게 만들고 사이트 2의 데이터를 사이트 1에서 사용할 수 있도록 하려는 경우입니다. 지리적 사이트의 경우 두 데이터 센터에서 활성 사용자가 있는 활성-활성을 타겟팅할 수 있습니다. 클라이언트가 두 데이터 센터에 모두 연결되어 있고 두 개의 서로 다른 사이트 간에 양방향 복제가 진행 중이며 3, 2+ 또는 3+ 활성-활성 토폴로지가 있습니다. 여기서 하나의 기본 입찰 서버가 있지만 모든 사이트에 데이터를 전송합니다. 사이트와 해당 사이트는 또한 다른 모든 사이트로 데이터를 다시 전송하고 있습니다. 따라서 모든 데이터 센터에 하나의 업데이트를 적용해야 하며 그 반대의 경우도 마찬가지입니다.

자, 여기 우리의 능동-수동이 있습니다.

여기에는 능동-수동이기도 한 대기열인 브리지가 있습니다. 사이트 1에는 클라이언트 요청을 처리하는 캐시 클러스터가 있습니다. 여기에 3개의 서버가 있습니다. 다리와 연결되어 있습니다. Bridge도 사이트 중 하나에 있습니다. 또는 경우에 따라 사이트 1에 활성 브리지가 있고 사이트 2에 수동 브리지 서버가 있을 수 있습니다. 또한 가능하지만 일반적으로 배포 아키텍처의 사이트 중 하나에서 브리지를 이동하는 것이 좋습니다. 두 번째 사이트는 수동 사이트이고 다시 수동 사이트는 여전히 실행 중입니다. 수동 사이트가 활성 사이트에 데이터를 다시 복제하지 않는다는 것입니다. 이는 데이터의 단방향 전송이며 이것이 수동 사이트라고 말할 때 의미하는 전부입니다. 기본적으로 여기에서 클라이언트 응용 프로그램을 실행할 수 있으며 이 상태에서도 완전히 작동합니다. 따라서 데이터 복제, 능동 수동이므로 이 서버가 다운되면 수동이 활성화되고 자동입니다. 코드 변경이 필요하지 않습니다. 실습 부분으로 넘어가면 브리지를 구성하는 방법을 보여 드리겠습니다. 아주 간단합니다.

질문이 들어왔는데 이 능동-수동과 관련이 있습니다. 주로 능동 사이트와 수동 사이트가 있는 경우 수동 사이트를 어떻게 활성화합니까? 수동 프로세스입니까? 사이트가 중지 되었습니까? 어떻게 합니까? 자, 그렇다면 이 질문을 올바르게 이해했다면 우리가 그것을 활성화하는 방법의 측면에서 수동적 사이트는 무엇입니까? 이미 활성화되어 있습니다. 실행 중이며 이 사이트를 중단하거나 트래픽을 여기로 이동하려는 경우 이 사이트로 이동해야 하는 것은 애플리케이션 트래픽 로드입니다. 따라서 여기에 응용 프로그램 서버가 있고 여기에 응용 프로그램 서버가 있습니다. 여러분이 가진 모든 데이터가 여기로 전송될 것이며 이 사이트 사용자는 캐시 자체에서 데이터를 사용할 수 있도록 할 수 있습니다. 이제 트래픽을 항상 수동 사이트로 라우팅할 수 있으며 모든 데이터를 사용할 수 있습니다. 따라서 활성화하기 위해 필요한 단계가 없습니다. 그러나 이 사이트가 활성 사이트로 데이터 전송을 다시 시작하도록 하려면 GUI 도구를 사용하여 활성 사이트로 만들 수 있습니다. 따라서 복제 측면에서 데이터를 활성 상태로 다시 복제하려는 경우 항상 활성 상태로 만들 수 있으며 이것이 런타임 프로세스입니다. 따라서 GUI 도구에서 한 번의 클릭으로 한 줄의 작업을 수행하거나 PowerShell 도구를 사용하여 이를 수행할 수 있습니다. 그러나 귀하의 질문이 수동 노드를 활성화하는 것과 관련이 있는 경우. 클라이언트 응용 프로그램을 연결하고 데이터를 사용할 수 있도록 하기 위한 수동 단계가 있는 경우 이미 실행 중인 것입니다. 이 캐시 클러스터로 트래픽 라우팅을 시작하면 애플리케이션에서 이를 사용하기 시작합니다. 따라서 로드 밸런서 내에서. 이 사이트를 끄고 모든 트래픽을 사용 가능한 사이트로 라우팅합니다. 이 사이트는 이미 가동되어 복제되고 있는 모든 데이터를 얻거나 이용할 수 있습니다.

그래서, 능동-능동, 그것은 다시 같은 원리에 기초합니다. 사이트 중 하나에 다리가 있는 곳입니다.

캐시 1, 캐시 2가 있습니다. 두 사이트 모두 활성 상태이며 수동 토폴로지도 마우스 오른쪽 버튼을 클릭하여 활성 상태로 만들 수 있습니다. 이 경우 사이트 1 캐시의 데이터가 캐시에서 브리지로 비동기식으로 사이트 2로 전송됩니다. 브리지에서 캐시로 이동한 다음 마찬가지로 사이트 2도 사이트 1로 데이터를 다시 전송합니다.

3개 이상의 활성-활성 데이터 센터, 세 개 이상의 활성-활성이 있고 사이트 중 하나가 브리지 서버로 있는 경우. 브리지에 대한 대체 사이트를 가질 수도 있습니다. 우리는 백업 브리지 사이트도 가질 수 있습니다. 그러나 일반적으로 호스팅하는 사이트 중 하나가 브리지를 호스팅하고 해당 사이트가 다른 사이트로 데이터를 전송하고 유사하게 사이트 2는 브리지를 통해 사이트 1과 사이트 3으로 데이터를 전송합니다. 그리고 활성의 경우 -활성, 시간 기반 충돌 해결이 있으므로 마지막 업데이트가 승리합니다. 우리가 사용하는 모든 데이터 구조는 충돌이 없습니다. 이들은 충돌이 없는 데이터 유형입니다. 마지막 업데이트가 보드 전체의 캐시 클러스터에 적용될 것이기 때문에 경쟁 조건이나 데이터 일관성 문제가 없습니다. 그래서, NCache 동일한 키에 대한 두 개의 업데이트가 들어오는지 관리합니다. NCache 이를 평가하고 요구 사항인 경우 자체 충돌 해결을 구축할 수도 있습니다. 따라서 NCache 토폴로지.

브리지 구성을 간단히 살펴보겠습니다.

우리는이 NCache 브리지 구성. NCache Bridge가 이름이고 Londo가 있습니다.nCache 환경 1, 따라서 동일한 이름을 가진 여러 캐시도 가질 수 있습니다. NewYorkCache와 이것들이 연결되어 있습니다.

실습 데모 NCache

이제 실제로 이 모든 것을 실제로 보여 드리겠습니다. 브리지를 구성하는 방법은 무엇입니까? 시작하는 방법과 개체 캐싱 및 세션 캐싱 응용 프로그램을 실제로 보여 드리겠습니다. Ron에 대해 알아보기 전에 이전 슬라이드에서 코드와 함께 질문을 받았는데, 그 질문은 브리지를 설정하기 위해 관련된 코드 변경 사항이 무엇입니까? 브리지를 통해 데이터를 복제하려면 코드를 작성해야 합니까? 전혀. 우리는 어떤 코드도 필요하지 않습니다. 그냥 구성입니다. 따라서 데이터 센터 1에 캐시 1이 있고 데이터 센터 2에 캐시 2가 있습니다. 브리지와 애플리케이션에서 이미 추가하고 있는 데이터를 구성하기만 하면 됩니다. NCache, 브리지를 통해 자동으로 복제됩니다. 따라서 모든 복제를 담당하는 것은 브리지의 책임입니다. 데이터 센터 간에 데이터를 복제하기 위해 명시적으로 코드를 작성할 필요가 없습니다. 데이터 유형, 충돌 해결은 기본적으로 구현되는 것이기도 합니다. 이는 시간 기반이지만 직접 구현하려는 경우 충돌 해결, 비즈니스 요구 사항이 개체를 평가하는 것이라면 여러 업데이트가 들어오는 경우 해당 인터페이스를 구현할 수 있습니다. 그러나 데이터 복제에 관한 한 브리지의 책임입니다. 이를 위해 코드를 작성할 필요가 없습니다.

캐시 생성

자, 빨리 시작하겠습니다. 캐시를 생성.

예를 들어 site1cache의 이름을 지정하거나 바로 여기에서 SiteOneCache를 실제로 사용하도록 하겠습니다. 이것은 빠르게 시작하고 브리지를 생성할 수 있는 방법에 대한 아이디어를 제공하기 위한 것입니다. 모든 것을 기본값으로 유지하겠습니다. NCache 아키텍처는 이러한 모든 세부 사항을 다룹니다.

그래서, 나는 그것들을 빠르게 살펴볼 것입니다. 복제본 캐시의 파티션, 모든 클러스터. 토폴로지 비동기 복제. 저는 101번을 선택하고 102번을 선택할 수 있는지 보겠습니다. 가능한 경우. 이것은 브리지를 호스팅하는 두 대의 서버입니다. 이 기본값을 모두 유지하겠습니다. 이것을 시작하고 자동 시작도 시작하십시오. 마치다. 따라서 내 캐시 101은 102과 XNUMX에 있으며 생성될 예정입니다. 어떻게 진행되는지 보겠습니다. 그런 다음 별도의 서버 세트에 있는 또 다른 캐시를 만든 다음 브리지를 호스팅하고 이 모든 것이 어떻게 작동하는지 보여드리겠습니다. 오른쪽. 따라서 SiteOneCache가 완전히 구성되었습니다. 보시다시피 시작되었습니다.

이제 실제로 생성하여 SiteTwoCache라는 다른 캐시를 생성하겠습니다. 나는 그것을 사용할 수 있다고 생각합니다. 예전에 가지고 놀았거든요. 모든 것을 단순하게 유지하고 이번에는 별도의 서버 세트를 제공하여 이를 완전히 별도의 사이트로 나타내도록 하겠습니다. 모든 것을 기본값으로 유지하고 우리의 브리지를 사용하면 모든 사이트를 원격으로 관리할 수 있으며 관리 및 통화 도구를 통해 하나의 중앙 위치에서 브리지와 함께 모든 사이트를 실제로 관리할 수 있습니다. 따라서 네트워크에 액세스할 수 있는 경우. SiteOne과 SiteTwo 사이에 사용 가능한 WAN 링크가 있으면 기본적으로 모든 것을 관리할 수 있습니다. 그래서 여기에 SiteTwoCache가 있습니다. 바로 여기에 SiteOneCache가 있습니다. 101 102는 SiteOneCache를 나타냅니다. 107 및 108은 SiteTwoCache를 나타냅니다. 지금, 그리고 이것들도 시작되었습니다.

통계를 클릭하면 아직 여기에 추가된 개체가 없음을 알 수 있습니다. SiteOneCache 또는 SiteTwoCache에는 데이터가 추가되지 않으므로 좋습니다. 나는 단순히 이것을 실행할 것입니다. 이 카운터를 검토할 수 있는 권한 문제가 있는 것 같습니다. 나는 할 수 있다고 생각합니다. 따라서 아직 사용할 수 있는 항목이 없음을 알 수 있습니다. 이제 브리지를 사용하여 이 두 캐시를 연결하겠습니다. 브리지는 다음에 구성할 것입니다.