Comprehensive data protection for all workloads
Post Reply
Hammy
Influencer
Posts: 19
Liked: never
Joined: Jan 01, 2006 1:01 am
Contact:

I/O frozen for 8 secs for VSS to SQL

Post by Hammy » Jun 14, 2011 12:29 pm

Hello all, I am running the latest version of VEEAM against a number of VM Guests, the jobs are configured against the LUNs to ensure only one job is going against any one LUN at a time. As I have also got a time delay between the various jobs I also currently only have one stream running at anytime as time taken to complete is very good. Not sure if this info is of any use however my DBA has raised a concern where he is getting an I/O freeze of 8 secs against the different database servers that are being backed up. Can anyone shed any light on whether this would be the expected norm or should I be looking at any setup issues. Right now the database servers are under a very low load as they have not gone fully operational yet.

Any advice welcomed.

regards

H

tsightler
VP, Product Management
Posts: 5304
Liked: 2159 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: I/O frozen for 8 secs for VSS to SQL

Post by tsightler » Jun 14, 2011 3:47 pm 2 people like this post

I would have to say that this is unfortunately "normal" for Veeam VSS. In our case the freeze is around 10 seconds. This is longer than with some other backup solutions because Veeam has to coordinate taking a VMware snapshot after the SQL I/O is frozen. The procedure is basically as follows:

1. Veeam pushes VSS agent to Windows VM
2. Veeam VSS agent initiates VSS freeze on various Windows components
3. Once VSS I/O freeze is in place Veeam VSS communicates to Veeam server that freeze has started
4. Veeam server communicates with vCenter (or ESX/ESXi host directly) to initiate VMware snapshot of VM
5. Once VMware snapshot tasks completes (this alone usually takes 3-5 seconds) Veeam server tells Veeam agent snapshot is complete
6. Veeam VSS agent tells VSS components to "thaw" and resume I/O

As you can see, that's a lot to coordinate, with a large percentage of the time being in the Veeam->vCenter communication and waiting for the VMware snapshot to complete.

Now, from an application perspective, this pretty much means that a query running at that exact moment would potentially take 8 seconds longer than normal. Most application will survive this level of delay, but this might be important for very time critical applications. The only other option is to basically do without Veeam VSS and rely on native SQL tools to dump the database, perhaps using a pre-freeze script to trigger the backup. You basically have to decide if that level of delay is acceptable in your environment or not.

Vitaliy S.
Product Manager
Posts: 22431
Liked: 1442 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: I/O frozen for 8 secs for VSS to SQL

Post by Vitaliy S. » Jun 14, 2011 5:18 pm

Hammy, could you please clarify what "freeze" are we talking about? Does it happen during snapshot creation or removal procedures?

tsightler
VP, Product Management
Posts: 5304
Liked: 2159 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: I/O frozen for 8 secs for VSS to SQL

Post by tsightler » Jun 14, 2011 5:32 pm

That's a good question. I guess I assumed, since he was being so specific about the length of the freeze, that we was referring to the messages in the Windows Application log regarding the I/O being frozen during VSS freeze.

Hammy
Influencer
Posts: 19
Liked: never
Joined: Jan 01, 2006 1:01 am
Contact:

Re: I/O frozen for 8 secs for VSS to SQL

Post by Hammy » Jun 15, 2011 8:07 am

To clarify yes the time stated is based on the Windows Event Logs. VSS writes an event when the freeze starts and subsequently writes an event when the freeze has finished for each of the databases within the instance. For the example I am using here the time between freeze occurring to it being un-frozen (excuse bad grammar) is 8 secs.

Tom thank you very much for the info, I will send this to our DBA and we can make a decision on whether to monitor this as the backups run outside busy hours so I would hope it would not affect any ops but time will tell.

H

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 18 guests