Skip to main content

Azure Storage tiers and availability

By
In this post, we will cover what are the main differences between all the storage tiers available inside Azure Storage.
With the launch of Geo Zone Redundant Storage, there are 6 different types of tiers, that can cover different scenarios. Let's take on different scenarios and see which of them are most suitable for different cases.

Whare are the 6 different tiers?
  • Locally redundant storage (LRS)
  • Geo-redundant storage (GRS)
  • Read Access geo-redundant storage (RAGRS)
  • Zone-redundent storage (ZRS)
  • Geo Zone Redundant Storage (GZRS)
  • Read Access Geo Zone Redundant Storage (RAGZRS)
Remember that all of them are having an availability SLA to write access that has 3 nines (99.9%). The read SLA is different for each tier and starts from 99.9% for LRS, GRS, ZRS and GZRS and goes up to 99.99% for RAGRS and RAGZRS. The durability SLA for a year is at least 11 nines for LRS and goes up to 16 nines for GRS, RAGRS, GZRS and RAGZRS.

Scenario 1: One storage node is not available inside the Availability Zone
For all 6 storage tiers, this case is covered because there at least 3 replicas of the storage on different nodes. The unavailability of one storage node is not affecting access to the content.

Scenario 2: An Availability Zone is down
  • Locally redundant storage (LRS)
    • High impact, content is not available anymore as long as the Availability Zone is down
  • Geo-redundant storage (GRS) & Read Access geo-redundant storage (RAGRS)
    • Content is still available. 
    • Even so, a failover needs to be triggered to make content available in the secondary locations, that would become the primary one (DNS entries need to be updated)
    • To identify the real value behind the RPO the Last Sync Time property can be used.
    • Using Last Sync Time we can identify what data was lost
  • Zone-redundent storage (ZRS) & Geo Zone Redundant Storage (GZRS) & Read Access Geo Zone Redundant Storage (RAGZRS)
    • No impact, content is available and ready to be consumed
    • Content is available in different Availability Zones
Scenario 3: An entire region is not available
  • Locally redundant storage (LRS)
    • High impact, content is not available anymore. 
    • There are no replicas in other regions
  • Geo-redundant storage (GRS) & Read Access geo-redundant storage (RAGRS)
    • Content is still available
    • Failover needs to be triggered to make content available from the secondary region
    • Last Sync Time property can be used to identify what data was lost 
  • Zone-redundent storage (ZRS)
    • High impact, content is not available. All 3 replicas were done on different Availability Zones from the same region
  • Geo Zone Redundant Storage (GZRS) & Read Access Geo Zone Redundant Storage (RAGZRS)
    • In both cases the replicas in another region are available, but the manual trigger for the failover procedure needs to be done
    • For RAGZRS the secondary node already supports reads operations, but failover is required to support write operations

    What tier should I use?
    Deciding what type of tier to use is hard and it is all the time a tradeoff between costs and features. Beside this tiers, we have the access tiers (hot, cool and archive). Hard choice. 

    In the next post, we will take some real-life scenarios and we will indentify the most suitable tier.

    Comments

    Post a Comment

    Popular posts from this blog

    Why Database Modernization Matters for AI

    By
      When companies transition to the cloud, they typically begin with applications and virtual machines, which is often the easier part of the process. The actual complexity arises later when databases are moved. To save time and effort, cloud adoption is more of a cloud migration in an IaaS manner, fulfilling current, but not future needs. Even organisations that are already in the cloud find that their databases, although “migrated,” are not genuinely modernised. This disparity becomes particularly evident when they begin to explore AI technologies. Understanding Modernisation Beyond Migration Database modernisation is distinct from merely relocating an outdated database to Azure. It's about making your data layer ready for future needs, like automation, real-time analytics, and AI capabilities. AI needs high throughput, which can be achieved using native DB cloud capabilities. When your database runs in a traditional setup (even hosted in the cloud), in that case, you will enc...
    Post a Comment
    Read more

    Cloud Myths: Migrating to the cloud is quick and easy (Pill 2 of 5 / Cloud Pills)

    By
    The idea that migration to the cloud is simple, straightforward and rapid is a wrong assumption. It’s a common misconception of business stakeholders that generates delays, budget overruns and technical dept. A migration requires laborious planning, technical expertise and a rigorous process.  Migrations, especially cloud migrations, are not one-size-fits-all journeys. One of the most critical steps is under evaluation, under budget and under consideration. The evaluation phase, where existing infrastructure, applications, database, network and the end-to-end estate are evaluated and mapped to a cloud strategy, is crucial to ensure the success of cloud migration. Additional factors such as security, compliance, and system dependencies increase the complexity of cloud migration.  A misconception regarding lift-and-shits is that they are fast and cheap. Moving applications to the cloud without changes does not provide the capability to optimise costs and performance, leading to ...
    Post a Comment
    Read more

    Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills)

    By
    Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills) The idea that moving to the cloud reduces the costs is a common misconception. The cloud infrastructure provides flexibility, scalability, and better CAPEX, but it does not guarantee lower costs without proper optimisation and management of the cloud services and infrastructure. Idle and unused resources, overprovisioning, oversize databases, and unnecessary data transfer can increase running costs. The regional pricing mode, multi-cloud complexity, and cost variety add extra complexity to the cost function. Cloud adoption without a cost governance strategy can result in unexpected expenses. Improper usage, combined with a pay-as-you-go model, can result in a nightmare for business stakeholders who cannot track and manage the monthly costs. Cloud-native services such as AI services, managed databases, and analytics platforms are powerful, provide out-of-the-shelve capabilities, and increase business agility and innovation. H...
    Post a Comment
    Read more