🥇Cassandra の Kubernetes への移行: 機能とソリューション

私たちは Apache Cassandra データベースと、それを Kubernetes ベースのインフラストラクチャ内で運用する必要性に頻繁に遭遇します。この資料では、Cassandra を K8s に移行するために必要な手順、基準、および既存のソリューション (オペレーターの概要を含む) に関するビジョンを共有します。

「女性を統治できる者は国家も統治できる」

カサンドラって誰？これは、単一障害点のない高可用性を確保しながら、大量のデータを管理するように設計された分散ストレージシステムです。このプロジェクトについて長い紹介はほとんど必要ないので、特定の記事の文脈に関連する Cassandra の主な機能のみを説明します。

Cassandra は Java で書かれています。
Cassandra トポロジには、いくつかのレベルが含まれています。
- ノード - デプロイされた Cassandra インスタンス XNUMX つ。
- ラックは、同じデータセンター内にある、何らかの特性によって結合された Cassandra インスタンスのグループです。
- データセンター - XNUMX つのデータセンターにある Cassandra インスタンスのすべてのグループのコレクション。
- クラスターはすべてのデータセンターの集合です。
Cassandra は IP アドレスを使用してノードを識別します。
書き込みおよび読み取り操作を高速化するために、Cassandra はデータの一部を RAM に保存します。

さて、実際に Kubernetes に移行する可能性があります。

移管時のチェックリスト

Cassandra の Kubernetes への移行について言えば、移行によって管理がより便利になることを期待しています。そのためには何が必要で、何が役立つのでしょうか？

1. データストレージ

すでに明らかになったように、Cassanda はデータの一部を RAM に保存します。 メムテーブル。ただし、データの別の部分がディスクに保存されます。 SSTテーブル。このデータにエンティティが追加されます コミットログ — すべてのトランザクションの記録。ディスクにも保存されます。

Cassandra でトランザクションダイアグラムを作成する

Kubernetes では、PersistentVolume を使用してデータを保存できます。実証済みのメカニズムのおかげで、Kubernetes でのデータの操作は年々簡単になってきています。

独自の PersistentVolume を各 Cassandra ポッドに割り当てます。

Cassandra 自体がデータレプリケーションを暗示しており、そのための組み込みメカニズムを提供していることに注意することが重要です。したがって、多数のノードから Cassandra クラスターを構築している場合は、データストレージに Ceph や GlusterFS などの分散システムを使用する必要はありません。この場合、次を使用してホストディスクにデータを保存するのが論理的です。ローカル永続ディスクまたは取り付け hostPath.

もう XNUMX つの質問は、機能ブランチごとに開発者用に別個の環境を作成するかどうかです。この場合、正しいアプローチは、XNUMX つの Cassandra ノードを起動し、データを分散ストレージに保存することです。前述の Ceph と GlusterFS が選択肢になります。そうすれば、開発者は、Kuberntes クラスターノードの XNUMX つが失われた場合でも、テストデータが失われないことを確信できます。

2. 監視

Kubernetes でモニタリングを実装するための事実上異論のない選択肢は Prometheus です (これについては、関連レポート)。 Cassandra は Prometheus のメトリクスエクスポータをどのように使用していますか? そして、Grafana に対応するダッシュボードについて、さらに重要なことは何でしょうか?

Grafana for Cassandra でのグラフの外観の例

エクスポータは XNUMX つだけです。 jmx_exporter и カサンドラ_エクスポーター.

私たちが最初のものを選んだ理由は次のとおりです。

JMX Exporter は成長し、発展していますが、Cassandra Exporter はコミュニティから十分なサポートを得ることができませんでした。 Cassandra Exporter はまだ Cassandra のほとんどのバージョンをサポートしていません。
フラグを追加することで Javaagent として実行できます -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
彼に一つあります適切なダッシュボード、Cassandra Exporter と互換性がありません。

3. Kubernetes プリミティブの選択

Cassandra クラスターの上記の構造に従って、そこで説明されているすべての内容を Kubernetes 用語に翻訳してみましょう。

