vranger evaluation guide - questsupport-public.cfm.quest.com/b8f15ed4-0789-474e-bf... · the...

vRanger Evaluation Guide

2

Contents Contents ................................................................................................................................................ 2

Overview ................................................................................................................................................ 3

About Quest Software ......................................................................................................................................... 3

About This Guide ................................................................................................................................................ 3

The Virtual Infrastructure ...................................................................................................................... 4

Supported VMware Platforms .............................................................................................................................. 4

Recommended Service Console Configurations (ESX Only) ................................................................................. 5

Configuring vRanger ............................................................................................................................. 6

Network Mode ..................................................................................................................................................... 6

LAN Free .......................................................................................................................................................... 10

Setting Up Repositories ..................................................................................................................................... 14

Replication ........................................................................................................................................................ 17

Advanced Configurations ................................................................................................................... 18

Fibre/iSCSI Backups ......................................................................................................................................... 18

Change Block Tracking...................................................................................................................................... 19

Job Configuration .............................................................................................................................................. 19

Application Consistency ..................................................................................................................................... 21

Testing vRanger .................................................................................................................................. 23

Backup Testing ................................................................................................................................................. 23

Restore Testing ................................................................................................................................................. 24

Failover Testing................................................................................................................................................. 27

3

Overview vRanger offers comprehensive data protection that supports VMware vSphere. Delivering fast and reliable backup and

recovery, vRanger captures the entire image of a VM and offers restore at the image, file or application level (When

using Quest Recovery Manager for Exchange). All backup jobs are executed without interrupting service--that is,

while the source machine is running. An intelligent resource scheduler maximizes throughput by leveraging all

available ESX hosts and controlling the number of simultaneous jobs, reducing the backup window. To save time and

disk storage, vRanger supports multiple space savings mechanisms such as Change Block Tracking (CBT),

incremental backup, differential backup, and Active Block Mapping (ABM). Finally, vRanger allows you to connect to

multiple vCenter Servers to easily protect larger or distributed environments.

About Quest Software Quest Software simplifies and reduces the cost of managing IT for more than 100,000 customers worldwide. Our

innovative solutions make solving the toughest IT management problems easier, enabling customers to save time and

money across physical, virtual and cloud environments. For more information about Quest, go to www.quest.com.

About This Guide This guide is intended to provide guidance on the proper environmental and application configurations needed to

effectively run and evaluate vRanger. This guide is not intended as a complete resource, but a quick reference guide

that captures the most common use cases.

Additional Documentation

The vRanger documentation set consists of the following:

• Release Notes (PDF)

• vRanger Deployment Guide (PDF)

• Getting Started Guide (PDF)

• What’s New Guide (PDF)

• System Requirements Guide (PDF)

• Installation and Setup Guide set PDF):

• User Guide (PDF and online help)

The vRanger documentation is available online at: http://portal.vizioncore.com

Quest Online Resources:

The Quest website contains a wealth of information, including product features and functions, release information,

product documentation, training, and support forums.

General Product Page - Feature Information, Demos, etc:

http://www.quest.com/vranger/

vCommunity - A collaborative environment for Quest customers featuring forums, wikis, and more.

http://communities.quest.com/community/vranger

http://www.quest.com/

http://www.quest.com/vranger/

http://communities.quest.com/community/vranger

4

The Virtual Infrastructure The performance and reliability of vRanger depends, in large part, on the configuration of the environment in which it is

used. Please use these configuration recommendations and guidelines within your environment to ensure optimal

operation of vRanger.

Supported VMware Platforms vRanger supports operation against the following versions of VMware Infrastructure:

ESX(i) Server * vCenter/VirtualCenter VCB

• 4.0

• 4.0 Update 1

• 4.1

• 4.1 Update 1

• 5.0

• 4.0

• 4.0 Update 1

• 4.0 Update 2 • 4.1

• 4.1 Update 1

• 5.0

VCB integration is not supported in

this release. VMware has

announced End of Life for VCB and

is shifting focus to the vStorage API,

which is supported by vRanger.

*Replication for ESXi requires the vRanger Virtual Appliance

For a complete list of supported platforms and installation platforms, please see the vRanger System Requirements

Guide at: http://portal.vizioncore.com

Port Requirements

If you are using a firewall that might restrict communication between the computers involved in the backup process,

ensure that these ports are available:

Port Direction Function

22 TCP vRanger: outgoing

Host ESX Servers: incoming

and outgoing

Used for backup traffic when

using Direct-To-Target

configuration. Also used for

basic SSH communications and

replication traffic.

443 TCP, 902 TCP vRanger: outgoing Used for vCenter and ESX(i)

host communications via the

VMware API

Licensing

Every ESX(i) host for which vRanger is expected to provide protection must be properly licensed, both by VMware and

