Skip to content

1.Overview & Architecture

Overview

Types

  • Standard:
    • Blob Storage:
    • General Purpose v1:
    • General Purpose v2:
  • Premium:

Access Tiers

  • Default access tier setting can be set to either Hot or Cool for new blob:
    • Can be set at the storage account or the blob level
    • Can be updated after creation
  • Changing a blob's tier from Hot to Cool or Archive is instantaneous
  • Changing tier from Cool to Hot is instantaneous
  • Changing tier from Archive to Cool or Hot can take up to 15hrs

  • Summary of access tier options

    Hot

    • Is an online tier
    • For data in active use

    Cool

    • Is an online tier
    • Designed for data that are not used frequently but are expected to be available for immediate access
      • For backup
      • For DR
      • For data sets not used frequently
    • For data stored with a minimum of 30 days:
      • Data is subject to an early deletion penalty
      • If deleted or moved to a different tier before 30 days has elapsed
      • Penalty is prorated according to the remaining time

    Archive

    • Is an offline tier
    • Flexible latency requirements on the order of hours (up to 15 hours)
    • To read or download a blob in the Archive tier you must first rehydrate it to an online tier
    • Data should be stored for a minimum of 180 days:
      • Data is subject to an early deletion charge
      • Penalty is prorated according to the remaining time
    • Designed for:
      • Long term backup
      • Legal retention
    • A maximum of 10 GiB per storage account may be rehydrated per hour.
    • 2 options to rehydrate the blob (aka move it to Cool or Hot tier):
      • Copy it
        • Copying an archived blob to an online destination tier is supported within the same storage account only
      • Change his access tier
        • Changing a blob's tier doesn't affect its last modified time
        • If lifecycle management exists this could lead to moving the blob back to Archive !
    • Rehydratation priority:
      • Through the x-ms-rehydrate-priority HTTP header when invoking Set Blob Tier or Copy Blob API
      • Standard priority: default, up to 15hrs
      • High priority:
        • May complete in less than one hour for objects under 10 GB in size
        • Cost more than standard priority
        • Recommended for use in emergency data restoration situations
      • Moving from Std to High is possible
      • Moving from High to Std is not possible

Data Lifecycle

  • rule-based policy that you can use to:
    • transition blob data to the appropriate access tiers
    • expire data at the end of the data lifecycle
  • Policy is a collection of JSON rule:
    • up to 100 rule per policy
    • definition object in a rule is made of filter + action
  • Rule filter:
    • specify the blob type and the path
  • Rule action:
    • specificy the action to take
    • tierToCool
    • enableAutoTierToHotFromCool
    • tierToArchive
    • delete
  • The run conditions are based on age of the data
  • The platform runs the lifecycle policy once a day

Pricing

SLA

RA-GRS

  • Read:
    • Standard access tier: 99.99 %
    • Cool access tier: 99.9 %
  • Write:
    • Standard access tier: 99.9 %
    • Cool access tier: 99 % (~ 7h30)

LRS, ZRS, GRS

  • Read:
    • Standard access tier: 99.9 %
    • Cool access tier: 99 % (~ 7h30)
  • Write:
    • Standard access tier: 99.9 %
    • Cool access tier: 99 % (~ 7h30)

Limits

  • Block Blob:
    • 197 TB max
  • Page Blob:
    • 8 TB max

Architecture

Storage Account to Blob

  • Storage Account 1.1 --- 0.n Container 1.1 --- 0.n Blob
  • Storage Account:
    • unique namespace avec FQDN: http://STORAGE_ACCOUNT_NAME.blob.core.windows.net
    • Unlimited number of containers
  • Container:
    • Sets of blob
    • Unlimited number of blob
    • name must be lower case
  • Blob:
    • 3 types:
      • Block: stockage de données de tout type
      • Append: = Block mais optimisé pour les opérations en ajout
      • Page: utilisé pour le stockage des disques de VM

Multitenancy guidelines

Multitenancy model

  • 1 account per tenant:
    • storage keys are isolated and can be rotated independently
    • Per-tenant scaling is easier
    • Increase Ops
  • Multitenant account with dedicated container:
    • no limit to the number of blob containers that you can create within a storage account
    • can use Azure Storage access control, including SAS, to manage access for each tenant's data
    • can easily monitor the capacity that each container uses
    • subject to noisy neighbor anti pattern
  • Multitenant account with multitenant container:
    • you can't assign access to all blobs within a specified path inside a container to a single tenant
      • Can be fixed by using hierarchical namespace however it reduce the features of storage account
    • subject to noisy neighbor anti pattern

Supported features for multitenancy

  • Shared Access Signatures:
    • Per-container and/or per-blob SAS supported
    • Increase Ops/ SAS management
    • When giving container direct access to tenants use Valet Key pattern
  • Access control:
    • Authorize access to blobs using Azure Active Directory is supported
    • Attribute-based access control (Azure ABAC) is supported
  • Lifecycle management:
    • As it's applied on a blob or container, multitenant scenario is supported
    • Be careful to maybe not create one specific dedicated rule per customer/tenant ! otherwise ops will increase
    • There are limits on the number of rules you can specify in a lifecycle management policy
  • Immutable storage:
    • Prevention is enforced at the storage account layer then it applies to all tenant
  • Encryption:
    • Applies at the storage account level = for all tenant within it
    • Rely on Encryption Scope to setup key encryption at the container or blob level
  • Monitoring:
    • it's possible to view the total capacity of a storage account, but not a single container