Longhorn クラウドネイティブ分散ブロックストレージソリューションの設計アーキテクチャとコンセプト

[[418057]]

この記事はWeChatの公開アカウント「Hacker Afternoon Tea」から転載したもので、著者はShaoです。この記事を転載する場合は、Hacker Afternoon Tea公式アカウントまでご連絡ください。

シリーズ

Longhornとは何ですか?

目次

• 1. デザイン
  • 1.1. Longhorn Manager と Longhorn Engine
  • 1.2.マイクロサービスベースの設計の利点
  • 1.3. CSIドライバー
  • 1.4. CSI プラグイン
  • 1.5.ロングホーンUI
• 2. Longhorn ボリュームとプライマリ ストレージ
  • 2.4.1.スナップショットの仕組み
  • 2.4.2.定期的なスナップショット
  • 2.4.3.スナップショットの削除
  • 2.4.4.ストレージスナップショット
  • 2.4.5.クラッシュの一貫性
  • 2.3.1.レプリカの読み取りおよび書き込み操作の仕組み
  • 2.3.2.新しいレプリカを追加する方法
  • 2.3.3.失敗したレプリカを再構築する方法
  • 2.1.シンプロビジョニングとボリュームのサイズ設定
  • 2.2.メンテナンスモードでボリュームを復元する
  • 2.3.コピー
  • スナップショット
• 3. バックアップとセカンダリストレージ
  • 3.1.バックアップの仕組み
  • 3.2.定期的なバックアップ
  • 3.3.災害復旧ボリューム
  • 3.4.バックアップ ストレージの更新間隔、RTO、RPO
• 付録: Kubernetes での永続ストレージの仕組み
  • 既存のストレージ構成
  • 動的ストレージ構成
  • Kubernetes ワークロードが新規および既存の永続ストレージを使用する方法
  • 永続ストレージを使用した Kubernetes ワークロードの水平スケーリング

1. デザイン

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

1.1. Longhorn Manager と Longhorn Engine

Longhorn Manager Pod は、Longhorn クラスターの各ノードで Kubernetes DaemonSet として実行されます。 Kubernetes クラスター内のボリュームの作成と管理を担当し、UI または Kubernetes ボリューム プラグインからの API 呼び出しを処理します。これは、Kubernetes コントローラー パターン (オペレーター パターンとも呼ばれる) に従います。

Longhorn Manager は Kubernetes API サーバーと通信して、新しい Longhorn ボリューム CRD を作成します。その後、Longhorn Manager は API サーバーからの応答を監視し、Kubernetes API サーバーが新しい Longhorn ボリューム CRD を作成したことを確認すると、Longhorn Manager は新しいボリュームを作成します。

Longhorn Manager はボリュームの作成を要求されると、ボリュームが接続されているノード上に Longhorn Engine インスタンスを作成し、レプリカが配置される各ノード上にレプリカを作成します。最大限の可用性を確保するには、レプリカを異なるホストに配置する必要があります。

レプリカへの複数のデータ パスにより、Longhorn ボリュームの高可用性が確保されます。レプリカまたはエンジンに問題があっても、その問題はすべてのレプリカまたはポッドのボリュームへのアクセスに影響するわけではありません。ポッドは引き続き正常に動作します。

Longhorn エンジンは常に、Longhorn ボリュームを使用する Pod と同じノード上で実行されます。複数のノードに保存されている複数のレプリカ間でボリュームを同期的に複製します。

エンジンとレプリカは Kubernetes を使用してオーケストレーションされます。

下の図では、

• Longhorn ボリュームのインスタンスは 3 つあります。
• 各ボリュームには、Longhorn Engine と呼ばれる専用のコントローラーがあり、Linux プロセスとして実行されます。
• 各 Longhorn ボリュームには 2 つのレプリカがあり、それぞれが Linux プロセスです。
• 図の矢印は、ボリューム、コントローラ インスタンス、レプリカ インスタンス、およびディスク間の読み取り/書き込みデータ フローを表します。
• 各ボリュームに個別の Longhorn エンジンを作成することにより、1 つのコントローラに障害が発生しても、他のボリュームの機能には影響しません。

図 1. ボリューム、Longhorn エンジン、レプリカ インスタンス、ディスク間の読み取り/書き込みデータ フロー

