Cassandra를 Kubernetes로 마이그레이션: 기능 및 솔루션

우리는 정기적으로 Apache Cassandra 데이터베이스와 이를 Kubernetes 기반 인프라 내에서 운영해야 하는 필요성에 직면합니다. 이 자료에서는 Cassandra를 K8s로 마이그레이션하는 데 필요한 단계, 기준 및 기존 솔루션(운영자 개요 포함)에 대한 비전을 공유합니다.

“여성을 통치할 수 있는 사람은 국가도 통치할 수 있다”

카산드라는 누구입니까? 단일 장애 지점 없이 고가용성을 보장하면서 대용량 데이터를 관리하도록 설계된 분산 스토리지 시스템입니다. 이 프로젝트는 긴 소개가 거의 필요하지 않으므로 특정 기사의 맥락에서 관련된 Cassandra의 주요 기능만 제공하겠습니다.

• 카산드라는 자바로 작성되었습니다.
• Cassandra 토폴로지는 여러 수준을 포함합니다.
  • 노드 - 배포된 Cassandra 인스턴스 XNUMX개.
  • Rack은 동일한 데이터 센터에 위치한 몇 가지 특성으로 통합된 Cassandra 인스턴스 그룹입니다.
  • 데이터 센터 - 하나의 데이터 센터에 위치한 모든 Cassandra 인스턴스 그룹의 모음입니다.
  • 클러스터는 모든 데이터 센터의 집합입니다.
• Cassandra는 IP 주소를 사용하여 노드를 식별합니다.
• 쓰기 및 읽기 작업 속도를 높이기 위해 Cassandra는 일부 데이터를 RAM에 저장합니다.

이제 실제로 Kubernetes로의 전환이 가능해졌습니다.

환승 체크리스트

Cassandra를 Kubernetes로 마이그레이션하는 것에 대해 말하면서, 이전을 통해 관리가 더욱 편리해질 수 있기를 바랍니다. 이를 위해서는 무엇이 필요하며 무엇이 도움이 될까요?

1. 데이터 저장

이미 밝힌 바와 같이 Cassanda는 데이터의 일부를 RAM에 저장합니다. 멤테이블. 그러나 디스크에 저장되는 데이터의 또 다른 부분이 있습니다. SS테이블. 이 데이터에 엔터티가 추가되었습니다. 커밋 로그 — 디스크에도 저장되는 모든 트랜잭션의 기록입니다.

Cassandra에서 트랜잭션 다이어그램 작성

Kubernetes에서는 PertantVolume을 사용하여 데이터를 저장할 수 있습니다. 검증된 메커니즘 덕분에 Kubernetes에서 데이터 작업이 매년 더 쉬워지고 있습니다.

각 Cassandra 포드에 자체 PertantVolume을 할당합니다.

Cassandra 자체는 데이터 복제를 의미하며 이를 위한 내장 메커니즘을 제공한다는 점에 유의하는 것이 중요합니다. 따라서 많은 수의 노드에서 Cassandra 클러스터를 구축하는 경우 데이터 저장을 위해 Ceph 또는 GlusterFS와 같은 분산 시스템을 사용할 필요가 없습니다. 이 경우 다음을 사용하여 호스트 디스크에 데이터를 저장하는 것이 논리적입니다. 로컬 영구 디스크 또는 장착 hostPath.

또 다른 질문은 각 기능 분기에 대해 개발자를 위한 별도의 환경을 만들고 싶은지 여부입니다. 이 경우 올바른 접근 방식은 하나의 Cassandra 노드를 생성하고 데이터를 분산 저장소에 저장하는 것입니다. 언급된 Ceph 및 GlusterFS가 선택 사항이 될 것입니다. 그러면 개발자는 Kuberntes 클러스터 노드 중 하나가 손실되더라도 테스트 데이터가 손실되지 않을 것이라고 확신할 수 있습니다.

2. 모니터링

Kubernetes에서 모니터링을 구현하기 위한 사실상 경쟁의 여지가 없는 선택은 Prometheus입니다. (우리는 이것에 대해 자세히 이야기했습니다. 관련 보고서). Cassandra는 Prometheus용 측정항목 내보내기 기능을 어떻게 사용하고 있나요? 그리고 Grafana용 대시보드 일치에서 더 중요한 것은 무엇입니까?

Cassandra용 Grafana의 그래프 모양 예

