Azure storage – Lab6

Azure storage accounts

• A storage account provides a unique namespace for your Azure Storage data that's accessible from
anywhere in the world over HTTP or HTTPS.
• Data in this account is secure, highly available, durable, and massively scalable.
• When you create your storage account, you’ll start by picking the storage account type.
• The type of account determines the storage services and redundancy options and has an impact on
the use cases.
• A list of redundancy options that will be covered later in this module:
• 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)
Azure storage accounts
 Storage account endpoints
• One of the benefits of using an Azure Storage Account is having a unique namespace in
Azure for your data.
• In order to do this, every storage account in Azure must have a unique-in-Azure account
name.
• The combination of the account name and the Azure Storage service endpoint forms the
endpoints for your storage account.
• When naming your storage account, keep these rules in mind:
• Storage account names must be between 3 and 24 characters in length and may contain numbers and
lowercase letters only.
• Your storage account name must be unique within Azure.
• No two storage accounts can have the same name.
• This supports the ability to have a unique, accessible namespace in Azure.
Endpoint format for Azure Storage services
 Azure storage redundancy
• Azure Storage always stores multiple copies of your data so that it's protected from planned
and unplanned events such as transient hardware failures, network or power outages, and
natural disasters.
• Redundancy ensures that your storage account meets its availability and durability targets
even in the face of failures.
• When deciding which redundancy option is best for your scenario, consider the tradeoffs
between lower costs and higher availability.
• The factors that help determine which redundancy option you should choose include:
• How your data is replicated in the primary region.
• Whether your data is replicated to a second region that is geographically distant to the primary region,
to protect against regional disasters.
• Whether your application requires read access to the replicated data in the secondary region if the
primary region becomes unavailable.
Redundancy in the primary region

• Data in an Azure Storage account is always replicated three

times in the primary region.
• Azure Storage offers two options for how your data is replicated
in the primary region,
• locally redundant storage (LRS)
• zone-redundant storage (ZRS).
 Redundancy in the primary region
• Locally redundant storage
• Locally redundant storage (LRS) replicates your data three times within a single
data center in the primary region.
• LRS provides at least 11 nines of durability (99.999999999%) of objects over a
given year.
• LRS is the lowest-cost redundancy option and offers the
least durability compared to other options.
• LRS protects your data against server rack and drive
failures.
• However, if a disaster such as fire or flooding occurs
within the data center, all replicas of a storage account
using LRS may be lost or unrecoverable.
• To mitigate this risk, Microsoft recommends using zone-
redundant storage (ZRS), geo-redundant storage (GRS),
or geo-zone-redundant storage (GZRS).
 Redundancy in the primary region
• Zone-redundant storage
• For Availability Zone-enabled Regions, zone-redundant storage (ZRS) replicates
your Azure Storage data synchronously across three Azure availability zones in the
primary region.
• ZRS offers durability for Azure Storage data objects of at least 12 nines
(99.9999999999%) over a given year.
• With ZRS, your data is still accessible for both read and write operations
even if a zone becomes unavailable.
• No remounting of Azure file shares from the connected clients is
required.
• If a zone becomes unavailable, Azure undertakes networking updates,
such as DNS repointing.
• These updates may affect your application if you access data before the
updates have completed.
• Microsoft recommends using ZRS in the primary region for scenarios that
require high availability.
• ZRS is also recommended for restricting replication of data within a
country or region to meet data governance requirements.
 Redundancy in a secondary region
• For applications requiring high durability, you can choose to additionally copy the data in your storage
account to a secondary region that is hundreds of miles away from the primary region.
• If the data in your storage account is copied to a secondary region, then your data is durable even in the
event of a catastrophic failure that prevents the data in the primary region from being recovered.
• When you create a storage account, you select the primary region for the account.
• The paired secondary region is based on Azure Region Pairs, and can't be changed.
• Azure Storage offers two options for copying your data to a secondary region:
• geo-redundant storage (GRS)
• geo-zone-redundant storage (GZRS).
• GRS is similar to running LRS in two regions, and GZRS is similar to running ZRS in the primary region and
LRS in the secondary region.
• By default, data in the secondary region isn't available for read or write access unless there's a failover to
the secondary region.
• If the primary region becomes unavailable, you can choose to fail over to the secondary region.
• After the failover has completed, the secondary region becomes the primary region, and you can again
read and write data.
 Redundancy in a secondary region
