5.- AZ-104 Azure - Storage

AZ-104 Azure - Storage Accounts

  1. Azure Queue: Message Based storage for microservices.
  2. Azure Table: Non-relational semi-structured data storage service.
  3. Azure Files: Cloud-based file-sharing service.
  4. Azure blob: object-oriented storage solutions (store jpgs, mp4s, etc).
Type of storage account Supported storage services Redundancy options Usage
Standard general-purpose v2 Blob Storage (including Data Lake Storage1), Queue Storage, Table Storage, and Azure Files Locally redundant storage (LRS) / geo-redundant storage (GRS) / read-access geo-redundant storage (RA-GRS)

Zone-redundant storage (ZRS) / geo-zone-redundant storage (GZRS) / read-access geo-zone-redundant storage (RA-GZRS)2
Standard storage account type for blobs, file shares, queues, and tables. Recommended for most scenarios using Azure Storage. If you want support for network file system (NFS) in Azure Files, use the premium file shares account type.
Premium block blobs3 Blob Storage (including Data Lake Storage1) LRS

ZRS2
Premium storage account type for block blobs and append blobs. Recommended for scenarios with high transaction rates or that use smaller objects or require consistently low storage latency. Learn more about example workloads.
Premium file shares3 Azure Files LRS

ZRS2
Premium storage account type for file shares only. Recommended for enterprise or high-performance scale applications. Use this account type if you want a storage account that supports both Server Message Block (SMB) and NFS file shares.
Premium page blobs3 Page blobs only LRS

ZRS2
Premium storage account type for page blobs only. Learn more about page blobs and sample use cases.

Storage accounts 
Azure Storage Redundancy 

Locally redundant storage

Illustration that shows three copies of blob data stored in the same datacenter with LRS.

Locally redundant storage (LRS) copies your data three times across separate racks of hardware in a datacenter inside one region. Even if there's a hardware failure or if there's maintenance work in the datacenter, this replication type ensures data is available for use.

LRS doesn't protect you from a datacenter-wide outage. If the datacenter goes down, you could lose your data.

Geographically redundant storage

image.png

Read-access geo-redundant storage

With GRS, your secondary region isn't available for read access until the primary region fails. If you want to read from the secondary region, even if the primary region hasn't failed, use Read-access geo-redundant storage (RA-GRS) for your replication type.

Zone-redundant storage

Illustration of data copied to three storage clusters in separate availability zones with ZRS.

Zone-redundant storage (ZRS) copies your data in three storage clusters in a single region. Each cluster is in a different physical location and is considered as a single availability zone. Each cluster uses its own separate utilities for things like networking and power. If one datacenter is experiencing an outage, your data remains accessible from another availability zone in the same Azure region.

Because all availability zones are in a single region, ZRS can't protect your data from a regional-level outage.

Geo-zone-redundant storage

Geo-zone-redundant storage (GZRS) combines the high availability benefits of ZRS with GRS. With this replication type, your data is copied across three availability zones in one region. Data is also replicated three times to another secondary region that's paired with it. This way, your zone-redundant data is also secure from regional-level outages.

Read-access geo-zone-redundant storage

Read-access geo-zone-redundant storage (RA-GZRS) uses the same replication method as GZRS, but lets you read from the secondary region. If you want to read the data that's replicated to the secondary region, even if your primary isn't experiencing downtime, use RA-GZRS for your replication type.

GZRS and RA-GZRS are currently available in the following regions:

Paired regions

A paired region is where an Azure region is paired with another in the same geographical location to protect against regional outage. Paired regions are used with GRS and GZRS replication types.

Illustration that shows a hierarchy of geography, regional pair, region, and datacenters.

Here's a list showing some of the regions that are paired together. You can get the full list at Azure paired regions.

  Region Region
Asia East Asia Southeast Asia
Australia Australia East Australia Southeast
Canada Canada Central Canada East
China China North China East
Europe North Europe (Ireland) West Europe (Netherlands)
Japan Japan East Japan West
North America East US West US
South Africa South Africa North South Africa West
UK UK West UK South

Use cases for each replication type

The following table summarizes how many copies you get with each replication type and when you should use it.

Replication type Copies Use case
LRS 3 Data remains highly available, but for compliance reasons, isn't allowed to leave the local datacenter.
GRS 6 App has access to the data, even if an entire region has an outage.
RA-GRS 6 App reads from multiple geographical locations, so you can serve users from a location that's closer to them.
ZRS 3 Need redundancy in multiple physical locations, but because of compliance, data isn't allowed to leave a region.
GZRS 6 App can access data, even if the primary region has failed, and your secondary region has a datacenter that's experiencing an outage, but you don't want to read from the secondary region unless the primary region is down.
RA-GZRS 6 Regularly read data from your secondary region, perhaps to serve users from a location closer to them, even if a datacenter is up in your primary region.

Creating a storage account

Navigate to Storage accounts and then create


image.png

Select type of redundancy

image.png

image.png

image.png

AZ-104 Azure - Conceptualizing Azure Blog Storage

  1. Describing Azure Blob Storage
  2. Components of Blob Architecture
  3. Type of Blobs
  4. Container Access Levels

Azure Blob Storage is Microsoft's object storage solution for the cloud. Blob Storage is optimized for storing massive amounts of unstructured data. Unstructured data is data that doesn't adhere to a particular data model or definition, such as text or binary data. Its object based and easily accessible from HTTP/REST

 

image.png

Blob Storage is designed for:

Blob Architecture
Types of Blobs
Container Access Level
Container Access Levels:

Now let's access our Storage account ,below we can see the system storage account, here we will crate a container

image.png

First check if blob anonymous access its enabled if not click on the link to enable

image.png

 

now create a new container, anonymous access level will only be available if blob anonymous access its enabled.

 

image.png

3 different levels of containers with different access.

image.png

 

We can see each container has its own url to access the container

image.png

 

now let's upload a random file to our private container, we can see it has its own url to access the file directly

image.png

AZ-104 Azure - Configuring blob object replication

Object replication asynchronously copies blocks of blobs between storage accounts

Diagram showing how object replication works


Create a destination storage account and make sure versioning for blobs its enabled

image.png

For source storage account we will enable versioning and change feed.

image.png

 

now we need to add our containers one on source and one on destination storage account.

image.png

image.png

 

 

Next step is to create an object replication rule on our source data storage

image.png

for our replication rule we need to select the destination storage account in this case dststorageaccountcloud1 specify the source container and destination container we can also apply filters to replicate only data on specific folder structure ,we can also specify which data to copy over here we select only new objects.

image.png

 

image.png

 

Now we are uploading a new blob on our src storage account and src container

image.png

now we can see file blob1.txt on our source account but not on our destination as there is a rule 

image.png

 

we are adding our same blob but this time we will specify the folder /prefix to match our object rule.

 

image.png

 

blob.txt is now also on destination container due to our object replication

image.png

AZ-104 Azure - Configuring Blob Lifecycle Management

Lifecycle Management Concepts

Azure Blob Storage service feature that enables automation to manage lifecycle operations of blobs.

image.png

 

Let's add random files to our container and add a lifecycle rule

 

image.png

 

 

image.png

image.png

we can also specify a filter to modify only those inside our testcontainer/folder 

image.png

Now after 30 days all our blobs will move from hot to cold.