Recommended number of max concurrent backups per iSCSI LUN?

[ShawnKPERS]

I know this probably is a “it depends” on… SAN, Host, OS, the direction the wind is blowing at this moment kind of thing but I figured I would ask just in case there is a good general rule.

That way I know how large or small I need to break up my Nimble iSCSI repository LUNs. When I break up my LUNs would prefer to do it based off job organization and not have to worry about saturating the number of theoretical connections the LUN has access to. I assume I will max out the throughput of the SAN before I have to worry about the number of connections but figured I would ask.

[foggy]

I'd check with your SAN vendor for their recommendations and use repository tasks limit to meet them, if required.

[dellock6]

More than cuncurrent backups, I'd look at cuncurrent snapshots open on the same datastore, mainly because, regardless the lower performance created by VMs running over snapshot, multiple open snapshot means more space consumption on the same datastore, and more IO needed to consolidate them. For this reason we have a default limit of 4 open snapshot per datastore. Depending on the performance of your environment, you may decide to increase this value using a dedicated registry key.

[foggy]

I assumed Shawn was talking about target storage, in case it was source, limiting the number of concurrent snapshots seems more reasonable, indeed.

[ShawnKPERS]

Funny thing is I am currently testing some new repository storage combined with moving over to per-VM backup jobs\Scale-Out storage clusters backup jobs and ran into the hidden 4 concurrent snapshots per datastore limit and changed it in registry to double since I have so far not maxed out my source yet according the backup job bottleneck report.

[dellock6]

Funny thing I described the solution before you hit the issue

[Gostev]

As someone who actually added this limitation, I just wanted to note that this value was not meant to protect from maxxing out source storage load, but rather from other things. Primarily to prevent overfilling the source datastore by too many concurrently open snapshots all eating the remaining free disk space, plus a bunch of lesser VMware and VMFS specific performance considerations around having too many open snapshots on the same datastore.