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
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
- Client layer
- Services layer
- Platform layer
- 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.,
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
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: