Fast Failover with Couchbase Server 5.0

빠른 장애 복구는 릴리스와 함께 제공되는 많은 개선 사항 중 하나입니다. 카우치베이스 서버 5.0 (현재 다운로드 가능).

장애 복구는 분산 데이터베이스와 관련하여 이해해야 할 중요한 개념 중 하나입니다. CAP 정리 는 분산 데이터베이스가 두 가지를 모두 사용할 수 없음을 나타냅니다. 그리고 일관성 모두 의 시간을 절약할 수 있습니다. Couchbase Server의 아키텍처는 다음과 같이 설계되었습니다. 항상 일관성, 파티션 내성을 제공합니다. 빠른 페일오버를 통해 Couchbase Server는 다음과 같은 부분에서 격차를 좁히고 있습니다. 고가용성.

이 블로그 게시물에서는 장애 조치를 실제로 시연해 보겠습니다. Docker를 사용하여 로컬 머신에 3개의 Couchbase 노드로 구성된 클러스터를 만들겠습니다.

이 블로그 게시물에서 코드 샘플을 따라할 수 있습니다. GitHub에서 사용 가능.

빠른 페일오버 개요

약간의 설정과 준비가 필요합니다.

먼저 3노드(최소) 이상의 Couchbase Server 클러스터를 만듭니다. 이를 수행하는 방법에는 다음과 같은 여러 가지가 있습니다. 방랑자가상 머신, 실제 머신, Azure등 다양한 기능을 제공합니다.

저는 Docker를 사용하기로 했습니다. 블로그에 다음과 같은 방법을 소개했습니다. Docker에서 Couchbase 클러스터를 만들고 .NET Core 애플리케이션으로 액세스합니다. (브리지 네트워크를 잊지 마세요!). 그래서 저는 동일한 지침을 다시 따랐습니다. 유일한 차이점은 ASP.NET 애플리케이션 대신 콘솔 애플리케이션을 사용했다는 점입니다(자세한 내용은 이 글의 뒷부분에서 확인할 수 있습니다).

Three Couchbase Server nodes

저는 Docker Hub의 Couchbase Server 5.0.0-beta2 이미지이 글을 읽으실 때쯤이면 Couchbase Server 5.0의 공식 릴리스가 출시될 것입니다. 공식 도커 카우치베이스 리포지토리에서 사용할 수 있습니다..

다음으로, "mybucket"이라는 버킷을 만들었습니다. 동일한 클러스터 내에서 데이터의 추가 복사본을 만들 수 있도록 복제본을 사용하도록 설정하세요.

Couchbase Server bucket

그런 다음, 'mybucket'에 대한 데이터 작성자 및 데이터 리더 권한 이상을 가진 사용자(저는 'myuser'라고 부릅니다)를 만듭니다.) 아직 카우치베이스 서버에 익숙하지 않은 경우 역할 기반 액세스 제어(RBAC)로 시작하여 RBAC 및 .NET을 사용한 인증에 대한 이 블로그 게시물을 참조하세요.

Couchbase Server user

마지막으로 자동 빠른 장애 조치를 켭니다. Couchbase 콘솔에서 설정으로 이동한 다음 자동 장애 조치로 이동합니다. "자동 장애 조치 사용" 확인란을 선택합니다. 버전 5.0부터는 시간 초과 값을 5(초)까지 낮게 설정할 수 있습니다. 이전에는 이 값을 최소 30초로 설정해야 했습니다.

Enable fast failover

자동 장애 조치가 기본적으로 꺼져 있는 데에는 이유가 있습니다. 전체 내용을 검토하세요. 자동 장애 조치에 대한 문서 를 통해 자신에게 적합한지 확인하세요.

.NET 예제

이제 Docker 호스트 내부에서 3노드 클러스터가 실행 중이므로 데모 애플리케이션을 작성할 차례입니다. 저는 Couchbase에 대해 지속적으로 읽기를 수행하는 콘솔 애플리케이션을 작성하기로 결정했습니다. 어느 시점에서 노드 중 하나에서 "플러그를 뽑아" 자동 고속 장애 복구가 작동하는 것을 보여줄 것입니다.

클러스터에 연결하기

Visual Studio에서 새 .NET Core 콘솔 응용 프로그램을 만든 후 다음을 추가했습니다. NuGet을 사용하는 Couchbase .NET SDK(현재 버전 2.5.1).

그런 다음 3노드 클러스터에 연결하고, "myuser"로 인증하고, "mybucket"을 열도록 구성을 만들었습니다.

var clientConfig = new ClientConfiguration
{
    Servers = new List<Uri>
    {
        new Uri("http://172.17.0.2"),
        new Uri("http://172.17.0.3"),
        new Uri("http://172.17.0.4")
    }
};
var cluster = new Cluster(clientConfig);

var credentials = new PasswordAuthenticator("myuser", "password");
cluster.Authenticate(credentials);

_bucket = cluster.OpenBucket("mybucket");

var clientConfig = new 클라이언트 구성

