Bin Yang | 6237ee2 | 2018-11-21 08:43:35 +0000 | [diff] [blame] | 1 | .. |
| 2 | This work is licensed under a Creative Commons Attribution 4.0 |
| 3 | International License. |
| 4 | Copyright (c) 2018 Wind River Systems, Inc. |
| 5 | |
| 6 | ============================ |
| 7 | ONAP MultiCloud Architecture |
| 8 | ============================ |
| 9 | |
| 10 | Value Proposition |
| 11 | ----------------- |
| 12 | |
| 13 | ONAP MultiCloud project aims to mediate most interactions (if not all of them) |
| 14 | between ONAP and any underlying VIM or Cloud to: |
| 15 | |
| 16 | * enable ONAP to deploy and run on multiple infrastructure environments |
| 17 | * provide a Cloud Mediation Layer supporting multiple infrastructures and |
| 18 | network backends so as to effectively prevents vendor lock-in |
| 19 | * decouples the evolution of ONAP platform from the evolution of underlying |
| 20 | cloud infrastructure, and minimizes the impact on the deployed ONAP while |
| 21 | upgrading the underlying cloud infrastructures independently |
| 22 | |
| 23 | Besides that, ONAP MultiCloud project enables |
| 24 | |
| 25 | * infrastructure providers exposing infrastructure's resources and features |
| 26 | to ONAP for optimization of homing and placement of VNFs |
| 27 | * support the closed control loop remediation over infrastructure resources |
| 28 | |
| 29 | High Level Architecture and Workflows |
| 30 | ------------------------------------- |
| 31 | |
| 32 | The following high level architecture and workflow diagram depicts how |
| 33 | ONAP MultiCloud is designed and integrated into ONAP end to end workflow |
| 34 | |
| 35 | .. image:: ./images/mc-arch-workflow.png |
| 36 | :alt: Multicloud icons in MSB |
| 37 | :width: 975 |
| 38 | :height: 293 |
| 39 | :align: center |
| 40 | |
| 41 | Components: |
| 42 | ~~~~~~~~~~~ |
| 43 | **Broker:** |
| 44 | |
| 45 | A single broker deployed as micro-service exposes following functionalities: |
| 46 | |
| 47 | * Expose metadata list of supported plugins to ESR |
| 48 | * Route and forward API requests to appropriate plugin by looking up AAI cloud |
| 49 | region with ID of the cloud region |
| 50 | * Dispatch capacity checking API to all related plugins |
| 51 | |
| 52 | |
| 53 | **Plugin(s):** |
| 54 | |
| 55 | Plugin adapts API requests to corresponding VIM/Cloud. |
| 56 | |
| 57 | There are multiple plugins deployed as micro-services available: |
| 58 | |
| 59 | * Plugin for Wind River: Adapt to Wind River Titanium Cloud R3, R4 or R5 |
| 60 | * Plugin for Ocata/Pike: Adapt to Vanilla OpenStack Releases: Ocata, Pike |
| 61 | * Plugin for VIO: Adapt to VMware VIO |
| 62 | * Plugin for Azure: Adapt to Microsoft Azure Cloud. |
| 63 | * Plugin for kubernetes: Adapt to Kubernetes clusters |
| 64 | |
| 65 | Dependencies: |
| 66 | ~~~~~~~~~~~~~ |
| 67 | |
| 68 | * MultiCloud micro-services exposed services via MSB |
| 69 | * MultiCloud relies on MSB for API forwarding between broker and plugin |
| 70 | micro-services |
| 71 | * MultiCloud micro-services relies on AAI for any persistent data storage. |
| 72 | e.g. AAI Cloud Region Object |
| 73 | |
| 74 | |
| 75 | Workflow elaboration: |
| 76 | ~~~~~~~~~~~~~~~~~~~~~ |
| 77 | |
| 78 | 0) OOM Deploys ONAP MultiCloud services |
| 79 | #) ONAP users on-boards underlying VIM or Cloud instances via ONAP ESR GUI. |
| 80 | ESR creates AAI cloud region object and requests MultiCloud to update the |
| 81 | cloud region with discovered infrastructure's resources and capabilities |
| 82 | |
| 83 | #) SDC distributes Service Model and VNF artifacts |
| 84 | |
| 85 | #) ONAP users deploy services, instantiate VNF |
| 86 | |
| 87 | #) ONAP SO consult OOF for VNF homing and placement hints, OOF matches the |
| 88 | VNF's requirement and cloud region's capabilities and resources to select |
| 89 | the best candidates for VNF homing.OOF also consult MultiCloud for checking |
| 90 | the capacity for VNF placement. |
| 91 | |
| 92 | #) The VNF instantiating |
| 93 | The VNF instantiating approach varies with different use case (or VNF |
| 94 | artifacts type): |
| 95 | |
| 96 | In case of VIM/Cloud specific artifact type, e.g. HEAT templates, SO |
| 97 | invokes MultiCloud directly to instantiate the VNF. |
| 98 | |
| 99 | In case of VNFD in TOSCA artifacts, SO invokes VF-C to decompose the |
| 100 | TOSCA artifact to atomic resource level and VF-C invokes MultiCloud for |
| 101 | atomic resource instantiating. |
| 102 | |
| 103 | The interaction between SDN-C and MultiCloud is not yet designed. |
| 104 | |
| 105 | #) MultiCloud also supports close loop remediation by relaying FCAPS events |
| 106 | and stream to DCAE VES collector. |
| 107 | |
| 108 | #) APP-C might request MultiCloud to perform resource level remediation |
| 109 | |
| 110 | API pattern: |
| 111 | ~~~~~~~~~~~~ |
| 112 | MultiCloud broker exposes API exposed with namespace and version as below: |
| 113 | |
| 114 | :: |
| 115 | |
| 116 | api/multicloud/v1/ |
| 117 | |
| 118 | MultiCloud Plugins expose their API with namespace and version as below: |
| 119 | |
| 120 | :: |
| 121 | |
| 122 | api/multicloud-titaniumcloud/v1/ |
| 123 | api/multicloud-ocata/v1/ |
| 124 | api/multicloud-vio/v1/ |
| 125 | api/multicloud-azure/v1/ |
| 126 | api/multicloud-k8s/v1/ |
| 127 | |
| 128 | |
| 129 | For most APIs, the ID of a cloud region follows the API version, with which |
| 130 | MultiCloud broker will forward the API to corresponding MultiCloud plugin for |
| 131 | handling. |
| 132 | |
| 133 | :: |
| 134 | |
| 135 | api/multicloud/v1/{cloud-owner}/{cloud-region-id} |
| 136 | |
| 137 | MultiCloud services are registered into MSB so they can be discovered/reached |
| 138 | via MSB API gateway. |
| 139 | |
| 140 | :: |
| 141 | |
| 142 | e.g. POST msb.onap.org:80/api/multicloud/v1/{cloud-owner}/{cloud-region-id}/infra_workload |
| 143 | |
| 144 | |
| 145 | API catalogs |
| 146 | ~~~~~~~~~~~~ |
| 147 | |
| 148 | The Northbound APIs can be cataloged as following |
| 149 | |
| 150 | 1) Common MultiCloud functionalities |
| 151 | |
| 152 | **API swagger:** |
| 153 | API swagger is used for Health Check as well |
| 154 | |
| 155 | 2) Infrastructure Provider registration |
| 156 | The infrastructure provider registration API is to trigger the discovery |
| 157 | and registration of infrastructure capabilities (e.g. HPA capabilities) |
| 158 | and resource. |
| 159 | |
| 160 | 3) Template level APIs |
| 161 | Template level APIs are the integrating point between SO and MultiCloud |
| 162 | which offloads the LCM of infrastructure workload from SO |
| 163 | |
| 164 | 4) Atomic resource level APIs: |
| 165 | |
| 166 | This set of API falls into either catalog of following |
| 167 | |
| 168 | **Proxy of OpenStack services** |
| 169 | |
| 170 | The proxy of OpenStack services exposed all OpenStack services by replacing |
| 171 | the endpoints. This is designed to smoothly integrate MultiCloud with |
| 172 | existing ONAP projects which have been talking to OpenStack directly. |
| 173 | e.g. APPC |
| 174 | |
| 175 | The API works the same way as native OpenStack API except the difference of |
| 176 | endpionts [1]_. |
| 177 | |
| 178 | **Legacy Abstract APIs for VF-C** |
| 179 | |
| 180 | The legacy abstract APIs for VF-C are inherited from OPEN-O project which |
| 181 | abstracted the OpenStack service APIs. |
| 182 | |
| 183 | 5) Placement Optimization APIs: |
| 184 | Aggregate Resource Checking APIs help OOF to optimize the placement of |
| 185 | VNF over underlying VIM/Cloud |
| 186 | |
| 187 | 6) FCAPS configuration APIs: |
| 188 | FCAPS Configuration APIs allow users to configure the MultiCloud FCAPS |
| 189 | relaying services. |
| 190 | |
| 191 | |
| 192 | Terminology |
| 193 | ----------- |
| 194 | |
| 195 | * ONAP MultiCloud, ONAP Multi-VIM/Cloud, ONAP MultiVIM refer to the same |
| 196 | project in ONAP. |
| 197 | |
| 198 | * MultiCloud framework is the repo for source code, MultiCloud broker is the |
| 199 | entity built from framework |
| 200 | |
| 201 | |
| 202 | References |
| 203 | ---------- |
| 204 | |
| 205 | .. [1] https://wiki.onap.org/download/attachments/8227952/OANP_MultiCloud_R1_service_proxy_design.docx?version=1&modificationDate=1531281181000&api=v2 |