The Snapshot removal and connection loss issue is not really relevant to the number of VMDK's in place: it's solely the time required to stun the VM for Snapshot creation/removal time, how busy the storage is and how much data needs to be processed. If you see the slow processing times, it's very unlikely due to the number of disks you process, but rather the limitations in place: Since you're using proxy to process all VMDK's, the processing time should really be in parallel: up to 15 disks mounted to each controller.
I'd really appreciate some input on this! Wouldn't it then be "better" to have a less complex setup like this?Ĭ:\ - OS & SQL program files (sized big enough to hold the temporary transaction logs before they are copied off) Plus we've had some problems with this setup (Veeam causing VSS errors -> causing cluster failovers, servers unreachable because of snapshot delete stuns). I understand that Derek uses multiple HDDs attached to different SCSI controllers for better performance, but in our case, performance is not an issue (and extremely unlikely to ever be) - powerfull hardware, low IOPS/TPS.īut now that we have Veeam, i see that it takes quite some time for the backup to map all those drives to the backup proxy for processing, and i'm not sure if this setup even makes a lot of sense. This guide results in 2 VM cluster, each with a lot of harddisks I'm looking for advice on how to design the Storage layout of SQL Server VMs (2014 with AlwaysOn Availability Groups) regarding best performance/operability with Veeam.īasically, we followed Derek Seaman's blog/walktrough.
0 kommentar(er)
