Overview
This analysis is to see the possibility of scaling the CPS-NCMP component horizontally to respond well to increased load.
CPS Deployment in ONAP
Currently, CPS in ONAP deployment has the following configuration
...
- creates instances of pods that run cps application
- default pod replica count is set to 1 (i.e. creates 1 pod)
- has 3 associated volumes
...
- creates instances of pods that run Postgres
- default pod replica count is set to 1 (i.e. creates 1 pod)
- utilizes persistent volumes
...
- uses ClusterIP which exposes CPS's multiple ports to allow only internal access to pods
Containers
The relevant container images for this study are cps-and-ncmp and Postgres.
Pods
- CPS-NCMP instance pod(s)
- default is one pod
- Postgres instance
- default is one pod
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
--------
web controller - stateless ---- replica sets
database - stateful
--------
bottleneck — filesystem —database — vertical scaling maybe more CPU/memory -
--- own deployment maybe ?
replicate cps core ncmp while being stateless and replicas - make sure that no state is kept (no cache) — look at all
--- if all user is in same deployment then maybe multiple instance of the database but the synchronisation will be complex (postgres running in clustermode)
can deploy database in clustermode ----
as per bruno - there's no authentication on cps
different database for different dataspaces ?
-----------------------------
Load Balancing
Horizontal Pod Autoscaler (HPA)
In the current CPS deployment object, the number of pods can be scaled up by specifying the number of replica counts which is currently at the default number of 1. Horizontal Pod Autoscaler allows the automatic deployment of pods to satisfy the expected configuration wherein the number of pods depends on the load i.e. the workload resource will be scaled back down if the load decreases and the number of pods are above the configured minimum.
Gliffy Diagram macroId 12f628bc-31d4-4714-ae5d-d7e4adc47638 displayName Diagram 3 name Diagram 3 pagePin 5
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
HPA can be defined with multiple and custom metrics.
https://www.heydari.be/papers/WoC-stef.pdf
- Scaling stateful applications requires more planning and is thus also slower in most cases. This makes vertical scaling the preferred method of scaling for stateful applications during a load peak, as no new replicas need to be scheduled.
- burst propagation: eviction of one replica results in the load being redirected to another replica.
- Another option for container orchestration frameworks is to throttle the resources of a container instead of evicting it, but this will cause a drop in performance during load peaks
Vertical Pod Autoscaler (VPA)
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|