Ch. 2 Implement and manage storage. Flashcards
How are storage accounts managed?
Through the Azure Resource Manager.
How are storage accounts authenticated and authorized?
Through Azure Active Directory and RBAC.
Azure storage account
- contains all of your Azure Storage data objects (blob, file shares, queues, tables, and disks)
- provides a unique namespace for your Azure Storage data that’s accessible from anywhere in the world over HTTP and HTTPS
- data in the storage account is durable and highly available, secure, and massively scalable
Endpoint
the combination of the account name and the service endpoint
Storage firewall
allows you to limit access to specific IP addresses or an IP address range
- by limiting access to the IP address range of your company, access from other locations will be blocked
- service endpoints are used to restrict access to specific subnets within an Azure VNet
Where do you configure the storage firewall using Azure portal?
- open the storage account blade
- Click Firewalls and virtual networks
- Under All Access From, click Selected Networks to reveal the Firewall and Virtual Network settings
Address space for storage firewall
When creating a storage firewall, you must use public Internet IP address space. You cannot use IPs in the private IP address space.
How do you access the storage account via the Internet?
Use the storage firewall to specify the Internet-facing source IP addresses.
Benefits of using network service endpoints
- allows you to remove access from the public Internet and only allow traffic from a virtual network for improved security
- optimized routing - service endpoints create a direct network route from the virtual network to the storage service
Configuring service endpoints
Step 1. create the route from the subnet to the storage service
Step 2. configure which virtual networks can access a particular storage account
How do you enable anonymous user access in Blob storage?
you much change the container access level
by default no public read access is enabled for anonymous users
Blob Storage access levels
Private
Blob
Container
the access level is configured separately on each blob container
Blob Storage access levels - Private
only the storage account owner can access the container and its blobs, no one else has access
Blob Storage Access levels - Blob
only blobs within the container can be accessed anonymously
Blob Storage access levels
only blobs within the container can be accessed anonymously
Blob Storage access levels Container
blobs and their containers can be accessed anonymously
Shared Access Signature token (SAS token)
a URI query string parameter that grants access to specific containers, blobs, queues, and tables
use a SAS token to grant access to a client that shouldn’t have access to the entire contents of the storage account (and storage account keys) but still requires secure authentication
grant access to a specific resource, for a specified period of time, and with a specified set of permissions
used to read and write the data to users’ storage accounts
used to copy blobs or files to another storage account
only use HTTPS because active SAS tokens provide direct authentication to your storage account, you must use a secure connection to distribute SAS token URIs
Types of services within a storage account
blobs
tables
queues
files
disks
Blobs
provides highly scalable service for storing arbitrary data objects such as text or binary data
tables
provides a NoSQL-style store for storing structured data
tables in Azure storage do not require a fixed schema, different entries in the same table can have different fields
queues
reliable message queuing between application components
files
managed files shares that can be used by Azure VMs or on-premises servers
disks
persistent storage volume for Azure VM which can be attached as a virtual hard disk
Types of Storage Blobs
- Block Blobs
- Append Blobs
- Page Blobs: used to store VHD files when deploying unmanaged disks (older disk storage technology for Azure virtual machines, managed disks are recommended for new deployments)
Configurable Options when creating a storage account
Performance Tier
Account Kind
Replication Option
Access Tier
Naming storage accounts
- the storage account name must be unique across all existing storage account names in Azure
- the name must be between 3 to 24 characters and can contain only lowercase letters and numbers
Performance tiers
Standard: supports all storage services, blobs, tables, files, queues, and unmanaged Azure virtual machine disks. It uses magnetic disks to provide cost-efficient and reliable storage.
Premium: designed to support workloads with greater demands on I/O and is backed by high-performance SSD disks
It only supports General-Purpose accounts with Disk Blobs and Page Blobs
It also supports Block Blobs or Append Blobs with BlockBlobStorage accounts and files with FileStorage accounts
Can the performance tier setting be changed once selected?
No, the setting cannot be changed at a later date.
Replication options with premium tier
premium tier only supports LRS as a replication option for general-purpose storage accounts
it supports LRS and ZRS both for BlockBlobStorage and File Storage accounts
Standard Tier account kind
- Storage V2 ( General-Purpose V2)
- Storage (General-Purpose V1)
- BlobStorage
Premium Tier Account kind
- Storage V2 (General-Purpose v2)
- Storage (General - Purpose v1)
- BlockBlobStorage
- FileStorage
Key points to remember.
- the Blob Storage account is a specialized storage account used to store Block Blobs and Append Blobs. You can’t store Page Blobs in these accounts, therefore you can’t use them for unmanaged disks
- Only General-Purpose V2 and Blob Storage accounts support the Hot, Cold, and Archive access tiers
- General-Purpose V1 and Blob Storage accounts can both be upgraded to General-Purpose V2 account. This operation is irreversible. No other changes to the account kind are supported.
Storage Account Replication Options
- Locally redundant storage (LRS)
- Zone Redundant storage (ZRS)
- Geographically redundant storage (GRS)
- Read access geographically redundant storage (RA-GRS)
- Geographically zone redundant storage (GZRS)
- Read access geographically zone redundant storage (RA-GZRS)
Locally Redundant Storage (LRS)
makes 3 synchronous copies of your data within a single datacenter
available for General-Purpose or Blob Storage accounts at both Standard and Premium Performance tiers
Zone redundant storage (ZRS)
makes 3 synchronous copies to 3 separate availability zones within a single region
available for General-Purpose V2 storage accounts only at the Standard Performance tier only, also available for BlockBlobStorage and FileStorage
Geographically redundant storage (GRS)
There are 3 local copies in the same datacenter (LRS) and 3 additional asynchronous copies to a second datacenter hundreds of miles away from the primary region. Data replication occurs within 15 min although no SLA s provided.
available for General-Purpose or Blob Storage accounts at the Standard Performance tier only
Read access geographically redundant storage (RA-GRS)
There are 3 local copies, plus 3 additional asynchronous copies to a second datacenter hundreds of miles away from the primary region as well as read-only access to the data in the secondary datacenter.
Available for General-Purpose or Blob Storage account at the Standard Performance tier only
Geographically zone redundant storage (GZRS)
There are 3 synchronous copies across multiple availability zones, plus 3 additional asynchronous copies to a second datacenter hundreds of miles away from the primary region. Data replication occurs within 15min although there is no SLA.
Read access geographically zone redundant storage (RA-GZRS)
There are 3 synchronous copies across multiple availability zones, plus 3 additional asynchronous copies to a second datacenter hundreds of miles away from the primary region, plus read-only access to the data in the secondary datacenter
Available for General-Purpose V2 storage accounts only at the Standard Performance tier only
Note on Replication options
- if an entire datacenter is down then LRS would incur an outage
- if a primary region is down both the LRS and ZRS options would incur an outage, but GRS and GZRS would provide the secondary region that takes care of requests
- not all the replication options are available in all regions
Specifying replication and performance tier settings
When creating a storage account via the Azure portal, the replication and performance tier options are specified using separate settings
When creating an account using Azure PowerShell, the Azure CLI, or via template, these settings are combined within the SKU settings
ex. to specify a Standard storage account using locally redundant storage using the Azure CLI, use –sku Standard_LRS
Access Tiers
- Hot
- Cool
- Archive
– access tiers apply to Blob Storage only. They do no apply to other storage services including Block Blob Storage
Access Tier - Hot
- used to store frequently accessed objects
- data access costs are low while storage costs are higher
Access Tiers - Cool
- used to store large amounts of data that is not accessed frequently and that is stored for at least 30 days
- the availability SLA is lower than for the Hot tier
- relative to the Hot tier, data access costs are higher and storage costs are lower
Access Tiers - Archive
- used to archive data for long-term storage, that is accessed rarely, can tolerate several hours of retrieval latency and will remain in the Archive tier for at least 180 days
- most cost effective option for storing data, but accessing that data is more expensive than accessing data in the Hot or Cool tiers
Note on Access Tiers
- new blobs will default to the access tier that is set at the storage account level, though you can override that at the blob level by setting a different access tier, including the archive tier
- the archive tier is not supported for ZRS, GZRS, and RA-GZRS
Shared Access Signatures (SAS) Token
- a SAS token is a way granularly control how a client can access data in an Azure storage account
- you can use an account - level SAS to access the account itself
- you can control what services and resources the client can access
- what permission the client has
- how long the token is valid for
What is the simplest way to create a SAS token?
Through the Shared Access Signature blade in the Azure portal