VRanger 5.2.1 DeploymentGuide Rev1

102
Deployment Guide vRanger ® Version 5.2.1

description

Del vRanger deployment guide for 5.2.1

Transcript of VRanger 5.2.1 DeploymentGuide Rev1

Page 1: VRanger 5.2.1 DeploymentGuide Rev1

vRanger®

Version 5.2.1

Deployment Guide

Page 2: VRanger 5.2.1 DeploymentGuide Rev1

© 2010 Quest Software, Inc.ALL RIGHTS RESERVED.

This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software, Inc.

The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document.

If you have any questions regarding your potential use of this material, contact:Quest Software World HeadquartersLEGAL Dept5 Polaris WayAliso Viejo, CA 92656www.quest.comemail: [email protected]

Refer to our Web site for regional and international office information.

Patents

This product includes patent pending technology.

Trademarks

Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, Benchmark Factory, Big Brother, BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight, ChangeAuditor, CI Discovery, Defender, DeployDirector, Desktop Authority, Directory Analyzer, Directory Troubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk Authority, Imceda, IntelliProfile, InTrust, Invirtus, iToken, JClass, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin, MessageStats, Monosphere, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point, Click, Done!, Quest vToolkit, Quest vWorkSpace, ReportADmin, RestoreADmin, ScriptLogic, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World, vAutomator, vConverter, vEcoShell, VESI, vFoglight, vPackager, vRanger, vSpotlight, vStream, vToad, Vintela, Virtual DBA, VizionCore, Vizioncore vAutomation Suite, Vizioncore vEssentials, Vizioncore vWorkflow, WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of America and other countries. Other trademarks and registered trademarks are property of their respective owners.

Deployment GuideAugust 2011Version 5.2.1

Page 3: VRanger 5.2.1 DeploymentGuide Rev1

Table of Contents

Planning Your Deployment .................................................................................................................................5

Getting Started ................................................................................................................................................................. 6

Before You Begin .................................................................................................................................................... 7

Other Information Sources .................................................................................................................................... 11

vRanger Overview.......................................................................................................................................................... 13

vRanger Overview ................................................................................................................................................. 14

vRanger Architecture............................................................................................................................................. 14

The vRanger Backup Process............................................................................................................................... 18

Available Backup Architectures ............................................................................................................................. 20

The vRanger Restore Process .............................................................................................................................. 28

vRanger Repositories ............................................................................................................................................ 29

The vRanger Replication Process ......................................................................................................................... 34

Deploying vRanger ............................................................................................................................................42

The Deployment Environment........................................................................................................................................ 43

The Deployment Environment ............................................................................................................................... 44

Choosing a vRanger Deployment Architecture ..................................................................................................... 47

Environment Configuration Recommendations ..................................................................................................... 54

VMware Recommendations .................................................................................................................................. 59

vRanger Repositories ............................................................................................................................................ 68

Common Configuration Issues .............................................................................................................................. 71

Managing vRanger Performance ......................................................................................................................75

Protection Best Practices ............................................................................................................................................... 76

Workload Protection Considerations ..................................................................................................................... 77

Pre-seeding Replication Jobs................................................................................................................................ 80

Space Saving Technologies .................................................................................................................................. 85

Page 4: VRanger 5.2.1 DeploymentGuide Rev1

Table of Contents 4

Filtering Catalog Collections...................................................................................................................................86

Integrating vRanger.........................................................................................................................................................88

Integrating vRanger................................................................................................................................................89

vRanger and Tape Backup Vendors ......................................................................................................................89

Application Backup & Recovery: Recovery Manager for Exchange.......................................................................97

Data Domain and vRanger Repositories................................................................................................................98

Using vRanger and Microsoft PowerShell..............................................................................................................98

Index..................................................................................................................................................................101

Page 5: VRanger 5.2.1 DeploymentGuide Rev1

Planning Your Deployment

This section provides general information on vRanger features and functions, as well as some key questions intended to guide your deployment planning.

This portion of the document contains the following sections:

Getting Started ..............................................................................................................................6

Other Information Sources .......................................................................................................... 11

vRanger Overview.......................................................................................................................14

vRanger Architecture...................................................................................................................14

The vRanger Backup Process.....................................................................................................18

The vRanger Backup Process.....................................................................................................18

The vRanger Restore Process ....................................................................................................28

vRanger Repositories ..................................................................................................................29

The vRanger Replication Process ...............................................................................................34

Page 6: VRanger 5.2.1 DeploymentGuide Rev1

Getting StartedThis chapter provides information on key questions and information sources used to plan a vRanger deployment.

This chapter contains the following sections:

Before You Begin .......................................................................................................................7

Learn About vRanger .........................................................................................................8

Setup Your Environment ....................................................................................................8

Install vRanger.....................................................................................................................9

Test Your Installation..........................................................................................................9

Tune Your Deployment ....................................................................................................10

Get More Out Of vRanger ...............................................................................................10

Other Information Sources...................................................................................................... 11

Page 7: VRanger 5.2.1 DeploymentGuide Rev1

7Getting Started

Before You BeginWhen planning any deployment, there are several steps that all customers will go through. Each of these steps is listed in the graphic below. The table below the image list the most common questions for each step, and provide links to the relevant sections of the document.

Page 8: VRanger 5.2.1 DeploymentGuide Rev1

8Getting Started

Learn About vRanger

Setup Your Environment

What does vRanger do? • “vRanger Overview” on page 14

How does vRanger work? • “vRanger Architecture” on page 14• “The vRanger Backup Process” on page 18• “The vRanger Restore Process” on page 28• “The vRanger Replication Process” on page 34• “vRanger Repositories” on page 29

What are my options for using vRanger?

• “The vRanger Backup Process” on page 18• “The vRanger Replication Process” on page 34• “The vRanger Restore Process” on page 28

Where can I get more information? • “Other Information Sources” on page 11

What are the requirements for deploying vRanger?

• “Hardware Requirements” on page 74• “Software Requirements” on page 74• “Application Databases” on page 16• “Source and Destination Requirements” on page 75• “VMware Requirements” on page 45• “Port Requirements” on page 44

How should I configure my environment for vRanger?

• “Recommendations for Network Backups” on page 54• “Recommendations for Fibre Backups” on page 55• “Recommendations for Replication” on page 56• “VMware Recommendations” on page 59• “vRanger Repositories” on page 68• “Installing the Databases” on page 78

What are some common configuration issues I should avoid?

• “Common Configuration Issues” on page 71

Page 9: VRanger 5.2.1 DeploymentGuide Rev1

9Getting Started

Install vRanger

Test Your Installation

I’m upgrading from vRanger 3.x - what do I need to know?

• “Upgrading from vRanger Pro 3.x” on page 80• “Performance Expectations” on page 82• “Job Migration” on page 84

Where should I install vRanger? • “Where to Install?” on page 75

What should I do with the vRanger database?

• “Database deployment options” on page 16• “Installing the Databases” on page 78

I’ve got my repositories set up - how can I test them?

• “Testing Repository Connections” on page 69

Page 10: VRanger 5.2.1 DeploymentGuide Rev1

10Getting Started

Tune Your Deployment

Get More Out Of vRanger

How should I configure by backup jobs for the best performance?

• “Workload Protection Considerations” on page 77• “Load Balancing” on page 84

How can I improve my data consistency?

• “Pre-seeding Replication Jobs” on page 80

How does vRanger reduce the storage footprint of archives?

• “Space Saving Technologies” on page 85• “Data Domain and vRanger Repositories” on

page 98

How do I get vRanger to work with my tape software?

• “vRanger and Tape Backup Vendors” on page 89

How can I extend vRanger?

• “Application Backup & Recovery: Recovery Manager for Exchange” on page 97

• “Using vRanger and Microsoft PowerShell” on page 98

I have a Data Domain appliance. Can I use that with vRanger?

• “Data Domain and vRanger Repositories” on page 98

Page 11: VRanger 5.2.1 DeploymentGuide Rev1

11Getting Started

Other Information SourcesBefore deploying vRanger, it is recommended to familiarize yourself with the available information sources.

Documentation

The vRanger documentation set consists of the following:

• Release Notes (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://vizioncore.com/product/vRangerPro

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

http://vcommunity.vizioncore.com/

• Training - Free access to online product training.

http://training.vizioncore.com

Contacting Support

Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have a valid maintenance contract.

Quest Support is easily accessed in the following ways:

• Email support directly at [email protected] for automatic case creation.

Page 12: VRanger 5.2.1 DeploymentGuide Rev1

12Getting Started

• Contact Quest support directly via our global and local telephone numbers.

• Log and create/update your case, and check its status via the Quest Support Case Management portal.

View the Quest Support Guide for a detailed explanation of support programs, online services, contact information, and policy and procedures. The guide is available at:

http://www.vizioncore.com/SupportDocs/Vizioncore_SupportGuide1_SFS.pdf.

Page 13: VRanger 5.2.1 DeploymentGuide Rev1

vRanger OverviewThis chapter details the vRanger features and functions and provides an overview of the backup and restore process.

This chapter contains the following sections:

vRanger Overview.......................................................................................................................14

vRanger Architecture...................................................................................................................14

Application Architecture...........................................................................................................14

Application Databases.............................................................................................................16

The vRanger Backup Process.....................................................................................................18

The vRanger Restore Process ....................................................................................................28

vRanger Repositories ..................................................................................................................29

The vRanger Replication Process ...............................................................................................34

Page 14: VRanger 5.2.1 DeploymentGuide Rev1

14vRanger Overview

vRanger OverviewvRanger offers comprehensive data protection and management that supports vSphere. Delivering fast and reliable backup and recovery, vRanger can capture the entire image of a VM or an individual file. All jobs can be executed without interrupting service--that is, while the source machine is running. Multiple ESX hosts can be used for simultaneous jobs, reducing the backup window. To save time and disk storage space after a full backup, you can run differential backup job to capture only the data that has changed since the full backup. You can run backup and restore jobs immediately or schedule them. You can track the progress of all jobs and their component tasks. vRanger allows you to connect to multiple VirtualCenters (VCs) and back up multiple ESX hosts.

vRanger ArchitecturevRanger is a multi-tiered application with both the client and server components installed on the same machine. vRanger will use a SQL Express database by default, but can easily be configured to use an existing SQL database installed anywhere in the network environment.

Application Architecture

The diagram below shows the various components, and where they are utilized during the backup process.

Page 15: VRanger 5.2.1 DeploymentGuide Rev1

15vRanger Overview

vRanger Client The vRanger Client is the main user interface for vRanger. The Client must be installed and run on the same machine as the vRanger Service.

vRanger Service The vRanger Service is the scheduling and communication “engine” for vRanger. The service runs independently of the vRanger Client, which means that task scheduling is not affected by closing the client.

vAPI vAPI is an exposed web service through which third-party vendors can integrate with vRanger.

A subset of the vRanger vAPI is the vAPI cmdlets for PowerShell. These cmdlets can be used to script vRanger features and functions.

Page 16: VRanger 5.2.1 DeploymentGuide Rev1

16vRanger Overview

Application Databases

vRanger utilizes a SQL database to store application and task configuration data. The database can be either SQL Express 2005, which is the default, or an external SQL database running on your own SQL Server 2005 or SQL Server 2008 database server.

Note The cataloging function of vRanger requires that the application and catalog databases be installed on the vRanger server. For more information, see “Installing the Databases” on page 78

Database deployment options

The database deployment occurs during the initial installation of vRanger.

Default

The Installation Wizard will default with a selection to install vRanger with the embedded SQL Express 2005 database. The default database can only be installed on the vRanger server.

While the embedded SQL Express database is free and simple to install, there is a size limit of 4GB per database.

External SQL Server

The Installation Wizard will guide you through configuring vRanger with an external SQL database. There is also an option in the Install Wizard to configure the database connection manually, but the guided approach is recommended.

USDI Service The USDI Service is responsible for FLR, specifically for the mounting of the .var archive and launching vzwino.exe to allow file extraction from within the GUI.

Repository In vRanger, this is the configured storage location for backup jobs. A repository can be: CIFS, FTP, SFTP, or NFS v 3.

Database vRanger requires a database (SQL or SQL Express) to store configuration information and task details. The database is installed by default on the vRanger machine, but can easily be installed on an existing SQL server as well.

VSS Module vRanger

Page 17: VRanger 5.2.1 DeploymentGuide Rev1

17vRanger Overview

Most larger organizations chose to use the embedded database to comply with internal policies and best practices. A significant advantage of using an external database, however, is that all settings and configurations (which are stored in the application database) are stored separate from the vRanger installation. In the event of a failure on the vRanger machine, the application can be quickly installed on another machine and configured to use the existing database.

Using an external database also makes it possible to move the vRanger installation with minimal effort.

The following versions of Microsoft SQL are supported for operation with vRanger.

Caution If you chose to use Microsoft SQL Server instead of SQL Express, the SQL Server application must be installed on the vRanger Machine in order for the cataloging feature to function. For more information, see “Installing the Databases” on page 78

SQL 2005SQL 2005 SP1SQL 2005 SP2SQL 2005 SP3

SQL 2008SQL 2008 R2

Page 18: VRanger 5.2.1 DeploymentGuide Rev1

18vRanger Overview

The vRanger Backup ProcessWith Inventory Node Selection, you can browse the VirtualCenter (vCenter) inventory and select which VMs or groups (folders) you wish to backup. You can select a VM, ESX host, folder, resource pool, datacenter, or vCenter and backup all of the VMs located under that node in the tree.

vRanger uses VMware snapshot technology to temporarily store incoming write requests while the VM is being backed up. After the backup completes, the snapshot is deleted, which commits those pending writes to disk. vRanger can backup a VM that already has an open snapshot and will backup the open snapshot, but any secondary consolidated helper backups will be closed prior to running the backup.

Backup Limitations

vRanger cannot backup physical RDMs (raw device map) partitions. You should see the warning: “incompatible drive detected”. Virtual RDMs (vRDMs) are supported.

For more detailed information on backup features supported by various configurations, please see the tables below.

• “Usage Compatibility Matrix - Compression” on page 110

• “Usage Compatibility Matrix - Space Saving Technologies” on page 111

• “Usage Compatibility Matrix - VM Disk Configurations” on page 112

What Changes in the Guest OS

By default, vRanger does not place any code into the Guest OS. Starting with vRanger 4.5, the vzShadow.exe executable will be included with the application download. vzShadow.exe is an optional component that can, if you choose, be installed on Windows VMs to provide an additional level of consistency. For more information, please see “Guest Quiescing” on page 82.

What Changes on the Source

While vRanger does not permanently install anything on the source ESX Servers, several tools are uploaded when a backup or restore task is run. Once the task is completed, these tools are removed. The tools are uploaded to the /tmp/.vzbin directory. The table below lists the tools that are uploaded:

Page 19: VRanger 5.2.1 DeploymentGuide Rev1

19vRanger Overview

Note For VMware ESX servers, these files are uploaded and run in the COS. For VMware ESXi, nothing is changed on the source server.

Tool Description

backup.exe backs up VM disks to a repository as a archive file

cleanup.exe deletes any orphaned temp files

delete.exe removes one archive file from a repository

deleteall.exe removes all archive files from a repository

filter-and.exe combines 2 filter files (for backup) into 1 by doing bitwise-and on each bit.

free.exe Checks the repository for sufficient free space.

metadata.exe writes metadata associated with a VM backup

restore.exe restores an archive file to a host

sizes.exe returns the size of a var file

sprinkle.exe re-arranges the original vRanger 4.0 repository structure to the current model.

ssh.exe Used for SSH connections.

touch.exe verifies access to a repository by writing and deleting a file

vddkd.exe used to engage the vStorage API for ESXi backups and LAN-Free backups.

vznwinio.exe an intermediate tool used in conjunction with vRanger’s file-level restore tool.

verify.exe verifies the existence of files in a repository

Page 20: VRanger 5.2.1 DeploymentGuide Rev1

20vRanger Overview

Available Backup ArchitecturesvRanger 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). Each option is described below, along with some common advantages and considerations.

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 option is to use the vRanger’s HotAdd functionality. 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.