{

서버 = new 목록<Uri>

{

new Uri("http://172.17.0.2"),

new Uri("http://172.17.0.3"),

new Uri("http://172.17.0.4")

}

};

var 클러스터 = new 클러스터(clientConfig);

var 자격 증명 = new 비밀번호 인증기("myuser", "비밀번호");

클러스터.인증(자격 증명);

_버킷 = 클러스터.OpenBucket("mybucket");

이러한 IP 주소는 다음과 같은 주소입니다. 내부 를 Docker 호스트에 추가합니다. 이 .NET Core 애플리케이션은 해당 IP 주소가 확인되는 Docker 호스트 내부에서도 실행됩니다. From 외부 를 도커 호스트에 지정하면 "localhost:8091"만 확인됩니다(도커 호스트의 튜토리얼 이전에 링크했습니다). Docker를 사용하지 않는 경우 대신 Azure 머신, 가상 머신 등의 IP 주소를 입력하세요.

다음, 비밀번호 인증 는 버킷 액세스를 보장하는 데 사용됩니다.

마지막으로 다음을 사용하여 버킷 객체를 가져옵니다. OpenBucket.

문서 설정

이 데모에서는 나중에 반복적으로 읽을 여러 개의 문서를 설정해 보겠습니다. 먼저 루프를 작성하여 임의의 수의 문서를 만들고 각 문서에 "documentKey[num]"과 같은 키(예: "documentKey1", "documentKey2" 등)를 갖도록 했습니다.

var docKeys = new List<string>();
for (var i = 0; i < numDocuments; i++)
{
    var key = "documentKey" + i;
    docKeys.Add(key);
    _bucket.Upsert(key, new { name = "Document" + i });
}

var docKeys = new 목록<문자열>();

에 대한 (var i = 0; i < 숫자 문서; i++)

{

var 키 = "documentKey" + i;

docKeys.추가(키);

_버킷.Upsert(키, new { 이름 = "문서" + i });

}

내 코드에서, 숫자 문서 는 50으로 설정되어 있습니다. 하지만 다른 숫자로 설정하고 어떤 일이 발생하는지 확인해 보세요.

문서 읽기

따라서 잘 알려진 키가 있는 50개의 문서가 있습니다. 나머지 프로그램은 계속 반복됩니다. 각 루프 반복은 50개의 문서를 모두 가져오려고 시도합니다.

var iteration = 0;
while (true)
{
    Console.WriteLine($"Getting {numDocuments} documents [{iteration++}]");
    foreach(var docKey in docKeys)
    {
        var result = _bucket.Get<dynamic>(docKey);
        if(terse)
            ShowResultTerse(result, docKey);
        else
            ShowResult(result, docKey);
    }
    Console.WriteLine();

    Thread.Sleep(2000);
}

var 반복 = 0;

동안 (true)

{

콘솔.WriteLine($"{numDocuments} 문서 가져오기 [{iteration++}]");

foreach(var docKey in docKeys)

{

var 결과 = _버킷.Get<동적>(docKey);

만약(간결한)

ShowResultTerse(결과, docKey);

else

결과 표시(결과, docKey);

}

콘솔.WriteLine();

스레드.수면(2000);

}

먼저 루프 안에 루프가 있는 것을 확인합니다. 내부 루프는 50회 실행되어 Get 를 클릭합니다. 결과 표시 를 호출하면 콘솔에 무슨 일이 일어나고 있는지 출력합니다(ShowResultTerse 는 훨씬 더 간결한 방식으로 동일한 기능을 수행합니다. 결과 표시 은 아래와 같지만 이후 스크린샷에서는 ShowResultTerse).

private static void ShowResult(IOperationResult<dynamic> result, string id)
{
    // happy path, document was found
    if (result.Success)
    {
        Console.WriteLine("Result: success");
        return;
    }

    // error, possibly node down
    // show error, try to get replica
    Console.WriteLine($"Result: unsuccessful {result.Message}");
    Console.WriteLine("\tAttempting to get replica.");

    var replica = _bucket.GetFromReplica<dynamic>(id);

    // happy path for replica, it was found
    if (replica.Success)
    {
        Console.WriteLine("\tReplica result: success");
        return;
    }

    // error! replication may not be configured
    // or it's possible something catastrophic happened
    // this should be rare, but definitely want to log it
    // maybe retry and/or escalate
    // in this example, it's just logged to console
    Console.WriteLine("\tReplica result unsuccessful: {result.Message}");
}

비공개 정적 void 결과 표시(IOperationResult<동적> 결과, 문자열 id)

{

// 행복한 길, 문서가 발견됨

만약 (결과.성공)

{

콘솔.WriteLine("결과: 성공");

반환;

}

// 오류, 노드 다운 가능성

// 오류 표시, 복제본 가져오기 시도

콘솔.WriteLine($"결과: 실패한 {result.Message}");

콘솔.WriteLine("\t복제본을 가져오려고 합니다.");

var 복제본 = _버킷.GetFromReplica<동적>(id);

// 복제본에 대한 행복한 경로가 발견되었습니다.

만약 (복제본.성공)

{

콘솔.WriteLine("\t복제 결과: 성공");

반환;

}

// 오류! 복제가 구성되지 않았을 수 있습니다.

// 또는 치명적인 일이 발생했을 수 있습니다.

// 이것은 드물지만 반드시 기록해야 합니다.

// 재시도 및/또는 에스컬레이션 가능

// 이 예제에서는 방금 콘솔에 로그되었습니다.

콘솔.WriteLine("\t복제 결과가 실패했습니다: {result.Message}");

}

