Docker ストレージ ドライバーとは何ですか?

Docker ストレージ ドライバーには、1. ファイル レベルのストレージ ドライバーである AUFS、2. Union FS であるオーバーレイ、3. マッピング フレームワーク メカニズムであるデバイス マッパー、4. Btrfs、これはファイルレベルのストレージドライバーでもあり、 5. ZFS、まったく新しいファイルシステムです。

この記事の動作環境: Windows 7 システム、Docker バージョン 20.10.11、Dell G3 コンピューター。

Docker ストレージ ドライバーとは何ですか? Docker の 5 つのストレージ ドライバー原則とそのアプリケーション シナリオ

1. 原則の説明

Docker は当初、ファイル システムとして AUFS を採用していましたが、AUFS 階層化の概念により、複数のコンテナが同じイメージを共有できます。ただし、AUFS は Linux カーネルに統合されておらず、Ubuntu のみをサポートしているため、互換性の問題を考慮して、Docker バージョン 0.7 でストレージ ドライバーが導入されました。現在、Docker は AUFS、Btrfs、デバイス マッパー、OverlayFS、およびZFS 5種類のストレージドライバー。 Docker 公式 Web サイトに記載されているように、単一のドライバーがすべてのアプリケーション シナリオに適しているわけではなく、さまざまなシナリオに応じて適切なストレージ ドライバーを選択することによってのみ、Docker のパフォーマンスを効果的に向上させることができます。適切なストレージ ドライバーを選択するにはどうすればよいですか? より適切な判断を行うには、まずストレージ ドライバーの原則を理解する必要があります。この記事では、Docker の 5 つのストレージ ドライバー原則の詳細な説明と、アプリケーション シナリオと IO パフォーマンス テストの比較を紹介します。原理について説明する前に、コピーオンライトとアロケーションオンライトという 2 つのテクノロジについて説明しましょう。

1. コピーオンライト (CoW)

すべてのドライバーで使用されるテクノロジ、コピーオンライト (CoW)。 CoW はコピーオンライト (書き込みが必要な場合のみコピーすることを意味します) であり、これは既存のファイルの変更シナリオを対象としています。たとえば、イメージに基づいて複数のコンテナを起動する場合、各コンテナにイメージと同様のファイル システムが割り当てられると、多くのディスク領域が占有されます。 CoW テクノロジを使用すると、すべてのコンテナがイメージのファイル システムを共有できます。すべてのデータはイメージから読み取られます。ファイルが書き込まれる場合にのみ、書き込まれるファイルは変更のためにイメージから独自のファイル システムにコピーされます。 。したがって、同じイメージを共有するコンテナーの数に関係なく、書き込み操作はイメージから独自のファイル システムにコピーされたコピーに対して実行され、イメージのソース ファイルは変更されず、複数のコンテナー操作が同時に実行されます。ファイルは各コンテナのファイル システムにコピーを生成します。各コンテナは独自のコピーを変更します。このコピーは互いに分離されており、相互に影響を及ぼしません。 CoW を使用すると、ディスク使用率を効果的に改善できます。

2. オンデマンド割り当て

オンデマンド割り当ては、ファイルがもともと存在しないシナリオで、新しいファイルが書き込まれる場合にのみ使用されます。スペースを割り当てる前にスペースを割り当てると、ストレージ リソースの使用率が向上します。たとえば、コンテナの起動時に、一部のディスク領域がコンテナに事前に割り当てられるのではなく、新しいファイルが書き込まれるときにオンデマンドで新しい領域が割り当てられます。

2. 5 つのストレージ ドライバーの基本原則

1、AUFS

AUFS (AnotherUnionFS) ) は Union FS であり、ファイル レベルのストレージ ドライバーです。 AUFS は、階層化されたファイル システムを 1 つ以上の既存のファイル システムに透過的にオーバーレイし、複数のレイヤーをファイル システムの単一レイヤー表現にマージできます。 簡単に言えば、同じ仮想ファイル システムのファイル システムへの異なるディレクトリのマウントをサポートします。。このファイル システムは、ファイルをレイヤーごとに変更できます。以下の層が読み取り専用であっても、書き込み可能なのは最上位のファイル システムのみです。ファイルを変更する必要がある場合、AUFS はファイルのコピーを作成し、CoW を使用してファイルを読み取り専用レイヤーから書き込み可能レイヤーにコピーして変更します。その結果も書き込み可能レイヤーに保存されます。 Docker では、その下の読み取り専用レイヤーはイメージ、書き込み可能なレイヤーはコンテナーです。構造は次のとおりです。

2、Overlay

Overlay は Linux カーネルでサポートされています。 3.18 以降、これも Union FS です。AUFS の複数のレイヤーとは異なり、Overlay には 2 つのレイヤーしかありません: 上位のファイル システムと下位のファイル システム。それぞれ Docker のイメージ レイヤーとコンテナー レイヤーを表します。 ＃＃＃。ファイルを変更する必要がある場合、CoW を使用してファイルを読み取り専用の下層から書き込み可能な上位層にコピーして変更し、その結果も上位層に保存されます。 Docker では、その下の読み取り専用レイヤーはイメージ、書き込み可能なレイヤーはコンテナーです。構造は以下のとおりです:

3,

デバイスマッパー

デバイス マッパーは、2.6.9 以降の Linux カーネルでサポートされており、論理デバイスから物理デバイスへのマッピング フレームワーク メカニズムを提供します。このメカニズムの下で、ユーザーは自分のニーズに応じてストレージ リソース管理を簡単に策定および実装できます。前述の AUFS と OverlayFS はファイル レベルのストレージですが、デバイス マッパーはブロック レベルのストレージです. すべての操作はファイルではなくブロックに対して直接実行されます。デバイス マッパー ドライバーは、最初にブロック デバイス上にリソース プールを作成し、次にリソース プール上にファイル システムを備えた基本デバイスを作成します。すべてのイメージはこの基本デバイスのスナップショットであり、コンテナーはイメージのスナップショットです。したがって、コンテナーに表示されるファイル システムは、リソース プール上の基本デバイスのファイル システムのスナップショットであり、コンテナーにはスペースが割り当てられません。新しいファイルが書き込まれると、コンテナーのイメージ内でそのファイルに新しいブロックが割り当てられ、データが書き込まれます。これは、時間割り当てと呼ばれます。既存のファイルを変更する場合は、CoW を使用してコンテナー スナップショットにブロック領域を割り当て、変更するデータをコンテナー スナップショット内の新しいブロックにコピーして、それを変更します。デバイス マッパー ドライバーは、デフォルトでイメージとコンテナーを含む 100G ファイルを作成します。各コンテナの容量は 10G に制限されており、自分で構成および調整できます。構造は以下のとおりです。

4, Btrfs

Btrfs は次世代書き込みと呼ばれます。 time ファイル システムをコピーし、Linux カーネルにマージします。これは ファイル レベルのストレージ ドライバーでもありますが、デバイス マッパーのように基盤となるデバイス を直接操作できます。 Btrfs は、ファイル システムの一部を、サブボリュームと呼ばれる完全なサブファイル システムとして構成します。サブボリュームを使用すると、大きなファイル システムを複数のサブファイル システムに分割できます。これらのサブファイル システムは、基盤となるデバイスのスペースを共有し、ディスク スペースが必要なときに基盤となるデバイスから割り当てられます。これは、アプリケーションが malloc() を呼び出して、メモリを割り当てます。デバイススペースを柔軟に利用するために、Btrfs はディスクスペースを複数のチャンクに分割します。各チャンクは、異なるディスク領域割り当て戦略を使用できます。たとえば、メタデータのみを格納するチャンクもあれば、データのみを格納するチャンクもあります。このモデルには、Btrfs がデバイスの動的な追加をサポートするなど、多くの利点があります。ユーザーは新しいディスクをシステムに追加した後、Btrfs コマンドを使用してデバイスをファイル システムに追加できます。 Btrfs は、大規模なファイル システムをリソース プールとして扱い、それを複数の完全なサブファイル システムに構成します。新しいサブファイル システムをリソース プールに追加することもできます。ベース イメージはサブファイル システムのスナップショットです。各サブ-イメージとコンテナー それぞれに独自のスナップショットがあり、これらのスナップショットはすべてサブボリュームのスナップショットです。

#新しいファイルが書き込まれると、コンテナーのスナップショットで新しいデータ ブロックがそのファイルに割り当てられ、ファイルはこのスペースに書き込まれます。これは時間割り当てと呼ばれます。 。既存のファイルを変更する場合は、CoW コピーを使用して新しい元のデータとスナップショットを割り当て、この新しく割り当てられた領域内のデータを変更してから、新しいサブファイル システムとスナップショットを指すように関連するデータ構造を更新します。元の元のデータ そして、スナップショットにはそれを指すポインターがないため、上書きされます。

5, ZFS