Page 21: VRanger 5.2.1 DeploymentGuide Rev1

21vRanger Overview

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 Disadvantages

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

Performs better with a larger number of ESX servers

Page 22: VRanger 5.2.1 DeploymentGuide Rev1

22vRanger Overview

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.

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

Page 23: VRanger 5.2.1 DeploymentGuide Rev1

23vRanger Overview

LAN Free Mode

vRanger can operate in two LAN-Free modes, traditional (using a physical proxy connected to your fibre infrastructure, or HotAdd (with vRanger installed in a VM).

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 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.

Advantages Disadvantages

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

Performance is slightly slower than traditional LAN-Free methods.

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

Page 24: VRanger 5.2.1 DeploymentGuide Rev1

24vRanger Overview

Advantages Disadvantages

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

Page 25: VRanger 5.2.1 DeploymentGuide Rev1

25vRanger Overview

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 for each backup job.

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:

• From the start menu, select "run" and enter diskpart.

• oRun the automount disable command to disable automatic drive letter assignment.

• 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.

LAN Free - HotAdd

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

Page 26: VRanger 5.2.1 DeploymentGuide Rev1

26vRanger Overview

installed on a virtual machine residing on an ESX(i) host connected to your fibre or iSCSI network.

Advantages Disadvantages

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

Page 27: VRanger 5.2.1 DeploymentGuide Rev1

27vRanger Overview

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 options.

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:

• From the start menu, select "run" and enter diskpart.

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

• Run the automount scrub command to clean any registry entries pertaining to previously mounted volumes.

Page 28: VRanger 5.2.1 DeploymentGuide Rev1

28vRanger Overview

The vRanger Restore ProcessUsing vRanger, recovery of an entire VM, multiple VMs, or individual files are simple processes. Configure a restore job to include particular VMs but exclude certain disks. Not only can you elect to restore only two of a VM’s four disks, you can do this while the VM is running and the other disks are not impacted. vRanger’s inline data validation for restore ensures that the data in the backup matches the data in the restore.

Data streaming is used with incremental and differential restores to speed up the restoration process. During the traditional restoration process of a VM, you restore the full backup first and then restore each incremental -one at a time - starting with the oldest one. This is very time consuming and inefficient.

vRanger Data Streaming allows each savepoint in a set, if it has the most recent instance of a block, to transfer that block from the repository to the VM(s) specified in the restore job. All of the savepoints transfer their blocks in parallel, resulting in an extremely fast restore, almost as fast as restoring a single full backup. With the speed of incremental restores, backup administrators may consider doing incrementally rather than doing full backups every night and saving lots of repository disk space.

The only caveat is that if any of the incremental savepoints in the set are corrupted on disk or corrupted during network transfer, the set becomes unusable.

For more detailed information on restore features supported by various configurations, please see the table below.

• “Usage Compatibility Matrix - Restore” on page 114

FLR Process

vRanger allows the restore of one or more files from a compressed or uncompressed full, differential, or incremental backup.

FLR Limitations

• Linux - File level restores from Linux VMs requires the use of a virtual appliance

• Files can only be restored to a Windows server.

• FLR is not supported with GPT partitions.

• FLR is not supported from dynamic disks.

Page 29: VRanger 5.2.1 DeploymentGuide Rev1

29vRanger Overview

Catalog Search

vRanger includes the option to collect and record file and directory information during the backup process. This information is stored in a catalog database, and used to enable a Browse and Search function that speeds and simplifies file level recovery.

During the backup transfer process, the source volume is mounted to achieve volume level access using VMware’s vStorage API. As a process independent of the backup transfer, data about the volumes files and directory structure is captured and recorded. Once the backup has been verified as successful, the catalog data is activated and available for searching. If there is a backup failure, the catalog data is deleted. Catalog data is also deleted when the corresponding savepoint is purged by retention policies.

Catalog collections are disabled by default, as there may be a slight performance impact. Collection must be enabled globally through vRanger’s Tools>Options menu. Collection must also be enabled on a per-job basis. Once enabled, if catalog collections are disabled in the future, the catalog data will be retained in line with retention policies.

In order to get the best performance and reliability from the cataloging function, the following recommendations are made:

• The catalog database can grow quite large. Please give careful consideration to the location of the database installation. If the default SQL Express installation is used, the catalog database will have a size limit of 4 GB.Please refer to “Sizing the Catalog Database” on page 78 for sizing information and recommendations for the cataloging database.

• Take advantage of the catalog filtering option to avoid recording data for system and program files. This will greatly reduce the number of files cataloged per backup, which will improve performance and limit database growth. For more information on filtering, see “Filtering Catalog Collections” on page 86.

vRanger RepositoriesDesigned for ease-of-use in recovery operations, repositories eliminate the need for countless backup locations and endless configurations. With vRanger, you can configure a repository once, and use it forever.

Repositories can be either in the CIFS, FTP, SFTP, or NFS (version 3) format. VMware VMFS does not support SFTP, so the SFTP repository must be located on a separate Linux or Windows server running the SFTP service.

Page 30: VRanger 5.2.1 DeploymentGuide Rev1

30vRanger Overview

Repository Structure

A repository is essentially a directory on a supported file system that vRanger uses to store savepoints (backup archives). When viewed from outside vRanger (through Windows Explorer, for example), a repository consists of a configuration file (GlobalManifest.metadata) and root level directories for each protected object.

Any time you add a repository in vRanger a GlobalManifest.Metadata XML file is created in the selected directory. It is the presence of that manifest file that tells vRanger that a repository exists in that folder.

Whenever you add a repository, that repository contains a global manifest XML file that provides details about the repository. As you do backups, an entry is placed in the global manifest file. The global manifest file is required when restoring a deleted repository.

Inside the root level directory for each object are sub-directories created for each full backup of the object in question. Differential or incremental savepoints will reside within the full backup sub-directory.

Inside the sub-directories are archives for every file protected during that task. Also in the sub-directory are two metadata files. The image below depicts a basic repository structure:

The tables below describe the naming conventions for the repository files and folders.

Root Level Directories - Naming Structure

Name Structure <ObjectName>_<ObjectUUID>

ObjectName The name of the protected object

Page 31: VRanger 5.2.1 DeploymentGuide Rev1

31vRanger Overview

ObjectUUID A unique identifier for the protected object. In the case of a VMware ESX VM this would be its UUID.BIOS

Full Backup Sub-directory - Naming Structure

Name Structure <ObjectName>_<Date>_<Time>_<JobTemplate UUID>

ObjectName The name of the protected object

Date The date the task started in YYYYMMDD format.

Time The time the task started, in 24 format HHMMSS.

JobTemplate_UUID The UUID of the job template that the backup task was spawned from.

Note This is not the same as the object UUID.

Archive File - Naming Convention

Name Structure

<ObjectName>_<Date>_<Time>_<JobType>_<FileIndex>_<FileName>_<Extension>

ObjectName The name of the protected object

Date The date the task started in YYYYMMDD format.

Time The time the task started, in 24 format HHMMSS.

JobType A single character representing the type of job. • F - for full backup, • I - for incremental, • D - for differential

FileIndex The index of the file in the backup order for the current task. This is not guaranteed to remain constant for the same input file between tasks. This is present to ensure there can be no filename collisions.

FileName The name of the input file minus extension

Root Level Directories - Naming Structure

Page 32: VRanger 5.2.1 DeploymentGuide Rev1

32vRanger Overview

Savepoints

When a backup task runs, a savepoint is written to the specified repository. A savepoint consists of three files - the archive itself and two small XML files, the Manifest.metadata and the VmConfig.metadata. The savepoint manifest and the VmConfig.metadata file together are equivalent to the .info file used in vRanger 3.x.

Whenever you do a backup, the job writes a savepoint to the specified repository along with a corresponding savepoint manifest XML file. The savepoint manifest provides details about the backup job. The savepoint manifest is placed in the repository’s folder for that job. The items in the blue box below represent one savepoint.

Extension The extension of the file. If the input file has no extension it should be set to an empty string

Metadata File - Naming Convention

Name Structure <ObjectName>_<Date>_<Time>_<JobType>.<Key>

ObjectName The name of the protected object

Date The date the task started in YYYYMMDD format.

Time The time the task started, in 24 format HHMMSS.

JobType A single character representing the type of job. • F - for full backup, • I - for incremental, • D - for differential

FileIndex The key portion for the metadata file. This value is either “Manifest” or “VmConfig”.

Archive File - Naming Convention

Page 33: VRanger 5.2.1 DeploymentGuide Rev1

33vRanger Overview

If we assume an incremental backup job with a Threshold Count setting of “2”, you will get a full backup savepoint and two incremental savepoints (the first savepoint of an incremental job is always a full backup).

Each of the three savepoints will have their own savepoint manifest. These savepoints and their respective manifests will be placed in a single folder in the repository that represents the job.

Repository Size

There is no limit to the number of savepoints that can be stored in a vRanger repository. There are, however, environmental limits on the size of a single directory. The available options, and their limits, are described below.

Tip When sizing vRanger repositories, allow for maintaining at least 5 GB of free space.

Note The volume limitations described in this section are limitations within the Microsoft Windows environment.

• Default Configuration- A standard volume, with an MBR partition on a basic disk, has a limit of 2 TB. This is the default configuration for Windows Server 2003. In this configuration, the vRanger repository cannot exceed 2 TB.

• Dynamic Disks - Dynamic disks contain dynamic volumes, including simple volumes, spanned volumes, striped volumes, mirrored volumes, and RAID-5 volumes. A repository located on dynamic disk volumes can be as large as 64 TB.

Page 34: VRanger 5.2.1 DeploymentGuide Rev1

34vRanger Overview

For more information, see the Microsoft TechNet article: http://technet.microsoft.com/en-us/library/cc773268(WS.10).aspx

• GPT Volumes - GPT provides a more flexible mechanism for partitioning disks than the older Master Boot Record (MBR) partitioning scheme that has been common to PCs. GPT partitions are supported on Windows Server 2003, SP1 and later, and can reach up to 256 TB. For more information, see http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx

Note FLR will not work from a GPT Partition.

The vRanger Replication ProcessvRanger includes an integrated replication based on the proven technology of vReplicator. There are two options for replication: standard replication using the service console; or replication via virtual appliance (required for replication to or from VMware ESXi). The replication process is the same for each method, except as noted.

A VM is made up of a set of files, which means that replicating a VM is, in essence, replicating the set of files that make up the VM, with changes to these files that reflect user specified settings for the target VM.

The set of files replicated by vReplicator is listed below:

File Extension Description

.vmx The VM config file, one per VM

.vmxf The extended VM config file, one per VM

.nvram The VM BIO file, one per VM

.vmdk The VM hard disk file, one per hard disk or snapshot

-flat.vmdk The VM hard disk data file, one per hard disk or snapshot

-delta.vmdk The VM snapshot data file, one per snapshot

-ctk.vmdk The VM hard disk change tracking file when CB is enabled on the disk

Page 35: VRanger 5.2.1 DeploymentGuide Rev1

35vRanger Overview

During the replication process, the configuration files will be created and modified on the target server via the VMware API.

A set of working files is also created and used during the replication process. These files and their purposes are listed below:

File Extension Description

.vzmap Records data block offset and hash of files on the target VM. A .vzmap file is created for each of the files replicated at the end of the replication. The .vzmap file is used by the next replication pass to detect any data changes since the previous pass. It stays on the target VM as long as the job is still configured to run.

Note These files are only used in Hybrid mode for VM disk -flat and -delta files.

vzundo-script A script created by the replication process to roll back changes on the target VM in case of a replication failure. This file created in the target VM folder at the beginning of the replication process and removed at the end.

.vzundo This is a temporary file that records original data of changed blocks since the replication started. One for each file replicated. In case of a replication failure such as network failure, vzundo-script can be executed to restore files to their original state. These files are created by the replication process and removed when the job is completed.

.vmdk-abbt.vztemp Active block filter file. One for each hard disk data file when ABT is enabled. It records active data block offsets for source VM disks. This file is used against the .vzmap file to figure out data blocks that need to be streamed to the target. It is created at the beginning of the replication process and removed when disk replication is completed.

Page 36: VRanger 5.2.1 DeploymentGuide Rev1

36vRanger Overview

When replication is executed through the virtual appliance, handling of these files will change:

• Working files that only exist during the replication process shall be written to a temporary directory of the VA, since their existence is relevant to the BET on the VA

• Working files that exists across replication processes shall be written to their original location, since these are not truly temporary files and should be reference-able even when the job is modified to not use a VA

• The .vzmutex file shall no longer be checked similar to how it is handled in ESXi backup

vRanger support three modes of replication: Change Block Tracking (CBT), differential and hybrid, all with the option of Active Block Mapping (ABM). Note that there is no option for CBT replication. If CBT is enabled on a VM, differential repliction will query for the changed blocks without a scan.

.vmdk-abfg.vztemp Change block filter file. One for each hard disk when CBT is enabled. It records changed block offsets for source VM disks. This file is only generated when CBT and ABT are both enabled. It will later be combined with the .vmdk-abbt.vztemp file into -flat-map.vztemp and removed.

-flat-map.vztemp Disk data filter file. One for each hard disk when one of two situations are true: CB is enabled, or both AB and CB are enabled. It contains active/changed data block offsets that need to be compared to the .vzmap file at the target in order to figure out data blocks that need to be streamed to the target. It is created right before file replication starts and removed when file replication is completed

.vzcid Records target VM disk CIDs at the end of the replication pass.

.vzmutex Lock file. Indicate ownership of the VM by the current Quest application.

Page 37: VRanger 5.2.1 DeploymentGuide Rev1

37vRanger Overview

VM replication in general starts with replicating the source VM to the target host. Changes are applied to the target VM at user designated intervals to keep the target in sync with the source. Thus the key areas of difference among the replication modes are:

• Base target VM creation

• Detection and application of changes to the base target VM

• The rest of the section describes each replication mode in more detail.

Differential/CBT Replication

The flowchart below, and the steps that follow, describe the process for differential replication.

Page 38: VRanger 5.2.1 DeploymentGuide Rev1

38vRanger Overview

Base target VM creation

1 Snapshot source VM

2 Capture source VM config

3 Create target VM based on source config

Page 39: VRanger 5.2.1 DeploymentGuide Rev1

39vRanger Overview

4 Fill disk data and retain disk hash map

5 Persist target CID map

6 Register target VM

7 Fix network configuration on target VM

8 Delete source snapshot

Subsequent replication pass

1 Verify CID in sync

2 Snapshot source VM

3 Capture source VM config

4 Update target VM based on source config

5 Compare source disk hash with vzmap on target

6 Transfer changed blocks over to the target disk and retain new target hash

7 Update CID map

8 Refresh target VM

9 Fix network configuration on target VM

10 Delete source snapshot

Hybrid Replication

The flowchart below, and the steps that follow, describe the process for hybrid replication.

Note You should only use Hybrid Replication if CBT is not an option. Replication with CBT is the preferred method. Hybrid replication is not supported when using the vRanger virtual appliance.

Page 40: VRanger 5.2.1 DeploymentGuide Rev1

40vRanger Overview

Initial pass

Hybrid replication is also known as snapshot rotation replication. It makes use of the differential engine for its initial pass and leaves the source snapshot open after the initial pass for snapshot rotation.

Page 41: VRanger 5.2.1 DeploymentGuide Rev1

41vRanger Overview

Subsequent passes

1 Verify CID in sync

2 Add new rotational snapshot to source VM

3 Snap target VM

4 Capture source VM config

5 Update target VM based on source config

6 Replicate rotational snapshot from source to target

7 Delete target snapshot

8 Delete old rotational snapshot from source

9 Update CID map

10 Refresh target VM

11 Fix network configuration on target VM (this step merges into step 5 in FMO)

Switching from Differential to Hybrid

Since Hybrid replication depends on an open snapshot at the source VM which is not created by differential replication, when a replication job is changed from Differential to Hybrid, the first replication after the job configuration change should still be differential on the back end. However, the source snapshot is not removed at the end of the replication pass in order to prepare for the next replication pass.

Switching from Hybrid to Differential

The initial pass after the job configuration change should delete the rotational snapshot created by the previous hybrid pass and reopen a new one to perform a full replication.

Page 42: VRanger 5.2.1 DeploymentGuide Rev1

Deploying vRanger

This section provides information on configuring your environment and deploying vRanger.

This portion of the document contains the following sections:

The Deployment Environment .....................................................................................................44

Environment Configuration Recommendations ...........................................................................54

VMware Recommendations ........................................................................................................59

Common Configuration Issues ....................................................................................................71

Page 43: VRanger 5.2.1 DeploymentGuide Rev1

The Deployment EnvironmentThis chapter outlines the recommendations and best practices for configuring your virtual environment with vRanger.

This chapter contains the following sections:

The Deployment Environment ...............................................................................................44

Environmental Requirements .............................................................................................44

Choosing a vRanger Deployment Architecture ...................................................................47

Small Environments (1-30 VMs)..................................................................................47

Mid-Size Environments (30-100 VMs) .......................................................................49

Large Environments (100+ VMs) .................................................................................52

Environment Configuration Recommendations ..................................................................54

Recommendations for Network Backups .....................................................................54

Recommendations for Fibre Backups ...........................................................................55

Recommendations for Replication ................................................................................56

SAN Setup Recommendations..............................................................................59

VMware Recommendations ...................................................................................................59

vRanger Repositories...............................................................................................................68

Common Configuration Issues...............................................................................................71

Page 44: VRanger 5.2.1 DeploymentGuide Rev1

44The Deployment Environment

The Deployment EnvironmentThe 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 to ensure proper operation of vRanger.

Environmental Requirements

There are some configurations required to be in place before vRanger will function properly.

Port Requirements

The diagram below depicts the ports used by each of the vRanger components.

Caution Replication with vRanger requires an SSH tunnel between the production site and D/R site. Port forwarding is not supported with vRanger replication.

Note A continuous connection between source and target sites is required when replication is taking place. Excessive network packet loss could result in replication failure. Replication

Page 45: VRanger 5.2.1 DeploymentGuide Rev1

45The Deployment Environment

will work with links having average packet loss of less than 2%. Replication is not designed to work in replication environments where packet loss can exceed commercially accepted limits. Networks having an of 99% Uptime/Availability will generally provide for good Replication performance.

VMware Requirements

The table below lists the versions of VMware platform components supported by vRanger.

vRanger supports backup, restore, and replication operation against the following versions of VMware Infrastructure:

Caution vRanger only supports VMware ESX(i) Servers running in English. No other language packs are supported.

Other VMware Requirements

• Licensing - Every ESX/ESXi host for which vRanger is expected to provide protection must be properly licensed, both by VMware and in the vRanger Host Licensing tab. While vRanger can restore to a host for which you have not

ESX(i) Server* vCenter Server VCB

• 3.5• 3.5 Update 1• 3.5 Update 2• 3.5 Update 3• 3.5 Update 4• 3.5 Update 5• 4.0• 4.0 Update 1• 4.1• 4.1 Update 1

• 2.5• 2.5 Update 1• 2.5 Update 2• 2.5 Update 3• 2.5 Update 4• 2.5 Update 5• 4.0• 4.1• 4.1 Update 1

VCB integration is not supported in this release.

* Support for ESXi requires VMware’s vStorage API. The vStorage API is not available with the free version of ESXi Server. Please be sure to have the appropriate platform licensing level before attempting ESXi backups. * ESXi replication requires the use of the vRanger virtual appliance.

Page 46: VRanger 5.2.1 DeploymentGuide Rev1

46The Deployment Environment

purchased a vRanger license, the application does not support the free versions of VMware ESXi.

Storage Requirements

• Dynamic Disks - While not a requirement, several vRanger features (most notably File-Level Restore) are not compatible with dynamic discs.

Page 47: VRanger 5.2.1 DeploymentGuide Rev1

47The Deployment Environment

Choosing a vRanger Deployment ArchitectureChoosing the correct architecture for your vRanger deployment is the single most important decision you can make in order to optimize the speed of your backups and restores. Choose the fastest option available given your network and storage considerations.

Small Environments (1-30 VMs)

Smaller environments will typically deploy a simple, network-based architecture using local storage or a small array. The image below depicts the logical deployment of vRanger in a typical small environment.

The key elements of this deployment are identified by numerals in white circles. The numbers in the image correspond to the descriptions below.

1 The vRanger machine - in a smaller environment, this can be a VM or perhaps an administrators workstation. In a network-based deployment, no backup traffic flows through the vRanger machine.

Page 48: VRanger 5.2.1 DeploymentGuide Rev1

48The Deployment Environment

2 The vCenter Server - while vRanger can connect directly to an ESX host, only editions of VMware Virtual Infrastructure or vSphere that include vCenter are supported. It is not recommended to install vRanger on the vCenter Server.

3 VMware ESX hosts - in the network deployment shown above, backup data is sent directly from the ESX host to the repository. Processing functions (compression, block comparisons, etc) occur in the Service Console of the ESX Server hosting the VMs being backed up.

4 vRanger Repository - Repositories are a supported storage device located somewhere in your environment, and configured as a repository within vRanger. Backup data flows directly from the ESX hosts to the Repository- bandwidth to the repository is a significant factor in determining the maximum number of simultaneous backups jobs.

5 D/R Location - in order to protect business operations in the event of a localized failure, business critical VMs should be replicated to an offsite D/R location. This may be a remote office, but for smaller deployments will most likely be capacity rented from a service provider.

Note D/R locations must be connected to the production environment via an IP tunnel for successful replication. For more information, see “Recommendations for Replication” on page 56.

Network Based Architecture

This is the default option out of the box, as it will apply to most configurations. In this configuration vRanger is typically installed in a VM. The table below lists the key benefits of this configuration, along with some important considerations.

Benefits Considerations

• Communications via Service Console NIC

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

• Allows for leveraging Direct-to-Target

• Sufficient throughput for small environments

• vRanger can be installed in a VM or on a Physical server

• Performs better with a larger number of ESX servers that are less VM/data dense

• SC NIC is a limiter of throughput• Works well for small environments or

deduplication environments

Page 49: VRanger 5.2.1 DeploymentGuide Rev1

49The Deployment Environment

Mid-Size Environments (30-100 VMs)

Mid-sized environments offer more complexity as the number of ESX hosts and VMs increases and multiple storage configurations are used. In a mid-sized environment, backup traffic is typically isolated to avoid impacting the production network.

Figure 1

The key elements of this deployment are identified by numerals in white circles. The numbers in the image correspond to the descriptions below.

1 The vRanger machine - in a mid-sized environment, this should be a virtual machine with access to the datastores for any VMs it will be configured to back up. Many environments of this size will include both VMware ESX and ESXi servers. With this configuration, vRanger can leverage VMware’s HotAdd functionality to speed network backups of ESXi servers.

2 The vCenter Server - while vRanger can connect directly to an ESX host, only editions of VMware Virtual Infrastructure or vSphere that include vCenter are supported. It is not recommended to install vRanger on the vCenter Server.

3 VMware ESX(i) hosts - in the deployment shown above, backup data is isolated to a separate backup network. If ESXi hosts are to be backed up, this traffic will be routed through the vRanger machine to the repository.

Page 50: VRanger 5.2.1 DeploymentGuide Rev1

50The Deployment Environment

4 vRanger Repository - Repositories are a supported storage device located somewhere in your environment, and configured as a repository within vRanger. Backup data flows directly from the ESX hosts to the Repository- bandwidth to the repository is a significant factor in determining the maximum number of simultaneous backups jobs.

5 D/R Location - in order to protect business operations in the event of a localized failure, business critical VMs should be replicated to an off site D/R location. This may be a remote office, or capacity rented from a service provider.

Note D/R locations must be connected to the production environment via an IP tunnel for successful replication. For more information, see “Recommendations for Replication” on page 56.

Mid-sized environments will typically use a combination of backup methods based on server or workload configuration. For information on network based backups, see “Network Based Architecture” on page 48. For information in iSCSI and VMware ESXi backups, please see the sections below.

iSCSI Backups

This is a high performance configuration that requires that vRanger is installed on a physical or virtual server with access to the target datastores.

The table below lists the key benefits of this configuration, along with some important considerations.

ESXi Backups

vRanger includes support for VMware's HotAdd disk transport functionality which enables faster backup speeds for network backups of ESXi.

Benefits Considerations

• Communications via vStorage API to the ESX server and the iSCSI initiator to the target.

• Performs very well.

VERY IMPORTANT: Do not initialize the VMFS volume from the backup server. This will wipe out your VM data.

Page 51: VRanger 5.2.1 DeploymentGuide Rev1

51The Deployment Environment

The table below lists the key benefits of this configuration, along with some important considerations.

Benefits Considerations

• Target VM disks are mounted directly to the vRanger VM using VMware's I/O stack rather than through the network.

• vRanger can be installed in a VM.• Backup processing (whitespace removal,

compression) done before data is sent over the network.

• No direct-to-target.• vRanger cannot be installed on a

physical server.

Page 52: VRanger 5.2.1 DeploymentGuide Rev1

52The Deployment Environment

Large Environments (100+ VMs)

Larger environments are the most complex to configure, with a large number of VMs and storage devices, and often multiple repositories. The preferred architecture for larger environments is most often a LAN-Free configuration over fibre.

Figure 2

The key elements of this deployment are identified by numerals in white circles. The numbers in the image correspond to the descriptions below.

1 The vRanger machine - in a larger environment, this should be a dedicated physical server. Many environments of this size will include both VMware ESX and ESXi servers. Backup traffic for ESXi backups must flow through the vRanger machine as there is no Service Console to process backup operations.

2 The vCenter Server - while vRanger can connect directly to an ESX host, only editions of VMware Virtual Infrastructure or vSphere that include vCenter are supported. It is not recommended to install vRanger on the vCenter Server.

3 VMware ESX(i) hosts - in the deployment shown above, backup data is isolated to a separate backup network. If ESXi hosts are to be backed up, this traffic will be routed through the vRanger machine to the repository.

4 vRanger Repository - Repositories are a supported storage device located somewhere in your environment, and configured as a repository within vRanger.

Page 53: VRanger 5.2.1 DeploymentGuide Rev1

53The Deployment Environment

Backup data flows directly from the ESX hosts to the Repository- bandwidth to the repository is a significant factor in determining the maximum number of simultaneous backups jobs. In larger environments, multiple repositories may be desired.

5 D/R location - in order to protect business operations in the event of a localized failure, business critical VMs should be replicated to an off site D/R location. This may be a remote office, or capacity rented from a service provider.

Note D/R locations must be connected to the production environment via an IP tunnel for successful replication. For more information, see “Recommendations for Replication” on page 56.

Larger environments will typically use a combination of backup methods based on server or workload configuration. For information on Fibre Channel backups, please see the section below. For information on the other types of backup architecture, please see:

• “Network Based Architecture” on page 48

• “iSCSI Backups” on page 50

• “ESXi Backups” on page 50

Fiber Channel Backups

This is a high performance configuration that requires that vRanger is installed on a physical proxy server connected to your fiber network.

The table below lists the key benefits of this configuration, along with some important considerations.

Benefits Considerations

• Communications via vStorage API to the ESX

• vRanger must be installed in a physical proxy server

• Backups are isolated to the fiber channel infrastructure

• Performs very well.

• Performs best when backup from LUNs to other LUNs in the same fiber infrastructure

• VERY IMPORTANT: Do not initialize the VMFS volume from the backup server. This will wipe out your VM data.

Page 54: VRanger 5.2.1 DeploymentGuide Rev1

54The Deployment Environment

Environment Configuration RecommendationsIn order to maximize the performance of vRanger, and safeguard your production network, the following recommendations should be considered.

Recommendations for Network Backups

vRanger, by virtue of it’s Direct-To-Target architecture, pushes a lot of data through the network very quickly. While this performance is good for minimizing your backup window, if not configured properly it can degrade your production network.

An important best practice is to separate the backup traffic from the production network by configuring a dedicated backup network.

Note This approach requires that each ESX host and the vRanger machine have two NICs installed.

1 Using the first (primary) NIC, connect the vRanger server, the vCenter Server, and Service Console 1 of each ESX Server host. This becomes the primary production network for VM traffic.

2 In each ESX Server host, configure a second Service Console, connecting it to a dedicated NIC.

Page 55: VRanger 5.2.1 DeploymentGuide Rev1

55The Deployment Environment

3 Using the second NIC, connect: the vRanger server; each Service Console 2; and each repository. This becomes the dedicated backup network.

Note For the backup network, fibre NICs are preferred and will provide better throughput than 1Gb/sec Ethernet nics;

NIC Teaming

NIC Teaming is a feature of VMware Infrastructure that allows you to connect a single virtual switch to multiple physical Ethernet adapters. To utilize NIC teaming, two or more network adapters must be uplinked to a virtual switch. The main advantage of NIC teaming is increased network capacity for the virtual switch hosting the team.

When bonding NICs into a team, it is important to use NICs from the same vendor as different NIC vendors achieve bonding differently. When using teamed NICs with vRanger, it is critical that the NICs are teamed for performance rather than load balancing. vRanger backups are streamed as a continuous file - changing NICs during a data stream will cause backup errors.

For more information on NIC teaming, please refer to the VMware Knowledge Base article 1004088: http://kb.vmware.com/kb/1004088

Recommendations for Fibre Backups

vRanger uses VMware’s vStorage API for fibre (LAN-Free) backups through your storage infrastructure. You must be using a version of VMware ESX(i) that supports vStorage API in order to use LAN-Free backups.

vRanger requires the use of physical backup proxy servers to take advantage of LAN-Free backups. Use the requirements and recommendations in the sections below to guide you in the proper configuration of your backup proxies.

Proxy Requirements

• The backup proxy server must be a physical machine running one of the supported operating systems below. Depending on the size of your environment, more than one proxy may be required.

• Windows Server 2003 SP2 (x86, x64)

• Windows Server 2008 SP2 (x86, x64)

• Windows Server 2008 R2 (x64)

• The backup proxy must use Fibre Channel HBAs to connect to the SAN on which virtual machines reside.

Page 56: VRanger 5.2.1 DeploymentGuide Rev1

56The Deployment Environment

• It is recommended to use two HBAs - one for read operations and one for writing.

• vRanger must be installed on each proxy server.

Sizing Recommendations

When planning your proxy configuration, you must evaluate a number of factors and identify which are likely to become bottlenecks in your environment. Factors that you should consider when sizing your deployment.

• The number of virtual machines in your environment is the main factor that determines the size of your backup infrastructure. If there are a great many virtual machines, you must either allow longer backup times or allocate a significant amount of resources to meet time constraints. As a starting point for testing your deployment, Quest recommends using 1 backup proxy for every 10 hosts or 100 VMs.

• A factor coinciding with the number of VMs is the number of VMs that can be processed at once. vRanger includes the Maximum number of tasks running locally configuration option that will limit the number of simultaneous backups per proxy server.

As a starting point, plan on 1 concurrent task per CPU core. For example, if your proxy server has 8 cores, you should set the Maximum number of tasks running locally setting to 8.

Recommendations for Replication

The sections below describe the configurations recommended for best replication performance.

Choosing a D/R Site

A disaster recovery site can be cold, warm or hot. Each type of site has different recovery times and different corresponding infrastructure requirements and costs.

A Cold, or Offline, site consists of powered off servers. A cold site is generally the most affordable DR strategy, and provides the highest RTO of any of the site types. In a DR event the servers are booted up and backup images are restored to them. Replication is not applicable to a cold site, but backups can be used in this situation.

A Warm site holds a number of ESX hosts, powered on. Network communication is fully enabled between the production site and the DR site. The ESX hosts hold powered

Page 57: VRanger 5.2.1 DeploymentGuide Rev1

57The Deployment Environment

off replicas of production VMs, ready to be booted up at a moment’s notice. With a warm site, no production services are running.

Similar to a warm site, a Hot site consists of powered on ESX hosts. In addition, a hot site includes running production services. for example, Active Directory Domain Controllers, DNS servers and File Servers. A hot site usually results in the fastest time to recovery as many essential infrastructure services are already running, reducing the time required for business applications to come online.

When implementing a hot disaster recovery site, you can choose to use a combination of replication tools native to certain infrastructure applications as well as vRanger for other applications. For example, Active Directory, DNS, Exchange 2007, SQL Server and many other applications include native replication functionality. When deciding whether to use vRanger or native replication functionality, consider the following questions:

• Are there any extra licensing costs for using vendor native replication rather than using vRanger to replicate to a powered off image?

• Will using multiple replication techniques for different applications complicate the DR plan for limited marginal benefit?

It is usually beneficial to have live critical infrastructure components such as Active Directory and DNS available at a hot site to assist with a quick recovery.

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. Correct sizing of a link for replication traffic is part science and part art. As a general rule of thumb, you should ensure you have sufficient bandwidth to handle replicated changes to the source virtual machines, any extra traffic that may utilize the link, and overhead for large data changes such as service packs and application upgrades. 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

Page 58: VRanger 5.2.1 DeploymentGuide Rev1

58The Deployment Environment

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 significantly and aids with any live failover testing. Changing IP address during a high pressure disaster recovery event always complicates the process. This introduces a potential for error and may lengthen the time to recover business operations at the DR site. Bridging the production and DR networks should always be your first choice.

An alternative configuration is to use two virtual network cards for each virtual machine that you replicate. The dual virtual NIC approach complicates the architecture of the solution. It can, however, prove more cost effective in some situations.

Both of the virtual network cards should be configured with IP addresses; a production virtual NIC with a production IP, and a DR virtual NIC with a DR IP.

When running in production, NIC1 will have the production IP address and be connected to the production virtual switch on the production network. NIC2 will have the DR IP address, and will be connected a DR virtual switch disconnected from any networks.

On the replicated virtual machine, the configuration will be the same except on the ESX host layer. The DR ESX host’s “Production” virtual switch should be disconnected from the physical network, whereas the DR virtual switch should be connected to the network at the DR site.

If choosing to implement the dual network card approach, ensure you comprehensively test a full site failover to ensure that all routing considerations are taken into account.

Latency Limitations

Excessive network packet loss could result in replication failure. Replication is not designed to work in replication environments where packet loss can exceed commercially accepted limits, summarized by the requirements below:

Page 59: VRanger 5.2.1 DeploymentGuide Rev1

59The Deployment Environment

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

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

SAN Setup Recommendations

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

• The multipathing software from your SAN vendor should be installed and configured for performance.

• LUNs that are not accessible to the proxy server should be masked.

• On your storage device, zone your LUNs so that the vRanger HBA can see and read them.

• Only one proxy should see a set of VMFS LUN’s at one time. The proxy server should have only read-only access to the LUNs.

• Disable automount on the vRanger machine:

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

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

• Run the automount scrub command to clean any registry entries pertaining to previously mounted volumes.

VMware RecommendationsDuring standard backup operations, the ESX Service Console is used to run vRanger backup tools. The additional performance load placed on the Service Console should be addressed by implementing the suggestions below.

Service Console Configurations

Quest recommends that the two changes below are made on your ESX hosts to optimize the regular backup of VMs. These ESX resource reservations are not mandatory and recommended only for operation efficiency.

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

1 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.

Page 60: VRanger 5.2.1 DeploymentGuide Rev1

60The Deployment Environment

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

3 Select Expandable Reservation and Unlimited.

4 Click OK to save.

Increase the Service Console CPU Reservation to 1500 MHz

1 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. 

2 Adjust the CPU reservation slider up to 1500 MHz.

Page 61: VRanger 5.2.1 DeploymentGuide Rev1

61The Deployment Environment

3 Select Expandable Reservation and Unlimited.

4 Click OK to save.

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

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

2 On the Memory window, enter a value between 256MB and 800MB for the service console parameter.

Note: For troubleshooting purposes, VMware recommends that you increase the service console RAM to 800MB.

3 Click OK to save

Note Changes do not take effect until the ESX host is rebooted.

Enabling Changed Block Tracking

In order to take advantage of CBT for backup and replication jobs, it must be enabled for each VM for which you will use it. CBT is only available on vSphere (ESX 4.x) hosts and requires that VMs be at hardware version 7.

Page 62: VRanger 5.2.1 DeploymentGuide Rev1

62The Deployment Environment

You can enable CBT on a per-vm basis via the vRanger interface. If desired, you may also enable CBT on a large scale basis using a PowerShell script. For detailed examples see the vCommunity blog posting “Bulk Managing CBT for VMs”

Creating a vCenter User for vRanger

vRanger requires a vCenter account to function properly. To comply with security best practices, Quest recommends creating a vCenter user account with the minimum required permissions for vRanger to use.

The procedures differ slightly depending on which version of vCenter you are using. For vCenter 2.5, see the section below. For vCenter 4.0, please see “To create a vRanger vCenter account - vCenter 4.0” on page 64.

To create a vRanger vCenter account - vCenter 2.5

1 Using the VI Client, navigate to Administrator>Roles.

2 Select Add Role.

3 Enter a name for the Role, such as “vRanger Non-Admin”.

4 In the Privileges section, set the permissions according the table below:

Section Privileges

Global • Log Event• Licenses

Datastore • Browse Datastore• File Management

Host > Local Operations Create Virtual Machine

Virtual Machine > Inventory Create

Virtual Machine > Interaction • Power On• Power Off• Device Connection• Configure CD Media• Configure Floppy Media

Virtual Machine > Configuration Select all options in this section.

Page 63: VRanger 5.2.1 DeploymentGuide Rev1

63The Deployment Environment

5 Navigate to the Inventory view, and right-click the desired area to assign user permissions, such as “Host & Clusters”. Select Add Permission…

6 Add and locate the desired user, select the newly created User Role and click OK.

Virtual Machine > State • Create Snapshot• Remove Snapshot

Virtual Machine > Provisioning • Mark As Template• Mark As Virtual Machine• Allow Disk Access• Allow Read-only Disk Access• Allow Virtual Machine Download• Allow Virtual Machine Files

Upload

Resource Assign Virtual Machine To Resource Pool

Page 64: VRanger 5.2.1 DeploymentGuide Rev1

64The Deployment Environment

To create a vRanger vCenter account - vCenter 4.0

1 Navigate to Administration > Roles.

2 Select Add Role.

3 Enter a name for the Role, such as “vRanger Non-Admin”.

4 In the Privileges section, set the permissions according the table below:

Section Privileges

Datastore • Allocate Space• Browse Datastore

Global • Licenses• Log Event

Host > Local Operations • Create Virtual Machine• Reconfigure Virtual Machine

Network • Assign Network

Page 65: VRanger 5.2.1 DeploymentGuide Rev1

65The Deployment Environment

5 Navigate to the Inventory view

6 Right-click the desired level to grant user permission, such as the main VC level.

7 Add and locate the desired user account, and select the recently created User Role

Resource • Assign virtual machine to resource pool

Virtual Machine > Configuration • Select all options in this section.

Virtual Machine > Interaction • Configure CD Media• Configure floppy media• Device Connection• Power Off• Power On

Virtual Machine > Inventory • Create new

Virtual Machine > Provisioning • Allow disk access• Allow read-only disk access• Allow virtual machine download• Allow virtual machine files upload• Mark as template• Mark as virtual machine

Virtual Machine > State • Create Snapshot• Remove Snapshot

Page 66: VRanger 5.2.1 DeploymentGuide Rev1

66The Deployment Environment

VM Configuration for Replication

The configuration of the source virtual machines (the VMs that are being replicated) can have an impact on replication performance and the success of the DR plan.

vRanger supports replicating virtual machines that have VMDK and virtual mode RDM virtual disks. Ensure that any disk volumes that must be replicated are either VMDK or virtual mode RDMs.

Note Physical mode RDMs are not supported for replication.

As vRanger uses VMware snapshots for replication, ensure there is adequate storage for snapshots during the replication process and between replications (if using Hybrid replication). Snapshots are stored with the VMX virtual machine configuration file in the virtual machine’s primary data store.

Page 67: VRanger 5.2.1 DeploymentGuide Rev1

67The Deployment Environment

To ensure best replication performance, ensure that disk intensive activities are not scheduled to occur within virtual machines during a replication. Examples of these activities can include anti-virus cans or traditional, file-level backups.

Note As vRanger replicates at a block level, disk intensive activities that make a large number of block level changes such as disk defragmentation may cause a large number of changes to be replicated by vRanger and as such should be planned appropriately.

Data consistency of the replicated virtual machine at the point in time of replication can assist with a quick recovery of transactionally consistent environment if a disaster is encountered. Different replication configurations are available for different platforms. Many database platforms support VSS, such as Microsoft Active Directory, Exchange, SQL and certain versions of Oracle. For more information, see “Pre-seeding Replication Jobs” on page 80.

Page 68: VRanger 5.2.1 DeploymentGuide Rev1

68The Deployment Environment

vRanger RepositoriesRepository location, along with the configuration of jobs to those repositories, plays a significant role in the performance of vRanger. Use the recommendations below to aid on planning your repository configuration.

Tip When sizing vRanger repositories, allow for maintaining at least 5 GB of free space.

Repository Storage Devices

Slow disk performance has been shown to negatively impact the backup performance of vRanger. When configuring repositories, special attention should be paid to the type of storage devices used.

The use of SAS (Serial Attached SCSI) disk drives are recommended. SAS drives typically offer a 30% performance improvement over SATA drives.

The use of external USB drives or low quality NAS devices is not recommended. If these types of storage are used, the vRanger configuration settings must be adjusted to accommodate the slow devices. Recommended configuration settings for slower repositories are shown below. These configurations can be made in the vRanger Configuration Options dialogue, available on the Tools>Options menu.

• Maximum number of tasks running off a LUN = 3

• Maximum number of tasks running off a host = 1

• Maximum number of tasks running per repository = 2

If no errors are received with these settings, increment the tasks per repository value by 1 to find the best fit for your environment.

Bandwidth to Repositories

Backups and restores go “direct-to-target”, using a direct communication path between the ESX hosts and repositories. This allows for a high data throughput and a highly scalable backup “engine”. Without due consideration, however, this can also lead to network saturation and decreased backup performance.

While performance varies based on environmental factors, data throughput during a single backup task can reach up to 100 MB/s. If we assume a standard case of a Repository connected via a Gigabit network, then as little as ten concurrent jobs can saturate the link to that repository.

Page 69: VRanger 5.2.1 DeploymentGuide Rev1

69The Deployment Environment

Although there is no ability to throttle data transmissions from an ESX host, vRanger can limit the number of simultaneous backup tasks on a per-repository level.

Note This configuration is a global configuration, meaning that it applies to all repositories.

If you have need a repository located at a remote site, the WAN link will most likely become the limiting factor in job configuration. Rather than limit all vRanger tasks to fit the limited bandwidth, it is recommended to install a second vRanger application to be used to manage backups 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.

Testing Repository Connections

In order to eliminate potential problems during backup jobs, you should test your repository configuration prior to configuring and running backup tasks.

Test Connection Speed

The connection between the VMware ESX host and the repository is critical for backup success. A simple ping test from the ESX host to the repository should provide an initial verification of connectivity.

To Ping the Repository

1 Launch a TTY terminal emulator (PuTTY, for example).

2 Provide the FQDN of the ESX host. This will confirm that DNS is functional.

3 Login with root or other ESX service console credentials.

4 At the command prompt, type ping <repository-host-name> to confirm that DNS is working.

5 If the ESX host has multiple NICs, optionally specify the NIC on the same subnet as the repository: ping -I <interface-address> <repository-host-name>.

6 Record your response times.

7 Logout or press Ctrl+D to end the TTY session.

Results

The expected result is a response time around 1 ms (or less).

Response times in the 50-60 ms range usually indicate that traffic is crossing one or more routers or firewalls. Due to the excessive CPU/memory load that backup traffic

Page 70: VRanger 5.2.1 DeploymentGuide Rev1

70The Deployment Environment

will place on a router and/or firewall, it is best to avoid passing that traffic through them.

Response times longer than 100ms may cause TCP/IP timeouts during backups. Usually, response times in this range indicate that the backup traffic will be crossing a WAN link. If this is the case, consider a separate vRanger installation to manage these remote jobs.

Test Repository Permissions

To eliminate the possibility of ESX server repository combination problems, do a simple read/write test from the ESX service console to the repository by mounting a share on the ESX host and then using the Linux touch command to create new, empty files.

To test permissions:

1 Confirm that the share has Full Control share permissions and at least Modify folder permissions.

2 Using SSH, connect to the ESX host.

3 Run the command mkdir /mnt/backup.

4 Run the command esxcfg-firewall -e smbClient.

5 Run the command mount -t smbfs //<repository-server>/<share> /mnt/backup -o username=<useraccount> .

Note For vSphere 4.0, replace “smbfs” in the above command with “cifs”.

6 If the mount fails, set the folder permissions to Full Control.

or

If the mount is successful, run the command touch /mnt/backup/testfile. If the touch command is successful, the ESX host should be able to perform a backup to the repository.

7 Run the command unmount /mnt/backup to clean up the mount.

Page 71: VRanger 5.2.1 DeploymentGuide Rev1

71The Deployment Environment

Common Configuration IssuesThere are configuration issues that can have negative effects on the performance of your VMware environment and your DR operations.

It must be understood that the cumulative effect of having many of these small problems means major performance issues in your virtual environment. The good news is that these problems are easily identified with the right knowledge and tools and easily fixed once identified.

The sections below list common issues and tips for each of the main configuration areas.

Storage

The three most common storage configuration issues are described below:

Too many LUNS per Array

Many types of storage are improperly configured as one large array. While this is the only available option for some iSCSI devices, this configuration will not scale well in disk I/O intensive environments.

In this configuration, you may find that your SAN becomes unusable from a practical standpoint long before you run out of storage space because a VM disk I/O will affect all other VMs.

For more information on LUN configuration in a VMware environment, please refer to VMware’s VMFS Technical Overview and Best Practices white paper.

Wasted Space

It is a common industry practice to over-allocate disk space to allow for data expansion. When planning, virtual administrators have to guess how much space to assign, with the primary consideration being “How much is more than enough?”

The reality is that a few of the VM’s will eventually use all of the space assigned, but most will not. All of these VMs contribute to WASTED SPACE and shorten the life of expensive storage devices.

Page 72: VRanger 5.2.1 DeploymentGuide Rev1

72The Deployment Environment

Mis-aligned Volumes

VMFS partitions that are not aligned to 64kb boundaries suffer a performance decrease of approximately 7-12%. In addition, if you have VMs that are being replicated using block level replication techniques - and you properly align those VMs - you can reduce your replication bandwidth requirements by up to 50%. Incremental/differential space requirements can also be reduced by up to 50%.

Note If your partitions were created using the vSphere (ESX 4.0) client, then they should have been automatically aligned to the 64kb boundary.

For more details on partition alignment, see the VMware document “Recommendations for Aligning VMFS Partitions”.

Network

The two most common network configuration issues are described below:

Understanding Default Load Balancing

The default load-balance configuration in VMware ESX is NOT statistical load balancing. Instead, it is a round-robin approach to load balancing which can lead to one NIC much more heavily used than the others.

The default option will not provide aggregate bandwidth to a single virtual machine. This will effectively function as active/passive with only 1 NIC being active. ESX supports alternative load-balancing methods such as 802.3ad link aggregation

Broadcasts

Broadcasts can crush your ESX server performance even when the total amount of broadcasts is low in terms of bandwidth. This can be resolved by the proper allocation

Page 73: VRanger 5.2.1 DeploymentGuide Rev1

73The Deployment Environment

of VLANs. When configuring your virtual network, make sure that server VMs are in VLANs that are isolated from user networks. User networks contain a large number of PC’s that issue a lot of broadcasts, which slow server performance because of interrupts.

Memory

The following memory configuration issues are commonly found in VMware environments.

Improper VM limits

A limit is a restriction on the VM, so it cannot use more memory than this limit. VMs often have limits set that are much lower than their RAM allocation. If the limit is set lower than the allocated memory value, the ballooning driver will start to inflate as soon as the VM demands more memory than this limit.

For more information on this topic, please see the blog article below:

http://www.vmguru.com/index.php/articles-mainmenu-62/mgmt-and-monitoring-mainmenu-68/96-memory-behavior-when-vm-limits-are-set

Low Amounts of Shared RAM

ESX servers scan pages of RAM periodically, searching for duplicate pages. When duplicate pages are found, the ESX server uses a single, read-only copy of the page in RAM and shares it among the VMs that have that page in common. If a VM attempts to change a shared memory page, a new read-write copy is created in RAM for that VM. The others continue to use the shared RAM as long as they have it in common.

Note that when an ESX server is booted, the common RAM is not instantly shared. The memory scanning process occurs at intervals over time - an overcommitted environment with a lot of shared RAM could still experience performance problems if multiple VMs are booted at the same time.

Using the same OS and patch revisions in your VMs can significantly increase the amount of shared RAM in your ESX environment. This, in turn, allows you to use more VMs with the available RAM in your environment.

CPU

The most common CPU configuration issues involve incorrectly configuring multiple vCPUs, which lead to a high % Ready value. This is described in more detail below.

Page 74: VRanger 5.2.1 DeploymentGuide Rev1

74The Deployment Environment

Multiple vCPU VMs and % Ready

VMs don’t reside on a processor all of the time- they are scheduled on demand onto a processor. Note that a VM cannot be schedule to a processor until all of the cores required for that VM are available simultaneously. Mixing single, dual and quad vCPU VMs on the same ESX server will lead to an increase in CPU % Ready that will severely affect VM performance. A % Ready measurement should never exceed 4%, and even at that rating you may experience performance degradation.

To avoid this, reduce your VMs (where possible) to single vCPU VMs. If you have large amounts of VMs that require multiple vCPUs, separating these VMs onto their own clusters improves scheduling.

When performing P2V migrations, reduce low utilization servers to a single vCPU. To do this, you will have to:

• change the HAL (Windows) or kernel configuration (Linux)

• change this inside of the guest OS. Changing it at the VM setting level is not enough.

If there is a mismatch between the number of CPUs the guest OS thinks it has and the setting on the VM in vCenter, the VM will idle at high CPU utilization levels.

Page 75: VRanger 5.2.1 DeploymentGuide Rev1

Managing vRanger Performance

This section provides information on configuring vRanger and your deployment environment for the best performance.

This portion of the document contains the following sections:

Workload Protection Considerations ...........................................................................................77

Space Saving Technologies ........................................................................................................85

Filtering Catalog Collections........................................................................................................86

Integrating vRanger.....................................................................................................................89

vRanger and Tape Backup Vendors............................................................................................89

Application Backup & Recovery: Recovery Manager for Exchange............................................97

Using vRanger and Microsoft PowerShell ...................................................................................98

Page 76: VRanger 5.2.1 DeploymentGuide Rev1

Protection Best PracticesThis chapter outlines the hardware and software requirements for installing vRanger.

This chapter contains the following sections:

Workload Protection Considerations ...........................................................................................77

Configuring Backup Jobs ........................................................................................................77

Configuring Replication Jobs ..................................................................................................78

Load Balancing .......................................................................................................................84

Space Saving Technologies ........................................................................................................85

Filtering Catalog Collections........................................................................................................86

Page 77: VRanger 5.2.1 DeploymentGuide Rev1

77Protection Best Practices

Workload Protection ConsiderationsThe main goal when configuring backup jobs is to minimize the backup window while protecting infrastructure performance. Backup performance may be affected by the available network bandwidth, available processing power on the ESX Servers, and by the I/O capacity of the configured storage devices. Use the available limiters (described below) in vRanger to configure the maximum number of backup jobs that run on a given infrastructure component.

Configuring Backup Jobs

There are a variety of factors to consider when configuring backup jobs. The backup workload needs to be effectively planned to avoid over-taxing storage and network resources. vRanger includes configurable limits for the maximum number of concurrent tasks on a per-LUN, per-Host, and a per-Repository basis. You can also configure the overall number of concurrent backup tasks at the application level.

vRanger Job Limits

The number of concurrent jobs that vRanger can handle is largely dependant on the hardware configuration of the vRanger machine.

Per LUN Limits

In order to avoid storage I/O contention issues, it is recommended to limit the number of jobs that can be processes based on their storage location. vRanger defaults with a limit of 3 backup tasks per LUN.

Per Host Limit

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.

Per Repository Limit

While performance varies based on environmental factors, data throughput during a single VM backup task will routinely reach 30-40 MB/s. 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.

If you have need a repository located at a remote site, the bandwidth between sites will most likely become the limiting factor in job configuration. Rather than limit all

Page 78: VRanger 5.2.1 DeploymentGuide Rev1

78Protection Best Practices

vRanger tasks to fit the limited bandwidth, it is recommended to install a second vRanger application to be used to manage backups 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.

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.

VMware vSphere 4.0 introduces Changed Block Tracking (CBT). CBT will track the disk block changes made by the source VM. CBT, once enabled on the source host, records the blocks that have changed since the last replication pass and transfers them to the target host without scanning the VMDK. CBT removes the need to scan for changed blocks, as vSphere keeps track of the changes. vRanger will simply query for a list of changes, and replicate those blocks only.

Tip If CBT is supported in your environment, this is the recommended replication method. Note that CBT must be enabled on a per-VM basis.

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 1GB per minute. The entire source VMDK will be scanned. With differential replication, a snapshot is held open on the source VM during the replication pass only.

Hybrid replication is based on snapshot rotation, with a fallback to differential scanning in certain circumstances. With hybrid replication, a snapshot is opened against the source VM to capture changes that occur to the VM without a block scan. On each replication interval, the snapshot containing the changed data is sent to the replica site, closed on the source side, and a new snapshot is opened to capture the next set of changes. Block scans are not done during a hybrid replication, except in the case where the destination VM state is altered (e.g. a failover test).

Note Hybrid replication is not compatible with CBT.

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

Page 79: VRanger 5.2.1 DeploymentGuide Rev1

79Protection Best Practices

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.

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 theelimination 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 largeVMs can be replicated less frequently, ensure that you have an adequate replication interval to replicate the entire VM.

Page 80: VRanger 5.2.1 DeploymentGuide Rev1

80Protection Best Practices

Pre-seeding Replication JobsRanger 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 locally in order to reduce the amount of data sent over the WAN.

The pre-seeding procedure differs based on the type of host you are using.

Pre-seeding with ESX Hosts

Pre-seeding to a remote ESX host requires the following actions:

1 Create and run a replication job for the VM that you wish to pre-seed. Instead of configuring the job with the final target host, select a local host as the target.

This will generate the .vzmap file which is required by vRanger to identify changed blocks.

2 Move the host to the remote location.

or

Move the entire target VM directory (including the .vzmap file) to the remote target host and register the VM. Do not power on the VM on the remote host - this will invalidate the .vzmap file.

3 Edit the original replication job to point to the new remote host.

Copying the .vzmap file and using the original job allows vRanger to continue replication without needing to send the entire image over the WAN.

Pre-seeding with ESXi Hosts

Pre-seeding to a remote ESXi host requires the following actions:

1 Create and run a replication job for the VM that you wish to pre-seed. Instead of configuring the job with the final target host, select a local host as the target. Make sure you replicate locally to a host using a virtual appliance.

This will generate the .vzmap file which is required by vRanger to identify changed blocks.

Page 81: VRanger 5.2.1 DeploymentGuide Rev1

81Protection Best Practices

2 Move the host and VA to the remote location.

or

Move the entire target VM directory to the remote target host and register the VM. Do not power on the VM on the remote host - this will invalidate the .vzmap file.

3 Move the VA to the remote host.

or

Copy the directory on the VA that contains the .vzmap file to the VA on the remote host.

4 Edit the original replication job to point to the VA on the remote host.

Data Consistency

vRanger, by default, provides no quiescing during backups. Quiescing in vRanger is provided by leveraging VMware Tools installed in the VM.

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 is enabled in the VMs by going to Add/Remove Programs> VMware Tools >Modify>Check VSS Sync Driver).

