スケーリングおよびパフォーマンスガイド

ノードホストは、ネットワークにアクセスして、atomic-openshift-*, iptables、および CRI-O または Docker などの RPM 依存関係をインストールします。これらの依存関係を事前にインストールすると、インストール中にホストごとに何度もアクセスするのではなく、必要な時にしか RPM にアクセスしないので、より効率的にインストールができます。

また、セキュリティー上の理由でレジストリーにアクセスできないマシンにも有用です。

OpenShift Container Platform のインストール手法では Ansible を使用します。Ansible は並行して実行する操作に役立ち、迅速かつ効率的なインストールを促進します。ただし、これらの操作はチューニングオプションを追加してさらに強化することができます。利用可能な Ansible 設定オプションの一覧については、Ansible の設定セクション を参照してください。

レイテンシーを最小限に抑えたコントロールノード (LAN 速度) からインストーラーを実行します。ワイドエリアネットワーク (WAN) での実行や、ネットワーク接続が途切れる可能性のある環境でのインストールの実行は推奨しません。

Ansible では、RHEL 6.6 以降を使用して OpenSSH のバージョンが ControlPersist をサポートすることを確認することや、クラスター内のマシンから 実行せずに、クラスターと同じ LAN からインストーラーが実行されるようにするなどの、独自のパフォーマンスやスケーリングに関する指針が提供されます。

以下は、Ansible がまとめた推奨事項を組み込んだ、大規模なクラスターのインストールや管理を行うための Ansible の設定例です。

# cat /etc/ansible/ansible.cfg

# config file for ansible -- http://ansible.com/
# ==============================================
[defaults]
forks = 20 1
host_key_checking = False
remote_user = root
roles_path = roles/
gathering = smart
fact_caching = jsonfile
fact_caching_connection = $HOME/ansible/facts
fact_caching_timeout = 600
log_path = $HOME/ansible.log
nocows = 1
callback_whitelist = profile_tasks

[privilege_escalation]
become = False

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=600s -o ServerAliveInterval=60
control_path = %(directory)s/%%h-%%r
pipelining = True 2
timeout = 10

ネットワークサブネットの変更はインストール後に実行できますが、これを容易に実行することはできません。サイズを少なく見積もってしまうとクラスターを拡張する際に問題が発生する可能性があるので、ネットワークサブネットのサイズをインストール前に検討することにより作業を大幅に容易にすることができます。

ネットワークサブネットに関する推奨プラクティスは、ネットワークの最適化 のトピックを参照してください。

OpenShift Container Platform インフラストラクチャーで、Pod トラフィックの他に最も使用されるデータパスは OpenShift Container Platform マスターホストと etcd 間のデータパスです。OpenShift Container Platform API サーバー (マスターバイナリーの一部) は、ノードのステータス、ネットワーク設定、シークレットなどについて etcd に確認します。

以下を実行してこのトラフィックパスを最適化します。

OpenShift Container Platform マスターは、CPU 負荷を軽減するためにデシリアライズされたバージョンのリソースを積極的にキャッシュします。ただし、1000 Pod 未満の小規模なクラスターでは、このキャッシュにより、無視できる程度の CPU 負荷を削減するために大量のメモリーが浪費される可能性があります。デフォルトのキャッシュサイズは 50,000 エントリーですが、リソースのサイズによっては 1 から 2 GB メモリーを占有する程度まで拡大する可能性があります。キャッシュのサイズは、/etc/origin/master/master-config.yaml で以下の設定を使用して縮小できます。

kubernetesMasterConfig:
  apiServerArguments:
    deserialization-cache-size:
    - "1000"

API サーバーに送信されるクライアント要求または API 呼び出しの数は、1 秒あたりクエリー (QPS: Queries Per Second) の値によって決まり、API サーバーで処理できる同時要求の数は、maxRequestsInFlight 設定によって決まります。クライアントが QPS レートを超えることのできる要求の数は、バースト値によって異なります。これは、バースト性があり、不規則な数の要求を実行できるアプリケーションに役立ちます。とくに大容量または高密度のクラスターなど、API サーバーが処理するる同時要求が多数ある場合は、要求の応答時間のレイテンシーが長くなる可能性があります。Prometheus の apiserver_request_count レートメトリクスを監視し、maxRequestsInFlight と QPS を適宜調整することが推奨されます。

