GettingStartedWithVCDA

Preview

This practical sheet aims to show the implementation of VM replication between VDR and CHA, in order to achieve the PRA of an application.

The practical and pricing arrangements for this functionality are described on this page.

Prerequisites

Be an administrator of at least two VCD organizations on the NGP platform
Have completed the pairing of these two organizations (see this practical sheet for the procedure).

Les 2 vOrg sont appairées.

Detailed procedure (“step by step”) :

Connect to the VCDA portal from the VCD portal of the "source" organization, that is to say the one which contains the VMs to be replicated. Then go to the "Plus" (more) menu, and choose the Availability option. Here, as we are connected to the console1 portal, our VCDA site is called recovery1. See the VM Replication page for explanations of topology and VCDA sites.
The VCDA portal home page provides an overview of the active configuration. Here, nothing is configured, so the indicators are all 0.
The first thing to do is to configure the remote site, which will receive the VM replicas. We go to the Approved Sites (Sites homologués) menu and display the list of VCDA sites. As said just before, our VCDA site is named recovery1, it is our source site, on the organization cav01ev01ocb0005792. We want to replicate on CHA, so we will choose recovery4, and establish a connection.
We establish the connection between recovery1 and recovery4 for the two organizations cav01ev01ocb0005792 and cav02ev04ocb0006386 which have been paired (see the prerequisites).
Our 2 VCDA sites are connected. The connection remains valid for 30 minutes in the portal, for any replication configuration.
Now let's create an outgoing replication, i.e. from recovery1 to recovery4. We choose recovery4 as the destination site.
We then click on the icon to create a new protection.
A form then opens to guide us in configuring this protection. We choose the VMs that will be protected: here we have chosen the vApp named WPvApp, which contains 3 VMs. The top of the form contains buttons to filter the content to display. Once the selection is made, click on NEXT.
We then choose the destination vDC and the storage policy that will store our replicas. On our target org, we only have one vDC, with one storage policy.
We then choose the replication policy, depending on the need and the criticality of the application.
All that remains is to validate the implementation of the protection by clicking on the FINISH button (TERMINER), after having reread and confirmed that the parameters are the correct ones.
Initial replication of the vApp starts immediately, and takes anywhere from a few seconds to a few minutes, depending on the size of the storage to be replicated.
Here, in less than 10s, the VMs are replicated and protected (they are very small).
On the portal home page, at the top right, we see that we have a vApp and 3 VMs in OK replication state.
We are now connected to our target vOrg: cav02ev04ocb0006386, on CHA. We don't see our vApp, and that's normal. It doesn't exist yet. On the other hand, we see, in recent tasks, that disks have been created. These disks correspond to the storage of the replicated VMs.
In the Virtual Data Center (Centre de données virtuelles) section, we will find our named disks, one per replicated VM. These named disks are updated with each replication task (according to a schedule corresponding to the policy defined when the protection was set up), and will be attached to VMs created by VCDA in the event of the switchover being triggered.
On the VCDA home page of our target vOrg (on the CHA site), we have our VMs in OK state, and, at the bottom right, the resources required to start the VMs, in the event of a failover. Our recovery vDC was configured in PAYG, so as to have the capacities necessary to start the VMs, without billing for the computing power. See vDC billing methods on this page.
On our CHA site, an incoming replication is visible.
It's finished, we have protected a vApp, running on the VDR site, by creating a replication on the CHA site. In the event of unavailability (total or partial) of the VDR site, we can switch the vApp up to date, and run it on CHA. This switchover procedure will be detailed next.