Page 82: VRanger 5.2.1 DeploymentGuide Rev1

82Protection Best Practices

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.

vzShadow.exe is an optional component that can be installed on Windows VMs to provide an additional level of consistency.

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

File-level Quiescing

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

ESX(i) 4.0 VMware VSS VMware VSS

ESX(i) 4.1 VMware VSS VMware VSS

Note for VMs created on ESX(i) 4.1, you must also set the disk.EnableUUID flag to "false"

Application-level Quiescing

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

ESX(i) 4.0 VMware VSS vzShadow.exe

ESX(i) 4.1 VMware VSS vzShadow.exe

Note for VMs created on ESX(i) 4.1, you must also set the disk.EnableUUID flag to "false"

Truncation of Exchange Logs

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

ESX(i) 4.0 vzShadow.exe vzShadow.exe

Page 83: VRanger 5.2.1 DeploymentGuide Rev1

83Protection Best Practices

Deploying vzShadow.exe:

Note vzShadow.exe works in conjunction with VMware Tools’ VSS function. VMware Tools VSS must be enabled when using vzShadow.exe.

1 Install vRanger.

Tip Refer to the vRanger Installation and Setup Guide.

2 Download and install the appropriate C++ Redistributable package on the same machine that hosts the VSS aware application you want to quiesce.