API サーバーの CPU およびメモリーの消費としてデフォルト値を変更すると、適切なバランスが必要となります。また、追加の要求を並行して処理する際に etcd IOPS が増えます。また、監視されていない要求が多くなると、60 秒の固定タイムアウトの後にキャンセルされ、クライアントが再試行を開始するため、API サーバーに過負荷がかかる可能性がある点に注意してください。

API サーバーシステムで十分な CPU およびメモリーリソースが利用できることを前提とすると、API サーバー要求のオーバーロードする問題は、上記の要素を考慮し、 *_/etc/origin/master/master-config.yaml で maxRequestsInFlight、API qps およびバースト値を引き上げることによって安全に軽減することができます。

masterClients:
  openshiftLoopbackClientConnectionOverrides:
    burst: 600
    qps: 300
servingInfo:
  maxRequestsInFlight: 500

OpenShift Container Platform ノード設定ファイルには、iptables 同期期間、SDN ネットワークの Maximum Transmission Unit (MTU)、プロキシーモードなどの重要なオプションが含まれます。ノードを設定するには、適切な ノード設定マップ を変更します。

ノード設定ファイルでは、kubelet (node) プロセスに引数を渡すことができます。kubelet --help を実行すると、利用可能なオプション一覧を表示できます。

/etc/origin/node/node-config.yaml ファイルでは、1 つのパラメーターでノードにスケジュールできる Pod の最大数 max-pods を制御します。max-pods オプションを使用すると、ノード上の Pod の数が制限されます。この値を超えると、次の結果になる可能性があります。

max-pods は、ノードのプロパティーにかかわらず、ノードが実行できる Pod 数を固定値に設定します。クラスターの制限 では、max-pods のサポートされる最大値について説明しています。

kubeletArguments:
  max-pods:
    - "250"

上記の例を使用すると、max-pods のデフォルト値は 250 です。

OpenShift Container Platform クラスターの推奨制限については、インストールドキュメントの サイジングに関する考慮事項 セクションを参照してください。推奨のサイズは、コンテナーのステータス更新時の OpenShift Container Platform とコンテナーエンジンの連携に対応します。この連携により、大量のログデータの書き込みなどを含め、マスターやコンテナーエンジンプロセスへの CPU の負荷がかかります。

kubelet が API サーバーと通信する速度は、qps およびバースト値によって異なります。各ノードで実行中の Pod に限りがある場合には、デフォルト値で十分です。ノードに CPU およびメモリーリソースが十分にある場合、qps および burst の値は /etc/origin/node/node-config.yaml ファイルで調整できます。

kubeletArguments:
  kube-api-qps:
  - "20"
  kube-api-burst:
  - "40"

etcd は、OpenShift Container Platform が設定に使用するキーと値の分散ストアです。

etcd 3.x では、クラスターのサイズに拘わらず、CPU、メモリー、ネットワーク、ディスク要件を軽減する、スケーラビリティーおよびパフォーマンスの重要な強化機能が導入されました。また、etcd 3.x は、オンディスク etcd データベースの 2 段階移行をスムーズに行うため、後方互換のあるストレージ API を実装します。移行の目的で、OpenShift Container Platform 3.5 の etcd 3.x で使用されるストレージモードは v2 モードのままとなっています。OpenShift Container Platform 3.6 の時点で、新規インストールで v3 のストレージモードが使用されます。OpenShift Container Platform の以前のバージョンからアップグレードしても、v2 から v3 に自動で 移行されません。提供されている Playbook を使用して、ドキュメントに記載のプロセスに従い、データを移行する必要があります。

etcd のバージョン 3 では、on-disk etcd データベースの 2 ステップ移行を簡素化する後方互換性対応のストレージ API を実装します。移行の目的で、OpenShift Container Platform 3.5 の etcd 3.x で使用されるストレージモードは v2 モードのままとなっています。OpenShift Container Platform 3.6 の時点で、新規インストールで v3 のストレージモードが使用されます。OpenShift Container Platform 3.7 へのアップグレードプロセスの一環として、必要な場合は etcd ストレージ API を v3 にアップグレードします。バージョン 3.7 以降では、v3 API を使用する必要があります。

