第5章 永続ストレージの最適化

5.1. 概要

ストレージを最適化すると、全リソースでストレージの使用を最小限に抑えることができます。管理者は、ストレージを最適化することで、既存のストレージリソースが効率的に機能できるようにすることができます。

注記

本ガイドでは、永続ストレージの最適化に重点を置いています。Pod の有効期間に使用されるデータ向けのローカルの一時ストレージのオプションは少なくなります。一時ストレージは、一時ストレージのテクノロジープレビューを有効化した場合のみ利用できます。この機能はデフォルトでは無効になっています。詳細情報は、「一時ストレージの設定」を参照してください。

5.2. 一般的なストレージガイドライン

以下の表では、OpenShift Container Platform で利用可能な永続ストレージ技術を紹介します。

表5.1 利用可能なストレージオプション

ストレージタイプ説明

Block

  • ブロックデバイスとしてオペレーティングシステムに公開されます。
  • ストレージを完全に制御し、ファイルシステムをバイパスしてファイルの低いレベルで操作する必要のあるアプリケーションに適しています。
  • ストレージエリアネットワーク (SAN) とも呼ばれます。
  • 共有できません。一度に 1 つのクライアントだけがこのタイプのエンドポイントをマウントできるという意味です。

コンバージドモード/独立モード GlusterFS [1]、iSCSI、ファイバーチャネル、Ceph RBD、OpenStack Cinder、AWS EBS [1]、Dell/EMC Scale.IO、VMware vSphere ボリューム、GCE 永続ディスク[1]、Azureディスク

File

  • マウントされるファイルシステムのエクスポートとして、OS に公開されます。
  • ネットワークアタッチストレージ (NAS) とも呼ばれます。
  • 同時実行、レイテンシー、ファイルロックのメカニズムその他の各種機能は、プロトコルおよび実装、ベンダー、スケールによって大きく異なります。

コンバージドモード/独立モード GlusterFS [1]、RHEL NFS、NetApp NFS [2]、Azure File、ベンダー NFS、ベンダー GlusterFS [3]、Azureファイル、AWS EFS

Object

  • REST API エンドポイント経由でアクセスできます。
  • OpenShift Container Platform レジストリーで使用するために設定できます。
  • アプリケーションは、ドライバーをアプリケーションやコンテナーに組み込む必要があります。

コンバージドモード/インデペンデントモード GlusterFS [1]、Ceph Object Storage (RADOS Gateway)、OpenStack Swift、Aliyun OSS、AWS S3、Google Cloud Storage、Azure Blob Storage、Vendor S3 [3]、Vendor Swift [3]

  1. コンバージドモード/インデペンデントモード GlusterFS、Ceph RBD、OpenStack Cinder、AWS EBS、Azure Disk、GCE 永続ディスク、および VMware vSphere は、OpenShift Container Platform で永続ボリューム (PV) の動的プロビジョニングをサポートします。
  2. NetApp NFS は Trident プラグインを使用する場合に動的 PV のプロビジョニングをサポートします。
  3. Vendor GlusterFS、Vendor S3 および Vendor Swift のサポート機能および設定機能は異なる場合があります。

コンバージドモード GlusterFS (ハイパーコンバージドまたはクラスターホストのストレージソリューション) またはインデペンデントモード GlusterFS (外部ホストのストレージソリューション) を、OpenShift Container Platform レジストリー、ロギング、モニタリング用のブロック、ファイルおよびオブジェクトストレージに使用できます。

5.3. ストレージの推奨事項

以下の表では、特定の OpenShift Container Platform クラスターアプリケーション向けに設定可能な推奨のストレージ技術についてまとめています。

表5.2 設定可能な推奨のストレージ技術

ストレージタイプRWO [1]ROX [2]RWX [3]レジストリースケーリングされたレジストリーモニタリングロギングアプリ

Block

Yes

Yes [4]

No

設定可能

設定不可

推奨

推奨

推奨

File

Yes

Yes [4]

Yes

設定可能

設定可能

設定可能 [5]

設定可能 [6]

推奨

Object

Yes

Yes

Yes

推奨

推奨

設定不可