수출업체는 단 두 곳뿐입니다. jmx_exporter и cassandra_exporter.

우리는 다음과 같은 이유로 첫 번째 것을 선택했습니다.

1. JMX 내보내기는 성장하고 발전하는 반면 Cassandra 내보내기는 충분한 커뮤니티 지원을 받지 못했습니다. Cassandra 내보내기는 여전히 대부분의 Cassandra 버전을 지원하지 않습니다.
2. 플래그를 추가하여 javaagent로 실행할 수 있습니다. -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. 그를 위한 것이 하나 있다 적절한 대시보드, 이는 Cassandra 내보내기와 호환되지 않습니다.

3. Kubernetes 프리미티브 선택

위의 Cassandra 클러스터 구조에 따라 거기에 설명된 모든 내용을 Kubernetes 용어로 번역해 보겠습니다.

• 카산드라 노드 → 포드
• 카산드라 랙 → StatefulSet
• Cassandra Datacenter → StatefulSets의 풀
• 카산드라 클러스터 → ???

전체 Cassandra 클러스터를 한 번에 관리하기 위해 일부 추가 엔터티가 누락된 것으로 나타났습니다. 하지만 존재하지 않는 것이 있다면 만들 수 있습니다! Kubernetes에는 이러한 목적을 위해 자체 리소스를 정의하는 메커니즘이 있습니다. 사용자 정의 리소스 정의.

로그 및 경고에 대한 추가 리소스 선언

하지만 Custom Resource 자체는 아무 의미도 없습니다. 제어기. 도움을 구해야 할 수도 있습니다 쿠버네티스 운영자...

4. 포드 식별

위 단락에서 우리는 하나의 Cassandra 노드가 Kubernetes의 하나의 포드와 동일하다는 데 동의했습니다. 그러나 포드의 IP 주소는 매번 다릅니다. 그리고 Cassandra의 노드 식별은 IP 주소를 기반으로 합니다. Pod가 제거될 때마다 Cassandra 클러스터는 새 노드를 추가하는 것으로 나타났습니다.

탈출구는 하나가 아니라 다음과 같습니다.

1. 호스트 식별자(Cassandra 인스턴스를 고유하게 식별하는 UUID) 또는 IP 주소별로 기록을 보관하고 이를 일부 구조/테이블에 모두 저장할 수 있습니다. 이 방법에는 두 가지 주요 단점이 있습니다.
   • 두 노드가 동시에 떨어지면 경쟁 조건이 발생할 위험이 있습니다. 상승 후 Cassandra 노드는 동시에 테이블에서 IP 주소를 요청하고 동일한 리소스를 놓고 경쟁합니다.
   • Cassandra 노드의 데이터가 손실되면 더 이상 이를 식별할 수 없습니다.
2. 두 번째 솔루션은 작은 해킹처럼 보이지만 그럼에도 불구하고 각 Cassandra 노드에 대해 ClusterIP를 사용하여 서비스를 생성할 수 있습니다. 이 구현의 문제점:
   • Cassandra 클러스터에 노드가 많으면 서비스도 많이 생성해야 합니다.
   • ClusterIP 기능은 iptables를 통해 구현됩니다. Cassandra 클러스터에 많은(1000... 또는 100?) 노드가 있는 경우 이는 문제가 될 수 있습니다. 하지만 IPVS 기반 밸런싱 이 문제를 해결할 수 있습니다.
3. 세 번째 솔루션은 설정을 활성화하여 전용 포드 네트워크 대신 Cassandra 노드용 노드 네트워크를 사용하는 것입니다. hostNetwork: true. 이 방법에는 다음과 같은 특정 제한 사항이 적용됩니다.
   • 장치를 교체합니다. 새 노드는 이전 노드와 동일한 IP 주소를 가져야 합니다(AWS, GCP와 같은 클라우드에서는 이는 거의 불가능합니다).
   • 클러스터 노드 네트워크를 사용하여 네트워크 리소스를 놓고 경쟁하기 시작합니다. 따라서 하나의 클러스터 노드에 Cassandra가 포함된 포드를 두 개 이상 배치하면 문제가 발생합니다.

5. 백업

우리는 일정에 따라 단일 Cassandra 노드 데이터의 전체 버전을 저장하려고 합니다. Kubernetes는 다음을 사용하여 편리한 기능을 제공합니다. 크론잡, 하지만 여기서 Cassandra 자신이 우리 바퀴에 말을 걸었습니다.

