So we have a few database VMs that have RDMs mapped to them, specifically for SQL Maintenance Plan Backup Jobs.

These ran Full and Inc backups, and kept 3 weeks worth before deleting the oldest set. Pretty standard stuff. It was decided to cull this down to 2 weeks worth. After doing this, this freed up a lot of additional space…..but being an RDM in a Windows VM, the space showed as free in Windows but the Compellent didn’t show this as free! So the savings weren’t replicated on the SAN, the key is that the savings would stay pretty consistent too, as if  it was going to grow again in a short period of time…..there would be no point in worrying about it!

There are 2 ways to address this:

  1. Dell address it by providing you with a Windows Enterprise Server Agent, and its job is to connect to the Compellent Data Collector to report changes in space usage, so it can be reported on the SAN.
  2. Create a new RDM and copy the data over to the new RDM and bin off the old one.

After discussing this with the higher ups, it was decided to go with  2. Why you may ask? They didn’t want to give the VMs an additional vNIC into the storage network so it could speak to the Dell Compellent Data Collector and also the Data Collector is temperamental and half the time it needs a reboot its self just to keep it working.

So I had a few RDMs to do, I created them on the SAN and mapped them to the whole cluster. I added them as additional disks to the VMs and then did a rescan in the Windows Disk Manger.

Once that was done I ran robocopy (it comes with 2008 and is an add-on for 2003). It copies everything from one location to another and maintains all dates/times/permissions.

Run as administrator from the command prompt:

robocopy B: F: /E  /COPYALL /DCOPY:T /R:5 /W:30 /LOG:C:\RESULTS.TXT

B: = The source drive (in my case the old RDM with backups)
F: = the destination drive (in my case the new blank RDM)
E = Everything including sub-folders and empty folders
COPYALL = copies everything inclduing security permissions and dates/times
DCOPY:T = keeps original time stamps of the folders etc
R = number of retries
W = wait between retries in seconds
LOG = text log file to see how its going

If you don’t set R or W it will keep retrying forever and having a log is good, because if it gets stuck for some reason you can see exactly what file caused the issue and then go sort it.

So anyway I did that for the first RDM transfer and it was taking its time (2.5TB of data!), then one of the SQL guys made a very valid point…and I wish I had thought of it.

Why not set the new drive as the backup location and give the other drive a different drive letter. SQL will start backing up to the new drive and after two weeks the data on the old RDM can just be deleted and no hassle! If the old data is needed before then it’s still there just on another drive in Windows.

So I did that and after a couple of weeks, I will come back and delete the old RDMs.

Interestingly Windows Server 2012 supports SCSI UNMAP commands, so no agents are needed as it is able to speak directly to the SAN and sort itself out. So the future is looking better!

From the Dell Windows 2012 Best Practice Guide:

“Windows Server 2012/R2 automatically identifies thin provisioned LUNs and will reclaim unused space (aka Trim) in real time. When files and folders are moved or deleted from a volume, Trim automatically reclaims that space on the SAN. Thin provisioning and Trim are enabled by default in Windows Server 2012/R2.”

Comments are closed.

Post Navigation