Running App Volumes with a SQL Always On Cluster

One of my customers has been deploying App Volumes, using their SQL Always On availability group for the database.  They pointed at the listener and everything looked good... until they initiated a failover.  Fortunately, the fix was really simple, although two part.

First, we noticed that the ODBC connections were using the default "SQL Server" driver.  That immediately stood out to us as a problem, as that driver can't handle AO failovers (exactly what we saw).  So, we switched it over to the Microsoft ODBC Driver 13 for SQL Server driver and figured that we'd be good to go.  Almost.

When we attempted to connect to the App Volumes Manager, we received a DB access error.  We saw that it was using the correct driver (yay!), but it was getting a credentials error because it was trying to use the server's computer account.  Some quick google searching pointed me at an article about changing database credentials in App Volumes, but that was for a fairly old version of App Volumes and we found that the database.yml file didn't even specify the local computer account.  So, we figured that that procedure was probably not going to work for us.  Fortunately, the solution proved even easier.

We just changed the App Volumes service to run as the AD Service Account that had SQL Database permissions.  We then restarted the service and everything went great.  Finally, we initiated a failover and watched as everything kept on trucking.

Comments

Popular posts from this blog

Deleting Orphaned (AKA Zombie) VMDK Files

Clone a Standard vSwitch from one ESXi Host to Another

Orphaned VMDK Files