この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

これは未公開の文書です SUSE® Storage 1.12 (Dev).

バックイメージ

SUSE Storage はバックイメージをネイティブにサポートしています。

QCOW2 または RAW イメージは、SUSE Storage ボリュームのバックイメージ/ベースイメージとして設定でき、SUSE Storage は SUSE Virtualization のような仮想化ソリューションと統合されます。

イメージサイズは 512 バイトの倍数 でなければなりません。SUSE Storage は直接 I/O を使用し、ファイルサイズを基盤となるストレージブロックサイズに合わせる必要があります。

V1 データエンジンバックイメージを作成する

パラメータ

Data Source

サポートされているデータソースのいずれかを使用して、V1 バックイメージを準備できます。

  1. バックイメージファイルをダウンロードします（URLを使用）。

  2. ローカルマシンからファイルをアップロードします。このオプションは SUSE Storage UI ユーザーに利用可能です。

  3. 既存のクラスター内ボリュームをバックイメージとしてエクスポートします。

  4. バックアップストアからバックイメージを復元します。詳細については、バックイメージバックアップ を参照してください。

  5. バックイメージをクローンします。

ボリュームのエクスポート

バックイメージは SUSE Storage ボリュームのスナップショットチェーンにおける初期スナップショットとして機能します。関連するバックイメージを持つボリュームをエクスポートすると、SUSE Storage はそのイメージをデルタ変更と統合し、新しい統合バックイメージを生成します。

[チェックサム]

  • バックイメージのチェックサムは、実際のコンテンツではなく、バックイメージ ファイル 全体の SHA512 チェックサム です。 違いは何ですか？SUSE Storage が qcow2 ファイルのチェックサムを計算する際、qcow ライブラリを使用して正しいコンテンツを読み取るのではなく、RAWファイルとして読み取ります。言い換えれば、ユーザーはファイル形式に関係なく shasum -a 512 <the file path> を実行することで常に正しいチェックサムを取得します。

  • バックイメージ作成時に期待されるチェックサムを提供することをお勧めします。 そうでなければ、SUSE Storage は最初のファイルのチェックサムを正しいものと見なします。最初のファイルの準備に何か問題があると、期待される値として不正なチェックサムが生成され、このバックイメージはおそらく利用できません。

スケジューリング

  • SUSE Storage は最初にバックイメージファイルをランダムなノードとディスクに準備して保存し、その後、レプリカを保存しているディスクにファイルを複製します。

  • スペース効率を向上させるために、特定のノードとディスクのセットにバックイメージファイルを強制的に保存するために nodeSelector と diskSelector を追加できます。

  • レプリカは、バックイメージをスケジュールできないノードやディスクにはスケジュールできません。

部数

  • クラスタ内に複数のバックイメージファイルが存在することを保証するために minNumberOfCopies を追加できます。

  • グローバル設定で minNumberOfCopies を調整して、BackingImage にデフォルト値を適用できます。

バックイメージを作成する方法

SUSE Storage UI を使用してバックイメージを作成する

高度な  バックイメージ ページでは、ユーザーはあらゆる種類のデータソースを使用してバックイメージを作成できます。

YAML を使用して V1 バックイメージを作成する

YAML を介してファイルをダウンロードするか、既存のボリュームをバックイメージとしてエクスポートできます。 YAML を介してファイルを「アップロード」しない方が良いです。そうでなければ、HTTP リクエストを介してデータのアップロードを手動で処理する必要があります。

たとえば、次のようになります。

apiVersion: longhorn.io/v1beta2
kind: BackingImage
metadata:
  name: bi-download
  namespace: longhorn-system
spec:
  dataEngine: v1
  minNumberOfCopies: 2
  nodeSelector:
    - "node1"
  diskSelector:
    - "disk1"
  sourceType: download
  sourceParameters:
    url: https://longhorn-backing-image.s3-us-west-1.amazonaws.com/parrot.raw
  checksum: 304f3ed30ca6878e9056ee6f1b02b328239f0d0c2c1272840998212f9734b196371560b3b939037e4f4c2884ce457c2cbc9f0621f4f5d1ca983983c8cdf8cd9a
apiVersion: longhorn.io/v1beta2
kind: BackingImage
metadata:
  name: bi-export
  namespace: longhorn-system
spec:
  dataEngine: v1
  minNumberOfCopies: 2
  nodeSelector:
    - "node1"
  diskSelector:
    - "disk1"
  sourceType: export-from-volume
  sourceParameters:
    volume-name: vol-export-src
    export-type: qcow2

