第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、メトリクス、ロギングなどのイメージは特に、接続速度が遅いことが原因でパフォーマンスが低下することなく、時間を節約できます。
また、この方法はセキュリティー上の理由でレジストリーにアクセスできないマシンにも役立ちます。
または、指定したデフォルトレジストリーではなく、ローカルイメージを使用できます。このためには、以下を実行します。
-
Pod 設定の
imagePullPolicyパラメーターをIfNotPresentまたはNeverに設定して、ローカルイメージからプルします。 - クラスターのすべてのノードで、同じイメージがローカルに保存されていることを確認します。
ノードの設定を制御できる場合は、ローカルレジストリーからプルすることが適切ですが、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 ベースのヘルスチェック」を参照してください。
