Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第4章 コンピュートリソースの最適化

4.1. オーバーコミット

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

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

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

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

4.2. イメージの留意事項

4.2.1. 事前デプロイ済みのイメージを使用した効率の強化

効率の強化や全ノードホストでの設定の一貫性の維持、反復タスクの削減を図るため、複数のタスクを組み込んだベースの OpenShift Container Platform イメージを作成できます。これは、事前デプロイ済みのイメージとして知られています。

たとえば、Pod を実行するために、すべてのノードには ose-pod イメージが必要なので、各ノードは定期的に Docker レジストリーに接続して最新のイメージをプルする必要があります。100 のノードが同時にレジストリーに接続し、最新のイメージをプルしようとすると問題が発生する場合があり、イメージレジストリーでのリソースの競合や、ネットワーク帯域幅の無駄な使用、および Pod の起動にかかる時間の増加などが生じる可能性があります。

事前にデプロイ済みのイメージをビルドするには、以下を実行します。

  • 必要とされるタイプおよびサイズのインスタンスを作成します。
  • コンテナー用の永続ボリュームとは別に、専用のストレージデバイスが Docker のローカルイメージやコンテナーストレージで利用できるようにします。
  • システムを完全に更新すると共に、Docker がインストールされていることを確認します。
  • ホストがすべての yum リポジトリーにアクセスできるようにします。
  • シンプロビジョニングされた LVM ストレージを設定します。
  • 一般的に使用するイメージ (rhel7 ベースイメージ) および OpenShift Container Platform インフラストラクチャーコンテナーイメージ (ose-pod、ose-deployer など) を事前にデプロイ済みのイメージに事前に設定します。

OpenStack または AWS で実行できるなど、事前デプロイ済みのイメージに対して、適切なクラスター設定やその他のクラスター設定が済んでいるようにします。

4.2.2. イメージの事前プル

イメージを効率的に生成するには、全ノードホストに、必要とされるコンテナーイメージをすべて事前にプルしておきます。最初にイメージをプルする必要がないので、サイズが大きくなる可能性のある S2I、メトリクス、ロギングなどのイメージは特に、接続速度が遅いことが原因でパフォーマンスが低下することなく、時間を節約できます。

また、この方法はセキュリティー上の理由でレジストリーにアクセスできないマシンにも役立ちます。

または、指定したデフォルトレジストリーではなく、ローカルイメージを使用できます。このためには、以下を実行します。

  1. Pod 設定の imagePullPolicy パラメーターを IfNotPresent または Never に設定して、ローカルイメージからプルします。
  2. クラスターのすべてのノードで、同じイメージがローカルに保存されていることを確認します。
注記

ノードの設定を制御できる場合は、ローカルレジストリーからプルすることが適切ですが、GCE など、自動的にノードを交換しないクラウドプロバイダーでは確実に機能しない場合があります。Google Container Engine (GKE) で実行している場合は、各ノードに、Google Container Registry の認証情報が設定された .dockercfg ファイルが配置されています。

4.3. RHEL ツールのコンテナーイメージを使用したデバッグ

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

  • ベースのディストリビューションからこのサポートコンテナーにパッケージを移動して、フットプリントが最小のコンテナーホストをデプロイできます。
  • 不変のパッケージツリーを含む Red Hat Enterprise Linux 7 Atomic Host 用のデバッグ機能が提供されます。rhel-tools には、tcpdump、sosreport、git、gdb、perf など、多くの一般的なシステム管理ユーティリティーが含まれます。

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

# atomic run rhel7/rhel-tools

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

4.4. Ansible ベースのヘルスチェックを使用したデバッグ

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

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

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