Azure Storage Account - Lets Understand


Storage Account

It’s a Service on Azure which contains all kinds of storage data objects. You can think it like a container where you can upload your data. Lets check what all kind of data we have and what all services Storage Account provides to deal with it -

Blobs – This is unstructured data. We have 3 types of blobs

·                   Block blobs – this is made up of blocks of data that can be managed individually upto 4.7TB. It stores text and binary data.

·                    Append Blobs – this is also made up of block as block blob but are optimized for append operations. This is ideal for scenarios such as logging data from virtual machines.

·                    Page Blobs – This is for random access files up to 8 TB in size. Page blobs store virtual hard drive (VHD) files and serve as disks for Azure virtual machines




Files – This is for Azure file share which is fully managed file shares in the cloud that are accessible via the industry standard SMB protocol. Azure file shares can be mounted concurrently by cloud or on-premises deployments of Windows, Linux, and macOS.


Tables - Azure Table storage stores large amounts of structured data. The service is a NoSQL datastore which accepts authenticated calls from inside and outside the Azure cloud. Azure tables are ideal for storing structured, non-relational data.


Queue -  Azure Queue storage service enables storing large numbers of messages that can be accessed from anywhere via authenticated calls using HTTP or HTTPS. Azure Storage Queue is a type of message queuing services provided by Azure that provides queue storage infrastructure for a REST-based interface, within and between different applications and services.


Storage Account has various properties that is very imp to understand as per an architect perspective –

  •  Account Kind
  •  Performance
  •  Access Tier
  •  Replication Type



Account Kind

·        General Purpose v2 – Basic Storage account type for blob, files, queues and tables
·        General Purpose V1 – Legacy account type for blob, files, queues and tables
·        Blob – Legacy blob-only storage accounts. Use general purpose-v2 instead when possible


Performance tiers

·        A standard performance backed by magnetic drives & provide low cost storage
·        A premium performance backed by SSD with high performance and low latency.

Premium storage only used by VM disks & suitable for DB servers with high I/O applications.

VM uses Premium storage qualify for 99.9% uptime/connectivity SLA, even when running as a single instance.


Premium Storage limitations:
  •         Only VM disk can be stored
  •         Only page blob can be created in Premium storage
  •         Only LRS will be configured.


Access Tier

Each access tier in Azure Storage is optimized for a particular pattern of data usage.

Hot - optimized for frequent access of objects in the storage account means accessing is most cost-effective, while storage costs are higher. New storage accounts are created in the hot tier by default.

Cool - optimized for storing large amounts of data that is infrequently accessed and stored for at least 30 days. Storing data in the cool tier is more cost-effective, but accessing that data may be more expensive than accessing data in the hot tier.

Archive - tier is available only for individual block blobs. The archive tier is optimized for data that can tolerate several hours of retrieval latency and that will remain in the Archive tier for at least 180 days. The archive tier is the most cost-effective option for storing data. However, accessing that data is more expensive than accessing data in the hot or cool tiers.



Replication

Replication options for a storage account include:

·        Locally-redundant storage (LRS): A simple, low-cost replication strategy. Data is replicated synchronously three times within the primary region.
·        Zone-redundant storage (ZRS): Replication for scenarios requiring high availability. Data is replicated synchronously across three Azure availability zones in the primary region.
·        Geo-redundant storage (GRS): Cross-regional replication to protect against regional outages. Data is replicated synchronously three times in the primary region, then replicated asynchronously to the secondary region. For read access to data in the secondary region, enable read-access geo-redundant storage (RA-GRS).
·        Geo-zone-redundant storage (GZRS) (preview): Replication for scenarios requiring both high availability and maximum durability. Data is replicated synchronously across three Azure availability zones in the primary region, then replicated asynchronously to the secondary region. For read access to data in the secondary region, enable read-access geo-zone-redundant storage (RA-GZRS).



Storage account endpoints


A storage account provides a unique namespace in Azure for your data. Every object that you store in Azure Storage has an address that includes your unique account name. The combination of the account name and the Azure Storage service endpoint forms the endpoints for your storage account.

·        Blob storage: http://mystorageaccount.blob.core.windows.net
·        Table storage: http://mystorageaccount.table.core.windows.net
·        Queue storage: http://mystorageaccount.queue.core.windows.net
·        Azure Files: http://mystorageaccount.file.core.windows.net





Azure Storage provides a layered security model. This model enables you to secure and control the level of access to your storage accounts that your applications and enterprise environments demand, based on the type and subset of networks used. When network rules are configured, only applications requesting data over the specified set of networks can access a storage account. You can limit access to your storage account to requests originating from specified IP addresses, IP ranges or from a list of subnets in an Azure Virtual Network (VNet).






7 comments:

  1. very good post.
    It'd be great produce a post with a end to end infrastructure creation (better is hybrid)
    example:
    create VPNsite2site
    define you azure vnet and subnet
    define your storage account
    define your vault
    define your RBAC roles
    deploy web app + slq server + load balancer
    define your back up policy
    define your NSG

    In the end we'll have an balanced web application(it is ok a welcome html on IIS) hosted on azure backed up on azure
    regards





    ReplyDelete

Azure Firewall - Detail Overview

Azure Firewall is a cloud-native and intelligent network firewall security service that provides the best of breed threat protection for you...