This presentation is for those of you who are interested in moving your on-prem SQL Server databases and servers to Azure virtual machines (VM’s) in the cloud so you can take advantage of all the benefits of being in the cloud. This is commonly referred to as a “lift and shift” as part of an Infrastructure-as-a-service (IaaS) solution. I will discuss the various Azure VM sizes and options, migration strategies, storage options, high availability (HA) and disaster recovery (DR) solutions, and best practices.
2. About Me
Microsoft, Big Data Evangelist
In IT for 30 years, worked on many BI and DW projects
Worked as desktop/web/database developer, DBA, BI and DW architect and developer, MDM
architect, PDW/APS developer
Been perm employee, contractor, consultant, business owner
Presenter at PASS Business Analytics Conference, PASS Summit, Enterprise Data World conference
Certifications: MCSE: Data Platform, Business Intelligence; MS: Architecting Microsoft Azure
Solutions, Design and Implement Big Data Analytics Solutions, Design and Implement Cloud Data
Platform Solutions
Blog at JamesSerra.com
Former SQL Server MVP
Author of book “Reporting with Microsoft SQL Server 2012”
3. Agenda
Azure VMs
Migrating data
Scaling VMs
SQL Server VM features
VM storage
HA/DR architectures
Best practices
4. Who manages what?
Infrastructure
as a Service
Storage
Servers
Networking
O/S
Middleware
Virtualization
Data
Applications
Runtime
ManagedbyMicrosoft
Youscale,make
resilient&manage
Platform
as a Service
Scale,Resilienceand
managementbyMicrosoft
Youmanage
Storage
Servers
Networking
O/S
Middleware
Virtualization
Applications
Runtime
Data
On Premises
Physical / Virtual
Youscale,makeresilientandmanage
Storage
Servers
Networking
O/S
Middleware
Virtualization
Data
Applications
Runtime
Software
as a Service
Storage
Servers
Networking
O/S
Middleware
Virtualization
Applications
Runtime
Data
Scale,Resilienceand
managementbyMicrosoft
Windows Azure
Virtual Machines
Windows Azure
Cloud Services
6. VM hosted on Microsoft Azure Infrastructure (“IaaS”)
• From Microsoft images (gallery) or your own images (custom)
SQL 2008R2 / 2012 / 2014 / 2016 Web / Standard / Enterprise
Images refreshed with latest version, SP, CU
• Fast provisioning (~10 minutes).
• Accessible via RDP and Powershell
•
Pay per use
• Per minute (only when running)
• Cost depends on size and licensing
• EA customers can use existing SQL licenses (BYOL)
• Network: only outgoing (not incoming)
• Storage: only used (not allocated)
Elasticity
• 1 core / 2 GB mem / 1 TB 32 cores / 448 GB mem / 64 TB
7. Windows Azure virtual machine tiers
Basic Standard
A0 – A4
1 – 8 CPU cores
768 MB – 14 GB RAM
Max 16 datadisks w/300 IOPS per disk
For dev/test workloads or applications
that don’t require load-balancing,
auto-scaling, or memory-intensive
VM’s.
G series (G1 – G5)
2 – 32 CPU cores
28 GB – 448 GB RAM
Up to 64 datadisks with 500 IOPS/disk
GS Series (GS1 – GS5)
2 – 32 CPU cores
28 GB – 448 GB RAM
Up to 64 datadisks with 5000 – 80000 IOPS/disk
F Series
Web/Application servers
H Series
Modeling/Simulation servers
N Series
Graphics workloadshttps://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/
A0 – A11
1 – 16 CPU cores
768 MB – 112 GB RAM
Max 16 datadisks with 500 IOPS/disk
D1 – D14 & D1_v2 – D15_v2
1 – 20 CPU cores
768 MB – 140 GB RAM
Max 16 datadisks with 500 IOPS/disk
DS1 – DS14
Up to 50,000 IOPS
32 – 512 MB second
9.
DS-Series: Same CPU and memory as D-Series. Support Premium Storage (good for Data, Log, and TempDB!!)
GS-Series: Fastest CPU, most memory. Support Premium Storage
Azure calculator: https://azure.microsoft.com/en-us/pricing/calculator/
15. Hyper scale Infrastructure is the enabler
34 Regions Worldwide, 30 Generally Available…
100+ datacenters
Top 3 networks in the world
2.5x AWS, 7x Google DC Regions
G Series – Largest VM in World, 32 cores, 448GB Ram, SSD…
Operational
Announced/Not Operational
Central US
Iowa
West US
California
East US
Virginia
US Gov
Virginia
North Central US
Illinois
US Gov
Iowa
South Central US
Texas
Brazil South
Sao Paulo State
West Europe
Netherlands
China North *
Beijing
China South *
Shanghai
Japan East
Tokyo, Saitama
Japan West
Osaka
India South
Chennai
East Asia
Hong Kong
SE Asia
Singapore
Australia South East
Victoria
Australia East
New South Wales
India Central
Pune
Canada East
Quebec City
Canada Central
Toronto
India West
Mumbai
Germany North East **
Magdeburg
Germany Central **
Frankfurt
North Europe
Ireland
East US 2
Virginia
United Kingdom
Regions (south
& west)
US DoD East
TBD
US DoD West
TBD
* Operated by 21Vianet ** Data Stewardship by Deutsche Telekom
Korea
(Seoul &
South)
West US 2
West
Central US
16. Migrating Data
Migrate from on-prem SQL server to Azure VM IaaS:
• Use the Deploy a SQL Server Database to a Microsoft Azure VM wizard. Recommended method for migrating an on-premises user database
when the compressed database backup file is less than 1 TB. Use on SQL Server 2005 or greater to SQL Server 2014 or greater
• Perform on-premises backup using compression and manually copy the backup file into the Azure virtual machine and then do a restore (only if
you cannot use the above wizard or the database backup size is larger than 1 TB). Use on SQL Server 2005 or greater to SQL Server 2005 or
greater
• Perform a backup to URL and restore into the Azure virtual machine from the URL. Use on SQL Server 2012 SP1 CU2 or greater to SQL Server
2012 SP1 CU2 or greater
• Detach and then copy the data and log files to Azure blob storage and then attach to SQL Server in Azure VM from URL. Use on SQL Server
2005 or greater to SQL Server 2014 or greater
• Convert on-premises physical machine to Hyper-V VHD, upload to Azure Blob storage, and then deploy as new VM using uploaded VHD. Use
when bringing your own SQL Server license, when migrating a database that you will run on an older version of SQL Server, or when migrating
system and user databases together as part of the migration of database dependent on other user databases and/or system databases. Use on
SQL Server 2005 or greater to SQL Server 2005 or greater
• Ship hard drive using Windows Import/Export Service. Use when manual copy method is too slow, such as with very large databases. Use on SQL
Server 2005 or greater to SQL Server 2005 or greater
• If you have an AlwaysOn deployment on-premises and want to minimize downtime, use the Add Azure Replica Wizard to create a replica in Azure
and then failover, pointing users to the Azure database instance. Use on SQL Server 2012 or greater to SQL Server 2012 or greater
• If you do not have an AlwaysOn deployment on-premises and want to minimize downtime, use SQL Server transactional replication to configure
the Azure SQL Server instance as a subscriber and then disable replication, pointing users to the Azure database instance. Use on SQL Server
2005 or greater to SQL Server 2005 or greater
• Others: data-tier application, transact-SQL scripts, sql server import and export wizard, SSIS, copy database wizard
19. Automated Patching
• Predictable solution for patching (Windows & SQL)
• Simple: just specify a time window
• Uses SQL Agent Extension and MS Update
• Portal and Powershell
• It relies on the Windows Update and the Microsoft
Update infrastructure and installs any update that
matches the ‘Important’ category for the machine
20. Automated Backup
• For all DBs in the SQL instance
• Simple: just specify a retention period
• Supports Compression and Encryption
• Portal and Powershell
• Full database and transaction log backups
• Configure at database level or SQL Server instance level
In SQL Server 2016:
• Full, bulk-logged and simple recovery models are all
supported
• System databases can be configured for backups
• Backup striping can be used to support backup sizes of up to
12 TB
• Customer backup schedules can be specified to ensure your
backups are created when it is best for your workload
22. Connecting to Azure VMs
Virtual Network
VPN
GW
Frontend
10.1/16
Mid-tier
10.2/16
Backend
10.3/16
Internet
On Premises
10.0/16
VPN &
ExpressRoute
Azure
Direct Internet
Connectivity
Virtual Machine networking
• Create subnets with private or public IP addresses
• Bring your own DNS or use Azure-provided DNS
• Secure with Network Security Groups ACLs
• Control traffic with user-defined routes
23. Connectivity options and hybrid offerings
Secure site-to-site
VPN connectivity
• SMB, Enterprises
• Connect to Azure compute
Secure point-to-site
connectivity
• Developers
• POC Efforts
• Small scale deployments
• Connect from anywhere
ExpressRoute private
connectivity
• SMB, Enterprises
• Mission critical workloads
• Backup/DR, media, HPC
• Connect to Microsoft services
Internet connectivity
• Consumers
• Access over public IP
• DNS resolution
• Connect from anywhere
24. Virtual Machine storage architecture
C:
OS disk (127 GB)
Usually 115 GB free
E:, F:, etc.
Data disks (1 TB)
Attach SSD/HDD up to 1TB. These
are .vhd files
D:
Temporary disk
(Contents can be lost)
SSD/HDD and size depends on VM
chosenDisk Cache
25. Azure Default Blob Storage
Azure Storage Page Blobs, 3 copies
Storage high durability built-in (like have RAID)
VHD disks, up to 1 TB per disk (64 TB total)
26. Geo-storage replication
3 copies locally, another 3 copies in different region
Disable for SQL Server VM disk (consistent write
order across multiple disks is not guaranteed).
Instead use DR techniques in this deck
Defend against regional disasters
Geo replication
29. HA/DR deployment architectures
Azure Only
Availability replicas
running across
multiple datacenters
in Azure VMs for
disaster recovery.
Cross-region solution
protects against
complete site outage.
Hybrid
Some availability
replicas running in
Azure VMs and other
replicas running on-
premises for cross-
site disaster recovery.
HA only, not DR
FCI on a two-node
WSFC running in
Azure VMs with
storage supported by
a third-party
clustering solution.
FCI on a two-node
WSFC running in
Azure VMs with
remote iSCSI Target
shared block storage
via ExpressRoute.
Azure Only
Principal and mirror
and servers running
in different
datacenters for
disaster recovery.
Principal, Mirror, and
Witness run within
same Azure data
center, deployed
using a DC or server
certificates for HA.
Hybrid
One partner running
in an Azure VM and
the other running on-
premises for cross-
site disaster recovery
using server
certificates.
For DR only /
Hybrid only
One server running in
an Azure VM and the
other running on-
premises for cross-
site disaster recovery.
Log shipping
depends on Windows
file sharing, so a VPN
connection between
the Azure virtual
network and the on-
premises network is
required.
Requires AD
deployment on DR
site.
On-prem or Azure
production databases
backed up directly to
Azure blob storage
for disaster recovery.
SQL 2016: Backup to
Azure with file
snapshots
Simpler BCDR story
Site Recovery makes
it easy to handle
replication, failover
and recovery for your
on-premises
workloads and
applications (not
data!).
Flexible replication
You can replicate on-
premises servers,
Hyper-V virtual
machines, and
VMware virtual
machines.
Eliminate the need
for secondary
Native support for
SQL Server data files
stored as Azure blobs
30. RPO/RTO
RTO – Recover Time Objective. How much time after a failure until we have to be up
and running again?
RPO – Recover Point Objective. How much data can we lose?
• HA – High Availability
• RTO: seconds to minutes
• RPO: Zero to seconds
• Automatic failover
• Well tested (maybe with each patch or release)
• DR – Disaster Recovery
• RTO: minutes to hours
• RPO: seconds to minutes
• Manual failover into prepared environment
• Tested from time to time
How long does it take to fail over:
• Backup-Restore: Hours
• Log Shipping: Minutes
• AlwaysOn FCI: Seconds to minutes
• AlwaysOn AG/Mirroring: Seconds
31. AlwaysOn Availability Groups
Azure Only
Availability replicas
running across
multiple datacenters
in Azure VMs for
disaster recovery.
Cross-region solution
protects against
complete site outage.
Hybrid
Some availability
replicas running in
Azure VMs and other
replicas running on-
premises for cross-
site disaster recovery.
Availability replicas running across multiple datacenters in Azure
VMs for disaster recovery. This cross-region solution protects
against complete site outage.
Within a region, all replicas should be within the same cloud
service and the same VNet. Because each region will have a
separate VNet, these solutions require VNet to VNet connectivity.
For more information, see Configure a Site-to-Site VPN in the
Azure classic portal.
All availability replicas running in Azure VMs for high
availability within the same region. You need to configure a
domain controller VM, because Windows Server Failover
Clustering (WSFC) requires an Active Directory domain.
For more information, see Configure AlwaysOn Availability
Groups in Azure (GUI).
32. AlwaysOn between Azure Regions
• Configure AlwaysOn between VMs in different geographic regions (asynchronous)
• Over secure tunnel
• Manual Failover (~15 seconds) in case of a regional failure
• Test it at any time
• Use closest secondary for read workloads
• Region 1: AG used instead
of FCI (synchronous)
33. AlwaysOn Failover Cluster Instances (FCI)
An FCI on a two-node WSFC running in Azure VMs with remote
iSCSI Target shared block storage via ExpressRoute. For example,
NetApp Private Storage (NPS) exposes an iSCSI target via
ExpressRoute with Equinix to Azure VMs.
For third-party shared storage and data replication solutions, you
should contact the vendor for any issues related to accessing data
on failover.
Note that using FCI on top of Azure File storage is not supported
yet, because this solution does not utilize Premium Storage. We
are working to support this soon.
HA only, not DR
FCI on a two-node
WSFC running in
Azure VMs with
storage supported by
a third-party
clustering solution.
FCI on a two-node
WSFC running in
Azure VMs with
remote iSCSI Target
shared block storage
via ExpressRoute.
You can use FCI to
host an availability
replica for an
availability group
FCI on a two-node WSFC running in Azure
VMs with storage supported by a third-party
clustering solution.
35. Database Mirroring
Azure Only
Principal and mirror
and servers running
in different
datacenters for
disaster recovery.
Principal, Mirror, and
Witness run within
same Azure data
center, deployed
using a DC or server
certificates for HA.
Hybrid
One partner running
in an Azure VM and
the other running
on-premises for
cross-site disaster
recovery using server
certificates.
Principal and mirror and servers running in
different datacenters for disaster recovery. You
must deploy using server certificates because an
Active Directory domain cannot span multiple
datacenters.
Principal, mirror, and witness servers all running in the
same Azure datacenter for high availability. You can
deploy using a domain controller.
You can also deploy the same database mirroring configuration
without a domain controller by using server certificates instead.
36. Block blobs
Reduced storage costs
Significantly improved
restore performance
More granular control
over Azure Storage
Azure Storage snapshot
backup
Fastest method for creating
backups and running restores
Support of SQL Server database
files on Azure Blob Storage
Backup to Azure
Managed backup
On-prem to Azure
Granular control of the backup
schedule
Local staging for faster recovery and
greater network resiliency
System database support
Simple recovery mode support
On-prem or Azure
production databases
backed up directly to
Azure blob storage
for disaster recovery.
SQL 2016: Backup to
Azure with file
snapshots
Production databases backed up directly to blob storage
in a different datacenter for disaster recovery
On-premises production databases backed up directly
to Azure blob storage for disaster recovery.
37. SQL Server in Azure VM Best Practices
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-performance-best-practices/
This presentation is for those of you who are interested in moving your on-prem SQL Server databases and servers to Azure virtual machines (VM’s) in the cloud so you can take advantage of all the benefits of being in the cloud. This is commonly referred to as a “lift and shift” as part of an Infrastructure-as-a-service (IaaS) solution. I will discuss the various Azure VM sizes and options, migration strategies, storage options, high availability (HA) and disaster recovery (DR) solutions, and best practices.
This deck can also be updated for a presentation “Hybrid cloud: Improve your on-prem SQL Server 2016 databases with Azure”.
This presentation will discuss hybrid cloud scenarios where you can use the Azure cloud to supplement your on-prem SQL Server 2016 databases. There are now many options for high availability and disaster recovery. I will cover features such as AlwaysOn AG, StretchDB, Azure SQL Data Sync, Log Shipping, SQL Server data files in Azure, Mirroring, Azure Site Recovery, and Azure Backup.
This deck can also be used for a “HA/DR options with SQL Server on-prem and in Azure”
Fluff, but point is I bring real work experience to the session
Note the IOPS for standard storage is the maximum rather than an expected number. For premium, IOPS are not just maximum but expected levels of performance.
Standard Disk Storage (HDD)
1GB-1023GB, 500 IOPs, 60 MB/s throughput, $2/month per 100GB (locally redundant), $5/month per 100GB (geo-redundant), $6/month per 100GB (read-access geo-redundant)
Premium Disk Storage (SSD)
P10, 128GB, 500 IOPs, 100 MB/s throughput, $20/month
P20, 512GB, 2300 IOPs, 150 MB/s throughput, $73/month
P30, 1024GB, 5000 IOPs, 200 MB/s throughput, $135/month
In the past, after provisioning a SQL Server VM, you had to manually attach and configure the right number of data disks to provide the desired number of IOPs or throughput (MB/s). Then you need to stripe your SQL files across the disks or create a Storage Pool to divide the IOPs or throughput across them. Finally, you’d have to configure SQL Server according to the performance best practices for Azure VM.
We’ve now made this part of the provisioning experience. You can easily configure the desired IOPs, throughput, and storage size within the limits of the selected VM size, as well as the target workload to optimize for (online transaction processing or data warehousing). As you change the IOPs, throughput, and storage size, we’ll automatically select the right number of disks to attach to the VM. During the VM provisioning, if more than one disk is required for your specified settings, we’ll automatically create one Windows storage space (virtual drive) across all disks.
https://azure.microsoft.com/en-us/regions/#services
The one exception for this is DSv2. This will be rolled out starting in the next few weeks. It will eventually be available in all regions that that have Dv2, but it may not be all regions at first. I’ll work with Jon to get the DSv2 size listed on the services by region site.
Migrating existing on-prem SQL Server applications to Microsoft Azure Virtual Machines is easier than even with the new migration wizard built right into SQL Server Management Studio that will help you size the appropriate VM and get your on-premise SQL Server. You also have more and more VM sizes becoming available on Microsoft Azure making migration easier. There are free tools to help you convert from non-virtualized state or if you are virtualized on a different solution to convert to Hyper-V. Once in Hyper-V VHD, you can choose to migrate the entire VHD or just the database to the Microsoft Azure VM.
As Trek, a manufacturer of high-performance bicycles realized, there many TCO advantages of leveraging cloud scale. In their case with distributors in 65 countries and 5000 retailers world wide, Microsoft Azure not only gave them broader reach for their Ascend retail management system software that retailers use to order parts and work orders, but also help them reduce operational IT costs by $15,000 a month over managing the infrastructure themselves. The best part was the learn curve was very low, as they are saying in the quote basically migrating SQL was easy.
http://www.microsoft.com/casestudies/Windows-Azure/Trek-Bicycle-Corporation/Bicycle-Firm-Moves-Retail-System-to-Cloud-Expects-to-Save-15-000-a-Month-in-IT-Costs/710000002640
Situation:
Trek designs, manufactures, and sells high-performance bicycles. Based in Waterloo, Wisconsin, the company employs 1,600 people and has distributors in 65 countries. A key component of Trek’s success is its commitment to its 5,000 independent bicycle retailers around the world.
To support its retailers, Trek offers Ascend, a retail management system that helps to manage inventory, place part orders, track work orders, and process customer purchases. The company wanted to move Ascend to a cloud-based system to reduce support costs and make it easier to maintain.
Solution:
The Ascend team considered cloud-computing solutions to meet its growing infrastructure and application modernization needs. After evaluating several solutions including Amazon, the Ascend team chose the Microsoft Azure platform and enlisted Skyline Technologies, a Microsoft partner with several gold and silver competencies, to help them with the migration.
Benefits:
With the new solution, Trek continues to improve its TCO by reducing the time and effort needed to support its Ascend infrastructure. Since the Ascend team moved its staging workloads to Microsoft Azure, Trek has saved US$5,000 each month in data-center hosting costs. When the production workloads have been migrated to Microsoft Azure, the company will be able to eliminate its data center operations and save $15,000 each month.
Microsoft Azure easily scales to meet increased workloads and a variety of deployment scenarios, offering much needed flexibility for Ascend. Trek no longer needs to wait 2–6 weeks to upgrade server capacity at its data center; by adding virtual machines in Microsoft Azure, Trek engineers can do the same job in just two hours.
The Ascend team also found that the learning curve associated with Microsoft Azure was small, similar to learning a new version of the .NET Framework or API. Existing development tools such as Microsoft Visual Studio just worked on Microsoft Azure, and the team could easily move applications to the cloud.
Develop and Test is another great scenarios where you have an opportunity to not only reduce costs, but also speed time to market as a SQL Server instance in a Microsoft Azure Virtual Machine can be provisioned in minutes verses in many cases days or weeks on premises depending on resource availability and hardware procurement policy. With Team Foundation Server availability in Microsoft Azure you can now have a consistent application lifecycle management policy from on-premises to Microsoft Azure as well as secure redundant source code.
In the case of Telenor group, one of the leading mobile operators in the world, they realized 70% savings in Dev/Test and had full dev/test environments readied in hours instead of weeks, without any resource constraints.
The best part is if the dev/test project is successful and ok’d for production you can choose to continue to run on Microsoft Azure or back on premises your choice, as you only pay for what you use. This not only reduces CAPEX, but also removes barriers to faster dev/test cycles, which can lead to faster innovation.
http://www.microsoft.com/casestudies/Windows-Azure/Telenor-Group/Telenor-Uses-Windows-Azure-Virtual-Machines-for-Fast-Efficient-Cost-saving-Development-and-Testing-of-company-wide-SharePoint-2013-Platform/710000002349
Telenor Uses Microsoft Azure Virtual Machines for Fast, Efficient, Cost-saving Development and Testing of company-wide SharePoint 2013 Platform
EasyJet is also a good dev & test case: http://www.microsoft.com/casestudies/Microsoft-Visual-Studio-Team-Foundation-Server-2010/easyJet/Airline-Aims-to-Save-Millions-Shorten-Airport-Waits-with-Cloud-Based-Mobile-Services/4000010767
https://azure.microsoft.com/en-us/blog/resize-virtual-machines
When a VM is running it is deployed to a physical server. The physical servers in Azure regions are grouped together in clusters of common physical hardware. A running VM can easily be resized to any VM size supported by the current cluster of hardware supporting the VM.
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-automated-patching/
For configuring these features for ARM SQL VMs, it can only be done at provisioning time. We are currently working on adding the ability to configure these features for existing SQL VMs. As for checking status, you can do this for existing VMs by checking the SQL IaaS Extension status. This can be found in Settings -> Extensions -> SqlVmIaasExtension. For now you must use PowerShell to modify settings.
Automated Backup relies on the SQL Server IaaS Agent. To install and configure the agent, you must have the Azure VM Agent running on the target virtual machine. Newer virtual machine gallery images have this option enabled by default, but the Azure VM Agent might be missing on existing VMs. If you are using your own VM image, you will also need to install the SQL Server IaaS Agent. For more information, see VM Agent and Extensions.
https://blogs.technet.microsoft.com/dataplatforminsider/2016/04/19/sql-server-2016-cloud-backup-and-restore-enhancements/
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-automated-backup/
https://msdn.microsoft.com/library/dn449496.aspx
For configuring these features for ARM SQL VMs, it can only be done at provisioning time. We are currently working on adding the ability to configure these features for existing SQL VMs. As for checking status, you can do this for existing VMs by checking the SQL IaaS Extension status. This can be found in Settings -> Extensions -> SqlVmIaasExtension. For now you must use PowerShell to modify settings.
Automated Backup relies on the SQL Server IaaS Agent. To install and configure the agent, you must have the Azure VM Agent running on the target virtual machine. Newer virtual machine gallery images have this option enabled by default, but the Azure VM Agent might be missing on existing VMs. If you are using your own VM image, you will also need to install the SQL Server IaaS Agent. For more information, see VM Agent and Extensions.
SQL Server Managed Backup to Windows Azure can be configured at the database level or at the SQL Server instance level. When configuring at the instance level, any new databases are also backed up automatically. Settings at the database level can be used to override instance level defaults on an individual case.
https://blogs.msdn.microsoft.com/mast/2013/12/06/understanding-the-temporary-drive-on-windows-azure-virtual-machines/
SSD/HDD storage included in A-series, D-series, and Dv2-series VMs is local temporary storage.
DS-series, G-series, GS-series SSD's have less local temporary storage due to storage used for caching purposes to ensure predictable levels of performance associated with premium storage.
DS-series and GS-series support premium storage disks, which means you can attach SSD's to the VM (the other series support only standard storage disks).
The pricing and billing meters for the DS sizes are the same as D-series and the GS sizes are the same as G-series.
When you create an Azure virtual machine, it has a disk for the operating system mapped to drive C (size is 127GB) that is on Blob storage and a local temporary disk mapped to drive D. You can choose standard disk type or premium (if DS-series or GS-series) for your local temporary disk - the size of which is based on the series you choose (i.e. A0 is 20GB). You can also attach new disks - specify standard or premium, for standard: specify size (1GB-1023GB), for premium: specify P10, P20, or P30. the disks are .vhd files that reside in an Azure storage account
http://www.jamesserra.com/archive/2015/11/redundancy-options-in-azure-blob-storage/
Geo-replication in Azure disks does not support the data file and log file of the same database to be stored on separate disks. GRS replicates changes on each disk independently and asynchronously. This mechanism guarantees the write order within a single disk on the geo-replicated copy, but not across geo-replicated copies of multiple disks. If you configure a database to store its data file and its log file on separate disks, the recovered disks after a disaster may contain a more up-to-date copy of the data file than the log file, which breaks the write-ahead log in SQL Server and the ACID properties of transactions. If you do not have the option to disable geo-replication on the storage account, you should keep all data and log files for a given database on the same disk. If you must use more than one disk due to the size of the database, you need to deploy one of the disaster recovery solutions listed above to ensure data redundancy. https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sql-high-availability-dr/
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-sql-dr/
It is up to you to ensure that your database system possesses the HADR capabilities that the service-level agreement (SLA) requires. The fact that Azure provides high availability mechanisms, such as service healing for cloud services and failure recovery detection for the Virtual Machines (https://azure.microsoft.com/en-us/blog/service-healing-auto-recovery-of-virtual-machines), does not itself guarantee you can meet the desired SLA. These mechanisms protect the high availability of the VMs but not the high availability of SQL Server running inside the VMs. It is possible for the SQL Server instance to fail while the VM is online and healthy. Moreover, even the high availability mechanisms provided by Azure allow for downtime of the VMs due to events such as recovery from software or hardware failures and operating system upgrades.
https://azure.microsoft.com/en-us/blog/high-availability-for-a-file-share-using-wsfc-ilb-and-3rd-party-software-sios-datakeeper/
Replaces SQL Server failover cluster
Requires shared storage, which becomes a single source of failure