For 64-bit (x64) machines, go to: http://www.microsoft.com/downloads/details.aspx?familyid=BD2A6171-E2D6-4230-B809-9A8D7548C1B6&displaylang=en

For 32-bit (x86) machines, go to: http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en#RelatedLinks

3 The installed vRanger software (version 4.5 and later) contains two files, one of which must be moved to the root directory of the machine that hosts vRanger. The files can be found:

C:\Program Files\Quest Software\vRanger\VSS

4 Depending on your system, move the appropriate file to the machine’s root directory (typically the C:\ directory).

vzshadow_x64.exe

or

vzshadow_x86.exe

5 Create a directory on the VM:

C:\Program Files\VMware\VMware Tools\backupscripts.d\

6 In this directory, create a batch file called freeze.bat.

A sample batch file is shown below;

c:\vzshadow.exe x:

ESX(i) 4.1 vzShadow.exe vzShadow.exe

Note for VMs created on ESX(i) 4.1, you must also set the disk.EnableUUID flag to "false"

Page 84: VRanger 5.2.1 DeploymentGuide Rev1

84Protection Best Practices

where X equals the drive that hosts the application -- if there are multiple volumes on this VM, list all volumes, separated by colon space (: ), as in:

c:\vzshadow.exe c: d: e:

When VSS is triggered by VMware tools, the pre-freeze script will execute vzShadow.exe.