新規インストールでストレージモードを v3 に変更するのに加え、OpenShift Container Platform 3.6 は、全 OpenShift Container Platform タイプに対して強制的に quorum reads を実行します。これは、etcd に対するクエリーが古くなったデータを返さないようにするために実行されます。単一ノードの etcd クラスターでは、古くなったデータが入っていても懸念はありません。実稼働クラスターで一般的に使用される高可用性の etcd デプロイメントでは、quorum read はクエリーの結果が有効になるようにします。quorum read は、データベース用語で 線形化可能性 のことで、すべてのクライアントにクラスターが最新の状態に更新されたものが表示され、同じ順番の読み取りおよび書き込みが表示されます。パフォーマンスの向上に関する情報は、etcd 3.1 の announcement を参照してください。

OpenShift Container Platform は、etcd を使用して Kubernetes 自体が必要な情報以外の追加情報を保存する点を留意することが重要です。たとえば、Kubernetes 以外に OpenShift Container Platform が追加する機能で必要になるので、OpenShift Container Platform は、etcd にあるイメージ、ビルド、他のコンポーネントの情報を保存します。最終的に、etcd ホストのパフォーマンスやサイジングに関する指針やその他の推奨事項は、Kubernetes とは顕著に異なります。Red Hat は最も正確な推奨事項を提案できるように、OpenShift Container Platform のユースケースやパラメーターを念頭において、etcd のスケーラビリティーやパフォーマンスをテストしています。

パフォーマンスの向上は、cluster-loader ユーティリティーで 300 ノードの OpenShift Container Platform 3.6 クラスターを使用して、定量化されています。etcd 3.x (ストレージモード v2) と etcd 3.x (ストレージモード v3) を比較すると、以下の図に示されるようにパフォーマンスの向上が明確に確認できます。

負荷のある状態でのストレージ IOPS が大幅に減少している:

安定した状態でのストレージ IOPS が大幅に減少している:

同じ I/O データの表示。 両モードでの平均 IOPS

API サーバー (マスター) と etcd プロセス両方の CPU 使用率が減少している:

API サーバー (マスター) と etcd プロセスの両方のメモリー使用率も減少している:

etcd 3.1 の 3 ノードクラスター (quorum reads を強制実行してストレージ v3 モードを使用) で実行したサイズ I/O 操作を確認してみると、読み取りサイズは以下のようになります。

また、書き込みサイズは以下のようになります。

Tuned は、Red Hat Enterprise Linux (RHEL) および他の Red Hat 製品で有効な Tuning プロファイルの配信メカニズムです。Tuned は、sysctls、電源管理、カーネルコマンドラインオプションなどの Linux の設定をカスタマイズして、異なるワークロードのパフォーマンスやスケーラビリティーの要件に対応するために、オペレーティングシステムを最適化します。

OpenShift Container Platform は tuned デーモンを活用して、openshift, openshift-node and openshift-control-plane と呼ばれる Tuned プロファイルを追加します。これらのプロファイルは、カーネルで一般的に発生する垂直スケーリングの上限を安全に増やし、インストール時に自動的にシステムに適用します。

Tuned プロファイルは、プロファイル間の継承をサポートします。また、プロファイルが仮想環境で使用されるかどうかにより、親プロファイルを選択する親の自動割り当て機能もサポートします。openshift プロファイルは openshift-node および openshift-control-plane プロファイルの親で、両機能を使用します。これには、それぞれ OpenShift Container Platform アプリケーションノードとコントロールプレーンノードの両方に関連するチューニングが含まれます。openshift-node および openshift-control-plane プロファイルは、アプリケーションおよびコントロールプレーンノードにそれぞれ設定されます。

openshift プロファイルがプロファイル階層の親である場合に、OpenShift Container Platform システムに配信されるチューニングは、ベアメタルホスト向けの throughput-performance (RHEL のデフォルト) と、RHEL 向けの virtual-guest または RHEL Atomic Host ノード向けの atomic-guest を組み合わせて作成されます。

