glasshouse tsm datadomain whitepaper

7/22/2019 GlassHouse TSM DataDomain Whitepaper

1/40

Tivoli Storage Manager (TSM) DesignBest Practices with Data Domain

GlassHouse Whitepaper

Introduction

TivoliStorageManager(TSM)customersrarelymanageenvironmentswithfixedor

shrinkingstoragepools.IfyouasaTSMadministratordofallintothisrarecategoryyou

neednotreadfurtherasthispaperwillnotlikelybeofinteresttoyou.Ifyouarebeing

askedtomanagemoredataandstorage,readon.

Written by:

John Merryman

GlassHouse

Technologies, Inc.

DataDomainprovidesanalternativestoragesolutionforTSMcustomerswhoarefaced

withneverendingdatagrowthandunabatedstorageexpansionassociatedwith

ballooningbackupandarchivedata.WhileTSMisoneofthemostscalabledata

protectionsolutionsavailabletothemarket,datagrowthanddataretention

requirementsdrivenearcontinualexpansiontoTSMstoragepools.

ThescopeofthiswhitepaperfocusesonhowtheDataDomainstoragesolution

integrateswithstandardTSMarchitecturalandoperationalenvironments.

TSMArchitectureandTerminology

TivoliStorageManager(TSM)isaclientserversoftwaresolutiondesignedfor

enterprisecustomers.Thecoreproductfunctionalityincludesbackup/recovery,

archive/retrieval,HSM,anddisasterrecovery.Thefollowingfigureillustratesthe

classicTSMarchitecturedesign.

1Copyright2007GlassHouseTechnologies,Inc.Allrightsreserved.


2/40

Figure1:ClassicTSMArchitectureDesign



3/40

EachTSMserverinstanceissupportedbyaselfmanagedrelationaldatabaseand

recoverylog.Aprimarydiskstoragepooloftenservesasaninitiallandinglocationfor

nightlybackups.ThisdataismigrateddailytothePrimaryStoragePoolandareplicaof

thisdataismaintainedinaCopyStoragePool,typicallyforpurposesofdisaster

recoveryandmediarecovery.Commonterminologyusedinthiswhitepaperis

providedinthefollowingtable.

Term Definition

SelectiveBackup Selectivebackupsallowyoutomanuallyselectaset

offilestobackupregardlessofwhethertheyhave

changedsinceyourlastincrementalbackup.

IncrementalBackup Incrementalbackupsonlybackupfilesthathave

changedsincethelastincrementalbackup.

PrimaryDiskPool Aprimarydiskpoolisastoragepoolconsistingof

disk

storage

volumes.

Disk

pools

are

traditionally

usedfordailyincrementalbackupstaging,upon

whichdataismigrateddailytoaprimarystorage

pool.

PrimaryStoragePool Anamedsetofvolumesthattheserverusestostore

backupversionsoffiles,archivecopiesoffiles,and

filesmigratedfromHSMclientnodes.Youcanback

upaprimarystoragepooltoacopystoragepool.

Primarystoragepoolscanbecomprisedoftapeor

diskvolumes.Multiplestoragepoolscanbecreated,

eachusingaspecificdevicetype.

CopyStoragePool Anamedsetofvolumesthatcontainscopiesoffiles

thatresideinprimarystoragepools.Copystorage

poolsareusedonlytobackupthedatastoredin

primarystoragepools.

Copystoragepoolscanbecomprisedoftapeordisk

volumes.Multiplestoragepoolscanbecreated,each

usingaspecificdevicetype.

LANFreeBackup Thedirectmovementofclientdatabetweenaclient

machineandastoragedeviceonaSAN,ratherthan

ontheLAN.LANFreebackupscanonlybe

configuredtowritetoTSMtapeorvirtualtapedevices.

NDMPBackup Anindustrystandardprotocolthatallowsanetwork

storagemanagementapplicationtocontrolthe

backupandrecoveryofanNDMPcompliantfile

server,withoutinstallingthirdpartysoftwareon



4/40

Term Definition

thatfileserver.

Expiration Expirationisadailyadministrativeprocess,which

deletesrecordsforTSMobjectswhichareexpired

from

the

TSM

database.

Reclamation Reclamationisadailyadministrativeprocess,which

reclaimsunusedspaceinsequentialstoragepoolsby

mountingpartiallyfilledvolumesandmigrating

datatoreturnthesevolumestoascratchstatus.

Migration Migrationisadailyadministrativeprocess,which

migratesnewincrementalbackupdatafroma

PrimaryDiskPooltoaPrimaryStoragePool.

Migrationistypicallyscheduledasthelast

administrativebatchprocess,priortotheproduction

backupwindow.

ActiveDataPool AnactiveTSMfilerepresentsthemostrecentactive

versionofafileonthebackupclientmachine.An

ActiveDatastoragepoolcontainsonlyactivefiles.

BatchProcess TSMbatchprocessesincludenonbackupand

restorerelatedprocesseswhichareessentialforTSM

dailyoperations.Batchprocessesaretypically

scheduledaftertheproductionbackupwindow,and

includeadministrativeandstoragemanagement

functionssuchasstoragepoolbackups,expiration,

TSMdatabasebackups,andmigration.

Table1:

TSM

Terminology

TypicalTSMChallenges

ThetypicalTSMenvironmentsupportshundredstothousandsofclients. TSMscalesby

addingadditionalTSMserverinstances,andassociateddiskandtapestorageresources.

ThemostcommonchallengesinTSMenvironmentsinclude:

CompletingbatchTSMworkloads(storagepoolbackups,offsitetapevaulting,

andreclamation)withlimitedtimeandphysicalresources

Contendingwithextremelylargeclientbackups(>2TBincrementalchangeper

client,orseveralmillionfileschangingperday)

ScalingTSMinstances,databases,logs,storagepoolstokeepupwithsheer

demand

Eliminatingredundantdatabackups(copiesofdatabases,aggressivebackup

retentionpolicies,etc.)



5/40

Eliminatingperformancebottlenecks(TSMserverordatabase,networking,

client,etc.)

Lackofcapacityplanningandreportingdisciplines

TechnologyOverview

DataDomaineliminatesunnecessaryTSMdatastorageviadatadeduplicationand

traditionalcompression.Datadeduplicationisperformedonincomingdatastreamsand

allowsredundantsegmentsofdatatobeidentifiedandstoredasuniqueinstances

withintheDataDomainRestorerfilesystem.Thefollowingtablelistskeyterminology

forDataDomain.

Term Definition

DataDomainRestorer(DDR) AstandaloneDataDomainstorageappliance,

gateway,orasinglecontrollerinaDDXarray.

ProtectedDataSize Thesumtotalofallfilesizesintheactivesetof

primarydatabeingbackedup(equivalenttothe

TSM5.4conceptofActiveStoragePool).

LogicalStorageSize Thetotalsizeofallbackupimagesinallstorage

poolsonaDataDomainRestorer.Thistotalsize

includesallstoragepoolsinTSMmappedtoaData

DomainRestorerinstance,whichcaninclude

primarydiskpools,primarystoragepools,andcopy

storagepools.

DiskPoolDumpSize Thesizeofanindividualbackupimagewrittentoa

storagepool(forexample,onenightsworthof

backupdata).

AddressableCapacity TheamountofphysicalspaceavailableonaData

DomainRestorertostorededuplicatedand

compressedbackupimages.

PhysicallyConsumedStorage TheamountofaddressablecapacityonaData

DomainRestorercurrentlystoringbackupdataand

associatedmetadata.

CumulativeCompression

Factor

Theratioofthelogicalstoragesizetothephysically

storedspace.

PeriodicCompressionFactor Theratioofoneormorediskpooldumpstothe

physicallyconsumedstorageforthosedumps. Note

thattheperiodiccompressionfactoroverany

intervalbeyondthefirstfewdayswilltypically

exceedthecumulativecompressionfactorbyalarge

marginbecausethefirstversionofafilewrittentoa



6/40

Term Definition

DataDomainRestorerwillcompress lessthan

subsequentversions. Considerforexampletwo

selectivebackupsof100GBofprotecteddataover

twonights:typicalperiodiccompressionfactors

mightbe2:1thefirstnightand50:1thesecondnight,butthecumulativecompressionfactorwouldonly

be~4:1(200GB/50+2GB)ratherthanthe25:1orso

onemightexpect. Notefurtherthatwhilethe

cumulativecompressionfactoriswhatdetermines

costperGB,itistheperiodiccompressionfactorthat

mostaffectsreplicationbandwidthrequirements.

Deduplication Replacing4KBto16KBsegmentsinincomingdata

streamswithverysmallreferencestoidentical

segmentsalreadystoredondisk. Alsoknownas

globalcompression.Segmentsizeisexpressedin

binaryvalues.

LocalCompression Standardlosslesscompressionalgorithms. The

availableLocalCompressionalgorithmsavailableon

aDataDomainRestorerincludeLZ(LempelZiv),gz

andgzfast.

Cleaning Aperiodicprocesstofindanyunreferenced

segmentsonaDataDomainRestorerandmakethat

spaceavailableforsubsequentbackups. Because

DataDomainRestorersneveroverwritedata,file

deletesbyaTSMserverdonotimmediatelymake

spaceavailable

for

subsequent

backups

cleaning

mustrunfirst. Cleaningmaybeperformedona

DataDomainRestoreratthesametimeas

backup/restoreI/O,butbecausecleaningisafairly

resourceintensiveprocessitisbesttoscheduleitfor

nonpeakhours. Thedefaultscheduleforcleaningis

Tuesdaymorningat6:00a.m.butmaybe

rescheduledforanyconvenienttimesduringthe

week.

Table2:DataDomainTerminology

Note:DeduplicationisalsoreferredtoasGlobalCompressioninDataDomainproductliterature,butforpurposesofthiswhitepaperwillbereferredtoas

deduplication.

DataDomaindatadeduplicationmethodsaremoregranularandvariablethanfixed

segmentsizedatadeduplicationcounterparts. DataDomainsegmentlengthisvariable

,rangingfrom416KB. Thisisasignificantdifferentiatorfromcompetitiveproducts



7/40

whichperformdeduplicationatthefileleveloratablocklevel,resultinginmore

efficientdeduplicationcapabilities.

Sinceatmostsitestherateofprimarydatachange(newlyintroducedunique4Kto16K

segments)staysaboutthesamefromnighttonight,theamountofphysicallyconsumed

storageforaselectiveTSMbackupisroughlythesameasthephysicallyconsumed

storageforanincrementalTSMbackup. Theratioofprotectedstoragesizetoincrementallyconsumedphysicalstorageeachnightstaysaboutthesame,butthe

periodiccompressionfactorofanincrementalbackupismuchlowerthantheperiodic

compressionfactorofaselectivebackup(becausetheformerismuchsmallerinsize).

Asaresult,itisextremelyinexpensivetoincludemanyversionsoffilesinastoragepool

onaDataDomainRestorer.Therelativesizeofprotecteddataandincrementalbackup

data,beforeandafterdeduplicationandcompressionisillustratedinthefollowing

figure.

Figure2:BackupDataDeduplicationandCompression

Bothdeduplicationandstandarddatacompression(alsoreferredasLocal

Compressioninproductliterature)areexecutedvialosslesscompressionmethods(ie.

nodataintegrityimpact).LempelZiv(LZ)compressionisstandard,howeverGZFastor

GZarealternativesavailabletoeachDataDomainRestorerinstanceforstandarddata

compression. Asarule,backupdatashouldnotbecompressedpriortoattempting

additionalcompressionatthedevicelevel.

Data

Domain

Architecture

and

Models

ThebaseDataDomainRestorermodelsupportsupto16TBofaddressablestorage,

whichmeansthatdependingondatadeduplicationandcompressionrates,80241TBof

logicalstorageisavailabletoeachinstanceofaDataDomainRestorer.



8/40

EachDataDomainRestorerinstancesupports100MB/secaveragethroughput.Thisbase

metricappliesbothtoreadandwriteoperations,asthearchitectureisoptimizedfor

sequentialI/O.

ModelName Addressable

Capacity

LogicalDataStorage

(TB)*

MaximumI/O

Performance

(GB/Hour)

DDX/16Fully

Expanded

usingDD560 256.8 1,2843,852

DDX/16 82.6 4131,239 6,554

DD560Fully

Expanded

16.05

80

241

DD560 5.29 26 79 410

DD460 4.3 22 65 297

DD430 2.1 11 32 225

DD410 0.8 4 12 164

Table3:DataDomainModels,AddressableandLogicalCapacity

