Scaling Cluster Metrics

You are viewing documentation for a release that is no longer supported. The latest supported version of version 3 is [3.11]. For the most recent version 4, see [4]

You are viewing documentation for a release that is no longer supported. The latest supported version of version 3 is [3.11]. For the most recent version 4, see [4]

Overview

OKD exposes metrics that can be collected and stored in back-ends by Heapster. As an OKD administrator, you can view containers and components metrics in one user interface. These metrics are also used by horizontal pod autoscalers in order to determine when and how to scale.

This topic provides information for scaling the metrics components.

Recommendations for OKD

• Run metrics pods on dedicated OKD infrastructure nodes.

• Use persistent storage when configuring metrics. Set USE_PERSISTENT_STORAGE=true.

• Keep the METRICS_RESOLUTION=30 parameter in OKD metrics deployments. Using a value lower than the default value of 30 for METRICS_RESOLUTION is not recommended. When using the Ansible metrics installation procedure, this is the openshift_metrics_resolution parameter.

• Closely monitor OKD nodes with host metrics pods to detect early capacity shortages (CPU and memory) on the host system. These capacity shortages can cause problems for metrics pods.

• In OKD version 3.7 testing, test cases up to 25,000 pods were monitored in a OKD cluster.

Capacity Planning for Cluster Metrics

In tests performed with 210 and 990 OKD nodes, where 10500 pods and 11000 pods were monitored respectively, the Cassandra database grew at the speed shown in the table below:

In the above calculation, approximately 20 percent of the expected size was added as overhead to ensure that the storage requirements do not exceed calculated value.

If the METRICS_DURATION and METRICS_RESOLUTION values are kept at the default (7 days and 15 seconds respectively), it is safe to plan Cassandra storage size requirements for week, as in the values above.

Scaling OKD Metrics Pods

One set of metrics pods (Cassandra/Hawkular/Heapster) is able to monitor at least 25,000 pods.

Prerequisites

If persistent storage was used to deploy OKD metrics, then you must create a persistent volume (PV) for the new Cassandra pod to use before you can scale out the number of OKD metrics Cassandra pods. However, if Cassandra was deployed with dynamically provisioned PVs, then this step is not necessary.

Scaling the Cassandra Components

Cassandra nodes use persistent storage. Therefore, scaling up or down is not possible with replication controllers.

Scaling a Cassandra cluster requires modifying the openshift_metrics_cassandra_replicas variable and re-running the deployment. By default, the Cassandra cluster is a single-node cluster. To deploy more nodes, provision storage if openshift_metrics_cassandra_replicas equals pv and increase the openshift_metrics_cassandra_replicas value.

To scale up the number of OKD metrics hawkular pods to two replicas, run:

# oc scale -n openshift-infra --replicas=2 rc hawkular-metrics

Alternatively, update your inventory file and re-run the deployment.

To scale down:

1. If remotely accessing the container, run the following for the Cassandra node you want to remove:

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

   If locally accessing the container, run the following instead:

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

   This command can take a while to run since it copies data across the cluster. You can monitor the decommission progress with nodetool netstats -H.

2. Once the previous command succeeds, scale down the rc for the Cassandra instance to 0.

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

   This will remove the Cassandra pod.