This post by David Papkin Planning and Implementing Storage using Microsoft Azure Storage Service
Azure Storage is used to store files, and virtual machine disks, together with other types of
information. Azure Storage is used by websites, mobile apps, desktop applications, and cloud
services, as well as custom solutions. Azure Storage is part of Azure Data Services, together with backup and recovery, and this post covers all these components.
Overview of Azure Storage
Azure Storage is a service that you can use to store files, messages, tables and other types of information. You can use Azure storage on its own—for example as a file share—but it is often used by developers as a store for working data. Such stores can be used by websites, mobile apps, desktop applications, and many other types of custom solution.
Azure storage is also used by IaaS virtual machines, and PaaS cloud services. Storage Accounts In order to use Azure Storage, you begin by creating a storage account. You can create many storage accounts within a single Azure subscription.
Storage Accounts
In order to use Azure Storage, you begin by creating a storage account. You can create many
storage accounts within a single Azure subscription.
Each storage account can contain up to 500 TB of data. For each storage account, you must specify:
- A URL. This defines the URLs at which the storage account can be accessed by clients. All storage accounts are within the core.windows.net domain. The full URL, depends on the type of storage you want to use. For example, if you specify the URL “mystorageaccount”, you can access BLOB storage at http://mystorageaccount.blob.core.windows.net.
- A Location or Affinity Group. This assigns the primary data center where your storage account maintains data. Choose a location close to the location where you expect most users.
- A Replication Option. In order to ensure resilience and availability, Azure automatically replicates your data to multiple physical servers. You can choose one of four replication schemes:
- Locally Redundant. Your data is replicated synchronously, so that there are three copies within a single facility in a single region. Locally Redundant Storage (LRS) protects your data against server hardware failures but not against the failure of the facility itself.
- Zone Redundant. Your data is replicated synchronously, so that there are three copies across two or three facilities in a single region. Zone Redundant Storage (ZRS) is more redundant that LRS but does not protect against failures that affecta while region. ZRS is only available for BLOB storage.
- Geo-Redundant. Your data is replicated asynchronously, with three copies of the data in the
primary region, and three copies of the data stored in a secondary region. If there is failure at the primary region, Azure Storage will failover to the secondary region. Geo-Redundant Storage (GRS) is the most resilient of the replication schemes. - Read-Access Geo-Redundant. As with GRS, your data is replicated asynchronously across two regions. However, with read-access GRS, the three copies in the secondary region are enabled for read-only access to the data, if the primary region is unavailable.
Storage Types
Each storage account can contain the following types of storage. You can use more than one of these types in the same storage account:
- BLOB Storage. Binary Large Objects (BLOBs) can be any type of file or binary data. This can include documents, images, videos, backup files, configuration files, and data logs. You can create any number of containers within a single storage account. Within each container, you can store any number of blobs up to the 500 TB limit.
- Table Storage. You can use tables to store data without specifying a schema as you would in a database. This schema-less designmakes it easy for developers to adapt a table to changing requirements. Developers can use table storage as the back-end data store for websites, mobile apps, PaaS cloud services, and other types of solution.
- Queue Storage. When developers architect distributed applications, they need a method by which components of the application can reliably communicate asynchronously. One popular method is to use a queue: a source component sends a message by placing it into a queue. The destination component works though the messages in the queue one at a time. You can use Azure Queue Storage to provide such a message queue with all the redundancy and reliability provided by Azure Storage.
- File Storage. Azure file storage enables you to create an SMB file share. Client computers can browse this share or map a network drive to the share as they might access a file share on an on-premises Windows file and print server.
For more information on performance and costs of the different Azure storage options, see:
Best Practices for Performance in Azure Applications
http://go.microsoft.com/fwlink/?LinkID=522638
Azure Site Recovery
Azure Site Recovery is a service you can use to orchestrate protection for on-premises virtual machines that run on Hyper-V®. The Hyper-V host servers can be part of a System Center Virtual Machine Manager (VMM) cloud, but this is not a requirement. The Azure Site Recovery Manager replicates the protected virtual server and ensures that, in the event of a failure, services are smoothly failed over to the replicated virtual server. The replicated virtual server can be located: On Premises. In this configuration, the Site Recovery Manager replicates the virtual server to second VMM cloud in another physical location from the source.
In Azure. In this configuration, the Site Recovery Manager replicates the virtual server to an Azure virtual machine.
For more information about Azure Site Recovery, see:Plan for Azure Site Recovery Deployment http://go.microsoft.com/fwlink/?LinkID=522639
Azure Backup
The Azure Backup service is designed to enable you to use Azure as a backup medium to replace physical media such as tapes, hard drives, and DVDs. To use Azure Backup to protect your data, you must:
1. Create a backup vault in Azure. A vault is a virtual location to which data will be backed up. You should create the vault in an Azure region close to the physical location of the data.
2. Download the vault credential. The Azure Backup Agent uses the vault credential to authenticate with Azure when it starts a backup operation.
3. Download and install the Azure Backup Agent. Choose the correct backup agent for your backup tool. There are separate downloads for System Center Data Protection Manager and for Windows Server Essentials.
4. Use Windows Server Backup to configure and schedule backups. Once the agent is installed and configured, Azure appears as a data destination within the Windows Server Backup MMC snap-in,and there is a separate Azure Backup management console available on the Start menu. You can also use PowerShell to configure and initiate backup operations.
For more information about Azure Backup, see:Backup
http://go.microsoft.com/fwlink/?LinkID=522640
This concludes this post by David Papkin about Planning and Implementing Storage using Microsoft Azure Storage Service