38.3.2. クラスターメトリクスのキャパシティーピニング
openshift_metrics Ansible ロールを実行した後、oc get pods の出力は以下のようになります。
# oc get pods -n openshift-infra NAME READY STATUS RESTARTS AGE hawkular-cassandra-1-l5y4g 1/1 Running 0 17h hawkular-metrics-1t9so 1/1 Running 0 17h heapster-febru 1/1 Running 0 17h
OpenShift Container Platform メトリクスは Cassandra データベースを使用して保存されます。このデータベースは openshift_metrics_cassandra_limits_memory: 2G の設定でデプロイされます。 この値は Cassandra の開始スクリプトで決定される空きメモリー容量に応じてさらに調整できます。この値はほとんどの OpenShift Container Platform メトリクスインストールに対応しますが、クラスターメトリクスをデプロイする前に、環境変数を使用して MAX_HEAP_SIZE と ヒープの新しい生成サイズ HEAP_NEWSIZE を Cassandra Dockerfile で変更できます。
デフォルトで、メトリクスデータは 7 日間保存されます。7 日が経過すると、Cassandra は最も古いメトリクスデータのパージを開始します。削除された Pod とプロジェクトのメトリクスデータは自動的にはパージされません。 7 日を超えたデータのみが削除されます。
例38.1 10 のノードと 1000 の Pod による累積データ
10 のノードと 1000 の Pod を含むテストシナリオでは、24 時間で 2.5 GB のメトリクスデータが累積されました。このため、このシナリオでのメトリクスデータの容量計画の計算式は以下のようになります。
(((2.5 × 109) ÷ 1000) ÷ 24) ÷ 106 = ~0.125 MB/hour per pod.
例38.2 120 のノードと 10000 の Pod による累積データ
120 のノードと 10000 の Pod を含むテストシナリオでは、24 時間で 25 GB のメトリクスデータが累積されました。このため、このシナリオでのメトリクスデータの容量計画の計算式は以下のようになります。
(((11.410 × 109) ÷ 1000) ÷ 24) ÷ 106 = 0.475 MB/hour
| 1000 の Pod | 10000 の Pod | |
|---|---|---|
| 24 時間で累積される Cassandra ストレージデータ (デフォルトのメトリクスパラメーター) | 2.5 GB | 11.4 GB |
openshift_metrics_duration の 7 日間および openshift_metrics_resolution の 30 秒間というデフォルト値を維持する場合、Cassandra Pod の週次のストレージ要件は以下のようになります。
| 1000 の Pod | 10000 の Pod | |
|---|---|---|
| 7 日間で累積される Cassandra ストレージデータ (デフォルトのメトリクスパラメーター) | 20 GB | 90 GB |
先の表では、予期せずモニターリングされた Pod 使用量のバッファーとして、予期されたストレージ容量に対して予備の 10% が追加されています。
Cassandra の永続化ボリュームに十分な空き容量がなくなると、データ損失が発生します。
クラスターメトリクスを永続ストレージと共に使用するには、永続ボリュームに ReadWriteOnce アクセスモードが設定されていることを確認します。このモードがアクティブではない場合、Persistent Volume Claim (永続ボリューム要求) は永続ボリュームを特定できず、Cassandra の開始に失敗します。
永続ストレージをメトリックコンポーネントと併用するには、十分なサイズの 永続ボリューム があることを確認します。Persistent Volume Claim (永続ボリューム要求) の作成は OpenShift Ansible openshift_metrics ロールによって処理されます。
OpenShift Container Platform メトリクスは、動的にプロビジョニングされた永続ボリュームもサポートします。この機能を OpenShift Container Platform メトリクスで使用するには、openshift_metrics_cassandra_storage_type の値を dynamic に設定する必要があります。EBS、GCE、Cinder ストレージバックエンドを使用すると 永続ボリュームを動的にプロビジョニング できます。
パフォーマンスの設定およびクラスターメトリクス Pod のスケーリングについては、Scaling Cluster Metrics のトピックを参照してください。
| ノード数 | 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 秒間) に維持されている場合、1 週間の Cassandra ストレージサイズ要件を上記の値に設定することを問題なく計画できるでしょう。
OpenShift Container Platform メトリクスは、メトリクスデータのデータストアとして Cassandra データベースを使用するので、メトリクス設定のプロセスで USE_PERSISTANT_STORAGE=true に設定した場合には、NFS でネットワークストレージの上層に PV がデフォルトで配置されます。ただし、Cassandra ドキュメント にあるように、ネットワークストレージと、Cassandra を組み合わせて使用することは推奨していません。
既知の問題と制限
テストの結果として、heapster メトリクスコンポーネントは最大 25,000 の Pod を処理できることが確認されています。Pod 数がこの数を超過すると、Heapster のメトリクス処理が遅くなり始め、メトリクスグラフが表示されなくなる可能性があります。Heapster がメトリクスを収集できる Pod 数を増加する作業と、メトリクスを収集する代替ソリューションのアップストリーム開発が進められています。
