• Facebook
  • 트위터
  • 유튜브
  • 라인드인
  • RSS
  • 기술 문서
  • 비교
  • 블로그
  • 다운로드
  • 문의하기
다운로드
목차 표시/숨기기

Bridge를 통한 다중 사이트 복제

대규모 애플리케이션의 경우 분산 캐시를 사용하여 애플리케이션의 성능, 안정성 및 런타임 확장성을 향상시킵니다. 따라서 분산 캐시는 자연 재해부터 내부 하드웨어 재해 또는 소프트웨어 오류에 이르는 재해 복구 계획에서 매우 중요한 부분이 될 수 있습니다.

가장 많이 사용되는 재해 복구 계획은 다른 백업 사이트에 실시간 데이터를 복제하는 것입니다. 따라서 필요한 경우 오류 없이 실제 사용자를 백업 사이트로 리디렉션할 수 있습니다. 그러나 이를 위해서는 활성 캐시와 백업 캐시가 모두 항상 동기화되어 있는지 확인해야 합니다. 동기화되지 않으면 애플리케이션의 캐시 클라이언트에 영향을 미칠 수 있습니다.

NCache 이 기능은 브리지를 통해 다중 사이트 복제를 제공합니다. 여러 클러스터 캐시 사이에 브리지가 생성되고, 데이터는 해당 브리지를 통해 소스 사이트에서 다른 사이트로 복제됩니다.

재해 복구 계획이 있을 뿐만 아니라 지리적으로 분리된 지역에 광범위하게 분산된 고객을 위해 애플리케이션을 배포하려는 경우 데이터 복제도 문제를 해결합니다. 여기서 두 개 이상의 활성 사이트를 가질 수 있으며, 이는 관련 지역의 사용자를 처리하고 다른 지역 사이트의 백업으로 사용할 수도 있습니다.

원격 데이터 복제는 효과적이고 효율적인 데이터 보호와 주요 중단으로부터의 신속한 복구를 보장하기 위한 모든 계획의 중요한 구성 요소입니다. 데이터의 동기식 복제는 클러스터 내부적으로는 좋지만, 캐시 클러스터가 지리적으로 분리되어 있는 경우 성능에 미치는 영향이 중요한 고려 사항이 됩니다. 브리지는 재해 복구를 위해 WAN을 통해 온사이트 캐시에서 다른 온사이트/오프사이트 캐시로 데이터를 복제하는 시나리오를 위해 설계되었습니다. 비동기식 복제로 인해 활성 캐시에 연결된 모든 클라이언트는 전체 백업이 다른 캐시에 원활하게 수행되는 동안 활성 캐시에서 작업이 수행되고 있다는 인상을 받습니다.

소스 캐시에서 작업이 수행되면 해당 작업은 비동기적으로 브리지로 전달됩니다. 그런 다음 이 작업은 브리지가 관리하는 큐에 추가됩니다. 브리지가 대상 캐시를 사용 가능하고 작업을 수락할 준비가 되었다고 판단하면 큐에 있는 작업이 대상 캐시로 전송됩니다. 브리지를 통해 다음 사항이 보장됩니다.

  • 성능 저하가 없습니다.
  • 작업은 원래 캐시에서와 동일한 순서로 수행됩니다.
  • 연결 실패 시 작업이 손실되지 않습니다.

플러그형 캐싱 아키텍처: 캐시는 서로를 알지 못합니다. 단지 브리지에 대해서만 알고 있으며, 자신의 데이터를 브리지에 복제할 뿐입니다. 이러한 느슨한 결합 덕분에 다음과 같은 이점을 누릴 수 있습니다. 브리지를 구성하다 캐시 토폴로지와 관계없이 여러 캐시 간에 자유롭게 이동할 수 있습니다. 제거 브리지로 구성된 캐시.

데이터 무결성: 소스 캐시에서 수행된 작업은 브리지에 의해 큐에 추가되며, 소스 캐시에서 수행된 실제 순서를 유지합니다. 브리지는 대상 캐시에서도 동일한 순서로 작업을 수행합니다. 충돌은 대상 캐시에서 해결됩니다. 이러한 방식으로 캐시는 궁극적으로 일관성을 유지하게 됩니다.

전용 브리지 서비스: 브리지는 캐시 서비스와 마찬가지로 독립적인 전용 서비스이므로 네트워크 지연으로 인해 브리지 작업이 지연되더라도 캐시 작업에는 영향을 미치지 않습니다.

브리지 구성: 클러스터 캐시가 있는 서버와 동일한 서버에서 브리지를 구성하거나 별도의 서버 노드에 브리지를 생성할 수 있습니다. 그런 다음 클러스터 캐시를 브리지에 추가하면 데이터가 캐시 간에 복제됩니다.