1.2.マイクロサービスベースの設計の利点

Longhorn では、各エンジンは 1 つのボリュームのみを提供する必要があるため、ストレージ コントローラーの設計が簡素化されます。コントローラ ソフトウェアの障害ドメインは単一のボリュームに分離されているため、コントローラのクラッシュは 1 つのボリュームにのみ影響します。

Longhorn エンジンはシンプルで軽量なので、最大 100,000 個の個別のエンジンを作成できます。 Kubernetes はこれらの独立したエンジンをスケジュールし、共有ディスク セットからリソースを抽出し、Longhorn と連携して回復力のある分散ブロック ストレージ システムを形成します。

各ボリュームには独自のコントローラがあるため、各ボリュームのコントローラとレプリカ インスタンスも、IO 操作に大きな中断を引き起こすことなくアップグレードできます。

Longhorn は、システムの継続的な操作を中断することなく、すべてのライブ ボリュームのアップグレードを調整するための長時間実行ジョブを作成できます。アップグレードによって予期しない問題が発生しないように、Longhorn ではボリュームの小さな部分をアップグレードし、アップグレード プロセス中に問題が発生した場合に古いバージョンにロールバックすることを選択できます。

1.3. CSIドライバー

Longhorn CSI ドライバーはブロック デバイスを取得し、フォーマットしてからノードにマウントします。次に、kubelet はデバイスを Kubernetes Pod にバインドマウントします。これにより、Pod は Longhorn ボリュームにアクセスできるようになります。

必要な Kubernetes CSI ドライバー イメージは、longhorn ドライバー デプロイヤーによって自動的にデプロイされます。

1.4. CSI プラグイン

Longhorn は、CSI プラグインを介して Kubernetes で管理されます。これにより、Longhorn プラグインを簡単にインストールできるようになります。

Kubernetes CSI プラグインは Longhorn を呼び出してボリュームを作成し、Kubernetes ワークロードの永続データを作成します。 CSI プラグインを使用すると、ボリュームの作成、削除、接続、切断、マウント、スナップショット作成が可能になります。 Longhorn によって提供されるその他すべての機能は、Longhorn UI を通じて実装されます。

Kubernetes クラスターは、CSI インターフェースを使用して Longhorn CSI プラグインと通信します。 Longhorn CSI プラグインは、Longhorn API を使用して Longhorn Manager と通信します。

Longhorn は iSCSI を利用するため、ノードの追加構成が必要になる場合があります。これには、ディストリビューションに応じて、open-iscsi または iscsiadm のインストールが含まれる場合があります。

1.5.ロングホーンUI

Longhorn UI は Longhorn API を介して Longhorn Manager と対話し、Kubernetes を補完します。 Longhorn インターフェースを通じて、スナップショット、バックアップ、ノード、ディスクを管理できます。

さらに、クラスター ワーカー ノードのスペース使用量が収集され、Longhorn UI によって表示されます。詳細はこちらをご覧ください。

2. Longhorn ボリュームとプライマリ ストレージ

ボリュームを作成すると、Longhorn Manager は Longhorn Engine マイクロサービスと、各ボリュームのレプリカをマイクロサービスとして作成します。これらのマイクロサービスが一緒になって Longhorn ボリュームを形成します。各レプリカは、異なるノードまたは異なるディスクに配置する必要があります。

Longhorn Manager は Longhorn Engine を作成した後、レプリカに接続します。エンジンは、ポッドが実行されるノード上でブロック デバイスを公開します。

kubectl は Longhorn ボリュームの作成をサポートしています。

2.1.シンプロビジョニングとボリュームのサイズ設定

Longhorn はシンプロビジョニングされたストレージ システムです。つまり、Longhorn ボリュームは現在必要なだけのスペースしか占有しません。たとえば、20 GB のボリュームを割り当てたが、そのうち 1 GB しか使用しない場合、ディスク上の実際のデータ サイズは 1 GB になります。実際のデータ サイズは、UI のボリューム詳細で確認できます。

ボリュームからコンテンツを削除しても、Longhorn ボリューム自体のサイズは縮小されません。たとえば、20 GB のボリュームを作成し、10 GB を使用した後、9 GB を削除した場合、ディスク上の実際のサイズは 1 GB ではなく 10 GB のままになります。これは、Longhorn がファイルシステム レベルではなくブロック レベルで動作し、ユーザーがコンテンツを削除したかどうかを Longhorn が認識できないために発生します。この情報は主にファイル システム レベルで保存されます。