Cassandra ノード → ポッド
Cassandra ラック → ステートフルセット
Cassandra データセンター → StatefulSet からのプール
カサンドラクラスター→???

Cassandra クラスター全体を一度に管理するには、追加のエンティティが不足していることが判明しました。しかし、何かが存在しない場合は、それを作成することができます。 Kubernetes には、この目的のために独自のリソースを定義するメカニズムがあります。カスタムリソース定義.

ログとアラート用の追加リソースの宣言

しかし、カスタムリソース自体には何の意味もありません。結局のところ、カスタムリソースには次のことが必要です。 コントローラ。助けを求める必要があるかもしれません Kubernetes オペレーター...

4. ポッドの識別

上の段落では、XNUMX つの Cassandra ノードが Kubernetes の XNUMX つのポッドに相当することに同意しました。ただし、ポッドの IP アドレスは毎回異なります。そして、Cassandra のノードの識別は IP アドレスに基づいています...ポッドが削除されるたびに、Cassandra クラスターは新しいノードを追加することがわかりました。

解決方法は XNUMX つだけではありません。

ホスト識別子 (Cassandra インスタンスを一意に識別する UUID) または IP アドレスごとにレコードを保持し、それをすべていくつかの構造/テーブルに保存できます。この方法には XNUMX つの主な欠点があります。
- XNUMX つのノードが同時にダウンすると競合状態が発生するリスク。上昇後、Cassandra ノードは同時にテーブルから IP アドレスを要求し、同じリソースをめぐって競合します。
- Cassandra ノードのデータが失われると、それを識別できなくなります。
XNUMX 番目の解決策は小さなハックのように見えますが、それでも、Cassandra ノードごとに ClusterIP を使用してサービスを作成できます。この実装の問題点:
- Cassandra クラスター内に多数のノードがある場合、多数のサービスを作成する必要があります。
- ClusterIP 機能は iptables 経由で実装されます。 Cassandra クラスターに多数 (1000... または 100?) のノードがある場合、これが問題になる可能性があります。それでも IPVSに基づくバランシングこの問題を解決できます。
XNUMX 番目の解決策は、設定を有効にして、ポッドの専用ネットワークの代わりに Cassandra ノードのノードのネットワークを使用することです。 hostNetwork: true。この方法には次のような制限があります。
- ユニットを交換するため。新しいノードは前のノードと同じ IP アドレスを持つ必要があります (AWS や GCP のようなクラウドでは、これを行うのはほぼ不可能です)。
- クラスターノードのネットワークを使用して、ネットワークリソースの競合を開始します。したがって、Cassandra を含む複数のポッドを XNUMX つのクラスターノードに配置すると問題が発生します。

5. バックアップ

単一の Cassandra ノードのデータの完全バージョンをスケジュールに従って保存したいと考えています。 Kubernetes は、次のような便利な機能を提供します。クロンジョブしかし、ここではカサンドラ自身が私たちの車輪にスポークを取り付けています。

Cassandra は一部のデータをメモリに保存することを思い出してください。完全バックアップを作成するには、メモリからのデータが必要です (メムテーブル) ディスクに移動 (SSTテーブル）。この時点で、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}"

XNUMX つの Cassandra ノードからバックアップを取得する bash スクリプトの例

Kubernetes の Cassandra 向けのすぐに使えるソリューション

現在、Kubernetes に Cassandra をデプロイするために何が使用されていますか?また、指定された要件に最も適しているのはどれですか?

1. StatefulSet または Helm チャートに基づくソリューション

基本的な StatefulSet 関数を使用して Cassandra クラスターを実行することは、良い選択肢です。 Helm チャートと Go テンプレートを使用すると、Cassandra をデプロイするための柔軟なインターフェイスをユーザーに提供できます。

通常、これは正常に動作します...ノード障害などの予期せぬ事態が発生するまでは。標準の Kubernetes ツールでは、上記のすべての機能を考慮することはできません。さらに、このアプローチは、ノードの交換、バックアップ、リカバリ、監視など、より複雑な用途に拡張できる範囲が非常に限られています。

代表者：

どちらのチャートも同様に優れていますが、上記の問題が発生する可能性があります。

