Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 5.3
Sv translation
languageen

This page describes how Xpand's architecture is designed for Consistency, Fault Tolerance, and Availability.

Section
Column

Table of Contents

Column
Panel

See also the System Administration Guide on Fault Tolerance and High Availability

Consistency

Many distributed databases have embraced eventual consistency over strong consistency to achieve scalability. However, eventual consistency comes with a cost of increased complexity for the application developer, who must develop for anomalies that may arise with inconsistent data.

Excerpt

Xpand provides a consistency model that can scale using a combination of intelligent data distributionmulti-version concurrency control (MVCC), and Paxos. Our approach enables Xpand to scale writes, scale reads in the presence of write workloads, and provide strong ACID semantics.

For an in-depth explanation of how Xpand scales reads and writes, see Concurrency Control.

Xpand takes the following approach to consistency:

  • Synchronous replication within the cluster. All nodes participating in a write must provide an acknowledgment before a write is complete. Writes are performed in parallel.
  • The Paxos protocol is used for distributed transaction resolution.
  • Xpand supports for Read Committed and Repeatable Read (Snapshot) isolation levels with limited support for Serializable.
  • Multi-Version Concurrency Control (MVCC allows) for lockless reads and ensures that writes will not block reads.

Fault Tolerance

Xpand provides fault tolerance by maintaining multiple copies of data across the cluster. By default, Xpand can accommodate a single node failure and automatically recover with no loss of data. The degree of fault tolerance (nResiliency) is configurable and Xpand can be set up to handle multiple node failures and zone failure. 

For more information, including how to adjust fault tolerance in Xpand, see Understanding Fault Tolerance,  MAX_FAILURES, and Zones.

Availability

In order to understand Xpand's availability modes and failure cases, it is necessary to understand our group membership protocol.

Group Membership and Quorum

Xpand uses a distributed group membership protocol. The protocol maintains two fundamental sets:

  1. The static set of all nodes known to the cluster
  2. The set of nodes that can currently communicate with each other.

The cluster cannot form unless more than half the nodes in the static membership are able to communicate with each other (a quorum). 

For example, if a six-node cluster experiences a network partition resulting in two sets of three nodes, Xpand will be unable to form a cluster.

Image Modified

However, if more than half the nodes are able to communicate, Xpand will form a cluster.

Image Modified

For performance reasons, MAX_FAILURES defaults to 1 to provide for the loss of one node or one zone.

Partial Availability

In the above example, Xpand formed a cluster because a quorum of nodes remained. However, such a cluster could offer only partial availability because the cluster may not have access to the complete dataset.

In the following example, Xpand was configured to maintain two replicas. However, both nodes holding replicas for A are unable to participate in the cluster (due to some failure). When a transaction attempts to access data on slice A, the database will generate an error that will surface to the application.

Image Modified

Availability Requirements

Xpand can provide availability even in the face of failure. In order to provide full availability, Xpand requires that:

  • A majority of nodes are able to form a cluster (i.e. quorum requirement).
  • The available nodes hold at least one replica for each set of data.




Sv translation
languageko

이 페이지에서는 일관성, 내결함성 및 가용성을 위해 ClustrixDB 아키텍처가 어떻게 설계되었는지 설명합니다.

Section
Column

Table of Contents

Column
Panel

Fault Tolerance and High Availability에 대한 시스템 관리 가이드도 참조하십시오.

일관성

다수의 분산 데이터베이스는 확장성을 달성하기 위해 엄격한 일관성 대신 결과적 일관성을 채택했습니다. 그러나, 이러한 선택은 응용 프로그램이 일관성 없는 데이터로 인해 발생할 수 있는 예외를 처리해야 하는 추가 부담이 따릅니다. 결과적 일관성은 응용 프로그램 개발자에게 복잡성 및 개발 비용 증가를 초래합니다.

Excerpt