お使いのシステムでどの Tuned プロファイルが有効になっているかを確認するには以下を実行します。

# tuned-adm active

Current active profile: openshift-node

Tuned に関する詳細情報は、Red Hat Enterprise Linux パフォーマンスチューニングガイドを参照してください。

CPU およびメモリーなどのリソースを必要とするクラスターの部分から、このようなリソースにアクセスしやすくなるように、オーバーコミットの手順を使用します。

オーバーコミットすると、別のアプリケーションが必要としているリソースを必要な時にアクセスできなくなってしまうリスクがあり、結果的にパフォーマンスが低下しますが、パフォーマンスが低下する代わりに、密度が高まり、コストが削減されるので、代償として妥当な範囲である場合もあります。ただし、パフォーマンスが低下する代わりに、密度が高まり、コストが削減されるので、許容できるトレードオフになる場合もあります。たとえば、開発、品質保証 (QA) またはテスト環境でオーバーコミットできても、実稼働環境ではできない場合があります。

OpenShift Container Platform は、コンピュートリソースモデルやクォータシステムでリソース管理を実装します。詳細は、OpenShift リソースモデル を参照してください。

オーバーコミットに関する詳細情報およびストラテジーは、クラスター管理ガイドのオーバーコミット を参照してください。

Red Hat は rhel-tools コンテナーイメージを配信します。これは、スケーリングがパフォーマンスの問題のデバッグをサポートするパッケージツールです。 このコンテナーイメージを使用すると、以下が可能です。

以下を実行して rhel-tools コンテナーを使用します。

# atomic run rhel7/rhel-tools

詳しい情報は、RHEL ツールコンテナーのドキュメント を参照してください。

追加のヘルスチェックは、OpenShift Container Platform クラスターのインストールおよび管理に使用する Ansible ベースのツール で利用できます。この正常性チェックでは、現行の OpenShift Container Platform インストールによくあるデプロイメントの問題を報告できます。

これらのチェックは、ansible-playbook コマンドの使用 (クラスターインストール で使用されるのと同じ方式) によるか、または openshift-ansible の コンテナー化されたバージョン として実行できます。ansible-playbook 方式については、チェックは openshift-ansible RPM パッケージを使って行われます。コンテナー化方式の場合は、openshift3/ose-ansible コンテナーイメージが Red Hat Container レジストリー 経由で配布されます。

利用可能な正常性チェックや使用例については、クラスター管理ガイドの Ansible ベースの正常性チェック を参照してください。

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

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

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

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

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

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

パフォーマンスを強化するために、デバイスマッパーよりも 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 の場合

Thinpool の場合

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

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

# docker info|grep loop0

 Data file: /dev/loop0

Pod は、一時ファイルの保存などの内部操作に一時ストレージを使用します。この一時ストレージは、個別の Pod の寿命より長くなることはなく、一時ストレージは Pod 間で共有することはできません。

OpenShift Container Platform 3.10 よりも前のバージョンでは、一時ローカルストレージは、コンテナーの書き込み可能な階層、logs ディレクトリー、EmptyDir ボリュームを使用して Pod に公開されていました。ローカルストレージのアカウントや分離がないことに関連する問題には、以下が含まれます。

一時ストレージは同様に Pod に公開されていますが、Pod の一時ストレージの使用に対する要求や制限を実装する新たな方法が追加されています。

一時ストレージはシステム内の Pod すべてで共有され、OpenShift Container Platform には管理者およびユーザーが確立した要求や制限を超えるサービスを保証する仕組みはない点を理解することが重要です。たとえば、一時ストレージでは、スループット、秒ごとの I/O 操作またはストレージパフォーマンスについての保証は一切ありません。

ノードのローカルストレージは、プライマリーパーティションとセカンダリーパーティションに分割できます。一時ローカルストレージには、プライマリーパーティションのみが使用できます。プライマリーパーティションでは、root とランタイムの 2 つがサポートされています。

OpenShift SDN は OpenvSwitch、VXLAN (Virtual extensible LAN) トンネル、OpenFlow ルール、iptables を使用します。このネットワークは、ジャンボフレーム、ネットワークインターフェイスカード (NIC) のオフロード、マルチキュー、ethtool の設定を使用してチューニングが可能です。