in the vRanger Host Licensing tab. Each physical CPU socket on a licensed ESX host requires 1 CPU License.

vRanger can restore and replicate to a host for which you have not configured a vRanger license.

vRanger does not support the free version of VMware ESXi. In order to use VMware’s vStorage APIs to perform LAN

Free Backups, a minimum of “vSphere Essentials” licensing is required from VMware.

5

Recommended Service Console Configurations (ESX Only) During standard backup operations in Direct-To-Target mode, the ESX Service Console is used to run process data.

The additional load placed on the Service Console should be addressed by implementing the suggestions below.

Service Console Configurations

Please ensure that your ESX build is 219382 or higher. Previous versions are affected by an issue that limits service

console read/write performance to approximately 20 MB/s. Apply VMware Patch ESX400-200912401-BG or the latest

available build to avoid this issue.

The tables below detail the approximate difference in performance provided by the patch.

vRanger 5.x Backup Time Comparison - vRanger 5.x

Backup Type ESX 4.0 (Build lower than 219382) ESX 4.0 (Build 219382 and above)

Compressed, 50 GB, LAN 12-14 MB/s 72-85 MB/s

Uncompressed, 50 GB, LAN 13-16 MB/s 90-110 MB/s

Compressed, 50 GB, Fibre 50-60 MB/s 48-58 MB/s

Uncompressed, 50 GB, Fibre 73-87 MB/s 73-87 MB/s

In addition to ensuring your ESX Hosts are at an adequate patch level, Quest recommends that the changes below be

made on your ESX hosts to optimize the backup of VMs when using Direct-To-Target mode. These ESX resource

settings are not mandatory, but are recommended to minimize potential issues and maximize performance.

Increase the VIM CPU reservation (2500-3200 MHz):

In the VI Client inventory, select the ESX host > Configuration tab > System Resource Allocation. In the System

Resource Pools view, select VIM and click Edit Settings.

1. Adjust the CPU reservation slider up to the equivalent of one core (2500-3200 MHz).

2. Select Expandable Reservation and Unlimited.

Increase the Service Console CPU Reservation to 1500 MHz

In the VI Client inventory, select the ESX host > Configuration tab > System Resource Allocation. In the System

Resource Pools view, select Console and click Edit Settings.

1. Adjust the CPU reservation slider up to 1500 MHz.

2. Select Expandable Reservation and Unlimited.

Increase the RAM allocated to the Service Console to 800 MB.

In the VI Client inventory, select the ESX host > Configuration tab > Memory. Click Properties.

1. On the Memory window, enter a value between 256MB and 800MB for the service console parameter. 2. Click OK to save.

Note: These changes requires a reboot of the ESX Host in order to take effect

6

Configuring vRanger vRanger can be used in either a network based mode (using a Direct-To-Target configuration for ESX backups) or in a

LAN Free mode (using Fibre or HotAdd). The installation requirements differ for each mode of installation. Actual

requirements vary depending upon a number of factors; the values below represent a starting point for an optimal

experience during your evaluation.

For either configuration, the operating system on the vRanger machine can be configured to use any of the languages below:

English French Italian

German Japanese Simplified Chinese

Spanish

Network Mode Network Mode within vRanger can be configured one of two ways, depending on whether you are using ESX or ESXi

as your hypervisor. When using ESX, Quest refers to the vRanger architecture as Direct-To-Target.

When using ESXi as the hypervisor of choice, the preferred Network Mode option is to use the VMware vStorage API’s

HotAdd functionality over the network from the vRanger server. This will yield performance similar to ESX network

backups.

Direct-To-Target

For network-based backups when using ESX, the backup data flows from the ESX Host to the target repository. This

means that the vRanger server does not process any of the backup traffic. This Network Mode configuration, also

known as “Direct-To-Target”, provides the best scalability when using ESX as your hypervisor platform, as the number

of concurrent backup jobs can be scaled across multiple hosts to write to multiple data repositories.

When using this Direct-To-Target architecture, vRanger monitors activity and can be installed in a VM without affecting

performance. The recommended configuration for this VM is as follows:

CPU: 2 CPUs

RAM: 2 GB RAM

Storage: At least 10 GB free hard disk space

OS: Windows Server 2003/2008 (32-bit or 64-bit)

It is important to note that for vRanger does not support this Direct-To-Target configuration for ESXi backups since

ESXi does not contain a Service Console. For ESXi environments, a similar option is available. See HotAdd for more

information.

Network-based, Direct-To-Target backups use the ESX Service Console and the Service Console NIC to process and

send data to a repository. In Direct-To-Target, the repository must be a CIFS, NFS, FTP, or SFTP repository. Direct-

To-Target is the default configuration option out of the box for ESX Hosts, and is suitable from SMB to Enterprise.

7

For smaller environments, the Direct-To-Target configuration is simple to configure and requires no additional