Note:LogicalDataStorageValuesabovereflectarangeof5xto15xdeduplication

andcompressioneffectsonbackupdata.Theactualvaluesarehighlydependent

ondatavolatilityandbackuppolicies.

ThesolutionscalesbyincrementallyaddingeithercapacitytoanexistingDataDomain

Restorerinstance,oraddinganewDataDomainRestorerinstancetotheTSM

productionenvironment. MultipleDataDomainRestorerinstancescanberackedand

managedthroughanenterpriseconsole;howeverlogicalmanagementofeachData

DomainRestorerinstanceisstillrequired.ThefollowingfigureillustratesDataDomain

Restorerarchitecturescalability.



9/40

Figure3:DataDomainRestorerArchitectureScalability

FileSystemandVTLIntegration

Data

Domain

Restorer

supports

two

integration

methods

with

TSM,

either

via

network

filesystemmountsorasastandaloneVirtualTapeLibrary(VTL).DataDomainRestorer

canruninamixedmodecapacity,providingbothinterfacemethodsconcurrentlytoone

ormanyTSMserverinstances. Thisflexibilityaffordsagreatnumberofintegration

scenariosforTSM. Thefollowingfigureillustratesbothintegrationscenarioswitha

TSMserver.



10/40

Figure4:TSM DataDomainRestorerIntegration

Fornetworkfilesystemaccess,TSMaddressestheDataDomainRestorerdeviceviaa

nativeNFS/CIFSmount.TSMaddressestheusablespaceexactlyasitwouldastandard

filesystemmountpoint(NTFS,JFS,UFS,etc.).

TheVTLinterfaceemulatesaSTKL180tapelibrarymanager,andrequiresafiber

channelconnectionalongwiththeappropriateTSMdevicedriver.NDMPbackupsare

alsosupportedviatheDataDomainVTLinterface. MultipleinstancesofVTLcanbe

createdperDataDomainRestorerinstance.Upto47LTOtapedrives,10000slots,and

100,000virtualcartridgescanbecreatedperDataDomainRestorerinstance.Asa

standaloneVTL,existingphysicaltaperesourcescanbeleveragedbynativeTSM

capabilities.

Replication

Asynchronousdata

replication

is

supported

between

Data

Domain

Restorer

instances.

Oncetheinitialmirrorreplicaisestablished,onlychangestoindex/metadataandnew

datasegmentsarereplicatedtothetargetsite.Asaresult,WANbandwidth

requirementsaresignificantlyreducedbyupto99%andtheamountoftimetoreplicate

datatoanoffsitelocationissignificantlyreduced.

ReplicationisconfiguredinCollectionorDirectorymode.Collectionmodeallowssingle

DataDomainRestorerinstancestobeconfiguredinasourcetargetrelationship,with



11/40

onewayreplicationonly.Directoryreplicationsupportsmanytooneconfigurations

whichareestablishedatthedirectory/mountlevel.Directoryreplicationsupports

bidirectionalreplicationbetweenDataDomainRestorerinstances,whichisidealfor

variousDRarchitectures,includinghubspokearchitecturesforremoteoffices.

Figure5:CollectionandDirectoryReplicationModes

HowDataDomainBestFitswithTSM

ADataDomainRestorerprovidesanalternativefordiskandtapestoragepoolsinTSM.

TheDataDomainfilesystemisoptimizedforsequentialreadandwriteoperations,

whichmakeforagreatfitwithTSMproductionbackupandbatchworkloads.AData

DomainRestorercanbeconfiguredasaprimaryorcopystoragepoolinTSM.

Note:TSMwasdesignedforadeploymentmodelwherebackupdataiswritten

firsttoaTSMprimarydiskpool(aDISKTYPEpoolontraditionaldiskmedia)andthensubsequentlycopiedtootherdiskortapestoragepoolsforlonger

retention. TheDataDomainRestorerprovidesanoutstandingtargetforthese

lattercopies,andinsmallerenvironmentsitisoftenpossibletoeliminatetheTSM

primarydiskpoolaltogetherandtargetbackupsdirectlytoa(FILETYPE)

storagepoolonaDataDomainRestorer. ForlargerTSMenvironmentswhere

morethan20concurrentbackupsessionswouldberequiredperDataDomain



12/40

Restorerinstance,werecommendcontinueduseofaTSMprimarydiskpoolfor

incomingbackupclienttrafficthatissubsequentlycopiedtoa(FILETYPE)

storagepoolonaDataDomainRestorer.

TSMdatabasesshouldcontinuetobeprovisionedontraditionaldiskdevices.AData

DomainRestorershouldnotbeusedforstoringactiveTSMdatabases,logs,and

configurationfiles.Instead,theseTSMelementscanbebackeduptoaDataDomainRestorerforoperationalrecoveryandreplicatedtoaremotesitefordisasterrecovery.

Note:SomeTSMenvironmentssupportextremelyhighperformancebackupsfor

highvolumeclients.Typically,specializeddesignsareimplementedtosupport

backupsof14TB/hour.TheDataDomainRestorerarchitecturecanbeconfigured

