From eeafc6f9a240099d4c190c47b637e34296e5770f Mon Sep 17 00:00:00 2001 From: fuqiao Date: Mon, 21 Dec 2015 16:45:01 +0800 Subject: Scenario Analysis doc - multisite scenario Scenario Analysis doc - multisite Scenario JIRA:HA-18 Change-Id: I74b51e91fcfed3a689945e8a86f6f5648aac00ba --- Scenario_2/scenario_analysis_multi_site.rst | 51 +++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Scenario_2/scenario_analysis_multi_site.rst (limited to 'Scenario_2') diff --git a/Scenario_2/scenario_analysis_multi_site.rst b/Scenario_2/scenario_analysis_multi_site.rst new file mode 100644 index 0000000..b9df8d0 --- /dev/null +++ b/Scenario_2/scenario_analysis_multi_site.rst @@ -0,0 +1,51 @@ +5, Multisite Scenario +==================================================== + +The Multisite scenario refers to the cases when VNFs are deployed on multiple VIMs. +There could be three typical usecases for such scenario. + +One is in one DC, multiple openstack clouds are deployed. Taking into 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 clouds will +have to be deployed in the DC to manage thousands of servers. In such a DC, it should +be possible to deploy VNFs accross openstack clouds. +..(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. + +Another typical usecase is Geographic Redundancy (GR). GR deployment is to deal with more +catastrophic failures (flood, earthquake, propagating software fault, and etc.) of a single site. +In the Geographic redundancy usecase, VNFs are deployed in two sites, which are +geographically seperated and are deployed on NFVI 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 continue the service. Different VNFs may have specified +requirement of such failover. Some VNFs may need stateful failover, while others +may just need their VMs restarted on the redundant site in their initial state. +The first would create the overhead of state replication. The latter may still +have state replication through the storage. Accordingly for storage we don't want +to loose any data, and for networking the NFs should be connected the same way as +they were in the original site. We probably want also to have the same number of +VMs on the redundant site coming up for the VNFs. +..(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 other usecase is the maintainance. When one site is planning for a maintaining, +it should first replicate the service to another site before it stops them. Such +replication should not disturb the service, nor should it cause any data loss. In +such case, the multisite schemes may be used. + +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/. + + -- cgit 1.2.3-korg From 3ae95a32c1ad82473e1658dd9753cae15b634d5a Mon Sep 17 00:00:00 2001 From: fuqiao Date: Mon, 18 Jan 2016 16:27:52 +0800 Subject: Scenario Analysis doc - multisite scenario Scenario Analysis doc - multisite Scenario JIRA:HA-18 : Change-Id: I3df017ec31325afab8dfde7d56bbb013d460acbb --- Scenario_2/scenario_analysis_multi_site.rst | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-) (limited to 'Scenario_2') diff --git a/Scenario_2/scenario_analysis_multi_site.rst b/Scenario_2/scenario_analysis_multi_site.rst index b9df8d0..2e43471 100644 --- a/Scenario_2/scenario_analysis_multi_site.rst +++ b/Scenario_2/scenario_analysis_multi_site.rst @@ -1,4 +1,4 @@ -5, Multisite Scenario +6, Multisite Scenario ==================================================== The Multisite scenario refers to the cases when VNFs are deployed on multiple VIMs. @@ -9,12 +9,7 @@ number of compute nodes in one openstack cloud are quite limited (nearly 100) fo both opensource and commercial product of openstack, multiple openstack clouds will have to be deployed in the DC to manage thousands of servers. In such a DC, it should be possible to deploy VNFs accross openstack clouds. -..(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. + Another typical usecase is Geographic Redundancy (GR). GR deployment is to deal with more catastrophic failures (flood, earthquake, propagating software fault, and etc.) of a single site. @@ -29,22 +24,21 @@ have state replication through the storage. Accordingly for storage we don't wan to loose any data, and for networking the NFs should be connected the same way as they were in the original site. We probably want also to have the same number of VMs on the redundant site coming up for the VNFs. -..(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 other usecase is the maintainance. When one site is planning for a maintaining, it should first replicate the service to another site before it stops them. Such -replication should not disturb the service, nor should it cause any data loss. In -such case, the multisite schemes may be used. +replication should not disturb the service, nor should it cause any data loss. The +service at the second site should be excuted, before the first site is stopped and +began maintenance. In such case, the multisite schemes may be used. 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. +capture the HA requirements in these usecases. The following links are the scenarios +and Usecases discussed in the Multisite project. https://gerrit.opnfv.org/gerrit/#/c/2123/ https://gerrit.opnfv.org/gerrit/#/c/1438/. -- cgit 1.2.3-korg