hardware. For larger VMware deployments, this configuration allows for a highly scalable backup solution that

distributes load across multiple hosts and repositories while minimizing single points of contention. For example,

assume that you have 10 ESX hosts, each with 1 GBit/s network connection. Your total backup bandwidth is

theoretically 10Gbit/s. As 10 GBit/s networks become more common, this configuration will be able to handle even

higher throughputs.

Advantages Considerations

Easiest method to install. Works this way “out-of-the-

box”

Performs better with a larger number of ESX

servers

Allows for leveraging Direct-to-Target for optimal

scalability Service Console NIC is a limiter of throughput

Sufficient configuration for small and large environments

alike

Works well in conjunction with Data

Deduplication appliances like Data Domain,

ExaGrid, and Quantum.

vRanger can be installed in a VM

Expected Performance – Direct To Target

The values below represent vRanger’s performance in a basic configuration. Performance will vary based on hardware

used and environmental factors - a properly configured environment, using similar hardware, should yield similar

results. When using the direct-to-target configuration, it is critical that your ESX servers are appropriately patched in

order to provide adequate transfer speeds. Please see Service Console Configurations for more information.

These values were obtained by performing 5 concurrent Full backups of 50 GB VMs, with vRanger installed as

described below:

8

• Dell PowerEdge 1950 running Windows 2003 SP2 (x86)

• CPU: 1.6 GHz Intel Xeon (8-core)

• RAM: 4 GB Ram

• Network: BCM5078 1Gb Nic

VMware ESX 4.0 (Patched)

Compressed Uncompressed

Job Duration Throughput Job Duration Throughput

125 minutes 26 seconds 54-60 MB/s 85 minutes 8 seconds 65-80 MB/s

HotAdd

When using vRanger in Network mode with ESXI, the best performance will be achieved by using HotAdd. In this

configuration, as illustrated below, the VMDK(s) of the source VM are attached (via HotAdd) to the vRanger machine,

yielding direct access to source data. Overall, the performance in this configuration is slightly less than network

backups from ESX servers, but significantly faster than previous ESXi backup methods.

When using this Network Mode for ESXi, vRanger must be installed on a virtual machine. The recommended settings

for this server are as follows:

CPU: 2 CPUs

RAM: 2 GB RAM



9


Easiest method to install. Works this way “out-of-

the-box”

Performance is often slower than LAN Free

methods.

vRanger is installed in a VM All traffic must flow through vRanger VM.

Expected Performance – ESXi Network Mode

The values below represent vRanger’s performance in a HotAdd configuration. Performance will vary based on

hardware used and environmental factors - a properly configured environment, using similar hardware, should yield

similar results. When using HotAdd for ESXi network backups, it is critical that your ESXi servers are appropriately

patched in order to provide adequate transfer speeds.

These values were obtained by performing 5 concurrent Full backups of 50 GB VMs

VMware ESXi 4.0 (Patched)




10

LAN Free – Traditional

Note: The information in this section applies to a traditional LAN-Free configuration using physical proxies. To

configure vRanger for LAN-Free backups and restores with vRanger installed in a virtual machine, see LAN Free -

HotAdd.

vRanger provides a method to offload backup traffic from the network and can perform backups directly via iSCSI or

Fibre connectivity. The LAN Free configuration is identical whether ESX or ESXi is used, providing the best mix of

performance and compatibility for protecting your data, especially if your environment has a mix of VMware

hypervisors. In order to perform LAN Free backups, vRanger must be installed on a physical system attached to your

SAN environment. This is a high performance configuration that requires vRanger to be installed on a physical proxy

server connected to your fibre or iSCSI network. In addition, the VMFS volumes containing the VMs to be protected

must also be properly zoned/mapped to the vRanger proxy server.

The hardware requirements for installation on a physical server are as follows:

CPU: 2 CPUs

RAM: 2 GB RAM



Fibre: At least one fibre HBA

- Or -

iSCSI: Hardware or Software iSCSI initiator

11


Backups are isolated to the fibre channel

infrastructure or iSCSI network

Performs best when backing up data between

LUNs within the same SAN infrastructure

Provides high performance throughput for backup

traffic

More complicated to setup and configure than

network backup

Offloads ESX/ESXi hosts and network If not configured correctly there is risk of VMFS

volume corruption. Make sure to follow the

instructions below.

Communicates via vStorage APIs vRanger must be installed on a physical proxy

server

Requirements for a LAN Free Configuration

In order to implement a LAN Free configuration, you must install vRanger on a physical proxy server connected to your

Fibre or iSCSI infrastructure. You will also need to enable LAN Free backups in the vRanger backup job – see

Fibre/iSCSI Backups for more information on how to properly configure vRanger job settings to take advantage of

LAN Free backups.

