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