vSAN Strech cluster and backup volume

[unsichtbare]

Howdy all!

I have a vSAN stretch cluster with present utilization of 43TB/125TB total capacity. vSAN reports total free space on disks of 87TB (across stretch cluster) with an effective free space of 27TB (based on Default Policy)

I would like to create a fast local backup volume (for Veeam) which would then use Backup Copy or Tape to offload older backups. My target is a 20TB volume.

My question is this: Am I best served using the vSAN Default Storage Policy (RAID 6 Erasure Coding) for the Veeam Volume or would I be better off creating a new Policy specifically for the Veeam volume, such as a RAID 5?

• Sub-question 1: I could create a Policy to use only on the non-production side of the stretch cluster - is there any point to this?

THX in advance!

[TheBobkin]

Hello unsichtbare​

"vSAN reports total free space on disks of 87TB (across stretch cluster) with an effective free space of 27TB (based on Default Policy)"

How many nodes in the cluster and exactly what are the rules (not the name) of the Storage Policy referenced in the capacity planner? The math makes sense of the "usable" space being for FTT=1 across sites and 25% slack space (which depending on your setup/preference may be too much/little).

"I would like to create a fast local backup volume (for Veeam) which would then use Backup Copy or Tape to offload older backups."

Are you planning on pulling the data off as you go/soon after? This is advised as you shouldn't store your backups on the thing it is backing up. If so then you want RAID1 for performance but then this could be argued as being okay for RAID5 if you only need the read part (while migrating to another datastore) to be fast.

"Am I best served using the vSAN Default Storage Policy (RAID 6 Erasure Coding) for the Veeam Volume or would I be better off creating a new Policy specifically for the Veeam volume, such as a RAID 5?"

RAID6 (assuming you mean FTM=RAID5/6,FTT=2) is not the 'vSAN Default Storage Policy' - that would be FTM=RAID1,FTT=1.

What Storage Policy fits the purpose here really depends on the needs/requirements, e.g. if it is being moved to another location right away does it even need FTT>0 ? (e.g. backups could be re-taken in the event of a failure)

Does it even need to just have one Storage Policy? e.g. you probably shouldn't go with just a single 20TB Object (less manageability) but a few smaller Objects that you could then even use different SPs on depending on the requirement/importance/size of the VMs/vmdks they are backing up.

If you have a large enough cluster to support it (e.g. optimally 5+5+1 or larger) then you also probably want to avoid the ISL in general and have any FTT just locally to sites for performance.

"Sub-question 1: I could create a Policy to use only on the non-production side of the stretch cluster - is there any point to this?"

Potentially yes, as per the above.

Bob

[unsichtbare]

Thanks for the advice Bob .

The Default Storage Policy (as configured on this instance/deployment of vSAN) is: 2 failures - RAID-6 (Erasure Coding). There are 12 total nodes - 6 Primary and 6 Failover. Each node has four 3TB (2.91TB) SSD Disks. I have 10Gb WAN and about 3ms. latency between the sites.

That being said, the goal of creating a Veeam volume would be reducing the backup/snapshot stun time for the first generation of backups. The full and incremental backups would then be transferred to a secondary (slower) backup device and/or offsite using backup copy job(s).

One of the reasons I was thinking about using the ability to specify only the Failover portion of the stretch cluster was specifically to provide a separation between the "active" volume and the resources where the backups reside. In most configurations, an asynchronous copy of a VM which is not stored at the production site is considered to be a valid part of a 3 -2 - 1 backup plan.