2.2.メンテナンスモードでボリュームを復元する

Longhorn UI からボリュームを接続する場合、メンテナンス モードのチェック ボックスがあります。これは主にスナップショットからボリュームを復元するために使用されます。

このオプションを選択すると、フロントエンド (ブロック デバイスまたは iSCSI) が有効になっていない状態でボリュームが接続されるため、ボリュームが接続されている間は誰もボリューム データにアクセスできなくなります。

v0.6.0 以降では、スナップショットの復元操作を行うには、ボリュームをメンテナンス モードにする必要があります。これは、ボリュームがマウントされている間または使用中にブロック デバイスの内容が変更されると、ファイル システムが破損する可能性があるためです。

データが誤ってアクセスされることを心配することなく、ボリュームの状態を確認するのにも便利です。

2.3.コピー

各レプリカは、Longhorn ボリュームの一連のスナップショットで構成されます。スナップショットはイメージのレイヤーのようなもので、最も古いスナップショットがベースレイヤーとして使用され、新しいスナップショットがその上に配置されます。データが古いスナップショットのデータを上書きする場合、そのデータは新しいスナップショットにのみ含まれます。一連のスナップショットを組み合わせると、データの現在の状態が表示されます。

各 Longhorn ボリュームについて、ボリュームの複数のレプリカが Kubernetes クラスター内で実行され、各レプリカが別々のノード上に配置されている必要があります。すべてのレプリカは平等に扱われ、Longhorn エンジンは常にポッドと同じノードで実行されます。ポッドはボリュームの消費者でもあります。この方法により、ポッドがダウンした場合でも、エンジンを別のポッドに移動でき、サービスが中断されないことが保証されます。

デフォルトのレプリカ数は設定で変更できます。ボリュームがアタッチされると、ボリュームのレプリカ数を UI で変更できます。

現在の正常なレプリカ数が指定されたレプリカ数より少ない場合、Longhorn は新しいレプリカの再構築を開始します。

現在の正常なレプリカ数が指定されたレプリカ数より大きい場合、Longhorn は何も実行しません。この場合、レプリカに障害が発生したり、レプリカが削除されたりすると、正常なレプリカ数が指定されたレプリカ数を下回らない限り、Longhorn は新しいレプリカの再構築を開始しません。

Longhorn レプリカは、シン プロビジョニングをサポートする Linux スパース ファイルを使用して構築されます。

2.3.1.レプリカの読み取りおよび書き込み操作の仕組み

ボリュームのレプリカからデータを読み取るときに、ライブ データ内にデータが見つかった場合は、そのデータが使用されます。 None の場合は、最新のスナップショットが読み取られます。最新のスナップショットにデータが見つからない場合は、次に古いスナップショットが読み取られ、最も古いスナップショットが読み取られるまでこれが繰り返されます。

スナップショットを作成すると、差分ディスクが作成されます。スナップショットの数が増えると、差分ディスク チェーン (スナップショット チェーンとも呼ばれます) が非常に長くなる可能性があります。したがって、読み取りパフォーマンスを向上させるために、Longhorn は、各 4K ストレージ ブロックの有効なデータがどの差分ディスクに保持されているかを記録する読み取りインデックスを維持します。

次の図では、ボリュームには 8 つのブロックがあります。読み取りインデックスには 8 つのエントリがあり、読み取り操作が発生すると遅延して設定されます。

書き込み操作により、読み取りインデックスがリセットされ、ライブ データを指すようになります。ライブ データは、一部のインデックス上のデータと、他のインデックス上の空き領域で構成されます。

読み取りインデックス以外に、どのブロックが使用されたかを示す追加のメタデータは現在保持されていません。

図2. 読み取りインデックスが最新のデータを保持するスナップショットを追跡する方法

上記の画像は、読み取りインデックスに基づいて、どのブロックに最新のデータが含まれているかを示すために色分けされています。最新データのソースも以下の表に記載されています。

上の図の緑の矢印で示されているように、読み取りインデックス Index 5 は、以前は最新データのソースとして 2 番目に古いスナップショットを指していましたが、Index 5 のストレージが 4K ブロックのリアルタイム データによって上書きされたときに、リアルタイム データを指すように変更されたことに注意してください。

