Kubernetes のストレージ: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

アップデート！。 コメントで、読者の一人が試してみることを提案しました リンスター （おそらく彼自身がそれに取り組んでいるでしょう）そのため、この解決策に関するセクションを追加しました。 私も書きました インストール方法を投稿する、プロセスが他のプロセスとは大きく異なるためです。

正直、諦めてしまいました Kubernetes （少なくとも今のところは）。 私が使用します ヘロク。 なぜ？ 保管場所のせいで！ 私が Kubernetes 自体よりもストレージをいじることになるとは誰が想像したでしょうか。 私が使う ヘッツナークラウド安価でパフォーマンスが良いため、最初から次を使用してクラスターをデプロイしてきました。 ランチャー。 すべてを自分で学びたかったので、Google/Amazon/Microsoft/DigitalOcean などのマネージド Kubernetes サービスは試しませんでした。 私も倹約家です。

そうですね、Kubernetes スタックの候補を評価するときに、どのストレージを選択するかを決めるのに多くの時間を費やしました。 私は価格の理由だけでなく、オープンソース ソリューションを好みますが、制限付きの無料バージョンがあるため、好奇心からいくつかの有料オプションを調べました。 さまざまなオプションを比較した最近のテストからいくつかの数値を書き留めました。Kubernetes ストレージについて学習している人にとっては興味深いかもしれません。 私個人としては、今のところ Kubernetes とは別れを告げていますが。 私も言及したいと思います CSIドライバーHetzner Cloud ボリュームを直接プロビジョニングできますが、まだ試していません。 特にノード障害や他の同様の状況の場合に備えて、レプリケーションと任意のノードに永続ボリュームを迅速にマウントする機能が必要だったので、クラウド ソフトウェア デファインド ストレージを検討しました。 一部のソリューションでは、ポイントインタイムのスナップショットとオフサイトのバックアップが提供されており、これは便利です。

6 ～ 7 個のストレージ ソリューションをテストしました。

OpenEBS

すでに言ったように 前回の投稿でリストのほとんどのオプションをテストした結果、最初は OpenEBS に落ち着きました。 OpenEBS はインストールも使用も非常に簡単ですが、正直に言うと、負荷をかけた実際のデータでテストした後、そのパフォーマンスにはがっかりしました。 これはオープンソースであり、開発者は独自に開発しています スラックチャンネル 助けが必要なときはいつもとても役に立ちました。 残念ながら、他のオプションと比較してパフォーマンスが非常に低いため、テストを再実行する必要がありました。 OpenEBS には現在 3 つのストレージ エンジンがありますが、cStor のベンチマーク結果を掲載します。 Jiva と LocalPV の数字はまだありません。

一言で言えば、Jiva は若干高速であり、LocalPV は一般的に高速であり、ディスク ベンチマークと直接比べても劣りません。 LocalPV の問題は、ボリュームが作成されたノード上でのみボリュームにアクセスでき、レプリケーションがまったく行われないことです。 バックアップを復元する際に問題が発生しました ヨット ノード名が異なっていたため、新しいクラスター上で実行されました。 バックアップについて言えば、cStor には Velero 用プラグインを使用すると、ある時点でのスナップショットのオフサイト バックアップを作成でき、Velero-Restic を使用したファイル レベルのバックアップよりも便利です。 私が書いた いくつかのスクリプト, このプラグインを使用してバックアップと復元を簡単に管理できるようにします。 全体として、私は OpenEBS がとても気に入っていますが、そのパフォーマンスは...

ルーク

Rook もオープンソースであり、リストの他のオプションと異なる点は、さまざまなバックエンドで複雑なストレージ管理タスクを処理するストレージ オーケストレーターであることです。 セフ, EdgeFS など、作業が大幅に簡素化されます。 数か月前に EfgeFS を試したときに問題が発生したため、主に Ceph でテストしました。 Cephはブロックストレージだけでなく、S3/Swiftと互換性のあるオブジェクトストレージや分散ファイルシステムも提供します。 Ceph で気に入っている点は、ボリューム データを複数のディスクに分散して、単一のディスクに収まるよりも多くのディスク領域をボリュームで使用できることです。 快適ですよ。 もう XNUMX つの優れた機能は、クラスターにディスクを追加すると、すべてのディスクにデータが自動的に再分散されることです。

