No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

FusionCloud 6.3.1.1 Solution Description 04

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Implementation Principles

Implementation Principles

Logical Architecture

This section describes CSHA components and their positions in the system architecture layer by layer.

Figure 25-3 shows the logical architecture of CSHA.

Figure 25-3 Logical architecture of CSHA
Table 25-1 Component details

Type

Name

Description

Console

CSHA

CSHA management console.

Service

BCManager eReplication

CSHA service system, which receives requests from the CSHA management console.

Management domain

Operation Plane

Provide operation management for CSHA, such as quota, metering and so on.

OM Plane

Provide operation and maintenance management for CSHA, such as alarm, log and so on.

IAM

Provides identity and access management for CSHA.

Service Flow

  • Figure 25-4 shows the workflow of applying CSHA.
    Figure 25-4 Service flow of applying CSHA
    1. A VDC operator applies for an ECS HA service instance on the ManageOne operation plane.
    2. After receiving the task of creating DR protection, BCManager Replication invokes Nova API to query the number of volumes mounted to ECSs in AZ1.
    3. BCManager eReplication invokes Cinder API to create a HyperMetro secondary volume on the corresponding HyperMetro storage device, and query the capacity of volumes mounted to ECSs in AZ1 and obtains the corresponding storage device information.
    4. BCManager eReplication invokes DRExtend API to create HyperMetro pairs between the primary and secondary volumes. Add all HyperMetro pairs in the service instance to the HyperMetro consistency group.
    5. BCManager eReplication invokes Nova API to unmount the system volumes of ECSs in AZ2.
  • Figure 25-5 shows the workflow of fault recovery of CSHA.
    Figure 25-5 Service flow of fault recovery
    1. BCManager eReplication invokes Neutron API to uninstall the network card of production cloud server.
    2. BCManager eReplication invokes Nova API to close the production cloud serve.
    3. BCManager eReplication invokes DRExtend API to perform the failover of consistency group.
    4. BCManager eReplication invokes Nova API to configure DR server, and removes the placeholder tag of DR server.
    5. BCManager eReplication invokes Cinder API to mount the disk of DR server to DR server.
    6. BCManager eReplication invokes Neutron API to mount the network card to DR server.
    7. BCManager eReplication invokes Nova API to start DR server.
    8. BCManager eReplication remaps the protection group.
Translation
Download
Updated: 2019-10-23

Document ID: EDOC1100063247

Views: 66455

Downloads: 182

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next