diff options
author | csatari <csatari@localhost.localdomain> | 2016-05-24 10:34:35 +0200 |
---|---|---|
committer | Gerrit Code Review <gerrit@172.30.200.206> | 2016-06-17 15:09:34 +0000 |
commit | 673bf398bf6bf74f40aa8a41d8aa25e265fab9de (patch) | |
tree | e78db0cbd7dd70d6a95f48d64d2db417716de5c7 /docs/requirements/use_cases/georedundancy_cells.rst | |
parent | 2e3f87a33ced07760058e1a6f8dff5b8d62ca65e (diff) |
Separating the georedundancy use cases to separate files.
Small corrections to both georedundancy and progamable provisioning.
Change-Id: I8ec6eeece4cb94f5aae230ef1d25a1bb76fc9db4
Signed-off-by: csatari <gergely.csatari@nokia.com>
Diffstat (limited to 'docs/requirements/use_cases/georedundancy_cells.rst')
-rw-r--r-- | docs/requirements/use_cases/georedundancy_cells.rst | 65 |
1 files changed, 65 insertions, 0 deletions
diff --git a/docs/requirements/use_cases/georedundancy_cells.rst b/docs/requirements/use_cases/georedundancy_cells.rst new file mode 100644 index 0000000..23fcb8d --- /dev/null +++ b/docs/requirements/use_cases/georedundancy_cells.rst @@ -0,0 +1,65 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Georedundancy: Connection between different OpenStack cells +----------------------------------------------------------- +Georedundancy refers to a configuration which ensures the service continuity of +the VNF-s even if a whole datacenter fails [Q: Do we include or exclude VNF +pooling?]. + +This can be achieved by redundant VNF-s in a hot (spare VNF is running its +configuration and internal state is synchronised to the active VNF), +warm (spare VNF is running, its configuration is synchronised to the active VNF) +or cold (spare VNF is not running, active VNF-s configuration is stored in a +database and dropped to the spare VNF during its activation) standby state in a +different datacenter from where the active VNF-s are running. +The synchronisation and data transfer can be handled by the application or the infrastructure. +In all of these georedundancy setups there is a need for a network connection +between the datacenter running the active VNF and the datacenter running the +spare VNF. + +In case of a distributed cloud it is possible that the georedundant cloud of an application +is not predefined or changed and the change requires configuration in the underlay networks. + +This set of georedundancy use cases is about enabling the possiblity to select a datacenter as +backup datacenter and build the connectivity between the NFVI-s in the +different datacenters in a programmable way. + +Description +^^^^^^^^^^^ +There should be an API to manage the infrastructure-s networks between two +OpenStack cells. +(Note: In the Mitaka release of OpenStack cells v1 are considered as, cells v2 +functionaity is under implementation) + +- Maybe the existing capability of Neutron to have several subnets associated + to an external network is enough? + +Requirements +^^^^^^^^^^^^ + - Possibility to define a remote and a local endpoint + - As in case of cells the nova-api service is shared it should be possible + to identify the cell in the API calls + +Northbound API / Workflow +""""""""""""""""""""""""" + - An infrastructure network management API is needed + - When the endpoints are created neutron is configured to use the new network. + (Note: Nova networking is not considered as it is deprecated.) + + +Data model objects +"""""""""""""""""" + - TBD + +Orchestration +""""""""""""" + - TBD + +Dependencies on compute services +"""""""""""""""""""""""""""""""" + None. + +Potential implementation +"""""""""""""""""""""""" + - TBD |