tsm ve 6.3 proxysizing v1.0

8/11/2019 TSM VE 6.3 ProxySizing v1.0

1/18

Tivoli Storage Manager for Virtual Environments Guide to Proxy Sizing

Page 1 of 18

Tivoli Storage Manager for Virtual Environments V6.3

Step by Step Guide To vStorage Backup Server (Proxy) Sizing

22 August 2012

1.0

Author: Dan Wolfe, Tivoli Software Advanced Technology


2/18


3/18


Page 3 of 18

ContentsContents .......................................................................................................................... 3

1. Introduction ............................................................................................................. 4

1.1

Overview ................................................................................................................................. 5

1.1.1 Performance ............................................................................................................. 5

1.1.2 Periodic Full Backup ................................................................................................. 6

1.2 A Few Definitions .................................................................................................................... 7

1.3 Scope of this document .......................................................................................................... 7

1.3.1 External Dependencies and Assumptions ................................................................ 7

1.3.2

Performance optimization and bottleneck analysis .................................................. 7

1.3.3 Proxy Hardware Configuration.................................................................................. 7

2.

Step by Step Proxy Sizing ...................................................................................... 9

2.1 Assumptions ............................................................................................................................ 9

2.2 Example environment ............................................................................................................. 9

2.3

Perform the Estimate .............................................................................................................. 9

2.3.1 Determine daily backup workload ........................................................................... 10

2.3.2 Calculate Aggregate Throughput Requirement ...................................................... 10

2.3.3 Calculate the number of concurrent datamovers (backup processes) ................... 10

2.3.4 Determine the number of proxy hosts required ...................................................... 11

2.3.5 Summary ................................................................................................................. 11

2.4

Architectural Considerations ................................................................................................. 12

2.4.1 Additional capacity requirements ............................................................................ 12

2.4.2 Physical or virtual proxy? ........................................................................................ 12

2.5 Scheduling of Backups ......................................................................................................... 14

2.5.1 Rotating Fulls backups by ESX Host ................................................................... 14

2.5.2 Alternate Scheduling Methods ................................................................................ 14

3. Your Estimate ....................................................................................................... 16

4. Proxy Host Resource Requirements .................................................................... 17

4.1 Determining proxy resource requirements ............................................................................ 17

4.1.1

Determining I/O resource requirements ................................................................. 17

4.1.2 Determining CPU requirements .............................................................................. 17

4.1.3 Memory estimation ................................................................................................. 17


4/18


Page 4 of 18

1. IntroductionTivoli Storage Manager for Virtual Environments (TSM-VE) is a feature of the Tivoli Storage Manager productfamily for backing up virtual machines in a VSphere (VMWare) environment. Tivoli Storage Manager for

Virtual Environments uses the latest backup technology provided by VMWare, called VStorage API (alsoknown as VADP or VStorage API for Data Protection).

An essential component of Tivoli Storage Manager for Virtual Environments is the VStorage Backup Serverwhich performs the data transfer from the data stores that contain the virtual machine data to the TivoliStorage Manager server. The VStorage Backup Server offloads the backup workload from the ESX serverand acts as a proxy for a backup. Throughout this document, the VStorage Backup Server will be referred toas the "proxy ". A proxy that is configured on a virtual machine is referred to as a virtual proxy, and ifconfigured on a physical machine is referred to as a physical proxy.

When you consider a backup solution using Tivoli Storage Manager for Virtual Environments, one of thefrequently asked questions is how to estimate the number of proxies required for a specific environment. Thispaper guides through the estimation process.

The following diagram provides a simplified, high level overview of the components involved with TSM-VEimage backup and restore:


5/18


Page 5 of 18

1.1 Overview

The proxy estimation is intended to help you plan a deployment of Tivoli Storage Manager for VirtualEnvironments. A recommended approach is described. However, there are many variations depending uponcustomer preferences, infrastructure capabilities, and other factors. Different vendors use variousapproaches to determine the number of proxies required, and may be constrained by product design. TivoliStorage Manager provides flexibility for deploying the proxies and selecting virtual, physical, or a combinationof both proxies. The intent is to provide a starting point for initial estimation and solution architecture.

The proxy estimation process comprises the following steps:

Define how the backups are scheduled.

Estimate the number of proxies required.

Decide whether to use virtual machine proxies, physical proxies, or a combination of both.

1.1.1 Perform ance

Estimating the number of proxies requires some assumptions about the performance characteristics ofindividual backup processes. Tivoli Storage Manager for Virtual Environments uses efficient disk block-levelI/O for the backup process, and the backup process itself adds minimal overhead.

Backup performance is determined the following system characteristics:

I/O capabilities of the data store storage arrays

Back-end storage device used by the Tivoli Storage Manager server, for example, Virtual Tape Library(VTL) or disk

Infrastructure connectivity, for example, Storage Area Network (SAN) or Local Area Network (LAN)bandwidth

It is recommended that you use benchmarking to refine the estimate of backup throughput specific to yourenvironment.

The throughput capabilities can range significantly depending upon the environment. Observed throughputshave ranged from 40GB/Hour to well over 200GB/hour for a single, individual backup processes.

1.1.1.1 Deduplication

Tivoli Storage Manager client side (inline) deduplication is highly effective with Tivoli Storage Manager forVirtual Environments and can substantially reduce back-end storage requirements as well as the proxy toTivoli Storage Manager server bandwidth requirements. Client side deduplication requires additionalprocessing (by the proxy host) that will slow the backup throughput. For a specific amount of data to backup,you may require more proxies to meet a given backup window when using deduplication as compared withnot using deduplication. Generally the benefits of storage and bandwidth reduction will outweigh the cost ofadditional instances of proxies. For estimation purposes, you can assume that backup throughput when youuse client deduplication is approximately 50% of the throughput without deduplication.

As an alternative to using client side (inline) deduplication, TSM server-side (post-process) deduplication maybe used if backup throughput requirements are the highest priority, and proxy to TSM server bandwidth is notconstrained.

1.1.1.2 Data transfer/transport methods

The methods used for data transfer from data store to proxy and from proxy to the Tivoli Storage Managerserver can have an impact on the per-process performance of Tivoli Storage Manager for Virtual


6/18


Page 6 of 18

Environments backups and restores. The following information on the methods available are listed here forreference. TSM user documentation should be referenced for more details on the methods available andhow to configure.

Data I/O from ESX data store to Proxy

Transport Method Available to VirtualProxy? Available to PhysicalProxy? Comments

NBD Yes Yes Uses LAN connection

NBDSSL Yes Yes Uses LAN connection

SAN No Yes Uses direct SAN connection to datastore (for SAN-attached data storesonly).

HOTADD Yes No Uses SAN connection (via ESX host)for SAN-attached volumes which isnearly as efficient as the SANtransport. For NFS data stores,provides more efficient transport than

NBD.

Data I/O from Proxy to Tivoli Storage Manager server

CommunicationMethod

Available to VirtualProxy?

Available to PhysicalProxy?

Comments

LAN Yes Yes Data transfers over LAN to TivoliStorage Manager server

LAN-free No Yes Data transfers over SAN to TivoliStorage Manager server storage pooldevices (Tape or Virtual Tape)

Note:LAN-free with disk is possibleusing SANergy or GFPFS.

1.1.1.3 Estimated ranges for performance

The throughput capabilities can range significantly depending on the environment, transport/data transfermethods, and whether client side deduplication is used. For the purpose of estimation, the following valuesare used in this document:

100GB/hour without deduplication

50GB/Hour with deduplication

1.1.2 Periodic Ful l Backup

As a best practice for Tivoli Storage Manager for Virtual Environments V6.3, you should perform a periodicfull backup every 7-14 days, and regular daily incremental backups. (Incremental backups use VMWaresChange Block Tracking feature.) Full backups can be scheduled less frequently however restore performancemay increase with less frequent full backups.


7/18


Page 7 of 18

1.2 A Few Definitions

Term Definition

Proxy The host that performs the offloaded backup. This host can be a virtual or physicalmachine. Also called VStor Backup Server (VBS), Backup Server (BUS). The TivoliStorage Manager Backup/Archive Client is installed on this host and provides theVMWare backup function.

Datamover An individual backup process that performs the VMWare guest backups. Eachdatamover is associated with one or more Tivoli Storage Manager backup schedules.Typically there will be multiple datamovers per proxy to fully utilize the proxy hostresources. Also called backup process.

1.3 Scope of this document

This document is intended to provide a first order estimation of proxy hosts required for a specific TivoliStorage Manager for Virtual Environments backup environment. Using these guidelines can help to provide asuccessful deployment by establishing a quantitative basis for determining the quantity, placement, andsizing of the proxy hosts. There are many assumptions made within this document and actual results canvary significantly depending upon the environment and infrastructure characteristics. Careful evaluation ofthe environment is necessary and benchmarking during the planning phase is strongly encouraged tocharacterize the capabilities of the environment.

1.3.1 External Dependencies and Ass umpt ion s

The estimation process in this document is based on the assumption that no constraints exist in theenvironment, and that storage capacity per VM, ESX host, and cluster are consistent across the environment.

If there are large disparities in storage capacity for individual VMs, for example, a separate sizing may needto be done for the largest VMs. The assumptions made include (but are not necessarily limited to):

1. data store I/O capacity is sufficient to sustain the backup workloads.

2. LAN or SAN connectivity is sufficient to sustain the backup workloads.

3. Tivoli Storage Manager server and storage device capacity and the number of instances aredesigned and configured to sustain the backup workload provided by the proxies.

1.3.2 Performance opt im izat ion and b ott leneck analysis

This document does not address design for performance or bottleneck analysis techniques for a TivoliStorage Manager for Virtual Environments environment.

1.3.3 Prox y Hardware Con f igurat ion

Although some guidelines are provided for proxy host resource requirements, it is not the intent of thisdocument to provide specific guidance on hardware or system configurations of physical or virtual proxyhosts. Hardware configuration (or in the case of a virtual machine, resource allocation) should be defined by


8/18


Page 8 of 18

a qualified system engineer that is familiar with hardware capabilities, I/O throughput, and other systemrequirements.

IBM Techline provides a service for pre-sales configuration of Tivoli Storage Manager hardware includingTivoli Storage Manager for Virtual Environments proxy sizing. Consult your IBM Tivoli sales representativefor more information.


9/18


Page 9 of 18

2. Step by Step Proxy SizingThis section provides the steps for sizing a proxy for a specific deployment scenario across an entire datacenter. This is a generalized approach, and the same method may be applied to individual environments that

differ significantly from one another.

2.1 Assumptions

Reasonably equal distribution (within 20%) of utilized virtual machine storage capacity (data stores)across all ESX hosts.

Backups are scheduled on a per ESX host basis. See scheduling section for more information.

Schedule a full backup weekly and an incremental backup 6 days a week. This means that on anyday, 1/7

thof the ESX hosts will have a full backup, and 6/7

thof the ESX hosts will have an

incremental backup. Since we assume an even distribution of storage and VMs across all ESX

hosts, this means that 1/7 thof the total amount of data is backed up daily (via the full backups) andthe remainder of the data is backed up incrementally.

Example environment:

o Total number of virtual machines: 5000

o Average used storage per virtual machine: 50GB

o Total

2.2 Example environment

The following example environment is used to illustrate the estimation process:

Environment Description

Total Number of virtual machines 5000

Average Utilized Storage per VM 50GB

Total Utilized Storage 5000 * 50GB 250,000 GB

Number of ESX Hosts 250

Number of DRS Clusters 50

Backup Window 10 Hours

Assumed daily change rate 2%

2.3 Perform the Estimate

The following sections demonstrate the estimation process.


10/18


Page 10 of 18

2.3.1 Determ ine dai ly backup wo rkload

You must determine how much data is backed up daily. Based on the previously stated assumptions, we willperform a full backup on 1/7

thof the hosts and an incremental backup on the remaining 6/7

thof the hosts.

Since we assume a relatively even distribution of data across hosts, we can apply these proportions to theaggregate amount of data to backup.

Determine Daily Backup Workload

Daily backup workload from fullbackups

250,000GB 7

NOTE: periodic full every 7days

35,700GB

Daily backup workload fromincremental backups

(6 7) * 250,000 * 0.02

NOTE: 6/7th

of total datamultiplied by incrementalchange rate of 2%

4,300GB

Total Daily Backup Workload 35,700 + 4,400 GB 40,100GB

2.3.2 Calculate Aggregate Thro ugh pu t Requirem ent

The aggregate throughput requirement is determined by the total amount of data that is backed up daily thatwas computed in the previous section. We assume a 10 hour daily backup window. Remember, the goal isto meet the overall backup window, and we can adjust the number of datamovers appropriately to achievethis.

Calculate aggregate throughput requirement

Total daily backup workload 35,700 + 4,400 GB 40,100GB

Backup window 10 hours

Aggregate throughput required 40,100GB 10 hours 4010 GB/Hour

2.3.3 Calculate the number of con cur rent datamovers (backup

processes)

The number of datamovers required is simply the aggregate throughput requirement divided by the estimatedper-process (per datamover) throughput. Assume the per-process throughput is 100GB/hour.

