クラウドネイティブストレージツールの選択と適用に関する議論

1.クラウドネイティブストレージの概念

クラウド ネイティブ ストレージの概念は、クラウド ネイティブ アプリケーションから生まれました。名前が示すように、クラウドネイティブ機能の要件を満たすために、アプリケーションにはクラウドネイティブストレージ機能であるストレージ機能が必要であり、これらの機能を満たすストレージソリューションはクラウドネイティブストレージと呼ぶことができます。

図1

上の図 1 に示すように、クラウド ネイティブ アプリケーションには、次の 3 つの側面にまとめられるストレージ要件があります。

• 俊敏性の要件:ブロック デバイスは柔軟にマウントでき、異なるノードにすばやく切り替えることができます。ストレージ サービスの問題に対する自動修復機能が提供され、人的介入が削減されます。より柔軟なボリューム サイズ構成機能が提供されます。
• 監視要件:よりきめ細かい (ディレクトリ) 監視機能を提供します。読み取りおよび書き込みのレイテンシ、読み取りおよび書き込みの頻度、IO 分散、その他の指標など、より次元の高い監視指標を提供します。
• テナント分離の要件:共有ファイル システムの異なるテナント間でファイル システム レベルの分離を実現するため。コンテナ オーケストレーション レイヤーは、名詞空間と PSP ポリシーに基づいてオーケストレーション分離機能を実装し、アプリケーション展開側から異なるテナントが他のテナントのストレージ ボリューム サービスにアクセスできないようにします。

上記の要件を満たすストレージ ツールは、次のカテゴリに分類できます。

• パブリック クラウド ストレージ:パブリック クラウドをベースとしたオブジェクト ストレージ、ブロック ストレージ、ファイル ストレージ、データベースは、安定性、パフォーマンス、スケーラビリティの面でビジネス ニーズを簡単に満たすことができます。
• 商用プライベート クラウド ストレージ:多くのクラウド ストレージ プロバイダーは、長年にわたってストレージ テクノロジーに深く関わっており、優れた技術力と運用・保守能力を備えています。彼らは現在、クラウドネイティブのサポートを提供しています。
• 自作クラウド ストレージ:いくつかのオープン ソース アーキテクチャに基づいて、Ceph、GlusterFS などの独自の物理マシン システム上にプライベート クラウド ストレージ サービスを構築します。
• オープンソースコンテナストレージ：ストレージとクラウドネイティブオーケストレーションシステムの統合を十分に考慮した設計で、Longhorn ^[1]やOpenEBS ^[2]などの優れたコンテナデータボリュームアクセス機能を備えています。

クラウド ネイティブの基本要件を満たす上記のストレージ ソリューションのうち、パブリック クラウド ストレージと商用プライベート クラウド ストレージは、展開場所とコストの制限により、プライベート クラウド環境に完全に適用することはできません。オープンソース アーキテクチャに基づく自社構築のクラウド ストレージは信頼性が低く、メンテナンス コストが高く、クラウド ネイティブ クラスターと完全に統合できません。したがって、次の記事では、オープンソースのコンテナ化ストレージ ソリューションに焦点を当てます。

2.オープンソースコンテナストレージの技術的ルート

図2

上の図 2 に示すように、現在主流のオープンソース コンテナ ストレージ ソリューションには主に次のものが含まれます。

• クラウド ネイティブ コミュニティに基づく車輪の再発明 - ネイティブ ソリューション:コンテナ化と k8s のアプリケーション シナリオに基づいて、比較的軽量な分散ストレージ システムが独自に開発されます。代表的なオープンソース プロジェクトには、Longhorn や OpenEBS などがあります。
• 従来の分散ストレージの移行 - 移行ソリューション:従来の分散ストレージ フレームワークに基づいて、k8s をコンテナー化およびオーケストレーションし、デプロイメントのために k8s クラスターに移行します。代表的なオープンソースプロジェクトとしては、rook+ceph ^[3] 、heketi+glusterfs ^[4] 、minio ^[5]などがあげられる。

著者のプロジェクトは、オープンソースのコンテナ ストレージ ソリューションを予備調査した結果、minio はオブジェクト ストレージ サービスしか提供できず、ディスクをマウントできないという結論に達しました。また、heketi+gluster オープンソース プロジェクトはメンテナンスを停止しているため、minio と heketi+gluster ソリューションは最初に除外されました。

3.オープンソースコンテナストレージの主要ツールの紹介

3.1 Longhorn クラウドネイティブストレージ

Longhorn は、Rancher コミュニティによって最初に作成および開発され、コンテナとマイクロサービスを完全に使用して分散ブロック ストレージを実装します。 Longhorn は、各ブロック デバイス ボリュームに専用のストレージ コントローラを作成し、複数のノードに保存されている複数のレプリカ間でボリュームを同期的に複製します。ストレージ コントローラーとレプリカ自体は Kubernetes を使用してオーケストレーションされます。

Longhorn は、データ プレーンとコントロール プレーンの 2 つのレイヤーで設計されています。 Longhorn Engine はデータ プレーンに対応するストレージ コントローラであり、Longhorn Manager はコントロール プレーンに対応します。

• 制御エンジン: Kubernetes クラスター内のボリュームの作成と管理、および UI または Kubernetes ボリューム プラグインからの API 呼び出しの処理を担当します。 Longhorn Manager はボリュームの作成を要求されると、ボリュームが接続されているノード上に Longhorn Engine インスタンスを作成します。
• データ エンジン:常に Longhorn ボリュームを使用する Pod と同じノードで実行されます。複数のノードに保存されている複数のレプリカ間でボリュームを同期的に複製します。エンジンとレプリカは Kubernetes を使用してオーケストレーションされます。

