Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
276 views

Best Practices For Running SQL Server in Windows Azure Virtual Machine - TechNet

This document provides best practices for running SQL Server in Windows Azure Virtual Machines. It recommends starting with small workloads for testing and outlines considerations for virtual machine provisioning, security, storage, high availability, and using a SQL Server VM in Azure for disaster recovery of an on-premises SQL Server.

Uploaded by

Alexander Tarasul
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
276 views

Best Practices For Running SQL Server in Windows Azure Virtual Machine - TechNet

This document provides best practices for running SQL Server in Windows Azure Virtual Machines. It recommends starting with small workloads for testing and outlines considerations for virtual machine provisioning, security, storage, high availability, and using a SQL Server VM in Azure for disaster recovery of an on-premises SQL Server.

Uploaded by

Alexander Tarasul
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

1/15/13

Best Practices for Running SQL Server in Windows Azure Virtual Machine - TechNet Articles - United

Best Practices for Running SQL Server in Windows Azure Virtual Machine
We'll use this wiki to communicate best practices you should consider when provisioning and deploying SQL Server in a Windows Azure Virtual Machine.

Table of Contents
Identifying SQL Server Workloads for Testing Virtual Machine Provisioning and Connectivity Virtual Machine Security Reccomendations Storage Recommendations Database Recommendations High Availability Recommendations Disaster Recovery for an on-premise SQL Server using a SQL Server VM in Windows Azure

Identifying SQL Server Workloads for Testing


Windows Azure Virtual Machine was designed to support a broad range of SQL Server workloads. As with any preview, you should start testing small workloads first and measure throughput and performance. Move on to test more demanding workloads as you gain confidence in the performance, reliability and availability of the service. Consider these guidelines when evaluating wich workloads to test. Run some performance tests (seePredeployment I/O Best Practices ) to help you compare baseline performance of virtual machines running in Windows Azure Virtual Machine to other platforms. Dev/Test Workloads: Infrastructure-as-a-Service is ideal for developing and testing applications regardless of where they will eventully be deployed. You can quickly provision developer machines, test servers and other resources without having to procure hardware on-premise. This is a great way of getting familiar with Windows Azure Virtual Machine independent of your decision to migrate applications there. OLTP: Start with small or medium OLTP workloads frist. Move on to more demainding OLTP workloads later as you gain confidence. Data Warehousing: Start with small data marts first (1 TB or smaller). Move on to bigger data warehousing workloads later as you gain confidence. Make sure you plan for the extra latency required to load data into a VM hosted in the public cloud.

Virtual Machine Provisioning and Connectivity


Consider setting the time zone on your VM to UTC. The host environment runs in UTC as well and synchronizing the time zone may avoid some daylight savings related issues. Adjust to the local time zone on client's only. Create a TCP endpoint for the virtual machine Open TCP ports in the Windows firewall Configure SQL Server to listen on the TCP protocol Configure SQL Server for mixed mode authentication Create SQL Server authentication logins Virtual machines must be on the same virtual network in order to communicate with each other regardless of how you configure affinity groups. Do not use Quick Create for virtual machines that will need to communicate with other virtual machines on a virtual network. Use the From Gallery... option instead. Choose the right VM size for the SQL Server edition you intend to use. See Running SQL Server in Windows Azure Virtual Machine - Performance Guidelines for Preview for more details.

Virtual Machine Security Reccomendations


Big thanks to Sandino Di Mattia for writing these up! Establish a local administrator account that is not 'administrator' Use a complex strong password for your new administrator account Change the default port (3389) for RDP Remove the RDP endpoint if you aren't using it Consider administering your VM's via Windows Azure Virtual Network instead of a public RDP ports.

Storage Recommendations
Do not use write caching. Note that by default the write cache is turned on for new OS disks, and it is turned off for new data disks. If you are using a SQL Server gallery image and keeping data on the OS drive, it is recommended that the OS disk write cache is turned off. If you are using a stock image, avoid using OS drive for large databases. Instead, add an additional virtual drive and store your databases there. Remember to re-configure the default database, log and backup directories in management studio to point to your new drive. Consider putting database and transaction log files on separate drives. Consider putting tempdb on the non-persistent cache disk (see the community contribution Change TEMPDB to Temporary Drive on Azure SQL IaaS for one person's approach.

microsoft.com//11578.best-practices-for-running-sql-server-in-windows-azure-virtual-machine.a

1/2

1/15/13

Best Practices for Running SQL Server in Windows Azure Virtual Machine - TechNet Articles - United

Database Recommendations
Consider using database page compression to reduce I/O. Speeding up restores of large databases (by skipping the zeroing process for data files) Determine the windows account under which SQL service runs Grant the windows account the "Perform Volume Maintenance Tasks" right Restart SQL service The next restore process should skip the zeroing of database files.

High Availability Recommendations


A SQL Server VM can become unavailable due to a failure of the Windows Azure host (which healing takes ~12 min), its patching (which with a restart takes ~15 min), or your patching of the VM. You can make one or more databases higly available by adding them to an an AlwaysOn Availability Group with one or more secondary replicas on other SQL Server VMs When provisioning these VMs (through Portal, Powershell, or REST API), ensure that they are in: Same Affinity Group - This causes the VMs to be in the same Windows Azure cluster, thus reducing intercommunication latency between the replicas Same Availability Set - This causes the VMs to be in different failure domains (i.e. different racks) and different upgrade domains (logical upgrade groups used by Windows Azure). This ensures that a host failure or WA upgrade impacts at most one of the replicas at the same time Same VNet - This causes the VM IPs to remain the same in case of a host failure, thus avoiding the time to update the DNS with a new VM IP (~12 min). Currently, the VNet must exist before the VM (how to create a VNet ) After, ensure that they are in: Same Windows domain - Requirement for Availability Groups. This involves joining the VMs to a domain (either on-prem or configured in Windows Azure ) Same Windows cluster - Requirement for Availability Groups. This involves joining the VMs to the same Windows cluster. Windows Azure VMs don't support Virtual IPs, thus, the creation of a cluster will fail when trying to bring up the Cluster Network Name. It's possible to work around this by assigning a fake IP to it temporarily (configuring Windows Cluster on Windows Azure VMs). When creating the Windows cluster add 3 members to the cluster: VM hosting primary, VM hosting secondary, and either another VM or a witness file share (potentially in the Active Directory Domain Controller of your domain. The configuration of an Availability Group is as on-premise (how to create an Availability Group ) Configure one of the replicas as Availability Mode = Synchronous - To ensure no data loss after failover Failover Mode = Automatic - To ensure that it automatically becomes the primary if the current primary becomes unavailable Application connectivity: Currently, Availability Group Listeners (virtual network names) are not supported. Applications can still connect to the primary replica out of 2 replicas only (1 primary and 1 secondary), and reconnect to it after failover specifying a failover partner in their connection string (same approach used by Database Mirroring) Notice that applications can connect to and run read workloads on secondary replicas marked as readable .

Disaster Recovery for an on-premise SQL Server using a SQL Server VM in Windows Azure
A SQL Server VM in Windows Azure can be added as a replica to an on-premise AlwaysOn Availability Group . This enables a disaster recovery solution for an onpremise SQL Server. If the on-premise SQL Server fails, you can failover the Availability Group to the SQL Server VM replica. In addition, you can configure the SQL Server
VM as readable, to offload read workloads and backups. The steps involved are:

1. Configure a virtual network for connectivity between on-premise and Windows Azure (how to create VNet for cross-premise connectivity

2. Join a WA VM to the on-premise (Active Directory) Windows Domain (how to join computer to a domain ) 3. Install the Windows Server Failover Clustering (WSFC) feature in the VM (how to install WSFC ) 4. Add the VM as a node of an existing on-premise Windows Server Failover Cluster, or create a new cluster adding it (how to create a failover cluster or add a node ) 5. Remove the cluster quorum vote from the VM so that it doesn't impact the quorum of the on-premise cluster (how to configure cluster quorum votes ) 6. If you have an existing Listener, you'll need to add a static IP address from the Windows Azure subnet to the listener (how to configure a listener ) 7. Add the SQL Server VM as a secondary replica of an existing Availability Group, or create a new Availability Group adding it (how to create an availability group or how to add a replica to an availability group ). As part of this, configure the secondary replica as Availability Mode = Asynchronous - To ensure no impact to primary replica's throughput Failover Mode = Manual (Only failover mode supported for asynchronous availability mode) Allow Connections = All (to make the replica readable) Please note the following caveats with regards to application connectivity: Currently, Availability Group Listeners (virtual network names) are not supported on Windows Azure VMs. Specifically, the listener can't be bound to a Windows Azure VM. Applications can still connect to the primary replica out of 2 replicas only (1 primary and 1 secondary), and reconnect to it after failover specifying a failover partner in their connection string (same approach used by Database Mirroring). Notice that applications can connect to and run read workloads on secondary replicas marked as readable . Return to SQL Server in Windows Azure Virtual Machine Early Adoption Cook Book (en-US)

). Notice that this requires configuring an on-premise VPN device today. VPN software solutions (e.g. TMG 2010) are not officially supported today (though some people have used them successfully. Windows 8 Remote Access will be supported in the future.

microsoft.com//11578.best-practices-for-running-sql-server-in-windows-azure-virtual-machine.a

2/2

You might also like