카우치베이스 롤링 업그레이드

Couchbase Server의 기능 중 하나는 다운타임 없이 온라인 업그레이드를 수행할 수 있는 기능입니다. 이는 부분적으로 Couchbase의 자동 샤딩 및 리밸런싱 기능 덕분입니다. 이 블로그 게시물에서는 롤링 업그레이드를 수행하는 데 권장되는 접근 방식을 안내합니다. 이러한 접근 방식은 모두 가능한 업그레이드 방법이지만, 모범 사례로 간주되는 순서대로 나열되어 있습니다. 운영의 용이성, 클러스터와 애플리케이션의 온라인 및 운영 상태 유지, 업그레이드가 진행되는 동안 일관된 성능 유지가 우선시됩니다. 물론 이 중 일부는 어떤 사람들의 상황에서는 다른 사람들보다 더 쉬울 것입니다. 하지만 모두 효과가 있을 것입니다.

참고: 여기서의 지침은 테스트를 거쳤으며 기능적인 수준에서 작동하지만, 항상 그렇듯이 프로덕션 클러스터를 업그레이드하기 전에 먼저 자체 테스트 환경에서 선택한 접근 방식을 시도해 보아야 합니다. 업그레이드 후에는 기존 애플리케이션 및 데이터베이스 스모크 테스트 절차를 실행하여 사용 중인 Couchbase의 기능이 필요하고 예상한 대로 계속 작동하는지 확인해야 합니다. 이 절차는 업그레이드 프로세스뿐만 아니라 Couchbase에서 제공하는 새로운 기능에 대해서도 진행해야 합니다. Couchbase와 엔터프라이즈 지원 계약을 체결한 상태에서 업그레이드 전 또는 업그레이드 도중 문제가 발생하여 전반적인 지원이 필요한 경우, 주저하지 말고 Couchbase 지원팀 및/또는 계정 관리자에게 문의하시기 바랍니다. Couchbase 커뮤니티 에디션을 사용하는 경우, 다음이 있습니다. 커뮤니티 포럼 에 도움을 요청하거나 지금처럼 세계적 수준의 지원과 기능을 이용할 수 있는 기회는 없습니다. 엔터프라이즈 에디션이 미션 크리티컬 시스템에 제공하는 기능입니다. 다음과 더불어 not 카우치베이스 지원팀에 액세스할 수 있는 커뮤니티 에디션은 일정 기간(보통 3개월 이상) 코드 개정이 늦어지고, 특정 엔터프라이즈 기능이 포함되지 않으며, 핫픽스가 출시될 때 액세스할 수 없습니다.

참고: Couchbase Server 2.5 Enterprise Edition에는 랙/영역 인식(RZA)이라는 기능이 도입되었습니다. 이 기능은 이 게시물의 범위를 벗어나지만 2.5 이전 버전에서 2.5 이상으로 업그레이드하는 경우 이 기능을 숙지하고 읽어보셔야 합니다. 자세한 내용은 다음을 참조하세요. 랙/영역 인식 를 문서에 추가하세요.

참고: Couchbase 1.8.1에서 2.x로 업그레이드하는 경우 검토해야 할 몇 가지 고유한 기술적 고려 사항이 있습니다. 여기에는 디스크 기반 스토리지에 필요한 디스크 공간을 저장하려는 데이터 양의 2~3배로 증가시키지만 디스크 쓰기 속도를 크게 향상시키는 디스크 기반 스토리지용 추가 전용 데이터 파일 구조의 도입이 포함되지만 이에 국한되지는 않습니다. 자세한 내용은 리소스 요구 사항 섹션을 참조하여 최소한 권장되는 최소한의 서버를 구성했는지 확인하세요. 또한 Perry의 2.0 클러스터 크기 조정에 대한 블로그 게시물 를 클릭해 도움을 요청하세요.

권장 접근 방식 #1, 풀 스왑 리밸런싱:

이 접근 방식은 다음과 같은 프로세스를 사용합니다. 스왑 리밸런싱 를 사용하여 기존 클러스터와 정확히 동일한 수의 새 서버/인스턴스를 추가하고 기존 클러스터를 제거할 수 있습니다. 이 방법은 서버 인스턴스를 비교적 쉽게 확보할 수 있는 퍼블릭 또는 프라이빗 클라우드를 사용하는 조직이나 하드웨어를 완전히 새로 교체하는 사용자에게 특히 유용합니다. 각 새 서버/인스턴스는 기존 서버와 하드웨어 사양이 같거나 더 우수해야 하며, 운영 체제 보안이 강화되고, 대상 업그레이드 버전의 Couchbase Server가 설치되어 있어야 합니다. (RAM을 늘려서 Couchbase의 전체 RAM 할당량을 늘려야 하는 경우 이 프로세스에 도움이 되는 자세한 정보는 아래 섹션을 참조하세요.) 이 업그레이드 방법은 최상의 성능을 제공하며 기존 버전에서 새 버전으로 가장 쉽게 전환할 수 있습니다. 리밸런싱이 완료되면 전체 클러스터가 새 버전을 사용하게 되고 이전 노드는 제거되어 재활용할 준비가 됩니다. 자세한 내용은 다음을 참조하세요. 스왑 리밸런싱 를 참조하세요.

