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

OceanStor BCManager 6.5.0 eReplication User Guide 02

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).
FusionSphere VMs

FusionSphere VMs

This section introduces DR restrictions for protected objects FusionSphere VMs.

You must comply with version restrictions and limitations when implementing DR for a protected object. See the Table 1-13 and Table 1-15 before implementing DR for a FusionSphere VM.
Table 1-13  DR restrictions for FusionSphere VMs (in Non-OpenStack Architecture)

Object

Restriction

Compatibility

Supports FusionSphere of FusionSphere V100R005C00, FusionSphere V100R005C10, and FusionSphere V100R006C00.

For detailed information about FusionSphere VM compatibility, see the OceanStor BCManager 6.5.0 eReplication Compatibility List.
NOTICE:

The version of the FusionCompute in production enter and DR center must be consistent to make sure the remote DR to recover FusionSphere VM production services.

In the DR Star network scenario, when you create an FusionSphere protected group, only the storage with DR Star is supported (V3 series V500R007C20 and later versions, Dorado series V300R002C00 and later versions).

VMs

If a test network needs to be configured for the FusionSphere VM, the VM must meet the following restrictions:
  • The root directory of the operating system cannot be installed on the extended partition of the system disk.
  • The system disk partition of the operating system cannot be a RAID file system.
  • When the system disk partition of the operating system is a LVM file system, only the default logical volume named lv_root serves as the primary partition. In addition, only one partition can be configured for the volume group where the system disk resides. If a user disk needs to be added to the volume group where the system disk resides, you must partition the user disk before using the VM. Otherwise, the customized configuration cannot be performed for the VM that is newly deployed using the VM template.
NOTE:
The restrictions on VMs are applicable only to the Linux operating system.

Non-host-based replication DR

  • Public
    • DR can be implemented only for created (based or not based on templates), fully cloned, and template VMs.
    • This DR plan is not applicable to management VMs, linked clone VMs, and VMs using shared disks.
    • This DR plan is not applicable to VM peripherals, such as USB flash drives and GPUs.
    • This DR plan is not applicable to VMs using non-persistent disks.
    • This DR plan is not applicable to VMs using remote deployment manager (RDM) disks.
    • This DR plan is not applicable to VMs without NICs or VM disks.
  • FusionCompute
    • This DR plan is applicable to user VMs and VM templates provisioned by the FusionCompute.
    • FusionCompute is required to create datastores using storage resources provided by Fibre channel SAN, IP SAN, Advanced SAN, and FusionStorage. On the datastores, VMs are created. In addition, cluster, host, and port group resources can be provided externally. FusionCompute has interconnection users.
  • FusionManager
    • This DR plan is applicable to VMs that belong to the VDC and are provisioned by the FusionManager.
    • This DR plan is not applicable to applications in the FusionManager, non-VDC VMs, and VM templates.
    • FusionManager can be cascaded with FusionCompute to create VMs and provide network and security group resources externally via VPC users.
    • To implement DR for VMs provisioned by the FusionManager, you are advised to configure the network types at the production and DR sites consistently.

      Restrictions for restored VMs differ by network type. For details. see Table 1-14. Because the IP addresses of VMs may change after a DR switchover, the administrator needs to manually adjust the services on the VMs if the services are associated with IP addresses.

