Skip to main content

Azure Replication Strategies

 

The data in your Azure storage account is always replicated to ensure durability and high availability. Azure Storage replication copies your data so that it is protected from planned and unplanned events ranging from transient hardware failures, network or power outages, massive natural disasters

You can choose to replicate your data within the same data center, across zonal data centers within the same region, and even across regions. Replication ensures that your storage account meets the Service-Level Agreement (SLA) for Storage even in the face of failures.

Comparison Of Replication Options:

 

LRS

ZRS

GRS/RA-GRS

GZRS/RA-GZRS

Node unavailability within
 a data center

Yes

Yes

Yes

Yes

An entire data center (zonal or non-zonal)
 becomes unavailable

No

Yes

Yes

Yes

A region-wide outage

No

No

Yes

Yes

Read access to your data (in a remote, geo-replicated region)
in the event of region-wide unavailability

No

No

Yes (with RA-GRS)

Yes (with RA-GZRS)

Available in storage account types

GPv1, GPv2, Blob

GPv2

GPv1, GPv2, Blob

GPv2


Locally redundant storage

LRS is the lowest-cost replication option and offers the least durability compared to other options. If a datacenter-level disaster (for example, fire or flooding) occurs, all replicas may be lost or unrecoverable.

Despite its limitations, LRS may be appropriate in these scenarios:

·       When your application stores data that can be easily reconstructed if data loss occurs.

·       When your data is constantly changing, for example a live feed, and storing the data is really not required.

·       When your application is restricted to replicating data only within a country due to data governance requirements.

 

 

Zone redundant storage

Zone Redundant Storage (ZRS) synchronously replicates your data across three (3) storage clusters in a single region. Each storage cluster is physically separated from the others and resides in its own availability zone. Each availability zone, and the ZRS cluster within it, is autonomous, with separate utilities and networking capabilities. Storing your data in a ZRS account ensures that you will be able to access and manage your data if a zone becomes unavailable. ZRS provides excellent performance and low latency.

Here are a few of more things to know about ZRS:

·       ZRS is not yet available in all regions.

·       Changing to ZRS from another data replication option requires the physical data movement from a single storage stamp to multiple stamps within a region.

·       ZRS may not protect your data against a regional disaster where multiple zones are permanently affected. Instead, ZRS offers flexibility for your data.

 

Geo-redundant storage

 