Changing the disk.EnableUUID flag

To change the disk.EnableUUID flag:

1 Open the VMware vSphere Client, and log in to a vCenter Server.

2 Select Virtual Machines and Templates and click the Virtual Machines tab.

3 Locate the Windows 2008 virtual machine for which you are disabling the disk UUID attribute. Shut down the guest or power off the virtual machine.

4 After power-off, right-click the virtual machine. Choose Edit Settings.

5 Click the Options tab, and select General in the settings column.

6 Select Configuration Parameters.

7 Click Add Row.

Note This row will already exist if the 2008 VM ware created on ESX(i) 4.1

8 In the Name column, enter disk.EnableUUID.

9 In the Value column, enter false.

10 Click OK. Click Save.

11 Power on the virtual machine.

Load Balancing

vRanger will use the configured limiters and job scheduling information to balance the backup load across as many hosts as possible.

For example, assume a simple scheduling scenario of 10 ESX hosts running 10 VMs each (for 100 VMs total). If you set limits of 1 backup job per host and 10 backup jobs per repository, vRanger will process the backup tasks in parallel, ensuring that each host is operating at capacity.

Note that VMs are not vMotioned for load balancing purposes. Assume, like the above scenario, we have a schedule with 10 ESX hosts running 10 VMs each. In this example, however, we have a small backup job of only 10 VMs, all of which happen to be on one

