Understanding Azure and SQL Server

By Terry Engelstad

AIS Network VP, Network Operations

 

For those of you who are considering using Microsoft Azure, you should know that Azure does not sell virtual machines with SQL Server installed.  They sell SQL Server databases which are carved out of much large SQL Server Server.

Recently, a colleague asked me about SQL. If we sold someone a self service HyperV private cloud, and they spun up a SQL instance, how would that be licensed?  He asked, “They wouldn’t be on the hook for a one month SPLA license for using it for an hour, would they?”

Here’s the way to look at SQL Server.

If SQL Server is installed on a server (physical or virtual, doesn’t matter), there are executables which get installed in the Programs directory.  One of those programs is sqlsrvr.exe.  And wherever sqlsrvr.exe runs, then it needs to be licensed for the server on which it is running.

This is why you need to license only one SQL Server in an active/passive cluster.  Sqlsrvr.exe does not run on the passive node until the primary node fails.

That question about “spun up a SQL instance” needs a technical explanation.

You can “spin up an instance” on a server which is running sqlsrvr.exe or you can request to have an instance spun up on another server and be given permission to access it.  In the former scenario, you would need a license.  In the latter scenario, you would not be running sqlsrvr.exe, therefore you would not need to license it under SPLA.  The SPLA license would cover the server which is running sqlsrvr.exe.

It’s just like a mail server.  We license the running imail.exe on the mail server.  Then you can dole out mailboxes and charge a set amount for a mailbox.  Or it’s just like our Shared SQL Server in Ashburn.  We have a single server which is running SQL Server.  Our Shared SharePoint server accesses an instance on it.  And so does Client 1.  And so do Clients 2, 3, 4 and 5.  We’re only paying for the license on the Shared SQL Server, not the usage by anybody else who has instances defined.

I have Clients 1-5 set up so they can use what are called “connection strings” for connection to the SQL Server.  These connection strings include an IP address of the SQL Server, an instance name, a user account, and a password.  That’s what they use to get to their respective (and only their respective) databases.

That’s the same way Azure does it.  When you ask for a database, they give you an address, an instance name, a user name and a password.  You can then access your Azure database.  This way, nobody needs to pay the huge licensing fees.  Now.  Clear as mud?

Go ahead and write me with your questions on this one.

 

Leave a Comment