ClustrixDB는 지능형 Data Distribution, MVCC(multi-version concurrency control) 및 Paxos의 조합을 사용하여 확장할 수 있는 일관성 모델을 제공합니다. 우리의 접근 방식은 ClustrixDB가 쓰기 워크로드가 있는 상태에서 읽기 및 쓰기를 확장하며 강력한 ACID 시멘틱스를 제공할 수 있게 합니다.

ClustrixDB가 읽기 및 쓰기를 확장하는 방법에 대한 자세한 설명은 Concurrency Control을 참조하십시오.

ClustrixDB는 일관성 유지를 위해 다음과 같은 접근 방식을 취합니다.

  • 클러스터 내의 동기식 복제. 쓰기에 참여하는 모든 노드는 쓰기가 완료되기 전에 ACK를 전달해야 합니다. 쓰기는 병렬로 수행됩니다.
  • Paxos 프로토콜은 분산 트랜잭션 해결에 사용됩니다.
  • ClustrixDB는 Serializable에 대한 제한적 지원과 함께 Read Committed 및 Repeatable Read (Snapshot) 격리 수준을 지원합니다.
  • MVCC(Multi-Version Concurrency Control)는 잠금 없는 읽기를 허용하고 쓰기가 읽기를 차단하지 않도록 보장합니다.

내결함성

ClustrixDB는 클러스터 전체에 걸쳐 복수의 데이터 복사본을 유지함으로써 내결함성을 제공합니다. 내결함성의 정도는 다음에 따라 달라집니다.

  • 지정된 복사본 수 (최소 REPLICAS = 2)
  • 데이터 손실 없이 동시에 장애가 발생할 수 있는 노드의 수인 MAX_FAILURES(nResiliency)에 설정된 값

ClustrixDB가 내결함성을 처리하는 방법을 충분히 이해하려면 데이터가 슬라이스라는 논리적 청크로 나누어져 클러스터 전체에 분산되는 데이터 분산 모델에 먼저 익숙해져야 합니다.

다음 섹션에서는 발생 가능한 장애 사례를 다루고 ClustrixDB가 각 상황을 처리하는 방법을 설명합니다. 이 일련의 예제에서는 다음을 가정합니다.

  • 별도의 프론트엔드 및 백엔드 네트워크가 있는 5 노드 클러스터
  • 각각 2개의 복제본을 가진 총 5개의 데이터 슬라이스. 기본 복제본에는 문자(예: A)가 표시되고 보조 복제본에는 아포스트로피(예: A')가 표시됩니다.

Image Added

노드를 사용할 수 없게 되는 경우

예를 들어, 커널 패닉이나 일종의 전원 이벤트와 같이 짧은 시간 동안 노드 사용이 불가능할 수 있습니다. 이 경우 노드는 손실된 노드에서 데이터를 재보호하는 데 걸리는 시간보다 훨씬 빨리 클러스터에서 사용할 수 있게 됩니다 (쿼럼에 참여). 이를 최적으로 처리하기 위해 ClustrixDB는 노드가 클러스터에 다시 참여할 때 재생되는 사용할 수 없는 노드의 데이터에 대한 변경 로그 설정을 제공합니다.

노드가 사라지면 시스템은 재보호 조치를 시작하기 전에 10분 동안 대기하여 노드가 온라인 상태로 되돌아갈 시간을 허용합니다. 이 기본 내부 동작은 전역 변수 rebalancer_reprotect_queue_interval_s를 수정하여 변경할 수 있습니다.

노드에는 다른 노드와 통신하여 노드가 온라인 상태인지 확인하는 하트비트 프로세스가 있습니다. 이 프로세스는 매초마다 발생합니다. 노드가 온라인 상태가 아니면 클러스터는 사용할 수 없는 노드를 제외하여 새 그룹을 구성하고 rebalancer_reprotect_queue_interval_s 타이머가 시작됩니다. rebalancer_reprotect_queue_interval_s에 설정된 시간이 지나고 나면 클러스터는 장애 노드에서 재보호를 시작합니다. 재보호 프로세스를 모니터링하는 방법에 대한 추가 내용은 Managing the Rebalancer를 참조하십시오.

클러스터가 장애 노드의 데이터를 완전히 재보호하면 Full Protection Restored를 나타내는 Database Alert가 발송됩니다. 그런 다음, 클러스터는 다른 노드 장애를 안전하게 수용할 수 있습니다.

처리 중인 쿼리에 노드 손실이 미치는 영향

노드 손실은 응용 프로그램에 다음과 같은 영향을 줍니다. 모든 슬라이스에 2개 이상의 복사본이 있으므로 슬라이스의 각 복제본이 쓰기(write)마다 쓰이고 순위가 매겨진 읽기 복제본은 읽기 실행 중에 읽힙니다. 이러한 복제본이 장애 노드에 있는 경우 쿼리가 재시도 되어야 합니다. 순위가 매겨진 복제본이 장애 노드에 있는 경우 새 복제본이 만들어질 때까지 나머지 복제본 중 하나가 순위가 매겨진 복제본이 됩니다. 이 복제본을 대상으로 한 쿼리는 재시도 되어야 합니다. 단일 명령문 트랜잭션의 경우에는 자동 내부재시도 메커니즘이 있으며 이러한 경우에는 클라이언트에 투명하게 재시도합니다. 노드 장애 시 잇따른 그룹 변경으로 인해 진행 중인 모든 쿼리는 메뉴얼로 재시도 되어야 합니다.

노드의 영구적인 손실

이 예제에서 노드 #2는 영구적인 하드웨어 장애로 인해 사용할 수 없게 됩니다. 장애 노드의 데이터는 나머지 클러스터에서 더 이상 액세스할 수 없습니다. 그러나, 시스템 내의 다른 노드에는 해당 데이터의 복사본이 있습니다. 데이터베이스는 나머지 노드로 그룹을 자동으로 생성하고 백그라운드에서 Rebalancer는 자동으로 일부 데이터가 충분히 보호되지 않음을 감지하고 그 데이터 복사본을 충분히 생성합니다. 아래 다이어그램은 ClustrixDB가 노드 장애로부터 어떻게 복구되는지 보여줍니다.

  • 단일 장애 노드의 복구에 여러 노드가 참여합니다.
    • ClustrixDB에서 데이터 재보호는 대다대 작업입니다. 더 많은 노드를 가진 클러스터는 노드 장애로부터 더 빨리 복구될 수 있습니다.
  • 클러스터가 슬라이스 A와 C의 새 복사본을 만들면 각 슬라이스의 복제본 2개가 있는 완전히 보호된 시스템을 갖게 됩니다.
    • 클러스터는 이제 장애 노드를 교체하지 않고도 다른 장애를 처리할 수 있습니다.
Panel
titleClustrixDB는 영구적인 노드 장애를 처리합니다. 장애 상태 (왼쪽) 및 복구된 상태 (오른쪽).

Image Added

Rebalancer가 재보호 프로세스를 완료하면 A와 C의 두 개의 복사본이 생깁니다. 이 프로세스 중에 데이터베이스는 온라인 상태를 유지합니다.

추가 복제본 구성

기본적으로 모든 테이블은 REPLICAS = 2로 생성되고 단일 노드가 영구적으로 손실되더라도 클러스터는 어떠한 데이터도 잃지 않게 됩니다. 클러스터에 대해 MAX_FAILURES 레벨을 설정하고 테이블에 대한 추가 복제본을 구성하면 여러 개의 노드 장애가 발생하더라도 클러스터는 데이터 손실 없이 사용 가능한 상태가 되도록 보장할 수 있습니다. MAX_FAILURES 설정 방법에 대한 추가 내용을 확인하십시오.

노드 임시 사용 불가

예를 들어, 커널 패닉이나 일종의 전원 이벤트와 같이 짧은 시간 동안 노드를 사용할 수 없을 수 있습니다. 이 경우 노드는 손실된 노드에서 데이터를 재보호하는 데 걸리는 시간보다 훨씬 빨리 클러스터에서 사용할 수 있게 됩니다 (쿼럼에 참여). ClustrixDB는 노드가 클러스터에 다시 참여할 때 재생되는 사용할 수 없는 노드의 데이터에 대한 변경 로그를 설정하여 이 시나리오에 대한 특별한 처리방법을 제공합니다.

아래 예제에서 노드 #4는 일시적으로 클러스터를 떠나게 됩니다. 노드 #2 및 노드 #5는 노드 #4의 데이터 변경을 추적하기 위해 로그(큐)를 설정합니다. 노드 #4가 클러스터로 돌아오면 로그된 변경 사항을 재생합니다. 이러한 모든 작업은 데이터베이스에 의해 자동으로 처리됩니다.

Panel
titleClustrixDB는 일시적 노드 장애를 처리합니다. 장애 상태 (왼쪽) 및 복구된 상태 (오른쪽).

Image Added

노드 4는 잠시 동안 사용이 불가능했고 클러스터에 다시 참여합니다. 노드 4가 완전히 온라인 상태가 되기 전에 노드의 데이터에 영향을 주는 트랜잭션이 재생됩니다.


프론트엔드 네트워크 장애

ClustrixDB는 중복 프론트엔드 네트워크 구성을 권장합니다. 이렇게 하면 완전한 프론트엔드 네트워크 장애 가능성이 크게 줄어듭니다. 그러한 장애가 일어나는 경우 장애 노드는 계속해서 쿼리 처리에 참여하지만 응용 프로그램에서 들어오는 연결을 받아들이지는 않습니다.

백엔드 네트워크 장애

ClustrixDB는 백엔드 네트워크 장애와 노드 장애를 구별하지 않습니다. 노드가 백엔드 네트워크의 피어와 통신할 수 없는 경우 하트비트 검사에 실패하고 시스템은 노드를 오프라인 상태로 간주합니다.

가용성

ClustrixDB의 가용성 모드 및 장애 사례를 이해하려면 그룹 멤버십 프로토콜을 이해해야 합니다.

그룹 멤버십 및 쿼럼

ClustrixDB는 분산된 그룹 멤버십 프로토콜을 사용합니다. 이 프로토콜은 두 가지 기본 집합을 유지합니다.

  1. 클러스터에 알려진 모든 노드의 정적 집합
  2. 현재 서로 통신할 수 있는 노드 집합

정적 멤버십 노드 중 절반 이상이 서로 통신할 수 없으면 클러스터를 구성할 수 없습니다.

예를 들어, 6 노드 클러스터에 네트워크 파티션이 발생하여 세 개의 노드를 가진 두 개의 집합이 생성되면 ClustrixDB는 클러스터를 구성할 수 없습니다.

Image Added

그러나, 노드의 절반 이상이 통신할 수 있는 경우 ClustrixDB는 다수 집합으로 클러스터를 구성합니다.

Image Added

쿼럼 요구 사항 때문에 MAX_FAILURES 값은 N/2+1 이상이어야 합니다.

부분 가용성

위의 예제에서 ClustrixDB는 쿼럼을 구성할 수 있었기 때문에 클러스터를 형성했습니다. 그러나, 클러스터가 완전한 데이터 집합에 액세스할 수 없을 수도 있으므로 이러한 클러스터는 부분적 가용성만 제공할 수 있습니다.

다음 예제에서 ClustrixDB는 두 개의 복제본을 유지하도록 구성되었습니다. 그러나, A에 대한 복제본을 보유한 두 노드 모두는 클러스터에 참여할 수 없습니다 (일부 장애로 인해). 트랜잭션이 슬라이스 A의 데이터에 액세스하려고 하면 데이터베이스는 응용 프로그램에 오류를 발생시킵니다.

Image Added

가용성 요구 사항

ClustrixDB는 장애 시에도 가용성을 제공할 수 있습니다. 완전한 가용성을 제공하기 위해 ClustrixDB는 다음 사항을 요구합니다.

  • 과반수의 노드는 클러스터(즉, 쿼럼 요구 사항)를 구성할 수 있습니다.
  • 사용 가능한 노드는 각 데이터 집합에 대한 복제본을 하나 이상 보유합니다.