When using the vStorage API, plan on 1 concurrent backup per CPU core. To calculate the maximum number of

concurrent backup tasks per proxy server, simply identify the number of CPU cores on that server – that is the

maximum number of concurrent backups. For example, a Dual-Socket, Quad-Core system will be able to perform up

to 8 concurrent backup jobs.

SAN Configuration Requirements

There are several SAN configurations that should be addressed before installing vRanger on the proxy server.

Caution: Do NOT initialize or format the unknown or offline disks from the backup server – these represent

your VMFS volumes. Any changes could potentially corrupt your VMFS volumes.

Disable automount on the vRanger machine:

o From the start menu, select “run” and enter diskpart.

o Run the automount disable command to disable automatic drive letter assignment.

o Run the automount scrub command to clean any registry entries pertaining to previously

mounted volumes.

The multi-pathing software from your SAN vendor should be installed and configured for the best throughput

performance

LUNs that are not accessible to the proxy server should be masked in the storage array configuration

On your storage device, zone your LUNs so that the vRanger HBA has Read-Only access (for backups). If

you want to restore over fibre, zone your LUNS so that the vRanger HBA has Read-Write access

Only one proxy should see a set of VMFS LUN’s at one time.

12

SAN Configuration Recommendations

VMware provides multiple documents detailing their recommendations for storage configuration. Two key documents

are the VMFS Overview and Best Practice Guide and the iSCSI SAN Configuration Guide.

Expected Performance – LAN Free

The values below represent vRanger’s performance in a basic configuration. Performance will vary based on hardware

used and environmental factors - a properly configured environment, using similar hardware, should yield similar

results. In order to determine whether you have properly configured vRanger for LAN Free backups, you can test your

configuration using steps identified in the Testing LAN Free section of this document.

These values were obtained by performing 5 concurrent Full backups of 50 GB VMs, with vRanger installed as

described below:

• Dell PowerEdge 1950 running Windows 2003 SP2 (x86)

• CPU: 1.6 GHz Intel Xeon (8-core)

• RAM: 4 GB Ram

• Network: BCM5078 1Gb Nic

• HBA: BCM5715S fibre adapter

VMware ESX 4.0 (Patched)




VMware ESXi 4.X (Patched)




http://www.vmware.com/pdf/vmfs-best-practices-wp.pdf

http://www.vmware.com/pdf/vsphere4/r40/vsp_40_iscsi_san_cfg.pdf

13

LAN Free - HotAdd Beginning with the 5.1 release, vRanger includes support for VMware’s HotAdd disk transport functionality. With the

proper configuration, HotAdd allows you to perform LAN-Free backups with vRanger installed inside a virtual machine.

This configuration that requires vRanger to be installed on a virtual machine residing on an ESX(i) host connected to

your fibre or iSCSI network.

The hardware recommendations for the vRanger virtual machine are as follows:

CPU: 2 CPUs

RAM: 2 GB RAM




Backups are isolated to the fibre channel

infrastructure or iSCSI network

Performs best when backing up data between

LUNs within the same SAN infrastructure

Provides high performance throughput for backup

traffic

More complicated to setup and configure than

network backup

Offloads ESX/ESXi hosts and network

Communicates via vStorage APIs

14

Requirements for a LAN Free - HotAdd Configuration

In order to use vRanger with HotAdd, vRanger must be installed in a VM, and that VM must be able to access the

target VM’s datastore(s). In addition, all hosts that the vRanger VM could be vMotioned to must be able to see the

storage for all VMs that vRanger will be configured to back up. You will also need to enable LAN Free backups in the

vRanger backup job – see Fibre/iSCSI Backups for more information on how to properly configure vRanger job

settings to take advantage of LAN Free backups.

When using the vStorage API, plan on 1 concurrent backup per CPU core. To calculate the maximum number of

concurrent backup tasks per proxy server, simply identify the number of CPU cores on that server – that is the

maximum number of concurrent backups. For example, a Dual-Socket, Quad-Core system will be able to perform up

to 8 concurrent backup jobs.

Configuring vRanger for HotAdd

When using HotAdd, make sure to disable automount on the vRanger machine. This will prevent Windows on the

vRanger VM from assigning a drive letter to the target VMDK. To disable automount:

o From the start menu, select “run” and enter diskpart.

o Run the automount disable command to disable automatic drive letter assignment.

o Run the automount scrub command to clean any registry entries pertaining to previously mounted

volumes.

Expected Performance – LAN Free

In a LAN-Free configuration, HotAdd yields similar results to the standard vRanger Fibre backups, which can be seen

in the section above.

Setting Up Repositories Repository location, along with the configuration of jobs to those repositories, plays a significant role in the

performance of vRanger. While performance varies based on environmental factors, data throughput during a single

VM backup task can routinely reach 30-40 MB/s. For repositories on a Gigabit network, Quest recommends a

