- Proposed name for the project:
Multisite Virtualized Infrastructure
- Proposed name for the repository:
- Project Categories:
NFV infrastructure must be distributed across multiple geographical locations. This will require multiple connected OpenStack deployments, of different sizes. The infrastructure will also mix physical and virtual infrastructure.
The platform must be able to support application-level redundancy across different datacenters, network management across multiple sites, and between physical and virtual infrastructure, multi-site image replication, and global and per-site quota management.
This project focus on the enhancement to OpenStack ( Nova / Cinder / Neutron / Glance / Ceilometer / KeyStone ), so that OpenStack as the VIM is able to support multisite NFV cloud.
As shown in the above figure, although Multisite is not a requirement project that only integrates works from other requirement projects, it does have possible inputs from projects like Copper, Promise, VNFFG, Doctor, HA, Paser, and other new project being able to running on multi-site scenario. It should be noted that it is up to the respective project team to decide if they have requirements for such scenario, and what those requirements would be (That's why they are all in dotted lines). For projects that do see multi-site scenario is necessary, Multisite project would be more than glad to work together with those projects, through any form it deems fit, to provide common requirements, and further feedback to the upstream community for implementation.
For those of which features will be developed only inside one site, for example Qtip, VSPERF, some feature of HA, some feature of Doctor, will not produce dependency on multi-site project. However it should also be noted that there are certain scenarios in a single site deployment that actually deals with similar technical difficualties as in a multisite deployment. These scenarios, if deems necessary, would be included in the Multisite project discussion.
General High Level Requirements
The Multisite Project would like to drive the following high level requirements to be defined in the process:
1. The requirement of supporting performance and fault management for a multisite VIM deployment scenario.
2. The requirement of supporting vnf software image management for a multisite VIM deployment scenario.
3. The requirement of virtualized resource management for a multisite VIM deployment scenario.
4. The requirement of supporting identity management for a multisite VIM deployment scenario.
5. The requirement of supporting policy management for a multisite VIM deployment scenario.
6. The requirement of message bus enhancement for a multisite VIM deployment scenario.
7. The requirement of defining/utilizing NFVI Descriptor/Record for a multisite VIM deployment scenario.
8. The requirement of supporting High Availability for a multisite VIM deployment scenario.
9. The requirement of supporting Disaster Recovery for a multisite VIM deployment scenario.
More requirements would be added afterwards.
Sample Use Cases dealing with HA, GR:
- 1. HA: High Availability cross VIMs ( in one site, but not limited to). Requirements for such use case would relate to how Neutron establish the networks to support HA or how Keystone maintains HA features, for instances.
- 2. GR: Geo-site Redundancy, with/without application level data/configuration replication (Cross-site disaster recovery would be one classic use case of this type). Requirements for such use case would relate to for example, how Cinder supports cross-site data replication.
- 3. GLB: Geo-site Load Balancing, DNS based, or non-DNS based. GLB can work as the front-end for HA and GR, HA and GR can work without GLB.
In the above exemplary use cases, VNF may run in active-active or active-standby mode, according to the VNF management setup, which is out of the scope of this project. This project only concerns with how VIM should support the VNF in multi-site scenario.
It should be noted that these are non-exhaustive exemplary use cases which aim to serve the purpose of the clarification of the project, in certain aspects that may have confusions .
More detailed use cases are among the targeted deliverables of phase 1 of this project, which won’t be available during the proposal period, and more sophisticated use cases like migration across VIM could be discussed in the later phase.
Currently there are several high level use cases already defined by ETSI NFV documents?
The application level use cases and requirements to deploy VNFs in multiple OpenStack instances in multi-site for NFV cloud need to be investigated and defined.
Based on the application level use cases defined in this project, currently technical solution provided by OpenStack should be studied whether these solutions are good enough for multi-site NFV cloud, what's the improvement for OpenStack (including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer) to meet the demand for multi-site use cases:
The gaps for OpenStack (including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer ) to support multi-site NFV cloud need to be identified and addressed.
Useful Etherpad Links
Multisite Related BPs For OpenStack Liberty Release
Search For "Multisite" in OPNFV BP Page
Describe the problem being solved by project.
Specify any interface/API specification proposed
Specify testing and integration:
Debugging and Tracing
Unit/Integration Test plans
Client tools developed for status shows etc.
Identity a list of features and functionality will be developed.
Identify what is in or out of scope. So during the development phase, it helps reduce discussion.
Describe how the project is extensible in future.
(optional, Project Categories: Integration & Testing)
- Specify testing and integration like interoperability, scalability, high availablity
* What QA and test resources will be available?
(optional, Project Categories: Documention)
- API Docs
* Functional block description
- Identify similar projects is underway or being proposed in OPNFV or upstream project
* Identify any open source upstream projects and release timeline.
* Identify any specific development be staged with respect to the upstream project and releases.
* Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
* If project is an integration and test, identify hardware dependency.
Committers and Contributors:
Names and affiliations of the committers
- Chaoyi Huang, Huawei ( firstname.lastname@example.org)
- Xiaolong Kong, Orange (email@example.com)
- Gerald Kunzmann (firstname.lastname@example.org)
- Ulrich Kleber (Ulrich.Kleber@huawei.com)
- Colin Tregenza Dancer (email@example.com)
Names and affiliations of any other contributors
- Morgan Richomme, Orange (firstname.lastname@example.org)
- Dimitri Mazmanov, Ericsson (email@example.com)
- Ashiq Khan (firstname.lastname@example.org)
- Zhipeng Huang, Huawei (email@example.com)
- Jianfeng Lai, Huawei (firstname.lastname@example.org)
- Ray, Smartscale Systems (email@example.com)
- Mike Godley, Intel (firstname.lastname@example.org)
- Jie Hu, ZTE (email@example.com)
- Described the project release package as OPNFV or open source upstream projects.
- NFV cloud multi-site use cases
- NFV cloud multi-site requirements
- Gaps for the current services of VIM (OpenStack), including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer
- Blueprint/specification to the services of VIM (OpenStack), including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer
- If project deliverable have multiple dependencies across other project categories, described linkage of the deliverables.
Proposed Release Schedule:
- When is the first release planned?
* Will this align with the current release cadence