Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

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

5.1. 概要

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

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

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

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

ストレージタイプ説明例

ブロック

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

CNS/CRS GlusterFS [a] iSCSI、Fibre Channel、Ceph RBD、OpenStack Cinder、AWS EBS [a]、Dell/EMC Scale.IO、VMware vSphere Volume、GCE 永続ディスク[a]、Azure Disk

ファイル

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

CNS/CRS GlusterFS [a]、RHEL NFS、NetApp NFS [b]、Azure File、Vendor NFS、Vendor GlusterFS [c]、Azure File、AWS EFS

オブジェクト

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

CNS/CRS 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] CNS/CRS 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 のサポート機能および設定機能は異なる場合があります。
CNS/CRS GlusterFS、Ceph RBD、OpenStack Cinder、AWS EBS、Azure Disk、GCE 永続ディスク、および VMware vSphere は、OpenShift Container Platform で永続ボリューム (PV) のネイティブプロビジョニングをサポートします。
NetApp NFS は Trident を使用する場合に動的 PV のプロビジョニングをサポートします。
Vendor GlusterFS、Vendor S3 および Vendor Swift のサポート機能および設定機能は異なる場合があります。
注記

OpenShift Container Platform 3.6.1 では、Container-Native Storage (CNS) GlusterFS (ハイパーコンバージドまたはクラスターホストのストレージソリューション) および Container-Ready Storage (CRS) GlusterFS (外部ホストのストレージソリューション) により、OpenShift Container Platform レジストリー、ロギング、計測の目的で、ブロック、ファイル、オブジェクトストレージにインターフェースが提供されます。

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

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

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

ストレージタイプROX <1>RWX <2>レジストリースケーリングされたレジストリーメトリクスロギングアプリ

ブロック

はい <3>

いいえ

設定可能

設定不可

推奨

推奨

推奨

ファイル

はい <3>

はい

設定可能

設定可能

設定可能

設定可能

推奨

オブジェクト

はい

はい

推奨

推奨

設定不可

設定不可

設定不可 <4>

ReadOnlyMany
ReadWriteMany
これは、物理ディスク、VM 物理ディスク、VMDK、NFS 経由のループバック、AWS EBS および Azure Disk には該当しません。
オブジェクトストレージは、OpenShift Container Platform の PV/永続ボリューム要求 (PVC: Persistent Volume Claim) で消費されません。アプリは、オブジェクトストレージの REST API と統合する必要があります。
注記

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

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

5.2.1.1.1. レジストリー

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

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

実稼働環境のワークロードを処理する OpenShift Container Platform レジストリーを、NFS を使用してバックアップすると、データが破損してしまう可能性があります。

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

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

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

実稼働環境のワークロードを処理する OpenShift Container Platform のスケーリングあり/高可用性レジストリーを、NFS を使用してバックアップすると、データが破損してしまう可能性があります。

5.2.1.1.3. メトリクス

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

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

実稼働環境のワークロードを処理するホスト型のメトリクスを、NFS を使用してバックアップすると、データが破損してしまう可能性があります。

5.2.1.1.4. ロギング

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

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

実稼働環境のワークロードを処理するホスト型のロギングを、NFS を使用してバックアップすると、データが破損してしまう可能性があります。

5.2.1.1.5. アプリケーション

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

  • 動的な PV プロビジョニングをサポートするストレージ技術は、マウント時のレイテンシーが低く、ノードに関連付けられておらず、正常なクラスターをサポートします。
  • NFS はリードアフターライト (Read-After-Write) の一貫性を確保しないので、一貫性を確保する必要のあるアプリケーションには推奨していません。
  • 同じ共有 NFS エクスポートに書き込みをする必要のあるアプリケーションは、実稼働環境のワークロードがかかると問題が発生する可能性があります。

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

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

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

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

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

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

名前説明利点制限

デバイスマッパー loop-lvm

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

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

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

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

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

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

OverlayFS

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

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

POSIX に準拠しません。

サポート内容や使用方法の注意点など、Overlay に関する詳しい情報は、『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 ユーティリティーを使用して、設定の詳細の多くを自動化します。

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

    DEVS=/dev/xvdb
VG=docker_vg

  2. 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 の出力には表示されません。

  3. 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.3.1. SELinux で Overlay グラフドライバーを使用する利点

Red Hat Enterprise Linux の Docker ストレージのデフォルト設定は DeviceMapper のままです。コンテナーのストレージ技術としての Overlay の使用は評価中ですが、今後のリリースで Red Hat Enterprise Linux でのデフォルト設定を Overlay に変更することを検討中です。Red Hat Enterprise Linux 7.2 で、グラフドライバーとして Overlay はサポートされるようになり、Red Hat Enterprise Linux 7.4 で、SELinux と Overlay2 グラフドライバーの組み合わせもサポートされるようになりました。

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

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