maximum setting of 3 concurrent backups per repository (see Job Configuration for more information), which can

consume 75% percent of the bandwidth to the repository.

There are two main scenarios when it comes to configuring repositories: a centralized datacenter or multiple sites.

While evaluations often use a more basic configuration, it is important to replicate real-world scenarios as much as

possible.

Scenario 1: Centralized Datacenter

If you will be evaluating vRanger in a single datacenter you will only need one repository. While additional repositories

increase your load balancing options, they are not necessary.

For most customers, a CIFS or NFS repository is preferred. If a third party will host your repository, or if your network

security is restrictive, an SFTP repository might be a better option as traffic flows through the standard SFTP port (22

or user configurable). Also, standard FTP is available as well.

For LAN Free configurations, or for those sites with a large number of ESXi servers, the repository should be local to

the vRanger machine.

Scenario 2: Multiple Sites

15

If you have a repository located at a remote site, the bandwidth between the sites will most likely become the limiting

factor in job configuration. Rather than limit all vRanger tasks to fit the limited WAN bandwidth, it may be

recommended to install a second vRanger server to be used for job management to remote repositories. On this

second vRanger installation, you may configure the per-repository limit to match the available bandwidth without

affecting the local backup tasks. The approach to multi-site configuration differs depending on whether you are using

ESX or ESXi.

ESX

In order to take full advantage of the direct to target flexibility, configure one repository at each location. With this

configuration, the backup traffic will be isolated to each site. This configuration also provides the simples way to

manage the environment, as only a single vRanger server is required to configure and view backup jobs.

ESXi

For ESXi backups, all of the data processing must occur on the vRanger machine. This means that in order to use a

single vRanger instance across multiple sites when using ESXi, all backup traffic must traverse the WAN from the

secondary site back to the primary. If your WAN speed is more than 10 Mbit/s between sites, or the amount of data at

the secondary site is relatively small with infrequent changes, you may deploy a single vRanger server at the primary

site. The following diagram illustrates this configuration.

16

For larger remote sites, or for organizations that have communication links slower than 10 Mbit/s between sites, a local

vRanger installation (with its own local repository) should be configured at each site. Using a repository local to the

vRanger machine eliminates the need for the data to flow back from the secondary site to the primary over the WAN.

Deploying a local vRanger server in each site for faster backups does not require additional vRanger licenses. The

following diagram illustrates this configuration.

17

Replication vRanger provides image-based replication of virtual machine (VM) images across local and wide-area networks (LANs

and WANs). During vRanger replication, changed data blocks are sent from the source VM to a target VM located at

the D/R site. The primary consideration for replication performance is the available bandwidth (and quality of

connection) between the two locations.

Replication is available only in the Pro version of vRanger. vReplicator is still offered as a stand-alone replication tool.

Network Connections to D/R Site

Network architecture is a significant component of any disaster recovery infrastructure. Components to consider

include bandwidth, link contention and latency. When sizing a link, ensure that all network traffic that will traverse the

link is taken into account, as this may have an impact on replication times.

Replication traffic is transmitted using the TCP protocol, and is susceptible to lower performance if transmitted across

a link with a very high latency, such as a satellite link. Low latency links such as Ethernet, DSL and MPLS allow TCP

to transmit data at its highest rate possible.

If there is a significant amount of production network traffic also using the link, implement network quality of service

(QoS). QoS will ensure that network traffic is correctly prioritized, granting all applications a fair percentage of the

bandwidth available. vRanger replication traffic can be identified for QoS as a transmission between ESX hosts on

TCP port 22 (SSH).

IP Addressing

Probably the most complicated, and most overlooked, component of designing a disaster recovery solution is the IP

addressing. Designing the IP addressing architecture correctly will allow your production site to communicate with your

DR site, and, more importantly, will allow your client computers to communicate with your servers in the event of a

disaster.

A bridged network connection between sites will ensure the highest probability of a successful failover in the case of a

disaster. With a bridged network connection, the Layer 2 network protocol is spanned between sites so a single IP

address range can be shared between sites. This simplifies the disaster recovery failover process and aids with any

live failover testing.

Latency Limitations

Excessive network packet loss could result in replication failure. Replication is not designed to work in environments

where packet loss can exceed commercially accepted limits, summarized by the requirements below:

Replication will work with links having average packet loss of less than 2%.

Networks having 99% Uptime/Availability will generally provide for good Replication performance.

18

Advanced Configurations There are some advanced job configuration options that will help you get the most out of vRanger. These options are

described below.

Fibre/iSCSI Backups To perform a LAN-Free backup, you must select the Perform LAN-free backup option during the backup job

configuration.

When testing LAN-Free backups, it is important to ensure that the backup traffic is not flowing over the network. In

