OpenShift Origin exposes metrics that can be collected and stored in back-ends by Heapster. As an OpenShift Origin 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.
Run metrics pods on dedicated OpenShift Origin infrastructure nodes.
Use persistent storage when configuring metrics. Set
USE_PERSISTENT_STORAGE=true.
Keep the METRICS_RESOLUTION=30 parameter in OpenShift Origin 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 OpenShift Origin 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 OpenShift Origin version 3.5 testing, test cases up to 25,000 pods were monitored in a OpenShift Origin cluster.
In tests performed with with 210 and 990 OpenShift Origin nodes, where 10500 pods and 11000 pods were monitored respectively, the Cassandra database grew at the speed shown in the table below:
| Number of Nodes | Number of Pods | Cassandra Storage growth speed | Cassandra storage growth per day | Cassandra storage growth per week |
|---|---|---|---|---|
210 |
10500 |
500 MB per hour |
15 GB |
75 GB |
990 |
11000 |
1 GB per hour |
30 GB |
210 GB |
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.
|
Because OpenShift Origin metrics uses the Cassandra database as a datastore for
metrics data, if |
One set of metrics pods (Cassandra/Hawkular/Heapster) is able to monitor at least 25,000 pods.
|
Pay attention to system load on nodes where OpenShift Origin metrics pods run. Use that information to determine if it is necessary to scale out a number of OpenShift Origin metrics pods and spread the load across multiple OpenShift Origin nodes. Scaling OpenShift Origin metrics heapster pods is not recommended. |
If persistent storage was used to deploy OpenShift Origin metrics, then you must create a persistent volume (PV) for the new Cassandra pod to use before you can scale out the number of OpenShift Origin metrics Cassandra pods. However, if Cassandra was deployed with dynamically provisioned PVs, then this step is not necessary.
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.
|
If you add a new node to or remove an existing node from a Cassandra cluster, the data stored in the cluster rebalances across the cluster. |