As we did AlwaysOn FCI we make a step into the AlwaysOn AG. The Configuration options are divided with a lot of options. But the methods are the same. Pardon I did already a post http://robertsmit.wordpress.com/2013/09/12/windows-server-2012-r2-with-sql-server-2014-failover-clustered-instance-step-by-step-alwayson-availabilitygroups-what-can-go-wrong-part-1/
As there are a lot of extra options to extend your SQL server and give your DB the HA feeling. I hope the next post will give you insight in a how to get there. In a follow up post I will explain the Azure and extra options of SQL Server 2014.
AlwaysOn Availability Groups (SQL Server)
The AlwaysOn Availability Groups feature is a high-availability and disaster recovery solution that provides an enterprise level alternative to database mirroring. An availability group supports a failover environment for a discrete set of user databases, known as availability databases, that fail over together. An availability group supports a set of read-write primary databases and one to four sets of corresponding secondary databases.
Deploying AlwaysOn Availability Groups requires a Windows Server Failover Cluster. To be enabled for AlwaysOn Availability Groups, an instance of SQL Server must reside on a Windows Server Failover Cluster node, and the Windows Server Failover Cluster and node must be online. Furthermore, each availability replica of a given availability group must reside on a different node of the same Windows Server Failover Cluster.
AlwaysOn Availability Groups supports cross-cluster migration of availability groups for deployments to a new Windows Server Failover Clustering. A cross-cluster migration moves one availability group or a batch of availability groups to the new, destination WSFC cluster with minimal downtime.
By implementing AlwaysOn SQL Server FCI an availability replica can be hosted by either a standalone instance of SQL Server or an FCI instance. Only one FCI partner can host a replica for a given availability group.
AlwaysOn Availability Groups does not depend on any form of shared storage. However, if you use a SQL Server failover cluster instance (FCI) to host one or more availability replicas, each of those FCIs will require shared storage as per standard SQL Server failover cluster instance installation.
You might need to configure a Windows Server Failover Clustering (WSFC) cluster to include shared disks that are not available on all nodes. For example, consider a WSFC cluster across two data centers with three nodes. Two of the nodes host a SQL Server failover clustering instance (FCI) in the primary data center and have access to the same shared disks. The third node hosts a stand-alone instance of SQL Server in a different data center and does not have access to the shared disks from the primary data center. This WSFC cluster configuration supports the deployment of an availability group if the FCI hosts the primary replica and the stand-alone instance hosts the secondary replica.
AlwaysOn Availability Groups
I already had my cluster in place with the SQL AlwaysOn FCI and I have also installed a Second Cluster and a Second Instance on the cluster and already extended the SQL site to Azure and with several standalone server.
Before we start we need to enable the AlwaysOn HA option in on the server this is only done on the running server and is cluster aware. One setting for all the nodes for the same instance!
When we tried to enable the AG it is grayed out. in the SQL management.
Go to the SQL Server Configuration Manager
When you are connecting to the passive node on the cluster you will see this, on a standalone install you can only connect to the active node.
Go to the other node and Set this setting. You can only change this setting on the running node that hold the SQL server
Now that we enabled the AlwaysOn Availability Groups we can start the wizard in SQL
I just created a dummy DB just to set this up and I will later Add the real DB.
The dummy DB needs to have a full Backup ! So If your DB is as large as a TB a full backup is needed.
This is a interesting Screen Lots of Options and also Connections To Azure.
First we do a on premise connection and build a Replica to Azure.
and make a choice “ add Replica “ When we select the add replica a SQL login screen will popup.
Remenber you need to connect to the replica SQL server.
This server is my standalone instance but installed on a failover cluster.
and as you can see I connected My Cluster SQL Server with the CSV installation now to a local SQL instance installed on Cluster Node 4
Some basics you need to know when connecting :
- All the cluster nodes must be in the same Active Directory Domain Services (AD DS) domain.
-
Each availability replica in an availability group must reside on a different node of the same Windows Server Failover Clustering (WSFC) cluster.
-
The cluster creator must have the following accounts and permissions:
-
Have a domain account in the domain where the cluster will exist.
-
Have local administrator permissions on each cluster node.
-
Have Create Computer objects and Read All Properties permissions in AD DS. For more information, see Failover Cluster Step-by-Step Guide: Configuring Accounts in Active Directory.
-
The Chosen Server is selected and added to secondary. In a cluster there is no automatically failover!
Readable secondary: No
In the secondary role, this availability replica will not allow any connections. I’ll use this pure as a backup and no changes will be made in the backup location. If the cluster is failing I have more problems than a not working Application.
All the options can be set but If you have multiple instances (AlwaysOn FCI ) and installed a local standalone Instance You may need to change the Endpoint Port! the default is 5022. I changed the port to 5023 just to make sure that there is no problem on my server.
Changing the port is easy “ SELECT * FROM sys.tcp_endpoints “ will show you the ports.
With “ ALTER ENDPOINT [hadr_endpoint] AS TCP (listener_port = 5023) “ you change the port to a better one.
Normally If you run this wizard and doing this steps you are fine, but in my demo site I had already a connection to Azure and therefor my listener want not only a local IP but also an Azure IP as described in the error message.
But this error is not saying he you need to do this again no simple add an IP address to your listener You can Add this by hand or create listener in SQL
As you could see I needed to add a second IP for my listener that is I already setup a failover to azure.
In the fist step we could choose Azure Replica or a replica
And I dis the Azure Replica and If you are not already connected and added the thumbprint to your SQL server then you need to do this.
Just click Download and the Azure Login will popup and you need to login with the Azure Admin account that can create the Azure VM
When check the down the Azure login screen will pop up
a quick connection screen will popup and does fill in your subscriptions. If you have multiple just pick the right one.
So after connecting and downloading you will have the following. Reminder there is only creating NEW VM available ! If you want to use an existing VM then use the add replica just as in a normal situation.
The bad thing is here you can not pick a SQL server that already is build. But in the Screenshots you will see this is much easier. But it would be nice to tweak this a bit. It Would be handy if you could also pick an existing VM.
After filling in my name and version Size We can go to the next step. keep in mind you can always lower the size of the VM but now it is faster and the setup process will be quicker.
As you can see the Azure Replica server is added.
As I connected the Azure SQL with a Azure Gateway to my LAB environment we can share files thru the domain.
The wizard kick in and we have to wait until it is done. I did not create a listener for this, I just want to replicate the data to Azure.
Real Pity that there is no export to script I would like to see the script that created my azure SQL VM
The progress screen an this can take a while. With a quick peek in Azure We can see this.
This is a Critical Point I have done this now several times and sometimes it fails in a time out , and I found out that I used most of the time a small server and then the script will fail with “Error” so a quick tip use the default size and adjust this after the creation.
Checking the VM 4 cores and with an extra disk from 1TB holding my DB
My Lessons learned
As you can see there are multiple disks and the Wizard has run successfully.
My source was clustered and the DB is running on a CSV. Witch s a bad choice for running a Replica. The reason is the Replica wizard want to see the same disk and placing the DB files on C is no problem but a CSV volume placed C:ClusterStorageVolume1MSSQL12.MSSQL001MSSQLDATA
and this path is available for every cluster node and therefore also in the Azure cloud. and the “ normal” wizard tells me he the DB is already there. but now this step is skipped.
Second mistake I used a sample DB. there is no way I can add a second DB because of the CSV problem “ Database is already there “ and this is the Source DB I think this will be better in the next version. Or not using CSV with AlwaysOn AG
Now that the wizard is done and a lot of scripting is passed the line to azure. But what is changed and does it work ?
The replica is created and as shown in the dashboard replicated.
Note:
The Following Issue can happen when you use CSV and or you want to create a replica from FCI to FCI. The reason is the disk letter need to be the same on source and destination, as the CSV volume is mounted to every node and therefor the DB is already there and the setup will fail.
Right I use CSV but is the CSV replicated to Azure Yes the cluster does this! But there is no disk mounted in azure and all the files will be placed on the c drive! and the replica can not be created on the location because the source DB is there. If you create the replica by hand you can do this but not by default with the wizard. just a reminder when you playing with this.
There are some options when you enable AlwaysOn the easiest way is having standalone SQL server running on a cluster node. More advanced is using AlwaysOn FCI. But all this can be done just test everything before you go in production . So that you know how your configuration is working.
And just because you can will not say this is your best solution or design. There are many options and will grow are products evolve.
SQL Server AlwaysOn Availability Group concepts
A SQL Server Availability Group enables you to specify a set of databases that you want to fail over together as a single entity. When an availability group fails over to a target instance or target server, all the databases in the group fail over also. Because SQL Server 2012 can host multiple availability groups on a single server, you can configure AlwaysOn to fail over to SQL Server instances on different servers. This reduces the need to have idle high performance standby servers to handle the full load of the primary server, which is one of the many benefits of using availability groups.
An availability group consists of the following components:
-
Replicas, which are a discrete set of user databases called availability databases that fail over together as a single unit. Every availability group supports one primary replica and up to four secondary replicas.
-
A specific instance of SQL Server to host each replica and to maintain a local copy of each database that belongs to the availability group.
Replicas and failover
The primary replica makes the availability databases available for read-write connections from clients and sends transaction log records for each primary database to every secondary replica. Each secondary replica applies transaction log records to its secondary databases.
All replicas can run under asynchronous-commit mode, or up to three of them can run under synchronous-commit mode. For more information about synchronous and asynchronous commit mode, see Availability Modes (AlwaysOn Availability Groups).
Note:
Database issues, such as a database becoming suspect due to a loss of a data file, deletion of a database, or corruption of a transaction log do not cause failovers.
Read the following articles to learn required and important concepts about SQL Server AlwaysOn technology:
-
For details about the benefits of AlwaysOn Availability Groups and an overview of AlwaysOn Availability Groups terminology, see AlwaysOn Availability Groups (SQL Server).
-
For detailed information about prerequisites, see Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server). This article contains the following information:
-
Windows Server system requirements and recommendations
-
SQL Server instance prerequisites and restrictions
-
Prerequisites and restrictions for using a SQL Server Failover Cluster Instance (FCI) to host an availability replica
-
-
Availability group prerequisites and restrictions
-
Availability database prerequisites and restrictions