Geo-redundant storage (GRS) replicates your data to a secondary region (hundreds of miles away from the primary location of the source data). GRS costs more than LRS, but GRS provides a higher level of durability for your data, even if there is a regional outage. GRS is designed to provide at least 99.99999999999999% (16 9's) durability. When your storage account has GRS enabled, then your data is durable even when there is a complete regional outage or a disaster where the primary region isn't recoverable.

For a storage account with GRS or RA-GRS enabled, all data is first replicated with locally redundant storage (LRS). An update is first committed to the primary location and replicated using LRS. The update is then replicated asynchronously to the secondary region using GRS. When data is written to the secondary location, it's also replicated within that location using LRS. Both the primary and secondary regions manage replicas across separate fault domains and upgrade domains within a storage scale unit. The storage scale unit is the basic replication unit within the datacenter. Replication at this level is provided by LRS. If you opt for GRS, you have two related options to choose from:

·       GRS replicates your data to another data center in a secondary region, but that data is available to be read only if Microsoft initiates a failover from the primary to secondary region.

·       Read-access geo-redundant storage (RA-GRS) is based on GRS. RA-GRS replicates your data to another data center in a secondary region, and also provides you with the option to read from the secondary region. With RA-GRS, you can read from the secondary regardless of whether Microsoft initiates a failover from the primary to the secondary.

 

Geo-zone redundant storage

Geo-zone-redundant storage (GZRS) combines the high availability of zone-redundant storage with protection from regional outages as provided by geo-redundant storage. Data in a GZRS storage account is replicated across three Azure availability zones in the primary region and also replicated to a secondary geographic region for protection from regional disasters. Each Azure region is paired with another region within the same geography, together making a regional pair.

With a GZRS storage account, you can continue to read and write data if an availability zone becomes unavailable or is unrecoverable. Additionally, your data is also durable when a complete regional outage or a disaster in which the primary region isn’t recoverable. GZRS is designed to provide at least 99.99999999999999% (16 9's) durability of objects over a given year. GZRS also offers the same scalability targets as LRS, ZRS, GRS, or RA-GRS. You can optionally enable read access to data in the secondary region with read-access geo-zone-redundant storage (RA-GZRS).

Microsoft recommends using GZRS for applications requiring consistency, durability, high availability, excellent performance, and resilience for disaster recovery. Enable RA-GZRS for read access to a secondary region when there is a regional disaster.

Thank you !! Example HTML page Pleaes provide your valuable feedback.
Labels:

Comments

Post a Comment

Popular posts from this blog

Script To Monitor disk Usage

Hello All, Many times we have a requirement to automate few of the tasks, and one of the important task is to delete old log files from log destination. We usually get the conditions where we have to delete the log from particular directory when it reaches to some thresh hold value. Now a day the requirement of automation is highly increased where we are seeing most of the day to day tasks are getting automated using different scripting languages. Its always a good idea to automate your daily tasks which will save your working hours and will increase your productivity. Most of the time log destination gets full and due to which we face other issues like application down or particular service stop working. And manual deleting of log is hectic process so below script will help you to delete your log data when it meets your condition, and also it will trigger mail to recipient after deletion of logs. You can schedule this script in your crontab according to your feasible ti...
7 comments
Read more

Azure Active Directory

  What is Azure Active Directory? Azure Active Directory is Microsoft’s multi-tenant, cloud-based directory and identity management service. For an organization, Azure AD helps employees sign up to multiple services and access them anywhere over the cloud with a single set of login credentials. Azure Active Directory Concept: It is important to understand these Azure AD concepts. Identity . An object that can get authenticated. An identity can be a user with a username and password. Account . An identity that has data associated with it. You can't have an account without an identity. Azure subscription . Used to pay for Azure cloud services. You can have many subscriptions and they're linked to a credit card. Azure tenant/directory . A dedicated and trusted instance of Azure AD, a Tenant is automatically created when your organization signs up for a Microsoft cloud service subscription. More instances of Azure AD can be created. Azure AD is the underlying product ...
1 comment
Read more

Azure Storage

Azure Storage is Microsoft's cloud storage solution for modern data storage scenarios.    Why Azure Storage: Durable and Highly Available: ·        Data is safe during hardware failure. ·        Replicate data across data centres. ·        In local catastrophe or natural disaster data replicated to other data centres remains highly available. Secure: ·        Data encrypted by Azure service Storage Service encryption (SSE) for data at rest. ·        Completed control over who access your data. Scalable: ·        Designed to massive scale. Managed: ·        Azure handles maintenance, updates and critical issues. Accessible: ·        Accessible from anywhere in the world. ·        You can access using http, https,...
Post a Comment
Read more

Connect SparkThriftServer with Tableau/PowerBI

  Connect SparkThriftServer with Tableau/PowerBI REFERENCE : https://docs.microsoft.com/en-us/azure/hdinsight/hdinsight-apache-spark-use-bi-tools Use Power BI for Spark data visualization Note This section is applicable only for Spark 1.6 on HDInsight 3.4 and Spark 2.0 on HDInsight 3.5.   Once you have saved the data as a table, you can use Power BI to connect to the data and visualize it to create reports, dashboards, etc.   1.       Make sure you have access to Power BI. You can get a free preview subscription of Power BI from http://www.powerbi.com/ . 2.       Sign in to Power BI . 3.       From the bottom of the left pane, click Get Data . 4.       On the Get Data page, under Import or Connect to Data , for Databases , click Get . 5.       On the next screen, click Spark on Azure HDInsight and then click Connect . When prompted, enter th...
Post a Comment
Read more

Continuous Integration with Jenkins and GitLab

  Enter the credential manager Go into system credentials Add a new credential (private key of slave node where you want to run the job) We need a SSH private key credential. I’m not sure the username matters, but I set it to “git” as that is what the login for gitlab uses. I then pointed it to my *private* key on the machine and gave it a description. Now the key shows up in the system. Once I had setup the ssh private key, which allows Jenkins to connect to the git host over ssh (i.e. git clone git@server:user/repo.git), I needed to setup API Access for Jenkins to get metadata from GitLab. In GitLab go to your user profile. Select “Access Tokens”. Now make a new token, I gave it a descriptive name and made it expire at the end of the decade (I haven’t investigated the pros/cons of expiration date length yet). You are then presented with a screen showing the token. Copy it now, as it won’t be accessible again! You can always create a new one if you mess it up t...
Post a Comment
Read more