StorageClass と PVC を使用してバックイメージを作成する

  1. Longhorn StorageClass 内で。

  2. パラメータ backingImageName を設定することは、SUSE Storage にこのバックイメージをボリューム作成中に使用するように依頼することを意味します。

  3. バックイメージを作成したい場合、CSI ボリューム作成中に存在しない限り、パラメータ backingImageDataSourceType と backingImageDataSourceParameters を設定する必要があります。YAML と同様に、StorageClass で「アップロード」を介してバックイメージを作成しない方が良いです。これらのすべてのパラメータが設定されていて、バックイメージがすでに存在する場合、SUSE Storage は使用する前にパラメータが既存のものと一致するかどうかを検証します。

    • について:`download`

      kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-backing-image-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  backingImage: "bi-download"
  backingImageDataSourceType: "download"
  backingImageDataSourceParameters: '{"url": "https://backing-image-example.s3-region.amazonaws.com/test-backing-image"}'
  backingImageChecksum: "SHA512 checksum of the backing image"
  backingImageMinNumberOfCopies: "2"
  backingImageNodeSelector: "node1"
  backingImageDiskSelector: "disk1"
  dataEngine: "v1"

    • について:`export-from-volume`

      kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-backing-image-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  backingImage: "bi-export-from-volume"
  backingImageDataSourceType: "export-from-volume"
  backingImageDataSourceParameters: '{"volume-name": "vol-export-src", "export-type": "qcow2"}'
  backingImageMinNumberOfCopies: "2"
  backingImageNodeSelector: "node1"
  backingImageDiskSelector: "disk1"
  dataEngine: "v1"

  4. ストレージクラスを使用してPVCを作成します。次に、バックイメージが存在しない場合は（SUSE Storageボリュームを使用して）作成されます。

  5. SUSE Storageは、バックイメージを使用するボリュームがノードに接続されると、ディスクにバックイメージを準備し始めます。

  • ストレージクラスにダウンロードURLを入力する際は、エスケープ文字`\`に注意してください。

  • ストレージクラスを使用して作成されたバックイメージは、ボリュームと同じデータエンジンを持っています。

ボリュームでバックイメージを使用します。

ユーザーは、ストレージクラスを介してバックイメージを直接作成し、すぐに使用するか、以下に示すように既存のバックイメージを利用することもできます。

既存のバックイメージを使用します。

ボリューム作成中に既存のバックイメージを使用します。

  1. 高度な  バックイメージをSUSE Storage UIでクリックします。

  2. *バックイメージを作成*をクリックして、ユニークな名前と有効なURLを持つバックイメージを作成します。

  3. リストからバックイメージを選択します。ボリュームとバックイメージは同じデータエンジンを使用する必要があります。

  4. SUSE Storageは、バックイメージを使用するボリュームがノードに接続されると、ディスクにバックイメージをダウンロードし始めます。

ボリューム復元中に既存のバックイメージを使用します。

  1. `Backup`をクリックして、復元するバックアップボリュームを選択します。

  2. バックアップボリュームにバックイメージがすでに設定されている限り、SUSE Storageは復元中にバックイメージを自動的に選択します。

  3. SUSE Storageは、復元中にバックイメージを再指定または上書きすることを許可します。

バックイメージファイルをダウンロードします。

v1.3.0以降、ユーザーはUIを介して既存のバックイメージファイルをローカルマシンにダウンロードできます。

  • ユーザーは、指定されたバックイメージを使用してボリュームを作成または復元する際に、バックイメージの存在を確認する必要があります。

  • 既存のバックイメージファイルをローカルにダウンロードする前に、ユーザーはそれに対して準備されたファイルがあることを保証する必要があります。

  • V2データエンジンのバックイメージのダウンロードは現在サポートされていません。

V2データエンジンバックイメージを作成する

v1.8.0以降、ユーザーはYAMLで`Data Engine`を設定することにより、V2データエンジンに対応したバックイメージを作成できます（UIまたはStorageClassを通じて）。

パラメータ

すべてのパラメータはV1データエンジンのバックイメージと同じですが、`Data Engine`を除きます。

データソース

サポートされているデータソースのいずれかを使用して、V2データエンジンのバックイメージを準備できます。

  • バックイメージファイルをダウンロードします（URLを使用）。

  • ローカルマシンからファイルをアップロードします。このオプションは SUSE Storage UI ユーザーに利用可能です。

  • 既存のクラスター内V1データエンジンボリュームをバックイメージとしてエクスポートします。

  • バックアップストアからバックイメージを復元します。詳細については、バックイメージバックアップを参照してください。

  • V1バックイメージをクローンします。

  • 現在サポートされていない操作は次のとおりです：

    • V2データエンジンボリュームからのエクスポート

    • V2バックイメージのクローン作成

    • V2バックイメージのバックアップ

  • ファイルベースのV1データエンジンとは異なり、V2データエンジンはバックイメージデータをSPDK論理ボリュームに保存するためにSUSE Storageを必要とします。その結果、qcow2イメージの場合、SUSE Storageはまずqcow2イメージをRAW形式に変換してから、V2データエンジンのバックイメージにデータを保存し、正しいデータを読み取れるようにする必要があります。

バックイメージをクリーンアップする

ディスク内のバックイメージをクリーンアップする

  • SUSE Storageは、設定`Backing Image Cleanup Wait Interval`に基づいて、ディスク上の未使用のバックイメージファイルを自動的にクリーンアップします。しかし、SUSE Storageは各バックイメージに対してディスク上に少なくとも1つのファイルを保持します。

  • SUSE Storage UIを使用して、手動でディスクからバックイメージを削除できます。設定 > *バックイメージ*に移動し、特定のバックイメージの名前をクリックします。開いたウィンドウで、1つ以上のディスクを選択し、次に*クリーンアップ*をクリックします。

  • バックイメージを使用しているディスクに1つのレプリカが存在する限り、レプリカの現在の状態に関係なく、このディスク内のバックイメージファイルはクリーンアップできません。

バックイメージの削除

  • バックイメージは、それを使用しているボリュームがない場合にのみ削除できます。

バックイメージの回復

  • 1つのディスクにまだ準備が整ったバックイメージファイルがある場合、SUSE Storageは自動的に失敗したバックイメージファイルをクリーンアップし、次に準備が整ったファイルからこれらのファイルを再起動します。

  • もしバックイメージのすべてのファイルが失敗し、最初のファイルが次のような場合：

    • URLからダウンロードされた場合、SUSE Storageはダウンロードを再起動します。

    • 既存のボリュームからエクスポートされた場合、SUSE Storageは（必要に応じてボリュームをアタッチし、次に）エクスポートを再起動します。

    • ユーザーのローカル環境からアップロードされた場合、回復する方法はありません。ユーザーはこのバックイメージを削除し、ファイルを再アップロードすることで新しいものを再作成する必要があります。

  • ノードがダウンしているか、ノード上のバックイメージマネージャーポッドが利用できない場合、ノード上のすべてのバックイメージファイルは`unknown`になります。後で、ノードが復帰し、ポッドが実行されている場合、SUSE Storageはそれを検出し、既存のファイルを自動的に再利用します。

バックイメージの追放

  • `Scheduling`を`Disabled`に、`Eviction Requested`を`True`に設定することで、ノードまたはディスクからすべてのバックイメージファイルを手動で追放できます。

  • クラスターにバックイメージファイルが1つだけ存在する場合、SUSE Storageは最初にそのファイルを別のディスクに複製し、次にそのファイルを削除します。

  • バックイメージファイルを他のディスクに複製できない場合、SUSE Storageはそのファイルを削除しません。設定を更新して問題を解決できます。

バックイメージワークフロー

  1. ディスク上のすべてのバックイメージファイルを管理するために、SUSE Storageは各ディスクに対して単一のバックイメージマネージャーポッドを作成します。ディスクにバックイメージファイルの要件がなくなると、バックイメージマネージャーは自動的に削除されます。

  2. バックイメージマネージャーがディスクのためにバックイメージファイルを準備すると、そのファイルはこのディスク内のすべてのボリュームレプリカで共有されます。

  3. バックイメージが作成されると、SUSE Storageは初期ファイルを準備するためにバックイメージデータソースポッドを起動します。ファイルデータは、ユーザーによって指定されたソースから取得されます。たとえば、リモートロケーションからのダウンロード、ローカルファイルからのアップロード、または既存のボリュームからのエクスポートなどです。準備が完了すると、同じディスク上のバックイメージマネージャーポッドがファイルを引き継ぎ、SUSE Storageはデータソースポッドを停止します。

  4. 新しいバックイメージがボリュームによって使用されると、そのボリュームレプリカが存在するディスクのバックイメージマネージャーポッドは、すでにファイルを含むバックイメージマネージャーポッドからファイルを同期するように求められます。

  5. セクション#clean_up_backing_images_in_disksで述べたように、1つのディスク内のすべてのレプリカが1つのバックイメージファイルを使用しない場合、ファイルは自動的にクリーンアップされます。

バックイメージ同期の同時制限

  • グローバル設定の`Concurrent Backing Image Replenish Per Node Limit`は、ノード上で同時に補充できるバックイメージのコピーの数を制御します。

  • 0に設定されている場合、SUSE StorageはminNumberOfCopiesを下回っていても自動的にコピーを補充しません。

警告

  • バックイメージのダウンロードURLは公開されている必要があります。将来的にこの部分を改善します。

  • ファイルダウンロードの後に1つのバックイメージマネージャーポッドのメモリ使用量が高い場合、これはシステムキャッシュ/バッファが原因です。メモリ使用量は自動的に減少するため、心配する必要はありません。詳細については GitHubチケットを参照してください。

履歴