VXLAN は、4096 から 1600 万以上にネットワーク数が増え、物理ネットワーク全体で階層 2 の接続が追加されるなど、VLAN での利点が提供されます。これにより、異なるシステム上で実行されている場合でも、サービスの背後にある Pod すべてが相互に通信できるようになります。

VXLAN は、User Datagram Protocol (UDP) パケットにトンネル化されたトラフィックをすべてカプセル化しますが、CPU 使用率が上昇してしまいます。これらの外部および内部パケットは、移動中にデータが破損しないようにするために通常のチェックサムルールの対象になります。これらの外部および内部パケットはどちらも、移動中にデータが破損しないように通常のチェックサムルールの対象になります。CPU のパフォーマンスによっては、この追加の処理オーバーヘッドによってスループットが減り、従来の非オーバーレイネットワークと比較してレイテンシーが高くなります。

クラウド、仮想マシン、ベアメタルの CPU パフォーマンスでは、1 Gbps をはるかに超えるネットワークスループットを処理できます。10 または 40 Gbps などの高い帯域幅のリンクを使用する場合には、パフォーマンスが低減する場合があります。これは、VXLAN ベースの環境では既知の問題で、コンテナーや OpenShift Container Platform 固有の問題ではありません。VXLAN トンネルに依存するネットワークも、VXLAN 実装により同様のパフォーマンスになります。

1 Gbps 以上にするには、以下を実行してください。

VXLAN オフロードはレイテンシーを短縮しません。ただし、CPU の使用率はレイテンシーテストでも削減されます。

networkConfig:
  mtu: 1450 1
  networkPluginName: "redhat/openshift-ovs-subnet" 2

OpenShift Container Platform は、Pod とサービスに対して IP アドレス管理を提供します。デフォルト値の許容範囲は以下のとおりです。

多くの状況下で、デプロイメント後にはこれらのネットワークの変更はできません。そのため、拡張関連のプランニングをすることが重要です。

ネットワークのリサイズに関する制限は、SDN の設定ドキュメント に記載されています。

より大規模な環境を計画する場合は、Ansible インベントリーファイルの [OSE3:vars] セクションに以下の推奨値を設定するようにしてください。

[OSE3:vars]
osm_cluster_network_cidr=10.128.0.0/10

これにより、使用可能な IP アドレス 510 個が割り当てられる 8192 ノードが許可されます。

インストールしているソフトウェアバージョンのノード/Pod の上限については、OpenShift Container Platform ドキュメントにあるサポートの制限について参照してください。

ノードホストの暗号化、復号化に CPU 機能が使用されるので、使用する IP セキュリティーシステムにかかわらず、ノードのスループットおよび CPU 使用率の両方でのパフォーマンスに影響があります。

IPSec は、NIC に到達する前に IP ペイロードレベルでトラフィックを暗号化して、NIC オフロードに使用されてしまう可能性のあるフィールドを保護します。つまり、IPSec が有効な場合には、NIC アクセラレーション機能を使用できない場合があり、スループットの減少、CPU 使用率の上昇につながります。

OpenShift Container Platform は、Heapster で収集してバックエンドに保存可能なメトリクスを公開します。OpenShift Container Platform の管理者は、1 つのユーザーインターフェイスでコンテナーやコンポーネントメトリクスを表示できます。これらのメトリクスは、Horizontal Pod Autoscaler によるスケーリングのタイミングと方法の決定にも使用されます。

以下のトピックでは、メトリクスコンポーネントのスケーリングに関する情報に触れます。

OpenShift Container Platform ノードが 210 台と 990 台で実行したテストでは、それぞれ Pod が 10500 台と 11000 台をモニターリングし、Cassandra データベースのサイズが、以下の表に記載の速度で増加しました。

上記の計算では、ストレージ要件が計算値を超過しないようにするためのオーバーヘッドとして、予期されたサイズのおよそ 20% が追加されています。

METRICS_DURATION および METRICS_RESOLUTION の値がデフォルト (それぞれ 7 日と 15 秒) のままの場合は、上記の値にあるように、安全策として週ごとの Cassandra ストレージのサイズ要件を計画することができます。

