/
OOF Beijing R2 OOM Deployment Planning

OOF Beijing R2 OOM Deployment Planning

Owned by Shankaranarayanan Puzhavakath Narayanan
Last updated: Mar 23, 2018
2 min read

Preferred deployment architecture (Based on meeting with Mike):

 

Deployment Architecture 1:

Showing the simplest scheme to start with. Note that this uses the deployment that MUSIC provides out of the box, but the MUSIC instance is not shared across other ONAP components. 

 

 

 

Deployment Architecture 2 (In R2):

Highlights the independent component-level scale out using the HAS API

 

Deployment Architecture 3 (Stretch goal in R2):

Scales out the SOLVER and DATA components independently by a different factor than the other components. Highlights the horizontal and vertical scalability of the OOF architecture.

Note:

  • All HAS components (and their replicas) access the same load-balanced instance of MUSIC

  • The HAS components other than the northbound interface of API, interact using a RPC/Messaging layer provided by MUSIC. Therefore they do not need load-balancers in front of them to scale - simply increasing the number of replicas of the components will suffice as they connect to the same underlying MUSIC instance. 

 

 

Slide deck: