The Workflow & Components
In the last post, I covered a 101 of replication in general and mentioned where Veeam has a play in A-Synchronous and will have Near Synchronous Replication in v10 in the form of CDP.
In this post, I wanted to walk through the steps taken when Veeam is used for A-Synchronous replication in your virtualised estate.
First, I want to touch on the components that are required for any sort of Veeam replication, these can double up for the backup elements also.
Veeam Backup Server
- The “configuration and control center”
- Coordinates tasks, controls job scheduling and resource allocation
- Set up and manage backup infrastructure components
- Windows-based physical or virtual machine on which Veeam Backup & Replication is installed
Veeam Proxy Server
- Used to process jobs and deliver backup traffic
- Takes data processing off the Veeam Backup server
- Controls Deduplication and compression tasks on the data
- A dedicated Windows server (physical or virtual)
- You can deploy backup proxies both in the primary site and remote sites
Veeam Replication Architecture
During the first run of a replication job, Veeam Backup & Replication copies the VM running on the source host and creates its full replica on the target host. The replica is stored uncompressed, in a native hypervisor format.
All subsequent replication jobs are incremental. Veeam Backup & Replication copies only those data blocks that have changed since the last replication cycle.
These image level replicas are stored as restore points in the target destination as snapshots, there are some small differences between VMware and Microsoft Hyper-V, I will differentiate those below.
If you are leveraging Veeam replication on VMware then you will still something like this in your secondary location.
VMware has a supported limit of 32 snapshots, minus the working snapshots that Veeam requires and a bit of overhead, this would allow for a 28 snapshots/restore points limitation.
For those using Microsoft Hyper-V you will see something like this on the target destination.
Microsoft Hyper-V has a supported limit of 50 snapshots, minus the working snapshots Veeam requires and a bit of overhead, this would allow for 47 snapshots/restore points.
VM data is moved block by block, with multiple processing cycles. The replication process is performed in the following way.
- The Source Data Mover speaks with the Target Data Mover to start any data collection.
- The Source Data Mover then checks the VM and copies the data using the correct Veeam transport mode. This is related to how the Proxy has been configured to access the virtual infrastructure. During scheduled incremental job runs the Veeam data mover service will only take the changed blocks since the last replication job. As well as copying the data the source data mover will perform some additional tasks, it will consolidate and filter out zero data block and swaps files from the virtual disks.
- Those changed blocks are compressed and transferred from the source data mover to the target data mover.
- The target data move decompresses the data and writes the result to the destination datastore.
How do we get that first bit of data over?
When planning for offsite replication, we should consider available features to reduce the amount of replication traffic and streamline replica configuration.
Replica Seeding allows us to send over the bulk of data via physical methods, this could be by placing the copy of data onto moveable hardware and shipping that to the target destination. USB Drive, Storage Array etc. Don’t underestimate the bandwidth of a man in a van. It will save a lot of time and bandwidth over those expensive links.
Another Veeam component, software only and it’s there to optimize VM data transfer, this is achieved by Global data caching and deduplication. The configuration for the WAN Accelerator is a One to many configuration, or can be used in pairs if you have an active pair of sites, A single WAN accelerator in the primary location, multiple WAN accelerators at branches or targets destinations.
There are some great best practices noted in the Veeam Best Practice guide around WAN Acceleration.
I will be sure to cover off in more detail some of these components and highlight some best practices, sizing and deployment facts from the field.