設定不可

設定不可能 [7]

  1. ReadWriteOnce
  2. ReadOnlyMany
  3. ReadWriteMany
  4. これは、物理ディスク、VM 物理ディスク、VMDK、NFS 経由のループバック、AWS EBS、 Azure Disk および Cinder (Block の場合は後者) には該当しません。
  5. モニタリングコンポーネントの場合、ReadWriteMany (RWX) アクセスモードのファイルストレージを使用することはできません。ファイルストレージを使用する場合は、モニタリングで使用できるように設定されている Persistent Volume Claim (永続ボリューム要求、PVC) で RWX アクセスモードを設定しないでください。
  6. ロギングの場合、共有ストレージを使用することはアンチパターンとなります。logging-es ごとに 1 つのボリュームが必要です。
  7. オブジェクトストレージは、OpenShift Container Platform の PV/PVC で消費されません。アプリは、オブジェクトストレージの REST API と統合する必要があります。
注記

スケーリングされたレジストリーとは、3 つ以上の Pod レプリカが稼働する OpenShift Container Platform レジストリーのことです。

5.3.1. 特定アプリケーションのストレージの推奨事項

重要

テストにより、RHEL NFS サーバーを RHEL でコンテナーイメージレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリクスストレージの Prometheus 、およびロギングストレージの ElasticSearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS サーバーを使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

5.3.1.1. レジストリー

スケーリングなし/高可用性 (HA) ではない OpenShift Container Platform レジストリークラスターのデプロイメント:

  • 推奨されるストレージ技術はオブジェクトストレージであり、次はブロックストレージです。ストレージ技術は、RWX アクセスモードをサポートする必要はありません。
  • ストレージ技術は、リードアフターライト (Read-After-Write) の一貫性を確保する必要があります。NAS ストレージ (オブジェクトストレージインターフェースを使用するのでコンバージドモード/インデペンデントモード GlusterFS 以外) は、実稼働環境のワークロードがある OpenShift Container Platform レジストリークラスターデプロイメントには推奨しません。
  • hostPath ボリュームは、スケーリングなし/非 HA の OpenShift Container Platform レジストリー用に設定可能ですが、クラスターデプロイメントには推奨しません。

5.3.1.2. スケーリングされたレジストリー

スケーリングされた/高可用性 (HA) の OpenShift Container Platform レジストリーのクラスターデプロイメント:

  • 推奨されるストレージ技術はオブジェクトストレージです。ストレージ技術は、RWX アクセスモードをサポートし、リードアフターライトの一貫性を確保する必要があります。
  • 実稼働環境のワークロードを処理するスケーリングされた/HA の OpenShift Container Platform レジストリークラスターのデプロイメントには、ファイルストレージやブロックストレージは推奨しません。
  • すべての NAS ストレージ (オブジェクトストレージインターフェースを使用するので コンバージドモード/インデペンデントモード GlusterFS 以外) は、実稼働環境のワークロードがある OpenShift Container Platform レジストリーのクラスターデプロイメントには推奨しません。

5.3.1.3. モニタリング

OpenShift Container がホストするモニタリングのクラスターデプロイメント:

  • 推奨されるストレージ技術はオブジェクトストレージです。
  • ファイルストレージを設定する場合は、POSIX 標準に準拠していることを確認してください。
重要

テストの結果、NFS を使用すると修復不能な大規模な破損が発生することが確認されたため、この使用は推奨されません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

5.3.1.4. ロギング

OpenShift Container がホストするロギングのクラスターデプロイメント:

  • 推奨されるストレージ技術はオブジェクトストレージです。
  • NAS ストレージ (iSCSI からのオブジェクトストレージインターフェースを使用するのでコンバージドモード/インデペンデントモード GlusterFS 以外) は、実稼働環境のワークロードがあるホスト型のメトリクスクラスターデプロイメントには推奨しません。
重要

テストにより、NFS サーバーを RHEL でコンテナーイメージレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、ロギングストレージの ElasticSearch が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

5.3.1.5. アプリケーション

以下の例で説明されているように、アプリケーションのユースケースはアプリケーションごとに異なります。

  • 動的な PV プロビジョニングをサポートするストレージ技術は、マウント時のレイテンシーが低く、正常なクラスターをサポートするためにノードに関連付けられていません。
  • アプリケーション開発者はアプリケーションのストレージ要件や、それがどのように提供されているストレージと共に機能するかを理解し、アプリケーションのスケーリング時やストレージレイヤーと対話する際に問題が発生しないようにしておく必要があります。

5.3.2. 特定のアプリケーションおよびストレージの他の推奨事項

  • OpenShift Container Platform Internal etcd: etcd の信頼性を最も高く保つには、一貫してレイテンシーが最も低くなるストレージ技術が推奨されます。
  • データベース: データベース (RDBMS、NoSQL DB など) は、専用のブロックストレージで最適に機能する傾向にあります。

5.4. グラフドライバーの選択

コンテナーのランタイムは、イメージとコンテナーを DeviceMapper および OverlayFS などのグラフドライバー (プラグ可能なストレージ技術) に保存します。それぞれに長所と短所があります。

サポート内容や使用方法の注意点など、OverlayFS に関する詳しい情報は、『Red Hat Enterprise Linux (RHEL) 7 リリースノート』を参照してください。

表5.3 グラフドライバーの比較

名前説明利点制限

OverlayFS

  • overlay
  • overlay2

下層 (親) および上層 (子) のファイルシステムと作業ディレクトリー (子と同じファイルシステム) を組み合わせます。下層のファイルシステムはベースイメージで、新規コンテナーを作成すると、差分が含まれる新しい上層ファイルシステムが作成されます。

  • コンテナーの起動および終了時間はデバイスマッパーよりも短くなります。デバイスマッパーと Overlay の起動時間の違いは、1 秒未満です。
  • ページキャッシュの共有が可能です。

POSIX に準拠しません。

デバイスマッパーのシンプロビジョニング

LVM、デバイスマッパー、dm-thinp カーネルモジュールを使用します。ループバックデバイスを削除して、raw パーティション (ファイルシステムなし) に直接移動する点が異なります。

  • 中程度の負荷および高密度でパフォーマンス関連のいくつかの利点を測定できます。
  • 容量においてコンテナー別の制限があります (デフォルトは 10GB)。
  • 専用のパーティションが必要です。
  • Red Hat Enterprise Linux (RHEL) ではデフォルト設定されていません。
  • コンテナーおよびイメージはすべて、同じ容量のプールを共有します。プールを破棄または再作成せずにサイズを変更することはできません。

デバイスマッパー loop-lvm

デバイスマッパーのシンプロビジョニングモジュール (dm-thin-pool) を使用して、copy-on-write (CoW) スナップショットを実装します。デバイスマッパーグラフの場所ごとに、2 つのブロックデバイス (データとメタデータ用) をベースにシンプールが作成されます。デフォルトでは、これらのブロックデバイスは、自動作成されるスパースファイルのループバックマウントを使用して、自動的に作成されます。

カスタマイズなしですぐに使用できるので、プロトタイプ化や開発の目的で役立ちます。

  • Portable Operating System Interface for Unix (POSIX) がすべて機能する訳ではありません (例: O_DIRECT)。最も重要な点として、このモードは実稼働環境のワークロードには対応していません。
  • コンテナーおよびイメージはすべて、同じ容量のプールを共有します。プールを破棄または再作成せずにサイズを変更することはできません。

パフォーマンスを強化するために、デバイスマッパーよりも overlayFS ストレージドライバーを使用することが推奨されます。実稼働環境でデバイスマッパーをすでに使用している場合、コンテナーイメージおよびコンテナールートファイルシステムにシンプロビジョニングを使用することを推奨します。そうでない場合、Docker エンジンに overlayfs2 を使用するか、または CRI-O に overlayFS を使用します。

ループデバイスを使用すると、パフォーマンスに影響がある可能性があります。そのまま使用を継続できますが、以下の警告メッセージがログに記録されます。

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 ユーティリティーを使用して、設定の詳細の多くを自動化します。