読み取りインデックスはメモリ内に保持され、4K ブロックごとに 1 バイトを消費します。バイトサイズの読み取りインデックスは、ボリュームごとに最大 254 個のスナップショットを作成できることを意味します。

インデックスを読み取ると、レプリカごとに一定量のメモリ内データ構造が消費されます。たとえば、1 TB のボリュームでは、インデックスを読み取るために 256 MB のメモリが消費されます。

2.3.2 新しいレプリカを追加する方法

新しいレプリカが追加されると、既存のレプリカが新しいレプリカに同期されます。最初のレプリカは、ライブ データから新しいスナップショットを取得することによって作成されます。

次の手順は、Longhorn が新しいレプリカを追加する方法のより詳細な内訳を示しています。

1. Longhorn エンジンが一時停止しました。
2. レプリカ内のスナップショット チェーンがリアルタイム データとスナップショットで構成されていると想定します。新しいレプリカが作成されると、ライブ データは最新 (2 番目) のスナップショットになり、ライブ データの新しい空のバージョンが作成されます。
3. 新しいレプリカは WO (書き込み専用) モードで作成されます。
4. Longhorn エンジンが一時停止を解除します。
5. すべてのスナップショットが同期されます。
6. 新しいコピーは RW (読み取り/書き込み) モードに設定されます。

2.3.3.失敗したレプリカを再構築する方法

Longhorn は常に、各ボリュームに対して少なくとも指定された数の正常なレプリカを維持しようとします。

コントローラはレプリカの 1 つで障害を検出すると、そのレプリカをエラー状態としてマークします。 Longhorn マネージャーは、障害が発生したレプリカを再構築するプロセスを開始および調整する責任を負います。

障害が発生したレプリカを再構築するために、Longhorn Manager は空のレプリカを作成し、Longhorn Engine を呼び出して、その空のレプリカをボリュームのレプリカ セットに追加します。

空のレプリカを追加するには、エンジンは次の操作を実行します。

• すべての読み取りおよび書き込み操作を一時停止します。
• WO (書き込み専用) モードで空のコピーを追加します。
• 既存のすべてのレプリカのスナップショットを作成します。これで、先頭に空の差分ディスクが設定されます。
• すべての読み取りおよび書き込み操作を一時停止解除します。新しく追加されたレプリカには書き込み操作のみが送信されます。
• 最新の差分ディスクを除くすべてのディスクを正常なレプリカから空のレプリカに同期するバックグラウンド プロセスを開始します。
• 同期が完了すると、すべてのレプリカのデータが整合し、ボリューム マネージャーは新しいレプリカを RW (読み取り/書き込み) モードに設定します。

最後に、Longhorn Manager は Longhorn Engine を呼び出して、障害が発生したレプリカをレプリカ セットから削除します。

スナップショット

スナップショット機能を使用すると、ボリュームを履歴の特定の時点に復元できます。セカンダリ ストレージ上のバックアップもスナップショットから構築できます。

スナップショットからボリュームを復元すると、スナップショットが作成された時点のボリュームの状態が反映されます。

スナップショット機能も Longhorn 再構築プロセスの一部です。 Longhorn はレプリカがダウンしていることを検出するたびに、自動的に (システム) スナップショットを作成し、別のノード上で再構築を開始します。

2.4.1.スナップショットの仕組み

スナップショットはイメージのレイヤーのようなもので、最も古いスナップショットがベースレイヤーとして使用され、新しいスナップショットがその上に配置されます。データが古いスナップショットのデータを上書きする場合、そのデータは新しいスナップショットにのみ含まれます。一連のスナップショットを組み合わせると、データの現在の状態が表示されます。

スナップショットが作成されると、削除しない限り変更することはできません。削除した場合、その変更は次に新しいスナップショットにマージされます。新しいデータは常にライブ バージョンに書き込まれます。新しいスナップショットは常にライブ データから作成されます。

新しいスナップショットを作成するには、ライブ データが最新のスナップショットになります。次に、ライブ データの新しい空白バージョンが作成され、古いライブ データが置き換えられます。

2.4.2.定期的なスナップショット

