At my previous employer’s Solutions Architect blog, I have a new post up on the path to full SQL Server certification 2012, as well as some tricks that could help you earn more certifications while saving money. Check it out!
I read yesterday that VMware has updated the “Microsoft Clustering on VMware vSphere: Guidelines for Supported Configurations” KB article linked here to include SQL Server 2012 AlwaysOn Failover Clusters. That’s fantastic news! I’ve known it works great for quite a while now, but it’s always nice icing on the cake to have the company publicly update their support policies.
As per the latest VMware vSphere 5.1 document “Setup for Failover Clustering and Microsoft Cluster Service“, up to five MFC nodes are now supported per cluster. Again, this is great news. The document talks about the various options of configuring MFC on vSphere and does a great job with specific configuration details usually missed (or ignored) by folks that I know that cluster on vSphere.
I’ve gotten multiple questions lately on how difficult it is to add a new node into an established AlwaysOn configuration. The answer is this – It’s easy! Let’s walk through it.
I have the original AlwaysOn replicated pair that I created a month ago and blogged about. The test servers were named DB3A and DB3B, and they formed a cluster node virtual name of DB3. We’ll add a new server called DB3C into the configuration.
First, make sure you have the cluster feature installed on the new server. If not, add it through the Server Manager, add Feature wizard.
Once the Failover Clustering services are installed, add the node. Connect to one of the two machines in the existing cluster, and open the Failover Cluster Manager. Right click on the cluster, and click Add Node.
Warnings should appear on not having shared disks. But… that’s one of the points to AlwaysOn, right? Ignore those particular errors!
You have just added the new node to the cluster! Now, remember to allow the SQL Server service able to connect to the Availability Group. Open the SQL Server Configuration Manager, right click on the SQL Server service, and hit Properties.
Restart the service to commit this change.
Now, it’s time to add this new server to the Availability Group. Open SSMS 2012 and connect to the server that is acting as the AlwaysOn Availability Group Primary server. Expand Availability Groups, and then right click on the Availability Replicas under your Availability Group. Click Add Replica.
Click Connect to load the connections to the secondary replicas. Now click Add Replica and authenticate to the third server.
All of the standard options for Availability Groups appears once authenticated. Set your options on the three tabs.
Click Next. Set a full bacukp and restore path where both service accounts have full access to, and click Next.
A validation wizard appears to check if everything is kosher before you continue.
Click to complete this operation!
The progress screen is pretty slick too!
Once this completes, make sure that everything looks good. If all is well, your screen should look similar to this.
W00t! Your third node is set up and ready to go! That wasn’t too hard, now was it?
Check out my latest blog post on my former employer’s Solutions Architect blog on how SQL Server 2012 AlwaysOn blurs the lines between HA and DR.
Have you ever had to set SQL Server trace flags or startup parameters on the instance startup? It’s quite a chore. SQL Server 2012 solves this pain with a very simple and elegant solution.
On all versions before SQL Server 2012, the interface was just bad. If the syntax is not perfect, including semicolons or other delimiters, the SQL Server instance will not start.
Do you see that tiny space after the last ‘ldf’? That’s where any additional start parameters must go. For example, if you wish to enable large memory pages (trace flag 834), the string goes from this:
The syntax must be perfect or else the instance will refuse to start.
However, in SQL Server 2012, this screen was updated.
That’s much better! Thanks Microsoft!
Before you can create your AlwaysOn availability group, you must first configure your two or more server nodes as a Microsoft Failover Cluster. It’s a trivial task if you are not using shared disks. Follow along as I create a two node cluster with Windows Server 2008R2.
NOTE: This demonstration was done on a VMware vSphere 5.0 cluster. SQL Server 2012 AlwaysOn’s clustering underpinnings work great on vSphere!
Launch the Failover Cluster Create Cluster Wizard.
My ultimate goal is to create the cluster virtual node db3. My two cluster nodes are db3a and db3b.
If you run the validation test, ignore any warnings about shared disks not being available for the quorum drive.
Name your virtual node name, and assign the network and IP address. You must have administrative privileges on the cluster within Active Directory, because this wizard creates an object in both Active Directory and DNS for these items.
The confirmation process is very straightforward.
It will take a bit of time to create the node objects on each of the two servers.
Look at that! The cluster has been established and the virtual node created. The warnings come from the lack of shared disks.
The cluster is up! It responds to pings appropriately.
The cluster is up and nodes are reporting that all is good.
Next step – AlwaysOn configuration!