diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/MultiCloud-Architecture.rst | 378 |
1 files changed, 205 insertions, 173 deletions
diff --git a/docs/MultiCloud-Architecture.rst b/docs/MultiCloud-Architecture.rst index f1c5087..56a3cc6 100644 --- a/docs/MultiCloud-Architecture.rst +++ b/docs/MultiCloud-Architecture.rst @@ -1,173 +1,205 @@ -..
- This work is licensed under a Creative Commons Attribution 4.0
- International License.
- Copyright (c) 2018 Wind River Systems, Inc.
-
-============================
-ONAP MultiCloud Architecture
-============================
-
-Value Proposition
------------------
-
-ONAP MultiCloud project aims to mediate most interactions (if not all of them)
-between ONAP and any underlying VIM or Cloud to:
-
-* enable ONAP to deploy and run on multiple infrastructure environments
-* provide a Cloud Mediation Layer supporting multiple infrastructures and network backends so as to effectively prevents vendor lock-in
-* decouples the evolution of ONAP platform from the evolution of underlying cloud infrastructure, and minimizes the impact on the deployed ONAP while upgrading the underlying cloud infrastructures independently
-
-Besides that, ONAP MultiCloud project enables
-
-* infrastructure providers exposing infrastructure's resources and features to ONAP for optimization of homing and placement of VNFs
-* support the closed control loop remediation over infrastructure resources
-
-High Level Architecture and Workflows
--------------------------------------
-
-The following high level architecture and workflow diagram depicts how
-ONAP MultiCloud is designed and integrated into ONAP end to end workflow
-
-.. image:: ./images/mc-arch-workflow.png
- :alt: Multicloud icons in MSB
- :width: 975
- :height: 293
- :align: center
-
-Components:
-~~~~~~~~~~~
-**Broker:**
-
-A single broker deployed as micro-service exposes following functionalities:
-
-* Expose metadata list of supported plugins to ESR
-* Route and forward API requests to appropriate plugin by looking up AAI cloud region with ID of the cloud region
-* Dispatch capacity checking API to all related plugins
-
-
-**Plugin(s):**
-
-Plugin adapts API requests to corresponding VIM/Cloud.
-
-There are multiple plugins deployed as micro-services available:
-
-* Plugin for Wind River: Adapt to Wind River Titanium Cloud R3, R4 or R5
-* Plugin for Ocata/Pike: Adapt to Vanilla OpenStack Releases: Ocata, Pike, and more to come
-* Plugin for VIO: Adapt to VMware VIO
-* Plugin for Azure: Adapt to Microsoft Azure Cloud.
-* Plugin for kubernetes: Adapt to Kubernetes clusters
-
-Dependencies:
-~~~~~~~~~~~~~
-
-* MultiCloud micro-services exposed services via MSB
-* MultiCloud relies on MSB for API forwarding between broker and plugin micro-services
-* MultiCloud micro-services relies on AAI for any persistent data storage. e.g. AAI Cloud Region Object
-
-
-Workflow elaboration:
-~~~~~~~~~~~~~~~~~~~~~
-
-0) OOM Deploys ONAP MultiCloud services
-#) ONAP users on-boards underlying VIM or Cloud instances via ONAP ESR GUI Portal.
- ESR creates AAI cloud region object and requests MultiCloud to update the cloud region with discovered infrastructure's resources and capabilities
-
-#) SDC distributes Service Model and VNF artifacts
-
-#) ONAP users deploy services, instantiate VNF
-
-#) ONAP SO consult OOF for VNF homing and placement hints, OOF matches the
- VNF's requirement and cloud region's capabilities and resources to select
- the best candidates for VNF homing.OOF also consult MultiCloud for checking
- the capacity for VNF placement.
-
-#) The VNF instantiating
- The VNF instantiating approach varies with different use case (or VNF artifacts type)
- In case of VIM/Cloud specific artifact type, e.g. HEAT templates, SO invokes MultiCloud directly to instantiate the VNF.
- In case of VNFD in TOSCA artifacts, SO invokes VF-C to decompose the TOSCA artifact to atomic resource level and VF-C invokes MultiCloud for atomic resource instantiating.
- The interaction between SDN-C and MultiCloud is not yet designed.
-
-#) MultiCloud also supports close loop remediation by relaying FCAPS events and stream to DCAE VES collector.
-
-#) APP-C might request MultiCloud to perform resource level remediation
-
-API pattern:
-~~~~~~~~~~~~
-MultiCloud broker exposes API exposed with namespace and version as below:
-
- api/multicloud/v1/
-
-MultiCloud Plugins expose their API with namespace and version as below:
-
- api/multicloud-titaniumcloud/v1/
-
- api/multicloud-ocata/v1/
-
- api/multicloud-vio/v1/
-
- api/multicloud-azure/v1/
-
- api/multicloud-k8s/v1/
-
-
-For most APIs, the ID of a cloud region follows the API version, with which MultiCloud broker will forward the API to corresponding MultiCloud plugin for handling.
-
- api/multicloud/v1/{cloud-owner}/{cloud-region-id}
-
-MultiCloud services are registered into MSB so they can be discovered/reached via MSB API gateway.
-
- e.g. POST msb.onap.org:80/api/multicloud/v1/{cloud-owner}/{cloud-region-id}/infra_workload
-
-
-
-API catalogs
-~~~~~~~~~~~~
-
-The Northbound APIs can be cataloged as following
-
-1) Common MultiCloud functionalities
-
- **API swagger:**
- API swagger is used for Health Check as well
-
-2) Infrastructure Provider registration
- The infrastructure provider registration API is to trigger the discovery and registration of infrastructure capabilities (e.g. HPA capabilities) and resource.
-
-3) Template level APIs
- Template level APIs are the integrating point between SO and MultiCloud which offloads the LCM of infrastructure workload from SO
-
-4) Atomic resource level APIs:
-
- This set of API falls into either catalog of following
-
- **Proxy of OpenStack services**
-
- The proxy of OpenStack services exposed all OpenStack services by replacing the endpoints. This is designed to smoothly integrate MultiCloud with existing ONAP projects which have been talking to OpenStack directly. e.g. APPC
-
- The API works the same way as native OpenStack API except the difference of endpionts [1]_.
-
- **Legacy Abstract APIs for VF-C**
-
- The legacy abstract APIs for VF-C are inherited from OPEN-O project which abstracted the OpenStack service APIs.
- The API exposes openstack services with abstract
-
-5) Placement Optimization APIs:
- Aggregate Resource Checking APIs help OOF to optimize the placement of
- VNF over underlying VIM/Cloud
-
-6) FCAPS configuration APIs:
- FCAPS Configuration APIs allow users to configure the MultiCloud FCAPS relaying services.
-
-
-Terminology
------------
-
-* ONAP MultiCloud, ONAP Multi-VIM/Cloud, ONAP MultiVIM refer to the same project in ONAP.
-
-* MultiCloud framework is the repo for source code, MultiCloud broker is the entity built from framework
-
-
-References
-----------
-
-.. [1] https://wiki.onap.org/download/attachments/8227952/OANP_MultiCloud_R1_service_proxy_design.docx?version=1&modificationDate=1531281181000&api=v2
\ No newline at end of file +.. + This work is licensed under a Creative Commons Attribution 4.0 + International License. + Copyright (c) 2018 Wind River Systems, Inc. + +============================ +ONAP MultiCloud Architecture +============================ + +Value Proposition +----------------- + +ONAP MultiCloud project aims to mediate most interactions (if not all of them) +between ONAP and any underlying VIM or Cloud to: + +* enable ONAP to deploy and run on multiple infrastructure environments +* provide a Cloud Mediation Layer supporting multiple infrastructures and + network backends so as to effectively prevents vendor lock-in +* decouples the evolution of ONAP platform from the evolution of underlying + cloud infrastructure, and minimizes the impact on the deployed ONAP while + upgrading the underlying cloud infrastructures independently + +Besides that, ONAP MultiCloud project enables + +* infrastructure providers exposing infrastructure's resources and features + to ONAP for optimization of homing and placement of VNFs +* support the closed control loop remediation over infrastructure resources + +High Level Architecture and Workflows +------------------------------------- + +The following high level architecture and workflow diagram depicts how +ONAP MultiCloud is designed and integrated into ONAP end to end workflow + +.. image:: ./images/mc-arch-workflow.png + :alt: Multicloud icons in MSB + :width: 975 + :height: 293 + :align: center + +Components: +~~~~~~~~~~~ +**Broker:** + +A single broker deployed as micro-service exposes following functionalities: + +* Expose metadata list of supported plugins to ESR +* Route and forward API requests to appropriate plugin by looking up AAI cloud + region with ID of the cloud region +* Dispatch capacity checking API to all related plugins + + +**Plugin(s):** + +Plugin adapts API requests to corresponding VIM/Cloud. + +There are multiple plugins deployed as micro-services available: + +* Plugin for Wind River: Adapt to Wind River Titanium Cloud R3, R4 or R5 +* Plugin for Ocata/Pike: Adapt to Vanilla OpenStack Releases: Ocata, Pike +* Plugin for VIO: Adapt to VMware VIO +* Plugin for Azure: Adapt to Microsoft Azure Cloud. +* Plugin for kubernetes: Adapt to Kubernetes clusters + +Dependencies: +~~~~~~~~~~~~~ + +* MultiCloud micro-services exposed services via MSB +* MultiCloud relies on MSB for API forwarding between broker and plugin + micro-services +* MultiCloud micro-services relies on AAI for any persistent data storage. + e.g. AAI Cloud Region Object + + +Workflow elaboration: +~~~~~~~~~~~~~~~~~~~~~ + +0) OOM Deploys ONAP MultiCloud services +#) ONAP users on-boards underlying VIM or Cloud instances via ONAP ESR GUI. + ESR creates AAI cloud region object and requests MultiCloud to update the + cloud region with discovered infrastructure's resources and capabilities + +#) SDC distributes Service Model and VNF artifacts + +#) ONAP users deploy services, instantiate VNF + +#) ONAP SO consult OOF for VNF homing and placement hints, OOF matches the + VNF's requirement and cloud region's capabilities and resources to select + the best candidates for VNF homing.OOF also consult MultiCloud for checking + the capacity for VNF placement. + +#) The VNF instantiating + The VNF instantiating approach varies with different use case (or VNF + artifacts type): + + In case of VIM/Cloud specific artifact type, e.g. HEAT templates, SO + invokes MultiCloud directly to instantiate the VNF. + + In case of VNFD in TOSCA artifacts, SO invokes VF-C to decompose the + TOSCA artifact to atomic resource level and VF-C invokes MultiCloud for + atomic resource instantiating. + + The interaction between SDN-C and MultiCloud is not yet designed. + +#) MultiCloud also supports close loop remediation by relaying FCAPS events + and stream to DCAE VES collector. + +#) APP-C might request MultiCloud to perform resource level remediation + +API pattern: +~~~~~~~~~~~~ +MultiCloud broker exposes API exposed with namespace and version as below: + +:: + + api/multicloud/v1/ + +MultiCloud Plugins expose their API with namespace and version as below: + +:: + + api/multicloud-titaniumcloud/v1/ + api/multicloud-ocata/v1/ + api/multicloud-vio/v1/ + api/multicloud-azure/v1/ + api/multicloud-k8s/v1/ + + +For most APIs, the ID of a cloud region follows the API version, with which +MultiCloud broker will forward the API to corresponding MultiCloud plugin for +handling. + +:: + + api/multicloud/v1/{cloud-owner}/{cloud-region-id} + +MultiCloud services are registered into MSB so they can be discovered/reached +via MSB API gateway. + +:: + + e.g. POST msb.onap.org:80/api/multicloud/v1/{cloud-owner}/{cloud-region-id}/infra_workload + + +API catalogs +~~~~~~~~~~~~ + +The Northbound APIs can be cataloged as following + +1) Common MultiCloud functionalities + + **API swagger:** + API swagger is used for Health Check as well + +2) Infrastructure Provider registration + The infrastructure provider registration API is to trigger the discovery + and registration of infrastructure capabilities (e.g. HPA capabilities) + and resource. + +3) Template level APIs + Template level APIs are the integrating point between SO and MultiCloud + which offloads the LCM of infrastructure workload from SO + +4) Atomic resource level APIs: + + This set of API falls into either catalog of following + + **Proxy of OpenStack services** + + The proxy of OpenStack services exposed all OpenStack services by replacing + the endpoints. This is designed to smoothly integrate MultiCloud with + existing ONAP projects which have been talking to OpenStack directly. + e.g. APPC + + The API works the same way as native OpenStack API except the difference of + endpionts [1]_. + + **Legacy Abstract APIs for VF-C** + + The legacy abstract APIs for VF-C are inherited from OPEN-O project which + abstracted the OpenStack service APIs. + +5) Placement Optimization APIs: + Aggregate Resource Checking APIs help OOF to optimize the placement of + VNF over underlying VIM/Cloud + +6) FCAPS configuration APIs: + FCAPS Configuration APIs allow users to configure the MultiCloud FCAPS + relaying services. + + +Terminology +----------- + +* ONAP MultiCloud, ONAP Multi-VIM/Cloud, ONAP MultiVIM refer to the same + project in ONAP. + +* MultiCloud framework is the repo for source code, MultiCloud broker is the + entity built from framework + + +References +---------- + +.. [1] https://wiki.onap.org/download/attachments/8227952/OANP_MultiCloud_R1_service_proxy_design.docx?version=1&modificationDate=1531281181000&api=v2 |