You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

Resource nameDescriptionNotes
Cps-and-ncmp deployment
  • 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
Postgres deployment
  • creates instances of pods that run Postgres
  • default pod replica count is set to 1 (i.e. creates 1 pod)
  • utilizes persistent volumes

CPS-NCMP Service
  • 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

Diagram 4



--------

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.


Diagram 3

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#:~:text=In%20Kubernetes%2C%20a%20HorizontalPodAutoscaler%20automatically,is%20to%20deploy%20more%20Pods.

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)


Diagram 1

  • No labels