Cassandra는 일부 데이터를 메모리에 저장한다는 점을 상기시켜 드리겠습니다. 전체 백업을 하려면 메모리의 데이터가 필요합니다(멤테이블) 디스크로 이동(SSTable). 이 시점에서 Cassandra 노드는 연결 수락을 중지하고 클러스터에서 완전히 종료됩니다.

그 후에는 백업이 제거됩니다(스냅 사진) 구성표가 저장됩니다(키 스페이스). 그런 다음 백업만으로는 아무것도 제공하지 않는다는 것이 밝혀졌습니다. Cassandra 노드가 담당하는 데이터 식별자를 저장해야 합니다. 이는 특수 토큰입니다.

Cassandra 노드가 담당하는 데이터를 식별하기 위한 토큰 배포

Kubernetes에서 Google로부터 Cassandra 백업을 가져오는 예제 스크립트는 다음에서 찾을 수 있습니다. 이 링크. 스크립트가 고려하지 않는 유일한 점은 스냅샷을 찍기 전에 데이터를 노드로 재설정하는 것입니다. 즉, 현재 상태가 아닌 조금 이전 상태에 대해 백업을 수행하는 것이다. 그러나 이는 노드의 작동을 중단하지 않는 데 도움이 되며 이는 매우 논리적으로 보입니다.

set -eu

if [[ -z "$1" ]]; then
  info "Please provide a keyspace"
  exit 1
fi

KEYSPACE="$1"

result=$(nodetool snapshot "${KEYSPACE}")

if [[ $? -ne 0 ]]; then
  echo "Error while making snapshot"
  exit 1
fi

timestamp=$(echo "$result" | awk '/Snapshot directory: / { print $3 }')

mkdir -p /tmp/backup

for path in $(find "/var/lib/cassandra/data/${KEYSPACE}" -name $timestamp); do
  table=$(echo "${path}" | awk -F "[/-]" '{print $7}')
  mkdir /tmp/backup/$table
  mv $path /tmp/backup/$table
done


tar -zcf /tmp/backup.tar.gz -C /tmp/backup .

nodetool clearsnapshot "${KEYSPACE}"

하나의 Cassandra 노드에서 백업을 수행하기 위한 bash 스크립트의 예

Kubernetes의 Cassandra를 위한 준비된 솔루션

현재 Kubernetes에 Cassandra를 배포하는 데 사용되는 것은 무엇이며, 이들 중 주어진 요구 사항에 가장 적합한 것은 무엇입니까?

1. StatefulSet 또는 Helm 차트 기반 솔루션

기본 StatefulSets 기능을 사용하여 Cassandra 클러스터를 실행하는 것은 좋은 옵션입니다. Helm 차트와 Go 템플릿을 사용하면 사용자에게 Cassandra 배포를 위한 유연한 인터페이스를 제공할 수 있습니다.

이는 일반적으로 노드 오류와 같은 예상치 못한 일이 발생하기 전까지는 잘 작동합니다. 표준 Kubernetes 도구는 위에 설명된 모든 기능을 고려할 수 없습니다. 또한 이 접근 방식은 노드 교체, 백업, 복구, 모니터링 등 더 복잡한 용도로 확장할 수 있는 범위가 매우 제한적입니다.

대표자 :

• 기본 Helm 저장소의 차트;
• 비트나미의 차트.

두 차트 모두 똑같이 훌륭하지만 위에서 설명한 문제가 있습니다.

2. Kubernetes Operator 기반 솔루션

이러한 옵션은 클러스터 관리를 위한 충분한 기회를 제공하므로 더욱 흥미롭습니다. 다른 데이터베이스와 마찬가지로 Cassandra 연산자를 설계하는 경우 Sidecar <-> Controller <-> CRD와 같은 좋은 패턴이 있습니다.

잘 설계된 Cassandra 연산자의 노드 관리 체계

기존 연산자를 살펴보겠습니다.

1. instaclustr의 Cassandra 연산자

• GitHub의
• 준비 상태: 알파
• 라이선스: 아파치 2.0
• 구현 언어: Java