order to do this, clear the Perform Network Backup on LAN-free Failure option. This will ensure that if there is a

configuration problem with your SAN environment, you will be alerted by a backup failure.

After you have verified your SAN configuration and LAN-Free backups are running correctly, select the “Perform

Network Backup on LAN-free Failure” option to ensure that your backups occur uninterrupted.

Note: HotAdd jobs will generate an error in the vRanger log indicating that “Backup task using VDDK SAN failed . . .”

this is a benign message and can safely be ignored.

Testing LAN Free

LAN Free backups (Fibre and iSCSI) flow through the Windows proxy to a local NTFS volume. You can use native

Windows tools to monitor this activity as a simple test.

Using Perfmon.exe, add Physical Disk counters for :

Disk Reads/Sec – this is the metric to evaluate backup traffic

Disk Writes/Sec – this is the metric to evaluate restore traffic.

19

Change Block Tracking Change Block Tracking (CBT) is a feature in vSphere that tracks changes within the VM. With Change Block Tracking

enabled, vRanger only backs up the portions of a disk that have changed since the last backup. This occurs without

scanning the VMDK for changes. This often results in shorter backup operations, and reduced resource consumption

on network and storage elements. Quest recommends enabling CBT within vRanger whenever possible.

CBT is supported for virtual machines running on ESX(i) 4.0 or later hosts (with virtual hardware 7). VMs that are

created in ESX(i) 3.5 or below must be migrated to ESX(i) 4.x and Hardware Version 7 for CBT to be supported.

Enable or disable CBT by right clicking on any VM in the My Inventory pane of vRanger and select Enable Change

Tracking (or Disable Change Tracking). Three small circles (Red-Blue-Green) indicate that CBT is enabled.

CBT can also be enabled in the vSphere client for each VM, or you can use a script to enable CBT for multiple VMs at

once.

Job Configuration vRanger includes global configuration options designed to allow you to throttle backup and restore activity to fit your

environment. The maximum number of tasks (backups or replications) can be changed based on your environment.

Start with default values and make sure your backups are successful before you increase any values.

The available options for configuring advanced resource management are:

Maximum number of tasks running on vRanger (>=1) – This value limits the total number of simultaneous

tasks for the vRanger machine. This value is affected by machine type and hardware as well as deployment

architecture. The default value is 100, which does not normally need to be changed as the other limiters will

take effect before this value is reached.

Maximum number of tasks running off a LUN (1-5) - In order to avoid storage I/O contention issues, it is

recommended to limit the number of tasks that can be processes based on their storage location. vRanger

defaults with a limit of 3 backup tasks per LUN.

20

Maximum number of tasks running on a host (1-4) -This setting should be set fairly low as all of the

backup processing (for standard backups) occurs on the host. The default per-host limit is set to 1. Due to the

amount of CPU and memory used by the host to process backups, it is recommended to use caution when

changing this value.

Maximum number of tasks running per repository (>=1) – Bandwidth to the repository is the main limiting

factor here. For repositories on a Gigabit network, Quest recommends a maximum setting of 3 concurrent

backups, which can consume 75% percent of the bandwidth to the repository.

Maximum number of tasks running locally (1-20) – This option applies only to LAN Free mode and limits

the number of simultaneous tasks on the vRanger proxy server. The recommended maximum is 1 task per

CPU core.

Maximum Number of Tasks Running per VA (1-18) - the number of backup, restore and replication tasks

running on a vRanger virtual appliance.

Enabling Cataloging

vRanger 5.0 includes Cataloging - the option to collect and record file and directory information during the backup

process. This information is stored in the Catalog database, and used to enable a Browse and Search function that

speeds and simplifies file level recovery.

Catalog collections are disabled by default. Collection must be enabled globally through vRanger’s Tools>Options

menu. Collection must also be enabled on a per-job basis by selecting Enable Cataloging in the vRanger backup job

Options Selection dialog.

For more information on cataloging, see The vRanger Catalog.

Configuring Replication Jobs

vRanger offers three different replication modes: CBT, Hybrid, and Differential. Each replication mode works in a

particular way. Regardless of which replication method is chosen, only the changed data will be replicated on each

replication pass.

In Differential replication, a differential block scan occurs to check for changes from the last replication pass

each time vReplicator hits a replication interval. The differential scan speed varies based on host resources

and disk speed, however, a good rule of thumb for the scan speed is approximately 1 minute per GB

Hybrid replication is based on snapshot rotation, with a fallback to differential scanning in certain

circumstances.

While the choice of Hybrid or Differential replication should be made for each VM based on the RPO, RTO, IO

characteristics of the VM and other requirements, there are some general rules of thumb that assist with determining

which method of replication to use for each VM:

VM Size Replication

Interval

Recommended Replication Settings

Small

(< 20 GB)

Any Use CBT if your virtualization platform supports it. If not, consider