スナップショットによって占有されるスペースを削減するために、ユーザーは定期的なスナップショットまたはバックアップをスケジュールし、複数のスナップショットを保持することができます。これにより、スケジュールに従って新しいスナップショット/バックアップが自動的に作成され、余分なスナップショット/バックアップがクリーンアップされます。

2.4.3.スナップショットの削除

不要なスナップショットは、インターフェースを通じて手動で削除できます。システム生成のスナップショットが削除対象としてトリガーされると、システムは自動的にそれを削除対象としてマークします。

Longhorn では、最新のスナップショットを削除できません。これは、スナップショットを削除するたびに、Longhorn がその内容を次のスナップショットとマージし、次のスナップショットとそれ以降のスナップショットに正しい内容が保持されるためです。

しかし、削除されたスナップショットとマージする最新のスナップショットがもう存在しないため、Longhorn は最新のスナップショットに対してこれを実行できません。最新のスナップショットの次の「スナップショット」はライブ ボリューム (ボリューム ヘッド) であり、これはユーザーがこの時点で読み取り/書き込みを行っているものなので、マージ プロセスは発生しません。

代わりに、最新のスナップショットが削除済みとしてマークされ、可能であれば次回クリーンアップされます。

最新のスナップショットをクリーンアップするには、新しいスナップショットを作成してから、以前の「最新の」スナップショットを削除します。

2.4.4.ストレージスナップショット

スナップショットは、ボリュームの各レプリカの一部としてローカルに保存されます。これらは、Kubernetes クラスター内のノード上のディスクに保存されます。スナップショットは、ホストの物理ディスク上のボリューム データと共に保存されます。

2.4.5.クラッシュ一貫性

Longhorn はクラッシュ整合性のあるブロック ストレージ ソリューションです。

ブロック層に書き込む前に、オペレーティング システムがコンテンツをキャッシュに保持するのは正常な動作です。つまり、すべてのレプリカが閉じられている場合、コンテンツは OS レベルのキャッシュに保持されており、まだ Longhorn システムに転送されていないため、シャットダウン直前に発生した変更が Longhorn に含まれない可能性があります。

この問題は、停電によりデスクトップ コンピューターがシャットダウンした場合に発生する可能性がある問題に似ています。電源が復旧した後、ハードドライブ上に破損したファイルがあることに気付く場合があります。

任意の時点でデータをブロック層に強制的に書き込むには、ノード上で sync コマンドを手動で実行するか、ディスクをアンマウントします。どちらの場合でも、オペレーティング システムはキャッシュの内容をブロック レイヤーに書き込みます。

Longhorn はスナップショットを作成する前に自動的に同期コマンドを実行します。

3. バックアップとセカンダリストレージ

バックアップは、Kubernetes クラスターの外部にある NFS または S3 互換のオブジェクト ストレージであるバックアップストア内のオブジェクトです。バックアップは一種のセカンダリ ストレージを提供するため、Kubernetes クラスターが利用できなくなった場合でも、データを取得できます。

ボリュームのレプリケーションは同期的であり、ネットワークの遅延により、リージョン間でのレプリケーションは困難です。この問題を解決する手段として、バックアップストレージ（バックアップストア）も使用されます。

Longhorn 設定でバックアップ先を構成すると、Longhorn はバックアップ ストレージに接続し、Longhorn UI に既存のバックアップの一覧を表示できるようになります。

Longhorn が 2 番目の Kubernetes クラスターで実行されている場合、災害復旧ボリュームをセカンダリ ストレージのバックアップに同期することもできるため、2 番目の Kubernetes クラスターでデータをより速く復元できます。

3.1.バックアップの仕組み

スナップショットをソースとして使用してバックアップを作成し、スナップショットが作成された時点でのボリューム データの状態を反映させます。

スナップショットとは対照的に、バックアップは一連のスナップショットのフラット化されたバージョンと考えることができます。レイヤー化されたイメージをフラットなイメージに変換するときに情報が失われるのと同様に、一連のスナップショットをバックアップに変換するときにもデータが失われます。どちらの変換でも、上書きされたデータは失われます。

バックアップにはスナップショットが含まれていないため、ボリューム データの変更履歴は含まれません。ボリュームがバックアップから復元されると、ボリュームには最初に 1 つのスナップショットが含まれます。このスナップショットは、元のチェーン内のすべてのスナップショットをマージしたバージョンであり、バックアップが作成された時点でのボリュームのライブ データを反映しています。

