For a few weeks now Failover Clustered Instances in the Microsoft Azure cloud have been possible by using SIOS DataKeeper Cluster Edition to cluster the VMs together and get yourself shared storage. This has actually been possible for a while, you just needed to know how to do it. Now it’s a fully Azure Certified configuration and VMs with SIOS DataKeeper preinstalled are even available from the Azure Marketplace.

Now when setting up clustering in Azure you need to be sure to follow the various scripts which are out there so that you can setup what’s called the Internal Load Balancer (the ILB) within Azure. The scripts which I like the most are by Dave Bermingham’s and can be found on his blog.

Now when you get down to the “Create an Internal Load Balancer” pay special attention to some of the settings in the Get-AzureVM lines as some of these values are going to determine how quickly the ILB sees that the SQL Instance has moved from one VM to another. Under the default settings shown in Dave’s blog post (don’t blame him, these are the same scripts that you’ll find on MSDB I just like how Dave presents them better) you’ll see that the ProbeIntervalInSeconds parameter is set for 10 seconds which means that the ILB will only check which VM the clustered IP address is running on every 10 seconds. Now by default the ILB must fail twice before it will move the connections to the new VM. This means that the cluster will be down for an additional ~20 seconds between when SQL comes up on the new cluster node and when connections to it will successfully connect.

You can adjust this value to reduce this time by reducing the ProbeIntervalInSeconds parameter to a lower number. The lowest supported value is 5 seconds which would reduce the outage from ~20 seconds to about ~10 seconds or so. Which is definitely something which I would recommend as we want to keep the downtime window as short as possible as the whole reason for Clustered SQL Instances is the most availability possible.

Recently this question came up with a client that I’ve been working with. In this case the problem was that disk space alarms were going off for the disk which held the database backups. The proposed solution was to change the log backup retention from 24 hours to 16 hours.

The problem with this solution, which I pointed out is that from 5pm until midnight you now have no way to do any log restore operations which means that you’ve lost your point in time restore capabilities.

Log and full backups shouldn’t be deleted from the disk until the full backup from the next cycle of backups has been completed. This way you are sure that you’ve always got a full backup to restore from. In a perfect world I’d like to see 2-3 days worth of full and t-log backups kept on disk so that if there is ever a problem with a corrupt database backup you can restore from the prior full backup and then roll two cycles of t-log backups forward.

So recently I got myself a Surface Pro 3 with the i7 processor in it as my laptop. It works great, except for one little power issue that I’ve noticed. The i7 Surface Pro 3 uses a LOT of power when it’s plugged in. In fact it uses almost all the power that the power cable can provide. I know this because if you plug your phone into the USB port on the power brick your phone won’t charge.

When I had my phone (a Samsung S5) plugged in the phone kept showing that it was charging then not charging, then charging then not charging, over and over until I unplugged it.

Now I know this is a problem with the i7 Surface because my wife has the i5 and the same phone and can charge her phone with the Surface plugged in without issue.

Now truth be told I haven’t played with the power settings in Windows to see if that makes it go away, I simply plugged the phone into the USB port on the monitor and was done with it. So there might be a way to slow down it’s charging so that you can charge a phone via the chargers USB port. At some point I’ll probably figure out if that’s an option.

Yep, that’s right. I’ll be speaking at the Microsoft Ignite conference. This year Microsoft has made the poor decision of allowing me to speak at their conference on High Availability and Disaster Recovery for Microsoft SQL Server both on prep (in your data center) and in Azure (in their data center). It’ll be a fun session with some demos, some stories and of course we’ll be going through what your HA/DR options with Microsoft SQL Server will be.

I’m thrilled that Microsoft has chosen me to talk about their product at what is going to be their biggest corporate conference in recent years. I’m really looking forward to seeing some old friends, and making some new ones. If you are at Ignite come to the SQL Server booth (sometimes called Data Platform) and say hi (I’ll probably be there a lot of the time when I’m not presenting) or come to my session (not sure when or where it is yet) and check out my presentation and say hello afterwards.

You can see the sessions that I’ll be presenting on my bio page. Hopefully I’ll see you at Ignite, and if not you’ll (probably) be able to watch the recordings of the sessions pretty quickly after they are presented (I’m assuming that they will be recording them just like they did at TechEd).

The most important thing to read today is the New York times notice of Mr. Leonard Nimoy passing. Today (just an hour or so ago) it was announced that we lost a fantastic actor, musician, poet, director, writer, and all around great guy. Live long and prosper Mr. Nimoy. My condolences go out to his family, friends, co-stars, etc. Leonard Nimoy will truly be missed.

In the IT world, I’ve found some great things for you to read. These are a few of my favorites that I’ve found this week.

Demo’s fail. If you don’t bribe the demo gods well enough things will come crashing down on you. How you handle and recovery from your demo fail shows just how good of a presenter you are.

My biggest demo fail was a few years ago now. Let me set the stage for you. It’s TechEd North America in Atlanta, GA. It’s my first time presenting at TechEd, ever. I get to my room 20 minutes before my session, get up on stage (TechEd has 30 minute breaks or longer between sessions) and fire up my laptop. You see I’ve got 5 VMs that I need to be able to run to make my demo happen. So I fire everything up, get logged into all the VMs, and I’ve got plenty of time left.

I plug in the audio feed to the sound system and fire up some music and tell the room monitors to start letting people in. People start to file in. The room holds probably 400 people and ends up about 1/2 full. A couple of friends have come to sit in the front row so we’re chatting (with the mic turned off). About two minutes to go before my session there’s a loud thud and the screens go dark, and I can see that the room is no longer bathed in the colorful glow of the projectors. The entire room now has a blue tint to it, while my music is still playing.

I head back over to my laptop and see that yep, it’s blue screened. The audience starts to give the congrats your machine blew up applause.

I quickly reboot my machine and get the slide deck back up on the screen while booting up my VMs while giving the talk.

Everyone in the room knew exactly how badly screwed I was, but by the time I got to the demo portion of the session the VMs were up and logged in, and the demos worked exactly as expected. Thankfully the laptop didn’t blue screen again during the entire time.

The lesson here is that these things happen. All you can do it recover, roll with it, and pray that you can get through it gracefully. It doesn’t matter how much you prepare, things happen. Apparently I did OK, as I presented at the next 3 TechEd North America and the next three TechEd Europe events.