メトリクス Pod (Cassandra/Hawkular/Heapster) 1 セットでは、最低 25,000 の Pod をモニターリングできます。

# oc scale -n openshift-infra --replicas=2 rc hawkular-metrics

OpenShift Container Platform は、cluster-monitoring-operator によってバックエンドで収集し、保存できるメトリクスを公開します。OpenShift Container Platform 管理者は、Grafana という 1 つのダッシュボードインターフェイスでシステムリソース、コンテナーおよびコンポーネントのメトリクスを表示できます。

以下のトピックでは、cluster monitoring operator のスケーリングについての情報を提供します。

Prometheus を永続ストレージで使用する場合は、Ansible インベントリーファイルの openshift_cluster_monitoring_operator_prometheus_storage_enabled 変数を true に設定する必要があります。

異なるスケールサイズについて各種のテストが実行されました。以下の表が示すように、Prometheus データベースが拡張されました。

上記の計算では、ストレージ要件が計算値を超過しないようにするために、オーバーヘッドとして予期されたサイズのおよそ 20% が追加されています。

上記の計算は、デフォルトの OpenShift Container Platform cluster-monitoring-operator について開発されました。スケールが拡張する場合、Ansible インベントリーファイルで、デフォルトが 50Gi に設定されている openshift_cluster_monitoring_operator_prometheus_storage_capacity=94Gi 変数を編集します。

195 GB (space per 15 days ) * 2 (pods) = 390 GB free

サービスプロバイダーとしてのインフラストラクチャー: OpenStack

環境の計画時 に、ノード配置できる Pod 数を判断します。

Maximum Pods per Cluster / Expected Pods per Node = Total Number of Nodes

ノードで適合する Pod 数は、アプリケーション自体により異なります。アプリケーションのメモリー、CPU、ストレージ要件を検討してください。

2200 / 250 = 8.8

ノード数を 20 に増やす場合は、Pod 配分がノードごとに 110 の Pod に変わります。

2200 / 20 = 110

アプリケーション環境の例を考えてみましょう。

推定要件: CPU コア 550 個、メモリー 450GB およびストレージ 1.4TB

ノードのインスタンスサイズは、希望に応じて増減を調整できます。ノードのリソースはオーバーコミットされることが多く、デプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。このデプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。運用上の敏捷性やインスタンスごとのコストなどの要因を考慮する必要があります。

アプリケーションによっては オーバーコミット の環境に適しているものもあれば、そうでないものもあります。たとえば、Java アプリケーションや、大きいページを使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境は一般的な比率として約 30 % オーバーコミットされています。

クラスターローダーとは、クラスターに対してさまざまなオブジェクトを多数デプロイするツールであり、ユーザー定義のクラスターオブジェクトを作成します。クラスターローダーをビルド、設定、実行して、さまざまなクラスターの状態にある OpenShift Container Platform デプロイメントのパフォーマンスメトリクスを測定します。

クラスターローダーは atomic-openshift-tests パッケージに含まれます。これをインストールするには、以下を実行します。

$ yum install atomic-openshift-tests

インストールが終わると、テスト用の実行ファイル extended.test は /usr/libexec/atomic-openshift/extended.test に配置されます。

複数のテンプレートや Pod を含む、namespaces (プロジェクト) を複数作成します。

クラスターローダーの設定ファイルを config/ サブディレクトリーに配置します。これらの設定ファイルで参照される Pod ファイルとテンプレートファイルは、content/ サブディレクトリーにあります。

provider: local 1
ClusterLoader:
  cleanup: true
  projects:
    - num: 1
      basename: clusterloader-cakephp-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/cakephp-mysql.json

    - num: 1
      basename: clusterloader-dancer-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/dancer-mysql.json

    - num: 1
      basename: clusterloader-django-postgresql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/django-postgresql.json

    - num: 1
      basename: clusterloader-nodejs-mongodb
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/nodejs-mongodb.json

    - num: 1
      basename: clusterloader-rails-postgresql
      tuning: default
      templates:
        - num: 1
          file: ./examples/quickstarts/rails-postgresql.json

  tuningsets: 2
    - name: default
      pods:
        stepping: 3
          stepsize: 5
          pause: 0 s
        rate_limit: 4
          delay: 0 ms