スナップショットは最大テラバイトですが、バックアップは 2 MB のファイルで構成されます。

同じ元のボリュームの新しいバックアップはそれぞれ増分バックアップであり、スナップショット間で変更されたブロックを検出して転送します。各スナップショットは差分ファイルであり、前のスナップショットからの変更のみを保存するため、これは比較的簡単なタスクです。

多数の小さなストレージ ブロックを保存しないようにするために、Longhorn は 2 MB のブロックを使用してバックアップ操作を実行します。つまり、2MB 境界上の 4K ブロックが変更された場合、Longhorn は 2MB ブロック全体をバックアップします。これにより、管理性と効率性の適切なバランスが実現します。

図3. セカンダリストレージのバックアップとプライマリストレージのスナップショットの関係

上の図は、Longhorn でスナップショットからバックアップを作成する方法を説明しています。

• 図のプライマリ ストレージ側には、Kubernetes クラスター内の Longhorn ボリュームのレプリカが表示されます。レプリカは 4 つのスナップショットのチェーンで構成されます。スナップショットは、新しいものから古いものの順に、Live Data、snap3、snap2、snap1 となります。
• 図のセカンダリ ストレージ側には、S3 などの外部オブジェクト ストレージ サービス内の 2 つのバックアップが表示されます。
• セカンダリ ストレージでは、backup-from-snap2 の色分けにより、snap1 からの青い変更と snap2 からの緑の変更が含まれていることがわかります。

snap2 の変更は snap1 のデータを上書きしていないため、snap1 と snap2 の両方の変更が backup-from-snap2 に含まれます。

• backup-from-snap3 という名前のバックアップは、snap3 が作成された時点でのボリューム データの状態を反映します。色分けと矢印は、backup-from-snap3 には snap3 からの濃い赤色の変更がすべて含まれているが、snap2 からの緑色の変更は 1 つだけ含まれていることを示しています。

これは、snap3 の赤色の変更が snap2 の緑色の変更を上書きしたためです。これは、スナップショットとその前のスナップショットが統合されるため、バックアップに完全な変更履歴が含まれないことを示しています。

• 各バックアップは独自の 2 MB ブロック セットを維持します。各 2 MB ブロックは 1 回だけバックアップされます。 2 つのバックアップは、1 つの緑色のブロックと 1 つの青色のブロックを共有します。

バックアップがセカンダリ ストレージから削除されても、Longhorn は使用されたすべてのブロックを削除するわけではありません。代わりに、定期的にガベージ コレクションを実行して、セカンダリ ストレージから未使用のブロックをクリアします。

同じボリュームに属するすべてのバックアップの 2 MB ブロックは共通ディレクトリに保存されるため、複数のバックアップ間で共有できます。

スペースを節約するために、バックアップ間で変更されない 2 MB ブロックを、セカンダリ ストレージ上の同じバックアップ ボリュームを共有する複数のバックアップに再利用できます。チェックサムは 2 MB ブロックのアドレス指定に使用されるため、同じボリューム内で 2 MB ブロックの重複排除をある程度実現できます。

ボリューム レベルのメタデータは volume.cfg に保存されます。各バックアップのメタデータ ファイル (例: snap2.cfg) には、バックアップ内のすべての 2 MB ブロックのオフセットとチェックサムのみが含まれているため、比較的小さくなります。

各 2 MB ブロック (.blk ファイル) を圧縮します。

3.2.定期的なバックアップ

バックアップ操作は、定期的なスナップショットおよびバックアップ機能を使用してスケジュールできますが、オンデマンドで実行することもできます。

ボリュームの定期的なバックアップをスケジュールすることをお勧めします。バックアップ ストアが利用できない場合は、代わりに定期的なスナップショットをスケジュールすることをお勧めします。

バックアップを作成するには、ネットワーク経由でデータをコピーする必要があるため、時間がかかります。

3.3.災害復旧ボリューム

ディザスタリカバリ (DR) ボリュームは、プライマリ クラスター全体に障害が発生した場合にバックアップ クラスターにデータを保存する特別なボリュームです。 DR ボリュームは、Longhorn ボリュームの回復力を向上させるために使用されます。