Calculate number of concurrent datamovers

Aggregate throughput required 40,100GB 10 hours 4010 GB/Hour

Per process throughputestimate

100GB/Hour


11/18


Page 11 of 18

Number of datamovers (backupprocesses)

4010GB/Hour 100GB/Hour 40

2.3.4 Determ ine the number of proxy h os ts required

To determine the number of proxy hosts required, we need to know how many concurrent datamovers(backup processes) can run on a single proxy host. For estimation purposes, we will assume tendatamovers. We will discuss resource requirements later in this document, and you may decide to run moreor less concurrent processes per proxy, but this will provide us a reasonable estimate to start with.

Determine the number of proxy hosts required



Number of concurrent

datamovers per proxy

10

Number or proxy hosts required 40 10 4

2.3.5 Summary

We have finished crunching through the numbers to estimate the number of proxies required for a TSM-VEdeployment. This gives us a good starting point, but now we need to think more about the architecture of theoverall solution to determine if any adjustments are necessary. We will cover this in the next section. Here isa table that summarizes all of the steps up to this point:

Environment DescriptionTotal Number of virtual machines 5000

Average Utilized Storage per VM 50GB

Total Utilized Storage 5000 * 50GB 250,000 GB

Number of ESX Hosts 250

Number of DRS Clusters 50

Backup Window 10 Hours

Assumed daily change rate 2%

Determine Daily Backup Workload

Daily Backup Workload from FullBackups

250,000GB 7

NOTE: periodic full every 7 days35,700GB

Daily Backup Workload fromIncremental Backups

(6 7) * 250,000 * 0.02

NOTE: 6/7thof total data

multiplied by incremental changerate of 2%

4,300GB


12/18


Page 12 of 18


Calculate Aggregate Throughput Requirement


Backup Window 10 hours

Aggregate throughput Required 40,100GB 10 hours 4010 GB/Hour

Calculate Number of Concurrent Datamovers

Aggregate throughput Required 40,100GB 10 hours 4010 GB/Hour

Per Process Throughput Estimate 100GB/Hour



Determine Number of Proxy Hosts Required



Number of concurrent datamoversper proxy

10

Number or proxy hosts required 40 10 4

2.4 Architectural Considerations

Now that we have an estimate of the number of proxies required to achieve the daily backup workload, wemust now consider whether this makes sense in practical terms. TSM-VE provides a great deal of flexibilityin deployment options, so we need to determine which options makes the most sense. We will consider otherfactors and determine if adjustments are required.

2.4.1 Ad di t ion al capaci ty requirements

We have estimated the number of proxies based only on the backup requirement during the backup window(in our case 10 hours). However, full image restores of virtual machines require the use of a proxy as well.The proxy can be located anywhere within the datacenter and could be a separate, dedicated proxy usedonly for restore purposes.

If you intend to use the same backup proxies for image restores during the backup window, you will need toadd this to your workload estimate which may increase the number of proxies required. You may also want toconsider a spare proxy in the event of a failed proxy host

2.4.2 Phys ical or vir tual proxy ?

The first consideration is to determine whether physical or virtual proxies will be used. Note that you dontneed to decide all one or the other. It is entirely possible to use virtual proxies for part of an environment, andphysical proxies for another where it makes sense.

For simplicity, we assume that the number of data movers will be the same whether you use a physical orvirtual proxy host. This assumption is based on equivalent resources and connectivity when comparing the


13/18


Page 13 of 18

physical and virtual hosts. In practice, a virtual proxy will share resources (e.g., i/o adapters, CPU, etc.) withother VMs whereas a physical proxy will have dedicated, static resources.

2.4.2.1 Questions to ask when you decide between a physical and a virtual proxyFollowing is a list of questions you should consider when deciding between physical and virtual machinesshowing which type of proxy would be preferred in each case depending upon a yes or no answer:

Question Yes No

Do you require backup traffic to flow over the SAN as much as possible?

*Note:Virtual machine proxies can take advantage of Hotadd data transfers froma SAN data store to the proxy which primarily uses SAN I/O via the ESX hostHBA. However, a virtual machine proxy cannot take advantage of LAN-free datatransfers from the proxy to the Tivoli Storage Manager server.

Physical* Virtual

Does your LAN (IP Network) have sufficient bandwidth to accommodate the

backup traffic.

Virtual Physical

Do you want to use LAN-free data transfers from the proxy to the Tivoli StorageManager server?

Note: LAN-free is usually only used with Tape or Virtual Tape backup storagedevices.

Physical Virtual

Do you prefer or require that all new hosts are virtual and not physical machines? Virtual Either

Do you want to minimize the number of proxy hosts?

Note: The preference is based on the assumption that you will dedicate moreresources to a physical proxy than a virtual proxy.

Physical Virtual

Do you use NFS attached data stores? Virtual Either

Is 10GB Ethernet connectivity available to the Tivoli Storage Manager server? Virtual Either

2.4.2.2 ESX Clusters and distribution of virtual proxies

It is important to consider the distribution of virtual proxy hosts within the infrastructure. In the example, thereare 4 proxies that backup 50 ESX hosts each, or 10 ESX clusters. Although you can do the job with 4proxies, you may want to consider using at least one virtual proxy per ESX cluster. This is because a virtualproxy within an ESX cluster can access datastore storage via Hotadd. Hotadd provides an efficient (and lowoverhead) data transfer method. For SAN attached storage, the proxy transfers data directly through theESX hosts fibrechannel adapter.

Using the example, you can use 10 proxies to cover all 10 ESX clusters. You can reduce the number of data

movers per proxy to distribute the workload over a greater number of proxies and reduce the resourcerequirements for each proxy. Using 10 virtual proxies will also provide additional reserve capacity forrestores which occur during the backup window.

2.4.2.3 Deduplication choices

Although the choice of deduplication methods does not relate directly to the decision regarding physical vs.virtual proxies, it should be considered in the context of LAN-free. Although the two deduplication methodsare not mutually exclusive, normally a choice is made between Tivoli Storage Manager deduplication and a


14/18


Page 14 of 18

deduplicating appliance (such as a Protectier Virtual Tape Library). If you use a deduplicating VTL device andTivoli Storage Manager data is backed up directly to VTL, LAN-free can be considered, but only for a physicalproxy.

2.4.2.4 Proxy CPU requirement with deduplication

If you use client-side deduplication, you must ensure sufficient CPU resources are allocated (whetherphysical or virtual). As an estimate, allocate 1.5 2.2ghz processors (virtual or physical) or equivalent perdatamover process when using Tivoli Storage Manager client-side deduplication.

2.5 Scheduling of Backups

The estimation technique described in this document is based on distributing the periodic full backupthroughout the backup cycle. For example, with a seven day backup schedule, on any day in the week 1/7thof the VMs will have a full backup scheduled and the remaining 6/7th will have an incremental backup. Thisdistribution can be accomplished through various methods, two of which are described below (Rotating Fulls

by ESX Host and Rotating Fulls by VM). Regardless of scheduling method, the estimation techniquedescribed in this document can still be applied, by adjusting the daily backup workload appropriately.

As with any backup technique, backup results should be monitored regularly to ensure that all VMs arebacked up according to business requirements.

2.5.1 Rotating Fu llsbackups by ESX Host

All the VMs on each ESX host are backed up once a week (full), and an incremental backup is scheduleddaily for six days. For more information, seehttps://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Recommendations+for+Scheduling+with+TSM+for+Virtual+Environments.

When you schedule backups on a per-ESX host basis, the VMs on each ESX host are backed up serially. Aproxy may not bet able to back itself up, so if you use a VM proxy, exclude the VM proxy from its own backupschedules.

2.5.2 A lternate Schedu l ing Methods

You can use other backup scheduling methods, based on business requirements or other characteristics ofthe environment.

2.5.2.1 Batched Fulls

Full backups for all ESX host/VMs are scheduled during an extended backup window (e.g., on the weekend).The remainder of the week, all VMs are backed up using incremental. This is usually suitable for smallerenvironments in which a full backup for all VMs can be architected within a 20 -40 hour window.

Typically, the full batch backup window requires a larger number of proxies than the incremental backups, sothe proxies are sized for the full backup window. The estimation technique and calculation method is thesame as described for Rotating Fulls except that the backup workload consists of 100% of all the VMs data.
https://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Recommendations+for+Scheduling+with+TSM+for+Virtual+Environmentshttps://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Recommendations+for+Scheduling+with+TSM+for+Virtual+Environmentshttps://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Recommendations+for+Scheduling+with+TSM+for+Virtual+Environmentshttps://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Recommendations+for+Scheduling+with+TSM+for+Virtual+Environmentshttps://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Recommendations+for+Scheduling+with+TSM+for+Virtual+Environments


15/18


Page 15 of 18

