第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 データベースをメトリクスデータのデータストアとして使用する場合、推奨事項については、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 クラスターに対して、新規ノードを追加したり、既存のノードを削除した場合は、クラスターに保存したデータの負荷がクラスター全体で再度分散されます。

スケールダウンを実行するには、以下を実行します。

  1. コンテナーにリモートからアクセスする場合は、削除する Cassandra ノードに対して以下を実行します。

    $ oc exec -it <hawkular-cassandra-pod> nodetool decommission

    コンテナーにローカルでアクセスする場合には、以下を代わりに実行します。

    $ oc rsh <hawkular-cassandra-pod> nodetool decommission

    このコマンドは、データをクラスター全体にコピーするので、実行にしばらく時間がかかります。停止の進捗状況は nodetool netstats -H でモニタリングできます。

  2. 先のコマンドに成功すると、Cassandra インスタンスの rc0 にスケールダウンします。

    # oc scale -n openshift-infra --replicas=0 rc <hawkular-cassandra-rc>

    これで Cassandra Pod が削除されます。

重要

スケールダウンプロセスが完了し、既存の Cassandra ノードが予想どおりに機能する場合には、この Cassandra インスタンスと対応する Persistent Volume Claim (PVC、永続ボリューム要求) の rc も削除できます。PVC を削除すると、この Cassandra インスタンスに関連付けられているデータが完全に削除されるので、スケールダウンが完全かつ正常に完了しなかった場合に、失われたデータを復元することはできません。