DR ボリュームの主な目的はバックアップからデータを復元することであるため、アクティブ化前のボリュームでは次の操作はサポートされません。

• スナップショットの作成、削除、復元
• バックアップを作成する
• 永続ボリュームの作成
• 永続ボリュームクレームを作成する

バックアップ ストレージ内のボリューム バックアップから DR ボリュームを作成できます。 DR ボリュームが作成されると、Longhorn は元のバックアップ ボリュームを監視し、最新のバックアップ増分から復元します。バックアップ ボリュームは、同じボリュームの複数のバックアップを含むバックアップ ストレージ内のオブジェクトです。

プライマリ クラスターの元のボリュームがダウンした場合、バックアップ クラスターの DR ボリュームをすぐにアクティブ化できるため、バックアップ ストレージからバックアップ クラスターのボリュームにデータを復元するのにかかる時間が大幅に短縮されます。

DR ボリュームがアクティブになると、Longhorn は元のボリュームの最後のバックアップをチェックします。バックアップが復元されていない場合は、復元が開始され、アクティベーション操作は失敗します。ユーザーは、再試行する前に回復が完了するまで待つ必要があります。

DR ボリュームが存在する場合、Longhorn セットアップでバックアップ先を更新することはできません。

DR ボリュームがアクティブ化されると、通常の Longhorn ボリュームになり、非アクティブ化できなくなります。

3.4.バックアップ ストレージの更新間隔、RTO、RPO

通常、増分復元は定期的なバックアップ ストアの更新によってトリガーされます。ユーザーは、[設定] - [全般] - [バックアップ ストアのポーリング間隔] でバックアップ ストアの更新間隔を設定できます。

この間隔は、復旧時間目標 (RTO) に影響する可能性があることに注意してください。時間が長すぎると、災害復旧ボリュームによって復元されるデータの量が多くなり、時間が長くなる可能性があります。

リカバリポイント目標 (RPO) については、バックアップ ボリュームの定期的なバックアップ スケジュールによって決まります。通常のボリューム A の定期バックアップ スケジュールで 1 時間ごとにバックアップが作成される場合、RPO は 1 時間になります。 Longhorn で定期的なバックアップを設定する方法については、こちらをご覧ください。

次の分析では、ボリュームのバックアップが 1 時間ごとに作成され、バックアップからのデータの増分復元に 5 分かかることを前提としています。

Backupstore のポーリング間隔が 30 分の場合、最後の復元以降のバックアップ データは最大 1 つになります。バックアップの復元時間は 5 分なので、RTO は 5 分です。

Backupstore のポーリング間隔が 12 時間の場合、最後の復元以降のデータ バックアップは最大 12 個になります。バックアップの復元時間は 5 * 12 = 60 分なので、RTO は 60 分になります。

付録: Kubernetes での永続ストレージの仕組み

Kubernetes の永続ストレージを理解するには、ボリューム、PersistentVolume、PersistentVolumeClaim、StorageClasses とそれらがどのように連携するかを理解することが重要です。

Kubernetes ボリュームの重要な特性は、それが属するポッドと同じライフサイクルを持つことです。ポッドがなくなると、ボリュームも失われます。対照的に、PersistentVolume はユーザーが削除するまでシステム内に存在し続けます。ボリュームは同じポッド内のコンテナ間でデータを共有するためにも使用できますが、通常、ユーザーはポッドごとに 1 つのコンテナしか持たないため、これは主な使用例ではありません。

PersistentVolume (PV) は Kubernetes クラスター内の永続ストレージであり、PersistentVolumeClaim (PVC) はストレージ要求です。 StorageClasses を使用すると、必要に応じてワークロード用に新しいストレージを動的にプロビジョニングできます。

Kubernetes ワークロードが新規および既存の永続ストレージを使用する方法

大まかに言えば、Kubernetes で永続ストレージを使用するには主に 2 つの方法があります。

• 既存の永続ボリュームを使用する
• 新しい永続ボリュームを動的にプロビジョニングする

既存のストレージ構成

既存の PV を使用するには、アプリケーションは PV にバインドされた PVC を使用する必要があり、PV には PVC に必要な最小限のリソースが含まれている必要があります。

つまり、Kubernetes で既存のストレージを設定するための一般的なワークフローは次のようになります。

