Microsoft Azure – Zone Redundancy and SLA of Azure SQL

Azure SQL is a Database service offered by the Microsoft cloud platform. Azure SQL is often used to provide a storage layer for applications built or hosted in the cloud. This article aims to explain the basic details and concepts surrounding Azure SQL. We also deep dive into how SLAs and zone redundancy is configured in this service. 

Key Terminologies:  

• PaaS: Platform as a Service
• SLA: Service Level Agreement

What is Azure SQL Service?

Azure SQL is a PaaS Database service offered by the Microsoft Azure Cloud Platform. Under this service, you, as a user, get an instance (or multiple instances) of a fully managed database. Along with the database, you can provision compute, storage, and memory resources. By using Azure SQL, you will be able to seamlessly integrate storage for your applications, both inside and outside the Azure cloud. Microsoft manages the database, meaning they handle updates, patching, monitoring, intelligent data insights for your database, and more. Azure SQL database can handle both relational and non-relational databases. 

Zone Redundancy

When working with any cloud platform, the concept of an Availability zone comes into the picture. The physical data centers for the Azure cloud are located worldwide. All these data centers are divided into distinct geographical areas, called “Regions”. Each region is further subdivided geographically into “zones”. You, as an azure user, can control which region/zone your server resides in. 

To understand zone redundancy, let’s take an example. Note that ” East US” is a region. “East US 1” and “East US 2” are zones. Suppose you deploy 2 servers A and B in “East US 1”. If the Azure zone faces a power outage, your data would be inaccessible. However, if your 2 servers A and B are in East US 1 and East US 2 respectively, you will still have a backup if East US 1 fails.

The SLA and SLA Offer From Azure

SLA is an acronym for Service Level Agreements. In Azure, SLA is often used to define Availability. In other words, an SLA defines the expected level of service from Azure, and the penalties from Azure in case that level is not met (in this case, uptime). For SQL Database, Azure has an SLA for 99.99% high availability. For Zone Redundant Premium tier, this can go to 99.995%.

The 3 Tiers of Azure SQL

Users of Azure SQL Database can pick among 3 service tiers as follows

• Basic Tier: With a maximum database size of 2 GB, the basic tier is meant for light application workloads. It’s the most cost-effective tier that provides stable Database transactions per hour. 
  
• Standard Tier: Next in line is the Standard tier. With a maximum database size of 250 GB, this tier is best suited for business applications. Its transaction rate is measured per minute. 
  
• Premium Tier: This tier is designed for highly sensitive and critical applications hosted in the cloud. It’s the most expensive option, but also one that provides the highest performance. The database can be scaled up to 500 GB. Transaction rates are measured per second for this tier.

Basic and Standard Tier Zone Redundancy

For basic and standard tiers, ZRS (Zone Redundancy) is not auto-configured. If you want to add make your application fault-tolerant, you’ll have to add ZRS. 

There are 2 layers in the architecture:

• The first layer stores database files that contains your actual data (.mdf). This layer is stateful. 
• The second layer is stateless and it contains cached Data like your Temporary databases and caches, along with SSD. Azure leverages existing Availability Zones to configure Zone Redundancy.

Premium Tier Zone Redundancy

The Premium tier in azure has a slightly different architecture. Here, your storage files (like .mdf) and your compute layer (that has temporary databases and SSD) are coupled in a single node. Both these nodes are together replicated across a cluster, giving you very low latency and very high availability. There is one primary node used for read-write operations. Up to 3 secondary nodes are synchronized with the primary node. Azure automatically redirects an application to access data from the secondary node, in case the primary node fails.