using Differential. Small VMs are replicated very efficiently using

Differential replication.

http://portal.vizioncore.com/sfc/p/5000000072w5B61ESv_GUKfbnHXiHQviHibQ1ds=

21

Medium-

Large

(20-150 GB)

Frequent

(e.g., once per hour)

Use CBT if your virtualization platform supports it. If not, consider

using Hybrid. By using Hybrid replication, replication intervals can

be very close due to the elimination of scan time.

Medium-

Large

(20-150 GB)

Infrequent

(e.g., once per day)

Use CBT if your virtualization platform supports it. If not, use

Differential. Using differential replication ensures that snapshots

will not grow throughout the day, as they would if using Hybrid.

Very Large

(500 GB+)

Any Use CBT if your virtualization platform supports it. If not, use

Hybrid, and replicate frequently. Hybrid ensures the elimination of

scan time, and replicating frequently ensures that snapshots do

not grow to an unmanageable size. While large

VMs can be replicated less frequently, ensure that you have an

adequate replication interval to replicate the entire VM.

Seeding replication jobs

vRanger replication is intended to replicate changes from a source VM to a remote target. It is often not practical to

perform the first replication pass (which sends the full VM) to a remote site over a WAN link. You may use vRanger to

“seed” a replication job by restoring a full backup of your source VM to the target location.

Application Consistency By default, vRanger provides no quiescing during backups or replication, which yields crash-consistent images.

Quiescing in vRanger is provided by leveraging VMware Tools’ VSS Sync Driver. This can provide three different

levels of backup consistency, as described below:

Crash-consistent - A crash consistent backup is analogous to pulling the plug on a server and then backing up

the data. The state of the data that is being backed up with respect to the users of the data is indeterminate.

Restoring a crash-consistent image is equivalent to rebooting a server after a hard shut-down.

File System Consistent - File system consistency is achieved through standard quiescing (via the VMware

Sync Driver.) which ensures that no file system writes are pending when the snapshot is taken. For normal VMs,

file-system consistency is adequate, although it can cause corruption in database applications.

Application consistent - Consistency of VSS compatible applications is achieved by freezing application I/O

just prior to creating the VM snapshots. This ensures that all application writes requests in the machines

memory are committed to disk before the snapshot is taken. Application consistency is achieved by leveraging

the Microsoft VSS driver in VMware Tools (for VMware ESX 3.5 Update 2 and later, make sure it´s enabled in

the VMs by going to Add/Remove Programs> VMware Tools >Modify>Check VSS Sync Driver).

Guest Quiescing

The level of consistency provided by the Enable Guest Quiescing option is dependent upon the version of VMware

ESX (and the corresponding VMware tools) and the Guest OS. In addition to the standard VSS implementation using

VMware Tools, Quest provides an optional method for application quiescing – vzShadow.exe.

The vzShadow.exe executable is included with the application download. vzShadow.exe is an optional component

that can be installed on Windows VMs to provide an additional level of consistency. For more information on

vzShadow.exe, see the vRanger Deployment Guide.

The tables below provide more detail on what is needed to achieve various levels of consistency:

http://portal.vizioncore.com/sfc/p/5000000072w54Przed4B3_myAwoQbC16JuC7X1s=

22

File-level Quiescing

ESX Version Windows Server 2003 Windows Server 2008 (includes R2)

VMware ESX(i) 4.0 VMware VSS VMware VSS

VMware ESX(i) 4.1 VMware VSS VMware VSS

Note – for VMs created on ESX(i) 4.1, you must also

set the flag to “false” *

Application-level Quiescing


VMware ESX(i) 4.0 VMware VSS vzShadow.exe

VMware ESX(i) 4.1 VMware VSS vzShadow.exe



Truncation of Exchange Logs


VMware ESX(i) 4.0 vzShadow.exe vzShadow.exe

VMware ESX(i) 4.1 vzShadow.exe vzShadow.exe



* For information on how to change the flag, see the vRanger Deployment Guide.

Recovery Manager for Exchange

While outside the scope of this document, Quest provides a more advanced option for object-level restore of individual

email messages, folders, and other objects from Microsoft Exchange databases which are protected in vRanger

backup images – Quest Recovery Manager for Exchange.

For more information on using Recovery Manager for Exchange with vRanger, see the chapter “Integrating vRanger”

in the vRanger Deployment Guide.



23

Testing vRanger After ensuring that your environment is properly configured, it is important to test vRanger in real-world scenarios.

Make sure you backup multiple VMs (10 or more) to see the performance, backup window and impact of your

infrastructure. If you lose a datastore you will loose multiple VMs, vRanger allows you to do multiple VM restores in a

single restore job. This will simplify your recovery process in the event of a disaster.

Backup Testing Backup jobs can be created against vCenter objects (vCenter, Cluster, Resource Pools, Folders etc) or against a

