How does 2012R2 CSV 2.0 handle backups?

Hello,

Just wondering how backups should work with a failover cluster running on 2012R2. From what I have read Direct I/O should be used in 2012R2 when running a virtual machine backups instead of redirected access in 2008. I am expecting that when a backup is taken that the VM backed up will access the data from its local ISCSI connection no matter which node the CSV is owned by.

What I am seeing is that if the VM and CSV are on different nodes the disk access is run over the management network connection from the CSV iSCSI owner to the VM owner and then sent to the backup server. This causes a reduced backup speed. The CSV stays in online mode and running Get-ClusterSharedVolumeState shows all volumes in direct access still. We have no 3<sup>rd</sup> party hardware VSS providers and this is happening on 2 separate clusters.

What I am trying to figure out is this how it is supposed to work or not? Is anyone able to help me with this? I have spoken to Symantec who now say it is a Microsoft issue but have not confirm this is expected or not.

August 27th, 2015 11:01am

Hi,


I am trying to involve someone more familiar with this issue. There might be some time delay. Appreciate your patience.


Thanks for your understanding and support.

Free Windows Admin Tool Kit Click here and download it now
August 31st, 2015 10:41pm

Hi MartinA895,

Yes, you are correct, direct I/O has been enabled since 2012.

Image a scenario: when we add data into the VM, CSV I/O synchronization is direct, thats to say, VM will access storage directly.

However, regarding running VM backups, it will contain metadata update, synchronization is only done on one node (the coordinator node), and metadata changes for all nodes are routed through that coordinator node. Below screenshot and document for your reference.

Introduction to Cluster Shared Volumes and CSV Architecture:

http://download.microsoft.com/download/6/1/0/610CC4C3-4A29-4D4B-AD00-9342276C5085/Module%203%20-%20Introduction%20to%20Cluster%20Shared%20Volumes%20and%20CSV%20Architecture.pdf

Whats more, if you consider your cluster backup speed is slow and needs to be optimized, some tuning regarding cluster network might be useful for you, please refer to the below website.

Configuring Windows Failover Cluster Networks

http://blogs.technet.com/b/askcore/archive/2014/02/20/configuring-windows-failover-cluster-networks.aspx

Other CSV related knowledge also for your reference.

Cluster Shared Volume (CSV) Inside Out

http://blogs.msdn.com/b/clustering/archive/2013/12/02/10473247.aspx

Best Regards,

September 3rd, 2015 5:25am

Thanks for your reply,

So backups are classed as metadata so all I/O is routed over the SMB path (Which is what we are seeing) to the coordinator node and backups are not classed as regular read write I/O even though from the article it doesn't mention backups are using metadata

Metadata updates are lightweight/small operations and only occur in specific situations, including:
 Creating/deleting VMs.
 Turning VMs on/off.
 Moving VMs (Live Migration or Storage Live Migration).
 Creating snapshots.
 Extending a dynamic virtual hard disk (VHD).
 Renaming a VHD.

I am taking that this is how it is supposed to work and the Direct I/O feature doesn't really benefit backups in the way that I thought it would other that the whole CSV doesn't go into redirected mode only the backup data gets redirected. Am I understanding this is this correctly?


Free Windows Admin Tool Kit Click here and download it now
September 3rd, 2015 8:30am

Hi MartinA895,

Yes, your understanding is correct, what you have seen was the expected behavior, and this is by design.

As we can see from the document, metadata updates will occur when creating snapshots, as you know, backup operation will contain snapshot creation, thats to say, the metadata updates will occur every time when we perform backups. And thiss why we saw all I/O is routed over SMB to the coordinator nodes, while not via direct I/O, thank you for your understanding.

Best Regards,

September 3rd, 2015 10:30pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics