Friday, April 27, 2012

SQL Development and Testing magic, brought to you by NetApp

I started supporting and deploying NetApp storage systems about 5 months ago.  I still am *very* far from being an authority on the subject, but I have been playing around with the kit and am learning an immense amount daily.  That said, I never seize to be amazed at how trivially easy NetApp technology make traditionally time-consuming and difficult tasks.  Take the following situation:  You have a big old production SQL DB, and your developers need to test against an up-to-date instance of it.  I bet the tired old way that your business is doing it is by taking a 500GB backup, pushing it across the network, or sneaker-netting it via USB or even worse restoring from tape (blegh!).

No more.  With a NetApp SAN I can do this in exactly 23 seconds (and this on a low-end FAS2040!).  It costs me zero storage*** on my SAN and all it takes is you putting on your PowerShell hat and typing one single line.  The only assumption I make here is that you are running SnapManager for Microsoft SQL Server on your SQL box (and you should!).  This gives us access to all the PowerShell goodness that makes the magic happen.  The following command (watch for wrappage):  

clone-backup -svr prod-sql-001 -Database big_prod_db -TargetDatabase yourdatabase -TargetServerInstance dev-sql-001 Backup sqlsnap__big_prod_db__snapshots

  1. What is happening behind the scenes, you ask?  Quite simple actually:
  2. It created a FlexClone of the Snapshot of the production store
  3. Created a DB on dev-sql-001
  4. Mounted the FlexClone as a mountpoint
  5. Attached the files to the database
  6. Made toast and coffee

But that's not all.  This example brought our development box up to the same point in time as production, but you can also specify a previous a point in time to go back to.  Of course you need to have snapshots of your chosen point in time.


***It will start consuming space once you start making changes in dev, because you are diverging from the cloned snapshot.

Wednesday, April 11, 2012

Issues when upgrading to Veeam Backup & Replication v6

Let me start off by saying that Veeam Backup & Replication (VBR) is one of the most awesome pieces of software I know of!  As with any piece of software there might be the occasional bug or issue that needs to be worked around.  I’ve upgraded a couple of clients to VBR already, and I’ve consistently run into two little niggles.  These are:

Backup of vCenter SQL DB fails when using VBR v6

This is actually detailed on the Veeam forums here.

What it boils down to is that when using VBR for an application aware backup of the VM which hosts the vCenter SQL DB, the backup will fail with a VSSControl: Failed to freeze guest, wait timeout error.  This occurs because VBR has to communicate with vCenter to create a snapshot, but at the same time the vCenter SQL DB is frozen because of the VSS snapshot

To solve this problem, add the IP-address of the ESX host which runs the vCenter Server SQL database to the Veeam console (the servers list in the left panel). Then adjust the job and select the virtual machine with the SQL database from the ESX host instead of via the vCenter Server. Veeam B&R will then use the host for communication with the VM to do the VSS snapshot.

This will, of course, cause your replication job to fail should the vCenter VM move to another host.  We can work around this by using DRS Host Affinity rules to tie your vCenter VM to a physical box.

Replication job fails – cannot connect to port 2500

When VBR does a replication job, it might fail with “Creating snapshot Cannot connect to server [x.x.x.x:2500]”

In my case it was always happening when the destination server was running ESX (not ESXi) v4.x.  This is easily resolved by logging onto the target server via SSH and issuing the following commands:

  1. esxcfg-firewall -openport 2500:2510,tcp,in,VeeamSCP
  2. service mgmt-vmware restart

Easy enough!