Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第9章 クラスターメトリクスのスケーリング
9.1. 概要
OpenShift Container Platform は、Heapster で収集してバックエンドに保存可能なメトリクスを公開します。OpenShift Container Platform の管理者は、1 つのユーザーインターフェースでコンテナーやコンポーネントメトリクスを表示できます。これらのメトリクスは、スケーリングのタイミングと方法を判断するために、Horizontal Pod Autoscaler でも使用されます。
以下のトピックでは、メトリクスコンポーネントのスケーリングに関する情報を提供します。
Hawkular および Heapster などのメトリクスコンポーネントの自動スケーリングは OpenShift Container Platform ではサポートされていません。
9.2. OpenShift Container Platform の推奨事項
- 専用の OpenShift Container Platform インフラストラクチャーノード でメトリクス Pod を実行する
-
メトリクスの設定時は永続ストレージを使用する。
USE_PERSISTENT_STORAGE=trueを設定します。 -
OpenShift Container Platform メトリクスデプロイメントで
METRICS_RESOLUTION=30パラメーターを保持する。METRICS_RESOLUTIONをデフォルト値の30よりも小さい値に設定することは推奨していません。Ansible メトリクスのインストール手順を使用する場合は、このパラメーターはopenshift_metrics_resolutionに置き換えてください。 - ホストメトリクス Pod が指定された OpenShift Container Platform ノードを詳しくモニタリングして、ホストシステムの容量不足 (CPU およびメモリー) を早い段階で検出する。このような容量不足により、メトリクス Pod で問題が発生する可能性があります。
- OpenShift Container Platform バージョン 3.7 のテストでは、最大 Pod 数 25,000 のテストケースが OpenShift Container Platform クラスターでモニタリングされました。
9.3. クラスターメトリクスの容量計画
210 および 990 の OpenShift Container Platform ノードで実施したテストでは、10500 および 11000 の Pod がそれぞれモニタリングされ、Cassandra データベースのサイズが、以下の表に記載の速度で増加しました。
表9.1 クラスター内のノード数/Pod 数に基づく Cassandra データベースのストレージ要件
| ノード数 | Pod 数 | Cassandra ストレージの増加速度 | 1 日あたりの Cassandra ストレージの増加速度 | 1 週間あたりの Cassandra ストレージの増加速度 |
|---|---|---|---|---|
|
210 |
10500 |
1 時間に 500 MB |
15 GB |
75 GB |
|
990 |
11000 |
1 時間に 1 GB |
30 GB |
210 GB |
上記の計算では、ストレージ要件が算出した値を超えないように、予想のサイズにオーバーヘッドとして約 20 % 追加しました。
METRICS_DURATION および METRICS_RESOLUTION の値がデフォルト (それぞれ 7 日と 15 秒) のままの場合は、上記の値にあるように、安全策として週ごとの Cassandra ストレージのサイズ要件を計画することができます。
OpenShift Container Platform メトリクスは、メトリクスデータのデータストアとして Cassandra データベースを使用するので、メトリクス設定のプロセスで USE_PERSISTENT_STORAGE=true に設定した場合には、NFS でネットワークストレージの上層に PV がデフォルトで配置されます。ただし、Cassandra ドキュメントにあるように、ネットワークストレージと、Cassandra を組み合わせて使用することは推奨していません。
9.4. OpenShift Container Platform メトリクス Pod のスケーリング
メトリクス Pod (Cassandra/Hawkular/Heapster) 1 セットでは、最低 25,000 の Pod をモニタリングできます。
OpenShift Container Platform メトリクス Pod が実行されるノードのシステムの負荷に注意してください。この情報を使用して、OpenShift Container Platform メトリクス Pod の数をスケールアウトし、複数の OpenShift Container Platform ノードに負荷を分散する必要があるかどうかを判断します。OpenShift Container Platform メトリクス heapster Pod のスケーリングは推奨していません。
9.4.1. 前提条件
OpenShift Container Platform メトリクスのデプロイに永続ストレージを使用した場合には、OpenShift Container Platform メトリクスの Cassandra Pod 数をスケーリングする前に、新規 Cassandra Pod が使用されるように、永続ボリューム (PV) を作成する必要があります。ただし、動的にプロビジョニングされる PV を使用して Cassandra がデプロイされた場合には、この手順は必要ありません。
9.4.2. Cassandra コンポーネントのスケーリング
Cassandra ノードは永続ストレージを使用するので、レプリケーションコントローラーでスケールダウンやスケールアップを実行することはできません。
Cassandra クラスターのスケーリングには、openshift_metrics_cassandra_replicas 変数を変更して、デプロイメント を再実行する必要があります。デフォルトでは Cassandra クラスターは単一ノードのクラスターとなっています。
OpenShift Container Platform メトリクスの hawkular pod を 2 つのレプリカにスケールアップするには、以下を実行します。
# oc scale -n openshift-infra --replicas=2 rc hawkular-metrics
または、インベントリーファイルを更新して、デプロイメントを再実行します。
Cassandra クラスターに対して、新規ノードを追加したり、既存のノードを削除した場合は、クラスターに保存したデータの負荷がクラスター全体で再度分散されます。
スケールダウンを実行するには、以下を実行します。
コンテナーにリモートからアクセスする場合は、削除する Cassandra ノードに対して以下を実行します。
$ oc exec -it <hawkular-cassandra-pod> nodetool decommission
コンテナーにローカルでアクセスする場合には、代わりに以下を実行します。
$ oc rsh <hawkular-cassandra-pod> nodetool decommission
このコマンドは、データをクラスター全体にコピーするので、実行にしばらく時間がかかります。停止の進捗状況は
nodetool netstats -Hでモニタリングできます。先のコマンドに成功すると、Cassandra インスタンスの
rcを0にスケールダウンします。# oc scale -n openshift-infra --replicas=0 rc <hawkular-cassandra-rc>
これで Cassandra Pod が削除されます。
スケールダウンプロセスが完了し、既存の Cassandra ノードが予想どおりに機能する場合には、この Cassandra インスタンスと対応する Persistent Volume Claim (PVC、永続ボリューム要求) の rc も削除できます。PVC を削除すると、この Cassandra インスタンスに関連付けられているデータが完全に削除されるので、スケールダウンが完全かつ正常に完了しなかった場合に、失われたデータを復元することはできません。