Geo-redundant storage
• GRS copies your data synchronously three times within a single
physical location in the primary region using LRS.
• It then copies your data asynchronously to a single physical
location in the secondary region (the region pair) using LRS.
• GRS offers durability for Azure Storage data objects of at least
16 nines (99.99999999999999%) over a given year.
 Redundancy in a secondary region

• Geo-zone-redundant storage
• GZRS combines the high availability provided
by redundancy across availability zones with
protection from regional outages provided by
geo-replication.
• Data in a GZRS storage account is copied
across three Azure availability zones in the
primary region (similar to ZRS) and is also
replicated to a secondary geographic region,
using LRS, for protection from regional
disasters.
• Microsoft recommends using GZRS for
applications requiring maximum consistency,
durability, and availability, excellent
performance, and resilience for disaster
recovery.

GZRS is designed to provide at least 16 nines (99.99999999999999%) of durability of objects over a given year.
 Azure storage services

The Azure Storage platform includes the following data services:

•Azure Blobs
•A massively scalable object store for text and binary data.
•Also includes support for big data analytics through Data Lake Storage Gen2.
•Azure Files:
•Managed file shares for cloud or on-premises deployments.
•Azure Queues:
•A messaging store for reliable messaging between application components.
•Azure Disks:
•Block-level storage volumes for Azure VMs.
•Azure Tables:
•NoSQL table option for structured, non-relational data.
 Azure Blobs

• Blob storage is ideal for:

• Serving images or documents directly to a browser.
• Storing files for distributed access.
• Streaming video and audio.
• Storing data for backup and restore, disaster recovery, and archiving.
• Storing data for analysis by an on-premises or Azure-hosted service.
• Accessing blob storage
• Objects in blob storage can be accessed from anywhere in the world via HTTP or
HTTPS.
• Users or client applications can access blobs via URLs, the Azure Storage REST API,
Azure PowerShell, Azure CLI, or an Azure Storage client library.
• The storage client libraries are available for multiple languages, including .NET,
Java, Node.js, Python, PHP, and Ruby.
 Azure Blobs
• Blob storage tiers
• Azure Storage offers different access tiers for your blob storage, helping you store
object data in the most cost-effective manner.
• The available access tiers include:
• Hot access tier:
• Optimized for storing data that is accessed frequently (for example, images for your website).
• Cool access tier:
• Optimized for data that is infrequently accessed and stored for at least 30 days (for example,
invoices for your customers).
• Cold access tier:
• Optimized for storing data that is infrequently accessed and stored for at least 90 days.
• Archive access tier:
• Appropriate for data that is rarely accessed and stored for at least 180 days, with flexible latency
requirements (for example, long-term backups).
Azure storage workspace
• Creating Azure storage workspace
• Go to your home page of Azure account as shown in next slide.
• Make sure you have a resource group. (VM is not required)
Click on storage
accounts
Click on create
• You should
see your
subscription
and resource
group
• Give a name
to your
storage
account as per
naming
convention
• Select other
details as
shown
• Click on
advanced
• Make sure all
options are
selected as
shown
• Now click on
create
• After validation,
deployment will begin
• After deployment is
successful, launch your
storage workspace
• Take a screen shot of your
created workspace for
submission
• In your
storage
workspace, on
the left side,
under data
storage, click
on containers
• Click on
+container to
create a
container
• Give a name
to your
container.
• Leave all other
parameters as
it is
• Create the
container
• You will see
your container
• Open your
container
• Click on upload as shown
• You can now upload any available
image you have on your machine.
• If you want you can download any
image, store it on your machine
and then upload it
• Select your image and click on
upload
• Your uploaded image will be visible
• Open the image.
• You will see the details of your
image
• See the details.
• Note that your image is stored as a
block blob
• Copy the url for viewing the image
in any browser
• Go to any browser (e.g. google
chrome) and paste the url and
enter
• You will see the error msg like this.
• Take a screen shot of this msg for
submission.
• This error is because your
container does not have
anonymous access for viewing
• In your container,
• Click on change access level, which
is next to upload as shown in text
box.
• Change the access level to blob
(anonymous read access for
bolb….)
• Click ok
• Now refresh your browser.
• You will be able to see the image
• Take a screen shot for submission.
Conclusion

• Learning from the lab:

• How to storage data in storage
workspace.
• We have seen blob storage.
• You may explore other storage
options.