tosupporthighperformanceworkloads(viamultipleparallelinstanceswitheach

DataDomainRestorerinstancesupporting100MB/secworkloadsoncurrently

shippingDataDomainRestorers.

Planning/SizingConsiderations

BackupPoliciesandDataVolatility

TSMpoliciesareuniquetoeachcustomerenvironment,buttypicallyrangefrom7to60

effectiveversionsforactivefiles.Mostsitesuseincrementalbackupsandrarelyrun

selective(full)TSMbackups.Backuppoliciesandassociatedclientdatachangerates

spellthefateofstoragepoolsizesinTSM. WhileTSMbenefitsfromanincremental

foreverbackupmethodology,datavolatilityisthefinalarbiterfortheamountof

backupdatastoredbyTSM.

TheimpactofbackuppoliciesonDataDomainRestorersizingislesssignificantthanthe

datavolatilityandactualdatachangerate. FromaTSMperspective,adatabasebackup

mayappearnetneweachtimeitisbackedup,butfromaDataDomainRestorer

perspective,theactualdatachangesmayresultinminimalnewphysicalstorageconsumption. Databases,email,andunstructureddata(fileserverdata)willbenefitthe

mostfromdatadeduplicationinmostproductionenvironments.Datagrowthissuesare

alsocompoundedbyreportingcopiesofproductionandthehighvolumesof

applicationtestdata,allofwhicharetypicallybackedupdailytoTSM. Thenetresultis

aneverendingdemandforTSMphysicalstorageresources.DataDomaincountersthe

effectsofuncontrolleddatagrowthonTSMstorage.

Deduplicationbenefitsarerealizedovertimeandeventuallyplateauoncethebackup

versioningpolicyandtheincrementalbackuptrafficisfullyrealized.Sincedatachange

ratesvarybydatatypeandproductionenvironment,acombinationofbackuppolicies,

datavolatility,anddatastructureimpactsDataDomainRestorersizingestimates.

Sizing

Sizingstoragecapacitiesforadatadeduplicationsolutiontakesintoconsiderationactual

datachangerates,whicharenotvisiblefromaTSMperspectivesinceTSMviewsdata

changeatthefile/objectlevel.



13/40

TheratioofcurrentbackupdatatoDataDomainRestorerdatastorage(afterdata

deduplication+compression)varies,butonaverageTSMcustomerscanexpectupto

15:1backupdatareduction. This ratioiswhollydependentonthedatavolatility,

backupmethodsbeingused,andthebackuppolicy.

Note:ForcustomersusingVTLmode,DataDomainRestorerdoesnotrequirespace

preallocationforvirtualtapevolumes.AsvirtualtapevolumesaremountedandfilledintheDataDomainRestorer,physicalspaceisnothedgedforscratchvirtual

tapevolumes. OtherVTLtechnologiespreallocatephysicaltapevolumes,

regardlessofwhetherornottheyareempty,full,orfilling.

AninitialsizingmetricfortheDataDomainRestoreristoestimatehalfoftheprimary

volumeofdataonallbackupclients,ora2:1ratioofprimarydata(nottobeconfused

withbackupdata)totheDataDomainRestoreraddressablecapacity.Anotherapproach

istototaltheoccupancyofTSMstoragepoolsandestimateusableDataDomain

Restorerstorageusingafactorof15:1(TSMStoragePoolOccupancytoDataDomain

RestorerAddressableCapacity)andthenbufferwithcapacityoverhead,asoutlinedin

thefollowingtable.

Storage

Pool

Occupancy

(TB)

Data

Domain

Restorer

Sizing

Metric

CapacityOverhead DataDomain

Restorer

Addressable

CapacityRequired

(TB)Note1

Storage

PoolA 40 15:1 25% 3.3

Storage

PoolB

30

15:1

25%

2.5

Storage

PoolC 50 15:1 25% 4.2

Note1:ForPoolA:3.3TB=1.25*(40/15)

Table4:DataDomainRestorerSizingExample

FornewDataDomainRestorercustomers,DataDomainrecommendsongoingcapacity

planning,throughadisciplineofsizing,provisioning,utilization,andongoing

measurement.Thisidealcapacityplanningmethodincludesongoingmeasurement,and

demandforecasting

once

a

subset

of

production

backup

data

is

sent

to

a

TSM

server

usingDataDomainRestorerandpoliciesarefullyrealized.Generally,thebenefitsof

datadeduplicationarerealizedovertimeasbackuppoliciesarefullyrealized.Only

then,dodatavolumesplateauwithinDataDomainRestorerinstances.

Note:AlthoughmostTSMenvironmentslimittheeffectivenumberofbackup

versionsduetophysicalspacelimitations,theimpactofadditionalbackupversions

toDataDomainRestorerisoftennegligible.Whilethisbenefitallowsmoreflexibility



14/40

foraggressivebackuppolicies,TSMdatabasesizeshouldremainakeyconsideration

inTSMpolicyplanning.



15/40

Integrationplanning

AsingleTSMservercanmapasingleormultipleDataDomainRestorerdirectoriesto

supportaprimarystoragepool.MultipleTSMinstancescanbemappedtoasingleData

DomainRestorerinstance,givenappropriatenetworkbandwidthandperformance

requirements.ThefollowingfigureillustratesTSMintegrationwithaDataDomain

Restorerinaprimaryandalternatesiteconfiguration.

Figure6:TSMSiteIntegration



16/40

OneormoredirectoriescanbespecifiedasthelocationoffilesforaFILEdeviceclass.

Asaresult,multipleDataDomainRestorerinstancescanbededicatedtoasingleTSM

instance;howeverthebenefitsofdatadeduplicationdonotspanmultipleDataDomain

Restorerinstancesatthistime.Storagepoolscontaininglikedatacanbemappedto

individualDataDomainRestorerinstances,ortoindividualmountpointswithinaData

DomainRestorer. Forexample,someTSMadministratorscreatepolicydomainsforall

fileservers,whereasignificantvolumeofprimaryunstructureddataisredundant.

Mappingthispolicydomainandassociatedstoragepool(s)toaDataDomainRestorer

expandsthebenefitsofdatadeduplicationaboveandbeyondredundantbackupcopies.

Thefollowingfigureillustratesthisconcept.

Figure7:MappingDataTypestoStoragePoolsandDataDomainRestorerInstances



17/40


18/40

Figure8:LargeSiteTSMIntegration

OperationalConsiderations

Regardless

of

the

storage

technologies

in

place,

the

TSM

functions

optimally

when

there

islittletonooverlapbetweenthebackupwindowandbatchprocesses.TSMbatch

processesrunmostefficientlywithserialschedules.Dailyoperationsconsistofthe

typicalroutines,outlinedinthefollowingdiagram.



19/40

Figure9:TSMDailyOperations

TSMcanbeintegratedwithaDataDomainRestorerwithoutchangingtheoverall

approachtobatchprocessmanagementinTSM. TSMreclamationprocessingis

requiredtoreclaimexpiredspaceintheDataDomainRestorerstoragepools,following

normalTSMreclamationprocessingprocedures.Asabestpractice,batchTSM

schedulesshouldbescheduledsequentiallywiththewait=yesconditiontoensurea

cleantransitionfromoneprocesstothenext.



20/40

IftheDataDomainRestorerarchitectureisleveragedforoffsitestoragereplication,the

TSMcopystoragepoolsandassociatedbackupstoragepoolbatchprocessescanbe

eliminated,alongwithmanualtapevaultingprocesses.Thisimplementationstrategy

significantlyreducestheamountoftimerequiredtocompletebatchoperationsas

illustratedinthefollowinggraphic.

Figure10:

TSM

Daily

Operations

with

Data

Domain

Capacityplanningandspacemanagementisanewoperationalrequirementwhenusing

aDataDomainRestorerwithTSM.Justlikephysicaldiskandtaperesource

managementinTSM,DataDomainRestorerinstancesmustbemanagedtoensure

efficientutilizationandsufficientavailablespace.Asillustratedinthefollowingfigure,

theTSMadministratorshouldmonitoravailableDataDomainRestorerspaceasa

routineoperationaltask.

Resource SizeGB UsedGB AvailGB Use%

/ddvar 78.7 17.7 57.1 24%

Precompression 6296.1

DataIf100%cleaned* 14949.7 373.1 14576.6 2%

Metadata 19.4 0.2 18.2 1%

Index 17.2 4.8 12.3 28%

Estimatedcompressionfactor*:16.6x=6296.1/(373.1+0.2+4.8)Figure11:ExampleDataDomainRestorerStorageUtilization



21/40

TheDataDomainRestorerrequiresanadditionaloperationalprocesstoperform

cleaningoftheDataDomainRestorerfilesystem,whicheffectivelyreclaimsspaceand

optimizestheDataDomainRestorerfilesystemforperformance.Thedefaultschedule

forcleaningistorunweekly,howeverdependingondatavolatilityandavailableData

DomainRestorerspacethisprocesscanbescheduledmorefrequently(23timesper

week).

Note: TheDataDomainRestorercleaningprocessisresourceintensive.Athrottle

commandisavailabletoassigntherelativeprioritytocleaningprocessestonormal

backupandrestoreI/O.WerecommendtheDataDomainRestorercleaning

processesrunperiodicallyaspartofstandardTSMoperations,scheduledwhen

backup/restoreactivityisatminimumlevels.

WhileexpirationprocessinginTSMimmediatelydeletesdatafromfiletypedevice

classstoragepools,thedataisnotimmediatelydeletedfrom virtualtapevolumeswhen

usingaDataDomainRestorerinVTLmode(exactlyasistruewithphysicaltape

volumes).Consequently,TSMreclamationprocessingshouldstillberunonVTLstorage

poolstoeffectivelyreclaimunusedspaceonvirtualvolumesandreturnthesevolumes

toscratchstatuswithinTSM.

RecoveryConsiderations

ThemajorityofTSMsitesleveragetheincrementalforeverapproachforproduction

backups.Whilethisminimizesbackupstorageresourcerequirements,incremental

changesareoftenspreadacrossmultiplephysicaltapevolumes,andconsequentlylarge

restoreoperationsrequiremultiplemountsandinsomecasessignificantamountsof

timetoperformrestoreoperations.

TSMadministratorscontendwiththischallengebyleveragingstoragepoolcollocation,

runningperiodicselectivebackups,orperformingmovenodedataoperationsto

consolidateclientdataontofewerphysicalvolumes.Eachoftheseoptionsdemandtape

processingresources,oftenwhichareinhighdemandinabusyTSMenvironment.

ADataDomainRestorerstoragepool(andmovingfromtapeingeneral),eliminatesthe

sequentialaccesslimitationsofphysicaltape,andprovidesimmediateaccesstoall

incrementalbackupobjectsrequiredforarestoreoperation.Thiscapabilitycan

significantlyimproverestoreperformanceforTSM.

Note: AswithanyTSMstoragedevice,therestoreperformanceofeachData

DomainRestorerinstance(100MB/sec)mustbetakenintoconsiderationwhen

planningforlargeclientorlargescale(disasterrecovery)restoreoperations.



22/40

IntegrationBasics

TSMServerTuning

TSMServertuningisrecommendedfornewDataDomainRestorerimplementations

usingNFS/CIFSandIPprotocol.TheTSMoptionscanbesetbymodifyingthe

DSM.OPT

server

configuration

file

or

by

executing

the

associated

SET

commands.

Note:SomeTSMServerconfigurationchangesrequireaTSMserverrefreshtotake

effect.

ThefollowingtableoutlinesstandardTSMservertuningparametersforoptimalData

DomainRestorerperformancewithTSM,usingNFS/CIFSandIPprotocol.

ConfigurationType Comments

TSMServer

ApplicationConfiguration

(DSM.OPT)

BUFPoolsize262144(exampleonly)

LOGPoolsize512(exampleonly)

TXNGroupmax256

MOVEBatchsize1000

MOVESizethresh2048

TCPWindowsize512

USELARGEBufferYes

TCPNODELAYYes

AIXNetwork

Configuration

ifconfigen0tcp_recvspace65536tcp_sendspace65536

tcp_nodelay1

tcp_nodelayack

sb_max

HPUXNetwork

Configuration

Enterthefollowingtwocommandsthenremountthe

restorerNFSsharetoenablethevalues:

ndd set/dev/tcptcp_recv_hiwater_def262144

ndd set/dev/tcptcp_xmit_hiwater_def262144

SOLARISNetwork

Configuration

Createafile/etc/rc3.d/S90ddr.Enterthefollowingtwolines

inthefile:

ndd set/dev/tcptcp_recv_hiwat131072

ndd set/dev/tcptcp_xmit_hiwat131072

Inthefile/etc/system,addthefollowinglines:

setnfs:nfs3_max_threads=16

setnfs:nfs3_async_clusters=4



23/40


setnfs:nfs3_nra=16

setrpcmod:clnt_max_conns=1

setfastscan=131072sethandspreadpages=131072

setmaxpgio=65536

LINUXNetwork

Configuration

echo 3276826214416777216 >

/proc/sys/net/ipv4/tcp_rmem

echo 3276826214416777216 >

/proc/sys/net/ipv4/tcp_wmem

echo262144>/proc/sys/net/core/rmem_max

echo262144>/proc/sys/net/core/wmem_max

echo262144>/proc/sys/net/core/rmem_default

echo262144>/proc/sys/net/core/wmem_default

echo536870912>/proc/sys/kernel/shmmax

echo536870912>/proc/sys/kernel/shmall

WINDOWSNetwork

Configuration

Note: DonotmodifytheWindowsregistryparameter

AFD iftheTSMserveroranyassociatedTSMclientsare

supportedbyWindowsNT4.0

1. OpenREGEDT32andnavigateto:

HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCON

TROLSET\SERVICES\AFD\PARAMETERS

2. AddanewDWORDvaluetotheDefaultSendWindow

keyandsetthevalueto65536(decimal).

3. AddanewDWORDvaluetothe

DefaultReceiveWindowkeyandsetthevalueto65536

(decimal).

4. WithinREGEDT32,navigatetothefollowinglocation:

HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\TCPIP\PARAMETERS

5. AddanewDWORDvaluetothe

GlobalMaxTcpWindowSizekeyandsetthevalueto

65536(decimal).

6. AddanewDWORDvaluetotheTcpWindowSizekey



24/40


andsetthevalueto65536(decimal).

7. AddanewDWORDvaluetotheTcp1323Optskeyand

setthevalueto3.

8. RestarttheWindowsserver.

Table5:TSMServerConfigurationGuidelinesforNFS/CIFSandIPProtocol

Note:TSMbufferpoolspacepreallocatesphysicalmemoryasamemorycache

forTSMdatabasetransactions,andprovidesdatabaseperformance

improvements. TSMbufferpoolsizingmustbecustomizedbyadjustingthe

bufferpoolsizetotheamountofphysicalmemoryavailabletotheTSMserver.

NetworkFileSystemIntegration

NFSisthemostcommonlyusedTSMimplementation methodforaDataDomain

Restorer. NFSmountsrequireIPprotocolandadedicatedGigabitVLANordirect

GigabitconnectionisrecommendedforTSMserverintegration.Jumboframesmaybe

usedtomaximizeTCP/IPprotocolefficiencyandprocessoroverheadontheTSMserver.

NetworkconnectiontrunkingisnotcurrentlysupportedbytheDataDomainRestorer.

DataDomainrecommendsthefollowinggeneralNFSconfigurationsettingsfor

mountingaDataDomainRestorertoaTSMserver.

TSMServer

Platform

NFSConfiguration

AIX mountvnfso

proto=tcp,vers=3,intr,hard,combehind,rsize=32768,wsize=32768,llock

ndd200restorername:/backup/mountpoint

Solaris mount Fnfs ohard,intr,vers=3,proto=tcp,rsize=32768,wsize=32768

restorername:/backup/mountpoint

HPUX mountFnfsorsize=32768,wsize=32768,hardrestorername:/backup

/mountpoint

LINUX mount tnfs ointr,hard,rsize=32768,wsize=32768,proto=tcp,vers=3

ddr:/backup/dd/

Windows CIFSaccesstoDataDomainRestorerisrecommendedforWindows

TSMServers

Table6:NFSMountConfigurationGuidelines

Note:DataDomainonlysupportsTCPprotocolwithNFS,andrecommends

hardmountstoensureavailabilityafterTSMserveroutages.



25/40

StoragePoolandDeviceClassDesignConsiderations

TSMallowsdisktypedeviceclassestobedefinedaseitherFILEorDISKtype. FILE

deviceclassesarecommonlyusedinTSMforvirtualvolumemanagement,however,

mostTSMadministratorsdefinediskstoragepoolsusingDISKdeviceclassdefinitions

andassociateformatted*.dsmfilesasstoragepoolvolumes.

Note:TheTSM5.3and5.4AdministratorsGuidestatesTivoliStorageManager

supportstheuseofremotefilesystemsordrivesforreadingandwritingstorage

pooldata,databasebackups,andotherdataoperations.

FILEtypedeviceclassesarerecommendedforusewithaDataDomainRestorer.FILE

deviceclassesallowTSMtoperformsequentialread/writeactivitytofileswithinafile

system. Incomingbackupdataiswrittentoafile,andonceafileisfilled,anewscratch

fileisautomaticallycreatedbyTSMandisfilledwithadditionalincomingbackupdata.

Note:Random/DiskdeviceclassesarenotsupportedwiththeDataDomain

Restorerasastoragepooldevice.

SeveraloptionsexistfordeviceclassandstoragepoolconfigurationsinTSM.TheFILE

deviceclassforsequentialmediaallowsafilesystemmountpointtobedefinedfora

primaryorcopystoragepool.

OneormoremountpointscanbespecifiedasthelocationoffilesforaFILEdeviceclass;

howeverthereisnobenefittocreatingmultipledirectories/mountpointswithinasingle

DataDomainRestorerinstancefromaperformanceperspective,howeverkey

advantagesareexploredaboveintheIntegrationPlanningsection.

DeviceClassConfiguration Detail

Directory CreateaseparatefolderforeachTSMdeviceclass

(FILETYPE)

Performcapacityplanningandmeasurementto

ensuretheDataDomainRestorercapacityis

adequateforeachfolder

Ifsubdirectoriesarecreated,exportthe

subdirectoriesviaNFStoensureTSMcalculates

accuratespaceforvolumes.

FormultipleTSMserversusingasingleData

Domain

Restorer

instance,

create

a

separate

file

systemmountpointorfolderforeachTSMinstance

MaximumCapacity ThedefaultTSMMaxCapacityvalueforaFILE

deviceclassis2GB. Dependingontheoperating

systemoftheTSMserver,maximumcapacity

parametersvary.Thisparameterissizedbetween

200and400GBforDataDomainRestorer



26/40

DeviceClassConfiguration Detail

implementations.

MountLimit ThedefaultMountLimitvalueis20andthe

maximumvalue

for

this

parameter

is

4096.

This

meansthatupto4096individualfilescanbeopened

atasingletime. EachDataDomainRestorer

instancesupportsupto20concurrentI/Othreads,

sothedefaultMountLimitvalueisrecommended.

Table7:TSMFileDeviceClassConfigurationStandards

NDMPIntegration

NDMPprotocolisstandardwithNetworkAttachedStorage(NAS)devicesindustry

wide.FollowingstandardintegrationtechniquesusedwithTSMandphysicaltape

libraries,theDataDomainRestorerprovidesthesamefunctionalityforNDMP

integrationwhenrunninginVTLmode.

Figure12:NDMPIntegrationwithTSMandDataDomainRestorer



27/40

LANFreeBackupIntegration

TSMsitesleverageLANFreebackupsforlargedatabasebackups(usuallydatamarts

andwarehouses)directtotape.LANFreebackupsaretypicallyconfiguredwith212

tapemounts(dependingonthedrivetechnology)perbackupclient,toaccommodate

extremelyhighperformancebackups.ThebackupdatamovesacrossFiberChannel

directlyfromtheTSMclientmachinetothemountedtapedevices,whilebackup

metadataisbrokeredtotheTSMserveroverIP.FiberChanneloffersthebenefitofdirect

channelconnectivityandareductioninserverCPUresourceconsumptionduringthe

backupwindow.

LargeTSMLANFreeimplementations(withdozenstohundredsofmountpoints)must

accomplishaperfectbalancingactoftapedriveavailability,availablemountpoints,

andappropriatebackupschedulingtoavoidcontentionformountpoints.Whenthe

balancingactfails,sodomanyLANFreebackupjobsthatusuallyhavealimited

windowavailableforproductionbackup.WhenLANFreebackupsoverlapwiththe

batch

TSM

window,

resource

contention

issues

typically

cascade

and

TSM

administratorsendupsacrificingeithermissed/failedLANFreebackupsordailybatch

processes.WeincreasinglyseededicatedIPbasedalternativesreplacinglegacyLAN

Freeconfigurations,duetoloweradministrativeoverheadandmanagementcomplexity.

ForTSMsitesthatneedtoretainLANFreechannelconfigurationsfornetwork

performancereasons,aDataDomainRestorerrunninginVTLmodeoffersan

alternativesolution.VTLoffersahighnumberofavailablemountpointsandhigher

availabilityofvirtualtapedrivescomparedtophysicalcounterparts. SeveralData

DomainRestorerinstanceswouldneedtobedeployedtoprovidethesamebackup

performanceinaLANFreeconfigurationusingseveralhighperformancetapedrives.

ThefollowingdiagramillustratesTSMLANFreeintegrationwiththeDataDomain

Restorer.



28/40

Figure13:TSMLANFreeClientIntegrationwithDataDomainRestorer

ActiveDataPools

ActiveDatapoolsareanewTSMfeatureaddedinTSM5.4.Thisfeaturegroupsactive

TSMfilestogether,whichcangreatlyincreasethespeedofTSMrestores. TheData

DomainRestorerprovidesanoptimallocationforActiveDatapools. ByplacingActive

DatapoolsonthesameDataDomainRestorerastheprimarystoragepools,therewill

bealmostnoimpactonthespacerequiredtostoretheActiveDatapools. SincetheData

DomainRestorerisalreadystoringtheprimarypoolwithalltheactiveandinactive

copies,theActiveDatapoolswillcontain100%duplicatedata.

Note:ActiveDataPoolssignificantlyreducerestoretimesfromphysicaltapestoragepoolsonly.



29/40

Figure14:UsingActiveDatapoolswithDataDomainRestorers

ArchivingIntegration

LongtermdataretentioninTSMisaccomplishedeitherviatraditionalbackupor

archivefunctionality.TSMarchivefunctionsasaselective,nonincrementalcopyofdata

forlongtermretention.Byextendingbackupmanagementclassretentionsettings,

traditionalbackupscanbescheduledonaninfrequentbasis(monthly,quarterly,etc.)

usinganalternateTSMnode(BackupClient01_Arc).ThisalternateapproachallowsTSM

toaccomplishlongtermretentionwiththebenefitsofincrementalbackupcopies.

ForTSMsitesdesiringlongtermretention,aDataDomainRestorercanbeleveragedas

aprimaryorcopystoragepoolforarchivedata,orasastagingareaforincoming

archivedata.ThefollowingdiagramillustratesTSMarchivedatamovementtoaData

DomainRestorerarchivestoragepool,whichisconfiguredtomigratedataperiodically

toanarchivetapepoolforlongtermretention.



30/40

Figure15:TSMArchivingtoTapewithaDataDomainRestorerforArchiveStaging

TSMarchivedatacanalsobearchiveddirecttotape,whichworkswellforlargeobject

archives(largefiles,databases,etc.).

TSMDatabase

Backups

TSMdatabasebackupsarecriticaltotherecoveryofaTSMserver. ATSMdatabase

backupcanbefullorincremental,andcapturesalltransactionscurrentlycommittedto

thedatabase.Databasebackupsareusuallywrittentotapeanditistypicalfortwofull

TSMdatabasebackupstobedoneeachday. Onebackupissentoffsitefordisaster

recoverypurposesandtheotheriskeptonsiteforoperationalrecovery.

AdrawbackofTSMbackuptotapeisthateachbackupmustbeonitsowntape. This

leadstoinefficientuseoftapecapacityespeciallywithtodayslargertapecapacities.

WithatypicalLTO3cartridgeholding1TB,a100GBTSMdatabasewillleave90%of

thetapeunutilized. Witha5daydatabaseretentionandtwobackupsaday,each

instanceofTSMwillhave10tapesthataresignificantlyunderutilizedforDBbackups.

WiththeintroductionofaDataDomainRestorertotheTSMenvironment,TSMDB

backupscanbewrittendirectlytotheDataDomainRestorer. WhenTSMdatabase

backupsaresenttotheDataDomainRestorer,storagespaceisnotwasted;thisistrue

whethertheDataDomainRestorerisusedinVTLmodeorsequentialaccessfilemode.

ADataDomainRestorerattheprimarysitecancutthenumberoftapesusedforTSM

databasebackupsinhalf. IfasecondDataDomainRestorerisintroducedatanalternate



31/40

site,theTSMdatabasecanbereplicatedusingtheDataDomainRestorer. Thissetup

willeliminatealloftheinefficientlyusedDBbackuptapes. Itwillalsoreducethe

amountofTSMservertimerequiredtowritetwoDBbackupsdaily,byleveragingthe

DataDomainRestorerdatareplicationfortheoffsitedatabasebackupcopy.

Figure16:TSMDatabaseBackupusingDataDomainRestorers

TSMDisasterRecovery

SeveralarchitecturalscenariosexploretheuseofaDataDomainRestorerasacentral

mechanismforvaultingTSMdatatoanalternatesiteforpurposesofdisasterrecovery.

AswithanyothermethodofperformingTSMdisasterrecoveryoperations,theTSM

database,configurationfiles,andstoragepoolsmustbeavailableforrecovery

operations.

Note:A

TSM

database

instance

can

only

recover

data

from

directly

associated

storagepools.StoragepoolsallocatedtootherTSMinstancescannotberecoveredto

asingleTSMserver.

We recommend the use of Tivoli Disaster Recovery Manager (DRM) to automate

TSM disaster recovery operations. The general sequence of events to recover a

TSM server instance includes the following steps.



32/40

Note: TostarttherecoverprocessyouwillneedanewserverrunningthesameOS

andpatchlevelastheproductionTSMserveranditwillneedtobeconnectedtothe

DataDomainRestorerattheDRsite.

1. InstalltheTSMserverCode

2. ConfiguretheTSMservertoseetheDataDomainRestorerfilesystems,they

mustbeconfiguredidenticaltothewaytheywereinproduction.

3. DefinetheTSMdatabaseandlogfilesystemstomatchwhatwasconfiguredin

production

4. Formatthedatabaseandlogvolumes

5.Usedsmservrestoredb torestorethedatabase

6.Register TSM server licensing

7.Inventory required media for storage pools (only if physical tape is

managedby TSM)

8.Resume

backup

and

restore

operations

in

alternate

backup

environment



33/40

ArchitecturalScenarios

LocalDataDomainPrimaryStoragewithManualTapeVaulting

Inthescenarioillustratedinthefollowingfigure,aDataDomainRestorerinstanceis

usedtoreplacetraditionalTSMdiskandtapeprimarystoragepools.

Figure

16:

Local

Data

Domain

Restorer

Primary

Storage

with

Manual

Tape

Vaulting

Atapelibraryisusedtocreatephysicaltapesforcopystoragepoolsandthetapesare

manuallytransportedoffsiteviacourier.DuetotheuseofaDataDomainRestoreras

theprimarystoragepoolforbackups,themigrationstephasbeenremovedfromthe

dailybatchprocessingtasks,shorteningthedailyoperationalworkload.



34/40

LocalDataDomainPrimaryStoragewithElectronicTapeVaulting

Inthescenarioillustratedinthefollowingfigure,aDataDomainRestorerinstanceis

usedtoreplacetraditionalTSMdiskandtapeprimarystoragepools. Atapelibraryis

accessibleviaextendedSANatthealternatesite,andisusedfordailyelectronictape

vaulting.

Figure17: LocalDataDomainRestorerPrimaryStoragewithElectronicTapeVaulting

Again,themigrationrequirementhasbeenremovedfromthedailybatchprocessing

tasks,shorteningthedailyoperationalworkload.Thisscenariobenefitssiteswith

existingelectronicvaultingandoffsitetapeinfrastructureinplace.

Note:AllcompressionanddeduplicationbenefitsachievedontheDataDomain

Restorerarenotrealizedontapecopy,sincealltapecopyoperationsareperformed

attheTSMapplicationlevel.



35/40

LocalDataDomainPrimaryStoragewithDataDomainRestorerReplicationto

AlternateSite

Inthescenarioillustratedinthefollowingfigure,physicaltapeiseliminatedbyusinga

DataDomainRestorerattheprimarydatacentertoholdtheprimarystoragepools.

AnotherDataDomainRestorerisplacedatthealternatedatacenteranddatais

replicatedbetweendatacentersusingtheDataDomainRestorerreplication. Theuseof

theDataDomainRestorerreplicationreducedthenetworkbandwidthneededfor

electronicvaultingofdata.

Figure18:LocalDataDomainRestorerPrimaryStoragewithReplicationtoOffsiteDataDomainRestorer

ByutilizingtheDataDomainRestorerdevicesatboththeprimaryandalternatedata

center,thedailyoperationaltasksforbackupstoragepoolsarereduced.



36/40

MixedProduction/DRwithDataDomainRestorerReplication

Inthescenarioillustratedinthefollowingfigure,multipleTSMproductioninstances

electronicallyvaultdatatotheDataDomainRestorersattheoppositesite.

Figure19:MixedTSMProduction/DRwiththeDataDomainRestorerReplication

Eachdatacentersupportsamixtureofproductionanddisasterrecoverycapacity,and

eachTSMproductioninstancevaultsdatatothealternatesiteusingtheDataDomain

Restorerreplication.



37/40

CentralDisasterRecoveryDataCenterConfiguration

Inthescenarioillustratedinthefollowingfigure,acentralizedDRsitesupportsmultiple

productiondatacenters,byreplicatingTSMbackupdatatotheDRsiteviatheData

DomainRestorerreplication.

Figure20:CentralDisasterRecoveryDataCenterConfiguration



38/40

RemoteOfficeLocalandDisasterRecoveryConfiguration

Inthescenarioillustratedinthefollowingfigure,acentralizedDRsitesupportsmultiple

remotesites,whichreplicateTSMbackupdatatoasingleDataDomainRestorer

instancetheDRsiteusingtheDataDomainRestorerreplication.

Figure21:RemoteOfficeLocalandDisasterRecoveryConfiguration

Conclusion

DataDomainarchitectureoffersavarietyofnewstoragearchitecturestrategiesforTSM

customers.TheTSMapplicationfunctionsasiswiththeDataDomainRestorer

interfacemethods,minusthecomplexitiesandmanagementoverheadassociatedwith

physicaltapemedia.Fortheenterprise,disasterrecoveryreplicationofTSMdatahas

traditionallyrequiredsignificantarchitecturalmeasuresandmanagementoverhead.

DataDomain

architecture

provides

a

viable

offsite

replication

alternative,

which

is

coupledwithareductionindailyTSMbatchoperationalprocesses.

WeseeaparticularlycompellingcasefortheDataDomainRestorertorevolutionizethe

waysmallandremoteTSMsitesmanagephysicalstorageresourcesandreplicationfor

disasterrecovery.ForextremelylargeTSMinstances,appropriateplanning,sizing,and

integrationstrategiesmaketheDataDomainRestoreraviablesolutionforthe

enterprise.



39/40

AboutGlassHouseTechnologies,Inc.

GlassHouseTechnologiesistheindustrysleadingindependentconsultingfirmwith

provenexperiencetransformingITinfrastructure. GlassHousesproprietary

methodologyalignsbusinessprocessesandinformationtechnologysystems,

transformingourclientsexistinginfrastructureintoscalable,compliant,costefficient

andtightlyorganizedenvironments. GlassHouseconsultantsarchitect,implementand

operateITenvironmentstodrivehighperformanceandagility.GlassHouseclients

include,Allianz,MorganStanley,AetnaandWellsFargo.



40/40

glasshouse tsm datadomain whitepaper

Documents