Ceph にはスナップショットがありますが、私の知る限り、それらを Rook/Kubernetes で直接使用することはできません。 確かに、私はこれについては深く掘り下げませんでした。 ただし、オフサイトのバックアップはないため、Velero/Restic を使用する必要がありますが、存在するのはファイルレベルのバックアップのみで、ポイントインタイムのスナップショットはありません。 私が Rook で本当に気に入ったのは、Ceph との連携がいかに簡単かということでした。Rook は、ほとんどすべての複雑な要素を隠し、トラブルシューティングのために Ceph と直接通信するためのツールを提供します。 残念ながら、Ceph ボリュームのストレス テスト中、次の問題が引き続き発生しました。 この問題これにより、Ceph が不安定になります。 これが Ceph 自体のバグなのか、それとも Rook による Ceph の管理方法の問題なのかはまだ明らかではありません。 メモリの設定をいじってみたら改善されましたが、完全に解決したわけではありません。 以下のベンチマークでわかるように、Ceph はまともなパフォーマンスを発揮します。 ダッシュボードも充実しています。

ランチャー ロングホーン

ロングホーンが本当に好きです。 私の意見では、これは有望な解決策です。 確かに、開発者自身 (Rancher Labs) は、まだ作業環境に適していないことを認めており、これが示しています。 これはオープンソースであり、適切なパフォーマンスを備えていますが (まだ最適化されていませんが)、ボリュームがポッドに接続するのに非常に時間がかかり、最悪の場合、特に大規模なバックアップやデータを復元した後は 15 ～ 16 分かかります。ワークロードのアップグレード。 スナップショットとこれらのスナップショットのオフサイト バックアップがありますが、それらはボリュームにのみ適用されるため、他のリソースをバックアップするには引き続き Velero のようなものが必要です。 バックアップと復元は非常に信頼性がありますが、非常に遅いです。 真剣に、信じられないほど遅いです。 Longhorn で中量のデータを操作すると、CPU 使用率とシステム負荷が急増することがよくあります。 Longhorn を管理するための便利なダッシュボードがあります。 私は Longhorn が好きだとすでに述べましたが、それにはもう少し努力が必要です。

ストレージOS

StorageOS は、リストの最初の有料製品です。 開発者バージョンには管理ストレージ サイズが 500GB に制限されていますが、ノード数に制限はないと思います。 営業部門によると、私の記憶が正しければ、料金は 125 TB で月額 1 ドルからだと言われました。 基本的なダッシュボードと便利な CLI がありますが、パフォーマンスに奇妙なことが起こっています。いくつかのベンチマークではかなりまともですが、ボリューム ストレス テストでは速度がまったく気に入りませんでした。 一般的に、何を言えばいいのか分かりません。 なので、あまり理解できませんでした。 ここにはオフサイト バックアップはなく、ボリュームをバックアップするには Velero と Restic を使用する必要があります。 有料の商品なので不思議ですね。 そして、開発者は Slack でのコミュニケーションに熱心ではありませんでした。

ロビン

Robin については、Reddit のテクニカル ディレクターから知りました。 私はそれまで彼のことを聞いたことがありませんでした。 おそらく私は無料のソリューションを探していたのですが、Robin は有料だったのではないでしょうか。 10TBのストレージとXNUMXつのノードを備えたかなり寛大な無料バージョンがあります。 全体として、この製品は非常にまともで、優れた機能を備えています。 優れた CLI がありますが、最も優れている点は、ボリュームやその他のリソースを含むアプリケーション全体 (リソース セレクターでは、これを Helm リリースまたは「フレックス アプリ」と呼びます) のスナップショットとバックアップができるため、Velero がなくても実行できることです。 そして、XNUMX つの小さな点さえなければ、すべてが素晴らしいでしょう。たとえば、災害からの回復の場合など、新しいクラスター上でアプリケーションを復元 (または Robin で「インポート」と呼ばれる) した場合、復元、もちろん動作しますが、アプリケーションのバックアップを続けることは禁止されています。 開発者が確認したように、このリリースではこれは不可能です。 これは、特に他の利点 (たとえば、信じられないほど高速なバックアップと復元) を考慮すると、控えめに言っても奇妙です。 開発者は次のリリースまでにすべてを修正すると約束しています。 パフォーマンスは全体的に良好ですが、奇妙な点に気づきました。ホストに接続されたボリュームで直接ベンチマークを実行すると、ポッド内から同じボリュームを実行するよりも読み取り速度がはるかに速くなります。 他の結果はすべて同じですが、理論的には違いはないはずです。 彼らはそれに取り組んでいますが、私は復元とバックアップの問題に腹を立てていました。ついに適切な解決策を見つけたと思いました。そして、より多くのスペースやサーバーが必要なときは、喜んでお金を払うつもりでした。

portworx