재해 복구: 재해 복구를 위해 액티브 데이터 센터와 패시브 데이터 센터 간에 브리지를 구성할 수 있습니다.

지리적으로 분산된 고객을 관리하는 방법: 관련 지역 사용자를 대상으로 하는 두 개 이상의 활성 사이트를 운영할 수 있으며, 이러한 사이트는 다른 지역 사이트의 백업으로도 사용할 수 있습니다.

비동기 복제: 다중 사이트 복제의 경우, 브리지 작업 지연으로 인해 캐시 작업에 차질이 생기지 않도록 비동기 복제가 사용됩니다.

대기열 백업: 브리지는 여러 노드로 구성된 클러스터형 큐이며, 하나의 노드는 활성 상태이고 다른 노드는 비활성 상태입니다. 브리지에서 데이터 손실을 방지하기 위해 활성 큐의 백업 기능이 있습니다.

연결 재시도: 또한 이 브리지는 연결 실패가 발생할 경우 재시도를 통해 모든 작업을 복제하려고 시도합니다.

브리지 복제기 대기열: 브리지 리플리케이터 큐 크기는 캐시 크기에 포함됩니다. 캐시가 브리지에 연결할 수 없는 경우, 캐시가 가득 찰 때까지 작업이 캐시에 대기열에 추가됩니다. 캐시가 가득 차면 추가 작업을 위한 공간을 확보하기 위해 캐시 항목이 제거됩니다. 브리지 큐.

캐시 : 당신은 어떤을 사용할 수 있습니다 토폴로지 브리지의 일부가 될 클러스터 캐시에 대해 설정할 수 있습니다. 하나의 브리지 내에서 각 사이트에 서로 다른 토폴로지 캐시를 사용할 수도 있습니다. 하지만 양쪽에서 동일한 토폴로지를 사용하는 것이 강력히 권장됩니다.

다중 사이트 복제를 위한 캐시 동기화 모드

The NCache 브리지에는 여러 캐시가 연결되어 있을 수 있으며 재해 복구를 위해 캐시에 다음 동기화 모드를 제공할 수 있습니다.

  • 활성 캐시:
    활성 캐시는 모든 클라이언트가 연결하고 브리지를 통해 연결된 다른 캐시에 복제되는 읽기 및 쓰기 작업을 연결하고 수행하는 토폴로지일 수 있습니다.

  • 패시브 캐시:
    패시브 캐시는 어떤 토폴로지든 가능하지만 액티브 캐시와 동일한 것이 좋습니다. 그러나 액티브 캐시에서 수행된 모든 작업은 패시브 캐시에 복제됩니다. 클라이언트는 패시브 캐시에 연결하여 읽기 및 쓰기 작업을 모두 수행할 수 있지만 이러한 작업은 액티브 캐시에 복제되지 않습니다. 필요한 경우 패시브 캐시에서 수정을 수행할 수 있습니다.

  • 어떤 이유로든 활성 사이트가 다운되면 해당 사이트를 활성 사이트로 만들어 요청을 수동 사이트로 리디렉션할 수 있습니다. 귀하의 패시브 사이트는 활성 사이트로 작동하고 모든 요청을 오류 없이 처리합니다.

  • 이전 활성 사이트가 준비되고 다시 시작되면 이전과 같이 구성을 재구성할 수 있습니다. 두 사이트를 모두 활성화하면 이전 수동 사이트의 모든 데이터가 이전 활성 사이트로 전송됩니다. 모든 데이터가 전송되면 패시브 사이트를 구성하고 모든 요청을 액티브 사이트로 리디렉션할 수 있습니다.

패시브-액티브 브리지

  • 두 활성 캐시 간 통신의 경우 동일한 캐시 데이터가 두 캐시에서 거의 동시에 업데이트되어 충돌이 발생할 수 있습니다. 이 갈등을 해결하려면, NCache 를 제공합니다 구성 가능한 충돌 해결기 브리지 시간에 대한 작업 충돌을 해결합니다. 기본적으로 최신 작업이 "승리"되며 충돌이 발생할 경우 캐시에 적용됩니다.

  • 사이트가 다운되면 모든 요청을 다른 활성 사이트로 리디렉션할 수 있습니다. 다운된 사이트가 다시 가동되면 이미 실행 중인 사이트에서 이 사이트로 데이터가 전송되고 해당 지역의 요청을 이 사이트로 리디렉션할 수 있습니다.

주의 사항

문제 발생을 방지하기 위해 토폴로지를 제외한 나머지 구성은 캐시 간에 동일하게 설정하는 것이 좋습니다. 예를 들어, 한 캐시에 데이터 소스가 구성되어 있다면 다른 캐시에도 동일하게 구성해야 합니다. 이는 한 사이트 캐시의 운영 사양이 다른 사이트로 복제되기 때문입니다.