Overlay の場合

  1. デバイスドライバーを指定するには、/etc/sysconfig/docker-storage-setup ファイルを編集します。

    STORAGE_DRIVER=overlay2
    注記

    CRI-O を使用している場合は、STORAGE_DRIVER=overlay を指定します。

    CRI-O の場合、デフォルトの overlay ストレージドライバーはoverlay2 の最適化を使用します。

    OverlayFS では、imagefs を異なる論理ボリュームに配置する必要がある場合、 CONTAINER_ROOT_LV_NAME および CONTAINER _ROOT_LV_MOUNT_PATH を設定する必要があります。 CONTAINER_ROOT_LV_MOUNT_PATH を設定するには、CONTAINER_ROOT_LV_NAME を設定する必要があります。たとえば、 CONTAINER_ROOT_LV_NAME="container-root-lv" のようになります。詳細は、「Using the Overlay Graph Driver」を参照してください。

  2. Docker ストレージ専用に別のディスクドライブがある場合 (例: /dev/xvdb) には、以下を /etc/sysconfig/docker-storage-setup ファイルに追加します。

    DEVS=/dev/xvdb
    VG=docker_vg
  3. docker-storage-setup サービスを再起動します。

    # systemctl restart docker-storage-setup
  4. Docker が overlay2 を使用していることを確認して、ディスク領域の使用状況をモニタリングするには、docker info コマンドを使用します。

    # docker info | egrep -i 'storage|pool|space|filesystem'

    出力例

    Storage Driver: overlay2 1
     Backing Filesystem: extfs

    1
    overlay2 を使用する場合の docker info 出力。

    Overlay は、Red Hat Enterprise Linux 7.2 の時点で、コンテナーランタイムのユースケースについてもサポートされ、起動時間の加速化、ページキャッシュ共有が可能になるため、全体的なメモリー使用率を下げて高密度化できる可能性があります。

シンプールの場合

  1. デバイスドライバーを指定するには、/etc/sysconfig/docker-storage-setup ファイルを編集します。

    STORAGE_DRIVER=devicemapper
  2. Docker ストレージ専用に別のディスクドライブがある場合 (例: /dev/xvdb) には、以下を /etc/sysconfig/docker-storage-setup ファイルに追加します。

    DEVS=/dev/xvdb
    VG=docker_vg
  3. 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 の出力には表示されません。

  4. Docker が LVM シンプールを使用していることを確認して、ディスク領域の使用状況をモニタリングするには、docker info コマンドを使用します。

    # docker info | egrep -i 'storage|pool|space|filesystem'

    出力例

    Storage Driver: devicemapper 1
     Pool Name: docker_vg-docker--pool 2
     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

    1
    devicemapper を使用する場合の docker info 出力。
    2
    /etc/sysconfig/docker-storage-setup で指定した VG に対応します。

デフォルトでは、シンプールは下層のブロックデバイスの 40% を使用するように設定されています。ストレージを使用していくにつれ、LVM は自動的にプールを最大 100% まで拡張します。Data Space Total の値が下層の LVM デバイスのフルサイズに一致しないのは、この理由によります。

開発において、Red Hat ディストリビューションの Docker はループバックマウントが実行されたスパースファイルにデフォルト設定されています。お使いのシステムでループバックモードを使用しているかどうかを確認するには、以下を実行します。

# docker info|grep loop0

出力例

 Data file: /dev/loop0

5.4.1. SELinux で OverlayFS または DeviceMapper を使用する利点

OverlayFS ファイルシステムの主な利点は、同じノードでイメージを共有するコンテナー間で Linux ページキャッシュが共有される点です。OverlayFS のこの特性により、コンテナーの起動時の出入力 (I/O) が減り (数百ミリ秒単位でコンテナーの起動時間が短縮)、同様のイメージがノードで実行されている場合にメモリーの使用率が減少します。これらはいずれも、(ビルドファームなど) コンテナーのチャーンレートを高め、密度を最適化する場合や、イメージの内容に重複が多い環境などの多くの環境で利点があります。

シンプロビジョニングのデバイスがコンテナーごとに割り当てられるので、DeviceMapper ではページキャッシュの共有はできません。

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 ドライバーを使用することが推奨されています