As public cloud platforms such as Microsoft Azure mature it is becoming easier to build deployment architectures that are substantially resilient to faults in cloud platforms that are increasingly unlikely to ever eventuate due to the previously mentioned maturity!
We’ll take a look at how we can deploy an ultra highly available database-backed ASP.Net MVC Website using Microsoft Azure across this post and my next one.
Desired State
The diagram below shows what we will be aiming to achieve with our setup.
This setup can best be summarised as:
- Two Azure SQL Database Servers in two Regions utilising Active Geo-replication to provide a read-only replica in a secondary Azure Region.
- Cloud Services in each Region containing dual Web Roles in an Availability Set. Web Roles are configured to communicate with the Azure SQL Database in their Region. The Primary Region will be read/write and the Secondary read-only.
- A Traffic Manager instance deployed using the two Regional Cloud Services as Endpoints, using a Failover configuration.
Locally AND Geographically Redundant
If you don’t have a deep familiarity with how Azure Cloud Services and Azure SQL Database work then you may not realise the level of local (intra-Region) resiliency you get “out of the box” when you sign up. Here’s a summary based on the setup we are deploying:
- Cloud Services with two instances will take advantage of Fault and Upgrade Domains to ensure that at least one Instance remains operational at all times (this is required to qualify for Azure Availability SLAs too).
- Azure SQL Database runs three local replicas concurrently – one primary and two secondaries ensuring that intra-Region hardware failures are less likely to impact you.
Now this is probably more than sufficient for most businesses. In the years that I’ve worked in the public cloud space I’ve never seen an entire Region in any provider go completely dark. While it is highly unlikely to ever occur this is not the same as saying it won’t ever occur (hence this post!)
Costs
A word to the wise: these setups don’t come cheap (example: Azure SQL Database Premium P3 ~AUD4,267.49/mo in AU East). This should be expected given the level of redundancy and service availability you get. Having said this, in comparison with having to build this setup out on-premises you’d be hard pushed to beat the price points (and flexibility) you’ll get from a cloud deployment like this one.
Sample Code
In order to wrap your head around this post I’ve created a sample project hosted on Github that you can use to test out the design covered here. The project is a modified version of the sample MVC Music Store hosted on Codeplex. I had trouble convincing Codeplex to authenticate or register me, so consequently I’ve set this sample up on Github. We’ll cover code changes in more detail in the second part of this post.
Database Tier
We’re going to start at the database tier as we’ll require configuration information from our database deployment in order to successfully deploy our web tier. The MVC Music Store sample application requires us to deploy two databases: the core data model supporting the MVC Music Store product catalogue and shipping; and the standard ASP.Net SQL Membership and Role Provider database.
The ASP.Net databases can be deployed using aspnet_regsql.exe (if you have problems running it with Azure SQL Database check out this Connect item for help) but I’m going to use some SQL scripts from the mentioned Connect item so that I can manage creation of the database.
The MVC Music Store sample application can also be allowed to initialise its own database using the following snippet:
[code language=”csharp”]
protected void Application_Start()
{
System.Data.Entity.Database.SetInitializer(
new MvcMusicStore.Models.SampleData()
);
}
[/code]
but in my case I want to control how and where the database is created so I’m using the supplied SQL script and commenting out the above snippet in my solution.
Get the show on the road
Firstly we’re going to initialise our Azure SQL Database Servers, Databases and geo-replication. Now we could do this via the standard Azure Management Portal but it’s much easier (and repeatable) if we use PowerShell.
The basic approach is:
- Setup Database Server in Primary Region (in our case Australia East) and open up the Firewall as required.
- Setup Database Server in Secondary Region (in our case Australia Southeast) and open up the Firewall on it as well.
- Create empty databases for the MVC store and ASP.Net Membership and Role Providers on the Primary server.
- Enable geo-replication.
- Create schemas and data in databases on Primary Server using SQL Server DDL.
I’m a bit bummed as I was unable to do all this via PowerShell leveraging the Invoke-SqlCmd Cmdlet to run the DDL. It looks like there’s a known issue floating around that means the SqlPs and Azure PowerShell Modules have a bit of a spat over some shared code. Rather that get you to edit core PowerShell settings I’m just going to run the DDL using the Azure SQL Database console.
Once you’ve run the above script you’ll have your underlying SQL infrastructure ready to go. Now we need to build the schemas and populate with data. We’ll do this using the old Azure Management Portal so we can avoid having to install any SQL Server tooling locally if we don’t need to.
- Open up a browser and log into the Azure Management Portal and navigate to the SQL Server that is your Primary Server.
- On the SQL Databases page, Click ‘Servers’ and highlight your primary server by clicking on the line anywhere other then Server Name.
- Click ‘Manage’ in the footer. This will open the Silverlight-based admin console.
- Log into the server with the credentials you put into your PowerShell setup script.
- Select the empty database instance you want to run your DDL SQL Script in and then click ‘Open’ in the navigation bar (your screen should look something like the below sample).
- Repeat for both databases (MVC Music Store and ASP.Net).
The ASP.Net scripts can be found in the solution on Github. All you need to run is InstallCommon.Sql, InstallMembership.Sql and InstallRoles.Sql (in that order).
Once completed you have setup the foundation database tier for our sample application. The geo-replication will play out your DDL changes into the Secondary Region and you’re already in a good position now having your data in at least four different locations.
This completes the first post in this two post series. In our next post we will look at setting up the web tier.
Comments are closed.