vRanger configurable Backup Group (a set of VMs). Use the steps below to create a vRanger backup job.

These steps provide a high level overview of the process of creating a backup job. For more detailed information

about creating backup jobs, see the vRanger User Guide.

1. Select the object to backup. You may select a vCenter object or create a custom group. When testing

vRanger, it is best to configure jobs in real-world scenarios.

2. Exclude any VMs that you do not want backed up as part of this job.

3. Exclude any disks that you do not want backed up as part of this job Select Repository

4. Configure your Backup Options, using the notes below for guidance. Also see Fibre/iSCSI Backups

a. If your repository has built-in deduplication, clear the checkbox for Compress backed up files.

b. If you need application consistency, select Enable guest quiescing. Also, see Application

Consistency.

c. Enabling Active Block Mapping (ABM) will reduce the backup window and size of the archives. With

ABM, no deleted files within the Windows file system will be backed up. This generally results in a

20-30% reduction of backup time and size.

d. Select Enable Cataloging. This will enable browse and search functions to facilitate file-level

restores.

5. Configure your Retention Policy

6. Set the Savepoint count - the number of restore points.

7. Select a space saving technology. Options are full backups, or differential or incremental backups.

8. Set your backup schedule

9. Configure Email notification, if desired.

10. View the job summary. Job status and progress can be seen under My Jobs.

http://portal.vizioncore.com/sfc/p/5000000072w5EDZeGJyNjPHDfXrJDDkWLthJ7pw=

24

Restore Testing The most important part of any backup is the recovery. It is critical when evaluating backup software that you evaluate

recovery in order to learn the procedures, the approximate recovery time, and at what level you can restore.

With vRanger, you may perform either an image level recovery, or a file level recovery. To do either, you must first

identify the savepoint from which you wish to recover.

Savepoints

You can view existing savepoints in the My Repository view.

Image Level Restore

An image level restore recovers the entire virtual machine. Use the steps below to create a vRanger image level

restore job.

These steps provide a high level overview of the process of creating a restore job. For more detailed information

about creating restore jobs, see the vRanger User Guide.

1. In the My Repositories view, select the VM savepoint you want to restore. Click Restore.

2. You may add multiple savepoints to one restore job. This allows you to restore multiple VMs at one time, in

the case of a lost datastore, for example.

3. Select the destination host and datastore for your recovery. For recovery testing, use the Restore As option

as it will create a new VM with the name you choose, rather than overwriting the existing VM.

4. Configure the network for your restored VM(s).

http://portal.vizioncore.com/sfc/p/5000000072w5EDZeGJyNjPHDfXrJDDkWLthJ7pw=

25

5. Select your restore options.

6. Set your restore schedule

7. Configure Email notification, if desired.

File Level Restore

1. In the My Repositories view, select the VM savepoint you want to restore. Click File Level Restore.

2. Browse the savepoint file system to select the file to restore.

3. Select the destination location. Click Restore.

Catalog Search

Rather than browse a specific archive for a file to recover, you can search the catalog for all versions of that file, and

recover the correct version.

1. From the My Repositories view, click Catalog Search. The Catalog Search and Browse dialog appears.

26

2. In the Advanced section, you can limit your search by selecting (or deselecting) repositories or

savepoints to be searched.

3. In the Catalog Search Criteria field, enter the text to search for.

The traditional wildcard character (*) is not supported in Catalog Search. The search string can be as short, or as long as you desire. However, the shorter the string, the longer the search will take. To minimize performance issues during Catalog Search, make the search string as specific as possible.

The search results display.

4. Highlight the desired file. Click FLR to restore just the file, or Restore to restore the entire savepoint.

The appropriate restore wizard will appear.

27

Failover Testing The Test Failover feature in vRanger will disable the replication job, snapshot the replica VM, disconnect the network

card on the replica, and power it on. This allows for simplified testing of the Guest OS without impacting the production

environment.

Before you initiate a test failover, you must disable the replication job. If you do not, an error message will display. On

Demand jobs do not need to be disabled before testing.

1. In the My Jobs pane, navigate to the replication job that you want to test.

2. Details about the job display in the Current Jobs pane.

3. Click the Test Failover icon.

4. A confirmation message displays. Click Yes.

5. The test failover process begins. A snapshot will be applied to the replica VM, the NIC will be disabled, and

the VM will be powered on.

6. When the sub-task displays a status of paused, you may safely test the VM via the VI Client console.

7. When testing is complete, select the sub-task and click Resume. Click Yes to confirm.

a. The snapshots made will be reverted.

b. The network card will be set to “Connect at power on”.

c. The VM will return to it’s dormant state

vranger evaluation guide - questsupport-public.cfm.quest.com/b8f15ed4-0789-474e-bf... · the...

Documents