2. Kubernetes Operator をベースとしたソリューション

このようなオプションは、クラスターを管理するための十分な機会を提供するため、より興味深いものになります。 Cassandra オペレーターを設計する場合、他のデータベースと同様に、サイドカー <-> コントローラー <-> CRD のようなパターンが適しています。

適切に設計された Cassandra オペレーターのノード管理スキーム

既存の演算子を見てみましょう。

1. Cassandra - instaclustr のオペレーター

GitHubの
準備状況: アルファ
ライセンス: Apache 2.0
実装言語: Java

これは確かに、マネージド Cassandra デプロイメントを提供する会社による、非常に有望で積極的に開発中のプロジェクトです。上で説明したように、HTTP 経由でコマンドを受け入れるサイドカーコンテナーを使用します。 Java で書かれているため、client-go ライブラリのより高度な機能が欠けている場合があります。また、オペレーターは XNUMX つのデータセンターに対して異なるラックをサポートしていません。

ただし、オペレーターには、監視のサポート、CRD を使用した高度なクラスター管理、さらにはバックアップ作成のための文書化などの利点があります。

2. Jetstack のナビゲーター

GitHubの
準備状況: アルファ
ライセンス: Apache 2.0
実装言語: Golang

DB-as-a-Service を導入するために設計されたステートメント。現在、Elasticsearch と Cassandra の XNUMX つのデータベースをサポートしています。これには、RBAC を介したデータベースアクセス制御などの興味深いソリューションがあります (このために、独自の別個の navigator-apiserver があります)。興味深いプロジェクトであり、詳しく見てみる価値はありますが、最後のコミットが XNUMX 年半前に行われたため、その可能性は明らかに低下しています。

3. Cassandra オペレーター (vgkowski 著)

GitHubの
準備状況: アルファ
ライセンス: Apache 2.0
実装言語: Golang

リポジトリへの最後のコミットは 1.9 年以上前だったため、彼らはそれを「真剣に」考えていませんでした。オペレーターの開発は放棄されました。サポートされていると報告された Kubernetes の最新バージョンは XNUMX です。

4. Cassandra - Rook によるオペレーター

GitHubの
準備状況: アルファ
ライセンス: Apache 2.0
実装言語: Golang

開発が思うように進んでいないオペレーター。クラスター管理用によく考えられた CRD 構造があり、ClusterIP によるサービス (同じ「ハック」) を使用してノードを識別する問題を解決します...しかし、今はここまでです。現在のところ、すぐに使用できる監視やバックアップはありません (ちなみに、私たちは監視を目的としています) 自分たちで取りました）。興味深い点は、この演算子を使用して ScyllaDB をデプロイすることもできることです。

注意: 私たちは、プロジェクトの 4 つでこの演算子を若干の変更を加えて使用しました。全運用期間（約XNUMXか月の運用）を通じて、オペレータの作業に問題は見られませんでした。

5. オレンジのキャスコップ

GitHubの
準備状況: アルファ
ライセンス: Apache 2.0
実装言語: Golang

リストの中で最も若いオペレーター: 最初のコミットは 23 年 2019 月 XNUMX 日に行われました。すでに私たちのリストにある多数の機能がその武器庫にあり、その詳細についてはプロジェクトリポジトリで見つけることができます。オペレーターは、一般的なオペレーター SDK に基づいて構築されています。すぐに使えるモニタリングをサポートします。他の演算子との主な違いは、使用方法です。キャスコッププラグイン、Python で実装され、Cassandra ノード間の通信に使用されます。

所見

Cassandra を Kubernetes に移植するためのアプローチと考えられるオプションの数がそれ自体を物語っています。このトピックは需要があるのです。

現段階では、上記のいずれかを自己責任で試すことができます。どの開発者も、実稼働環境でのソリューションの 100% の動作を保証しません。しかし、すでに多くの製品が開発ベンチで使用してみるのに有望に見えます。

将来、この船上の女性は役に立つと思います！

PS

私たちのブログもお読みください:

出所： habr.com

Cassandra の Kubernetes への移行: 機能とソリューション