• アクセスできる物理ストレージまたは仮想ストレージという意味で永続ストレージ ボリュームを設定します。
• 永続ストレージを参照する PV を追加します。
• PV を参照する PVC を追加します。
• PVC をワークロード内のボリュームとしてマウントします。

PVC がストレージを要求すると、Kubernetes API サーバーは、一致するボリュームが利用可能であるため、その PVC を事前に割り当てられた PV と一致させようとします。一致が見つかった場合、PVC は PV にバインドされ、ユーザーは事前に割り当てられたストレージ ブロックの使用を開始します。

一致するボリュームが存在しない場合、PersistentVolumeClaims は無期限にバインドされないままになります。たとえば、50 Gi の PV が多数設定されたクラスターは、100 Gi を要求する PVC と一致しません。 100 Gi PV をクラスターに追加したら、PVC をバインドできます。

つまり、無制限の PVC を作成できますが、Kubernetes マスターが PVC に必要なディスク容量以上の十分な PV を見つけることができた場合にのみ、それらの PVC が PV にバインドされます。

動的ストレージ構成

動的ストレージ プロビジョニングの場合、アプリケーションは StorageClass にバインドされた PVC を使用する必要があります。 StorageClass には、新しい永続ボリュームをプロビジョニングするための権限が含まれています。

Kubernetes で新しいストレージを動的にプロビジョニングするためのワークフロー全体には、StorageClass リソースが関係します。

1. StorageClass を追加し、アクセスできるストレージから新しいストレージを自動的にプロビジョニングするように構成します。
2. StorageClass を参照する PVC を追加します。
3. PVC をワークロードのボリュームとしてマウントします。

Kubernetes クラスター管理者は、Kubernetes StorageClass を使用して、提供するストレージ「クラス」を記述できます。 StorageClasses には、異なる容量制限、異なる IOPS、またはベンダーがサポートするその他のパラメータを設定できます。ストレージ ベンダー固有のプロビジョナーは、StorageClass と組み合わせて使用​​され、StorageClass オブジェクトに設定されたパラメーターに従って PV を自動的に割り当てます。さらに、プロビジョナーはユーザーに対してリソースの割り当てと権限の要件を適用できるようになりました。この設計により、管理者は PV 需要の予測や PV の割り当てといった不要な作業から解放されます。

StorageClass を使用する場合、Kubernetes 管理者は各ストレージの割り当てを担当しません。管理者は、ユーザーにストレージ プールへのアクセスを許可し、クォータを決定するだけで済みます。ユーザーは、ストレージ プールから必要なストレージ部分をマイニングできます。

Kubernetes で StorageClass オブジェクトを明示的に作成せずに StorageClass を使用することもできます。 StorageClass は PVC と PV を一致させるために使用されるフィールドでもあるため、カスタム ストレージ クラス名を持つ PV を手動で作成し、その StorageClass 名を持つ PV を必要とする PVC を作成できます。 Kubernetes は、StorageClass オブジェクトが Kubernetes リソースとして存在しない場合でも、指定された StorageClass 名を使用して PVC を PV にバインドできます。

Longhorn では、Kubernetes ワークロードが必要に応じて永続ストレージをパーティション分割できるように、Longhorn StorageClass が導入されています。

永続ストレージを使用した Kubernetes ワークロードの水平スケーリング

VolumeClaimTemplate は、ブロック ストレージ ソリューションが Kubernetes ワークロードを水平にスケーリングする方法を提供する StatefulSet 仕様プロパティです。

このプロパティは、StatefulSet によって作成されたポッドに一致する pv と pvc を作成するために使用できます。

これらの PVC は StorageClass を使用して作成されるため、StatefulSet がスケーリングされたときに自動的にプロビジョニングされます。

StatefulSet がスケールダウンされると、余分な PV/PVC はクラスター内に残り、StatefulSet が再度スケールアップされるときに再利用されます。

VolumeClaimTemplate は、EBS や Longhorn などのブロック ストレージ ソリューションにとって重要です。これらのソリューションは本質的に ReadWriteOnce であるため、Pod 間で共有することはできません。

永続データを使用して複数の Pod を実行している場合、デプロイメントは永続ストレージとうまく連携しません。複数のポッドの場合は、StatefulSet を使用する必要があります。