2.5.2.2 Rotating Fulls by VM

This method will require backup scheduling by individual VM and can include concurrent backup of multipleVMs on the same ESX host. Although it is possible to do this with the TSM scheduler, it is usually notpractical for large environments. Custom scripting methods can be used, via VMWares PowerCLI to obtainVM lists and drive TSM backup commands (dsmc backup vm) via a command line.

IBM Tivoli Lab Services provides an offering for custom backup scheduling based on specific customercriteria (such as balancing load within clusters, between data stores, etc.).

The same proxy sizing method described in this document can be used for the Rotating Fulls by VM.


16/18


Page 16 of 18

3. Your EstimateYou can use this table to provide your proxy sizing estimate, using the example as a guideline:

Environment Description

Total Number of virtual machines ___________

Average Utilized Storage per VM ________GB

Total Utilized Storage_____ * ___ GB

# of VMs * Avg. Storage Per VM_______ GB

Number of ESX Hosts _____

Number of DRS Clusters ___

Backup Window ___ Hours

Assumed daily change rate __%Determine Daily Backup Workload

Daily Backup Workload from FullBackups

______GB 7

NOTE: periodic full every 7 days_______GB

Daily Backup Workload fromIncremental Backups

(6 7) * ______ * 0.0_

NOTE: 6/7thof total data

multiplied by incremental changerate of 2%

_________GB

Total Daily Backup Workload _______ + ______ GB ______GB

Calculate Aggregate Throughput Requirement

Total Daily Backup Workload ______ + ______ GB ______ GB

Backup Window ______ hours

Aggregate throughput Required ______ GB ___ hours ______ GB/Hour

Calculate Number of Concurrent Datamovers

Aggregate throughput Required ______ GB ___ hours ______ GB/Hour

Per Process Throughput Estimate 100GB/Hour


______ GB/Hour 100GB/Hour ______

Determine Number of Proxy Hosts Required


______ GB/Hour 100GB/Hour ______

Number of concurrent datamoversper proxy

10

Number or proxy hosts required ______ 10 ______


17/18


Page 17 of 18

4. Proxy Host Resource RequirementsResource requirements for a proxy are driven by the following key factors:

I/O data transfer capacity

CPU capacity

Of the two factors, I/O capacity is the most important factor because the proxys main role is to move data.When you use client deduplication, the CPU resources may become the constraint for throughput.

4.1 Determining proxy resource requirements

4.1.1 Determ ining I/O resou rce requ irements

In the case of LAN data transfers the I/O resources for the proxy are the network adapter cards (NICs). In thecase of SAN data transfers (which includes SAN transport from the datastore to the proxy anad LAN-freefrom the proxy to the TSM server), the FC adapters (HBAs) are the critical I/O resource.When both LANand SAN transfers are used, then both NICs and HBAs are critical to support the required data transfer rates.An example of this is when LAN transport is used between the datastore and proxy, and LAN-free is usedbetween the proxy and the TSM server.

For virtual proxies, the resource requirements apply to virtual adapters and the requirements (number andspeed of adapters) will remain the same as a physical proxy. However, dedicating shared resources acrossan ESX hypervisor may require additional planning and configuration for a virtual machine.

The NIC and HBA adapters should be sized to ensure adequate capacity to handle the expected i/o datarates through the IP network and SAN, respectively.

Machine backplane i/o capacity must also be considered, but generally is not an issue for a properlyconfigured system.

4.1.2 Determinin g CPU requirements

For estimation purposes, use of a 2.2Ghz physical or virtual processor cores (or equivalent) per individualbackup process. Thus, a proxy that runs 8 concurrent backup processes would require 4 processor cores.

Note: Processor corerefers to a processing unit. A quad-core socket has 4 processor cores.

When you plan for deduplication, 1.5 processor cores should be configured per backup process. A 16 coreproxy host should have no more than 10 concurrent backup processes.

An advantage of considering virtual proxies is that you can distribute a larger number of proxies with smaller

resources to accommodate the same backup workload as fewer, physical proxies, that require moreresources each.

4.1.3 Memory est imat ion

The memory requirements for Tivoli Storage Manager for Virtual Environments backup processes are smalland generally not a constraint. The memory should be sized adequately for the proxy host operating system


18/18


(for example, Windows 2008R2). A minimum of 4GB of RAM should be considered when running fourconcurrent backup processes, with an additional 1 GB for each additional backup process.

END OF DOCUMENT

tsm ve 6.3 proxysizing v1.0

Documents