summaryrefslogtreecommitdiffstats
path: root/Scenario
diff options
context:
space:
mode:
authorfuqiao <fuqiao@chinamobile.com>2015-11-25 10:11:59 +0800
committerfuqiao <fuqiao@chinamobile.com>2015-12-15 11:19:35 +0800
commit197313b46e5e1b21f71ff5e264f43a284ac20dbe (patch)
treeb17ddc628342dca5bd54a69ec0b9e1f0b357f6ed /Scenario
parent6d63f786a25688ff2033cb53f1932ec357b1c5df (diff)
Scenario analysis doc - general issues for VNF HA
Scenario Analysis doc - general issues for VNF HA JIRA:HA 15 Change-Id: I8dff0d1120ac4f5046f678667204cb6bc80d761e
Diffstat (limited to 'Scenario')
-rw-r--r--Scenario/scenario_analysis_multi_site.rst70
1 files changed, 0 insertions, 70 deletions
diff --git a/Scenario/scenario_analysis_multi_site.rst b/Scenario/scenario_analysis_multi_site.rst
deleted file mode 100644
index 016fe58..0000000
--- a/Scenario/scenario_analysis_multi_site.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-5, Multisite Scenario
-====================================================
-
-The Multisite scenario refers to the cases when VNFs are deployed on multiple VIMs.
-There could be two typical usecases for such scenario.
-
-One is in one DC, multiple openstack cloud are deployed. Taking consideration that the
-number of compute nodes in one openstack cloud are quite limited (nearly 100) for
-both opensource and commercial product of openstack, multiple openstack cloud will
-have to be deployed in the DC to manage thousands of servers. VNFs in such DC should
-be possible to be deployed accross openstack cloud.
-..[MT] Do we anticipate HA VNFs that require more than 100 VMs so that they need to
-be deployed across DCs? Or the goal is to provide higher availability by deploying
-across DCs?
-..[fq] Here I just try to explain what multisite scenario means. I don't think HA should
-be discussed in this scenario since as you said, we can not have 100 more VMs deployed
-to be HA.
-
-The other typical usecase is geographic redundancy. GR deployment is to deal with more
-catastrophic failures (flood, earthquake, propagating software fault, and etc.) for one site.
-In the Geographic redundancy usecase, VNFs are deployed in two sites, which are
-geographically seperated and are managed by seperate VIM. When such a catastrophic
-failure happens, the VNFs at the failed site can failover to the redundant one so as to
-proceed the service.
-..[MT] I agree and this scenario is definitely not limited to HA VNFs. Thus there could
-be different mechanisms for the state replication between the sites and from an HA
-perspective in this case it is important that the replication mechanism does not degrade
-the performance at normal behaviour.
-
-The multisite scenario is also captured by the Multisite project, in which specific
-requirements of openstack are also proposed for different usecases. However,
-the multisite project mainly focuses on the requirement of these multisite
-usecases on openstack. HA requirements are not necessarily the requirement
-for the approaches discussed in multisite. While the HA project tries to
-capture the HA requirements in these usecases.
-https://gerrit.opnfv.org/gerrit/#/c/2123/
-https://gerrit.opnfv.org/gerrit/#/c/1438/.
-
-
-An architecure of stateful VNF with redundancy in the multisite scenario can be as
-follows. Architecture for the other cases can be worked out accordingly.
-https://wiki.opnfv.org/_detail/stateful_vnf_in_multisite_scenario.png?id=scenario_analysis_of_high_availability_in_nfv
-..[MT] What is the relation of the VMs of a single site e.g. on the left hand side?
-Do they collaborate? Do they protect each other? What makes the two VIMs independent
-if they need to support that VNF and its VNFM? Could they be logically the same
-VIM and wouldn't that be a better solution for the VNF?
-..[fq] This is kind of architecture captureed from the multisite project's work.
-One VM on the left site is acting as the active VNFC, and the other VM at the right
-site is acting as the standby. I assume the two VIM are cooperate with each other
-under the control of the orchestrator. I am also thinking that if the two VMs contrled
-by one VIM would be a better solution. But apparently that is not the scenario for
-multisite, cause they are thinking multisite means you have multi openstack.
-
-
-Below listed the additinal labor and extra requirements of multisite comparing with
-the basic usecases.
-
-1, specific network support for the active/standby or active/active VNFs across VIM.
-
-In the multisite scenario, instances constructing the VNFs can be placed across VIM.
-This will introduce extra network support requirement. For example, heartbeat between
-active/standby VMs placed across VIM requires overlay L2 network. The IP address used
-for VNF to connect with other VNFs should be able to be floating across VIM as well.
-
-2, in the multisite scenario, a logical instance of VNFM should be put on multiple
-VIM to manage the instances of VNFs placed across the VIM.
-
-3, in the VM failure scenarios, recovery of failed VM requires interface between
-VNFM and the VIM. In the multisite scenario, the VNFM should have knowledge of
-which VIM it should communicate with so as to recover the failed VNF. \ No newline at end of file