Page 85: VRanger 5.2.1 DeploymentGuide Rev1

85Protection Best Practices

ESX host. In this case, vRanger will process the backup tasks serially because of the per host limit.

Space Saving TechnologiesvRanger offers the following options to reduce the storage footprint and network load of VM backups.

Full Backups

For full backups, vRanger performs a full scan and copy of the source VM. Full backup jobs can be modified with the following operations:

• Active Block Mapping (ABM): ABM will scan the disks on a virtual machine, and detect the blocks being actively used by the disk, as opposed to blocks that have been deleted by the Windows operating system. With ABM enabled, vRanger will only backup that part of a virtual disk that has active data on it.

Caution ABM does not backup deleted data. If a VM backed up using ABM is restored, undelete operations will not be possible.

Incremental Backups

For incremental backups, vRanger will perform a full scan of the source VM, but copy only blocks that have changed since the last backup.

Incremental backups are typically the fastest backup option and consume less storage space per archive. It is important to note, however, that in order to restore from an incremental backup, each incremental archive between the full backup and the desired restore point must be available. When creating incremental backup schedules, use caution to minimize the risk introduced by long incremental chains.

Restoring an incremental backup can take longer than restoring a full or differential backup, because each previous incremental archive needs to be restored as well.

Incremental backups can be modified with the following operations:

• Active Block Mapping (ABM): ABM will scan the disks on a virtual machine, and detect the blocks being actively used by the disk, as opposed to blocks that have been deleted by the Windows operating system. With ABM enabled, vRanger will only backup that part of a virtual disk that has active data on it.

Caution ABM does not backup deleted data. If a VM backed up using ABM is restored, undelete operations will not be possible.

Page 86: VRanger 5.2.1 DeploymentGuide Rev1

86Protection Best Practices

• Changed Block Tracking (CBT): Changed Block Tracking reduces the time needed for incremental and differential backups by only backing up the portions of a disk that have changed since the last backup. By determining which blocks changed within the VMDK file, vRanger only backs up the portions of a disk that have changed since the last backup. This will often result in shorter durations for backup operations, and reduce resource consumption on network and storage elements.

Note CBT will copy deleted blocks if ABM is not also enabled.

Differential Backups

For differential backups, vRanger will perform a full scan of the source VM, but copy only blocks that have changed since the last Full backup.

Differential backups are typically slower than incrementals and can consume more storage space. They are usually faster to restore, however, and require only one differential backup and the parent full backup to restore.

Differential backups can be modified with the following operations:

• Active Block Mapping (ABM): ABM will scan the disks on a virtual machine, and detect the blocks being actively used by the disk, as opposed to blocks that have been deleted by the Windows operating system. With ABM enabled, vRanger will only backup that part of a virtual disk that has active data on it.

Caution ABM does not backup deleted data. If a VM backed up using ABM is restored, undelete operations will not be possible.

• Changed Block Tracking (CBT): Changed Block Tracking reduces the time needed for incremental and differential backups by only backing up the portions of a disk that have changed since the last backup. By determining which blocks changed within the VMDK file, vRanger only backs up the portions of a disk that have changed since the last backup. This will often result in shorter durations for backup operations, and reduce resource consumption on network and storage elements.

Note CBT will copy deleted blocks if ABM is not also enabled.

Filtering Catalog CollectionsWhile there are thousands (or hundreds of thousands) of files in a typical VM, most are not relevant to file level recovery operations. In order to streamline cataloging operations, and reduce impact to the catalog database, vRanger filters files to be indexed in two ways:

Page 87: VRanger 5.2.1 DeploymentGuide Rev1

87Protection Best Practices

• Path - by default, vRanger does not catalog any files in the directories listed below. Path filtering is determined by entries in the PathFilterTokens.txt file, located at C:\Program Files\Quest Software\vRanger\Service\Configuration.

• File - By default, vRanger does not catalog files of the type below. File filtering is determined by entries in the FilesFilterTokens.txt file, located at C:\Program Files\Quest Software\CatalogManager\Config\Files.

Note File filtering applies to un-filtered paths. If a path is filtered, files in that path do not need to be.

For most situations, the default filtering options will be sufficient. If you want to filter out additional paths or files, simply add the path or file to the appropriate text file.

Program FilesWindows$Extend$TxfLog

$TxfRECYCLER

System Volume InformationI386

.lnk$MFT

$Volume$AttrDef$BitMap

$Boot$BadClus$Secure$UpCase$Quota$ObjID

$Reparse$RmMetadata

$Repair$Tops

$TxfLog

Page 88: VRanger 5.2.1 DeploymentGuide Rev1

Integrating vRangerThis chapter outlines the hardware and software requirements for installing vRanger.

This chapter contains the following sections:

Integrating vRanger .................................................................................................................89

vRanger and Tape Backup Vendors.......................................................................................89

Application Backup & Recovery: Recovery Manager for Exchange ..............................97

Using vRanger and Microsoft PowerShell ...........................................................................98

Page 89: VRanger 5.2.1 DeploymentGuide Rev1

89Integrating vRanger

Integrating vRangerLike any component of your virtual infrastructure, vRanger can be used in conjunction with other applications to achieve more complex tasks.

vRanger and Tape Backup VendorsTo configure the vRanger sweep-to-tape feature, both vRanger and the tape vendor’s software must point to a common vRanger repository folder located locally on the vRanger server.

The vRanger backup administrator creates an on-demand (not scheduled), incremental job with a specific name, appending -Tape as a case-sensitive suffix (e.g., any-jobname-Tape). The -Tape suffix can be changed by editing the PowerShell script if you prefer something else. There should be a dedicated repository for each on-demand job.

The tape software administrator schedules a recurring incremental backup job whose PRE field calls a .cmd file containing the PowerShell script that searches for and then starts the vRanger on-demand job(s) with the -Tape suffix.

The vRanger on-demand job performs the incremental backup, placing the savepoint files in the repository and updating the repository's global manifest file.

After the vRanger job completes (e.g., the job status equals either success or failure), the PowerShell script exits, thus completing the Backup Exec PRE command.

With the tape software’s PRE command completed, the tape software, which is also pointing to the vRanger repository folder, runs its scheduled incremental job, backing up the vRanger savepoints and global manifest file to tape or whatever media server type is configured.

Required Components

The components required differ depending on the installation scenario.

Scenario 1 - vRanger & 3rd-party tape software on the same server

• Tape vendor’s software on a Windows 2003 server.

Note Note: a physical server will provide better performance than a VM.

• vRanger resides on the tape software server.

• A local repository shared by vRanger and the tape software.

Page 90: VRanger 5.2.1 DeploymentGuide Rev1

90Integrating vRanger

• PowerShell (PowerShell and vRanger must always be installed on the same server).

• A PowerShell script that finds and launches the vRanger on-demand job.

• A CMD file that contains the PowerShell script.

Scenario 2 - vRanger & 3rd-party tape software on different servers

The tape software is on its own server. All other components, including a remote tape backup agent, reside on the vRanger server. Note: Scenario 2 is not discussed in this document.

Server 1-Backup Exec:

• Tape vendor’s software on a Windows 2003 server

Server 2-vRanger/PowerShell:

• Tape software’s remote tape backup agent that can run a PRE command. The agent runs the PowerShell script contained in the .CMD file called via the PRE command

• vRanger resides on its own server

• A local repository located on the vRanger server and shared by vRanger and the tape software

• PowerShell (PowerShell and vRanger must always be installed on the same server).

• A PowerShell script that finds and launches the vRanger on-demand job

• A CMD file that contains the PowerShell script.

Configuration Steps

Use the procedures below to configure integration of your tape software and vRanger.

Note Although the procedure below uses Symantec Backup Exec, the procedures should be similar for any tape vendor’s software.

These procedures assume that:

• You have your components installed according to Scenario 1 as described above.

• The customer already will have a Backup Exec physical server and vRanger will be installed on that server.

Page 91: VRanger 5.2.1 DeploymentGuide Rev1

91Integrating vRanger

Installing vRanger

1 Install vRanger onto your Backup Exec server. Consider placing the local repository on the D: drive of the vRanger server.

2 Create the local share D:\vranger_backups (or similar).

a Assign the group Everyone (or similar) Full Control for the Share.

b The user credentials specified in the next step when adding the repository should have Full Control NTFS security. This folder will become the repository that contains the incremental job savepoints and global manifest file. The folder should have enough disk space to hold a full backup and several incremental backups.

3 Add a local repository on the vRanger server that points to the vranger_backups share. Click My Repositories > Add > specify the necessary repository details, pointing to the share.

4 Create an on-demand, daily, incremental backup job that backs up your environment. In this paper, we will backup a single server for simplicity. Click:

a My Inventory > Add > Backup Job > Advanced > Job Name = vRanger-Sweep-to-Tape. Click Next.

b Select VMs to exclude. Click Next

c Select hard disks to include. Click Next.

d Select your options. Click Next.

e For Retention Policy, select Savepoint Count=7, Space Saving Technology=Incremental, Threshold Count=6. Click Next.

If Backup Exec calls this on-demand job daily, there will be a full backup performed the first day and an incremental backup performed each of the remaining days of the week.

f Select the This will be an on demand job and does not require a recurrence schedule checkbox. Click Next.

g Click the vRanger-Sweep-to-Tape repository to select it. Click Next.

h Select the email address(es) that should be notified when the job has completed running. The Email a report after the job has finished running checkbox should remain checked. Click Next.

i Review your settings and click Finish.

Page 92: VRanger 5.2.1 DeploymentGuide Rev1

92Integrating vRanger

Installing and Configuring PowerShell

1 From http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=10ee29af-7c3a-4057-8367-c9c1dab6e2bf, download PowerShell 1.0 for Windows Server 2003 to the vRanger server.

2 Install PowerShell. PowerShell appears in Add/Remove Programs as a hotfix:

3 Click Start > All Programs > Quest Software> vRanger > vRanger Console to launch the vRanger Console.

