NCache 아키텍처
오늘은 에 대해 이야기해보겠습니다. NCache 건축물. NCache .NET 및 Java 애플리케이션을 위한 메모리 내 분산 저장소입니다. 매우 빠르고 확장성이 뛰어납니다. 또한 트랜잭션이 많은 서버 애플리케이션에서 이를 사용하여 애플리케이션 성능과 확장성을 높일 수 있습니다.
일반적인 용도 NCache
분산 캐시
두 가지 일반적인 방법 NCache 사용됩니다. 번호 1은 다음과 같습니다. 분산 캐시 값비싼 데이터베이스 이동을 줄이기 위해 애플리케이션 데이터를 캐시하는 곳, 그리고 두 번째는 메시징 및 스트림 플랫폼입니다. 아키텍처에 들어가기 전에 두 가지에 대해 간략하게 살펴보겠습니다.
-
앱 데이터 캐싱
따라서 분산 캐시에서 애플리케이션 데이터 캐싱은 다음을 사용한다는 것을 의미합니다. NCache API는 일반적으로 애플리케이션 데이터를 캐시하기 위한 용도로 사용됩니다. 캐시가 데이터베이스보다 훨씬 빠르기 때문에 데이터베이스를 자주 사용할 필요가 없습니다. 또한 메모리에 저장되어 확장성이 뛰어나고 빠릅니다. 애플리케이션과 가까이 위치하여 속도가 빠르고, 분산되어 있어 확장성이 뛰어납니다. .NET 애플리케이션에서 EF Core를 사용하는 경우 다음을 사용할 수 있습니다. NCache EF Core를 통해서도, NHibernate와 EF 6을 통해서도 가능합니다. Java 애플리케이션이 있는 경우 다음을 사용할 수 있습니다. NCache Hibernate Second Level Cache로 사용할 수도 있고, Spring Cache로 사용할 수도 있으며, JCache를 기반으로 프로그래밍할 수도 있습니다. -
웹 앱 캐싱
분산 캐시 사용의 두 번째 부분은 웹 애플리케이션이 있는 경우 다음을 저장할 수 있다는 것입니다. 세션 NCache 그런 다음 NCache 이러한 세션을 여러 서버에 복제하므로 하나가 있는 경우 NCache 서버가 다운되더라도 데이터 손실은 없으며, 이러한 세션은 분산 저장소이기 때문에 확장성이 매우 뛰어나고 속도 또한 매우 빠릅니다. 또한 .NET, Java, Nodejs 등 모든 언어에서 멀티 사이트 세션 기능을 사용할 수 있습니다. 예를 들어, .NET 6의 경우 ASP.NET Core 애플리케이션은 세션 외에도 자체 데이터를 저장할 수 있습니다. 응답 캐시 NCache 그리고, 그들은 또한 사용할 수 있습니다 NCache 로 SignalR용 백플레인SignalR은 웹 앱이 클라이언트에 이벤트를 전송해야 하는 라이브 웹 애플리케이션을 위한 것입니다. .NET 4.8을 사용하는 경우 세션 상태도 저장할 수 있습니다. 상태 보기, 출력 캐시, 그리고 SignalR도 있습니다.
NCache 미션 크리티컬 앱용
무엇인지 빠르게 보여드리겠습니다 NCache 처럼 보입니다. 미션 크리티컬 애플리케이션을 위한 분산 캐시의 개념은 다음과 같습니다. "미션 크리티컬"이라는 단어를 사용한 이유는 대부분의 경우 고객이 사용하는 것을 보기 때문입니다. NCache 고객과 직접 접촉하는 매우 민감한 애플리케이션에서, 그리고 그들의 비즈니스에 매우 중요한 애플리케이션에서. 그래서, NCache 아시다시피, 그 경우에는 매우 중요한 인프라의 일부입니다.
그리고 앞서 말씀드린 것처럼, 이러한 애플리케이션들은 트랜잭션 처리량이 많은 서버 애플리케이션입니다. 웹 애플리케이션, 마이크로서비스, 웹 API, 또는 기타 서버 애플리케이션들이 여기에 해당합니다. 당연히 .NET, Java, Node.js, Python 등을 사용할 수 있습니다. 이러한 애플리케이션들은 SQL Server, Oracle, DB2, MySQL 등의 관계형 데이터베이스나, 기존 메인프레임 데이터, 또는 MongoDB, CosmosDB, Cassandra 등의 NoSQL 데이터베이스에 접근하려고 합니다. 이러한 상황에서, NCache ...를 사용하면 분산 캐시가 됩니다. NCache 별도의 캐싱 계층으로 두 개 이상의 서버를 사용할 수 있지만 별도의 캐싱 계층이 없어도 애플리케이션은 동일한 상자에서 실행될 수 있습니다. NCache 그리고 완벽하게 잘 작동하지만 더 인기 있는 배포 아키텍처는 별도의 캐싱 계층을 갖는 것입니다. 이는 사용하기에 더 깔끔한 방법입니다. NCache.
따라서 2개의 서버 캐시 클러스터로 시작한다고 가정해 보겠습니다. NCache 무리, NCache 이러한 모든 서버의 메모리, CPU, 네트워크 카드 리소스를 하나의 논리적 용량으로 풀링하고, 예를 들어 애플리케이션을 통해 더 많은 트랜잭션 부하를 발생시킨다고 가정해 보겠습니다. NCache 그리고 이 두 서버가 최대치에 도달하면 쉽게 세 번째 서버나 네 번째 서버, 다섯 번째 서버를 추가할 수 있습니다. NCache 절대 병목 현상이 되지 않습니다. 데이터베이스로는 불가능한 일이죠. 데이터베이스는 확장성이 없습니다. NoSQL은 확장성이 있지만, 대부분의 경우 다양한 비즈니스 이유로 관계형 데이터베이스를 사용해야 하고, 기존 메인프레임 시스템도 보유하고 있습니다. 데이터 저장 계층이 확장성이 없기 때문입니다. NCache 최대한 많은 데이터를 캐시할 수 있도록 하여 애플리케이션 확장에 도움이 됩니다. 일반적인 목표는 약 80%의 시간 동안 데이터를 찾을 수 있도록 하는 것입니다. NCache 데이터베이스로 이동하는 것보다 훨씬 효율적입니다. 이 비율을 달성할 수 있다면 데이터베이스의 부담을 덜고 애플리케이션의 확장성을 높일 수 있습니다.
메시징 및 스트림
두 번째 일반적인 사용 사례 또는 사용 사례 NCache 여러 애플리케이션이 서로 통신할 수 있는 메시징 및 스트림 플랫폼으로 사용하는 것입니다. 게시/구독 메시징를 통해 연속 쿼리및 NCache 기반 이벤트입니다. 어떤 모습인지 보여드리겠습니다. 예를 들어, 실시간 메시징이나 스트림 처리를 많이 해야 하는 대량 트랜잭션 서버 애플리케이션이 있는 경우 NCache. 이제 같은 NCache 분산 캐시였던 것이 이제 메시징 및 스트림 플랫폼이 되었습니다. 다시 말해, 메모리 내 분산 저장소입니다. 선형적으로 확장되며, 여러 서버에 메시지를 복제합니다. 실제로, NCache 또한 지속성도 있습니다.
이를 통해 다양한 애플리케이션을 구현할 수 있습니다. 예를 들어, Pub/Sub 메시징은 매우 널리 사용되는 방법론이자 패러다임으로, 여러 게시자와 여러 구독자가 분리된 방식으로 서로 통신할 수 있습니다. 분리된 방식은 게시자가 구독자를 알 필요 없이 특정 토픽에 메시지를 게시하면 구독자가 해당 메시지를 받을 수 있다는 것을 의미합니다. 연속 쿼리도 마찬가지입니다. 이 두 가지가 일반적인 방식입니다. NCache 사용.
.NET 대 Java 애플리케이션
이제 어떻게 이야기하는지 살펴보겠습니다. NCache .NET과 Java 애플리케이션을 처리합니다. NCache 여러분이 매우 흥미롭게 여길 매우 독특한 기본 멀티플랫폼 기능이 있는데, 자세히 설명하겠습니다.
.NET 에디션
NCache .NET과 Java 모두에 대한 네이티브 솔루션을 제공하려고 합니다. 즉, .NET 애플리케이션을 사용하면 전체 애플리케이션 스택이 .NET을 사용하게 되며, .NET만 사용하게 됩니다. 예를 들어, NCache 애플리케이션에서 사용할 네이티브 .NET 클라이언트가 있습니다. 이는 애플리케이션 서버에서 실행되며 NCache 100% 'C#'(C Sharp)로 개발했습니다.
마찬가지로 .NET으로 작성한 Read-through, Write-through, Right-behind, Loader/Refresher와 같은 서버 측 코드가 있는 경우 NCache 해당 코드는 자체 .NET CLR 프로세스에서 실행됩니다. 방법을 보여드리겠습니다. 그리고 이 다이어그램을 앞뒤로 살펴보겠습니다. 예를 들어, 다음과 같습니다. NCache 아키텍처에는 Windows 또는 Linux에서 실행될 수 있는 .NET 애플리케이션이 있습니다. 여기에는 네이티브 NCache .NET 클라이언트. 그리고 이것은 다음과 대화하고 있습니다. NCache .NET Edition인 클러스터 NCache 클러스터입니다. 즉, 서버 측 코드도 .NET이라는 뜻입니다.
이제 방법 NCache 아키텍처가 구축되어 있으며, 이것이 바로 멀티플랫폼 네이티브 지원에 매우 강력한 이유입니다. 캐시 프로세스와 관리 프로세스가 있으며, 이 프로세스들은 서버 측 코드 프로세스와 분리되어 있습니다. 그리고 매우 고성능 RPC(인메모리 RPC)가 있습니다. NCache 사용, 그것 NCache 초고속 자체 RPC를 개발했습니다. 캐시가 서버 측 코드와 통신하는 방식이 바로 이 방식입니다. 예를 들어, 읽기 처리기를 호출해야 하는 경우, 읽기 처리기는 .NET CLR 프로세스 내부에서 실행되어 데이터베이스로 이동하여 데이터를 가져온 후 캐시에 전달합니다. 쓰기 처리, 로더, 리프레셔에도 동일하게 적용됩니다. 따라서 애플리케이션의 전체 환경은 .NET 기반입니다.
자바 에디션
자, 이제 Java 측으로 넘어가 볼까요? 마찬가지로 Java 서버 측 코드가 있습니다. NCache 애플리케이션 서버에서 실행되는 100% Java 클라이언트가 있으며, .NET과 동일한 방식으로 작동합니다. Java Edition은 다음과 같습니다. 예를 들어 Linux, Windows, Docker, Kubernetes 등에서 실행되는 Java 애플리케이션이 있다고 가정해 보겠습니다. 그러면 해당 애플리케이션은 NCache Java 클라이언트는 제가 바로 여기서 말했듯이 100% 네이티브 Java이며, 이 Java 클라이언트는 .NET 클라이언트와 기본적으로 동일합니다. 또한 NCache .NET 클라이언트가 사용하는 것과 동일한 방식으로 클러스터링합니다. NCache자체 독점 소켓 프로토콜과 NCache 서버는 서버 측 Java 코드가 자체 JVM에서 실행되도록 설계되었습니다.
따라서 모든 개발, 테스트, 디버깅은 네이티브 JVM 프로세스에서 수행됩니다. 그리고 이 캐시 프로세스는 예를 들어 읽기 처리기(Read-through handler)를 호출하는데, 이 처리기는 Oracle, DB2, 또는 SQL Server 데이터베이스로 이동하여 데이터를 가져와 캐시 프로세스에 전달합니다. 다시 한번 동일한 고성능 인메모리 RPC가 사용됩니다. 따라서 .NET과 Java 코드를 자체 네이티브 프로세스에 캡슐화하는 아키텍처를 구축함으로써, NCache Java와 .NET 모두에 대한 네이티브 스택을 제공할 수 있습니다.
그리고 Java 애플리케이션의 경우 Windows 또는 Mac OS에서 개발을 수행하고 싶을 수도 있습니다. NCache 완벽하게 지원하거나 Linux를 사용하는 경우 .NET 사용자보다 Docker 및 Kubernetes를 사용할 가능성이 더 높습니다. NCache Docker 이미지를 제공하고 Kubernetes, Azure AKS, AWS EKS, Google GKE 또는 Red Hat OpenShift를 완벽하게 지원합니다. 매우 원활하게 사용할 수 있습니다.
그래서, NCache 매우 독특합니다. 네이티브 .NET 환경과 동시에 네이티브 Java 환경을 제공합니다. 따라서 Java를 사용하는 업체라면 Java가 아닌 제품을 사용한다는 느낌이 들지 않고, .NET을 사용하는 업체라면 .NET이 아닌 제품을 사용한다는 느낌이 들지 않습니다. 바로 이것이 Java의 장점입니다. NCache 그것이 설계된 방식이에요.
동적 클러스터
피어 투 피어 아키텍처(자체 복구)
- 단일 장애 지점 없음(마스터/슬레이브 없음)
- 클러스터 코디네이터 가장 오래된 노드, 그 다음으로 오래된 노드가 자동 후속 노드입니다.
좋습니다. 이제 들어가겠습니다. 동적 클러스터링 부분의 NCache 고가용성을 위한 아키텍처입니다. 잠깐, 알겠습니다. 첫 번째 부분은 동적 클러스터입니다. 제가 클러스터라는 단어를 사용할 때 쿠버네티스 클러스터나 다른 운영 체제 수준의 클러스터를 의미하는 것은 아닙니다. NCache자체 TCP 기반 클러스터입니다. 이 클러스터는 피어 투 피어 아키텍처를 사용합니다. 피어 투 피어는 마스터도 슬레이브도 없다는 것을 의미합니다. 마스터/슬레이브의 문제점은 마스터가 다운되면 슬레이브가 작동하지 않거나 제한된다는 것입니다. 반면 피어 투 피어 아키텍처에서는 모든 노드가 동등한 성능을 발휘합니다. 가장 오래된 노드인 클러스터 코디네이터 노드가 있는데, 이 노드가 다운되면 그 다음으로 오래된 노드가 자동으로 클러스터 코디네이터로 선택됩니다. 클러스터 코디네이터는 클러스터 멤버십을 관리합니다. 분산 맵, 클러스터 상태, 그리고 나중에 자세히 설명할 여러 가지 기능을 관리합니다.
동적 클러스터
- 서버 추가/제거 런타임에
- 클러스터 멤버십 런타임 시 전파
- 캐시나 클라이언트 애플리케이션을 중지하지 않고
동적 클러스터링은 캐시나 애플리케이션을 중단하지 않고 런타임에 클러스터에 서버를 추가하거나 제거할 수 있음을 의미합니다. 중단이 발생하지 않습니다. 예를 들어 클러스터에 새 서버를 추가하면 클러스터 멤버십이 런타임에 업데이트되고 해당 런타임 정보가 클라이언트에 전파됩니다. 다음 슬라이드에서 이에 대해 자세히 설명하겠습니다.
클러스터 연결 장애 조치
- 연결 자동 복구(재시도, 타임 아웃)
- 심장의 고동 연결 끊김을 감지하려면
클러스터 연결 장애 조치 기능도 있습니다. 소켓 방식이기 때문에 클러스터 서버는 일반적으로 동일한 서브넷에 있고 서로 상당히 가까이 있지만 항상 그런 것은 아닙니다. 다른 지역에 서버를 배치한 고객도 있는데, 이 경우 아무 문제 없이 작동하지만 대부분의 경우 다음을 권장합니다. NCache 서버는 서로 상당히 가까워야 합니다. 하지만 여전히 연결에 실패할 수 있습니다. 만약 그렇다면 NCache 재시도 로직이 있고, 시간 초과도 있고, 하트비트 로직도 있는데, 이 모든 게 다 동적으로 동작하도록 하기 위한 겁니다.
동적 클라이언트 및 동적 구성
동적 클라이언트 연결
- 런타임에 클라이언트 추가/제거
- 멈추지 않고 캐시 또는 클라이언트 애플리케이션
동적 아키텍처의 또 다른 부분은 동적 클라이언트입니다. 이처럼 클러스터는 런타임에 서버를 추가하거나 제거할 수 있었고, 클라이언트도 런타임에 추가하거나 제거할 수 있습니다. 클라이언트란 무엇을 의미할까요? 클라이언트는 NCache 애플리케이션 서버, 즉 웹 서버에서 실행되는 클라이언트는 애플리케이션과 통신하는 부분입니다. 따라서 런타임에 클라이언트를 추가하거나 중지 없이 런타임에 클라이언트를 제거할 수 있습니다. NCache캐시나 애플리케이션을 중단 없이 사용할 수 있습니다. 자, 이것이 첫 번째 부분입니다.
동적 구성
- 클러스터 멤버십, 캐싱 토폴로지, 분산 맵
- 런타임 모든 클라이언트와 서버로 전파
두 번째 부분은 동적 구성입니다. 마지막 슬라이드에서 언급했듯이 클러스터에 서버를 추가하면 클러스터 멤버십이 변경됩니다. 연결된 모든 기존 클라이언트에 전파되어 연결해야 할 새 서버가 있음을 알 수 있습니다. 따라서 캐싱 토폴로지에 따라 해당 서버에도 연결할 수 있습니다. 또한 토폴로지에 따라 배포 맵이 있을 수 있습니다. 배포 맵은 분할 캐시 및 분할 복제본 캐시에 더 적합합니다. 하지만 서버를 추가하면 업데이트되고 런타임에 전파됩니다. 또한 여러 다른 구성 변경 사항도 있습니다. 런타임에 전파되는 핫 적용 기능이 있습니다. 이것이 두 번째 부분입니다.
클라이언트 연결 장애 조치
- 서버와의 클라이언트 연결을 위해
- 연결 자동 복구(재시도, 타임 아웃)
- 살아 유지 연결 끊김을 감지하려면
세 번째 부분은, 클러스터 연결 장애 조치와 동일한 방식인 클라이언트 연결 장애 조치(Client Connection Failover)가 있다는 것입니다. 하지만 클라이언트가 클러스터 서버와 항상 가까이 있지는 않을 수 있기 때문에 이 기능이 훨씬 더 필요합니다. 또한, 중간에 라우터나 방화벽이 있을 수도 있습니다. 따라서 클라이언트와 클러스터 간의 연결이 끊어질 가능성이 더 높습니다. NCache 상당히 지능적인 재시도 기능과 시간 제한 기능을 제공합니다. 또한 연결 유지 기능도 있어 연결이 끊어져도 클라이언트가 연결을 유지할 수 있습니다. 클라이언트는 다시 연결됩니다. NCache 무리.
스플릿 브레인 감지 및 복구
동적 측면의 또 다른 중요한 주제 NCache 아키텍처는 스플릿 브레인(Split Brain)입니다. 스플릿 브레인은 클러스터에서 발생할 수 있는 현상입니다.
분할 뇌는 연결 끊김 시 발생합니다.
- 연결 재시도 실패 시 형성되는 하위 클러스터
- 각 하위 클러스터는 자체 코디네이터를 선택하고 다른 코디네이터는 죽었다고 가정합니다.
그리고, 스플릿 브레인은 예를 들어 1대의 서버로 구성된 건강한 클러스터가 있을 때, 어떤 이유로든 서버 간 연결이 끊어지면 발생합니다. 네트워크 연결이 끊어질 수 있는 상황이면 언제든 발생할 수 있습니다. 이런 상황은 흔히 볼 수 있습니다. 따라서 이런 상황이 발생하면 하위 클러스터가 형성됩니다. 예를 들어, 스플릿 2, 스플릿 3, 스플릿 XNUMX이 있다고 가정해 보겠습니다. 각 하위 클러스터는 자신이 살아남았다고 생각합니다. 그래서 자체 클러스터 코디네이터를 생성하고 독립적인 클러스터가 됩니다.
분할 뇌 감지
- 스플릿 재연결 시 감지됨 서버와 함께
- 분할 복구 프로세스가 시작되었습니다
하지만 이 모든 분할은 이전에는 건강한 클러스터의 일부였으며, 이 서버들이 자발적으로, 원활하게 종료되지 않았다는 점을 기억해야 합니다. '노드 종료'를 실행하지 않았습니다. NCache 관리 도구 대신 연결이 끊어졌습니다. 따라서 네트워크 연결이 복구되었는지 확인하기 위해 해당 서버를 계속 탐색합니다. 그리고 대부분의 경우 5분, 10분, 30분, 1시간 후에 연결이 복구될 가능성이 높습니다.
스플릿 브레인 복구
- 하위 클러스터 반복적으로 병합됨 가장 큰 것부터 가장 작은 것까지
- 더 작은 클러스터 클라이언트는 더 큰 클러스터로 이동됩니다.
- 더 작은 클러스터 데이터 손실
이런 일이 발생하면 분할 브레인 복구(Split Brain Recovery)가 수행됩니다. 그리고 이 분할들이 병합되는 지점입니다. 이러한 하위 클러스터는 가장 큰 클러스터부터 가장 작은 클러스터까지 반복적으로 병합되는데, 이 과정에서 데이터 손실이 발생합니다. 독립된 클러스터가 되었기 때문에 일부 데이터가 손실될 수밖에 없습니다. 하지만 이 모든 작업은 사용자가 지정한 규칙에 따라 자동으로 수행됩니다.
분할된 뇌에 대한 자세한 내용은 별도로 제공됩니다. 비디오 하지만 이런 종류의 기능은 개요를 제공합니다. 이는 귀하의 NCache 클러스터는 건강을 유지하며 뇌가 분열될 때마다 회복될 수 있습니다.
캐싱 토폴로지
좋아요, 이제 다음으로 넘어가겠습니다. 캐싱 토폴로지캐싱 토폴로지는 기본적으로 데이터 저장, 복제 전략, 그리고 클라이언트 연결 전략을 포함합니다. 네 가지 토폴로지가 있는데, 하나는 분할 캐시, 분할 복제, 복제 캐시, 그리고 미러 캐시입니다. 여기서는 분할 캐시를 예로 들어 보겠습니다.
파티션된 캐시
- 캐시를 파티션으로 분할 런타임에
- 캐시 서버당 하나의 파티션. 전체 캐시 클러스터에 대해 균등하게 분산된 100개의 버킷
- 서버 추가/제거 시 파티션 생성/삭제
파티션된 캐시 기본적으로 전체 캐시가 파티션으로 나뉘고, 각 서버는 하나의 파티션을 갖습니다. 그리고 버킷이라는 개념이 있습니다. 각 파티션에는 버킷이 있습니다. 전체 캐시에는 총 100개의 버킷이 있습니다. 따라서 파티션 수에 따라 버킷이 균등하게 분배됩니다.
그리고 이러한 파티션은 런타임에 생성되는데, 이것이 여기서 중요한 부분입니다. 따라서 서버를 추가하면 파티션이 생성됩니다. 예를 들어, 하나의 서버로 시작하고 파티션이 하나뿐이며 100개의 버킷이 모두 해당 파티션에 있다고 가정해 보겠습니다. 런타임에 두 번째 서버를 추가하면 이전 슬라이드에서 언급한 클러스터 멤버십 정보가 업데이트될 뿐만 아니라 이제 분산 맵도 업데이트됩니다. 분산 맵은 기본적으로 어떤 파티션에 어떤 버킷이 포함되어 있는지에 대한 맵입니다. 따라서 두 번째 파티션을 추가하면 분산 맵이 변경됩니다. 분산 맵은 실제로 버킷에 매핑되는 해시 맵입니다. 해시 맵 값의 범위는 버킷입니다. 그리고 이것은 추가한 데이터 양에 따라 변경되지 않고 서버 수, 파티션 수를 변경하거나 데이터 재조정을 수행할 때만 변경됩니다. 따라서 파티션은 동적입니다.
동적 데이터 밸런싱
- 버킷을 다른 파티션으로 이동합니다. 런타임에
- 파티션이 추가/제거될 때
- 파티션이 과부하되면
두 번째는 동적 데이터 밸런싱입니다. 이 모든 것이 해시 맵 기반이기 때문에, 사용한 키 유형에 따라 일부 버킷이 다른 버킷보다 더 많은 데이터를 얻을 가능성이 매우 높습니다. 그리고 일부 파티션은 거의 가득 차고 다른 파티션은 거의 비어 있는 상황이 발생할 수 있습니다. 그리고 이런 상황이 발생하면 NCache 임계값을 설정할 수 있는 기능이 있습니다. 예를 들어, 파티션이 80% 이상 차면 20%, 10%, 또는 5%를 제거한다고 가정해 보겠습니다. 제거하는 것이 아니라 동적으로 균형을 맞추는 것입니다. 데이터 밸런싱은 파티션 1에서 해당 버킷을 가져와 다른 파티션에 복사하거나 다른 파티션으로 이동하는 것을 의미합니다. 따라서 데이터 밸런싱은 데이터와 모든 파티션이 상당히 균등하게 유지되도록 보장합니다.
클라이언트가 모든 파티션에 연결됨
- 사용하여 분포도 & 클러스터 멤버십
- 클라이언트가 자동으로 연결됩니다 새로운 파티션 런타임에
분할 캐시에서는 모든 클라이언트가 모든 파티션 또는 모든 서버에 연결합니다. 이는 한 번의 호출로 원하는 항목에 직접 액세스하기 위해서입니다. 예를 들어, 클라이언트가 하나의 서버에만 연결되어 있고 항목 번호 3을 원한다고 가정해 보겠습니다. 서버 1과 통신하면 서버 1은 서버 2로 이동하여 해당 항목을 가져옵니다. 이는 두 번의 홉(hop)을 거치는 작업으로, 클라이언트가 데이터가 있는 곳으로 직접 이동할 수 있는 경우보다 최적화되지 않습니다. 클라이언트는 분산 맵(distribution map)을 통해 이를 알 수 있습니다. 분산 맵은 클라이언트가 데이터의 위치를 파악하고 해당 위치에서 직접 데이터를 가져올 수 있도록 돕기 위해 생성됩니다.
즉, 분할 캐시에는 복제 기능이 없습니다. 따라서 서버가 다운되면 데이터가 손실됩니다. 잠시 후에 설명할 '지속성' 기능을 사용하지 않는 한 다른 방법이 없습니다. 그러면 분할 캐시도 데이터를 잃지 않습니다.
파티션 복제본 캐시
파티션 복제본(동적)
- 런타임에 생성됨 파티션이 추가/제거될 때
- 다른 서버에 위치 파티션보다
- 그들에게 말을 건 고객은 없다. 고객은 Partitions와 상담합니다.
파티션은 복제본과 통신/복제합니다.
다음 토폴로지는 파티션-레플리카 캐시입니다. 이 토폴로지는 두 가지 장점을 모두 제공하기 때문에 가장 인기 있는 토폴로지입니다. 확장성을 제공하는 파티셔닝과 고가용성을 제공하는 복제 기능을 제공합니다. 따라서 데이터 손실이 없습니다. 예를 들어, 파티션 캐시와 마찬가지로 모든 것이 동일하지만 모든 파티션은 이제 다른 서버에 복제본을 갖습니다. 따라서 파티션 1이 서버 1에 있고 복제본은 복제본 2이라고 하며, 이 경우 서버 XNUMX에 있다고 가정해 보겠습니다. 따라서 파티션이 시간에 따라 동적으로 생성되는 것처럼 복제본도 파티션이 추가되거나 제거될 때 런타임에 생성됩니다. 그리고 복제본은 항상 다른 서버에 위치합니다.
또 다른 측면은 모든 복제본이 수동적이라는 것입니다. 수동적이란 클라이언트가 복제본과 직접 통신하지 않는다는 것을 의미합니다. 클라이언트는 복제본이 파티션과만 통신하고, 파티션은 복제본을 업데이트한다는 것을 의미합니다. 따라서 파티션에서 무언가를 업데이트할 때마다 파티션은 복제본에 해당 내용을 업데이트합니다. 그리고 이 업데이트는 기본적으로 비동기식입니다. 비동기식은 더 빠른 속도를 제공하기 위해 사용됩니다. 첫째, 클라이언트는 복제가 완료될 때까지 기다릴 필요가 없습니다. 둘째, 대량 복제가 가능합니다. 따라서 수백 또는 수천 개의 업데이트를 결합하여 복제본으로 한 번에 이동하거나 푸시할 수 있습니다. 이러한 네트워크 연결 비용은 데이터를 결합하는 것보다 훨씬 빠르거나 훨씬 더 비쌉니다.
비동기/동기 복제
- 비동기(기본값): 대량 복사. 일부 데이터 손실이 발생할 수 있지만 더 빠릅니다.
- Sync: 작업이 완료되었습니다. 복제가 실패하면 작업이 실패합니다.
그러나 비동기 복제는 항상 일관성이 있는 것은 아닙니다.결과적으로 일관성이 있으므로 95%에서 99%의 경우 충분하고, 매우 민감한 데이터를 다루는 경우는 1~5% 정도입니다.따라서 비동기 복제가 아닌 동기 복제가 필요합니다.동기 복제라는 기능이 있는데, 이 기능을 켜면 클라이언트가 파티션의 항목을 업데이트할 때마다 파티션이 먼저 복제본을 업데이트할 때까지 작업이 완료되지 않습니다.따라서 복제가 실패하면 작업이 실패합니다.따라서 작업이 성공하면 복제도 성공하는 방식입니다.이것이 매우 중요한 기능입니다.
동적 데이터 밸런싱(복제본)
- 파티션에서 수행되는 경우에도 복제본의 데이터 밸런싱
마지막으로, 분할 토폴로지와 마찬가지로 분할 캐시 토폴로지에도 복제본에 동적 데이터 밸런싱이 적용됩니다. 파티션이 동적으로 데이터 밸런싱되면 복제본도 그에 맞춰야 합니다. 복제본은 항상 파티션과 동일한 복사본이기 때문입니다. 따라서 데이터 밸런싱도 진행됩니다.
동적 파티셔닝
이제 동적 파티셔닝이 실제로 어떻게 발생하는지 간략하게 살펴보겠습니다. 예를 들어, 두 대의 서버로 구성된 클러스터에 6개의 항목이 있고 세 번째 서버를 추가하려는 경우를 가정해 보겠습니다. 아직은 데이터를 추가하지 않습니다. 이는 또 다른 사용 사례이기 때문입니다. 이는 노드를 추가할 때 데이터가 다른 파티션으로 이동하는 방식일 뿐입니다.
노드를 추가한다고 가정해 보겠습니다. 이제 세 번째 서버가 있습니다. 파티션 3이 생성되고 파티션 3은 이제 파티션 1과 파티션 2에서 데이터를 가져옵니다. 즉, 파티션 1에서 일부 데이터를 가져오고 파티션 2에서 일부 데이터를 가져옵니다. 예를 들어, 파티션 3에서 항목 1을 가져오고 파티션 4에서 항목 2를 가져와서 파티션 3이 된다고 가정해 보겠습니다.
이제 파티션 3이 되었으므로 복제본은 다른 서버에 있어야 하므로 서버 1에 배치한다고 가정해 보겠습니다. 예를 들어 서버 1에는 복제본 2가 있었는데, 복제본 3으로 변환되고 복제본 2가 서버 3으로 이동합니다. 예를 들어 이제 복제본 3에는 3, 4, 4 대신 5, 6가 포함되고 복제본 2에는 5, 6이 포함됩니다. 이 모든 작업은 애플리케이션이 중단되지 않고 런타임에 동적으로 수행됩니다.
서버가 다운되면 동일한 일이 역으로 발생합니다. 예를 들어 3개의 파티션이 있다고 가정해 보겠습니다. NCache 클러스터와 서버 3이 다운되었는데, 서버 3을 직접 다운시켰거나 아예 다운된 것 같습니다. 3번 파티션을 더 이상 사용할 수 없기 때문에 다운되는 즉시, 복제본 XNUMX의 색상을 변경했습니다. 보시다시피, 복제본은 활성화됩니다. 일반적으로 복제본은 활성화되지 않은 상태죠? 파티션만 활성화되지만, 이제 분할된 상태가 됩니다. 하지만 이는 일시적인 현상일 뿐입니다. 같은 시스템에 두 개의 파티션이 있는데 복제본이 없어지는 것을 원치 않기 때문입니다.
이제 이 항목이 파티션 1과 병합됩니다. 예를 들어 항목 3은 파티션 1로, 항목 4는 파티션 2로 이동한다고 가정해 보겠습니다. 이렇게 되면 복제본 3은 복제본 2가 됩니다. 따라서 동일한 작업이 역방향으로도 실행 시간에 발생합니다. 동적 파티셔닝은 매우 유연하고 동적입니다. 이러한 동적성은 고가용성을 제공합니다. NCache.
유지 관리 모드
동적 파티셔닝은 매우 유용하고 강력하지만, 재파티셔닝을 원하지 않는 경우도 있습니다. 그중 하나가 예약된 유지 관리입니다. 예를 들어 운영 체제 패치를 적용하고 있는데, 그 패치로 인해 서버가 5분 또는 10분 동안 다운될 예정이라고 가정해 보겠습니다. 전체 캐시 클러스터에 수십 기가바이트의 데이터가 있을 수 있습니다. 5분 동안만 재파티셔닝하고 노드가 다시 가동될 때 다시 재파티셔닝하는 것은 바람직하지 않습니다. 따라서 예약 유지 관리 기능을 활성화할 수 있습니다. NCache 이 경우 이 노드를 다운시킬 때 관리 도구를 통해 다시 다운시켜야 하며, 복제본이 활성화되지만 재분할은 이루어지지 않습니다.
따라서 파티션 1은 복제본 3, 파티션 2는 복제본 1로 구성된 두 개의 서버 구성으로 유지됩니다. 이 복제본 3은 실제로 파티션 3이므로 활성 상태로 작동합니다. 물론 고가용성은 아닙니다. 파티션 1은 백업되지만 파티션 2와 복제본 3은 백업되지 않습니다. 하지만 이는 일시적인 현상이며 5~10분 정도만 필요합니다. 따라서 이 서버가 다시 작동하면 이전 상태로 돌아가고, 다시 파티션이 되면 복제본이 됩니다. 이것이 예약된 유지 관리 기능의 작동 방식입니다. NCache 작동합니다.
복제된 캐시
다음 토폴로지는 다음과 같이 불립니다. 복제된 캐시이 토폴로지에서는 두 대 이상의 서버를 사용할 수 있으며, 각 서버는 캐시 전체 사본을 보유하고 모든 서버가 활성 상태입니다. 즉, 각 서버에는 클라이언트가 연결되어 있습니다. 하지만 이 토폴로지에서는 모든 클라이언트가 하나의 서버에만 연결됩니다. 해당 서버가 전체 캐시를 보유하고 있기 때문입니다. 따라서 파티션이나 파티션 복제본처럼 두 대의 서버에 연결할 필요가 없습니다.
이 토폴로지에서는 전체 캐시가 바로 거기에 있기 때문에 모든 읽기가 매우 빠르지만 업데이트는 동기적으로 수행되어야 합니다.두 서버 모두 활성 서버이기 때문에 동일한 항목이 여기저기서 동시에 업데이트될 수 있으며 당연히 데이터 무결성 문제가 발생하고 싶지 않을 것입니다.따라서 인덱싱 체계가 있고 인덱스가 있으며 실제로 발급된 시퀀스 번호가 있고 모든 항목이 동일한 시퀀스로 업데이트되는 동기 방식으로 수행됩니다.따라서 업데이트가 항상 올바른 방식으로 수행될 수 있습니다.그러나 동기 업데이트의 비용은 항목 1을 업데이트하는 클라이언트가 있는 경우 이 서버가 항목 2에 항목 1을 업데이트하도록 알린다는 것을 의미합니다.두 서버 모두 항목 1을 성공적으로 업데이트한 경우에만 업데이트가 성공하고 제어가 다시 돌아갑니다.즉, 파티션이나 파티션 복제 토폴로지만큼 빠르지는 않지만 해당 업데이트가 성공하면 모든 서버에서 항상 수행된다는 것을 의미합니다.
이 토폴로지는 읽기 집약적인 작업에 적합합니다. 두 대의 서버로 구성된 클러스터의 경우 쓰기 속도도 상당히 빠릅니다. 파티션 복제본만큼 빠르지는 않지만 대부분의 상황에서는 상당히 빠릅니다. 하지만 서버를 더 추가할수록 업데이트 성능이 저하됩니다. 실제로는 더 많은 서버를 동기적으로 업데이트해야 하므로 속도가 더 느려집니다. 따라서 이 토폴로지는 고유한 용도가 있기 때문에 계속 사용하고 있습니다. 많은 고객들이 특수한 상황에서 이 토폴로지를 사용하고 있습니다.
미러링된 캐시
네 번째 토폴로지는 다음과 같습니다. 미러링된 캐시. 이것도 매우 구체적인 토폴로지입니다. 2노드 토폴로지입니다. 액티브 노드와 패시브 노드가 있습니다. 다시 말해, 액티브 노드는 전체 캐시를 가지고 있으며, 캐시 사본은 패시브 노드에 저장됩니다. 모든 클라이언트는 액티브 노드에 연결하여 모든 항목에 대해 액티브 노드를 업데이트하고, 업데이트 내용은 패시브 노드에 비동기적으로 미러링되거나 복제됩니다. 그리고 이러한 비동기성은 Partition Replica처럼 매우 빠르다는 것을 의미합니다.
이 토폴로지에서는 액티브 노드가 다운되면 패시브 노드가 자동으로 액티브 노드로 전환되고 모든 클라이언트는 패시브 노드나 새로 액티브 노드로 자동 이동합니다. 이렇게 하면 다운타임이나 중단이 발생하지 않습니다. 이를 자동 페일오버 지원이라고 하는데, 제가 말한 의미는 바로 이것입니다. 그리고 액티브 노드가 다시 활성화되면 당연히 같은 일이 역으로 일어납니다.
미러 토폴로지는 특수한 경우에도 매우 유용합니다. 두 서버 이상으로 확장할 수는 없지만, 모든 클라이언트가 여기에 연결하여 다른 서버에 복제할 수 있다는 점에서 고유한 용도가 있습니다. 예를 들어 재해 복구 상황 등에 사용할 수 있습니다.
실시간 지속성
또 다른 매우 강력한 기능 NCache 불렀다. 실시간 지속성라이브 퍼시스턴스는 파티션 및 파티션 복제 토폴로지에서만 사용할 수 있으며, 라이브로 실행됩니다. 즉, 런타임에 캐시를 업데이트하면 퍼시스턴스 저장소도 즉시 업데이트됩니다. 퍼시스턴스 저장소 업데이트는 비동기 방식으로 진행되므로 애플리케이션 성능에 영향을 주지 않습니다. NCache 성능 향상 덕분입니다. 그래서 애플리케이션이 매우 빠른 속도를 유지할 수 있는 것입니다. 영구 저장은 버킷 레벨에서 이루어집니다. 전체 캐시를 나타내는 100개의 버킷이 NoSQL 문서 저장소에 저장됩니다. 파일 기반 저장소이므로 서버 기반 저장소가 아닙니다. NoSQL 데이터베이스 서버가 아니라 NoSQL 문서 저장소입니다. NCache 사용. 모든 서버에 공통적인 공통 위치에서 사용할 수 있습니다. NCache 클러스터를 구성하면 모두 동일한 영구 저장소에 의존할 수 있습니다.
이 기능의 장점 중 하나는, 그리고 이 기능이 제공되는 이유는, 첫째, 무엇을 저장하든 전체 캐시를 저장할 수 있고, 전체 캐시는 항상 유지된다는 것입니다. 캐시에서 업데이트하는 모든 내용은 몇 밀리초 차이로 영구 저장소에도 저장됩니다. 따라서 해당 캐시를 다른 캐시에 다시 로드하거나, 모든 서버가 다운되더라도 영구 저장소에서 언제든지 다시 시작할 수 있습니다. 아주 적은 양의 데이터를 제외하고는 어떤 데이터도 손실되지 않습니다. 또는 캐시를 한 환경에서 다른 환경으로 쉽게 옮길 수 있습니다.
또 다른 이점은 파티션 및 파티션 복제 토폴로지에 실제로 고가용성을 더한다는 것입니다. 파티션 토폴로지에 대해 자세히 설명하겠습니다. 앞서 언급했듯이 파티션 캐시에는 복제 기능이 없습니다. 따라서 어떤 파티션이나 서버가 다운되면 해당 파티션을 잃게 되는 것이 아닙니까? 지속성이 켜져 있다면 그럴 필요가 없습니다. 해당 데이터의 사본도 이 버킷에 보관되기 때문입니다. 따라서 이 서버가 다운되면 메모리의 버킷은 재할당되지만, 다른 서버에는 데이터가 없습니다. 이제 해당 서버는 이 버킷이 비어 있고 지속성 저장소에 데이터가 있다는 것을 알고 있으므로 지속성 저장소에서 해당 데이터를 다시 로드합니다.
즉, Partitioned-Cache를 사용하더라도 서버가 다운되더라도 데이터 손실이 발생하지 않습니다. 또한, Partition Replica를 사용하면 Partitioned-Cache와 동일한 이점을 누릴 수 있습니다.
여기서 얻을 수 있는 이점은 더 많은 메모리를 사용할 수 있다는 것입니다. 캐시에 더 많은 데이터를 저장할 수 있는데, 여기서는 할당할 필요가 없는 복제본에 더 많은 메모리를 할당해야 하지만, 지속성 저장소는 할당해야 합니다. 그래서 이것이 Partitioned Cache의 이점입니다. Partition-Replica에도 이점이 있습니다. 그리고 이것이 이미 고가용성을 제공하지만, 높은 가용성이 어느 한 시점에서 하나의 서버가 다운되는 경우에만 발생한다는 점이 흥미롭습니다. 하지만 예를 들어, 두 서버가 동시에 다운되면 Partition-Replica에서도 지속성 없이 데이터가 손실됩니다. 모든 파티션의 사본은 하나뿐이고 두 서버가 다운되면 감당할 수 있는 것보다 더 많은 서버를 잃게 됩니다. 지속성을 사용하면 문제가 없으며 지속성 저장소에서 모든 데이터를 다시 로드할 수 있습니다.
두 경우 모두, 영구 저장소에서 데이터를 로드할 때마다 세 대의 서버가 두 대가 된다는 점을 명심해야 합니다. 데이터가 너무 커서 두 서버에 모두 담을 수 없을 수도 있습니다. 또 다른 문제는 나머지 두 서버에 세 대의 서버를 모두 수용할 수 있을 만큼 충분한 메모리를 확보하는 것입니다. 이것이 유일한 제약입니다. 그 외에는, 영구 저장소는 Partitioned 캐시와 Partition-Replica 캐시 모두에 실질적인 가치를 부여합니다.
클라이언트 캐시
좋아요, 또 다른 매우 중요한 기능은 다음과 같습니다. NCache 불렀다. 클라이언트 캐시. 분산 저장소 환경에서 InProc 속도를 제공합니다. 예를 들어 분산 저장소가 있다고 가정해 보겠습니다. NCache 클러스터에서 애플리케이션이 실행되고 있으며, 이는 일반적으로 데이터베이스 또는 기타 작업 위에 있는 캐시입니다. 클라이언트 캐시는 일반적으로 분산 캐시 시나리오에서 사용됩니다. 클라이언트 캐시는 이 캐시 클러스터 위에 있는 캐시이며 애플리케이션과 매우 가까이 위치합니다. 애플리케이션 서버 또는 NCache 클라이언트 박스입니다. 또한, 선호도에 따라 InProc 또는 OutProc을 사용할 수도 있습니다. InProc 캐시는 데이터를 역직렬화된 객체 형태로 힙에 보관하기 때문에 매우 빠릅니다. 즉, 해당 객체를 힙에 저장하는 것과 같습니다. 그보다 더 빨라질 수도 있습니다.
따라서 InProc 캐시는 매우 빠르지만 동시에 다음과 동기화된다는 장점이 있습니다. NCache 클러스터입니다. 동기화 방식은 클라이언트 캐시에 저장된 내용에 따라 달라지며, 클러스터는 이를 인지합니다. 따라서 이 클라이언트 캐시에 저장된 내용을 다른 클라이언트가 클러스터에서 업데이트하면, 클러스터는 해당 클라이언트 캐시에 업데이트하도록 알립니다. 그러면 해당 클라이언트 캐시는 비동기적으로 업데이트됩니다. 물론 몇 밀리초 정도의 지연은 있지만, 앞서 말씀드렸듯이 대부분의 경우 최종 일관성(Eventual Consistency)을 보장하는 모델이며, 99%의 경우 일반적으로 허용 가능합니다.
만약 그것이 허용되지 않는다면 NCache ...을 제공합니다. 낙관적 동기화가 기본값으로 설정되어 있는데, 몇 밀리초의 지연이 발생하고 기술적으로 오래된 데이터가 있는 상황이 발생할 수 있습니다. 앞서 말씀드렸듯이 99%의 경우 괜찮습니다. 하지만, 만약 데이터가 매우 민감하지만 클라이언트 캐시를 계속 사용하고 싶다면 비관적 동기화 기능을 사용할 수 있습니다. 이 기능은 애플리케이션이 클라이언트 캐시에서 데이터를 가져오기 전에 클라이언트 캐시가 해당 데이터의 최신 버전만 확인하도록 합니다. 이렇게 하면 데이터를 직접 가져오는 것보다 훨씬 빠르게 호출할 수 있습니다. NCache 여러 버전 정보를 보관합니다. 그리고 해당 데이터의 최신 버전이 있으면 클라이언트 캐시가 가져오고, 그렇지 않으면 클라이언트 캐시에서 다시 가져옵니다.
코드 변경 없이 사용할 수 있는 클라이언트 캐시입니다. 환경에 바로 연결되며, 읽기 작업이 많은 상황에 적합합니다. 읽기 작업이 많을 경우 최소 5:1, 10:1의 비율이 이상적이지만, 웹 세션처럼 1:1의 비율로 처리되는 경우에는 클라이언트 캐시가 전혀 도움이 되지 않습니다. 실제로는 전혀 권장하지 않습니다.
WAN 복제
다중 구역/다중 지역
좋아, 또 다른 부분 NCache 어디인가 NCache 하지 WAN 복제 애플리케이션의 다중 영역 또는 다중 리전 배포를 처리합니다. 예를 들어, 재해 복구(DR)를 위해 애플리케이션을 두 개의 다른 사이트에 배포할 수 있습니다. 하나는 액티브이고 다른 하나는 패시브입니다. 그리고 이 애플리케이션이 있습니다. NCache 실행 중이고, 실행 중이 아닌 애플리케이션이 있습니다. 하지만 이 사이트가 다운될 경우, 즉시 부하를 처리할 수 있도록 해야 합니다. 따라서 브리지를 설치할 수 있습니다. 브리지는 2노드 클러스터 자체로, 동일한 서버에 배치될 수 있습니다. NCache 메인 캐시일 수도 있고, 별도의 전용 캐시일 수도 있습니다. 마음대로 정하면 됩니다. 그리고 이 캐시에서 업데이트하는 내용은 WAN을 통해 다른 캐시로 비동기적으로 복제됩니다. 이것이 액티브-패시브 방식입니다.
액티브-액티브에서도 동일한 작업을 수행할 수 있습니다. 예를 들어, 이 사이트조차 액티브 상태인 경우, 두 사이트가 서로 업데이트할 수 있는 액티브-액티브에서도 동일한 작업을 수행할 수 있습니다. 이 경우 충돌이 해결되거나 발생할 수 있는 상황도 있습니다. 충돌이란 동일한 항목, 동일한 키가 두 사이트에서 동시에 업데이트되는 것을 의미합니다. 이 경우 브리지는 기본적으로 '마지막 업데이트 우선' 논리를 적용합니다. 즉, 업데이트 타임스탬프가 더 늦은 쪽이 우선합니다. 하지만 예를 들어, 브리지가 호출하는 .NET 또는 Java 코드인 충돌 해결 및 충돌 해결 처리기를 제공할 수도 있습니다. 이 처리기는 데이터 또는 객체의 두 복사본을 해당 처리기로 전달합니다. 그런 다음 콘텐츠를 분석하여 어느 것이 더 정확한지 확인할 수 있습니다. 그런 다음 이 업데이트가 우선하고 해당 업데이트가 두 사이트에 모두 적용됩니다. 양쪽에 모두 적용되면 충돌이 발생하지 않습니다.
The NCache 세 개 이상의 사이트를 액티브-액티브, 액티브-패시브, 또는 이들의 조합으로 제공할 수 있습니다. 예를 들어, 최소 하나의 액티브 사이트가 필요하지만, 이 사이트들이 모두 패시브일 수도 있고, 모두 액티브일 수도 있으며, 액티브와 패시브의 조합일 수도 있습니다. 마찬가지로, 액티브 사이트가 두 개 이상인 경우 충돌 해결이 가능합니다.
컨테이너(Docker 및 Kubernetes)
마지막으로, 컨테이너는 Docker와 Kubernetes를 통해 큰 인기를 얻었습니다. 그래서, NCache 물론 지원하는 건 사실입니다. 아직은 .NET이나 Windows보다 Java나 Linux 쪽에서 더 인기가 많으니까요. 하지만 시간이 지나면서 바뀔 거라고 확신합니다. 어쨌든, NCache 두 환경 모두에서 완벽하게 처리할 수 있습니다. 예를 들어, 다음은 일반적인 예입니다. Kubernetes 배포 NCache.
여기에 NCache 배치. 거기에 NCache 자체 Discovery Service가 있습니다. 이는 확장 가능한 Pod이며 Kubernetes 클러스터 내에 다음과 같은 애플리케이션이 있습니다. NCache 클라이언트이며 Azure, AKS, AWS, EKS, Google GKE 또는 Red Hat OpenShift일 수 있습니다. Red Hat OpenShift는 일반적으로 AWS, Azure 또는 Google과 같은 다른 클라우드이거나 다른 클라우드일 수 있지만 NCache 모든 것을 지원합니다. 그리고 이 Pod는 Kubernetes에서 더 일반적인 경우인 Linux일 수 있으며 NCache 완벽하게 작동합니다. 그리고 애플리케이션은 Linux 또는 Windows에서도 실행 가능합니다. 즉, Linux 또는 Windows, Linux 또는 Windows 모두 가능합니다.
Docker / Kubernetes(멀티 존)
WAN 복제가 작동하는 방식과 마찬가지로, 예를 들어 클라우드 덕분에 여러 가용성 영역을 가질 수 있습니다. 즉, 다중 영역 Kubernetes를 구축하려는 것입니다.
따라서 우리가 권장하는 방법은 하나의 Kubernetes 클러스터를 생성하고 두 개를 갖는 것입니다. NCache 배포는 액티브-액티브 또는 액티브-패시브로 구성될 수 있습니다. 브리지는 완전히 여기에 위치하거나, 완전히 여기에 위치할 수 있습니다. 또는 브리지를 분할하여 한 부분은 이 영역에, 다른 부분은 저 영역에 위치하게 한 다음 복제가 비동기적으로 수행되도록 할 수도 있습니다.
오늘 주제는 거의 다 다루었다고 생각합니다. 저희 웹사이트에 오셔서 다음 내용을 살펴보시기를 강력히 추천합니다. NCache 운동장 브라우저에서 라이브 실행 사본을 사용하는 매우 빠르고 쉬운 방법입니다. NCache, 그리고 2노드도 얻을 수 있습니다 NCache 설치가 필요 없는 모든 도구가 포함된 클러스터입니다. 준비가 되셨다면 여기로 오세요. 등록하고 다운로드하세요 중 NCache .NET 에디션용 엔터프라이즈 또는 NCache Java 에디션용 엔터프라이즈 버전입니다. 말씀드린 대로 Linux용 .tar.gz 파일, .msi 파일 또는 Docker 이미지를 다운로드할 수 있습니다. Docker 이미지를 다운로드하면 바로 사용할 수 있습니다. NCache. 이것으로 제 프레젠테이션을 마칩니다. 정말 감사합니다.