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