6:00 AM
Paul B
At my day job that shall not be named, we ran into a very interesting issue over the last month and a half or so. You see, we run our production environment in Microsoft Azure, and the way we've configured our Microsoft SQL database cluster is by following this Always On Setup in Azure.
On top of that, for performance in Azure, we are using Microsoft Storage Spaces. If you aren't familiar with Storage Spaces, you basically take a number of physical disks (They are actually virtual disks in Azure) and pool them together so you are striping data across them. This increases your IO, and thus increases your performance. It's pretty slick!
 |
| Typical Storage Spaces/Storage Pool Setup |
I digress...
Anyway, we wanted to add a new pool to both of our servers, so naturally we added the virtual disks in the VM, then created our pool in Microsoft Storage Spaces, and created our virtual drives on top. Simple right?
Well it was simple until we used Azure Site Recovery (ASR) to replicate these new disks to our DR zone in the East US region. When we did our test failover, and powered up our servers in the East US region, we noticed that the servers showed our virtual disks as being detached. WTF is that all about?!?!
Well after going back and forth with Azure tech support for weeks, my Systems Engineer finally figured out a fix by running a PowerShell command.
The command he ran was:
Get-VirtualDisk | Where-Object -FilterScript {$_.IsManualAttach -eq "True"} | Set-VirtualDisk -IsManualAttach $False
After running this on the production nodes from an elevated PowerShell, we no longer had the issue of the virtual disks replicating in a detached state when we initiated ASR test failovers!
Now why did Windows mark these new virtual disks to be manually attached in the first place? We still don't know that, but if you run into this issue yourselves at least you know how to fix it.