Host-based replication DR

  • Supported scenarios:

    This DR plan is applicable to VMs using virtual disks or FusionStorage disks.

  • Unsupported scenarios:
    • This DR plan is not applicable to VMs using hybrid disks (virtual and physical disks).
    • This DR plan is not applicable to linked clone VMs, FT VMs, PVS VMs, VM templates, and VMs using shared volumes, pass-through devices (such as USB flash drives, GPUs, and HBAs), remote devices (such as remote USB flash drives and remote CD-ROMs), and raw device mapping (RDM) disks.
    • This DR plan is not applicable to scenarios including VM migration as a whole and online/offline expansion of disks.
    • This DR plan is not applicable to memory volumes on VMs.
    • This DR plan is not applicable to incremental replication when a single disk is added.
    • This DR plan is not applicable to VMs using non-persistent disks.
    • This DR plan is not applicable to VMs without NICs.
    • This DR plan is not applicable to applications in the FusionManager, non-VDC VMs, and VM templates.
    • This DR plan cannot grantee data consistency between dependent VMs or applications. For example, it cannot be ensured that all Oracle RAC VMs are restored to the status at the same time point.
    • This DR plan cannot grantee data consistency between VMs of the same application instance. It cannot be ensured that VMs are restored to the status at the same time point.
  • Others:
    • VRG is one of the FusionCompute's component. Use a VRG that meets version requirements in FusionCompute.
    • When a system is switched from the production site to the DR site or switched back from the DR site to the production site (including planned switchover and failover), the existing VM snapshot chain is not switched together with the system. To be more specific, host-based replication-based DR replicates only latest data, excluding the snapshot chain.

DR operations

In the geo-redundant solution based on active-active (VIS) and asynchronous replication (SAN), when services are switched to the remote DR site, reprotection cannot be implemented.

Others

  • VM specifications are periodically synchronized between sites. When a DR switchover is in progress, the VM specifications at the DR site may be different from those at the production site. Therefore, you are advised to minimize VM specification changes.
  • Cache data may fail to be written into disks during LUN remote replication. As a result, data consistency cannot be guaranteed, and VMs may fail to start during the DR process.
  • When planning and deploying a DR environment, ensure that datastores in a cluster must be associated with all hosts in the cluster.
  • On the DR management page, a storage mapping needs to be added for the target storage to which VM data is migrated.
Table 1-14  Restrictions for FusionSphere VMs (in Non-OpenStack Architecture) of different network types after the DR

Network Type

Restriction

Static injection

  • The production site and the DR site are in the same network segment.

    If no VMs at the DR site are on this network segment, the network of VMs can be completely restored.

  • The production site and DR site are in different network segments.

    After VMs are restored, you need to manually configure IP addresses that are reassigned by the system for VMs. To query the reassigned IP addresses, click IP Address Usage in the virtual private cloud (VPC) network to which VMs belong.

Manually configured IP address

  • VMs of the production site and the DR site must be planned in different MAC address segments so that the original MAC address of a VM can be retained after a DR switchover. In this manner, the manually configured IP address of the VM will not be lost.
  • If a VM's MAC address conflicts, it will be assigned to a new MAC address and its manually configured IP address will be lost.

External DHCP

After VMs are restored, IP addresses are not controlled by the DR system but assigned by an external DHCP server.

Internal DHCP

  • The production site and the DR site are in the same network segment.

    If no VMs at the DR site are on this network segment, the network of VMs can be completely restored.

  • The production site and DR site are in different network segments.

    IP addresses of the VMs are automatically reassigned.

Table 1-15  DR restrictions for FusionSphere VMs (in OpenStack Architecture)

Object

Restriction

Compatibility

  • Supports FusionSphere V100R006C00 and FusionSphere V100R006C10.
  • OceanStor V3 series and FusionStorage storage systems are supported.

DR protection

  • DR can be implemented only for created (based or not based on templates), fully cloned, and template VMs.
  • This DR plan is not applicable to VM peripherals, such as USB flash drives and GPUs.
  • This DR plan is not applicable to VMs without NICs or VM volume.
  • DR cannot be implemented for VMs that use linked clone volumes.

Others

  • When specifications of VMs at the production site are changed, synchronize the changes to the specifications of VMs at the DR site to maintain consistency. By doing this, DR services can run properly.
  • Silent VMs are not supported to ensure the data consistency of VMs and applications on these VMs. As a result, VMs or applications on VMs may be unable to start during DR.
  • One eReplication Server only can manage one OpenStack.
Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 13909

Downloads: 68

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