ここで言うことはあまりありません。 これは有料の製品ですが、同様にクールで高価です。 パフォーマンスはただただ素晴らしいです。 これはこれまでで最高の指標です。 Slack は、Google の GKE Marketplace に記載されているように、料金はノードあたり月額 205 ドルからであると教えてくれました。 直接購入した方が安いかどうかはわかりません。 とにかくそんな余裕はないので、静的プロビジョニングに満足しない限り、開発者ライセンス (最大 1 TB および 3 ノード) が Kubernetes では実質的に役に立たないことに非常に残念に思いました。 試用期間の終了時にボリューム ライセンスが自動的に開発者にダウングレードされることを期待していましたが、それは起こりませんでした。 開発者ライセンスは Docker でのみ直接使用でき、Kubernetes での構成は非常に面倒で制限されます。 もちろん、私はオープンソースの方が好きですが、お金があれば間違いなく Portworx を選択するでしょう。 これまでのところ、そのパフォーマンスは他のオプションと比較できません。

リンスター

この記事を公開した後、読者からLinstorを試してみるように勧められたので、このセクションを追加しました。試してみたところ、気に入りました！でも、もう少し詳しく調べる必要があります。今のところ、パフォーマンスはかなり良いと言えます（ベンチマーク結果を以下に追加しました）。実際、オーバーヘッドなしで、直接ディスクベンチマークと同じパフォーマンスが得られました。（Portworxの数値が直接ディスクベンチマークよりも優れている理由は聞かないでください。私にもわかりません。魔法でしょう。）つまり、Linstorは今のところ非常に効果的なようです。セットアップはそれほど難しくはありませんが、他のオプションほど簡単ではありません。まず、Linstor（カーネルモジュールとツール/サービス）をインストールし、Kubernetesの外部でホスト上に直接、シンプロビジョニングとスナップショットサポートのためにLVMを設定し、Kubernetesからストレージを使用するために必要なリソースを作成する必要がありました。 CentOS そして使用する必要がありました Ubuntuもちろん大した問題ではありませんが、ドキュメント（ちなみに非常に優れています）に記載されているパッケージの中には、指定された Epel リポジトリで利用できないものがいくつかあるため、少し煩わしいです。Linstor にはスナップショット機能がありますが、オフサイトバックアップ機能がないため、ボリュームバックアップには再び Velero と Restic を使用する必要がありました。ファイルレベルのバックアップよりもスナップショットの方が望ましいのですが、ソリューションのパフォーマンスと信頼性が高ければ許容範囲です。Linstor はオープンソースですが、有料サポートがあります。私の理解が正しければ、サポート契約がなくても制限なく使用できるはずですが、確認する必要があります。Linstor が Kubernetes でどの程度テストされているかはわかりませんが、ストレージレイヤー自体は Kubernetes の外部にあり、かなり前から存在しているようなので、実環境でのテストは既に行われていると思われます。ここで、私の考えを変えて Kubernetes に戻るようなソリューションはありますか？わかりません。レプリケーションについてもう少し調べて学ぶ必要があります。どうなるか見てみましょう。でも、第一印象は良いです。自由度が高く、新しいことを学べるので、Herokuではなく独自のKubernetesクラスターを使う方が断然良いです。Linstorは他のものほど簡単にインストールできないので、近いうちにそのことについて記事を書く予定です。

ベンチマーク

残念ながら、比較については書こうと思っていなかったので、あまりメモを残していませんでした。 基本的な fio ベンチマークの結果だけがあり、単一ノード クラスターの結果しかないため、レプリケートされた構成の数値はまだありません。 ただし、これらの結果から、各オプションで何が期待できるかの大まかなアイデアを得ることができます。なぜなら、同じクラウド サーバー、4 コア、16 GB の RAM、およびテストされたボリューム用の追加の 100 GB ディスク上でそれらを比較したからです。 各ソリューションに対してベンチマークを 38 回実行して平均結果を計算し、さらに各製品のサーバー設定をリセットしました。 これはすべて完全に非科学的であり、一般的なアイデアを示しているだけです。 他のテストでは、ボリュームから XNUMX GB の写真とビデオをコピーし、読み取りと書き込みをテストしましたが、残念なことに、数値は保存されませんでした。 つまり、Portworkx ははるかに高速でした。

ボリューム ベンチマークには、次のマニフェストを使用しました。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

まず、適切なストレージ クラスでボリュームを作成し、その後、バックグラウンドで fio を使用してジョブを実行しました。 あまり長く待たずにパフォーマンスを見積もるために 1 GB を使用しました。 結果は次のとおりです。

各メトリクスの最良の値を緑色で、最悪の値を赤色で強調表示しました。

まとめ

ご覧のとおり、ほとんどの場合、Portworx は他のものよりも優れたパフォーマンスを発揮しました。 しかし、私にとってそれは高価です。 Robin の価格はわかりませんが、素晴らしい無料版があるので、有料製品が必要な場合は、それを試してみてください (復元とバックアップの問題がすぐに解決されることを願っています)。 XNUMX つの無料のものの中で、OpenEBS は最も問題が少なかったのですが、そのパフォーマンスはひどいものでした。 結果をさらに保存できなかったのは残念ですが、数値と私のコメントがお役に立てば幸いです。

出所： habr.com