I often help people automate the configuration of their infrastructure so they can build 3-node clusters that span Availability Zones and Regions. The CLI for creating a DataKeeper Job and associated mirrors that contain more than one target can be a little confusing, so I'm documenting it here in case you find yourself looking for this information. The DataKeeper documentation describes this as a Mirror with Multiple Targets.
The environment in this example looks like this:
PRIMARY (10.0.2.100) - in AZ1
SECONDARY (10.0.3.100) - in AZ2
DR (10.0.1.10) - in a different Region
I want to create a synchronous mirror from PRIMARY to SECONDARY and an asynchronous mirror from PRIMARY to DR. I also have to make sure the DataKeeper Job knows how to create a mirror from SECONDARY to DR in case the SECONDARY or DR server ever become the source of the mirror. EMCMD will be used to create this multiple target mirror.
We need to first create the Job that contains all this possible endpoints and define whether the mirror will be Sync (S) or Async (A) between those endpoints.
Changing a Drive Letter With PowerShell
Here is a short but sweet post on how to change the drive letter of a partition. Despite using my best Google skills I couldn't find an example that was doing it for me. I rolled up my sleeves and just figured it out on my own. I hope this helps someone out there.
Set-Partition -DiskNumber 4 -PartitionNumber 1 -NewDriveLetter X
As long as you know the DiskNumber and PartitionNumber this will immediately change the drive letter of the partition you specify.
On-Prem vs the Cloud: Comparing the Cost of Configuring for High Availability
Any way you look at it, configuring SQL Server for high availability involves the cost of redundant infrastructure. If you need your SQL Server data to be available 99.99% of the time and the infrastructure supporting your database goes offline — for whatever reason — you need backup infrastructure that can take over immediately.
But the costs of deploying a high availability infrastructure on-premises vs. in the cloud are very different and it’s important to understand those differences in order to achieve the high availability assurances you seek at the optimal cost to your organization.
Calculating Application Availability in the Cloud
When deploying business-critical applications in the cloud you want to make sure they are highly available. The good news is that if you plan properly, you can achieve 99.99% (4-nines) of availability or more. However, calculating your true availability may not be as straightforward as it seems.
When considering availability you must consider the key components that make access to your application possible, which I'll call the availability chain. Component of the availability chain are:
Step-by-Step: iSCSI Target Server Cluster in Azure
I recently helped someone build an iSCSI target server cluster in Azure and realized that I never wrote a step-by-step guide for that particular configuration. So to remedy that, here are the step-by-step instructions in case you need to do this yourself.
Prerequisites
I'm going to assume you are fairly familiar with Azure and Windows Server, so I'm going to spare you some of the details. Let's assume you have at least done the following as a pre-requisite
Ensuring SQL Server High Availability in the Cloud
Theoretically, the cloud seems tailor-made for ensuring high availability (HA) and disaster recovery (DR) solutions in mission critical SQL Server deployments. Azure, AWS, and Google have distributed, state-of-the-art data centers throughout the world. They offer a variety of SLAs that can guarantee virtual machine (VM) availability levels of 99.95% and higher.
But deploying SQL Server for HA or DR has always posed a challenge that goes beyond geographic dispersion of data centers and deep levels of hardware redundancy. Configuring your SQL Server for HA or DR involves building a Windows Server Failover Cluster (WSFC) that ensures not only the availability of different machines running SQL Server itself but also — and most importantly — the availability of storage holding the data in which SQL Server is interacting.
Configuring SQL Server for High Availability in the Cloud
Cloud service providers offer SLAs guaranteeing availability of 99.95% and higher. That number might prompt one to think the cloud ideally suited for a SQL Server deployment that requires high availability (HA). Given the geographic distribution of Azure and AWS data centers, one might even think the cloud perfect for a SQL Server deployment configured with disaster recovery (DR) in mind.
But let’s rethink this.
Moving SQL Server 2008/2008 R2 Databases to the Azure Cloud
Extended Support for SQL Server 2008 and 2008 R2 ended in July 2019, and Extended Support for Windows Server 2008 and 2008 R2 will end in January 2020. Upgrading the software to the latest versions is always an option, of course, but for a variety of reasons, that may not be viable or cost-effective for some legacy applications. Another option is to pay an additional fee to continue receiving Extended Security Update support for three more years. But for most organizations, the best option will be to get continued support for free by moving the databases to the Azure cloud.
This article highlights the considerations and challenges involved when migrating mission-critical SQL Server 2008/R2 databases to the Azure cloud and offers some useful suggestions to help avoid common pitfalls.
Achieving Application Consistent Recovery Points of SQL Server 2008 R2 With Azure Site Recovery in Azure
If you want to use ASR to replicate SQL Server 2008 R2 standalone or clustered instances, you will need to update the SQL Writer to 2012 or later.
You can use SQL express version as it is a free download.
New Azure ”SQL Server Settings” Blade in the Azure Portal
I just noticed today that there is a new blade in the Azure portal when creating a new SQL Server virtual machine. I've been looking for an announcement regarding this new Azure portal experience, but I haven't found one yet. This feature wasn't available when I took the screenshots for my last post on creating a SQL Server 2008 R2 FCI in Azure on April 19th, so it must be relatively new.
![New Azure "SQL Server Settings" blade on the Azure portal](https://lh3.googleusercontent.com/9m_YKKQ2JaTrPB-laGa7DWosmRmZ1LxNFGOjvqPU00u427BpNQHxu9RGEYU2XEWkLCKFEkp7b8Bk0Kx2neuSIYxLOYgqcdmYn1polVy0MgN9i3Li1wM_SWOhDhJfllZV2Wa5zOtu "New Azure "SQL Server Settings" blade on the Azure portal")
Most of the settings are pretty self-explanatory. Under Security and Networking, you can specify the port you want SQL to listen on. It also appears as if the Azure Security Group will be updated to allow different levels of access to the SQL instance: Local, Private, or Public. Authentication options are also exposed in this new SQL Server settings blade.
Storage Considerations for Running SQL Server in Azure
If you are deploying SQL Server in Azure or any Cloud platform for that matter, instead of just provisioning storage like you did for your on-premises deployments for many years, you may consider that storage in Azure isn't exactly like the storage you may have had access to on-premises. Some traditional "best practices" may wind up costing you additional money and give you less than optimal performance, all while not providing you any of the intended benefits. Much of what I am about to discuss is also described in Performance Guidelines for Azure in SQL Server Virtual Machines.
I'm not here to tell you that you must use UltraSSD, Premium Storage, or any other disk type. You just need to be aware that you have options and know what each disk type brings to the table. Of course, like anything else in the cloud, the more money you spend, the more power, speed, throughput, etc. you will achieve. The trick is finding the optimal configuration so that you spend just enough to achieve the desired results.
Achieving SQL Server HA/DR With a Mix of Always On AGs and SANless SQL Server Failover Cluster Instances
The topic of mixing SQL Server Failover Cluster Instances (FCI) with Always On Availability Groups (AG) is pretty well documented. However, most of the available documentation documents configurations that assume the SQL Server FCI portion of the solution utilizes shared storage. What if I want to build a SANless SQL Server FCI using Storage Spaces Direct (S2D), can I still add a SQL Server AG to the mix? Unfortunately, the answer to this question is no. As of today, this combination of S2D based SQL Server FCI and Always On AG is not supported. I previously blogged about this S2D limitation here.
However, the good news is you CAN build a SANless SQL Server FCI with SIOS DataKeeper and still leverage Always On AG for things like readable secondaries. You still have to abide by the same rules that apply when mixing traditional SAN-based SQL Server FCI and Always On AGs, but other than that, it is exactly the same...mostly.
How to Configure a SQL Server 2008 R2 Failover Cluster Instance in Azure
Introduction
If you are reading this article you probably are still using SQL Server 2008/2008 R2 and want to take advantage of the extended security updates that Microsoft is offering if you move your SQL Server 2008/2008 R2 into Azure. I previously wrote about this topic in this post.
You may be wondering how to make sure your SQL Server instance remains highly available once you make the move to Azure. Today, most people have business critical SQL Server 2008/2008 R2 configured as a clustered instance (SQL Server FCI) in their data center. When looking at Azure you have probably come to the realization that due to the lack of shared storage it might seem that you can't bring your SQL Server FCI to the Azure cloud. However, that is not the case thanks to SIOS DataKeeper.
Tick Tock…6 Months Until SQL Server 2008/2008 R2 Support Expires Unless You Take Action
If you are still running SQL Server 2008/2008 R2, you probably have heard by now that as of July 9, 2019, you will no longer be supported. However, realizing that there are still a significant number of customers running on this platform that will not be able to upgrade to a newer version of SQL before that deadline, Microsoft has offered two options to provide extended security updates for an additional three years.
The first option you have requires the annual purchase of “Extended Security Updates.” Extended Security Updates will cost 75% of the full license cost annually and also requires that the customer is on active software assurance, which is typically 25% of the license cost annually. So effectively, to receive Extended Security Updates you are paying for new SQL Server licenses annually for three years, or until you migrate off SQL Server 2008/2008 R2.