アーキテクチャと概念

Longhorn Managerポッドは、SUSE Storageクラスター内の各ノードでKubernetesの デーモンセットとして実行されます。Kubernetesクラスター内でボリュームを作成および管理し、SUSE Storage UIまたはLonghorn CSIプラグインからのAPI呼び出しを処理します。Kubernetesコントローラパターンに従い、これは時折オペレータパターンと呼ばれます。

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

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

レプリカのための複数のデータパスは、Longhornボリュームの高可用性を確保します。レプリカまたはエンジンに問題が発生した場合、すべてのレプリカやポッドのボリュームへのアクセスに影響を与えることはありません。ポッドは通常通り機能し続けます。レプリカ数が`N`の特定のボリュームに対して、Longhornボリュームは最大`N-1`のレプリカ障害に耐えることができます。これは、ボリュームが稼働し続けるためには少なくとも1つの健康なレプリカが必要だからです。

Longhorn Engineは、SUSE Storageボリュームを使用するPodと同じノードで常に実行されます。それは、複数のノードに保存された複数のレプリカ間でボリュームを同期的に複製します。

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

以下の図では、

図1。ボリューム、Longhorn Engine、レプリカインスタンス、およびディスク間の読み取り/書き込みデータフロー

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

Longhorn Engineはシンプルで軽量であり、数千の別々のエンジンを作成することができます。Kubernetesはこれらの別々のエンジンをスケジュールし、共有ディスクセットからリソースを引き出し、SUSE Storageと連携して回復力のある分散ブロックストレージシステムを形成します。

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

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

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

必要なKubernetes CSIドライバーイメージは、Longhornドライバーデプロイヤーによって自動的にデプロイされます。 SUSE Storageをエアギャップ環境にインストールするには、このセクションを参照してください。

SUSE Storageは、 CSIプラグイン。を介してKubernetesで管理されます。これにより、プラグインの簡単なインストールが可能になります。

Kubernetes CSIプラグインは、Kubernetesワークロードのために永続データを作成するためにボリュームを作成するためにSUSE Storageを呼び出します。CSIプラグインは、ボリュームの作成、削除、アタッチ、デタッチ、マウント、およびボリュームのスナップショットを取得する機能を提供します。SUSE Storageによって提供される他のすべての機能は、UIを通じて実装されています。

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

v1ボリュームの場合、SUSE StorageはiSCSIを使用し、ノードに追加の設定が必要な場合があります。

対照的に、v2ボリュームは構成に応じて異なる前提条件があります。

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

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

各レプリカは、SUSE Storageボリュームのスナップショットのチェーンを含んでいます。スナップショットは画像の層のようなもので、最も古いスナップショットがベース層として使用され、新しいスナップショットがその上に重ねられます。データは、古いスナップショットのデータを上書きする場合にのみ、新しいスナップショットに含まれます。スナップショットのチェーンは、データの現在の状態を示します。

各SUSE Storageボリュームについて、Kubernetesクラスター内で複数のレプリカが異なるノードで実行されるべきです。すべてのレプリカは同じように扱われ、Longhorn Engineは常にポッドと同じノードで実行され、ポッドはボリュームの消費者でもあります。そのようにして、ポッドがダウンしても、エンジンを別のポッドに移動でき、サービスは中断されずに続行されます。

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

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

現在の正常なレプリカ数が指定されたレプリカ数より多い場合、レプリカの自動バランスとデータのローカリティは無効になり、SUSE Storageは何もしません。この状況では、レプリカが失敗したり削除された場合、正常なレプリカ数が指定されたレプリカ数を下回らない限り、SUSE Storageは新しいレプリカの再構築を開始しません。レプリカの自動バランスまたはデータのローカリティが設定されている場合、SUSE Storageはレプリカの1つを削除する可能性があります。

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

スナップショット機能により、ボリュームを特定の履歴の時点に戻すことができます。セカンダリストレージのバックアップもスナップショットから作成できます。

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

スナップショット機能は、SUSE Storage 再構築プロセスの一部でもあります。SUSE Storage がレプリカのダウンを検出するたびに、自動的に（システム）スナップショットを取得し、別のノードで再構築を開始します。

バックアップは、1つのスナップショットをソースとして使用して作成され、そのスナップショットが作成された時点でのボリュームのデータの状態を反映します。バックアップはクラスターの外部にリモートで保存されます。

スナップショットとは対照的に、バックアップはスナップショットのチェーンを平坦化したバージョンと考えることができます。階層化されたイメージがフラットなイメージに変換されるときに情報が失われるのと同様に、スナップショットのチェーンがバックアップに変換されるときにもデータが失われます。両方の変換において、上書きされたデータは失われます。

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

スナップショットは数百ギガバイトになることがありますが、バックアップは2 MBのファイルで構成されています。

同じ元のボリュームの各新しいバックアップは増分であり、スナップショット間の変更されたブロックを検出して送信します。これは比較的簡単な作業です。なぜなら、各スナップショットは 差分ファイルであり、最後のスナップショットからの変更のみを保存するからです。この設計は、ブロックが変更されていない場合にバックアップが取得されると、そのバックアップがバックアップストアで0バイトとして表示されることを意味します。しかし、そのバックアップから復元すると、バックアップストアにすでに存在する必要なブロックを復元するため、完全なボリュームデータが含まれます。

非常に多くの小さなストレージブロックを保存しないようにするために、SUSE Storageは2 MBブロックを使用してバックアップ操作を実行します。これは、2 MBの境界内の任意の4Kブロックが変更された場合、SUSE Storageが全体の2 MBブロックをバックアップすることを意味します。これは、管理のしやすさと効率のバランスを提供します。

図3。二次ストレージのバックアップと一次ストレージのスナップショットの関係