상태 전송을 통한 수동 데이터 동기화

소스 캐시의 상태를 대상 캐시와 동기화하려는 경우 두 캐시 간에 상태 전송을 수동으로 트리거할 수 있습니다. 이것은 다리를 통해 발생합니다.

상태 전송 작업은 캐시 끝에서 대기하고 브리지에 연결하자마자 브리지로 작업을 전송하기 시작하여 대상 캐시로 전달됩니다. 캐시 간 상태 전송이 시작되면 다른 상태 전송을 시작할 수 없습니다. 이는 시스템의 안정성을 보장하기 위한 것입니다.

사례 1: 상태 전송의 캐시가 발생합니다.
캐시 A와 캐시 B에 상태 전송이 진행 중인 경우 캐시 A는 다운되고 다시 돌아오지 않습니다. 브리지가 상태 전송 중이므로 다른 수신 상태 전송 요청이 거부될 수 있습니다. 이를 해결하기 위해 브리지는 지정된 간격 후에 캐시 A로부터 작업 수신을 중지했는지 지능적으로 결정합니다. 따라서 해당 상태 전송은 손상된 것으로 간주되며 브리지는 새로운 상태 전송 요청을 허용합니다.

사례 2: 캐시와 브리지에 네트워크 오류가 있지만 연결이 끊어지지 않음:
캐시와 브리지 연결에 네트워크 결함이 발생하여 부분적으로 연결되는 경우 작업 및 상태 전송 큐는 그대로 유지됩니다. 따라서 손실된 작업이 없으므로 상태 전송을 재개할 수 있습니다.

브리지 대기열

캐시 A는 활성 캐시인 반면 캐시 B는 수동 캐시입니다. 캐시 A는 브리지를 통해 캐시 B에 작업을 전송하지만 캐시 B는 한동안 다운됩니다. 이는 브리지 대기열이 캐시 A에서 전송되는 작업으로 채워지고 있지만 캐시 B가 중단되어도 대기열에서 제거되지 않음을 의미합니다. 브릿지 대기열이 완전히 채워지고 더 이상 작업을 저장할 공간이 없게 되는 지점이 올 것입니다. 따라서 캐시 A는 공간이 확보될 때까지 작업을 계속 유지하도록 지시합니다. 그런 다음 작업은 캐시 끝에서만 대기열에 추가됩니다. 캐시 B가 다시 작동하고 브리지 복제기 큐가 해당 캐시로 작업을 보내기 시작하여 큐에서 제거된다고 가정해 보겠습니다. 구성 가능한 공간(기본적으로 20MB)이 해제되면 브리지는 이제 대기열에 있는 작업을 보낼 수 있음을 캐시 A에 알립니다.

그러나 캐시 대기열이 가득 차고 제거가 활성화된 경우 캐시는 캐시된 항목을 제거하지만 대기 중인 작업은 제거하지 않습니다. 이것은 작업 손실을 방지합니다.

도 참조

캐시 토폴로지
동적 클러스터
로컬 캐시
NCache Client
클라이언트 캐시

문의하기

전화

+1 214-619-2601   (미국)

+44 20 7993 8327   (UK)

 
이메일

sales@alachisoft.com

support@alachisoft.com

NCache
  • 판 비교
  • NCache 아키텍처
  • 벤치 마크
다운로드
가격
놀이터를 사용해보십시오

배포
  • 클라우드(SaaS 및 소프트웨어)
  • 온 프레미스
  • Kubernetes
  • 도커
기술 사용 사례
  • ASP.NET 세션
  • ASP.NET 코어 세션
  • 게시/구독 메시징
  • 실시간 ASP.NET SignalR
  • 사물의 인터넷 IOT ()
  • NoSQL 데이터베이스
  • 스트림 처리
  • 마이크로 서비스
리소스
  • 잡지 기사
  • 제XNUMX자 기사
  • 기사
  • 비디오
  • 백서
  • 쇼
  • 회담
  • 블로그
  • 기술 문서
고객 사례 연구
  • 환자 후기
  • 고객
고객 지원
  • 데모 예약
  • 포럼(Google 그룹스)
  • Tips
회사
  • Leadership
  • 파트너
  • ​뉴스
  • 이벤트
  • 채용 정보
문의하기

  • 영어중국어 (간체)프랑스어독일 사람이탈리아 사람일본제한국어포르투갈어스페인어

  • 문의하기
  •  
  • 사이트 맵
  •  
  • 이용 약관
  •  
  • 개인정보 처리방침
© 저작권 Alachisoft 2002 - . 판권 소유. NCache 는 Diyatech Corp.의 등록상표입니다.
맨 위로