댓글은 따라하는 데 도움이 되지만 결과 표시 는 세 가지 검사를 수행합니다:

읽기에 성공했나요? 그렇다면 출력하세요. 완료! 그렇지 않으면...
(다른 노드에서) 복제본을 가져옵니다. 성공했나요? 그렇다면 출력하세요. 완료! 그렇지 않으면...
애플리케이션이 문서 또는 그 복제본 중 하나를 읽을 수 없습니다. 이 예에서는 매우 드문 경우입니다. 실제로는 문서가 존재하지 않거나 복제가 올바르게 구성되지 않았거나 다른 문제가 발생했음을 의미할 수 있습니다.

이제 애플리케이션을 실행할 준비가 되었습니다. 도커를 사용하는 경우 이 애플리케이션을 도커에서 실행하는 것을 잊지 마세요( 비주얼 스튜디오에서 쉽게). (또한 .NET Core 애플리케이션 컨테이너를 Docker 브리지 네트워크에 연결해야 합니다).

플러그를 뽑으세요!

노드 중 하나에서 플러그를 뽑기 전에 위의 .NET Core 애플리케이션을 실행할 때 "정상적인" 출력이 무엇인지 살펴봅시다.

아래 GIF에서 확인할 수 있습니다:

3노드 카우치베이스 서버 클러스터
Visual Studio로 전환
CTRL+F5로 Docker 컨테이너를 빌드하고 시작하기
Docker 컨테이너의 (간결한) 콘솔 출력

Console output from Docker

(애니메이션 속도를 약간 높였습니다). "S"가 50번 표시되는 것을 볼 수 있습니다. 이는 각 문서가 성공적으로 검색되었음을 의미합니다.

다음으로 빠른 장애 복구가 실제로 작동하는 모습을 보여드리겠습니다. 노드 중 하나에서 "플러그를 뽑아보겠습니다." Docker를 사용하면 다음을 실행할 수 있습니다. 도커 스톱 DB2를 예로 들 수 있습니다.

한 번에 추적해야 할 사항이 많기 때문에 무슨 일이 일어나고 있는지 보여주는 짧은 동영상을 만들었습니다.

[유튜브 https://www.youtube.com/watch?v=KbU5eG2R9XU&w=700&h=394]

이 동영상에서 보고 계신 내용은 다음과 같습니다:

정상 작동(성공 시 모두 "S")
중지 중인 노드(도커 사용)
카우치베이스가 노드가 다운된 것을 감지합니다.
복제본을 활성화하기 위해 빠른 페일오버를 시작하는 카우치베이스.
장애 조치 기간 동안에는 더 이상 모두 "S"가 아닙니다. 복제본(읽기 전용)을 위한 "R"도 일부 있습니다.
장애 조치가 완료되면 결과는 다시 모든 'S'로 돌아갑니다.

빠른 장애 조치의 목표는 모든 문서를 완전히 사용할 수 없는 기간을 줄이는 것입니다.

요약

Couchbase Server 5.0은 네트워킹이 잘 갖춰진 환경에 유용한 '빠른 장애 조치' 옵션으로 장애 조치 기능을 개선했습니다.

이 블로그 게시물은 빠른 장애 조치를 시연하기 위한 콘솔 앱을 보여줍니다. 이 앱은 그다지 유용한 앱은 아니지만, 원칙을 가져와 ASP.NET 또는 ASP.NET Core 웹사이트에 적용할 수 있습니다.

확인 카우치베이스 서버 5.0 에서 이 기능 및 기타 새로운 기능에 대해 알아보세요.

특별 감사 대상 제프 모리스 그리고 이 블로그 포스팅을 도와주신 SDK 팀에게 감사드립니다!

빠른 장애 조치에 대한 자세한 내용은 다음 링크를 참조하세요:

그리고 SDK RFC 를 사용하세요. 이 문서에서는 .NET뿐만 아니라 Java, libcouchbase 및 Go에 대해서도 다룹니다.
자동 장애 조치 문서 Couchbase Server용.
.NET Core 콘솔 앱의 소스 코드 이 블로그 게시물에 사용됨 (깃허브)
.NET 빠른 장애 조치를 위한 2개의 JIRA 티켓: NCBC-1366 그리고 NCBC-1388.

장애 조치에 대한 질문이나 의견이 있는 경우 카우치베이스 포럼.

.NET과 카우치베이스에 관한 모든 질문과 의견을 남겨주시거나 다음에서 저를 찾아주세요. 트위터 @mgroves.

매튜 그로브스

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

모든 게시물

카우치베이스 서버 5.0을 사용한 빠른 장애 조치