10-08-2015 05:26 AM
10-08-2015 05:38 AM
MSDP pool uses 1 volume only.
You cannot create an MSDP pool across multiple volumes/luns.
If hardware array is used with striping/Raid across 5 disks, the OS and NBU has no knowledge of this.
The OS and NBU will see 1 volume only.
10-08-2015 06:24 AM
10-08-2015 06:36 AM
I think the docs and explaining of that option is highly ambiguous
Netbackup doen't know how many LUNs or disk is used for a given storage unit. The value is the maximum number of concurrent read or write stream the storage unit should handle.
In your case 100 and not 20.
10-08-2015 06:41 AM
10-08-2015 06:49 AM
Yes - in other words - Netbackup see a file system. Not how its made
10-08-2015 07:01 AM
10-08-2015 07:11 AM
10-09-2015 09:31 AM
No matter how the disk storage is comprised - the max achievable sustained IO levels under load... all depend upon so many different factors. It is perhaps easier to baseline, benchmark and monitor IO levels on de-dupe storage that is private to a NetBackup Media Server - but even then one needs to grasp all of the abstraction layers all the way from OSI level 1 (physical/electrical) up to the application layer. Not easy. One has to understand all of the IO abstractions at each layer - i.e. IO in and IO out - it comes from somewhere and goes to somewhere, in some form. Needless to say, this is much much harder if a shared storage platform, or a shared storage network, is being used. I think this demonstrates why no-one can ever give a hard and fast number.
Consider this... the IO packet sizes are different as the data moves up and back down through the layers, each time being chopped up and/or transformed in some way:
spindles -> disk blocks -> volume-manager/file-system -> bpbkar -> TCP -> bptm -> bpdm -> de-dupe/OST -> file-system/volume-manager -> LUN/SCSI/iSCSI -> SAS/FC/TCP -> RAID -> stripe -> spindles -> disk blocks
Finally, the efficiency, performance and reponsiveness of de-dupe is also utterly dependent upon the nature of the data being backed-up - which only you have visibility of.
In a nut-shell, it could be construed as mis-leading if any of us were to give you any hard and fast guidelines. So, the usual advice will have to suffice... i.e. initially be conservative, establish several metrics that you can measure... and slowly increase the max allowed job counts... and try to identify the peformance cliff, i.e. the point at which either one or more of "performance or efficiency or responsiveness or capacity or throughput" takes a nose dive.