diff options
Diffstat (limited to 'Scenario_2/scenario_analysis_multi_site.rst')
| -rw-r--r-- | Scenario_2/scenario_analysis_multi_site.rst | 22 |
1 files changed, 8 insertions, 14 deletions
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/. |