上記の図は、スナップショットからバックアップがどのように作成されるかを示しています：

バックアップが二次ストレージから削除されると、SUSE Storageは使用しているすべてのブロックを削除しません。代わりに、定期的にガーベジコレクションを実行して、二次ストレージから未使用のブロックをクリーンアップします。

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

スペースを節約するために、バックアップ間で変更されなかった2 MB ブロックは、二次ストレージで同じバックアップボリュームを共有する複数のバックアップに再利用できます。チェックサムを使用して2 MB ブロックにアドレスを付けるため、同じボリューム内の2 MB ブロックに対してある程度の重複排除を達成します。

ボリュームレベルのメタデータはvolume.cfgに保存されます。各バックアップのメタデータファイル（例：snap2.cfg）は比較的小さく、バックアップ内のすべての2 MB ブロックの オフセットと チェックサムのみを含んでいます。

各2 MB ブロック（.blkファイル）は圧縮されています。

バックアップ操作は、定期スナップショットおよびバックアップ機能を使用してスケジュールできますが、必要に応じて実行することもできます。

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

バックアップの作成は、ネットワークを通じてデータをコピーすることを含むため、時間がかかります。

災害復旧（DR）ボリュームは、メインクラスター全体がダウンした場合に備えて、バックアップクラスターにデータを保存する特別なボリュームです。DRボリュームは、SUSE Storageボリュームのレジリエンシーを高めるために使用されます。

DRボリュームの主な目的はバックアップからデータを復元することなので、このタイプのボリュームはアクティブ化される前に以下のアクションをサポートしていません：

DRボリュームは、バックアップストアのボリュームのバックアップから作成できます。DRボリュームが作成された後、SUSE Storageはその元のバックアップボリュームを監視し、最新のバックアップから段階的に復元します。バックアップボリュームは、同じボリュームの複数のバックアップを含むバックアップストア内のオブジェクトです。

メインクラスターの元のボリュームがダウンした場合、DRボリュームはバックアップクラスターで即座にアクティブ化でき、バックアップストアからバックアップクラスター内のボリュームへのデータ復元に必要な時間を短縮します。

DRボリュームがアクティブ化されると、SUSE Storageは元のボリュームの最後のバックアップを確認します。そのバックアップがすでに復元されていない場合、復元が開始され、アクティブ化アクションは失敗します。ユーザーは復元が完了するまで待ってから再試行する必要があります。

設定のバックアップターゲットは、DRボリュームが存在する場合は更新できません。

DRボリュームがアクティブ化された後、それは通常のSUSE Storageボリュームになり、非アクティブ化することはできません。

増分復元は通常、定期的なバックアップストアの更新によってトリガーされます。バックアップターゲット設定画面で更新間隔を設定できます（バックアップと復元 → バックアップターゲット）。

この間隔は、回復時間目標（RTO）に影響を与える可能性があることに注意してください。間隔が長すぎると、災害復旧ボリュームが復元するためのデータ量が多くなり、時間がかかる可能性があります。

回復ポイント目標（RPO）は、バックアップボリュームの定期的なバックアップスケジュールによって決まります。通常のボリュームAの定期的なバックアップスケジュールが毎時バックアップを作成する場合、RPOは1時間です。ここで、SUSE Storageにおける定期バックアップのハウツーを確認できます。

以下の分析は、ボリュームが毎時バックアップを作成し、1つのバックアップからのデータの増分復元に5分かかると仮定しています：

広く言えば、Kubernetesで永続ストレージを使用する主な方法は二つあります：

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

言い換えれば、Kubernetesで既存のストレージを設定するための典型的なワークフローは次のようになります：

PVCがストレージの一部を要求すると、Kubernetes APIサーバーは、そのPVCを事前に割り当てられたPVと一致させようとします。一致が見つかれば、PVCはPVにバインドされ、ユーザーはその事前に割り当てられたストレージを使用し始めます。

一致するボリュームが存在しない場合、PersistentVolumeClaimsは無期限にバインドされないままとなります。例えば、50 GiのPVが多数プロビジョニングされたクラスターは、100 Giを要求するPVCと一致しません。100 GiのPVがクラスターに追加されると、PVCはバインドされる可能性があります。

言い換えれば、無限にPVCを作成できますが、KubernetesコントロールプレーンがPVCが要求するディスクスペース以上の十分なPVを見つけられた場合にのみ、PVにバインドされます。

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

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

Kubernetesクラスターの管理者は、提供するストレージの"`classes`"を説明するためにKubernetes StorageClassを使用できます。StorageClassは、異なる容量制限、異なるIOPS、またはプロビジョナーがサポートする他の任意のパラメータを持つことができます。ストレージベンダー特有のプロビジョナーは、StorageClassと共に使用され、StorageClassオブジェクトに設定されたパラメータに従ってPVを自動的に割り当てます。また、プロビジョナーは、ユーザーのリソースクォータと権限要件を強制する能力を持っています。この設計では、管理者はPVの必要性を予測し、それを割り当てるという不必要な作業から解放されます。

StorageClassが使用されると、Kubernetes管理者はすべてのストレージを割り当てる責任を負いません。管理者は、特定のストレージプールへのアクセス権をユーザーに与え、ユーザーのクォータを決定するだけで済みます。その後、ユーザーはストレージプールから必要なストレージの部分を切り出すことができます。

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

SUSE Storageは、Kubernetesワークロードが必要に応じて永続ストレージの部分を切り出すことができるようにStorageClassを導入します。

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

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

これらのPVCはStorageClassを使用して作成されるため、StatefulSetがスケールアップすると自動的に設定されます。

StatefulSetがスケールダウンすると、余分なPV/PVCはクラスターに保持され、StatefulSetが再びスケールアップする際に再利用されます。

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

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