이는 실제로 관리형 Cassandra 배포를 제공하는 회사의 매우 유망하고 적극적으로 개발 중인 프로젝트입니다. 위에서 설명한 대로 HTTP를 통해 명령을 받아들이는 사이드카 컨테이너를 사용합니다. Java로 작성되었으므로 클라이언트 이동 라이브러리의 고급 기능이 부족한 경우가 있습니다. 또한 운영자는 하나의 데이터 센터에 대해 서로 다른 랙을 지원하지 않습니다.

그러나 운영자에게는 모니터링 지원, CRD를 사용한 상위 수준 클러스터 관리, 백업 작성을 위한 문서화 등의 이점이 있습니다.

2. Jetstack의 네비게이터

• GitHub의
• 준비 상태: 알파
• 라이선스: 아파치 2.0
• 구현: Golang

DB-as-a-Service를 배포하도록 설계된 명령문입니다. 현재 Elasticsearch와 Cassandra라는 두 개의 데이터베이스를 지원합니다. RBAC를 통한 데이터베이스 액세스 제어와 같은 흥미로운 솔루션이 있습니다(이를 위해 자체 별도의 Navigator-apiserver가 있습니다). 자세히 살펴볼 가치가 있는 흥미로운 프로젝트이지만 마지막 커밋이 XNUMX년 반 전에 이루어졌기 때문에 잠재력이 확실히 감소했습니다.

3. vgkowski의 Cassandra 연산자

• GitHub의
• 준비 상태: 알파
• 라이선스: 아파치 2.0
• 구현: Golang

저장소에 대한 마지막 커밋이 1.9년 이상 전이었기 때문에 그들은 이를 "심각하게" 고려하지 않았습니다. Operator 개발이 중단되었습니다. 지원되는 것으로 보고된 Kubernetes의 최신 버전은 XNUMX입니다.

4. Rook의 Cassandra 연산자

• GitHub의
• 준비 상태: 알파
• 라이선스: 아파치 2.0
• 구현: Golang

우리가 원하는 만큼 개발이 빠르게 진행되지 않는 운영자입니다. 클러스터 관리를 위해 세심하게 고려된 CRD 구조를 갖추고 있으며 ClusterIP(동일한 "해킹")를 사용하여 서비스를 사용하여 노드를 식별하는 문제를 해결하지만 지금은 그게 전부입니다. 현재는 기본적으로 모니터링이나 백업이 없습니다(그런데 우리는 모니터링을 위해 스스로 가져갔어). 흥미로운 점은 이 연산자를 사용하여 ScyllaDB를 배포할 수도 있다는 것입니다.

주의: 우리는 프로젝트 중 하나에서 이 연산자를 약간 수정하여 사용했습니다. 전체 운영 기간(~4개월 운영) 동안 운영자의 작업에 아무런 문제가 발견되지 않았습니다.

5. 오렌지의 CassKop

• GitHub의
• 준비 상태: 알파
• 라이선스: 아파치 2.0
• 구현: Golang

목록에 있는 가장 어린 운영자: 첫 번째 커밋은 23년 2019월 XNUMX일에 이루어졌습니다. 이미 목록에 있는 수많은 기능이 무기고에 포함되어 있으며, 자세한 내용은 프로젝트 저장소에서 확인할 수 있습니다. 연산자는 널리 사용되는 연산자 SDK를 기반으로 구축되었습니다. 즉시 모니터링을 지원합니다. 다른 연산자와의 주요 차이점은 사용입니다. CassKop 플러그인, Python으로 구현되고 Cassandra 노드 간의 통신에 사용됩니다.

조사 결과

Cassandra를 Kubernetes로 포팅하기 위한 접근 방식과 가능한 옵션의 수는 그 자체로 말해줍니다. 주제는 수요가 많습니다.

이 단계에서는 위험을 감수하고 위의 작업을 시도할 수 있습니다. 개발자 중 누구도 프로덕션 환경에서 솔루션의 100% 작동을 보장하지 않습니다. 그러나 이미 많은 제품이 개발 벤치에서 사용해 볼 가능성이 있어 보입니다.

앞으로는 배에 탄 이 여자가 도움이 될 것 같아요!

PS

블로그에서도 읽어보세요.

• «MongoDB를 Kubernetes로 원활하게 마이그레이션";
• «RabbitMQ를 Kubernetes로 원활하게 마이그레이션";
• «데이터베이스 및 Kubernetes(개요 및 동영상 보고서)";
• «K8s 팁과 요령: 대규모 데이터베이스의 부트스트랩 속도 향상".

출처 : habr.com