IDENTIFIER パラメーターがユーザーテンプレートで定義されていない場合には、テンプレートの作成は error: unknown parameter name "IDENTIFIER" エラーを出して失敗します。テンプレートをデプロイする場合は、このエラーが発生しないように、以下のパラメーターをテンプレートに追加してください。

{
  "name": "IDENTIFIER",
  "description": "Number to append to the name of resources",
  "value": "1"
}

Pod をデプロイする場合は、このパラメーターを追加する必要はありません。

CPU マネージャーは、CPU グループを管理して、ワークロードを特定の CPU に制限します。

CPU マネージャーは、以下のような属性が含まれるワークロードに有用です。

CPU マネージャーを設定するには、以下を実行します。

メモリーは Page と呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 262,144 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。そうでない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズは固定されているので、TLB ミスの発生率を減らすには Page サイズを大きくする必要があります。

Huge Page とは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的な Huge Page サイズです。別のアーキテクチャーではサイズは異なります。Huge Page を使用するには、アプリケーションが認識できるようにコードを書き込む必要があります。Transparent Huge Pages (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。

OpenShift Container Platform では、Pod のアプリケーションが事前に割り当てられた Huge Page を割り当て、消費することができます。以下のトピックでは、その方法について説明します。

Huge Page は、リソース名の hugepages-<size> を使用してコンテナーレベルのリソース要件で消費可能です。この場合、サイズは特定のノードでサポートされる整数値を使用した最もコンパクトなバイナリー表記です。たとえば、ノードが 2048KiB ページサイズをサポートする場合、これはスケジュール可能なリソース hugepages-2Mi を公開します。CPU やメモリーとは異なり、Huge Page はオーバーコミットをサポートしません。

kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

プラットフォームによっては、複数の Huge Page サイズをサポートするものもあります。特定のサイズの Huge Page を割り当てるには、Huge Page の起動コマンドパラメーターの前に、Huge Page サイズの選択パラメーター hugepagesz=<size> を指定してください。<size> の値は、バイトで指定する必要があります。その際、オプションでスケール接尾辞 [kKmMgG] を指定できます。デフォルトの Huge Page サイズは、default_hugepagesz=<size> の起動パラメーターで定義できます。詳細は、Huge Page および Transparent Huge Pages を参照してください。

Huge Page 要求は制限と同じでなければなりません。制限が指定されているにもかかわらず、要求が指定されていない場合には、これがデフォルトになります。

Huge Page は、Pod のスコープで分割されます。コンテナーの分割は、今後のバージョンで予定されています。

Huge Page がサポートする EmptyDir ボリュームは、Pod 要求よりも多くの Huge Page メモリーを消費することはできません。

shmget() で SHM_HUGETLB を使用して Huge Page を消費するアプリケーションは、proc/sys/vm/hugetlb_shm_group に一致する補助グループで実行する必要があります。

アプリケーションにコンバージドモードを使用する場合には、お使いのワークロードの種類によって、gluster-block と GlusterFS モードを使い分けられるように、このトピックで説明されているガイドとベストプラクティスに従うようにしてください。

OpenShift Container Platform 3.10 では、これらの SQL データベースを使用する場合および使用しない場合に関連して広範なテストが行われました。

これらのデータベースのストレージは、コンバージドモードのストレージクラスターから取得しています。

Postgresql SQL ベンチマークについては、pgbench がデータベースのベンチマークに使用されていました。MongoDB の場合は、noSQL ベンチマーク YCSB Yahoo!Cloud Serving Benchmark ベンチマークに使用され 、workloada、workloadb、workloadf がテストされました

上述のように GlusterFS のパフォーマンス変換は、コンバージドモードの最新イメージで提供されるデータベースプロファイルにすでに含まれています。

Postgresql SQL データベースの場合は、GlusterFS と gluster-block のパフォーマンスはほぼ同じ結果となりました。MongoDB noSQL データベースの場合は、gluster-block のパフォーマンスのほうが優れています。したがって、MongoDB noSQL データベースには、gluster-block ベースのストレージを使用します。