Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
By using the management interface in the HI GIO cloud site, organization administrators create the server side of the L2 VPN session, enabling the L2 stretch of one or more networks across the on-premises site.
Step 1: Log in to HI GIO Portal
Select Network > Edge Gateways > VPC name
Step 2: Under Services, click L2 VPN > NEW to open L2 VPN Tunnel window.
On Choose Session Mode, select Server > click Next.
Enter a name and pre-shared key > NEXT
VLAN & Port groups will be created on vDistributed Switch.
This short manual guide is intended to assist HI GIO users in understanding the features and benefits of our DRaaS offering. In this guide, you will find step-by-step instructions for setting up your disaster recovery environment, best practices for maintaining your recovery plans, and tips for testing and optimizing your DRaaS strategy.
Before running the replicated VM's Recovery, we must configure a Failover Network on APP1.
Step 1: Log in to HI GIO Availability.
Step 2: Select Incoming Replications > select vAPP1 > ALL ACTIONS > Recovery settings.
During on-premises to the cloud migrations, stretch the on-premises networks across the HI GIO cloud site to allow network connectivity between already migrated and not yet migrated virtual machines in the same network segment.
Layer 2 VPN (L2 VPN) stretches the L2 networks across the sites.
Prerequisites:
Procedure: To complete the L2 stretch, we follow the steps:
Partial failover is necessary when your DC (on-premises site) is still up and running but only one (or a subset) of your servers, applications, or virtual machines (VMs) is experiencing problems.
In this scenario, a complete site failover is unnecessary. Partial failover allows you to run the corrupted systems at the DR site (HI GIO cloud) while the rest of your functional systems keep running on your DC site (on-premises site).
Disaster scenarios almost always strike unexpectedly. In a disaster event, it is critical to restore the infrastructure of your business as soon as possible before any significant damage is done.
Failover and failback can help ensure that your business continues functioning properly, even if the DC site is affected by a disaster.
Enter the IP address for the Local IP, remote IP, Initiation Mode > NEXT
- Select Networks > NEXT
These networks were created in the preparation phase.
Review and click FINISH.
Waiting some minutes.
Once complete, we can see tunnel IDs (use it for manual configure on NSX autonomous edge)
And copy Peer code (use it for manual configure on NSX autonomous edge)
Remark
1
Management
137
For NSX Autonomous Edge management
2
Uplink
138
For NSX Autonomous Edge uplink
3
Trunk
140, 141, 142
Stretch L2 network traffic
Network settings for NSX Autonomous Edge.
#
OVF Template Name
Port Group
Primary Node
Second Node (optional)
Remark
1
Network 0
Management
Public IP address:
On-premises Public IP
HI GIO's Public IP
<IP Address>
<IP Address>
#
Port Group
VLAN
We provide HI GIO DRaaS for all enterprises who need to initiate secure data replication to another region, such as on-premises to HI GIO Cloud, HI GIO Cloud Ho Chi Minh to HI GIO Cloud Hanoi, or vice versa by setting up HI GIO DRaaS on their resource servers. Furthermore, the RPO has a minimum value of 5 minutes, which suits their critical system.
Step 3: In the Recovery settings window > click the Nics tab > vAPP1
Step 4: Assign a network that fits with HI GIO's network > APPLY
On-premises Site: fulfill VLAN, IP address, port groups, and Public IP.
HI GIO site: Public IP, networks.
On-premises VMs must connect to VLAN-backed networks configured on Distributed Switches
(Standard Switch is NOT supported).
After migrating over the workload to On-Premises, we can reverse the replication and reprotect it back to the HI GIO Cloud site.
Once reprotect is successful, this will show as outgoing replication from On-Premises to the Cloud.
Step 1: Log on to the HI GIO portal.
Step 2: Expand More > Click on Availability ()
Step 3: Click on Outgoing Replications >Check the checkbox for vAPP1 > Expand ALL ACTIONS
Step 4: Click on Reverse
Step 5: Click on REVERSE
The reverse from On-Premises to HI GIO Cloud Is In Progress
Reverse from On-Premises to Cloud Completed Successfully. Outgoing Replications is empty now.
You can find the protected jobs on the jobs on-premises site.
After creating the protection job\reverse job on HI GIO cloud (by provider account), you cannot see these jobs on-premises site.
Solution: Change the owner of these jobs to a tenant organization
Virtual Machine disk consolidation is needed.
Migrating back VMs from HI GIO cloud to on-premises made VMs warn - virtual machine disk consolidation is needed.
Solution: consolidate for VMs
The issue with the Windows server - lost trust relationship after migrating VM to HI GIO cloud or migrating back to on-premises.
Solution: Follow this guide to resolve it
Tip. You can configure the maximum computer password age using the Domain member: Maximum machine account password age policy under Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options. A computer password lifetime may last from 0 to 999 days (30 days by default);
Since the VM is successfully replicated from Cloud to On-Prem, we will migrate the VM APP1, DB1 from HI GIO Cloud back to On-Prem.
Step 1: Log on to the HI GIO portal.
Step 2: Expand More > Click on Availability ()
This short manual guide is designed to help HI GIO users navigate
How to install vCDA On-Premises
How to complete the vCDA Configuration Wizard
Once the NSX Autonomous Edge appliance is deployed in the on-premises site, the On-Premises to Cloud Director Replication Appliance starts managing the NSX Autonomous Edge after you register it on-premises.
To complete the L2 stretch configuration entirely by using the management interface of the On-Premises to , after deploying the NSX Autonomous Edge in the on-premises site, you register it by using the On-Premises to Cloud Director Replication Appliance.
Step 1: Log in to the management interface of the VMware Cloud Director Availability On-premises Appliance.
In a Web browser, go to .
After configuring the networks of the NSX Autonomous Edge, by using On-Premises to Cloud Director Replication Appliance create the client side of the L2 VPN session, stretching one or more networks across the cloud site.
Step 1: Log in to the management interface of the VMware Cloud Director Availability On-premises Appliance.
In a Web browser, go to .
Log in as the root user.
After the on-premises site has recovered from the issue and is available, we can migrate the workload (APP1, DB1) from the HI GIO cloud back to on-premises by reversing the replication.
Step 1: Log on to the HI GIO portal.
Step 2: Expand More > Click on Availability ()
192.168.137.79
192.168.137.80
2
Network 1
Uplink
192.168.138.77
–
must to have access to internet
3
Network 2
Trunk
–
–
4
Network 3
– (HA, optional)
192.168.137.81
192.168.137.82
Since the replication is configured from On-Premises to Cloud, we will view Incoming Replications.
Select Incoming Replications. Here, you will notice VM APP1-xxxx is replicated back from On-Premises to Cloud, and the Replication type is On-Premise Protection.
Verify replication status from the On-Premises site
Expand Menu > Click on Cloud Provider DR and Migration.
Click on Outgoing Replications.
Confirm VM APP1-xxxx & DB1-xxxx is replicated back from On-Premises to Cloud and Replication type is Protection.
Step 3: Click on Outgoing Replications > Check the checkbox for vAPP1 > Expand ALL ACTIONS > Click on Migrate
Step 4: Configure Migrate Settings. Leave the Defaults and Click on NEXT
Step 5: Review the Migration Settings and click on FINISH
Migration in Progress
Migration to on-premises is Completed Successfully. Confirm that:
- Recovery state = Failed-Back
- Replication type = On-Premise Protection
- Overall health = Green
Confirm VMs migrated back to On-premises.
VM APP1-xxxx, DB-xxxx now show up in the vCenter's inventory
Login to APP1 & DB1 by local account > change the IP address to fit with the on-premise site (in my case, I just changed the default gateway to .1) and validate the application.
vCenter Requirements. 6.5U3, 6.7U3, 7.0 (GA-U3), 8.0 (GA, U1). (We also support vCenter 6.0U3, 5.5U3 only for migration purpose)
Network Requirements. To get a list of the required firewall ports to be opened, see VMware Cloud Director Availability Network Ports.
Hardware Requirements. From a hosting perspective, the VMware Cloud Director Availability On-Premises Appliance is a virtual machine with the following hardware requirements
4 vCPUs
4 GB RAM
10 GB Storage
Deployment Requirements. In ESXi hosts, a VMkernel interface can be dedicated for the replication traffic. By default, ESXi handles the replication traffic through its management VMkernel interface. As a best practice, you can separate the management traffic from the replication traffic by creating a dedicated VMkernel interface. Use following tags when creating a VMkernel interface for the replication traffic
Use the vSphere Replication tag to configure the ESXi host for the Outgoing Replication Traffic
Use the vSphere Replication NFC tag to configure the ESXi host for the Incoming Replication Traffic
Configure the replication VMkernel interface in its own IP subnet and connect the VMware Cloud Director Availability On-Premises Appliance to the same virtual port group. Using this configuration, the replication traffic between the ESXi hosts and the VMware Cloud Director Availability On-Premises Appliance stays in the same broadcast domain. As a result, uncompressed replication traffic avoids crossing a router and saves the network bandwidth
The tenant deployment process is similar to all typical VMware OVF deployments. The tenant must install the vCloud Availability On-Premises Appliance OVA into the vCenter.
Please download OVA file from this link
VMware-Cloud-Director-Availability-On-Premises-4.5.0.5226630-ab9eb01ccb_OVF10.ova
Once downloaded, log into your vSphere Client and Deploy OVF Template
Select an OVF template. Install from a local file. Browse to the location of the previously downloaded OVA. Select the vCDA OVA file and click Next
Select a name and folder. Type in your desired virtual machine (appliance) name. Next, select a location for your virtual machine
Select a compute resource. Choose a host or a cluster for the appliance. Click Next
Review details. This is a chance for you to evaluate and verify the template
License agreement. Check the I accept all license agreements checkbox and click Next
Select storage. Configure optional storage options for the deployment and click Next
Select networks. Choose a destination network for every individual source network
Customize template. During this step of the wizard, customize the deployment
Root Password. Defining a root password is mandatory. However, you will need to change it when you log in to vCDA for the first time. So, you don’t need to define a very strong password at this point
Enable SSH. Select the Enable SSH checkbox
NTP Server. Enter the NTP server address the vCDA appliance will use. vCenter Server, ESXi, vCloud Director, Platform Services Controller, and the vCloud Availability appliance MUST all use the same NTP server
Log in to your vCDA appliance at https://your-appliance-IP/ui/admin. Use the root/password defined during OVA deployment
Change the root password. Set and confirm a new password. Create a strong password with at least eight (8) characters. Make sure to use lowercase, uppercase, numeric, and special characters.
To get started, you will need to configure a Lookup Service Endpoint. To do so, select Run Initial Setup Wizard
Lookup Service. Enter your connection details to set up the lookup service along with SSO admin credentials
Lookup service address. Type in the following URL, adding the IP address of your vCenter: https://Ip-of-your-vcenter:443/lookupservice/sdk
Enter SSO admin account credentials in the Username and Password field
Site Details. In it, type your Site Name and optionally, a short Description about the site. Click Next
Proceed to the configure Cloud Details by pairing up your vCloud and vCDA sites
Service Endpoint Address, Organization Admin and Organization Password is provided by HI GIO Support
Configure your organization’s credentials for logging in to the cloud site. Type in Organization Admin (user@org) and Organization Password
Optional: Select Allow Access from Cloud. If you select this feature, the cloud provider and organization administrators can access and perform certain operations through the vCloud Availability Port
Click Next and accept the SSL certificate of the vCenter Server Lookup to continue
Move on to Ready to Complete. It shows the details you have provided in the previous steps. Verify that everything is accurate
Check Configure local placement now to enable cloud to datacenter replications. Leaving the box unchecked requires additional set up to configure the replications
Step 2: In the left pane, under the System section click L2 Stretch.
Step 3: On the NSX Autonomous edges page, click New.
Step 4: Register a New NSX Autonomous Edge window, register the new NSX Autonomous Edge with the On-Premises to Cloud Director Replication Appliance.
Enter a friendly name for the new NSX Autonomous Edge in the Name text box.
From the vCenter Server drop-down menu, select the vCenter Server instance hosting the NSX Autonomous Edge virtual machine.
Under NSX Autonomous Edge VMs, select the virtual machine of the newly deployed NSX Autonomous Edge.
In the Management Address text box, enter the URL for the NSX Autonomous Edge management.
In the User name and Password text boxes, enter the admin user credentials for the NSX Autonomous Edge management.
(Optional) In the Description text box, enter a description for this NSX Autonomous Edge.
-To register the NSX Autonomous Edge for management, click REGISTER.
NSX Autonomous Edge will show up once completed.
Step 5: On the NSX Autonomous edges page, select deployed NSX Autonomous Edge instance & Click EDIT NETWORK
Select the network adapters of the NSX Autonomous Edge > click Apply.
Step 6: On the NSX Autonomous edges page, select deployed NSX Autonomous Edge instance > Click Configure the uplink port.
Enter the settings for the external network port > click Apply.
Step 2: In the left pane, under the System section, click L2 Stretch.
Step 3: On the NSX Autonomous edges page, click L2 VPN Sessions > NEW
Step 4: If your user session is not currently extended to the cloud site, enter credentials to authenticate to the cloud site.
Step 5: Select the cloud site virtual data center and the edge gateway on the VDC and edge Gateway page.
Step 6: On the Settings and networks page, configure the L2 VPN and click Next.
In the Name text box, enter a name for this client L2 VPN session.
From the Server session drop-down menu, select the cloud side L2 VPN server session.
In the Local Address text box, enter the on-premises IP address at the client side of the L2 VPN session. The local IP address must be the same as the uplink port IP address of the NSX Autonomous Edge hosting the client L2 VPN session.
In the Remote Address text box, enter the HI GIO public IP address at the server side of the L2 VPN session.
Under the Client Network column, to create an L2 stretch across the networks select an on-premises VLAN network.
Step 7: On the Ready To Complete page, review and click FINISH.
>>> The client L2 VPN session on-premises is created and the L2 stretch across the cloud site is complete.
*** Test Connectivity
Ping to Gateway (on-prem) from HI GIO.
Ping to HI GIO’s VM (same VLAN\difference VLAN) from on-prem.
Step 3: Click Incoming Replications > Check the checkbox for vAPP1 > Expand ALL ACTIONS > Click on Reverse.
You can also select individual VMs in this step.
Step 4: Confirm Reverse Replication from HI GIO Cloud to on-prem. Click REVERSE.
Step 5: Expectation result:
Reverse Replication is in progress. You can monitor the progress of the Reverse task in the Last changed section and replicate the state.
Reverse Replication is Completed. Here, APP1 & DB1 are replicated back to On-Prem, and the Recovery State is Reversed.
This short manual guide is designed to help HI GIO users navigate
How to create a Migration Job
How to create a Protection Job
How to Test Failover, Failover, Reverse, or Migrate
Configuring a migration allows later migrating a vApp or a virtual machine to a remote organization and running the workload in the destination site
The target recovery point objective (RPO) for a migration is 24 hours
If you log in to VMware Cloud Director Availability On-Premises Appliance, then :
Step 1: Log in to vCenter, Expand Menu > Click on Cloud Provider DR and Migration
Step 2: Click on Outgoing Replications > New Protection
Step 3: Enter credential of Organization > LOGIN
Step 4: On Source VMs windows:
- Enable Group VMs to a single vApp.
- Select APP1 & DB1.
- Click NEXT
Step 5: On vApp Settings
- Enter vApp name: vAPP1
- Set: start wait time
- Click NEXT
Step 6: Select destination VDC & storage policy > NEXT
Step 7: Select SLA profile > NEXT
Step 8: Review > FINISH
Step 9: Expectation result
Confirm the Replication is started. You can monitor the % progress here
Replication state completed. Confirm that:
Use this step when your primary infrastructure (on-premise) is running well. After this step:
- Workload is on the HI GIO cloud site.
- Source workload is powered off.
Step 1: Log on to the HI GIO portal.
Step 2: Expand More > Click on Availability ()
Step 3: Click on Incoming Replications > Check the checkbox for VM APP1 > Expand ALL ACTIONS > Click on Migrate
Step 4: Configure Recovery Settings for Migrate
- Instances handing after recovery: Default.
- Power Settings: Power on recovered vApps.
- Network Settings: Apply preconfigured network settings on migrate (configured in step2)
- Click NEXT
Step 5: Review and click FINISH
Step 6: Expectation result:
Failover in Progress: You will notice Migrate in Progress with % progress in the Detailed Status.
Once the migration task is completed, confirm on
Step 1: Log on to the HI GIO portal: select vAPP1 > Virtual machines.
Step 2: Confirm that VM APP1 was migrated to HI GIO and powered on.
On-premises sites or the client’s L2 VPN require a specially configured VMware® NSX Edge™ appliance called autonomous edge. Deploy the NSX Autonomous Edge appliance using an OVF file on the ESXi host.
The autonomous NSX Edge is straightforward to deploy and provides a high-performance VPN. The autonomous NSX Edge is deployed using an OVF file. You can also enable high availability (HA) for VPN redundancy by deploying primary and secondary autonomous Edge L2 VPN clients.
Please request the HI GIO team to get the OVF file.
Step 1: Log in to the vCenter Server.
Hostname. The hostname of VM
IP. IP address ( e.g. 192.168.1.186/24 )
Gateway. Gateway address
MTU. MTU ( e.g. 1500 )
DNS Server. IP DNS Server. It needs to resolvable the domain name of vCenter Server and Service Endpoint
Search Domains. List of search Domains ( e.g. abc.local )
Ready to complete. Review the settings. You can also select Power on after deployment. Click Finish to deploy the Appliance
If you leave this feature deselected, configuring new replications will only be accessible to users authenticated to the on-premises vCloud Availability Portal. Additionally, no existing replications will be reversed from the Portal
Service Endpoint Address, Organization Admin and Organization Password is provided by HI GIO Support
Outgoing Replications are replication and failover VM from the on-premises vCenter Server to a cloud site
Incoming Replications are replication and failover VM from the cloud site to the on-premises vCenter Server
If you login to VMware Cloud Director Availability Tenant Portal (provided by Services Provider) then :
Incoming Replications is replication and failover VM from the on-premises vCenter Server to a cloud site
Outgoing Replications are replication and failover VM from cloud site to on-premises vCenter Server or Cloud to Cloud
In the left pane, choose a Replication Direction – Choose Outgoing Replication – Create New Migration
Select the VMs you want to migration by checking the corresponding box(es). Click Next
On the Destination VDC and Storage policy page, select the virtual data center for the replication destination and the storage policy for placing the recovered virtual machines, and click Next.
On the Settings page, configure the following replication settings and click Next
To apply compression on the replication data traffic for reducing the network data traffic at the expense of CPU, leave Compress replication traffic selected
To start the replication when the wizard finishes, leave Delay start synchronization deselected. Alternatively, to schedule the start of the replication, select it and enter the local date and time for starting the replication
From the VDC VM placement policy drop-down menu, select an organization VDC placement compute policy for the recovered virtual machines
(Optional) To select specific hard disks of the virtual machines for replicating to the destination site for reducing the replication data network traffic, select Exclude disks
(Optional) To select a previous copy of the virtual machines in the destination site for reducing the replication data network traffic, select Configure Seed VMs
If you selected Exclude disks, on the Replicated Disks page select the virtual machine disks for replicating and click Next
On the Ready to complete page, verify that the replication settings of the migration are correct and click Finish
After the replication finishes, for the vApp and its virtual machines in the Replication type column, you see a Migration state
Configuring a protection allows protecting a vApp or a virtual machine from one organization to another, while keeping the workload running in the source site. If the source site is unavailable, after a successful replication you can fail over and power on the source virtual machine in the destination site
If you login to VMware Cloud Director Availability On-Premises Appliance then :
Outgoing Replications is replication and fail over VM from the on-premises vCenter Server to a cloud site
Incoming Replications is replication and fail over VM from cloud site to on-premises vCenter Server
If you login to VMware Cloud Director Availability Tenant Portal (provided by Services Provider) then :
Incoming Replications is replication and fail over VM from the on-premises vCenter Server to a cloud site
Outgoing Replications is replication and fail over VM from cloud site to on-premises vCenter Server or Cloud to Cloud
In the left pane, choose a Replication Direction – Choose Outgoing Replication – Create New Protection
Select the VMs you want to protect by checking the corresponding box(es). Click Next
On the Destination VDC and Storage policy page, select the virtual data center for the replication destination and the storage policy for placing the recovered virtual machines, and click Next.
To set the SLA settings of the replication, select any of the preconfigured SLA profiles. Click Next
From the VDC VM placement policy drop-down menu, select an organization VDC placement compute policy for the recovered virtual machines
(Optional) To select specific hard disks of the virtual machines for replicating to the destination site for reducing the replication data network traffic, select Exclude disks
To manually configure the SLA settings, select Configure settings manually
Target recovery point objective (RPO): If you selected Configure settings manually, set the acceptable period for which data can be lost if there is a site failure by using the slider or by clicking the time intervals. The available RPO range for a protection is from one minute to 24 hours
Retention policy for point in time instances: If you selected Configure settings manually, to preserve multiple rotated distinct instances to which the virtual machines can be recovered, select this option, select the number of replication instances to keep, and select the retention time distance and unit. The retention distance unit must be greater than RPO
Instances: Select how many rotated instances participate in the current retention rule. The total number of instances in this example matches the maximum of 24 rotated instances
Distance: Select the time distance that the rotated instances spread apart in the current retention rule
Unit: Select the time unit for spreading the rotated instances in the current retention rule. Select one from: Minutes – Hours – Days – Weeks – Months – Years
On the Ready to complete page, verify that the replication settings of the protection are correct and click Finish
Diagram for Replication State
Test Failover: By performing a test failover you can validate that the data from the source site replicates correctly in the destination site
In the left pane, choose a replication direction
Select the protected vApp or virtual machine to test the failover and click All actions > Test Failover
On the Recovery Settings page, configure the recovered workload and click Next
Power on recovered vApps: Select to power on the virtual machines in the destination site after the task completes
Network settings:
On the Recovery Instance page, configure the recovery point in time and click Next
Synchronize all VMs to their current state: Creates an instance of the power on workload with its latest changes and uses that instance for the test failover
Manually select existing instance: Select an instance without synchronizing the data for the recovered workload
On the Ready To Complete page, review the test details and click Finish
In the Last changed column, you can monitor the progress of the test. After the test finishes, for the vApp and its virtual machines in the Recovery state column you see a Test image ready state
To Delete the Test Failover results, select the replication to clean. Click All actions > Test Cleanup.
The Cleanup Deletes All recovered vApps and virtual machines
Perform a Failover Task: If the protected source site is unavailable, in the destination site perform a workload disaster recovery operation
Select the protected vApp or virtual machine to fail over and click All actions > Failover
In the Failover wizard, configure your selected workload for the failover
Consolidate VM disks: Select this option for a better performance of the recovered virtual machines at the expense of the failover task taking longer to complete
Power on recovered vApps: Select this option to power on the virtual machines on the destination site after the task completes.
On the Recovery Instance page, configure the recovery point in time and click Next
On the Ready To Complete page, review the task details and click Finish
After the failover task finishes, the failed over workload is running in the destination site and the workload is no longer protected upon the task completion. For the vApp and its virtual machines, in the Recovery state column you see a Failed-Over state
Perform a Reverse Task:
After performing failover or migration, return the workload data from the destination site back to the original source site by reversing the replication.
After failing over or migrating from the source site to the destination site, the workload runs on the destination site. A subsequent reverse task replicates the failed-over or migrated workload data back to the original source protected vApp or virtual machine
After the reverse task finishes, the reversed replication overwrites the source vApp or virtual machine. The reversed workload runs in the destination site with a workload protection in the original source site. For the vApp and its virtual machines, in the Recovery state column you see a Reversed state
Perform a Migrate Task: By migrating an existing replication to a remote organization, the workload runs in the destination site and the source workload is powered off
Select the protected vApp or virtual machine to migrate over and All actions > Migrate
On the Migrate Settings page, configure the recovered workload and click Next
All source vApps will be powered-off after successful recovery
Consolidate VM disks: Select this option for a better performance of the recovered virtual machines at the expense of the failover task taking longer to complete
On the Ready To Complete page, review the task details and click Finish
After a successful recovery, all source virtual machines are synchronized and then powered off. The migration completes when in the Recovery state column of the replication you see Failed-Over
A manual (offline) sync runs. If the source workload is powered on, then it is powered off and a manual sync runs. Then the vApp or virtual machines are recovered on the destination site
- Overall health = Green.
Confirm the Replication Status from HI GIO Cloud:
Log in to HI GIO Availability > Incoming Replications, select INSTANCES.
Confirm the vAPP1:
- Replication state = Healthy
- Overall Health = Green
APP1:
- Recovery state = Failed-Over,
- Replication Type = On-Premise Protection,
- Overall health = Green.
DB1:
- Recovery state = Not stated,
- Replication Type = On-Premise Protection,
- Overall health = Green.
Migrate completed successfully. The workload is running in the HI GIO cloud, and the workload is no longer protected.
Step 4: Expectation result:
The VM APP1 is running on the HI GIO site now. The VM is no longer protected.
The VM APP1 is power off on-premises - automatic by vCDA.
Step 2: Select Hosts and Clusters. To show the available hosts, expand the clusters.
Step 3: To deploy the NSX Edge, right-click the host where you want it and select Deploy OVF Template.
On the Select an OVF template page, to download and deploy the OVF file, paste the URL, or select a locally downloaded OVF file and click NEXT.
On the Select a name and folder page, Enter Virtual machine name & select a location for its > click Next.
Select the destination compute resource > click Next on the Select a compute resource page.
On the Review details page, verify the OVF package template details > click Next.
On the Configuration page, select a deployment configuration size (detail as below) > click Next.
Sizing for NSX Autonomous Edge VM
On the Select storage page: select a storage & select virtual disk format = Thin provision > click Next.
On the Select networks page, for all destination networks select the management network > click Next.
On the Customize template page, enter the following properties > click NEXT.
+ In the Application section, do the following:
Set the System Root User Password.
Set the CLI "admin" User Password.
Select the Is Autonomous Edge checkbox.
Leave the remaining fields empty.
+ In the Network Properties section, do the following:
Set the Hostname.
Set the Management Network IPv4 Address. This is the management IP for the autonomous edge.
Set the Management Network Netmask. This is the management network prefix length.
Set the Default IPv4 Gateway. This is the default gateway of the management network.
+ In the DNS section, do the following:
In the DNS Server list field, enter the DNS server IP addresses separated by spaces.
In the Domain Search List field, enter the domain name.
+ In the Services Configuration section, do the following:
Enter the NTP Server List.
Enter the NTP Servers, separated by spaces.
Select the Enable SSH checkbox.
Select the Allow Root SSH logins checkbox.
+ In the External section, do the following:
Enter the External Port details in the following format: VLAN_ID,Exit Interface,IP,Prefix Length.
For example: 138,eth2,192.168.138.77,24. Replace the following values:
VLAN ID: VLAN ID of the uplink VLAN
Exit Interface: interface ID reserved for uplink traffic
IP: IP address reserved for the uplink interface
Prefix Length: prefix length for the uplink network
In the External Gateway field, enter the default gateway of the uplink network.
+ (Optional) In the HA section, do the following:
Enter the HA Port details in the following format: VLAN_ID,Exit Interface,IP,Prefix Length.
For example: 137,eth2,192.168.137.81,24. Replace the following values:
VLAN ID: VLAN ID of the uplink VLAN
Exit Interface: interface ID reserved for uplink traffic
IP: IP address reserved for the uplink interface
Prefix Length: prefix length for the uplink network
In the HA Port Default Gateway field, enter the default gateway of the management network
Review the NSX Autonomous Edge settings > on the Ready to complete page> and click FINISH.
After the deployment completes, power on the NSX Autonomous Edge virtual machine.
Log in NSX autonomous via web browser:
If the protected site (on-premises) is unavailable. In the HI GIO cloud, you can perform a workload disaster recovery operation (full failover)
Step 1: Log on to the HI GIO portal.
Step 2: Expand More > Click on Availability ()
Step 3: Click on Incoming Replications > Check the checkbox for VM APP1 > Expand ALL ACTIONS > Click on Failover
Step 4: Configure Recovery Settings for Failover
- Instances handing after recovery: Default.
- Power Settings: Power on recovered vApps.
- Network Settings: Apply preconfigured network settings on migrating.
Click NEXT
Step 5: Configure Recovery Instance for Failover
Click SELECT LATEST FOR EVERY VM > NEXT
Step 6: Review and FINISH
Step 7: Expectation result:
Failover in Progress: In the Detailed Status, you will notice Failover in Progress with % progress.
Failover successfully: This process will take a couple of minutes. Please be patient.
In this scenario, on-premise has issues: network, hardware host, and storage… that make it not available.
Step 1: Log on to the HI GIO portal: select vAPP1 > Virtual machines.
Step 2: Confirm that 02 VMs, APP1 & DB1, were migrated to HI GIO and are running.
Optionally, use the following steps to deploy a secondary NSX-T Autonomous Edge (Layer 2 VPN client) in HA mode in your on-premises environment:
DC site has an issue - full failover
On-premises Site
(Optional) To select a previous copy of the virtual machines in the destination site for reducing the replication data network traffic, select Configure Seed VMs
Compress replication traffic: If you selected Configure settings manually, to apply compression on the replication data traffic for reducing the network data traffic at the expense of CPU, select this option
Delay start synchronization: If you selected Configure settings manually, choose the following option
To schedule the start of the replication, select this option and enter the local date and time to start the replication.
To start the replication when the wizard finishes, leave this option deselected.
VDC VM placement policy: Select an organization VDC placement compute policy for the recovered virtual machines
Exclude disks: To select specific hard disks of the virtual machines for replicating to the destination site for reducing the replication data network traffic, select this option
Configure Seed VMs : To select a previous copy of the virtual machines in the destination site for reducing the replication data network traffic, select this option
Create a Replication Seed: Use one of the following methods for creating a seed VM in the destination site
Offline data transfer: Export the VM as an OVF package into removable media and send it to Cloud service administrator imports the package to your cloud organization
Copy over the network: Copy a source VM to the cloud organization and transfer the source data to the destination site by using other means than VMware Cloud Director Availability (FTP, OneDrive, Google Drive, …)
On the Disks page you must select the hard disks to replicate and click Next
Select Apply preconfigured network settings on failover, to assign the network configured during the virtual machine replication
Select Connect all VMs to network and from the drop-down menu select a network to connect the replicated virtual machines to
Network settings:
Select Apply preconfigured network settings on failover, to assign the network configured during the virtual machine replication
Select Connect all VMs to network and from the drop-down menu select a network to connect the replicated virtual machines to
When reversing a replication from a cloud site back to an on-premises site, VMware Cloud Director Availability uses the original datastore for the placement of the workload, regardless of the current on-premises local placement setting
Select the vApp or the virtual machine that are failed-over and All actions > Reverse
In the Reverse window, to confirm the reversal click Reverse. Reversing the replication enables the replication traffic and allows the replication to be recovered back to the source
Power on recovered vApps: Select this option to power on the virtual machines on the destination site after the task completes.
Network settings:
Select Apply preconfigured network settings on failover, to assign the network configured during the virtual machine replication
Select Connect all VMs to network and from the drop-down menu select a network to connect the replicated virtual machines to
Medium size is suitable for normal use-case. If you don’t have special requirement, please use it.
NSX Edge core services do not start unless you enter passwords meeting these requirements:
At least 12 characters
At least one uppercase letter
At least one lowercase letter
At least one digit
At least one special character
At least five different characters
Confirm that all VMs in vAPP1:
- Recovery State = Failed-Over.
- Replication Type = On-Premise Protection
- Overall health = Green
Logon APP1 & DB1 by admin local > change default gateway and validate that APP1 & DB1 can be reachable.
Step 4: Point domain name to APP1 (public DNS record if needed).
Step 5: Access to APP1 via the internet (in my case, I used a public IP).
Network 0
Management
192.168.137.79
192.168.137.80
2
Network 1
Uplink
192.168.138.77
–
must to have access to internet
3
Network 2
Trunk
–
–
4
Network 3
– (HA, optional)
192.168.137.81
192.168.137.82
Step 1: Follow the steps in Deploy NSX Autonomous Edge (on-premises site) until you reach the Customize template step.
Step 2: On the Customize template step, do the following instead:
In the Application section, do the following:
Set the System Root User Password.
Set the CLI "admin" User Password.
Select the Is Autonomous Edge checkbox.
In the Network Properties section, do the following:
Set the Hostname.
Set the Management Network IPv4 Address. This is the management IP for the autonomous edge.
-Enter the HA Port details in the following format: VLAN_ID, Exit Interface, IP, Prefix Length.
For example: 137,eth2,192.168.137.81,24. Replace the following values:
VLAN ID: VLAN ID of the uplink VLAN
Exit Interface: interface ID reserved for uplink traffic
IP: IP address reserved for the uplink interface
Prefix Length: prefix length for the uplink network
-In the HA Port Default Gateway field, enter the default gateway of the management network
-Select the Secondary API Node checkbox.
-In the Primary Node Management IP field, enter the management IP address of the primary autonomous edge.
-In the Primary Node Username field, enter the username of the primary autonomous edge (for example, "admin").
-In the Primary Node Password field, enter the password of the primary autonomous edge.
-In the Primary Node Management Thumbprint field, enter the API thumbprint of the primary autonomous edge.
You can get this by connecting using SSH to the primary autonomous edge using admin credentials and running the command: “get certificate api thumbprint”
Step 3: Complete the remaining OVF template deployment steps to deploy the secondary autonomous edge (on-premises Layer 2 VPN client).
PowerOn the second NSX autonomous edge
Step 4: Validate:
It will take some minutes to sync.
Log in to both NSX autonomous nodes, check High Availability, L2VPN\
-Primary node:
-Secondary node:
-Port ID, Tunnel ID, exit interfaces are same on both nodes.
Step 5: Failover test:
To test the NSX autonomous failover:
-Ping from on-premises to HI GIO cloud.
-Shutdown NSX autonomous primary node
-Result:
NSX autonomous secondary status will change to ACTIVE, L2 VPN = UP
The connection drop ~ 5-10 seconds
#
OVF Template Name
Port Group
Primary Node
Second Node (optional)
Remark
1
IP Address
Note
1
vcsa7.lab.local
vCenter
192.168.137.77
2
vcda7.lab.local
VMware Cloud Director Availability On-premises
192.168.137.78
3
host16.lab.local
ESXi host
192.168.137.50
4
DC.lab.local
Primary Domain controller
192.168.137.200
HI GIO Site
No.
Item
Description
IP Address
Note
1
ASG000001-Customer01
Organizations
3. Environment System Configuration
#
App Name
Hostname
On-prem IP address
HI GIO's Network
HI GIO IP address
Remark
1
APP1
No.
Item
Description
2
ADC.lab.local
Secondary Domain controller
192.168.137.201
APP1.lab.local
192.168.140.14
[L2]VM140
192.168.140.14
2
APP1
DB1.lab.local
192.168.141.14
[L2]VM141
192.168.141.14
Set the Default IPv4 Gateway. This is the default gateway of the management network.
In the DNS section, do the following:
In the DNS Server list field, enter the DNS server IP addresses separated by spaces.
In the Domain Search List field, enter the domain name.
In the Services Configuration section, do the following:
Enter the NTP Server List.
Enter the NTP Servers, separated by spaces.
Select the Enable SSH checkbox.
Select the Allow Root SSH logins checkbox.
Leave External section empty.
In the HA section, do the following:
After powering on the NSX autonomous primary node, the HA status between the nodes was re-established. The secondary edge remains active, and the primary will become active only in case of additional failure.
NSX Edge core services do not start unless you enter passwords meeting these requirements:
At least 12 characters
At least one uppercase letter
At least one lowercase letter
At least one digit
At least one special character
At least five different characters