ZFS ファイル システムは、ファイル システムの管理を根本的に変える革新的な新しいファイル システムです。このように、ZFS 「ボリューム管理」を完全に放棄し、仮想ボリュームを作成せず、すべてのデバイスをストレージ プールに集中して管理します。「ストレージ プール」の概念を使用して物理ストレージ領域を管理します## ＃。以前は、ファイル システムは物理デバイス上に構築されていました。これらの物理デバイスを管理し、データの冗長性を提供するために、「ボリューム管理」の概念により単一のデバイス イメージが提供されます。 ZFS は、「zpool」と呼ばれる仮想ストレージ プール上に構築されます。各ストレージ プールは、複数の仮想デバイス (vdev) で構成されます。これらの仮想デバイスは、RAW ディスク、RAID1 ミラー デバイス、または非標準の RAID レベルのマルチディスク グループにすることができます。これにより、zpool 上のファイル システムは、これらの仮想デバイスの合計ストレージ容量を使用できるようになります。

Docker での ZFS の使用を見てみましょう。まず、ZFS ファイル システムを zpool からイメージのベース レイヤーに割り当てます。他のイメージ レイヤーは、この ZFS ファイル システム スナップショットのクローンです。スナップショットは読み取り専用で、クローンは書き込み可能です。コンテナーが起動すると、最上位のレイヤーは書き込み可能なレイヤーを生成します。以下に示すように:

新しいファイルを書き込む場合は、オンデマンド割り当てを使用します。新しいデータは zpool から生成され、新しいデータはこのブロックに書き込まれ、この新しいスペースはコンテナー (ZFS クローン) に保管されます。既存のファイルを変更する場合は、コピーオンライトを使用して新しいスペースを割り当て、元のデータを新しいスペースにコピーして変更を完了します。

3. ストレージ ドライバーの比較と適応シナリオ

##1、AUFS VS オーバーレイ## AUFS とオーバーレイはどちらも共同ファイル システムですが、AUFS には複数のレイヤーがあるのに対し、オーバーレイには 2 つのレイヤーしかありません。下位層の場合、AUSF は遅くなる可能性があります。さらに、Overlay は Linux カーネルのメインラインに統合されていますが、AUFS は統合されていないため、AUFS よりも高速である可能性があります。ただし、Overlay はまだ若すぎるため、運用環境での使用には注意が必要です。 Docker の最初のストレージ ドライバーとして、AUFS には長い歴史があり、比較的安定しており、多数のプロダクションで実践されており、強力なコミュニティ サポートがあります。現在のオープンソース DC/OS では、オーバーレイの使用が指定されています。

2、

オーバーレイ VS デバイスマッパー オーバーレイはファイルレベルのストレージであり、デバイスマッパーはブロックレベルですファイルは特に大きく、変更されたコンテンツは非常に小さいです。オーバーレイは、変更されたコンテンツのサイズに関係なく、ファイル全体をコピーします。大きなファイルの変更には、小さなファイルよりも時間がかかります。ただし、ファイルが大きいかどうかは関係ありません。ファイルまたはブロック レベルの小さなファイルの場合、変更する必要があるブロックのみをコピーするだけで、ファイル全体がコピーされるわけではありません。このシナリオでは、デバイス マッパーの方が明らかに高速です。ブロック レベルは論理ディスクに直接アクセスするため、IO 集中型のシナリオに適しています。複雑な内部プログラム、大規模な同時実行性があり、IO が少ないシナリオでは、オーバーレイのパフォーマンスが比較的優れています。

3、

デバイス マッパー VS Btrfs ドライバー VS ZFS デバイス マッパーと Btrfs It の両方はブロック上で直接動作し、共有ストレージをサポートしていません。これは、複数のコンテナが同じファイルを読み取るときに、複数のコピーを保存する必要があることを意味します。そのため、このストレージ ドライバは、高密度コンテナ PaaS プラットフォームでの使用には適していません。さらに、多数のコンテナが起動および停止されると、ディスク オーバーフローが発生し、ホストが動作できなくなる可能性があります。デバイス マッパーは運用環境での使用には推奨されません。Btrfs は Docker ビルドで非常に効率的です。

ZFS はもともと大容量のメモリを搭載した Salaris サーバー向けに設計されているため、使用するとメモリに影響があり、大容量のメモリを備えた環境に適しています。 ZFS の COW は断片化の問題をさらに深刻にし、シーケンシャル書き込みによって生成された大きなファイルの場合、将来その一部がランダムに変更されると、ハードディスク上のファイルの物理アドレスが連続しなくなり、将来のシーケンシャル読み取りのパフォーマンスが低下します。貧しくなるだろう。 ZFS は、キャッシュ ブロックを共有する複数のコンテナをサポートします。これは、PaaS および高密度のユーザー シナリオに適しています。

推奨学習:「

docker チュートリアル

」

以上がDocker ストレージ ドライバーとは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。