단계:

1) 현재 클러스터에 있는 것과 동일한 수의 새 서버/인스턴스를 확보합니다.
2) 각 새 서버/인스턴스에 대해 운영 체제를 강화하고 대상 버전의 Couchbase Server와 모든 핫픽스를 설치합니다.
3) 다음을 사용하여 클러스터 데이터의 백업을 만듭니다. CB백업 도구를 클릭합니다.
4) DB 노드 중 하나에서 다음을 사용하여 명령줄 호출을 구성해야 합니다. couchbase-cli 명령. 이 글을 쓰는 현재 웹 UI는 클러스터의 모든 기존 노드를 한 번에 교체하는 기능을 지원하지 않습니다. 다음은 4개의 노드를 추가 및 제거하기 위해 실행해야 하는 명령의 예입니다:

이 명령은 지정된 기존 클러스터 노드에 연결하여 온라인 스왑 재조정 프로세스를 시작하여 4개의 새 노드를 추가하고 기존 4개의 노드를 제거합니다. 이 프로세스를 실행하려면 연결을 끊었다가 다시 연결하여 진행 상황을 확인할 수 있도록 화면과 같은 것을 사용해야 합니다. 클러스터 리소스(예: 디스크 I/O, 네트워크 등)의 크기와 사용률에 따라 리밸런싱에 시간이 걸릴 수 있습니다. 또한 리밸런싱은 백그라운드 프로세스로 진행되며 애플리케이션 수준 트래픽에 우선순위를 부여하므로 리밸런싱 시간이 늘어날 수 있습니다. 즉, 클러스터의 규모에 따라 재조정이 실행되는 동안 약간의 성능 저하가 발생할 수 있습니다. 여러 요인에 따라 1시간 이상 걸릴 수도 있습니다. 일반적으로 네트워크와 디스크가 가장 큰 병목 현상이 됩니다. 리밸런싱 모니터링에 대한 아래 섹션을 참조하여 진행 상황을 확인하고 프로세스가 계속 진행 중인지 확인하세요. 또한 이 자리를 빌어 다시 한 번 말씀드리지만 테스트 환경에서 먼저 테스트하여 어떤 일이 일어나고 타이밍이 어떻게 되는지 확인하는 것이 좋습니다.

참고: 일반적으로 리밸런싱이 완료되면 업그레이드된 Couchbase 버전의 새로운 기능을 사용할 수 있습니다. 하지만 일부 기능은 즉시 사용할 수 있습니다.

5) 이제 Couchbase 클라이언트 연결 문자열을 정리해 보겠습니다. 실행 중인 애플리케이션 서버에는 이미 업데이트된 클러스터 맵이 있지만, 해당 애플리케이션 서버를 다시 시작하려면 클러스터에서 새 맵을 가져와야 합니다. 따라서 Couchbase 클러스터에 액세스하는 각 애플리케이션 서버에서 연결 문자열 구성을 편집하여 클러스터 노드의 이전 호스트 이름/IP를 완전히 제거하고 활성 노드가 3개 이상 있는지 확인하세요.

권장 접근 방식 #2, 롤링 스왑 리밸런싱:

이 프로세스는 #1의 변형입니다. 클러스터의 모든 서버/인스턴스를 교체하는 대신, 하드웨어 사양이 같거나 더 나은 새 서버/인스턴스를 하나 이상(하나면 좋고 많을수록 좋습니다) 클러스터에 추가하고 동시에 스왑 리밸런싱 프로세스를 실행합니다. 그런 다음 각 노드가 대상 버전으로 업그레이드될 때까지 이 과정을 반복합니다.

기술적 배경 정보: 서버를 두 개 추가하면 두 개를 제거한다는 점을 기억하세요. 이렇게 하면 리밸런싱에 관련된 노드를 최소화할 수 있습니다. 스왑 리밸런싱에서 노드는 자신의 vBuckets를 새 노드로 복사하고 스왑되는 두 개의 서버만 관여합니다. 예를 들어, 교체하는 것보다 더 많은 서버를 교체하는 경우 클러스터는 모든 노드에서 vBuckets를 섞어야 하며 클러스터의 모든 노드에서 부하 증가를 감수해야 합니다.

단계:

1. 새 서버/인스턴스를 원하는 만큼 확보합니다. 이 단계를 두 번째로 진행하는 경우 이전 단계에서 교체한 다른 서버/인스턴스를 재사용하면 됩니다.
2. 각 인스턴스에 대해 운영 체제를 강화하고 대상 Couchbase 정식 버전과 모든 핫픽스를 설치합니다.
3. 를 사용하여 클러스터 데이터의 백업을 만듭니다. CB백업 도구 일반 절차에 따라
4. Couchbase 웹 콘솔, 서버 노드 탭을 열고 서버 추가 버튼을 클릭한 다음 프로세스에 따라 각각의 새 서버/인스턴스를 클러스터에 추가합니다.
5. 방금 추가한 각 서버에 대해 기존 서버의 제거 버튼을 클릭합니다.
6. 클러스터의 재조정 프로세스를 시작하려면 재조정 버튼을 클릭합니다. 재조정 프로세스는 제거하도록 플래그가 지정된 노드의 모든 데이터를 새 노드로 자동으로 이동합니다.

모든 노드가 새 버전으로 업그레이드될 때까지 이 단계를 반복합니다.

완료되면 Couchbase 클라이언트 연결 문자열을 정리해 보겠습니다. 실행 중인 애플리케이션 서버에는 이미 업데이트된 클러스터 맵이 있지만, 해당 애플리케이션 서버를 다시 시작하려면 클러스터에서 새 맵을 가져와야 합니다. 따라서 Couchbase 클러스터에 액세스하는 각 애플리케이션 서버에서 연결 문자열 구성을 편집하여 클러스터 노드의 이전 호스트 이름/IP를 완전히 제거하고 활성 노드가 3개 이상 있는지 확인하세요.

모든 노드가 동일한 버전을 사용하면 모든 새로운 기능을 사용할 수 있습니다. 스왑 리밸런싱에 대한 일반적인 정보는 다음을 참조하세요. 스왑 리밸런싱.

참고: 여기 예제에서는 Couchbase 웹 콘솔을 사용하지만, REST API 또는 CLI 도구를 사용하여 이 작업을 수행할 수도 있습니다.

권장 접근 방식 #3, 진정한 롤링 업그레이드:

이 프로세스는 조금 더 복잡하며, 클러스터의 크기가 적절하고 업그레이드하는 동안 성능 저하가 거의 또는 전혀 없이 일시적으로 노드가 완전히 손실되는 것을 견딜 수 있는 경우에만 수행해야 한다고 말씀드리는 이유도 여기에 있습니다. 클러스터의 크기가 적절한지 확실하지 않은 경우에는 유지 관리 기간 중간에 하지 말고 미리 조사하여 알아보세요. 이 프로세스를 사용하는 이유는 다른 서버/인스턴스에 액세스할 수 없고 제자리에서 업그레이드를 수행하려는 경우입니다. Couchbase Enterprise 지원 계약을 체결하고 이 프로세스에 대한 도움이 필요한 경우, 이 업그레이드를 계획하는 동안 궁금한 점이 있으면 지원팀에 문의할 수 있습니다.

또한 일반적으로 클러스터 용량(수직 또는 수평)을 추가한 다음 위의 권장 솔루션인 #1 또는 #2를 사용하는 것이 좋을 수 있다는 점을 기억하세요.

단계:

1. 를 사용하여 클러스터 데이터의 백업을 만듭니다. CB백업 도구 일반 절차에 따라
2. 관리자 웹 UI에서 클러스터에서 하나의 노드에 대해서만 제거 버튼을 클릭합니다.
3. 클러스터의 나머지 노드에서 클러스터의 밸런스를 재조정합니다.
4. 서버/인스턴스에서 Couchbase 서버 업그레이드를 대상 버전의 Couchbase와 모든 핫픽스로 수행합니다.
5. 서버 추가 버튼을 클릭하여 업그레이드된 노드를 클러스터에 다시 추가합니다.
6. 재조정 버튼을 클릭하여 클러스터의 재조정 프로세스를 시작합니다. 재조정 프로세스는 클러스터 전체에 vBuckets를 균등하게 분산합니다.

모든 노드가 새 버전으로 업그레이드될 때까지 이 단계를 반복합니다.

리밸런싱 시 세 가지 중요한 항목이 있습니다:

1. 1.8.1에서 2.x로 업그레이드하는 중 어떤 이유로든 리밸런싱이 중지/실패하거나 일시 중지되는 경우, 최소 5분 정도 기다렸다가 다시 시작해야 합니다. 그 이유는 카우치베이스가 노드 간 리밸런싱에 사용하는 네트워크 연결이 일시 중지 또는 예기치 않은 중단 시 정상적으로 종료되지 않기 때문에 리밸런싱이 실패한 후 바로 리밸런싱을 시작하면 더 오래 지속될 수 있기 때문입니다. 그러나 네트워크 연결에 활동이 없는 경우 5분의 시간 제한이 있으므로 최소 5분 정도 기다렸다가 다시 재밸런싱을 시도하는 것이 좋습니다. 버튼을 계속 누르는 것은 득보다 실이 많을 수 있습니다. 2.x에서 상위 버전(예: 2.0.1에서 2.5로)으로 업그레이드하는 경우에는 적용되지 않으며 즉시 재밸런싱을 다시 시작할 수 있습니다.
2. 브라우저 캐시는 부분적으로 제거된 노드를 기억하는 데 사용되므로 재조정을 다시 클릭하기 전에 클러스터가 다음 재조정에 해당 노드를 다시 포함해야 한다고 생각하지 않도록 떠나는 노드를 다시 제거하는 것을 기억하는 것이 중요합니다.
3. 클라이언트 구성 - Moxi와 Couchbase 클라이언트는 모두 실제 클러스터의 일부인 하나 이상의 Couchbase 노드를 가리키도록 구성해야 합니다. 이렇게 구성된 노드를 통해 클러스터의 토폴로지를 수신할 수 있습니다. 클러스터에서 노드의 균형을 재조정할 때 클라이언트가 원래 클러스터의 일부인 노드로 구성되어 있고 새로 추가되는 업그레이드된 노드 중 하나를 가리키는 백업 구성이 있는지 확인하세요. 이렇게 하면 재조정 중에 새 클라이언트 개체가 만들어지더라도 노드가 제거되고 추가될 때 클라이언트가 클러스터에 계속 액세스할 수 있습니다.

리밸런싱 진행 상황 모니터링

물론 리밸런싱 GUI 자체를 통해 모니터링할 수 있지만 중단 여부를 확인하려면 더 자세한 보기가 필요할 수 있습니다. 노드에서 최소한 아래 두 가지 메트릭, 즉 디스크 쓰기 대기열과 활성 vBucket 수를 관찰해야 합니다. Couchbase 2.x에서는 서버 탭 아래에 더 많은 자세한 리밸런싱 메트릭이 있습니다. 또한 리밸런싱하는 동안 Couchbase는 한 번에 하나의 버킷을 이동합니다. 따라서 버킷이 여러 개 있는데 디스크 쓰기 대기열이나 버킷 번호에 활동이 보이지 않는다면 잘못된 버킷을 보고 있는 것일 수 있습니다.

디스크 쓰기 대기열

디스크 쓰기 대기열은 각 노드당 1백만 개 미만이어야 합니다. 이 숫자를 초과하면 노드는 리밸런싱 프로세스 중에 다른 노드가 vbuckets을 보내려고 할 때 백 오프 메시지를 보냅니다. 이는 정상이며 여기서 해야 할 일은 디스크 쓰기 큐가 비워질 때까지 기다렸다가 다시 리밸런싱 작업을 수락하기 시작하는 것뿐입니다. 이를 위한 할당량 구성 가능를 클릭하지만, 이 작업은 자신이 무엇을 하고 있는지 알고 있는 경우에만 수행하세요.

활성 버킷 수

이 숫자는 추가 및 제거되는 노드에서 변경되어야 합니다. 10~20분 동안 이 숫자가 변경되지 않으면 리밸런싱이 중단된 것일 수 있으므로 중지했다가 다시 시작해야 합니다.
???
자세한 내용은 Couchbase 문서에서 리밸런싱 모니터링하기를 참조하세요.

명령줄에서 재조정

이렇게 하면 한 번의 리밸런싱으로 새 노드를 추가하고 기존 노드를 제거할 수 있으므로 웹 콘솔을 사용하는 것보다 조금 더 유연하게 작업할 수 있습니다. 추가할 노드와 제거할 노드를 지정하기 위해 couchbase-cli 명령을 사용하겠습니다. CLI 명령에 대한 자세한 내용은 다음과 같습니다. 여기.

다음과 같은 것을 사용해야 합니다. 화면 또는 아니요 클러스터, 복제본, XDCR 등의 크기에 따라 리밸런싱에 시간이 걸릴 수 있습니다.

클라이언트 SDK 업그레이드

업그레이드와 관련하여 한 가지 더 말씀드리자면, 카우치베이스 클라이언트 SDK는 버그 수정과 새로운 기능이 항상 추가되어 매월 업데이트됩니다. 사용 중인 클라이언트 라이브러리 중 어떤 것이 업데이트되었는지 확인하고 애플리케이션에서 업데이트 대기열에 추가하는 것이 좋습니다. SDK 업데이트에 대한 자세한 내용은 여기를 참조하세요.

클라이언트 SDK에 대해 이야기하는 동안, 각 애플리케이션 서버의 Couchbase 클라이언트 구성 연결 문자열에 최소 2~3개의 클러스터 노드가 있는지 확인하는 것도 좋은 시기입니다.