第5章 永続ストレージの最適化
5.1. 概要
ストレージを最適化すると、全リソースでストレージの使用を最小限に抑えることができます。管理者は、ストレージを最適化することで、既存のストレージリソースが効率的に機能できるようにすることができます。
本ガイドでは、永続ストレージの最適化に重点を置いています。Pod の有効期間に使用されるデータ向けのローカルの一時ストレージのオプションは少なくなります。一時ストレージは、一時ストレージのテクノロジープレビューを有効化した場合のみ利用できます。この機能はデフォルトでは無効になっています。詳細情報は、「一時ストレージの設定」を参照してください。
5.2. 一般的なストレージガイドライン
以下の表では、OpenShift Container Platform で利用可能な永続ストレージ技術を紹介します。
| ストレージタイプ | 説明 | 例 |
|---|---|---|
|
ブロック |
|
コンバージドモード/インデペンデントモード GlusterFS [a] iSCSI、Fibre Channel、Ceph RBD、OpenStack Cinder、AWS EBS [a]、Dell/EMC Scale.IO、VMware vSphere Volume、GCE 永続ディスク[a]、Azure Disk |
|
ファイル |
|
コンバージドモード/インデペンデントモード GlusterFS [a]、RHEL NFS、NetApp NFS [b]、Azure File、Vendor NFS、Vendor GlusterFS [c]、Azure File、AWS EFS |
|
オブジェクト |
|
コンバージドモード/インデペンデントモード GlusterFS [a]、Ceph Object Storage (RADOS Gateway)、OpenStack Swift、Aliyun OSS、AWS S3、Google Cloud Storage、Azure Blob Storage、Vendor S3 [c]、Vendor Swift [c] |
[a]
コンバージドモード/インデペンデントモード GlusterFS、Ceph RBD、OpenStack Cinder、AWS EBS、Azure Disk、GCE 永続ディスク、および VMware vSphere は、OpenShift Container Platform で永続ボリューム (PV) の動的プロビジョニングをネイティブにサポートします。
[b]
NetApp NFS は Trident プラグインを使用する場合に動的 PV のプロビジョニングをサポートします。
[c]
Vendor GlusterFS、Vendor S3 および Vendor Swift のサポート機能および設定機能は異なる場合があります。
| ||
OpenShift Container Platform 3.6.1 では、コンバージドモード GlusterFS (ハイパーコンバージドまたはクラスターホストのストレージソリューション) およびインデペンデントモード GlusterFS (外部ホストのストレージソリューション) を、OpenShift Container Platform レジストリー、ロギング、メトリクス用のブロック、ファイルおよびオブジェクトストレージのインターフェースに使用できます。
5.3. ストレージの推奨事項
以下の表では、特定の OpenShift Container Platform クラスターアプリケーション向けに設定可能な推奨のストレージ技術についてまとめています。
| ストレージタイプ | ROX [a] | RWX [b] | レジストリー | スケーリングされたレジストリー | メトリクス | ロギング | アプリ |
|---|---|---|---|---|---|---|---|
|
ブロック |
はい [c] |
いいえ |
設定可能 |
設定不可 |
推奨 |
推奨 |
推奨 |
|
ファイル |
はい [c] |
はい |
設定可能 |
設定可能 |
設定可能 |
設定可能 |
推奨 |
|
オブジェクト |
はい |
はい |
推奨 |
推奨 |
設定不可 |
設定不可 |
設定不可 [d] |
[a]
ReadOnlyMany
[b]
ReadWriteMany
[c]
これは、物理ディスク、VM 物理ディスク、VMDK、NFS 経由のループバック、AWS EBS および Azure Disk には該当しません。
[d]
オブジェクトストレージは、OpenShift Container Platform の PV/永続ボリューム要求 (PVC: Persistent Volume Claim) で消費されません。アプリは、オブジェクトストレージの REST API と統合する必要があります。
| |||||||
スケーリングされたレジストリーとは、3 つ以上の Pod レプリカが稼働する OpenShift Container Platform レジストリーのことです。
5.3.1. 特定アプリケーションのストレージの推奨事項
5.3.1.1. レジストリー
スケーリングなし/高可用性 (HA) ではない OpenShift Container Platform レジストリークラスターのデプロイメント:
- 推奨されるストレージ技術はオブジェクトストレージであり、次はブロックストレージです。ストレージ技術は、RWX アクセスモードをサポートする必要はありません。
- ストレージ技術は、リードアフターライト (Read-After-Write) の一貫性を確保する必要があります。NAS ストレージ (オブジェクトストレージインターフェースを使用するのでコンバージドモード/インデペンデントモード GlusterFS 以外) は、実稼働環境のワークロードがある OpenShift Container Platform レジストリークラスターデプロイメントには推奨しません。
-
hostPathボリュームは、スケーリングなし/非 HA の OpenShift Container Platform レジストリー用に設定可能ですが、クラスターデプロイメントには推奨しません。
Red Hat のテスト時に、NFS (RHEL 上) をレジストリーのストレージバックエンドとして使用する場合の問題が確認されました。そのため、(RHEL 上で) NFS をレジストリーのストレージバックエンドとして使用することは推奨していません。
市場で提供されている他の NFS の実装には Red Hat のテスト時に確認された問題がない可能性があります。実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
5.3.1.2. スケーリングされたレジストリー
スケーリングされた/高可用性 (HA) の OpenShift Container Platform レジストリーのクラスターデプロイメント:
- 推奨されるストレージ技術はオブジェクトストレージです。ストレージ技術は、RWX アクセスモードをサポートし、リードアフターライトの一貫性を確保する必要があります。
- 実稼働環境のワークロードを処理するスケーリングされた/HA の OpenShift Container Platform レジストリークラスターのデプロイメントには、ファイルストレージやブロックストレージは推奨しません。
- すべての NAS ストレージ (オブジェクトストレージインターフェースを使用するので コンバージドモード/インデペンデントモード GlusterFS 以外) は、実稼働環境のワークロードがある OpenShift Container Platform レジストリーのクラスターデプロイメントには推奨しません。
Red Hat のテスト時に、NFS (RHEL 上) をレジストリーのストレージバックエンドとして使用する場合の問題が確認されました。そのため、(RHEL 上で) NFS をレジストリーのストレージバックエンドとして使用することは推奨していません。
市場で提供されている他の NFS の実装には Red Hat のテスト時に確認された問題がない可能性があります。実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
5.3.1.3. メトリクス
OpenShift Container Platform がホストするメトリクスのクラスターデプロイメント:
- 推奨されるストレージ技術はオブジェクトストレージです。
- NAS ストレージ (iSCSI からのオブジェクトストレージインターフェースを使用するのでコンバージドモード/インデペンデントモード GlusterFS 以外) は、実稼働環境のワークロードがあるホスト型のメトリクスクラスターデプロイメントには推奨しません。
実稼働環境のワークロードを処理するホスト型のメトリクスを、NFS を使用してバックアップすると、データが破損してしまう可能性があります。
5.3.1.4. ロギング
OpenShift Container がホストするロギングのクラスターデプロイメント:
- 推奨されるストレージ技術はオブジェクトストレージです。
- NAS ストレージ (iSCSI からのオブジェクトストレージインターフェースを使用するのでコンバージドモード/インデペンデントモード GlusterFS 以外) は、実稼働環境のワークロードがあるホスト型のメトリクスクラスターデプロイメントには推奨しません。
実稼働環境のワークロードを処理するホスト型のロギングを、NFS を使用してバックアップすると、データが破損してしまう可能性があります。
5.3.1.5. アプリケーション
以下の例で説明されているように、アプリケーションのユースケースはアプリケーションごとに異なります。
- 動的な PV プロビジョニングをサポートするストレージ技術は、マウント時のレイテンシーが低く、ノードに関連付けられておらず、正常なクラスターをサポートします。
- NFS はリードアフターライト (Read-After-Write) の一貫性を確保しないので、一貫性を確保する必要のあるアプリケーションには推奨していません。
- 同じ共有 NFS エクスポートに書き込みをする必要のあるアプリケーションは、実稼働環境のワークロードがかかると問題が発生する可能性があります。
5.3.2. 特定のアプリケーションおよびストレージの他の推奨事項
- OpenShift Container Platform Internal etcd: etcd の信頼性を最も高く保つには、一貫してレイテンシーが最も低くなるストレージ技術が推奨されます。
- OpenStack Cinder: OpenStack Cinder は ROX アクセスモードのユースケースで適切に機能する傾向にあります。
- データベース: データベース (RDBMS、NoSQL DB など) は、専用のブロックストレージで最適に機能する傾向にあります。
5.4. グラフドライバーの選択
コンテナーのランタイムは、イメージとコンテナーを DeviceMapper および OverlayFS などのグラフドライバー (プラグ可能なストレージ技術) に保存します。それぞれに長所と短所があります。
サポート内容や使用方法の注意点など、OverlayFS に関する詳しい情報は、『Red Hat Enterprise Linux (RHEL) 7 リリースノート』を参照してください。
| 名前 | 説明 | 利点 | 制限 |
|---|---|---|---|
|
デバイスマッパー loop-lvm |
デバイスマッパーのシンプロビジョニングモジュール (dm-thin-pool) を使用して、copy-on-write (CoW) スナップショットを実装します。デバイスマッパーグラフの場所ごとに、2 つのブロックデバイス (データとメタデータ用) をベースにシンプールが作成されます。デフォルトでは、これらのブロックデバイスは、自動作成されるスパースファイルのループバックマウントを使用して、自動的に作成されます。 |
カスタマイズなしですぐに使用できるので、プロトタイプ化や開発の目的で役立ちます。 |
|
|
デバイスマッパーのシンプロビジョニング |
LVM、デバイスマッパー、dm-thinp カーネルモジュールを使用します。ループバックデバイスを削除して、ローパーティション (ファイルシステムなし) に直接移動する点が異なります。 |
|
|
|
OverlayFS |
下層 (親) および上層 (子) のファイルシステムと作業ディレクトリー (子と同じファイルシステム) を組み合わせます。下層のファイルシステムはベースイメージで、新規コンテナーを作成すると、差分が含まれる新しい上層ファイルシステムが作成されます。 |
|
POSIX に準拠しません。 |
サポート内容や使用方法の注意点など、OverlayFS に関する詳しい情報は、『Red Hat Enterprise Linux (RHEL) 7 リリースノート』を参照してください。
実稼働環境の場合、コンテナーイメージやコンテナーの root ファイルシステムストレージには、通常のブロックデバイス (ループデバイス以外) の上層に、論理ボリューム管理 (LVM) シンプールを使用することを推奨します。
ループデバイスを使用すると、パフォーマンスに影響がある可能性があります。そのまま使用を継続できますが、以下の警告メッセージがログに記録されます。
devmapper: Usage of loopback devices is strongly discouraged for production use. Please use `--storage-opt dm.thinpooldev` or use `man docker` to refer to dm.thinpooldev section.
ストレージの設定を容易にするには、docker-storage-setup ユーティリティーを使用して、設定の詳細の多くを自動化します。
Docker ストレージ専用に別のディスクドライブがある場合 (例: /dev/xvdb) には、以下を /etc/sysconfig/docker-storage-setup ファイルに追加します。
DEVS=/dev/xvdb VG=docker_vg
docker-storage-setupサービスを再起動します。# systemctl restart docker-storage-setup
再起動後に、
docker-storage-setupで、docker_vgという名前のボリュームを設定して、シンプールの論理ボリュームを作成します。RHEL でのシンプロビジョニングに関するドキュメントは、『LVM 管理ガイド』で確認できます。新規作成したボリュームは、lsblkコマンドで表示します。# lsblk /dev/xvdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvdb 202:16 0 20G 0 disk └─xvdb1 202:17 0 10G 0 part ├─docker_vg-docker--pool_tmeta 253:0 0 12M 0 lvm │ └─docker_vg-docker--pool 253:2 0 6.9G 0 lvm └─docker_vg-docker--pool_tdata 253:1 0 6.9G 0 lvm └─docker_vg-docker--pool 253:2 0 6.9G 0 lvm
注記シンプロビジョニングされたボリュームはマウントされず、ファイルシステムもないので (個別のコンテナーには XFS ファイルシステムがない)、
dfの出力には表示されません。Docker が LVM シンプールを使用していることを確認して、ディスク領域の使用状況をモニタリングするには、
docker infoコマンドを使用します。Pool Nameは、/etc/sysconfig/docker-storage-setup で指定したVGと同じです。# docker info | egrep -i 'storage|pool|space|filesystem' Storage Driver: devicemapper Pool Name: docker_vg-docker--pool Pool Blocksize: 524.3 kB Backing Filesystem: xfs Data Space Used: 62.39 MB Data Space Total: 6.434 GB Data Space Available: 6.372 GB Metadata Space Used: 40.96 kB Metadata Space Total: 16.78 MB Metadata Space Available: 16.74 MB
デフォルトでは、シンプールは下層のブロックデバイスの 40% を使用するように設定されています。ストレージを使用していくにつれ、LVM は自動的にプールを最大 100% まで拡張します。Data Space Total の値が下層の LVM デバイスの古サイズに一致しないのは、この理由によります。この自動拡張技術は、Red Hat Enterprise Linux と、単一パーティションのみを使用する Red Hat Atomic Host の両方で使用するストレージのアプローチを統合するために使用されてきました。
開発において、Red Hat ディストリビューションの Docker はループバックマウントが実行されたスパースファイルにデフォルト設定されています。お使いのシステムでループバックモードを使用しているかどうかを確認するには、以下を実行します。
# docker info|grep loop0 Data file: /dev/loop0
Red Hat は、実稼働環境のワークロードを使用するシンプールモードでは DeviceMapper ストレージドライバーを使用することを強く推奨します。
Overlay は、Red Hat Enterprise Linux 7.2 の時点で、コンテナーランタイムのユースケースについてもサポートされ、起動時間の加速化、ページキャッシュ共有が可能になるため、全体的なメモリー使用率を下げて高密度化できる可能性があります。
5.4.1. SELinux で OverlayFS または DeviceMapper を使用する利点
OverlayFS ファイルシステムの主な利点は、同じノードでイメージを共有するコンテナー間で Linux ページキャッシュが共有される点です。OverlayFS のこの特性により、コンテナーの起動時の出入力 (I/O) が減り (数百ミリ秒単位でコンテナーの起動時間が短縮)、同様のイメージがノードで実行されている場合にメモリーの使用率が減少します。これらはいずれも、(ビルドファームなど) コンテナーのチャーンレートを高め、密度を最適化する場合や、イメージの内容に重複が多い環境などの多くの環境で利点があります。
シンプロビジョニングのデバイスがコンテナーごとに割り当てられるので、DeviceMapper ではページキャッシュの共有はできません。
DeviceMapper は、Red Hat Enterprise Linux のデフォルトの Docker ストレージ設定です。コンテナーストレージ技術としての OverlayFS の使用は評価中であり、今後のリリースで Red Hat Enterprise Linux を OverlayFS にデフォルトで移行することも検討中です。
5.4.2. Overlay と Overlay2 のグラフドライバーの比較
OverlayFS はユニオンファイルシステムの 1 つです。ファイルシステムの上に別のファイルシステムを重ねる (オーバーレイする) ことができます。変更は上層のファイルシステムに記録され、下層のファイルシステムは未変更のままになります。コンテナーや DVD-ROM などのファイルシステムイメージを複数のユーザーで共有でき、ベースのイメージは読み取り専用メディアに置かれます。
OverlayFS は、単一の Linux ホストで 2 つのディレクトリーに階層化し、それらを 1 つのディレクトリーとして表示します。これらのディレクトリーは階層と呼ばれ、統合プロセスはユニオンプロセスと呼ばれます。
OverlayFS は、2 つのグラフドライバー overlay または overlay2 のいずれかを使用します。Red Hat Enterprise Linux 7.2 の時点では、overlay グラフドライバーがサポートされるようになりました。Red Hat Enterprise Linux 7.4 時点で、overlay2 がサポートされるようになりました。Docker デーモン上の SELinux は、Red Hat Enterprise Linux 7.4 でサポートされるようになりました。サポート内容やご利用のヒントなど、お使いの RHEL バージョンでの OverlayFS の使用に関する情報は、『Red Hat Enterprise Linux リリースノート』を参照してください。
overlay2 ドライバーは、最大 128 個の 下層にある OverlayFS 階層をネイティブでサポートしますが、overlay ドライバーは下層の OverlayFS 階層 1 つでしか機能しません。この機能が原因で、overlay2 ドライバーの方が、docker build などの階層関連の Docker コマンドのパフォーマンスが優れており、サポートするファイルシステムで使用する inode が少なくなります。
overlay ドライバーは、下層にある単一の OverlayFS 階層で機能するので、複数の OverlayFS 階層として複数階層のイメージを実装できません。代わりに、各イメージ階層は、/var/lib/docker/overlay の配下に独自のディレクトリーとして実装されます。下層にある階層と共有されるデータを参照する場合には、スペース効率が配慮された方法としてハードリンクが使用されます。
Docker は inode の使用において効率が良いので、overlay ドライバーではなく、OverlayFS のある overlay2 ドライバーを使用することが推奨されています。
RHEL または CentOS で Overlay2 を使用するには、バージョン 3.10.0-693 以降のバージョンが必要です。