3.2 OpenEBS クラウドネイティブストレージ

OpenEBS は、Kubernetes におけるコンテナ ネイティブおよびコンテナ接続ストレージ タイプに関連するオープン ソース プロジェクトの 1 つです。これは最初に CloudByte によって開発され、CNCF にオープンソース化されました。 GO で開発された OpenEBS は、コンテナ接続ストレージ (CAS) の原則に従い、ワークロードごとに専用のストレージ コントローラを指定して、オペレーターと管理者がワークロードに基づいてボリュームのサイズを動的に変更できるようにします。

OpenEbs はコントロール パネルとデータ パネルに分かれています。

• コントロール パネル:ノード コンポーネントとクラスター コンポーネントの 2 種類のポッドが含まれます。 NDM (ノード ディスク マネージャー) は、各ノード上のディスクを識別および管理する役割を担います。 m-apiserver はストレージ REST API を公開し、ボリューム ポリシーの処理と管理の大部分を実行します。 Provisioner は、K8s で PVC と m-apiserver 間の相互作用を実装します。 NDM オペレーター ユーザーは、NDM の初期化とライフサイクル管理を制御します。
• データ パネル: cStor、Jiva、LocalPV の 3 つの異なるポッドに分かれており、ビジネス ポッドと共存します。 Jiva は実際には Longhorn エンジンを使用します。 LocalPV は、レプリカをコピーできず、障害を転送できない K8S のローカル PV モードです。

3.3 Rook+Ceph コンテナ化ストレージ

Rook 自体は分散ストレージ システムではありませんが、Kubernetes プラットフォームのパワーを活用して、Kubernetes Operator を通じて各ストレージ プロバイダーにサービスを提供します。分散ストレージ システムを、自己管理、自己スケーリング、自己修復のストレージ サービスに変換します。

Ceph は、2003 年にカリフォルニア大学サンタクルーズ校の Sage Weil 氏が博士課程のプロジェクトの一環として開発しました。最初のプロトタイプは、約 40,000 行の C++ コードを含む ceph ファイル システムで、2006 年に LGPL プロトコルに基づいてオープンソース化されました。

Ceph アーキテクチャには、モニター (MON) とストレージ (OSD) という 2 つのコア モジュールがあります。さらに、AWS S3 をベースとしたオブジェクト ストレージ ゲートウェイ RadosGW も含まれています。ブロック ストレージとファイル ストレージに関連するシステム プラグイン。で：

• モニター:クラスターの構造とステータス情報を保存および更新するために使用され、ブロック ストレージとファイル ストレージのメタデータ情報を制御します。デフォルトは、3 つのレプリカの選挙クラスターです。
• ストレージ:データの保存、自動データ検証、データ容量の自動バランス調整に使用されます。定期的にモニターにハートビートを報告し、データの書き込みおよび読み取り API を提供します。

Rook + Ceph の組み合わせソリューションは、比較的成熟した Ceph コンテナ化された展開および移行ソリューションです。 Rook は主に Ceph クラスターの初期化とステータスのハング、Kubernetes とのドッキングを完了します。実際のストレージ ビジネス ロジックは、コンテナ化された Ceph クラスターによって引き続き実装されます。

3.4 オープンソースコンテナストレージプロジェクト機能の水平比較

筆者のテスト環境では、上記 3 つのオープンソースのコンテナ化ストレージ ツールの機能とパフォーマンスを順にテストしています。 3 つの比較を表 1 に示します。

表1

3 つの長所と短所、ディスク パフォーマンスの低下、メンテナンスの複雑さなどを総合的に考慮した結果、著者のプロジェクトでは、Longhorn がストライピングをサポートしていないという欠点は Linux ボリューム グループをマウントすることで回避できると考え、最終的にLonghorn を使用することを選択しました。

4. Longhornのインストールと使用

各ノードに ISCSI デーモンをインストールします。すべてのクラスター ノードにすでにインストールされている場合、これは必要ありません。

 yum install -y iscsi -initiator -utils && systemctl enable --now iscsid.

下の図 6 に示すように、Longhorn リポジトリを Rancher アプリケーション ストアに追加すると、Rancher アプリケーション ストア リストに Longhorn アプリケーションが表示されるようになります。

図6

以下の図 7 および 8 に示すように、Rancher アプリケーション ストア リストで Longhorn を選択してインストールします。その後、Longhorn ドメイン名、デフォルト パス、レプリカのデフォルト数などを事前に設定できます。

図7

図8

すべてのコンポーネントがインストールされたら、前の手順で設定した Longhorn ドメイン名を通じてホームページ UI を開き、ストレージ パス、自動バックアップ、バウチャーの割り当て、マウントなどの操作を実行できます。

図9

上記の図 9 に示すページから PVC を作成するだけでなく、下の図 10 に示すように、ユーザーは Rancher ページの PVC 作成ページで StorageClass として Longhorn を直接選択することもできます。

図10

5.結論

この時点で、クラウド ネイティブ ストレージ ツールの選択と適用に関する予備的な議論は完了しました。私のプロジェクトでは、保守性とコストを考慮して最終的に Longhorn を選択しましたが、Rook+Ceph および OpenEBS ソリューションは、特定の条件下では依然として価値があります。条件が整うプロジェクトの場合、共有クラウドを使用したり、商用のプライベート クラウド ストレージを購入したりすることも適切な選択肢です。