The easiest way to do that is to run the SQL Setup as shown below.
SQL Server must be uninstalled from each of these instances before we can install the cluster instance. However, they are installed as standalone SQL Server instances, not clustered instances. Uninstall SQL Server 2008 R2Įach of the two SQL Server instances provisioned already have SQL Server 2008 R2 installed on them. In my lab environment my FSW is also my domain controller. It can in fact be used for other purposes. It’s only purpose is to host a simple file share. This instance does not need to be the same size, nor does it require any additional disks to be attached. This instance will host the file share witness required by WSFC.
This instances does not require SQL Server, it can be a simple Windows Server as all it needs to do is host a simple file share. By placing it in the same Availability Set you ensure that each cluster node and the FSW reside in different Fault Domains, ensuring your cluster stays on line should an entire Fault Domain go off line. In order for the Windows Server Failover Cluster (WSFC) to work optimally you are required to create another Windows Server instance and place it in the same Availability Set as the SQL Server instances. Create a File Share Witness (FSW) Instance Create the 2nd SQL Server Instance in Azureįollow the same steps as above, except be sure to place this instance in the same virtual network and Availability Set that you created with the 1st instance. Make sure that your virtual network is configured to set the DNS server to be a local Windows AD controller to ensure you will be able to join the domain in a later step. This is required for SIOS DataKeeper and is best practice for clustered instances.
Once the instance is created, go in to the IP configurations and make the Private IP address static. If you don’t already have a virtual network configured, allow the creation wizard to create a new one for you. Refer to Performance guidelines for SQL Server in Azure Virtual Machines for additional information on storage best practices. Enable read-only caching on the disk used for the SQL data files. Disable caching on the disks used for the SQL log files. This allows the two cluster nodes and the file share witness each to reside in their own Fault Domain.Īdd additional disks to each instance. During this process be sure to increase the number of Fault Domains to 3.
When you provision the first instance you will have to create a new Availability Set. This guide will leverage the SQL Server 2008R2SP3 on Windows Server 2008R2 image that is published in the Azure Marketplace. Create the first SQL Server Instance in Azure SIOS DataKeeper will be used in place of the shared storage normally required to create a SQL Server 2008 R2 FCI. Although SIOS DataKeeper also supports clusters that span Availability Zones or Regions, this guide assumes each node resides in the same Azure Region, but different Fault Domains. This guide will walk through the process of creating a two-node SQL Server 2008 R2 Failover Cluster Instance (FCI) in Azure, running on Windows Server 2008 R2.
SIOS DataKeeper not only supports SQL Server 2008 R2 and Windows Server 2008 R2 as documented in this guide, it supports any version of Windows Server, from 2008 R2 through Windows Server 2019 and any version of SQL Server from from SQL Server 2008 through SQL Server 2019. DataKeeper overcomes Azure’s lack of shared storage and allows you to build a SQL Server FCI in Azure that leverages the locally attached storage on each instance. In order to mitigate the possibility of downtime and qualify for Azure’s 99.95% or 99.99% SLA, you have to leverage SIOS DataKeeper. Downtime in Azure is a very real possibility that you must take steps to mitigate. When moving to Azure, none of those options are available. On premises you may be running a SQL Server Failover Cluster (FCI) instance for high availability, or possibly you are running SQL Server in a virtual machine and are relying on VMware HA or a Hyper-V cluster for availability.
One of the challenges you will face when running SQL Server 2008/2008 R2 in Azure is ensuring high availability. An unpatched instance of SQL Server could lead to data loss, downtime or a devastating data breach.
If you are currently running SQL Server 2008/2008 R2 and you are unable to update to a later version of SQL Server before the July 9th deadline, you will want to take advantage of this offer rather than running the risk of facing a future security vulnerability. However, if you move those SQL Server instances to Azure, Microsoft will give you three years of Extended Security Updates at no additional charge. That means the end of regular security updates. On July 9, 2019, support for SQL Server 20 R2 will end.