Getting Started With SQL Azure series:

1. What is SQL Azure? 2. Creating First SQL Azure Database 3. Provisioning and Billing Model 4. SQL Azure Architecture 5. SQL Azure's security model 6. Migrating Databases to SQL Azure 7. Administration Tasks - I 8. Administration Tasks - II 9. Developing SQL Azure applications 10A. Getting started with SQL Azure reporting and SQL Azure Data SYNC 10B Conclusion

Now in this article, we are going to discuss the SQL Azure Architecture and see what happens inside SQL Azure.

SQL Azure Architecture:

SQL Azure architecture has a layered approach. Each layer does a specific task. Broadly, the SQL Azure Architecture is classified into following layers:

1. Client layer
2. Services layer
3. Platform layer
4. Infrastructure layer

Now let’s talk about each layer.

First is the Client Layer. Client layer is something that is used by the application to talk with SQL Azure. Moreover, an application could be a mobile device talking via a WCF data service or it could be SSMS. Application could be a PHP app or a custom app. Application cloud can be ODBC or ADO.Net. Whenever application tries to communicate to SQL Azure, it does this via client layer. And this layer is closest to the Application.

Now next is Services Layer. Note that Data is given to the application via Service layer. This layer has three sub-tasks associated with it viz.,

1) Provisioning

2) Billing

3) Connection routing

We have already discussed the provisioning and the billing model in part 3 and services layer is responsible to enforce those model. Connection routing is responsible to make it possible for the client to connect to correct service instance. To understand this, think SQL Azure has hundreds and thousands of servers running in cloud. Now, whenever a connection request arrives, it needs to be mapped to the correct service instance and it is the job of the connections routing task in the services layer to direct the request to the correct destination where your data resides. And this process is abstracted from the end user.

One point to note here is that the communication between the client layer and the services layer happens over TDS + SSL via Internet. (TDS is Tabular data stream and SSL is secure sockets layer)

Fun Fact: All connections with SQL Azure are SSL encrypted. BTW, next part will have security model of SQL Azure in detail.

Next is the Platform Layer. It is composed of three parts viz.

1) SQL server

2) SQL Azure Fabric

3) Management services.

Here, SQL server is the relational database engine that we all are familiar with. Then, the SQL Azure Fabric makes sure that everything is highly available. Therefore, to keep SQL Azure highly available, the SQL Azure Fabric is responsible for automatic failover, load balancing and replication (More discussion on it in the second half of the article). In addition, we also have the management services that monitor the health of the service and do software updates and patches.

Therefore, with SQL Azure you do not have to worry about high availability and you do not have to worry about software updates and patches, etc. We had discussed it in part 1 of the series under the advantages of SQL Azure section.

Next is Infrastructure layer. Have you ever wondered that if you do not perform physical administration tasks, then who does it? The answer is that the Microsoft folks do it as a part of the service. In addition, the Infrastructure layer in the SQL Azure Architecture represents the IT admin tasks that support the SQL Azure Services.

That’s about the SQL Azure architecture. Now there’s a lot of under the hood processes that takes place inside SQL Azure. One of the interesting fact that you should know is that SQL Azure keeps three replicas (in total) of our Database. Apparently, this is to tackle failovers and provide the guaranteed High Availability (99.9% availability) with SQL Azure. We talked about it briefly in the platform layer section while discussing the SQL Azure architecture but here let us explore it a little more.

With SQL Azure, we have one replica called a primary and the remaining two are called secondary replicas. The reads and writes go through the primary replica. The changes are then replicated to the secondary replicas asynchronously. In case a replica fails, the failed replica is replaced and this process is called Reconfiguration. This process happens under the hood.

The other interesting question that arises here is where do the replicas reside? Well, the replicas reside on different physical servers (albeit in same data centre). This has its own advantage. This is so because, if a server (containing primary replica of our SQL Azure Database) fails for whatever reason, then we have two other replicas residing on other servers. Also, with such an architecture, It also interesting to know when a Transaction is considered 'committed' for SQL Azure Database. With SQL Azure Database, a transaction is not considered committed unless a primary replica and at least one of the secondary replica confirm that the transaction log records were successfully written to the disk.

This Mechanism (that happen under the hood) is in contrast to the On-Premise environment where the SQL server DBA's are responsible for handling failovers. With SQL Azure, we can now truly focus on the "Logical" administration and not worry about "Physical" administration of our database. To know more about what goes on inside SQL Azure, please refer to: http://social.technet.microsoft.com/wiki/contents/articles/inside-sql-azure.aspx

Now since you know about the SQL Azure Architecture, please note that whenever some document refers to SQL Azure “Server”, it refers to a server that is logical in nature. SQL Azure Server is just a “container” that “points” to SQL Azure database and it does not exist physically. In SQL server context, a server is something that is physical in nature whereas in SQL Azure, the server is a logical entity. It is an interesting difference and I hope you understood it.

In the next article, we will study the security model of SQL Azure. stay tuned!

Update Part 5:

http://beyondrelational.com/blogs/parasdoshi/archive/2011/10/25/getting-started-with-sql-azure-part-5-lt-lt-paras-doshi.aspx