4 Set the PowerShell Script Execution Policy to RemoteSigned.

a Set the PowerShell Script Execution Policy to RemoteSigned by running the cmdlet:

Set-ExecutionPolicy RemoteSigned.

b Confirm the policy setting by running the Get-ExecutionPolicy cmdlet.

c Exit PowerShell by running the Exit cmdlet.

See http://www.microsoft.com/technet/scriptcenter/topics/msh/cmdlets/set-executionpolicy.mspx for an explanation of the available PowerShell Execution Policies.

5 Edit the vRanger config files with Notepad (or similar) to use the vRanger server's local IP address instead of localhost.

a Edit the vRanger.API.exe.config file, located at: \Program Files\Quest Software\vRanger\PowerShell \vRanger.API.exe.config.

• Change:<endpoint address="http://localhost:2480/VAPIHost.svc" binding="wsDualHttpBinding"

Page 93: VRanger 5.2.1 DeploymentGuide Rev1

93Integrating vRanger

To: <endpoint address="http://<Server-IP>:2480/VAPIHost.svc" binding="wsDualHttpBinding"

b Edit the vRanger.API.PowerShell.dll.config file, located at \Program Files\Quest Software\vRanger\PowerShell \vRanger.API.PowerShell.dll.config.

• Change:<endpoint address="http://localhost:2480/VAPIHost.svc" binding="wsDualHttpBinding"

To:<endpoint address="http://<Server-IP>:2480/VAPIHost.svc" binding="wsDualHttpBinding"

Using the PowerShell Script

1 Download the PowerShell script that will launch the vRanger on-demand job.

a Go to the URL and save the zip file to any folder (e.g., c:\download) on the vRanger server: http://www.vizioncore.com/downloads/vRangerPro/PowerShellScripts/vRangerTape.ps1.zip.

b Extract the script from the zip file by right-clicking the file and clicking Extract All.

c While you do not need to edit the script, you can open it with Notepad to understand why your vRanger job name has to have the suffix -Tape (case sensitive).

The PowerShell $JobString = "*-Tape" must match the suffix used in your vRanger job name. As long as they match, you can change the $JobString and vRanger job name suffix to something other than -Tape.

d Close the file.

e Using Notepad, create a CMD file in the C:\Download\vRangerTape.ps1 folder titled vRangerTape.cmd. Its contents are:

@echo off

c:\Windows\system\system32\windowspowershell\v1.0\powershell.exe c:\download\vRangerTape.ps1\vRangerTape.ps1

Note Make sure that the vRangerTape.cmd file has .CMD extension, not a .TXT extension.

Page 94: VRanger 5.2.1 DeploymentGuide Rev1

94Integrating vRanger

Configuring Backup Exec

1 Install and configure Backup Exec according to the applications instructions.

2 When configuring the Backup-to-disk folder type, select Backup-to-disk folder. Click Next.

3 At the Enter a name for the backup-to-disk-folder prompt, type vRanger Daily and click Next.

4 At the Enter a path for the backup-to-disk-folder prompt, type or browse to D:\Backup_Exec Backups and click Next.

5 At the Enter the maximum size for a backup-to-disk file prompt, type a number of GBs (default=4).

Note You can later change this number from within Backup Exec.

6 At the Allocate the Maximum Size for Backup-to-Disk Files prompt, click the Yes radio button and click Next. Pre-allocating the space improves performance.

7 At the Enter the maximum number of concurrent jobs prompt, type 1 (the default) and click Next.

8 At the Enter the size for the low disk space threshold prompt, type 0 (the default) and click Next.

9 Review your Device Configuration Wizard settings and click Next.

10 Click Finish.

11 Create a media set named vRanger Daily Backups. Set the Overwrite Protection Period to 4 weeks.

12 Set the Append Period to 4 weeks.

Create a Backup Job

1 Click on Create a backup job. This launches a wizard.

a At the Welcome to the Backup Wizard page, click Create a backup job with custom settings and click Next.

b At the Backup Selections page, drill down to and select the vRanger repository e.g., D:\vRanger_Backups, and click Next.

c At the Select Volume Credentials page, click Test All. When the results are successful, click Next.

d At the Select Volume Order page, click Next.

Page 95: VRanger 5.2.1 DeploymentGuide Rev1

95Integrating vRanger

e At the Backup Names page, title the backup job vRanger Daily Job, title the backup set vRanger Daily Backup, and click Next.

f At the Backup Device and Media page, at the Which device would you use to backup your data drop-down box, select vRanger Daily. At the Which media set would like to use to back your data drop-down box, select vRanger Daily Backup. When finished making your selections, click Next.

g At the Backup Overwrite Method page, accept the default Append to media, overwrite if no appendable media is available radio button. Click Next.

h At the Backup Options page, click the Incremental - Changed Files - Reset Archive Bit method from the drop-down list. Click Next.

i At the Completing the Backup Wizard page, click the No, schedule the job to run later radio button and click Finish.

j At the Schedule Options page, click the Run according to schedule radio button and click the Edit Schedule Details button.

k At the Edit Calendar schedule by box, click the Recurring Days of the Month option and then click the Select All button.

l At the Edit Calendar schedule by box, click the Effective Date option and confirm that today's date is placed in the Make the schedule go into effect on drop-down box.

m At the Edit Calendar schedule by box, click the Time Window option and accept the defaults: Start no earlier than 11:00:00 PM and no later than 10:59:59 PM the following day.

n Click Submit.

o At the Completing the Backup Wizard page, click the No, schedule the job to run later radio button and click OK.

p Click Close to close the Getting Started with Backup Exec page.

2 Specify the vRangerTape.cmd file in the Backup Exec job's PRE field.

a Close the Backup Exec Assistant window.

b Click on the vRanger Daily Job and click Properties.

Page 96: VRanger 5.2.1 DeploymentGuide Rev1

96Integrating vRanger

c In the vRanger Daily Job Properties column, click Pre/Post Commands and type the PowerShell script path\command (e.g., C:\Download\vRangerTape.ps1\vRangerTape.ps1).

-

d Click Submit.

e At the Job Summary page, click OK.

Run Sweep-to-Tape

1 In Backup Exec, highlight the vRanger Daily Job and click Run Now. Click Yes to confirm.

2 Click the Job Monitor tab and double-click the Active job.

Restore From Backup Exec

Restoring from Backup Exec is the reverse procedure of doing backups.

1 From within Backup Exec, restore from tape or disk to the vRanger repository.

Page 97: VRanger 5.2.1 DeploymentGuide Rev1

97Integrating vRanger

2 From within vRanger, restore from savepoints, using the global manifest file or savepoint manifest files.

Troubleshooting Sweep-to-Tape

Sweep-to-tape has three main components. Each component should be tested individually.

• The vRanger on-demand, incremental backup job.

• The PowerShell script contained in the .CMD file.

• The Backup Exec scheduled, incremental backup job.

1 From with vRanger, manually run the vRanger on-demand job and confirm that it works.

2 Run the PowerShell script from a CMD prompt. Manually cut and paste the executable statement into the CMD prompt and check for errors to troubleshoot further:

c:\windows\system32\windowspowershell\v1.0\powershell.exe c:\download\vRangerTape.ps1\vRangerTape.ps1

3 Launch PowerShell

a Run the Get-PSSnapin command. vRanger.API.PowerShell should be registered.

b Run the Get-Executionpolicy command. The execution policy should be set to RemoteSigned.

4 From Backup Exec, confirm that its job runs. If the job fails quickly, confirm that the Backup Exec services are using credentials with local administrator rights. If so, then the PRE command is probably failing due to a PowerShell issue.

Application Backup & Recovery: Recovery Manager for ExchangeRecovery Manager for Exchange (RME) provides object-level restore of individual email messages, folders, and other objects from Microsoft Exchange databases which are protected in vRanger backup images. Restoring an individual email object is faster and easier than recovering the entire Virtual Machine image.

For more information on how vRanger can be used with Recovery Manager for Exchange, see the document “Application-level Backup & Recovery with vRanger Pro and Quest Recovery Manager for Exchange”.

Page 98: VRanger 5.2.1 DeploymentGuide Rev1

98Integrating vRanger

Data Domain and vRanger RepositoriesQuest vRanger and Data Domain appliances provide companies with a simple and efficient method for backing up and recovering VMware environments. vRanger provides significant enhancements with regard to architecture, performance and communications over traditional backup solutions. Data Domain provides superior data de-duplication capabilities. The combination of vRanger and Data Domain Technology will dramatically reduce your backup and recovery time for virtual machines on VMware ESX hosts.

For more information about integrating vRanger and Data Domain, see the document “vRanger Pro & Data Domain Best Practices”.

Using vRanger and Microsoft PowerShellvRanger includes a way to remotely connect to the vRanger Service using Microsoft PowerShell. This allows an administrator to use PowerShell (and Virtualization EcoShell) to create a client utility that can interact with vRanger from anywhere in the environment.

Configuring the vRanger Server

To get started, you must make a few quick configuration changes on the vRanger server.

Step 1: Edit the Config File

1 Browse to the PowerShell directory in the vRanger installation path. By default this is:

C:\Program Files\Quest Software\vRanger\PowerShell

2 Using a text editor, open the file vRanger.API.exe.config.

3 In the file, find the following line:

<endpoint address="http://localhost:2480/VAPIHost.svc" binding="wsDualHttpBinding"

4 Replace “localhost” with the IP address of the vRanger server. Save the file.

Step 2: Edit the Client File

1 In the same directory (C:\Program Files\Quest Software\vRanger\PowerShell) find the file vRanger.API.PwerShell.dll.config.

Page 99: VRanger 5.2.1 DeploymentGuide Rev1

99Integrating vRanger

2 Using a text editor, open the file and find the following line:

<endpoint address=”http://localhost:2480/VAPIHost.svc” binding=”wsDualHttpBinding”

3 Replace “localhost” with the IP address of the vRanger server. Save the file.

Step 3: Restarting vRanger Services

1 Restart the vRanger services so that the changes may take effect.

The easiest method is to simply restart the machine hosting vRanger. If that is not possible, ensure that you restart each of the three vRanger services:

• vRanger API Service

• vRanger FLR Service

• vRanger Service

Configuring the Remote Machine

You may now copy the entire vRanger PowerShell directory (C:\Program Files\Quest Software\vRanger\PowerShell) and move it to any system that has Windows PowerShell (Version 1 or Version 2) installed.

Once you have the directory copied over, simply open up a standard Windows PowerShell prompt and navigate to the vRanger PowerShell directory. Type the following command to launch the vRanger console for the first time:

./vRangerConsole.ps1

This command will register the proper components and allow you to add the Quest vRanger PowerShell library into Virtualization EcoShell. This will also allow PowerShell to interact remotely with your vRanger server to create a client-server architecture using the vRanger Cmdlets.

To import a library into Virtualization EcoShell:

This procedure assumes that you have Virtualization EcoShell installed on the machine to which you copied the vRanger PowerShell directory.

Page 100: VRanger 5.2.1 DeploymentGuide Rev1

100Integrating vRanger

1 From the Virtualization EcoShell console, click File>PowerShell Libraries.

2 Select the vRanger.API.PowerShell entry.

3 Click OK.

Page 101: VRanger 5.2.1 DeploymentGuide Rev1

Index 101

Index

Bbackup process 18

dfferentials 86incrementals 85limitations 18

Cconfigurations

common issues 71CPU 73memory 73network 72storage 71

Fibre backups 55network backups 54SAN setup 56task limits 76VMware 59

DData Domain 98deployment

reference architectures 47disk.EnableUUID 84

FFile-level restore 28

limitations 28

Kkey questions 8

MMicrosoft Exchange backups 97

Pport requirements 44PowerShell 98proxy sizing 56

Rreference architectures

large 52mid-sized 49small 47

repositories 29bandwidth 68size 33storage devices 68structure 30testing 69using a Data Domain appliance 98

requirementslicensing 45platforms 45port 44

restore process 28

Ssavepoints 32

Ttape backups 89teaming NICs 55

Page 102: VRanger 5.2.1 DeploymentGuide Rev1

Index 102

VVMware

vCenter permissions 62vRanger

and Data Domain 98and PowerShell 98and Recovery Manager for Exchange 97and tape backup vendors 89application architecture 14backup process 18configuring limits 76information sources 11key questions 8repositories 29restore process 28