We have already mentioned that the GPv1 and GPv2 support file shares, so it is useful to take note of some of the main differences:
Important note
You might be expecting the sizes in GB, TB, or PB (that is, gigabyte, terabyte, or petabyte); however, these tables show TiB, GiB, and PiB (that is, gibibyte, tebibyte, and pebibyte). This isn’t a type; it’s a slightly different notation used when measuring certain storage types. It’s down to the fact that GB, TB, and PB are Base 10, whereas GiB, TiB, and PiB are base 2 (that is, binary). As an example, 1 GB is 1,073,741,824 bytes, whereas 1 GiB is 1,000,000,000 bytes. You don’t need to worry about this too much and certainly not for the exam; the important point is to note the differences between each tier’s relative sizes.
Blob Storage is a similar story. Again, Blob Storage is also included with GPv1 and GPv2 accounts, but the Blob Storage account kind is a premium version that is specifically optimized for smaller, kilobyte-sized data. It’s ideal for an application that has a high number of transactions and requires low-latency storage.
Important note
A Blob is an acronym for a Binary Large Object. In Azure, it refers to files, especially non-text files such as executables, images, videos, disk files, and more. However, since text files and structured data files, such as comma-separated values (CSV), can also be stored as blobs, this can be a confusing definition! In Azure, blobs can also be Block, Page, and Append blobs – block blobs are optimized for large uploads; page blobs are fixed byte-sized and are optimized for random I/O – often used for disk images; and append blobs are optimized for – well, appending! Typically, if you see the term ”Blob,” think file.
As you can see, both Blob and File storage account kinds are generally only used for specific scenarios that require the capabilities that we have mentioned.
General Purpose V1 supports blobs, files, disks, queues, and tables. Usually, you would only choose GPv1 if your application is transaction-intensive but does need a large capacity. It also supports older versions of the storage services REST API, which is used to access the account programmatically.
Finally, we come to General Purpose V2. As you can probably guess, GPv2 is the newest version and is recommended for most scenarios. GPv2 supports blobs, files, disks, queues, tables, and Azure Data Lake Gen 2, which is a particular type of Blob Storage mainly aimed at big data analytics.
To ensure your data is always available, each option supports different replication options.
Storage replication
To help protect your data against hardware failure, storage accounts replicate your information to two other locations within any one region – this means that you always have at least three copies. Although they are all in the same region, each copy is in a different physical location within the availability zone. This is known as locally redundant storage (LRS). LRS is not the only option – if you need better protection, you can also choose other options.
Zone-redundant storage (ZRS) copies data synchronously across availability zones (for example, in separate data centers) within a region.
Geo-redundant storage (GRS) protects against regional failures by using LRS in the primary regions and creating three replicas in another region. This can be a read/write replica or a read-only replica with read-access geo-redundant storage (RA-GRS). In both cases, data is copied asynchronously to the other region.
Geo-zone-redundant storage (GZRS) is similar to GRS except that the local region’s data uses ZRS rather than LRS. Again, a read-only option is available with read-access geo-zone-redundant storage (RA-GZRS). At the time of writing, GZRS and RA-GZRS are relatively new and are now available in all regions.
Important note
The difference between synchronous writes and asynchronous writes is essential. Synchronous writes with LRS and ZRS happen simultaneously – in other words, the loss of one replica means the data in the other two will always be up to date. Asynchronous copies used in GRS and AZGRS happen after the primary replicas have been written – this means there is a time delay. Microsoft does not offer an SLA for the asynchronous copy but typically takes less than 15 minutes. In other words, the replica in the second region could be up to 15 minutes out of date from the primary replica.
Not all storage accounts support all redundancy options as the following table shows:
Using replicas help protects your data against hardware failure or regional outages; however, it does not protect against accidental or malicious deletion. Fortunately, Azure provides additional tools to help with this.
Leave a Reply