Tag: AAG

SQL 2017

SQL 2017 Always-on AG Pt. 8: ​AAG Setup

​In this installment we will perform several tasks needed to successfully configure a SQL 2017 Always-On Availability Group (AAG). Tasks include Windows firewall rules (if you use the Windows firewall), configuring a replication folder, creating a small sample database, and finally configuring the SQL AAG.​We will need to create two...

SQL 2017

​SQL 2017 Always-on AG Pt. 7: File Share Witness

​Now that we have the Windows failover cluster service installed and configured with a management point, we need to configure a witness. A witness is a 'third party' that enables monitoring of the cluster node status and assist with failing over SQL services. The witness can live either in the...

SQL 2017

SQL 2017 Always-On AG Pt. 6: Cluster Configuration

Now that SQL 2017 is installed on both nodes, we need to configure the Windows Cluster service. Although SQL AAGs don't use the 'traditional' clustering technology of shared SCSI disks and a quorum disk, the clustering service is required to manage the state and failover the AAG instances.For this procedure...

SQL 2017

SQL 2017 Always-On AG Pt. 5: Node B SQL Installation

​This is the fifth installment of the SQL 2017 AAG series, where we do an unattended install of SQL on node B. We will use a modified configuration INI file that was generated from the node A installation. This reduces human error and makes your installs repeatable. With the use...

SQL 2017

SQL 2017 Always-On AG Pt. 4: Node A SQL Installation

​This is Part 4 of the SQL 2017 Always-On Availability Group installation series. In this post we will manually install SQL 2017 on the first node of the cluster. We will then capture an answer file for SQL, which will be used ​for an unattended SQL installation on Node B...

SQL 2017

SQL 2017 Always-On AG Pt. 3: Service Accounts

This is Part 3 of the SQL 2017 Always-On Availability group series where we setup two service accounts and a security group. One account is for the database engine and the other is for the SQL agent. In order for Kerberos to work properly the database engine account must be...

SQL 2017

SQL 2017 Always-On AG Pt. 2: VM Deployment

First up in this series is deploying your two Windows Server 2016 VMs, which will be the SQL 2017 Always-on availability group nodes. Each VM should be configured with the same VM hardware properties. Selecting the right virtual hardware configuration is important, regardless of which hypervisor you are using. Memory,...

SQL 2017

SQL 2017 Always-On AG Pt. 1: Introduction

​In this series of posts I will show you how to configure SQL 2017 on Windows Server 2016 with Always-on Availability Groups. I will also be pointing out Nutanix AHV and VMware vSphere configuration best practices along the way. As you will see, 98% of the configuration is hypervisor independent.​SQL...

SQL 2014 AlwaysOn AG Pt. 13: SSL

As we near the end of this installation series, there are a couple of final areas to cover. Up in this installment is configuring SSL. Now you may be thinking, SQL and SSL, really? Yes, for a good number of years SQL has supported the use of SSL for database...

SQL 2014 Always-on AG Pt. 12: Kerberos

We are nearing the end of the SQL 2014 AlwaysOn Availability Group series, with just Kerberos and SSL left to configure. In this installment we tackle Kerberos. Depending on your environment, you may or may not need Kerberos configured. Kerberos is only effective when using Windows authentication to your SQL server, not...

SQL 2014 Always-on AG Pt. 10: AAG Setup

After a brief pause in this SQL 2014 AlwaysOn Availability Group series, we are resuming with the server configuration. In this installment we will configure the Windows firewall to allow the two SQL servers to communicate to each other, configure a shared folder for the SQL replication, and finally configure...

SQL 2014 Always-on AG Pt. 7: TempDB

One of the most important aspects of SQL performance is TempDB. Applications can use TempDB as a scratch space, and in most cases you should not rely on just a single TempDB file. If the number of vCPUs is less than 8, then configure an equal number of TempDB files...