--- relatedlinks: https://www.youtube.com/watch?v=z_OKwO5TskA --- (storage-drivers)= # ストレージドライバ LXD はイメージ、インスタンスとカスタムボリュームを保管するのに以下のストレージドライバをサポートします。 ```{toctree} :maxdepth: 1 storage_dir storage_btrfs storage_lvm storage_zfs storage_ceph storage_cephfs storage_cephobject ``` ドライバ固有の情報と設定オプションについては対応するページを参照してください。 (storage-drivers-features)= ## 機能比較 可能であれば、各システムの高度な機能を使って、LXD は操作を最適化しようとします。 機能 | ディレクトリ | Btrfs | LVM | ZFS | Ceph RBD | CephFS | Ceph Object :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- {ref}`storage-optimized-image-storage` | no | yes | yes | yes | yes | n/a | n/a 最適化されたインスタンスの作成 | no | yes | yes | yes | yes | n/a | n/a 最適化されたスナップショットの作成 | no | yes | yes | yes | yes | yes | n/a 最適化されたイメージの転送 | no | yes | no | yes | yes | n/a | n/a {ref}`storage-optimized-volume-transfer` | no | yes | no | yes | yes | n/a | n/a コピーオンライト | no | yes | yes | yes | yes | yes | n/a ブロックデバイスベース | no | no | yes | no | yes | no | n/a インスタントクローン | no | yes | yes | yes | yes | yes | n/a コンテナ内でストレージドライバの使用 | yes | yes | no | no | no | n/a | n/a 古い(最新ではない)スナップショットからのリストア | yes | yes | yes | no | yes | yes | n/a ストレージクオータ | yes{ref}`* ` | yes | yes | yes | yes | yes | yes `lxd init` で利用可能 | yes | yes | yes | yes | yes | no | no オブジェクトストレージ | yes | yes | yes | yes | no | no | yes (storage-optimized-image-storage)= ### 最適化されたイメージストレージ ディレクトリドライバを除く全てのストレージドライバはなんらかの種類の最適化されたイメージ保管フォーマットがあります。 インスタンスの作成をほぼ瞬時に行うため、 LXD はインスタンスの作成時にイメージの tarball を一から解凍するのではなく事前に作成したイメージボリュームを複製します。 全く使われないかもしれないイメージのためにストレージプール上にそのようなボリュームを準備するのを避けるため、ボリュームはオンデマンドで生成されます。 このため、最初のインスタンスの作成は後続のインスタンスより時間がかかります。 (storage-optimized-volume-transfer)= ### 最適化されたボリュームの転送 Btrfs, ZFS と Ceph RBD は内部で送信/受信の機構を持ち最適化されたボリューム転送を行えます。 同じストレージドライバを使うストレージプール間でボリュームを転送する場合、ストレージドライバが最適化された転送をサポートしている場合は、LXDはこの最適化された転送を使用し、最適化された転送のほうが速いです。 そうでない場合は、LXDはコンテナとファイルシステムボリュームを転送するのに`rsync`を使用するか、仮想マシンとカスタムボリュームブロックを転送するのにrawブロック転送を使います。 最適化された転送は下層のストレージドライバのデータ転送のネイティブの機能を使い、`rsync`を使うより通常は速いです。 しかし、最適化された転送のフルのポテンシャルが明らかになるのは、インスタンスや定期的なスナップショットを使用するカスタムボリュームのコピーを更新するときです。 - 初回のスナップショットを作成しコピーを更新する際、転送はほぼフルコピーと同じ時間がかかります。 LXDは新しいスナップショットとスナップショットとメインボリュームの差分を転送します。 - 後続のスナップショットでは、転送は大幅に速くなります。 LXDはフルの新規のスナップショットは転送せず、新規のスナップショットとターゲット上に存在する最新のスナップショットとの差分のみを転送します。 - 新規のスナップショット無しで更新する場合、LXDはメインボリュームとターゲット上に存在する最新のスナップショットとの差分のみを転送します。 この転送は`rsync`を使うより通常は速いです(最新のスナップショットがあまりにも古すぎない限りは)。 一方で、スナップショットなしのインスタンスのコピーを更新する際は`rsync`を使うよりも(インスタンスがスナップショットを1つも持っていないか、リフレッシュが`--instance-only`フラグを使うことのために)遅くなるでしょう。そのような場合には最適化された転送であれば(存在しない)最新のスナップショットとメインボリュームの差分、つまりフルのボリュームを転送したでしょう。 ですので、LXDはスナップショットがないリフレッシュには最適化された転送ではなく`rsync`を使用します。 ## おすすめのセットアップ LXD で使う場合のベストな 2 つのオプションは ZFS と Btrfs です。 このふたつは同様の機能を持ちますが、ZFS のほうがより信頼性が上です。 可能であれば、LXD のストレージプールにディスク全体かパーティションを専用で使用させるべきです。 LXD で loop ベースのストレージを作れますが、プロダクション環境ではおすすめしません。 詳細は {ref}`storage-location` を参照してください。 ディレクトリーバックエンドは最後の手段の選択肢と捉えるべきです。 LXD の全てのメインの機能をサポートしますが、インスタントコピーやスナップショットを実行できないため遅く非効率です。 そのため、絶えずインスタンスのストレージ全体をコピーすることになります。 ## セキュリティの考慮 現在、 Linux Kernel はブロックベースのファイルシステム(例: `ext4`)が別のオプションでマウント済みの場合マウントオプションは黙って無視し適用しません。 これは専用ディスクデバイスが異なるストレージプール間で異なるマウントオプションで共有されている時、2つめのマウントは期待しているマウントオプションにならないかもしれないことを意味します。 これは例えば1つめのストレージプールが `acl` サポートを提供する想定で、2つめのストレージプールが `acl` サポートを提供しない想定であるようなときにセキュリティ上の問題になります。 この理由により、現状はストレージプールごとに専用のディスクデバイスを持つか、同じ専用ディスクを共有する全てのストレージプールで確実に同じマウントオプションを使うことを推奨します。