In part two of this series, I’ll explain the differences between the four storage type options and redundancy settings for Azure storage accounts.
In part one of Understanding Azure Storage, I explained the differences between the two Azure storage account options, and how Managed Disks can be used to provision VMs and Virtual Machine Scale Sets (VMSS) more easily. If you missed it, you can read it here: Managed Disks and Storage Accounts.
Azure Storage provides four different storage services suited for varying application purposes.
If your app needs to store unstructured object data, then blob storage is for you. Sometimes referred to as object storage, blob storage can be any form of text or binary data, such as a document or media file. Unstructured means that data isn’t stored in columns and rows, as is the case in relational databases. Blob storage can be accessed from anywhere using REST APIs, but unlike file storage, can’t be mounted using the SMB protocol.
Intended mainly for legacy apps that you want to ‘lift and shift’ to the cloud, file storage allows files to be accessed from virtual machines using the standard SMB protocol. There’s also a REST API so that on-premises apps can access data stored in shares.
This is where it gets interesting because while table storage might sound like it’s just an SQL database, instead of storing data in rows and columns, data is stored in collections of individual documents, or as Microsoft refers to it, a NoSQL key/attribute data store. In other words, a JSON blob with no defined schema. The lack of structure enables more rapid development and faster access to data because unlike relational SQL databases, NoSQL key/attribute data stores don’t require careful planning and can be adapted more easily as needs change.
Designed for storing large numbers of messages that can be accessed from anywhere using authenticated HTTP or HTTPS calls, queue storage enables app components, which have been decoupled from one another so that they can scale independently, to communicate efficiently. Queue storage can handle traffic bursts so that servers aren’t brought to their knees by a sudden rise in demand. And like the other types of storage it is accessible using REST APIs, and client libraries for .NET, Java, Android, C++, Node.js, PHP, Ruby, and Python are available.
Azure replicates data to ensure that it’s always available in the event of a hardware failure. There are four different replication options available. Data within a region is replicated synchronously, and to secondary regions asynchronously in the background. For more information on synchronous and asynchronous replication, see Windows Server 2016: DFS-R vs. Storage Replica on Petri.
Locally Redundant Storage (LRS)
LRS ensures that your data stays within a single data center in your chosen region. Data is replicated three times. LRS is cheaper than the other types of redundancy and doesn’t provide protection against data center failures.
Zone-Redundant Storage (ZRS)
Only available for block blobs, ZRS keeps three copies of your data across two or three data centers, either within your chosen region or across two regions.
Geo-Redundant Storage (GRS)
This is the type of redundancy that Microsoft recommends by default, and it keeps six copies of your data. Three copies stay in the primary region, and the remaining three are replicated to a secondary region.
Read-Access Geo-Redundant Storage (RA-GRS)
The default redundancy setting, RA-GRS replicates data to a secondary region, where apps also get read access to the data.
In this article, I outlined the different available storage services and redundancy settings in Azure Storage.