SQL Server – Tech-Coffee https://www.tech-coffee.net Mon, 02 Nov 2015 19:36:07 +0000 en-US hourly 1 https://wordpress.org/?v=5.2.11 65682309 SQL AlwaysOn FCI in Azure IaaS Cloud with StarWind Virtual SAN Solution https://www.tech-coffee.net/sql-alwayson-fci-in-azure-iaas-cloud-with-starwind-virtual-san-solution/ https://www.tech-coffee.net/sql-alwayson-fci-in-azure-iaas-cloud-with-starwind-virtual-san-solution/#respond Mon, 02 Nov 2015 19:09:38 +0000 https://www.tech-coffee.net/?p=4212 1 – Introduction This article explains how to deploy an SQL AlwaysOn FCI in Azure IaaS Cloud in SAN-less mode (without Shared Storage like SAN, NAS …) with StarWind Virtual SAN solution.           StarWind Virtual SAN allows to present Shared Volume to a WSFC Cluster from two or more nodes without ...

The post SQL AlwaysOn FCI in Azure IaaS Cloud with StarWind Virtual SAN Solution appeared first on Tech-Coffee.

]]>
1 – Introduction

This article explains how to deploy an SQL AlwaysOn FCI in Azure IaaS Cloud in SAN-less mode (without Shared Storage like SAN, NAS …) with StarWind Virtual SAN solution.

 

 

 

 

 

StarWind Virtual SAN allows to present Shared Volume to a WSFC Cluster from two or more nodes without physical shared storage solution (SAN, NAS …). The DAS Storage (Physical or Virtual) of each node is used to create clustered volume managed by VirtualS AN. It can be used for Hyper-V clusters, SQL Cluster, VMware cluster …

For SQL, the advantage of this solution is that it is possible to deploy a SQL AlwaysOn Failover Cluster Instance (which requires only SQL Server Standard version licenses) instead of a SQL AlwaysOn AAG cluster (which requires SQL Enterprise licenses => more expansive).

Links:

StarWind Virtual SAN: https://www.starwindsoftware.com/starwind-virtual-san/fr

StarWind Resource Library: https://www.starwindsoftware.com/resource-library

Azure Marketplace VM: http://azure.microsoft.com/en-us/marketplace/partners/starwind/starwindvirtualsan-starwindbyol/

Overview of Architecture:

Schema - Azure - SQL AlwaysOn FCI & Virtual SAN - Overview

I will deploy three VM in azure:

  • One AD DC/DNS Server used to create a forest.
  • Two SQL Server nodes in cluster (with SQL Server 2014 STANDARD Edition).

Note:

  • In Azure, you can also directly used the Azure SQL Database service (based on AlwaysOn), the infrastructure is managed by Azure (PaaS mode).
  • You can also deploy an SQL AlwaysOn Availability Group, but this feature require SQL Server ENTERPRISE licenses (more expansive)

SQL VM Prerequisites:

To deploy StarWind Virtual SAN Solution, each VM must have:

  • Two NIC (minimum two subnets are required : one for Data Synchronization and one for Heartbeat)
  • One dedicated VHDX (this is not required, you can create Shared volume on each System volume of VM (C:\) but this is not a Best Practice).

StarWind Virtual SAN overview:

Virtual SAN must be installed on all nodes that will participates to the cluster.

On each node a Virtual SAN volume is created (file extension: SWDSK), Virtual SAN will replicate this volume between the two nodes (Synchronous replication). The Virtual SAN Volume will be presented to cluster nodes through iSCSI protocol with the use of MPIO.

Note about Cache: There is different Cache mode configuration applicable on a Virtual SAN Volume, this part is not covered in this article, but for example you can configured cache on SSD disk on each node to accelerate your IOPS.

You can also configure Virtual SAN Volume in Thick or Thin-provisioned mode.

Several Virtual SAN volume can be created on a same volume, this is just a question of Performance/Usage.

Configuration:

In this article, each SQL VM will be configured with two VHDX (one for system and one to host Virtual SAN Volumes). I will configure two Virtual SAN volumes: 1x dedicated for the cluster quorum and one dedicated for the SQL FC Instance Data (DB + LOG).

Overview of Virtual SAN clustered disks and ISCSI configuration:

Schema - Azure - SQL AlwaysOn FCI & Virtual SAN - iSCSI

1.1 – Azure environment preparation

The environment will be composed:

  • 1x Azure subscription (for reminder you can create a trial account with 150€ available for 30 days).
  • 1x Azure Resource Group:

A RG is a logical container used to regroup Azure resources associated to an application. It provides the centralized management and monitoring of these resources (lifecycle, cost calculation, provisioning, access control …)

name

type

location

RG-TCLAB1 Resource Group West Europe
  • 1x Azure Storage Account (required to host VM VHDX):

name

type

resource group

account type

tclab1storage Storage Account RG-TCLAB1 Standard-LRS (Locally Redundant)
  • 1x Virtual Network (VNET) with three subnets:

name

type

resource group

address space

subnets

description

tc-lab1-lan Virtual Network RG-TCLAB1 172.16.0.0/16 Prod 172.16.0.0/24 PROD Subnet
Gateway (Azure) 172.16.1.0/29 Used for VPN (P2S or S2S)
Heartbeat 172.16.10.0/24 Cluster /Virtual SAN Heartbeat
  • 2x Cloud Service. Just for reminder all VM in a Cloud Service must have the same number of NIC. So with two CS, I don’t need to create the AD DC VM with the Heartbeat VLAN. In addition CS allow scalability option.

name

type

resource group

description

tc-lab1-cs Cloud Service RG-TCLAB1 Used for basic servers (AD DC …)
tc-lab1-cs-sqlsrv Cloud Service RG-TCLAB1 Used for SQL Servers
  • 3x Virtual Machine

name

type

resource group

dns name

pIP

size

description

l1-dc-1 Virtual Machine RG-TCLAB1 tc-lab1-cs.cloudapp.net 172.16.0.4 Basic A0 (0.25 Core, 0.75 GB) AD DC / DNS Server
l1-sqlfci-1 Virtual Machine RG-TCLAB1 tc-lab1-cs-sqlsrv.cloudapp.net 172.16.0.5 Standard A3 (4 Cores, 7 GB) SQL AlwaysOn FCI Node 1
l1-sqlfci-2 Virtual Machine RG-TCLAB1 tc-lab1-cs-sqlsrv.cloudapp.net 172.16.0.6 Standard A3 (4 Cores, 7 GB) SQL AlwaysOn FCI Node 2
  • The two SQL nodes will be created with two vNIC and two VHDX.

If you begin with Azure read my detailed article (explains all steps to create the Azure environment: VM creation, Virtual Network configuration …): How to create an Azure Cloud environment.

2 – Installation of StarWind Virtual SAN

In this part I will configure two Virtual Volume (Replicated between the two SQL nodes). At the end both volumes can be added to the WSFC Cluster.

You can use the procedure bellow to configure CSV Disk for Hyper-V Cluster or any other WSFC Cluster.

Note: You can install only “Virtual SAN” components on Servers that will participate to the Replication and install the “Management console” component on an administration server or client.

On the first SQL Server, launch the Setup, select “StarWind Virtual SAN Service” and check the “Management Console”:

Enter your license:

https://www.starwindsoftware.com/registration-starwind-virtual-san

Click Finish:

Note that a Firewall Rule is created:

During the first start, the Management Console ask to configure the Storage Pool for Virtual Disk:

Select the disk previously prepared:

Repeat the operation on the second SQL Server and close the console.

2.1 – Virtual Disk “Quorum” – Creation

From the first SQL server, select it and click “Connect”:

Click the “Add Device (advanced)“:


Select “Hard Disk Device”:


Select Virtual disk and click “Next“.


Check the virtual disk location, change the name and specify the size:


Select “Thick-provisioned”:

Configure the cache policy and specify the cache size.

Note: StarWind recommends to use 1GB cache per 1TB storage.



Define the L2 cache policy if needed.

Note: StarWind recommends to use SSD for L2 cache and if it will be used, the formula is 1GB (sum of L1 and L2) cache per 1TB storage.

Enter a “Target Alias”, if you want you can change the Target Name:


Click “Create”:

Wait for completion and click Close:

Note that on the disk, two files (.img and .swdsk) are created:

2.2 – Virtual Disk “Quorum” – Configure Replication

Select the device you just created and click “Replication Manager“.


In the “Replication Manager” Window click “Add Replica“. Select “Synchronous two-way replication” and click “Next“:

Enter the FQDN of the second SQL server:

Select the target disk for the second SQL Server:

Same disk as the first SQL Server:

Choose “Create new Partner Device
and click Next.

Leave default options (check the driver letter)

Click “Change network settings“:


Select a Network for “Synchronization and HA” and the other Network for Heartbeat:

Note: if you have more than two networks, you can configure several networks for Synchronization/HA flows (or Heartbeat).


You can also modify the ALUA (Asymmetric Logical Unit Assignment / Multipathing method) settings, but it”s recommended to keep “ALUA Optimized” for the both targets.


Click “Create Replica”:

Click “Close”:

Wait for the end of Synchronization and click “Close”:

On the Management Console, add the second SQL Server to manage it:

Click “Add Server”:

Enter “FQDN”:

Click “Connect”:

Now we can see the status of our replicated Virtual Disk. You can see that the second SQL server priority is set to “Second” and you can retrieve the local path of Virtual disk:

Note that the “Image1” name as change to “HAImage1”.

2.3 – Virtual Disk “SQL Data” – Creation & Replication Configuration

Repeat the procedure to create disk for “SQL DATA”:

Then configure Replication:

Wait for Synchronization and click “Close”:

So now the two disk are ready and after iSCSI configuration we can add them to WSFC Cluster:

3 – Enable iSCSI MPIO

To allow iSCSI multipath (configuration of several paths between iSCSI initiator and target) we must configure the MPIO Driver (installed previously) on both nodes

Start the MPIO Console: mpiocpl.exe

Go to “Discover Multi-Paths”, select “Add support for iSCSI devices” and click “Add”:

Restart Computer

After restart, re-run “MPIOCPL” and valid that “MSFT2005iSCSIBusType_0x9” is added to “Devices”:

4 – Configure iSCSI

The last step is to configure iSCSI Initiator on both node to present the two target disk in multipath mode.

On each SQL node (2x iSCSI Target for the Quorum disk + 2x iSCSI Target for the SQL-Data Disk)

Reminder:

Hostname IP Prod IP Heartbeat
l1-sqlfci-1 172.16.0.5 172.16.10.5
l1-sqlfci-2 172.16.0.6 172.16.10.6

4.1 – Present Disks to SQL Node 1

On the first SQL Server (L1-SQLFCI-1), start the “iSCSI initiator” configuration: iscsicpl

Configure Discovery

Go to “Discovery” tab and click “Discover Portal…”:

First add the host himself, enter the loopback address and click “Advanced”:

Select “Microsoft iSCSI Initiator” and set the Initiator IP to “Default”:

Next repeat the procedure to add the other SQL Server:

Enter the IP address of the second SQL Server, click “Advanced” and set the Initiator IP to the local IP of the server.

For more High Availability, you can also add the Heartbeat network:

Connect Targets

Go to the “Targets” tab. You can see that the two disk are listed (two different path) and the connection are “Inactive”.

Select the first target on the local server himself and click “Connect”:

Check “Enable multi-path”, click “Advanced” and configure the Initiator IP to default and the Target Portal on the loopback:

Repeat the procedure for the second path of the Quorum disk. Set the Initiator IP to the local IP of the Server and the Target Portal IP to the IP of the other SQL Serve:

Repeat the procedure for the second iSCSI target (SQL-Data Disk). The first path on the local server and the second path on the other Server. At the end all the targets status must be “Connected”:

Configure MPIO

Select the first Target of the “Quorum disk” and click “Devices…”

Click “MPIO”:

By default the “Load balance policy” is configured to “Round robin”.

Change it to “Fail Over Only” and check that the Active path is the localhost => Select the Active path, click “Details” and control the Source/Target Portal:

Repeat the same procedure for the second Target “SQLData”:

4.2 – Present Disks to SQL Node 2

Repeat the Full procedure to configure iSCSI Targets on the second SQL Server

Configure Discovery:

Connect all Targets (for each disk, one locally and the second to the other server):

Configure MPIO “Load Balance Policy” to “Fail Over Only” on the both targets:

Quorum Disk:

SQLData Disk:

5 – Prepare Disk

Now, we can see that the two volumes are visible by both SQL node (with multipath):

On one node, initialize both disks:

Now we are ready to mount the SQL Cluster!

6 – Create the WSFC Cluster

Go to the first node and start the WSFC Console and select “Validate cluster Configuration.

Add the two SQL Nodes:

Run all tests, check “Create the cluster now…” and click Finish:

Enter the Cluster Name:

Note that the Cluster IP is configured in DHCP Mode.

Uncheck “Add all eligible storage to cluster”:

Click Finish:

At the end of the cluster configuration, there is an error:

This is “normal” on Azure, this issue is due to the DHCP mode for the Cluster IP, the Cluster retrieves the same IP as the node where the cluster is created, so there is an IP Conflict.

Go to the second SQL node and start the WSFC Console:

Edit the IP Cluster Core resource:

Change IP to a Static IP (there is no way for the moment to reserve it on Azure):

Click “Yes”:

6.1 – Configure Network

Go to Network, rename them and check the configuration (Cluster Use):

6.2 – Add Disk to cluster

Go to Storage and select “Add Disk”:

Add the two Virtual Disks (managed by StarWind Virtual SAN):

Start the “Server Management” console and create new Volume on these Disks:

Create Quorum Volume (Q:):

Create “SQL Data” Volume (G:):

6.3 – Configure Quorum

Edit “Cluster Quorum Settings”:

Select “Advanced”:

Keep “All Nodes” for “Voting Configuration” and select “Configure a disk witness”:

Select the Q: Volume and click “Finish”:

So now we have one Disk used for Cluster Quorum and one disk available for SQL Server:

7 – SQL Server – Install first Node

On the first node, mount the SQL Server 2014 (or 2012) Standard ISO and select “Installation\New SQL Server failover cluster installation”:

Select “Database Engine Services” and “Management Tools – Basic”:

Select “Default instance” and enter a SQL Server Network Name:

Keep or change the SQL Cluster group:

Select the Cluster Disk:

Configure an IP Address for the SQL cluster:

Configure you service accounts:

Set “Collation”:

Configure your Authentication mode and Administrators Group:

Configure the SQL path to the Cluster Disk (except for the TempDB, select a local path). Normally you should configure TempDB, Log … on separate disks):

Click “Yes”:

Start Installation:

Wait for installation and click “Close”:

Now, the SQL Cluster Instance is ready with the Clustered disk:

8 – SQL Server – Install the second Node

Go to the second node, mount SQL ISO and select “Add node to a SQL Server failover cluster”:

Check the Cluster Node and Network Configuration:

Configure Service Accounts:

Click “Install” and wait for completion:

9 – Connect to Instance

Ok, so now if you try to connect the instance directly from a node, it’s OK:

But if you try to connect from a client, you get an error:

This is normal, in Azure you cannot connect directly to a cluster, you have to configure an ILB (Internal Load Balancer). To access the SQL Cluster Instance clients must connect to the ILB instead of the Cluster IP.

10 – Create an Internal Load Balancer (ILB)

Start “Azure PowerShell” and run:

1 – Create the ILB:

Change variables with your parameters and choose a Load balanced Set name.

$SQLClusterName = "sqlfci-1"
$SQLClusterIP = "172.16.0.115"
$CloudServiceSQL = "tc-lab1-cs-sqlsrv"
$LBSetName = "LBS-SQLFCI"
Add-AzureInternalLoadBalancer -InternalLoadBalancerName $SQLClusterName -SubnetName "default" -ServiceName $CloudServiceSQL –StaticVNetIPAddress $SQLClusterIP

Note: Check ILB in a Cloud Service

Get-AzureInternalLoadBalancer -ServiceName "tc-lab1-cs-sqlsrv" -Verbose:$false

Note: Get VM Azure Endpoint

Get-AzureVM -Name "l1-sqlfci-1" -ServiceName "tc-lab1-cs-sqlsrv" -Verbose:$false | Get-AzureEndpoint | ft Name,protocol,port,localport,ProbeProtocol,ProbePort, ProbeIntervalInSeconds,InternalLoadBalancerName -AutoSize

By default, on a VM a PS and RDP endpoint are created:

2 – Add load balanced endpoint to the first cluster SQL node:

Note: Choose your own “Probe Port” (here: 311433). The same Probe Port must be configured on endpoint on both VM and on the SQL IP Address cluster resource.

Get-AzureVM -ServiceName $CloudServiceSQL -Name "l1-sqlfci-1" | Add-AzureEndpoint -Name "SQL" -LBSetName $LBSetName -Protocol "TCP" -LocalPort 1433 -PublicPort 1433 -ProbePort 31433 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 –DirectServerReturn $true -InternalLoadBalancerName $SQLClusterName | Update-AzureVM

Now if we check Endpoints:

3 – Add load balanced endpoint to the second SQL cluster node:

Get-AzureVM -ServiceName $CloudServiceSQL -Name "l1-sqlfci-2" | Add-AzureEndpoint -Name "SQL" -LBSetName $LBSetName -Protocol "TCP" -LocalPort 1433 -PublicPort 1433 -ProbePort 31433 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 –DirectServerReturn $true -InternalLoadBalancerName $SQLClusterName | Update-AzureVM

MSDN Links:

  • LoadBalancerProbe Schema: https://msdn.microsoft.com/en-us/library/azure/jj151530.aspx
  • Add-AzureEndpoint: https://msdn.microsoft.com/en-us/library/azure/dn495300.aspx

NOTE – View Load Balanced Set configuration through the Azure Portal:

Edit VM Settings. You can see the new “Load-Balanced” endpoint:

Got to “Load balanced sets”, you can see the ILB:

In addition, you can edit the Load Balanced set:

View of member VM and you can manage ACL:

10.1 – Configure SQL IP address Cluster Resource

Now the last step is to configure Cluster.

For reminder, during the SQL setup, I set a static IP Address 172.16.0.115 on the SQL Server instance role and I configure the ILB with the same IP. The last step is to add the probe port defined in the ILB to the SQL IP resource cluster.

On a cluster node, start a PowerShell console with Elevated privileges. Retrieve the name of the resource “IP Address” of the SQL Server cluster group:

Configure Probe Port (here 31433) on the SQL IP Address cluster resource:

Get-ClusterResource "SQL IP Address 1 (sqlfci-1)" | Set-ClusterParameter -Multiple @{Address="172.16.0.115";ProbePort="31433";SubnetMask="255.255.255.255";Network="Cluster Network - PROD";OverrideAddressMatch=1;EnableDhcp=0}

Check the SQL IP Address cluster resource configuration:

Get-ClusterResource "SQL IP Address 1 (sqlfci-1)" | Get-ClusterParameter

Note: Probe port’s job is to find out which is the active node that hosts the IP Address (SQL Role) in the Cluster. Load Balancer sends the probe pings over TCP port 31433 to every node in the cluster (by default every 10 seconds)

For more information about ILB and Probe Port configuration, read this excellent article: http://blogs.technet.com/b/askcore/archive/2015/06/24/building-windows-server-failover-cluster-on-azure-iaas-vm-part-2-network.aspx

Restart the SQL Server Cluster Role:

Now you can connect to the SQL Cluster Instance through a Client.

The post SQL AlwaysOn FCI in Azure IaaS Cloud with StarWind Virtual SAN Solution appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/sql-alwayson-fci-in-azure-iaas-cloud-with-starwind-virtual-san-solution/feed/ 0 4212
AlwaysOn Part 8 – Methods to add Database (SCOM) https://www.tech-coffee.net/alwayson-part-8-methods-to-add-database-scom/ https://www.tech-coffee.net/alwayson-part-8-methods-to-add-database-scom/#comments Wed, 01 Oct 2014 05:42:24 +0000 https://www.tech-coffee.net/?p=2464 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Part 8 – Methods to add Database (SCOM) appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:


I will not cover the entire SCOM installation, but just the part of Databases configuration.

Note that the Availability Groups (one or two, depending of your architecture) must be created before the SCOM installation. Indeed, during the installation we need to specify the AAG Listener DNS name in place of the classic instance Name.

During the installation, the database is created on the active instance (which hosts the Availability Group Listener) but it’s not added to the AlwaysOn Availability Group, this action must be done at the end of installation. This article covers the methods to add Database to an AAG through SQL Management Studio, T-SQL and PowerShell.

In the previous part (7 – AAG Advanced Configuration), I have created two dedicated AAG for SCOM:

AlwaysOn Availability Groups for SCOM Databases

 

Install SCOM

Note: Before installation the AAGs are dispatched (nominal mode):

  • *  AAG-3SCOM (with the listener: AAG-3L) is hosted by the AOI2 Instance
  • *  AAG-4SCOM (with the listener: AAG-4L) is hosted by the AOI4 Instance

Start the SCOM installation (full procedure will be written in a dedicated article):

Select components that you want:

First Management server:

And now the part that interest us.

For the “Server name and instance name” we just have to specify the AG Listener DNS Name and the port (check the paths):

Same for the data warehouse database:

Finalize the installation:

Now from SQL, on the AOI2 Instance, we can see the OperationsManager Database (not added to the AG):

And on the AOI4 Instance, we can see the OperationsManagerDW Database:

 

Add SCOM Databases to the Availability Groups

Prepare Databases

Change recovery model to Full and make a Full Backup

With Transact-SQL

-- Set Recovery Model to FULL
USE master ;
ALTER DATABASE OperationsManager SET RECOVERY FULL ;

-- Check Recovery Model
SELECT name, recovery_model_desc
FROM sys.databases WHERE name = 'OperationsManager' ;
GO

-- Make a Full Backup
USE master
GO
BACKUP DATABASE OperationsManager TO DISK = 'G:\MSSQL\MSSQL11.AOI2\MSSQL\Backup\OperationsManager.bak'
GO

Repeat the same operation for the OperationsManagerDW database.

 

Add SCOM Databases to Availability Groups

There are 3 methods to configure a Database in an Availability Group:

  • –  From SQL Management Studio
  • –  From Transact-SQL
  • –  From PowerShell

For demonstration, I will add to the AAGs:

  • –  the first SCOM Database (OperationsManager) with Management Studio
  • –  the second SCOM Database (OperationsManagerDW) with T-SQL
  • –  a test database with PowerShell

 

Add a Database to an Availability Groups through Management Studio

Target: Database “OperationsManager” to the Availability Group “AAG-3SCOM”

Right-click on the Availability Group and select “Add Database”:

Select the SCOM Database:

On the “Select Initial Data Synchronization” enter a shared network location:

There is an issue with Management Studio. For security I have set a static port on all instances (not the default 1433) and I disabled SQL Browser Service. To add a database to an AAG you need to connect all Replicas, but I cannot specify the port and so without the Browser service enabled I cannot connect the secondary instance… (This issue is only present with the use of SQL Management Studio)

So start the SQL Browser Service temporarily (and open the firewall port if needed) and connect to the instance:

Review checks:

Start the operation:

Now first SCOM Database is configured for High Availability on the Availability Group AAG-3COM.

Check the status on the Primary Instance (synchronized under Databases):

On the secondary instance, wait until the status is “Restoring”:

Status OK on the secondary replica:

 

Add a Database to an Availability Groups through T-SQL

Target: Database “OperationsManagerDW” to the Availability Group “AAG-4SCOM”

Prepare the T-SQL script:

Script: AAG-4SCOM-Add-DB-OperationsManagerDW.sql

--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE.
:Connect M-SQLA4\AOI4,1764
USE [master]
GO

ALTER AVAILABILITY GROUP [AAG-4SCOM]
ADD DATABASE [OperationsManagerDW];
GO

:Connect M-SQLA4\AOI4,1764
BACKUP DATABASE [OperationsManagerDW] TO DISK = N'\\10.0.1.21\Share\OperationsManagerDW.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

:Connect M-SQLA2\AOI2,1764
RESTORE DATABASE [OperationsManagerDW] FROM DISK = N'\\10.0.1.21\Share\OperationsManagerDW.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

:Connect M-SQLA4\AOI4,1764
BACKUP LOG [OperationsManagerDW] TO DISK = N'\\10.0.1.21\Share\OperationsManagerDW_20140505174600.trn' WITH NOFORMAT, NOINIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

:Connect M-SQLA2\AOI2,1764
RESTORE LOG [OperationsManagerDW] FROM DISK = N'\\10.0.1.21\Share\OperationsManagerDW_20140505174600.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

:Connect M-SQLA2\AOI2,1764
-- Wait for the replica to start communicating
begin try
declare @conn bit
declare @count int
declare @replica_id uniqueidentifier
declare @group_id uniqueidentifier
set @conn = 0
set @count = 30 -- wait for 5 minutes
if (serverproperty('IsHadrEnabled') = 1)
and (isnull((select member_state from master.sys.dm_hadr_cluster_members where upper(member_name COLLATE Latin1_General_CI_AS) = upper(cast(serverproperty('ComputerNamePhysicalNetBIOS') as nvarchar(256)) COLLATE Latin1_General_CI_AS)), 0) <> 0)
and (isnull((select state from master.sys.database_mirroring_endpoints), 1) = 0)
begin
select @group_id = ags.group_id from master.sys.availability_groups as ags where name = N'AAG-4SCOM'
select @replica_id = replicas.replica_id from master.sys.availability_replicas as replicas where upper(replicas.replica_server_name COLLATE Latin1_General_CI_AS) = upper(@@SERVERNAME COLLATE Latin1_General_CI_AS) and group_id = @group_id
while @conn <> 1 and @count > 0
begin
set @conn = isnull((select connected_state from master.sys.dm_hadr_availability_replica_states as states where states.replica_id = @replica_id), 1)
if @conn = 1
begin
-- exit loop when the replica is connected, or if the query cannot find the replica status
break
end
waitfor delay '00:00:10'
set @count = @count - 1
end
end
end try
begin catch
  -- If the wait loop fails, do not stop execution of the alter database statement
end catch

ALTER DATABASE [OperationsManagerDW] SET HADR AVAILABILITY GROUP = [AAG-4SCOM];
GO

 

From the M-SQLA4 server, start a CMD and execute:

sqlcmd -S M-SQLA4\AOI4,1764 -i c:\tools\AAG-4SCOM-Add-DB-OperationsManagerDW.sql



Check the status of Database, now the both SCOM Databases are OK:

(Note) You can remove all backups in the share folder:

Another prerequisite for a failover of a database on another instance (replica) is that the logins of the application must be configured (with the same permissions: Server Roles/User Mapping) on all instances involved in the Availability group.

To do a failover, the application (here SCOM) logins must be configured on all replicas.

Check SCOM SQL logins on all Instances of the Availability Group. First Replica “M-SQLA2\AOI2”:

  • * svc-scomaa
  • * svc-scomdas
  • * svc-scomdww

Second replica “M-SQLA4\AOI4”:

 

Add a Database to an Availability Groups through PowerShell

Target: Database “AdvWorks” to the Availability Group “AAG-1”

Requirement:

  • Check if Database backup mode is set to Full

Start PowerShell (elevated privileges):
SCRIPT: SQLAO_Add-database-to-AAG.ps1

1 – Backup Database
Note: If you launch the command remotely, the SQL Browser Service must be started on the target Instance.

Import-Module SQLPS
# Backup Database
Backup-SqlDatabase -Database “AdvWorks1” -BackupFile “\\10.0.1.21\share\AdvWorks1.bak” -ServerInstance “M-SQLA1\AOI1”
Backup-SqlDatabase -Database “AdvWorks1” -BackupFile “\\10.0.1.21\share\AdvWorks1.trn” -ServerInstance “M-SQLA1\AOI1” -BackupAction “Log”

 

The Full DB and log backups are created :

 

2 – Restore Database on the other instance

Note: To execute this command on a remote computer, the SQL Browser service must be activated.

# Restore databases and logs
Restore-SqlDatabase -Database “AdvWorks1” -BackupFile “\\10.0.1.21\share\AdvWorks1.bak” -ServerInstance “M-SQLA1\AOI1” -NoRecovery

Restore-SqlDatabase -Database “AdvWorks1” -BackupFile “\\10.0.1.21\share\AdvWorks1.trn” -ServerInstance “M-SQLA1\AOI1” ” -RestoreAction “Log” -NoRecovery

Now the Database is in “Restoring” state on the secondary Instance:

 

3 – Join the Database to the AAG on the primary instance

# Join databases to Primary
Add-SqlAvailabilityDatabase -Path “SQLSERVER:\SQL\M-SQLA1\AOI1\AvailabilityGroups\AAG-1\” -Database “AdvWorks1”

The database is added on the AAG-1, check the status (must be Synchronized)

 

3 – Join the Database to the AAG on the secondary instance

# Join databases to Secondary
Add-SqlAvailabilityDatabase -Path “SQLSERVER:\SQL\M-SQLA3\AOI3\AvailabilityGroups\AAG-1\” -Database “AdvWorks1”

Check status on the secondary node:

Note: You can check the copy Status from PowerShell

# Browse the Active instance (*):
# (*) To view information about all of the availability replicas in an availability group, use the server instance that hosts the primary replica.
cd
SQLSERVER:\SQL\M-SQLA1\AOI1\AvailabilityGroups\AAG-1\DatabaseReplicaStates
dir

The post AlwaysOn Part 8 – Methods to add Database (SCOM) appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-part-8-methods-to-add-database-scom/feed/ 2 2464
AlwaysOn Part 7 – AAG with dedicated Replication Network https://www.tech-coffee.net/alwayson-part-7-aag-with-dedicated-replication-network/ https://www.tech-coffee.net/alwayson-part-7-aag-with-dedicated-replication-network/#respond Wed, 01 Oct 2014 05:39:50 +0000 https://www.tech-coffee.net/?p=2426 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Part 7 – AAG with dedicated Replication Network appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:

 


In Part 6, the AAG1 and AAG2 Availability Groups was created from wizard. In this part, I will do an advanced creation of AAG: AAG-3 and AAG-4. Instances members of these AAG will be configured to communicate over a replication Network. I will do the configuration with Transact-SQL and I will write later an article on how to configure AAG through PowerShell.

Now we have to create the Availability Groups: AAG-3SCOM and AAG-4SCOM on instances AOI2 and AOI4:

AAG

Members (Instance)

Default Role

AAG Listener

Databases

Name

IP

Port

AAG-1 m-sqla1\aoi1 Primary

AAG-1L

10.0.1.41

1764

DBTest01
m-sqla3\aoi3 Secondary
AAG-2 m-sqla1\aoi1 Secondary

AAG-2L

10.0.1.42

1764

DBTest02
m-sqla3\aoi3 Primary
AAG-3SCOM m-sqla2\aoi2 Primary

AAG-3L

10.0.1.43

1764

SCOM OP
m-sqla4\aoi4 Secondary
AAG-4SCOM m-sqla2\aoi2 Secondary

AAG-4L

10.0.1.44

1764

SCOM DW DB Orchestrator
m-sqla4\aoi4 Primary

IP use for Instances Endpoints (subnet 10.0.20.0/24):

Hostname

IP Public Network

IP Cluster Network

IP Replication Network

M-SQLA1 10.0.1.21 10.0.10.21 n/a
M-SQLA2 10.0.1.22 10.0.10.22 10.0.20.22
M-SQLA3 10.0.1.23 10.0.10.23 n/a
M-SQLA4 10.0.1.24 10.0.10.24 10.0.20.24

For people who don’t know SCOM, this product require two Databases: one DB “Operation” (for live monitoring) and one DB “Data warehouse” (for historical monitoring). These Databases require performances, so with this configuration, in nominal mode, each DB is hosted on a different Instance and have a replica on the other.

 

Create Availability Group: AAG-3SCOM

This AAG will host the SCOM “OperationsManager” database.

AlwaysOn Availability Group - SCOM Operational DB

1 – Create Instances Endpoint

Network Configuration: The only difference with the Endpoints created for the first two AAG (with the default configuration) is that we add an IP Address of the dedicated Replication network:

–  LISTENER_IP = (10.0.20.22) – for the Instance AOI2

–  LISTENER_IP = (10.0.20.22) – for the Instance AOI4

Endpoints rights: Note the Grant Connect command that it gives rights to the other Instances account (MSA):

–  GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [lab1\svc-sqldbe4$]on the Instance AOI2

–  GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [lab1\svc-sqldbe2$] – on the Instance AOI4

Also, the script checks if the Extended Event session “AlwaysOn_health” is started.

Script “AAG-3SCOM-Creation-1-Endpoint.sql:

--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE.
-- Create Login for both Instances -------------------------------------

:Connect M-SQLA2\AOI2,1764
USE [master]
GO
CREATE LOGIN [lab1\svc-sqldbe4$] FROM WINDOWS
GO

:Connect M-SQLA4\AOI4,1764
USE [master]
GO
CREATE LOGIN [lab1\svc-sqldbe2$] FROM WINDOWS
GO

- Create ENDPOINT for Instance: AOI2 -----------------------------------
:Connect M-SQLA2\AOI2,1764
USE [master]
GO

CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (10.0.20.22))
FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES)
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') &lt;&gt; 0
BEGIN
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO

use [master]
GO
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [lab1\svc-sqldbe4$]
GO

-- Create ENDPOINT for Instance: AOI4 ----------------------------------
:Connect M-SQLA4\AOI4,1764
USE [master]
GO

CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (10.0.20.24))
FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES)
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') &lt;&gt; 0
BEGIN
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO
use [master]
GO
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [lab1\svc-sqldbe2$]
GO

-- Start Extended Event session: "AlwaysOn_health" ---------------------
:Connect M-SQLA2\AOI2,1764
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

:Connect M-SQLA4\AOI4,1764
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

You cannot execute this script from the Management Studio (the command “Connect” is not recognized). You have to use the “sqlcmd” utility.

For more information, see TechNet “sqlcmd How-to Topics“: http://technet.microsoft.com/en-us/library/hh213540.aspx

From the M-SQLA2 server, start a CMD and execute:

sqlcmd -S M-SQLA2\AOI2 -i c:\tools\AAG-3SCOM-Creation-1-Endpoint.sql

Check Endpoint creation, use script “SQL_Endpoint-Get-List.ps1

.\SQL_Endpoint-Get-List.ps1 -SQLServer “M-SQLA2” -InstanceName “AOI2,1764”

From SQL, you can check the TCP Listener:

— Get TCP Listener list

SELECT * FROM sys.dm_tcp_listener_states;

Or via netstat:

netstat -ano | findstr 5022

 

2 – Create Availability Group

Network Configuration: So now we can configure the Endpoint URL on the replication network (same IP as the Endpoint):

–  ENDPOINT_URL = N’TCP://10.0.20.22:5022′) – for the Instance AOI2

–  ENDPOINT_URL = N’TCP://10.0.20.24:5022′) – for the Instance AOI4

AG Listener: The script create the listener with the DNS name and the VIP:

–  ADD LISTENER N’AAG-3L’ ( WITH IP ((N’10.0.1.43′, N’255.255.255.0′)), PORT=1764 )

Script “AAG-3SCOM-Creation-2-AG”:

--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE.
-- CREATE AAG ----------------------------------------------------------
:Connect M-SQLA2\AOI2,1764
USE [master]
GO

CREATE AVAILABILITY GROUP [AAG-3SCOM]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR
REPLICA ON
N'M-SQLA2\AOI2' WITH (
ENDPOINT_URL = N'TCP://10.0.20.22:5022',
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 50,
SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
N'M-SQLA4\AOI4' WITH (
ENDPOINT_URL = N'TCP://10.0.20.24:5022',
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

-- Create Listener -----------------------------------------------------
:Connect M-SQLA2\AOI2,1764
USE [master]
GO

ALTER AVAILABILITY GROUP [AAG-3SCOM]
ADD LISTENER N'AAG-3L' ( WITH IP ((N'10.0.1.43', N'255.255.255.0')), PORT=1764 );
GO

-- JOIN Other Instances ------------------------------------------------
:Connect M-SQLA4\AOI4,1764
ALTER AVAILABILITY GROUP [AAG-3SCOM] JOIN;
GO

 

From the M-SQLA2 server, start a CMD and execute:

sqlcmd -S M-SQLA2\AOI2 -i c:\tools\AAG-3SCOM-Creation-2-AG.sql

Now from netstat we can see that instances communicate over the replication network (10.0.20.0):

Check the Availability Group status from the Dashboard:

Status if failed because there is no Database in the AG:

 

Create Availability Group: AAG-4SCOM

Now we have to create the last AG:

This AAG will host the SCOM “OperationsManagerDW” database.

AlwaysOn Availability Group - SCOM DataWarehouse DB

Instance Endpoints are already created (previously with the AAG-3). So we just have to create the Availability Group.

Network Configuration: The same Endpoint URL as the AAG-3 will be used:

–  ENDPOINT_URL = N’TCP://10.0.20.22:5022′) – for the Instance AOI2
– 
ENDPOINT_URL = N’TCP://10.0.20.24:5022′) – for the Instance AOI4

AG Listener IP: 10.0.1.44

–  ADD LISTENER N’AAG-3L’ ( WITH IP ((N’10.0.1.44′, N’255.255.255.0′)), PORT=1764 );

Script “AAG-4SCOM-Creation-1-AG”:

-- CREATE AAG ----------------------------------------------------------
:Connect M-SQLA4\AOI4,1764
USE [master]
GO

CREATE AVAILABILITY GROUP [AAG-4SCOM]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR REPLICA ON
N'M-SQLA4\AOI4' WITH (
  ENDPOINT_URL = N'TCP://10.0.20.24:5022',
  FAILOVER_MODE = AUTOMATIC,
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
  BACKUP_PRIORITY = 50,
  SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
N'M-SQLA2\AOI2' WITH (
  ENDPOINT_URL = N'TCP://10.0.20.22:5022',
  FAILOVER_MODE = AUTOMATIC,
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
  BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

-- Create Listener -----------------------------------------------------
:Connect M-SQLA4\AOI4,1764
USE [master]
GO
ALTER AVAILABILITY GROUP [AAG-4SCOM]
ADD LISTENER N'AAG-4L' ( WITH IP ((N'10.0.1.44', N'255.255.255.0')), PORT=1764 );
GO

-- JOIN Other Instances ------------------------------------------------
:Connect M-SQLA2\AOI2,1764
ALTER AVAILABILITY GROUP [AAG-4SCOM] JOIN;
GO

 

From the M-SQLA2 server, start a CMD and execute:

sqlcmd -S M-SQLA4\AOI4 -i c:\tools\AAG-4SCOM-Creation-1-AG.sql

Now the configuration is done, we can use the AAG.

 

Next PART: Installation of SCOM with AlwaysOn Availability Groups.

The post AlwaysOn Part 7 – AAG with dedicated Replication Network appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-part-7-aag-with-dedicated-replication-network/feed/ 0 2426
AlwaysOn Availability Groups Creation https://www.tech-coffee.net/alwayson-availability-groups-creation/ https://www.tech-coffee.net/alwayson-availability-groups-creation/#respond Sun, 18 May 2014 16:51:03 +0000 https://www.tech-coffee.net/?p=1455 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Availability Groups Creation appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:

 


Now the next step is to create and configure the first Availability Groups.

There are three methods to do this:

  • –  with Wizard (through Management Studio)
  • –  with PowerShell
  • –  with Transact-SQL

I will use the Wizard to create the first two groups (this permit to create also the Transact-SQL scripts that we can reuse later).

 

Prepare a Database

For reminder, the first availability group will be named “AAG-1” and replica will be host on instance:

  • –  M-SQLA1\AOI1
  • –  M-SQLA3\AOI3

For test I use the Microsoft Adventure Works Database sample. Download “AdventureWorks2012 Data File” (around 200Mb) from: http://msftdbprodsamples.codeplex.com/releases/view/55330

Copy Database file to: G:\MSSQL\AOREPLICA\MSSQL\Data.

I rename it to “AdvWorks1” (I will use same mdf for other tests DB)

Add database to first instance (M-SQLA1\AOI1):

There is only MDF file. So in order to build a new log file, use the ATTACH_REBUILD_LOG option when attaching the databases.


USE [master]
GO

CREATE DATABASE [AdvWorks1]
ON (FILENAME = N'G:\MSSQL\AOREPLICA\Data\AdvWorks1.mdf')
FOR ATTACH_REBUILD_LOG
GO

SELECT
DB_NAME(database_id)  AS "Database Name",
type_desc             AS "File Type",
name                  AS "Logical File Name",
physical_name         AS "Physical File",
state_desc            AS "State"
FROM sys.master_files WHERE database_id IN (DB_ID('AdvWorks1'));

 

Check Backup mode of DB:

 

Another prerequisite is that you have to do at least 1 full backup of each database that will be part of your AG:


# Make a Full Backup
$db = "AdvWorks1"
Backup-SqlDatabase -ServerInstance "M-SQLA1\AOI1" -Database $db -BackupAction Database -BackupFile "G:\MSSQL\MSSQL11.AOI1\MSSQL\Backup\$($db).bak"

 

Or from SQL:


-- Make a Full Backup
USE master
GO
BACKUP DATABASE AdvWorks1 TO DISK = 'G:\MSSQL\MSSQL11.AOI1\MSSQL\Backup\AdvWorks1.bak'
GO

 

So now Database is ready with a full backup.

 

Mirroring Endpoints – Note

The first step is to create one Mirroring Endpoint per Instance.

For reminder, I have prepared a dedicate network for SQL Instances Communications: VLAN Replication. For tests I will configure two instances “AOI2” and “AOI4” to use this Network and the two other to the default network (Public):

Hostname IP VLAN Public IP VLAN CLUSTER IP VLAN Replication
M-SQLA1 10.0.1.21 10.0.10.21 n/a
M-SQLA2 10.0.1.22 10.0.10.22 10.0.20.22
M-SQLA3 10.0.1.23 10.0.10.23 n/a
M-SQLA4 10.0.1.24 10.0.10.24 10.0.20.24

Explications:

By default the Wizard create automatically a Mirroring Endpoint for each Instance (The Endpoint configuration doesn’t contains any Network parameter) and configure the Replica Endpoint URL with the server FQDN. Example: TCP://M-SQLA1.lab1.ad:5022.

With this configuration the Instance communication will be done over the “Public” Network”

This part will be done for the AAG-1 and the AAG-2 (Instance AOI1 and AOI3).

To configure instance for communicate over the Replication Network, we have to create the Endpoint and specify an IP address of the replication network for each instance and configure the Endpoint URL with this IP for each Replica.

This part will be done for the AAG-3 and the AAG-4 (Instance AOI2 and AOI4).

For reminder, there is only one Endpoint per Instance (can be used for multiple Availability Group).

 

 

Create AAG-1 (Instance AOI1 & AOI3)

Ok, now I create the first AAG (DBTest01 is the AdvWorks1 database added before)

Schema - AlwaysOn Availability Groups - AAG 1

Schema: AlwaysOn Availability Groups – AAG 1

From M-SQLA1, start Management Studio, connect to instance AOI1.

Right-click on “Availability Group” and select “New Availability Group Wizard”:

Specify the AAG name (this will be the WSFC Resource Group name):

Select the DB:

Select “Add replica”

Connect to the AOI3 instance:

Enable “Automatic Failover” (Synchronous Commit must be enabled) and configure the “Readable Secondary Option” (For more information about parameters see chapter “Availability Replicas Configuration” in “Part 2 – AlwaysOn – Lab Design“)

Configure Endpoints (Default URL = Server FQDN => Communication on the Public network):

Configure “Backup Preferences” (this is the default option):

Create the Listener:

(When you configure later applications to host their Databases in the AAG you have to specify this Listener DNS Name and the Port, this is the only information known by applications).

Note: The Listener VCO and DNS record must be prestage (see chapter “Prestage – Availability Group Listener” in article “Part 6 – Create AAG“)

Select “Full” for the initial data synchronizatrion:

Note: If the default Database paths (file and log) are not the same on all instances, the Full mode will not work.

For more information see paragraph “Note for Databases/Logs path on AAG” in the chapter “Storage” on “Part 2 – AlwaysOn – Lab Design

More information on Data Synchronization Page:

Select Initial Data Synchronization Page (AlwaysOn Availability Group Wizards)

http://msdn.microsoft.com/en-us/library/hh231021.aspx

 

Manually Prepare a Secondary Database for an Availability Group (SQL Server)

http://msdn.microsoft.com/en-us/library/ff878349.aspx


Click on “Script” and save it and start the creation:



Check AAG

Now you can start the Dashboard to check the Status of AAG:

Note: Requires Permissions to use Dashboard:

  • –  CONNECT
  • –  VIEW SERVER STATE
  • –  VIEW ANY DEFINITION

 

And via the WSFC Console, you can show the availability group resource group status:

Note: Normally you should not use the WSFC Console to administer AlwaysOn Availability Groups. Everything (failover …) must be done via the Dashboard, Transact-SQL or PowerShell. The WSFC Console provides a view of the cluster state.

 

 

Create AAG-2 (Instance AOI1 & AOI3)

So now I will create the second Availability Group (on the same node as AAG-1).

At the end, there will be an active database on each instance with a replica on each other side. So the loss of an instance will be supported.

 

Schema - AlwaysOn Availability Groups - AAG 2

Schema: AlwaysOn Availability Groups – AAG 2

From Instance M-SQLA3\AOI3

 

Create a test DB with one table:


-- CREATE DATABASE DBTestAOI3 --------------------------------------------------------------
USE master;
GO
CREATE DATABASE DBTestAOI3
ON
( NAME = DBTestAOI3_Data,
FILENAME = 'G:\MSSQL\AOREPLICA\Data\DBTestAOI3.mdf',
SIZE = 10MB,
MAXSIZE = 500MB,
FILEGROWTH = 1MB )
LOG ON
( NAME = DBTestAOI3_Log,
FILENAME = 'L:\MSSQL\AOREPLICA\Log\DBTestAOI3_log.ldf',
SIZE = 5MB,
MAXSIZE = 25MB,
FILEGROWTH = 5MB ) ;
GO

USE DBTestAOI3
GO

CREATE TABLE Servers (SrvID int IDENTITY (100,1) PRIMARY KEY, Name nvarchar (50))
GO
-- Populate Table
INSERT INTO Servers ([Name]) VALUES ('ServerAOI3-01')
INSERT INTO Servers ([Name]) VALUES ('ServerAOI3-02')
INSERT INTO Servers ([Name]) VALUES ('ServerAOI3-03')
GO

select * from servers

 

Do a full backup:


-- MAKE A FULL BACKUP -----------------------------------------------------------------------
USE master
GO
BACKUP DATABASE DBTestAOI3 TO DISK = 'G:\MSSQL\MSSQL11.AOI3\MSSQL\Backup\DBTestAOI3.bak'
GO

 

Create the AAG-2

Enter AAG name:

Select the database:

Add the replica M-SQLA1\AOI1

Note that you cannot change the name or port of Endpoints (there was previously created with the first AAG):

Configure Backup Preferences:

Configure the Listener:

Select Initial synchronization option:

Start the Availability Grou pcreation :

So now, the two AAG are created:

 

Network Note:

We can see that the Instances communications are established on the Public Network (10.0.1.0), this is due to the endpoints configuration:

 

Share Note:

The network share specify in the “Initial synchronization” page contains backup of Databases added to the AG. These backups can be removed, there are used only for the initial replica creation.

The post AlwaysOn Availability Groups Creation appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-availability-groups-creation/feed/ 0 1455
AlwaysOn Availability Group Install SQL Server Core https://www.tech-coffee.net/alwayson-availability-group-install-sql-server-core/ https://www.tech-coffee.net/alwayson-availability-group-install-sql-server-core/#comments Mon, 28 Apr 2014 18:29:17 +0000 https://www.tech-coffee.net/?p=981 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Availability Group Install SQL Server Core appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:

 


 

 

 

This part covers the installation of SQL Server on Core node (with the creation of a SQL Configuration INI file).

Requirements

MSA AD Account

In Part 3, I created this group/account:

  • –  lab1\SQLAlwaysOnAdmins
  • –  lab1\sqlaoinstall

Now, I need to create the MSA accounts for each node.

(Note: You can find PowerShell scripts used for this part here)

MSA Account for Instance 1:

From a DC, start PowerShell (run as Administrator) with a Domain Admin account.

Creates new managed service accounts and restrict its use to a single computer:

New-ADServiceAccount -Name svc-sqldbe1 -RestrictToSingleComputer -Description "SQL MSA"
New-ADServiceAccount -Name svc-sqlagt1 -RestrictToSingleComputer -Description "SQL MSA"
New-ADServiceAccount -Name svc-sqlbws1 -RestrictToSingleComputer -Description "SQL MSA"

Associate MSA accounts with the target SQL Server:

Add-ADComputerServiceAccount -Identity M-SQLA1 -ServiceAccount svc-sqldbe1
Add-ADComputerServiceAccount -Identity M-SQLA1 -ServiceAccount svc-sqlagt1
Add-ADComputerServiceAccount -Identity M-SQLA1 -ServiceAccount svc-sqlbws1


View Service Account associate to a Server:

Get-ADComputerServiceAccount -Identity m-sqla1 | ft name,samaccountname,enabled -AutoSize


You can see MSA accounts from “Active Directory Users and Computers” console:


Go to the SQL Server (M-SQLA1) (you must be connected with a Domain Admin account):

  • –  Install the AD PowerShell Module
  • –  Install MSA accounts previously created
Install-WindowsFeature RSAT-AD-PowerShellInstall-ADServiceAccount svc-sqldbe1
Install-ADServiceAccount svc-sqlagt1
Install-ADServiceAccount svc-sqlbws1


Repeat the Operation for all nodes:

  • M-SQLA2, M-SQLA3, M-SQLA4



 

TechNet Resources:

 

Security Note for Service Accounts

If you are using a standard AD Account (not a MSA), you have to Assign “Deny logon locally” right to SQL service accounts (through secpol.msc or GPO) on each node.

And from AD, you have to assign “Deny permissions to log on to Remote Desktop Session Host server’:

With MSA, these steps are not necessary.

 

 

Install First SQL Server

The installation of SQL can be fully automated via an INI answer file. To prepare the INI file, I will install the first server via the wizard.

Note: Normally, to create the INI file I use the SQL Installation Wizard and I cancel it just before the installation.

First download the last Cumulative Update for SQL and copy it on the server. (To check the last CU available: http://support.microsoft.com/kb/2772858/en-us)

From first node (M-SQLA1), connect with sqlaoadm account; launch the SQL Setup (with the CU included):

CMD
Setup.exe /Action=Install /UpdateEnabled=TRUE /UpdateSource=“E:\CU”

Note: By default Setup will search update on Microsoft Windows Update (require Internet access), this is equivalent to “/UpdateSource=MU” parameter.

Update retrieve from local path:

Select Features:

  • Database Engine Services
  • Full-Text Search (needed for SCOM Databases)
  • Management Tools – Complete

Select “Named instance” and enter name and path:

Disk space requirements:

Configure Service account (MSA, add a “$” at the end of account name) and Startup Type:

Set Collation to (this is the collation required for System Center Product): SQL_Latin1_General_CP1_CI_AS

I use “Mixed Mode” to keep the sa account as “lifeboat account”, but for security I rename the sa account later.

Add the “SQLAlwaysOnAdmins” group:

Set paths:

Start installation :

 

Automate Installation

Prepare SQL Setup INI File

Retrieve ConfigurationFile.ini from previous installation (M-SQLA1), path:

C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\20xxxxxx_110110

 

Edit the file and do the following modifications:

Installation Options:

Remove:

  • –  UIMODE=”Normal”
  • –  QUIET=”False”

Modify:

  • –  QUIETSIMPLE=”True” (Original value: False)
    (Setup will display progress only, without any user interaction)

Add:

  • –  IAcceptSQLServerLicenseTerms=”True”
    (Accept the License agreement to continue with Installation)

Feature Options:

Modify:

  • –  FEATURES=SQLENGINE,FULLTEXT

Removed feature:

  • –  SSMS: Management Tools – Basic
  • –  ADV_SSMS: Management Tools – Complete

 

Path Options:

Add:

  • –  INSTALLSQLDATADIR=”C:\MSSQL”
    (Specifies the data directory for SQL Server data files)
    Default values:

    • *  For WOW mode on 64-bit:%Program Files(x86)%\Microsoft SQL Server\
    • *  For all other installations:%Program Files%\Microsoft SQL Server\

     

Note – Parameters Path

Do not confuse these two parameters: “INSTALLSQLDATADIR” and “INSTANCEDIR”.

 

Example Result:

; Specify the installation directory. (Contains binary files)

INSTANCEDIR=”C:\MSSQL”

; Specify the Data directory for SQL Server data files (Contains System Databases, Logs, JOBS, FTData)

INSTALLSQLDATADIR=”C:\MSSQLDATADIR”

 

Note – About COMMFABRIC Parameters

When you retrieve an INI file generates by SQL Wizard, there are these parameters (not listed in the TechNet article):

; CM brick TCP communication port
COMMFABRICPORT=”0″
; How matrix will use private networks
COMMFABRICNETWORKLEVEL=”0″
; How inter brick communication will be protected
COMMFABRICENCRYPTION=”0″
; TCP port used by the CM brick
MATRIXCMBRICKCOMMPORT=”0″

These parameters are for Microsoft internal tests and can be removed:

http://connect.microsoft.com/SQLServer/feedback/details/741274/new-switches-in-sql-2012-command-line-install-are-not-documented

 

Now the file is ready to be used in silent installation (and in addition on a core server, without Management Tools features)

 

INI File (M-SQLA1\AOI1):

INI

;SQL Server 2012 Configuration File
[OPTIONS] ; INSTALL OPTIONS———————————————————————-
ACTION=“Install”
ENU=“True”
QUIETSIMPLE=“True”
;Specifies that the detailed Setup log should be piped to the console.
INDICATEPROGRESS=“FALSE”
HELP=“False”
X86=“False”
IACCEPTSQLSERVERLICENSETERMS=“True”
SQMREPORTING=“False”
ERRORREPORTING=“False”
ENABLERANU=“False”
FILESTREAMLEVEL=“0”
; Updates:
UPDATEENABLED=“True”
UPDATESOURCE=“L:\SQLCU”
; FEATURE OPTIONS———————————————————————————-
FEATURES=SQLENGINE,FULLTEXT
;To Add Management Tools (not compatible on core installation):

;FEATURES=SQLENGINE,FULLTEXT,SSMS,ADV_SSMS

;    SSMS    : SQL Server Management Tools – Basic

;    ADV_SSMS: SQL Server Management Tools – Complete

;Path —————————————————————————————–

INSTALLSQLDATADIR=“C:\MSSQL”

INSTANCEDIR=“C:\MSSQL”

INSTALLSHAREDDIR=“C:\Program Files\Microsoft SQL Server”

INSTALLSHAREDWOWDIR=“C:\Program Files (x86)\Microsoft SQL Server”

; Instance ——————————————————————————

INSTANCENAME=“AOI1”

INSTANCEID=“AOI1”

SQLCOLLATION=“SQL_Latin1_General_CP1_CI_AS”

; Service – SQL Server

SQLSVCACCOUNT=“lab1\svc-sqldbe1$”

SQLSVCSTARTUPTYPE=“Automatic”

; Service – Agent

AGTSVCACCOUNT=“lab1\svc-sqlagt1$”

AGTSVCSTARTUPTYPE=“Automatic”

; Service – Browser Service

BROWSERSVCSTARTUPTYPE=“Disabled”

; Service – Full-Text Search

FTSVCACCOUNT=“NT Service\MSSQLFDLauncher$AOI1”

; Default Path – Database Engine user databases

SQLUSERDBDIR=“G:\MSSQL\AOREPLICA\Data”

SQLUSERDBLOGDIR=“L:\MSSQL\AOREPLICA \Log”

; Default Path – Database Engine backup files

SQLBACKUPDIR=“G:\MSSQL\MSSQL11.AOI1\MSSQL\Backup”

; Path – Database Engine TempDB files.

SQLTEMPDBDIR=“G:\MSSQL\MSSQL11.AOI1\MSSQL\TempDB\Data”

SQLTEMPDBLOGDIR=“L:\MSSQL\MSSQL11.AOI1\MSSQL\TempDB\Log”

; Protocol – TCP/IP (0=disable – 1=enable)

TCPENABLED=“1”

; Protocol – Named Pipes (0=disable – 1=enable)

NPENABLED=“0”

; Security ——————————————————————————

; SQL Server system administrators.

SQLSYSADMINACCOUNTS=“LAB1\SQLAlwaysOnAdmins”

; Authentication Mode (SQL=Mixed Mode)

SECURITYMODE=“SQL”

; Provision current user as a system administrator

ADDCURRENTUSERASSQLADMIN=“False”

 

 

Setup command line

All configuration parameters are set in the INI file except the passwords for Security reason.

So to set password we have to use argument on the setup.exe.

We need to add to command line:

 

  • *  /SQLSVCPASSWORD=”xxxxxxxxx”

Specify the password for the SQL Database Engine service account

  • *  /AGTSVCPASSWORD=”xxxxxxxxx”
    Specify the password for the SQL Server Agent service account
  • *  /SAPWD=”xxxxxxxxx”

    Specifies the password for the SQL Server sa account

 

For information, bellow the argument for manage services configuration (account, password, startup type):

SQL Server component

Account parameter

Password parameter

Startup type

SQL Server Agent /AGTSVCACCOUNT /AGTSVCPASSWORD /AGTSVCSTARTUPTYPE
Analysis Services /ASSVCACCOUNT /ASSVCPASSWORD /ASSVCSTARTUPTYPE
SQL Server Database Engine /SQLSVCACCOUNT /SQLSVCPASSWORD /SQLSVCSTARTUPTYPE
Integration Services /ISSVCACCOUNT /ISSVCPASSWORD /ISSVCSTARTUPTYPE
Reporting Services /RSSVCACCOUNT /RSSVCPASSWORD /RSSVCSTARTUPTYPE
Full-Text Search /FTSVCACCOUNT /FTSVCPASSWORD n/a

Startup type values:

  • Automatic
  • Manual
  • Disabled

For more information, see TechNet article “Install SQL Server 2012 from the Command Prompt“: http://msdn.microsoft.com/en-us/library/ms144259.aspx

 

 

Prepare INI file for other nodes

Copy the INI file prepare before for each Server installation. Edit the file and replace the Instance name (with the other instance, in my case AOI2, AOI3 and AOI4):

INSTANCENAME=”AOI1
INSTANCEID=”AOI1
FTSVCACCOUNT=”NT Service\MSSQLFDLauncher$AOI1
SQLBACKUPDIR=”G:\MSSQL\MSSQL11.AOI1\MSSQL\Backup”
SQLTEMPDBDIR=”G:\MSSQL\MSSQL11.AOI1\MSSQL\TempDB\Data”
SQLTEMPDBLOGDIR=”L:\MSSQL\MSSQL11.AOI1\MSSQL\TempDB\Log”

 

Install SQL Server on Core Nodes

Do this operation for all nodes (in this lab m-sqla2/ m-sqla3/ m-sqla4).

Connect to M-SQLA2 with sqlaoadm account

  • *  Copy the INI configuration file to L:
  • *  Check Volumes
  • *  Copy Cumulative Update in the location specify in the parameter: UpdateSource
  • *  Mount SQL Server ISO
  • *  Launch a CMD in as Administrator

 

Launch installation:

Setup.exe /SQLSVCPASSWORD=“xx” /AGTSVCPASSWORD=“xx” /SAPWD=“xx” /ConfigurationFile=“L:\SQLConfigCore.ini”

 

Configure Instances

Done the following configurations on all Instances:

Configure – Instance TCP Port

TCP Dynamic Ports = 0, indicate that the Database Engine is listening on dynamic ports, on a named-instance TCP Dynamic Ports it’s enabled by default:

 

Configure Instance Static Port via Console (SQL Server Configuration Manager)

In “SQL Server Configuration Manager“, go to SQL Server Network Configuration\Protocols for <instance>\TCP/IP properties.

To set a Static Port:

  • *  Delete “TCP Dynamic Ports” value 0 for all IP (IP1, IP2, …)
  • *  On IPALL clean the “TCP Dynamic Ports” value
  • *  On IPALL enter you Static port in “TCP Port” Field
  • *  Restart SQL Server Service

Configure Instance Static Port via PowerShell

  • *  2 – Edit the script “SQL_Set-Instance-Port.ps1” (set ServerName, Instance and Port) and execute it (with Administrator rights):

  • *  3 – Check configuration (SQL_Get-Instance-Network-Cfg.ps1):

Restart SQL Instance service

Get-Service -Name ‘MSSQL$AOI1’ | Restart-Service

Check configuration from console:


Information/Note:

NOTE Check if Instance is listening on the defined port
Use netstat:

 

NOTE Retrieve TCP Configuration from Registry
Go to : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<InstanceName>\MSSQLServer\SuperSocketNetLib\Tcp

 

NOTE View Windows Dynamic Port range configuration
netsh int ipv4 show dynamicport tcpSo Range is: 49152 to 65535

 

Configure Instance Memory

The memory configuration depends of your environment (if SQL Server is mutualized, number of instance …). I will not cover this part in this article. But in this lab, Servers are dedicated to SQL and there is only one instance per servers, so I allow SQL to use memory dynamically (default option).

 

For more information about memory configuration see TechNet article “Server Memory Server Configuration Options“: http://technet.microsoft.com/fr-fr/library/ms178067.aspx

 

Configure TempDB

This article does not cover TempDB Tuning, but you can read note in “Part 2 – Lab Design“.

 

Get Number of Cores:

Transact-SQL

SELECT cpu_count FROM sys.dm_os_sys_info;

 

If you need to add additional TempDB files:

Transact-SQL

ALTER DATABASE [tempdb] ADD FILE (NAME = N’tempdev2′, FILENAME = N’G:\MSSQL\MSSQL11.AOI1\MSSQL\TempDB\Data\tempdb2.ndf’, SIZE = 10GB, FILEGROWTH = 10%)

 

Note: A recommendation is that all TempDB files must have the same size. So to do this you have to disable autogrowth for all files (during creation: FILEGROWTH = 0) and set the right size to all TempDB.

List Database Files:

Transact-SQL

SELECT MF.database_id AS [DB ID],SD.name AS [DB Name], MF.name AS [Logical Name], MF.physical_name AS [Physical Name], MF.type_desc as [Type], MF.state_desc AS [State], (MF.size*8)/1024 AS [Size MB],growthFROMsys.master_files MF, sys.sysdatabases SDwhere MF.database_id = SD.dbid AND SD.name = ‘tempdb’

 

Another way to list Database Files:

Transact-SQL

USE
TempDB
GO
EXEC
sp_helpfile
GO

 

Instance – Enable AlwaysOn

Now we can enable the “AlwaysOn Availability Groups” feature on the instance.

Note: This option is only available if the server if member of a WSFC cluster.

1 – Via Console

From “SQL Server Configuration Manager” console edit the “SQL Server (<instance>)” service properties. In the “AlwaysOn High Availability” tab, check the box “Enable AlwaysOn Availability Groups“.

2 – Via PowerShell

PowerShell Command:

Enable-SqlAlwaysOn -ServerInstance “$SQLServer\$SQLInstance” -Force

(-force remove user confirmation; command automatically restart instance)

Use script SQLAO_Enable-AlwaysOn-Feature.ps1

 

NOTE Retrieve SQL Server Property with Transact-SQL
AlwaysOn Availability Group Property:

IsHadrEnabled Description
1 AlwaysOn Availability Groups is enabled
0 AlwaysOn Availability Groups is disabled

 

SELECT SERVERPROPERTY (‘IsHadrEnabled’);

 

 

Security

 

Rename – System Administrator (sa) account

For Security, rename “sa” account:

–Rename Account

ALTER LOGIN sa WITH NAME = [9wadm]

 

NOTE Retrieve “System Administrator” account name with SID (Transact-SQL)
— Retrieve “sa” account name with SID
SELECT sid,name,dbname,sysadmin,loginname FROM sys.syslogins WHERE sid = 0x01

— Change “sa” password
ALTER LOGIN sa WITH PASSWORD = ‘password’

 

Configure – Login Audit

By default, audit is active for Failed “Logins only”, to monitor all connection set the audit to “Both failed and successful logins”:

I use two scripts:

 

Next

Connect on all instances from M-SQLA1.

Now the four instances are ready !

 

Create Remote SQL Configuration Manager MMC

From the management server (here m-sqla1) I create all “SQL Configuration Manager” consoles for all server (core or not) I have to managed.

From M-SQLA1, launch mmc in Author mode:

Add “Computer Management” and select a remote server:

Select “New Window from Here”:

Switch back to the “Computer Management” console (Window\1 Console Root) and close it:


On the File menu, click Save As, and save the mmc. Close the MMC.

 

Next

Now the cluster and all SQL nodes are OK, the next part covers the creation of the first two Availability Group: AlwaysOn Availability Goup – Part 6 – Create first two AAG

 

The post AlwaysOn Availability Group Install SQL Server Core appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-availability-group-install-sql-server-core/feed/ 2 981
AlwaysOn Availability Group WSFC Cluster Creation https://www.tech-coffee.net/alwayson-availability-group-wsfc-cluster-creation/ https://www.tech-coffee.net/alwayson-availability-group-wsfc-cluster-creation/#comments Sun, 27 Apr 2014 16:15:47 +0000 https://www.tech-coffee.net/?p=913 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Availability Group WSFC Cluster Creation appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:

 


This part cover the configuration of the WSFC Cluster required for the AlwaysOn Availability Group.

 

WSFC Node Updates [Note]

In addition to WSUS update, you have to check Hotfix/Rollup for WSFC Cluster:

WS2012 R2
  • Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters: http://support.microsoft.com/kb/2920151/en-us

Or on this article from the TechNet Blog “The troubleshooters and problem”

 

WS2012

 

WS2008 R2 SP1

 

AlwaysOn – Prerequisites

Install Windows Features

On all nodes install “.NET 3.5” and “Failover Clustering” features:

Add “Failover Clustering Administration Tools”:

Note: Only “Failover Cluster Module for PowerShell” is available on core node.

Or installation via PowerShell:

PowerShell

# For remote install add: -Computer <Hostname>
Install-WindowsFeature Net-Framework-Core -source V:\sources\sxs
Install-WindowsFeature Failover-Clustering -IncludeManagementTools# ‘-IncludeManagementTools’ includes:# * Failover Cluster Management Tools
# * Failover Vluster Module for Windows PowerShell

 

 

 

WSFC Cluster – Creation

During the WSFC Cluster creation a CNO (Cluster Name Object) is created in Active Directory. This operation requires specific AD right.

There are three options:

  • Give Active Directory right “Create Object” to the SQL Admin account which you plan to create the WSFC Cluster.

 

From M-SQLA1, launch “Failover Cluster Manager” console:

Launch “Validate Configuration”:

Add all SQL AlwaysOn nodes:

Do the Validation tests:

Check “Create the cluster now…”:

Enter Cluster name and add an IP (on the Public VLAN):

Note: Cluster Name and IP are used for management and Cluster operations. These resources are known as “Cluster Core Resources”.

Create Cluster:

Check nodes status:

 

 

WSFC Cluster – Configuration

Configure Networks

Rename each Cluster Network and configure Communications allowed.

 

Network Communications
Public Cluster and Client
Heartbeat Cluster Only
Replication None

 

 

Configure Quorum

In this example I do not use a Witness. I use only the Dynamic Quorum mode (enabled by default).

Be careful, because Dynamic Quorum works fine as long as the nodes go down one by one. If multiples nodes fail at the same time (e.g.: the loss of a datacenter), the Dynamic Quorum may have malfunction (no recalculate vote). I will do further tests in a future article.

So for Production environment it’s recommended to use a Witness.

Configure Quorum:

 

 

NOTE Create WSFC Cluster through PowerShell

PowerShell

# Run “Validate Configuration and Open Report
$clustreportPath = “D:\Reports\TestClusterReport_xxx-xx-xx”
Test-Cluster -ReportName $clustreportPath
Invoke-Item $clustreportPath
# Create Cluster
$ClustVIP = “10.0.1.25”
$ClusterName = “CN=clustsqlao1,OU=Clusters,DC=lab1,DC=ad”
write-host “Create Cluster: $($ClusterName)”
New-Cluster -Name $ClusterName -StaticAddress $ClustVIP -NoStorage -Node “M-SQLA1”,“M-SQLA2”,“M-SQLA3”,“M-SQLA4”
#Check Cluster Creation
$clust = Get-Cluster 2> $null
if ($clust -eq $null) { Write-Warning “Cluster not found” }
else {Get-ClusterNode}

 

Quorum Configuration Note

Dynamic Quorum is a new feature came with Windows Server 2012.

When Dynamic Quorum is enabled (by default) , the cluster dynamically manages the vote assignment to nodes, based on the state of each node. Votes are automatically removed from nodes that leave active cluster membership, and a vote is automatically assigned when a node rejoins the cluster.

Get the Quorum Type:

PowerShell

Get-ClusterQuorum | fl *

 

Check if Dynamic Quorum is enabled:

PowerShell

Get-Cluster | ft name,dynamic* -Autosize

 

View the “Dynamic Node Weight” status for nodes:

PowerShell

Get-ClusterNode | ft name,*weight,id,state -Autosize

 

 

Property Description
DynamicWeight This is the node weight manage by “Dynamic Quorum”. If a node is failed, DynamicWeight = 0
NodeWeight This is the “hard” configuration, for example you can decided that nodes on a DR site will not have a vote, so in this case NodeWeight = 0.

 

For more information about Quorum Configuration see TechNet Article:

Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster

http://technet.microsoft.com/fr-fr/library/jj612870.aspx

 

NOTE Retrieve “NodeWeight” from SQL (Transact-SQL)
SELECT member_name, member_state_desc, number_of_quorum_votes
FROM sys.dm_hadr_cluster_members;

 

 

Guest Cluster Virtualization Configuration

This part is for Hyper-V Hypervisor, I will add later configuration for VMware vSphere.

 

Hyper-V – Heartbeat configuration

On Hyper-V, during a Live Migration of a node, the Cluster resources (in our case the AAG) can failover to another node. The configuration bellow is for tuning WSFC Cluster on a multi-site environment or on a virtualized environment

What’s happen:

WSFC nodes send heartbeat packets to other nodes of the cluster. The default port for cluster communication is TCP\UDP 3343.

If a node does not receive a response from another node for a specified period of time, the cluster removes the node from cluster membership. By default, a cluster node is considered down if it does not respond within 5 seconds. In this case another node will initiate failover

At the end of a Live Migration, the VM is stopped on the original Hyper-V host and begins to start on the destination host. During this short time, the VM node may exceed the Heartbeat threshold and so a failover starts. (Note: With the 2012 R2 version, “Live migration” has been improved. Migration is faster and after several migration tests of SQL node the Availability Group have not failover).

To prevent this problem, you have to increase the Threshold (there are two parameters, one for Cluster on same subnet, and one for cross-subnet):

Parameter Default Value Range Configuration needed
SameSubnetThreshold 5 heartbeats 5 <> 120 heartbeats 20 heartbeats
CrossSubnetThreshold 5 heartbeats 5 <> 120 heartbeats 20 heartbeats

Retrieve Cluster configuration

get-cluster | fl name, samesubnet*,crosssubnet*

Change values (in my lab same subnet):

(Get-Cluster).SameSubnetThreshold = 20

 

 

For information:

You can also configure Heartbeat Frequency.

By default, regardless of subnet configuration, heartbeat frequency is once every second (1000 milliseconds). So with the configuration above, we have 20 x 1000 = 20 seconds before node becomes unavailable for the cluster (This is the Microsoft recommendation for Hyper-V).

Heartbeat frequency:

Parameter Default Value Range
SameSubnetDelay 1000 ms 250 <> 2000 ms
CrossSubnetDelay 1000 ms 250 <> 4000 ms

 

Hyper-V – Place SQL VM Nodes on Different Physical hosts

For guest clustering, if you have multiple Hyper-V hosts in cluster you have to host VM on different physical hosts. To prevent that the VMs do not end up on the same host (during Live Migration or PRO operation) you have to configure the Anti-Affinity rules on Hyper-V (AntiAffinityClassNames Paramerter).

View Anti-Affinity Rules

Get-ClusterGroup | Select AntiAffinityClassNames

 

On the first Hyper-V Cluster:

$ColAntiAffinity = New-Object System.Collections.Specialized.StringCollection

$ColAntiAffinity.Add(“GuestClust-AlwaysOn”)

(Get-ClusterGroup -Name M-SQLA1).AntiAffinityClassNames = $ColAntiAffinity

(Get-ClusterGroup -Name M-SQLA2).AntiAffinityClassNames = $ColAntiAffinity

 

Repeat the operation on the second Hyper-V Cluster for M-SQLA3 and M-SQLA4 nodes.

 

Prestage – Availability Group Listener

Active Directory

The Availability Group Listeners are register as Cluster Resources and so in Active Directory as VCO (Virtual Computer Object). As the CNO (Cluster Name Object), we have to prestage these VCO and give the appropriate permissions.

With a Domain Admin account, launch the “Active Directory Users and Computers console
Click on the “View” menu and select “Advanced Features”.

Go to the OU where there is the AlwaysOn cluster CNO, and create a new computer:


Enter the Listener name:

Edit Properties of the created VCO, add a description, go to the “Security” tab and add the AlwaysOn cluster CNO (here: clustsqlao1), under Permissions allow “Full Control”

Repeat operation for all Listeners:

 

DNS (Integrated in AD)

Launch the DNS console, go to you domain zone, and create an new Host (A or AAAA):

Enter the Listener Name and the IP Address:

Repeat the operation for all Listener :

 

Allow the Cluster Name Object (CNO) to update DNS records:

Note: This configuration must be done DNS is integrated to Active Directory.

Edit the properties of record created previously:

Go to the “Security” tab and add the CNO, give the Full Control permissions:

Repeat the operation on all Listeners DNS records.

Next

The next part covers the installation of SQL Server on Core node (automated through unattened INI file): AlwaysOn Availability Group – Part 5 – Install SQL Core Server

The post AlwaysOn Availability Group WSFC Cluster Creation appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-availability-group-wsfc-cluster-creation/feed/ 5 913
AlwaysOn Availability Group Install WS2012 R2 Core Server https://www.tech-coffee.net/alwayson-availability-group-install-ws2012-r2-core-server/ https://www.tech-coffee.net/alwayson-availability-group-install-ws2012-r2-core-server/#respond Sun, 27 Apr 2014 15:28:47 +0000 https://www.tech-coffee.net/?p=852 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Availability Group Install WS2012 R2 Core Server appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:


This part covers the installation and configuration of Windows Server 2012 R2 Core.

 

Virtual Machine

Create the four SQL Servers and configure the three Network adapters and the three Virtual disks:

   

AD Account

Create Group:

  • lab1\SQLAlwaysOnAdmins

Create accounts:

  • lab1\sqlaoinstall

Add your account and sqlaoinstall account to SQLAlwaysOnAdmins Group. This is not mandatory but I recommend using an “Install account” for environments installation.

 

Server Installation – 1st Node

Install and Configure a WS2012 R2 Server

Server: M-SQLA1

  • Install WS2012R2 (in full GUI mode). For reminder this server will be used for management (consoles, …)
  • Configure Network

Note about IPv6 for WSFC Cluster

For Cluster network you can disable IPv6 protocol, but by default the heartbeat mechanism prefer use first IPv6 addresses. Now on WS2012, it’s not recommended to disable IPv6.

Note for Cluster and Replication NIC

Disable “Register this connection’s addresses in DNS”

  • Configuration: Do the same configuration as the Core server bellow.

 

Core Server Installation – Three other Nodes

Servers: M-SQLA2, M-SQLA3, M-SQLA4

Install and Configure a Windows Server 2012 R2 Core Server

 

Configure all Nodes

All commands bellow are in the script: “WSCoreNode-Configuration.ps1.

Configure Network

List NIC:

Identify NIC, retrieve MAC address from Hyper-V:

 

Rename Network Adapter

Rename-NetAdapter -Name "Ethernet" -NewName "eth1-public"

Repeat operation for “Ethernet 2” and “Ethernet 3”:

Set IP Address

Note: Option -Gateway <IP>new

New-NetIPAddress -InterfaceAlias "eth1-public" -IPAddress 10.0.1.24 -PrefixLenght 24

 

Repeat Operation for “eth2-cluster” and “eth3-replication” NICs:

# NIC Cluster
New-NetIPAddress -InterfaceAlias "eth2-cluster" -IPAddress 10.0.10.24 -PrefixLenght 24
#NIC Replication
New-NetIPAddress -InterfaceAlias "eth3-replication" -IPAddress 10.0.20.24 -PrefixLenght 24

Set DNS

To set multiple DNS: “-ServerAddresses 10.0.1.1, 10.0.1.2”

 

Configure Protocols

Retrieve Protocol status:

Get-NetAdapterBinding -InterfaceAlias "eth1-public"

 

NIC “eth1-public”:

I disable “Link-Layer Topology …” and “IPv6” protocols.

Disable-NetAdapterBinding -InterfaceAlias "eth1-public" -ComponentID ms_rspndr, ms_lltdio, ms_tcpip6

 

Repeat Operation for “eth2-cluster”:

Disable “Link-Layer Topology …” and “QoS” protocols.

Disable-NetAdapterBinding -InterfaceAlias "eth2-cluster" -ComponentID ms_rspndr, ms_lltdio, ms_pacer

Repeat Operation for “eth3-creplication”:

Disable “Link-Layer Topology …”, “QoS”, and “IPv6” protocols.

Disable-NetAdapterBinding -InterfaceAlias "eth3-replication" -ComponentID ms_rspndr, ms_lltdio, ms_pacer, ms_tcpip6

Enable Remote Desktop

Method 1 – From SCONFIG

Go to “7”:

 

Method 2 – From PowerShell

Enable Remote Desktop:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server'-name "fDenyTSConnections" -Value 0

Enable Secure Connections:

set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name "UserAuthentication" -Value 1

Enable Firewall Exception:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Check:

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server'-name "fDenyTSConnections"
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name "UserAuthentication"

 

Check Firewall:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | ft displaygroup,displayname,enabled,profile -AutoSize

 

Configure Firewall

This configuration can be done (and it’s better) though AD GPO. Commands bellows are for information or for lab environment.

 

Enable Firewall Remote Management

Show CurrentProfile:

netsh advfirewall show currentprofile settings


Enable Remote Management:

netsh advfirewall set domainprofile settings remotemanagement enable


This enables rules:

NOTE To disable Remote Management (netsh)
netsh advfirewall set currentprofile settings remotemanagement disable

 

Enable Remote Management Rules

I use script “FW_Enable-GroupRules-RM.ps1” to enable this rules:

 

 

NOTE Enable Remote Management rules (netsh/powershell)

Set-NetFirewallRule -DisplayGroup “Remote Service Management” –Enabled True -Profile “Domain,Private”

Or via netsh

netsh advfirewall firewall set rule group=”Remote Shutdown” new enable=yes

 

Check the Remote Management Rules:

Get-NetFirewallRule -DisplayGroup “Remote *” | ft displaygroup,displayname,enabled,profile -AutoSize

 

Create Firewall Rules for SQL

You have to create these inbound rules:

Protocol Port Name Note
TCP

1764

Instance and VNN Port  
TCP

5022

Instance SQL Endpoint User for AAG communication

 

Script: FW-Create-Rules-AOLab.ps1

Script overview:

#SQL Server Firewall RULES
#VAR
$Profile = “Domain,Private”
$RuleGroup = “SQL”

#Rule: INBOUND – Allow Instance/VNN Port
$RuleName = “SQL Database Engine – Instance/VNN (TCP 1764)”
$LocalPort = 1764
$Protocol = “TCP”
$Action = “Allow”
New-NetFirewallRule -Group $RuleGroup -DisplayName $RuleName -Direction Inbound -Protocol $Protocol -LocalPort $LocalPort -Action $Action -Profile $Profile | out-null

# ...

Other SQL Ports:

Protocol Port Name Note
UDP

1434

SQL Browser Service Browser Service listens for incoming connections to a named instance and provides the client the TCP port number that corresponds to that named instance.

Browser will be disabled.

For more information (other port for SSRS, AS …) see TechNet article “Configure the Windows Firewall to Allow SQL Server Access“: http://msdn.microsoft.com/en-us/library/cc646023.aspx

 

Join Server to Domain

Rename-Computer -NewName xxxx


Add-Computer -DomainName domain.local -DomainCredential (Get-Credential)

Restart-Computer

 

Add account to Local Administrators Group

 

 Add AD Group to local Administrators group:

CMD

net localgroup administrators /add lab1\SQLAlwaysOnAdmins
List members of a Local Group:
net localgroup administrators

 

Or via PowerShell:

PowerShell

#Add an account/group:

([ADSI]“WinNT://localhost/Administrators,group”).psbase.Invoke(“Add”,([ADSI]“WinNT://lab1/SQLAdmins”).path)

#Remove an account/group:

([ADSI]“WinNT://localhost/Administrators,group”).psbase.Invoke(“Remove”,([ADSI]“WinNT://lab1/SQLAdmins”).path)

 

 

Add Route (optional)

I need route for RDP, this is the netsh command:

 

[Note] Remote Management

Now, we can remotely manage the server with consoles from another Server in Full-GUI mode.

Commands bellows are for information.

 

Configure DVD-Drive Letter

View the CD/DVD Drive Letter:

Get-WmiObject -Class Win32_CDROMDrive

 

Change Drive Letter:

(gwmi Win32_cdromdrive).drive | %{$a = mountvol $_ /l;mountvol $_ /d;$a = $a.Trim();mountvol v: $a}

Warning: This method function if there is only one CD/DVD Drive.

 

Configure update

Now the core server is joined to domain, I have GPO to set Update mode (Automatic during the night) and WSUS options.

List installed updates

wmic qfe

Force Update:

Copy this script to each core node:

http://msdn.microsoft.com/fr-FR/library/aa387102%28VS.85%29.aspx

And launch it (this script start a Windows Update session):

TechNet Resources:

Configure Automatic Updates by Using Group Policy
http://technet.microsoft.com/en-us/library/cc720539%28v=ws.10%29.aspx
Servicing a Server Core installation
http://technet.microsoft.com/en-us/library/ff698994%28v=ws.10%29.aspx
Searching, Downloading, and Installing Updates
http://msdn.microsoft.com/en-us/library/aa387102%28v=vs.85%29.aspx#fbid=kpO9Qceh-_Y

 

Core Servers deployment done!

 

[Note] Switch between Full-GUI/Minimal/Core interface

Command for switch between Full-GUI, Minimal, or Core mode

By default on core installation, “Server-Gui-Shell” and “Server-Gui-Mgmt-Infra” features are removed, so you have to specify the source files. To do that retrieve Index on the source WIM:

dism /get-wiminfo /wimfile:”v:\sources\install.wim”

To switch to Minimal interface:

Install-WindowsFeature Server-gui-mgmt-infra -Source wim:v:\sources\install.wim:2

To switch to Full interface:

Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra -Source wim:v:\sources\install.wim:2

 

To switch to Core interface:

Remove-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra

Note: you can use “-remove” option to delete binary files from local disk.

 

Manage all nodes from Server M-SQLA1

From M-SQLA1 (with full GUI mode), connected with lab1\sqlaoadm account, got to Server Manager and add the three core nodes.

Click “Add other servers to manage”:

Select the 3 other nodes:

 

Configure Volume for all nodes:

Note: For AAG the volume letter (for DB and Log) must be the same on all instance that participate to the AAG

If you want to use PowerShell, you can read this great article on Volume Management with PS:

http://blogs.technet.com/b/meamcs/archive/2012/04/06/windows-server-8-disk-management-with-powershell-3-0.aspx

 

Next

Now all nodes are ready, the next part covers the WSFC Cluster creation: Part 4 – AlwaysOn – WSFC Cluster Creation

The post AlwaysOn Availability Group Install WS2012 R2 Core Server appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-availability-group-install-ws2012-r2-core-server/feed/ 0 852
AlwaysOn Availability Group Design https://www.tech-coffee.net/alwayson-availability-group-design/ https://www.tech-coffee.net/alwayson-availability-group-design/#respond Sun, 27 Apr 2014 10:53:15 +0000 https://www.tech-coffee.net/?p=765 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Availability Group Design appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:

 


This part describe the design of the environment.

Article summary: SQL Server 2012-2014 AlwaysOn Availability Group

For the tests, I will create an “AlwaysOn Availability Group” cluster with four nodes and four AAG. Each AAG has two SQL Server Instance members, so each SQL node participate to two AAG.

The first two AAG will be used to host only test Databases. The other two will be used to host databases for SCOM 2012 R2 and SCO 2012 R2.

Schema AlwaysOn Availability Groups - Design - Multiple AAG - Replication Network

Schema: AlwaysOn Availability Groups Design with multiple AAG on four Nodes and a dedicated Network for Replication

AlwaysOn Cluster – Physical View

Schema - AlwaysOn Availability Groups Physical View (DataCenter Fault Tolerance)

Schema: AlwaysOn Availability Groups Physical View (DataCenter Fault Tolerance)

 

LAB Requirements

Three Networks are required.

vSwitch Description Subnet
vSwitch0-Public Client Access 10.0.1.0 /24
vSwitch1-Cluster Heartbeat 10.0.10.0 /24
vSwitch2-Replication AAG Replication 10.0.20.0 /24

Note: I use same subnet for all nodes, I’ll write an article for WSFC Cluster Administration/Troubleshoot which also cover cross-subnet configuration.

Infra server:

Server Description IP
M-DCDNS AD Root / DNS 10.0.1.1

 

SQL Servers / Instances Configuration

The lab will be composed on a four node WSFC cluster:

 

Hostname OS IP VLAN Public IP VLAN CLUSTER IP VLAN Replication Note
M-SQLA1 WS2012R2 10.0.1.21 10.0.10.21 10.0.20.21
M-SQLA2 WS2012R2-CORE 10.0.1.22 10.0.10.22 10.0.20.22
M-SQLA3 WS2012R2-CORE 10.0.1.23 10.0.10.23 10.0.20.23
M-SQLA4 WS2012R2-CORE 10.0.1.24 10.0.10.24 10.0.20.24
clustsqlao1 n/a 10.0.1.25 n/a n/a Cluster Resource Name

M-SQLA1 OS will be installed in full GUI mode with the SQL Feature “Management Tools – Complete” (include “Management Studio”; it’s not compatible with a Core installation). This server will be used to manage SQL AAG and WSFC cluster.

Note: In a production environment, all servers must be identical (all in core mode, or full/minimal) and a dedicated “management/tools” server with consoles is used for administration.

Best Practices and Recommendations
It’s recommended to use the Windows Server Core Installation option for setting up a SQL server environment (especially if it’s virtualized).
Advantages of a SQL Core installation:
  • reduce the space required on disk.
  • reduce the potential attack surface.
  • reduce the overhead of updating patches.
  • minimize the requirements for servicing and restarting the server.

 

We need to install one named-instance per SQL Server:

Server Instance Name Instance Port SQL Features
M-SQL1 aoi1 1764 SQL Database Engine
Full-Text Search (needed for SCOM)
M-SQL2 aoi2 1764
M-SQL3 aoi3 1764
M-SQL4 aoi4 1764

 

Note Port Instances/Listener:

For an AAG Environment, you have to choice Ports for instances (here x4) and Ports for AAG-Listener (also x4 in my lab). I choose to use the same port (but not the default 1433) for all instances and all AAG Listeners, but there is no restriction. You can use different ports for each instance, different ports for each Listener, same port for all instances and another port for all Listeners, etc…

 

Availability Groups Configuration

I will create four Availability Groups:

AAG Members (Instance) Default Role AAG Listener Databases

Name

IP

Port

AAG-1 m-sqla1\aoi1 Primary AAG-1L 10.0.1.41 1764 DBTest01
m-sqla3\aoi3 Secondary
AAG-2 m-sqla1\aoi1 Secondary AAG-2L 10.0.1.42 1764 DBTest02
m-sqla3\aoi3 Primary
AAG-3SCOM m-sqla2\aoi2 Primary AAG-3L 10.0.1.43 1764 SCOM OP
m-sqla4\aoi4 Secondary
AAG-4SCOM m-sqla2\aoi2 Secondary AAG-4L 10.0.1.44 1764 SCOM DW
DB Orchestrator
m-sqla4\aoi4 Primary

AAG-1 and AAG-2 will serve for tests only. AAG-3SCOM and AAG-4SCOM will be used for my SCOM and Orchestrator Labs.

In this configuration, in nominal mode each instance hosts an “Active” Primary Replica.

The simulation is m-sql1 and m-sql2 in the same room and the two others in another room.

So I can lose one room (all my AAG/Databases remain available)

 

AAG Listener (VNN – Virtual Network Name)

For reminder, on the WSFC cluster side an AAG is a cluster Resource Group and the VNN is two cluster resources:

  • Virtual Name
  • Virtual IP

Example:


When you configure an application to host its Database on a SQL Availability Group you have to specify the Listener name for the instance name and the Listener port for the Instance port.

 

AAG Implementation – Version 1

This is the first version that will be configured in the next parts of the article:

 

Schema AlwaysOn Availabilty Groups Design 4 AAG v1

Schema: Design 4x AlwaysOn Availability Groups with Synchronous Replicas – V1

AAG Implementation – Version 2

In another part, to simulate a Remote DRP Site, I will add and additional Instance (with two Replicas in Asynchronous mode on the AAG-1 and the AAG-2):

 

Schema AlwaysOn Availability Groups Design 4 AAG v2

Schema: Design 4x AlwaysOn Availability Groups with Synchronous/Asynchronous Replicas – V2

Availability Replicas Configuration

The next part is to specify the detailed availability replica (two per AAG) configuration:

AAG Server Instance Initial Role Automatic
Failover
Synchronous
Commit
Allow Readable
Secondary
AAG-1 m-sqla1\AOI1 Primary Yes Yes Yes
m-sqla3\AOI3 Secondary Yes Yes Yes
AAG-2 m-sqla1\AOI1 Secondary Yes Yes Yes
m-sqla3\AOI3 Primary Yes Yes Yes
AAG-3SCOM m-sqla2\AOI2 Primary Yes Yes Yes
m-sqla4\AOI4 Secondary Yes Yes Yes
AAG-4SCOM m-sqla2\AOI2 Secondary Yes Yes Yes
m-sqla4\AOI4 Primary Yes Yes Yes

All replicas will be configured in “Automatic” failover mode and so in “Synchronous” availability mode.

For more information see TechNet: Failover and Failover Modes (AlwaysOn Availability Groups) – http://technet.microsoft.com/en-us/library/hh213151

 

Readable Secondary Option:

For future tests, I enable Readable Secondary option.

Option Description
No No user connections are allowed to secondary databases of this replica. They are not available for read access. This is the default setting.
Read-intent only Only read-only connections are allowed to secondary databases of this replica. The secondary database(s) are all available for read access.
Yes All connections are allowed to secondary databases of this replica, but only for read access. The secondary database(s) are all available for read access.

 

Primary Role Connections:

I use the default settings (Allow all connections).

Option Description
Allow all connections All connections are allowed to the databases in the primary replica. This is the default setting.
Allow read/write connections When the Application Intent property is set to ReadWrite or the Application Intent connection property is not set, the connection is allowed. Connections where the Application Intent connection property is set to ReadOnly are not allowed. This can help prevent customers from connecting a read-intent work load to the primary replica by mistake.

 

Endpoints Configuration

There is one Endpoint per SQL Server Instance.

During AAG Creation (via Wizard), Endpoint URL is configured with the SQL Instance FQDN. With this default option, instances will communicate over the Public Network (for reminder: 10.0.1.0/24).

So to configured instance communication on the Replication Network (10.0.20.0/24) I have to set my endpoint to: TCP://10.0.20.x:5022.

For tests, I will configure two instances (AOI1 and AOI3) on the Public Network (with FQDN) and the two other instances (AOI2 and AOI4) on the Replication Network.

Server Instance Endpoint URL Endpoint Port Endpoint Name
m-sqla1\AOI1 TCP://M-SQLA1.lab1.ad:5022 5022 Hadr_endpoint
m-sqla2\AOI2 TCP://10.0.20.22:5022 5022 Hadr_endpoint
m-sqla3\AOI3 TCP://M-SQLA3.lab1.ad:5022 5022 Hadr_endpoint
m-sqla4\AOI4 TCP://10.0.20.24:5022 5022 Hadr_endpoint

 

Note: 5022 is the default port, you can use another port.

 

Service Accounts Requirement

Isolate Instance Services

Isolating services reduces the risk that one compromised service could be used to compromise others.

At the Instance level, each SQL Service (SQL Server, SQL Agent …) must be configured with different account.

Isolate Instances

A Security Best Practice is to use different accounts for each instance, but considers these points:

  • Microsoft recommends to use the same account for all instances of an AlwaysOn Cluster (it’s more simple to assign rights to Endpoints)
  • If you want to use Kerberos, instances must use the same account:

     

Service Accounts – Solutions

Use the same account for all Instances (enable Kerberos authentication):

  • gMSA (Group Managed Service Accounts): the best solution for the AlwaysOn Availability Group is to use a gMSA (same as a MSA account but available on multiple host). But it’s not supported for the moment on SQL Server…

 

Status about  gMSA/MSA accounts for SQL

http://blogs.msdn.com/b/sqlosteam/archive/2014/02/19/msa-accounts-used-with-sql.aspx

Group Managed Service Accounts Overview

http://technet.microsoft.com/en-us/library/hh831782.aspx

 

  • “Classic” Domain Account:
    you can use the same domain account for all instances (this works), but when you have to change the password account you have to program an interruption of service (all node will be affected at the same time by the password change…)

 

Use different accounts for all Instances (disable Kerberos authentication):

    • MSA (Managed Service Account): you can use a MSA account per Instance (MSA is a domain account; password is managed automatically by the domain controller; a MSA is assigned to only one host)

 

  • Virtual Accounts: you can use a virtual account per Instance (the functioning is identical to a MSA except it’s a local account managed by the host, not by the DC). This is the default option during a SQL Instance installation.

 

For more information, see TechNet article: Configure Windows Service Accounts and Permissions – http://msdn.microsoft.com/en-us/library/ms143504.aspx

So actually, there is no possible solution for use Kerberos with AAG in a production environment. I will use MSA account for my lab.

Account MSA Description Member Of / Rights Instance Service Mode
lab1\SQLAlwaysOnAdmins n/a SQL Administrators Group Local Administrator of all nodes
Sysadmin on all instance
n/a n/a
lab1\sqlaoinstall No Account use for Installation Member of SQLAOAdmins Group n/a n/a
lab1\svc-sqldbe1 Yes SQL Service – Database Engine Domain User aoi1 Automatic
lab1\svc-sqlagt1 Yes SQL Service – Agent Domain User Automatic
lab1\svc-sqldbe2 Yes SQL Service – Database Engine Domain User aoi2 Automatic
lab1\svc-sqlagt2 Yes SQL Service – Agent Domain User Automatic
lab1\svc-sqldbe3 Yes SQL Service – Database Engine Domain User aoi3 Automatic
lab1\svc-sqlagt3 Yes SQL Service – Agent Domain User Automatic
lab1\svc-sqldbe4 Yes SQL Service – Database Engine Domain User aoi4 Automatic
lab1\svc-sqlagt4 Yes SQL Service – Agent Domain User Automatic

 

Permission needed for Service Account:

Notes: During installation, these permissions are granted by the SQL setup.

Service Description Permissions granted by SQL Server Setup
SQL Server Database Services The service for the SQL Server relational Database Engine. The executable file is <MSSQLPATH>\MSSQL\Binn\sqlservr.exe. Log on as a service
Replace a process-level token
Bypass traverse checking
Adjust memory quotas for a process
Permission to start SQL Writer
Permission to read the Event Log service
Permission to read the Remote Procedure Call service
SQL Server Agent Executes jobs, monitors SQL Server, fires alerts, and enables automation of some administrative tasks. The executable file is <MSSQLPATH>\MSSQL\Binn\sqlagent.exe. Log on as a service
Replace a process-level token
Bypass traverse checking
Adjust memory quotas for a process
Reporting Services Manages, executes, creates, schedules, and delivers reports. The executable file is <MSSQLPATH>\Reporting Services\ReportServer\Bin\ReportingServicesService.exe. Log on as a service
SQL Server Browser The name resolution service that provides SQL Server connection information for client computers. The executable path is c:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe Log on as a service
Full-text search Quickly creates full-text indexes on content and properties of structured and semistructured data to provide document filtering and word-breaking for SQL Server. Log on as a service
Adjust memory quotas for a process
Bypass traverse checking

 

Storage

Disk configuration per node:

Disk Letter RAID Level Size Name SQL Path Description
disk0 c: n/a 25GB System C:\Program Files\Microsoft SQL Server\
C:\Program Files (x86) \Microsoft SQL Server\
C:\MSSQL\MSSQL11.<instancename>\
C:\MSSQL\MSSQL11.<instancename>\MSSQL\Data
SQL Shared Features
SQL Shared Features
SQL Server Directory
System Databases
disk1 G: n/a 5 GB SQL_DB G:\MSSQL\AOREPLICA\Data
G:\MSSQL\MSSQL11.<instancename>\MSSQL\TempDB\Data
G:\MSSQL\MSSQL11.<instancename>\MSSQL\Backup
Databases
TempDB Database
Database Backups
disk2 L: n/a 5 GB SQL_LOG L:\MSSQL\AOREPLICA\Log
L:\MSSQL\MSSQL11.<instancename>\MSSQL\TempDB\Log
DB Transaction Log
TempDB Log

 

Notes about Storage:

If your SQL Servers are virtualized, for production environment you shouldn’t use Virtual Disk (except for OS). You have to use Pass-through (via Virtual FC) for Hyper-V, or RDM LUN for VMware.

In addition for better performance you must use a dedicated disk for TempDB.

Install SQL Server (SQL Server Directory) on a separate disk (D:).

You can also add a separate disk for pagefile, but if the SQL server is correctly sized it should not have to swap.

 

Example of a Production configuration

Disk Letter RAID Level Size Name SQL Path Description
disk0 C: Raid 1 xx GB System C:\Program Files\Microsoft SQL Server\
C:\Program Files (x86) \Microsoft SQL Server\
SQL Shared Features
SQL Shared Features
disk1 D: Raid 1 xx GB SQL_BIN D:\MSSQL\MSSQL11.<instancename>\
D:\MSSQL\MSSQL11.<instancename>\MSSQL\Data
SQL Server Directory
System Databases
disk2 G: Raid 10 xx GB SQL_DB G:\MSSQL\AOREPLICA\Data Databases
disk3 K: Raid 5 xx GB SQL_BAK K:\MSSQL\MSSQL11.<instancename>\MSSQL\Backup Database Backups
disk4 L: Raid 10 xx GB SQL_LOG L:\MSSQL\AOREPLICA\Log Transaction Log
disk5 T: Raid 10 xx GB SQL_TEMPDB T:\MSSQL\MSSQL11.<instancename>\MSSQL\TempDB\Data
T:\MSSQL\MSSQL11.<instancename>\MSSQL\TempDB\Log
TempDB Database
TempDB Logs
disk6 R: Raid 5 xx GB SQL_SSRS R:\MSSQL\MSSQL11.<instancename>\MSSQL\Reports SSRS Feature

 

Note for Databases/Logs path on AAG:

If you use the default instance path (which contains the instance name) for Databases and Logs, the paths on all the nodes participating to the AAG are different. This has an impact on AlwaysOn AG.

TechNet:

If the file path (including the drive letter) of a secondary database differs from the path of the corresponding primary database, the following restrictions apply:

  • New Availability Group Wizard/Add Database to Availability Group Wizard:  The Full option is not supported (on the “Select Initial Data Synchronization” Page).
  • RESTORE WITH MOVE:  To create the secondary databases, the database files must be RESTORED WITH MOVE on each instance of SQL Server that hosts a secondary replica.
  • Impact on add-file operations:  A later add-file operation on the primary replica might fail on the secondary databases. This failure could cause the secondary databases to be suspended. This, in turn, causes the secondary replicas to enter the NOT SYNCHRONIZING state.

 

So it is recommended to use the same path on all instances:

Data Default Path New Path
DB G:\MSSQL\MSSQL11.<instancename>\MSSQL\Data G:\MSSQL\AOREPLICA\Data
LOG L:\MSSQL\MSSQL11.<instancename>\MSSQL\Log L:\MSSQL\AOREPLICA\Log

 

Note about TempDB

  • The TempDB shouldn’t be store on the same disk as your Databases
  • In Production, autogrow operations can affect performance so preallocate space to allow for the expected workload (autogrow should be used to increase disk space for unplanned exceptions)
  • SQL CAT team recommends one file per CPU Core. Microsoft Note:

But this recommendation is subject to discussion and depends of your SQL environment (and the TempDB Contention). I’m not going to analyze this in this article, but I invite you to read the great articles of Paul Randal:

A SQL Server DBA myth a day: (12/30) tempdb should always have one data file per processor core:
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/

The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention: http://www.sqlskills.com/blogs/paul/the-accidental-dba-day-27-of-30-troubleshooting-tempdb-contention/

Another “General” Recommendation:

Last year at PASS 2011 Bob Ward, one the Sr Escalation Engineers for SQL, made the following recommendation which will be updated in the Microsoft references that other people provided on this thread:

As a general rule, if the number of logical processors is less than 8, use the same number of data files as logical processors. If the number of logical processors is greater than 8, use 8 data files and then if contention continues, increase the number of data files by multiples of 4 (up to the number of logical processors) until the contention is reduced to acceptable levels or make changes to the workload/code.

http://social.msdn.microsoft.com/Forums/sqlserver/en-US/dceea24c-7a53-4450-94cd-8327b5daa759/what-is-the-best-practice-for-configuring-tempdb

 

Security

Firewall

These ports (incoming) must be opened:

Service Protocol Port Name Managed by
Windows (*)
Note
SQL TCP 1764 Instance and VNN Port    
SQL TCP 5022 Instance SQL Endpoint   User for AAG Replica Communication
WSFC Cluster TCP 3343 Failover Clusters (TCP-In) Yes Required during a node join operation
WSFC Cluster UDP 3343 Failover Clusters (UDP-In) Yes  
WSFC Cluster TCP 135 Failover Clusters (DCOM-RPC-EPMAP-In) Yes  
WSFC Cluster TCP 445 Failover Clusters – Named Pipes (NP-In) Yes  
WSFC Cluster TCP <Dynamic> Failover Clusters <RPC Server Programs> Yes  
(*) Rules are automatically created during the feature/role installation

For more information about Microsoft Products Port requirements see MS KB “Service overview and network port requirements for Windows” – http://support.microsoft.com/kb/832017/en-us#method70

 

Antivirus Exclusion

Configure these exclusions on your Antivirus:

Exclusions for Cluster:

Type Detail (Path, Extension,…) Description
Folder %Systemroot%\Cluster Cluster folder
Folder Q:\mscs Qurom disk

Exclusions for SQL Server:

Type Detail (Path, Extension,…) Description
File-name extensions .mdf
.ldf
.ndf
SQL Server data files
Process <installpath>\MSSQL11.<Instance Name>\MSSQL\Binn\SQLServr.exe SQL process

 

Next

Next par covers the installation and configuration of servers in core mode: AlwaysOn Availability Group – Part 3 – Install WS2012 R2 Core Server

 

The post AlwaysOn Availability Group Design appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-availability-group-design/feed/ 0 765
AlwaysOn Availability Group Introduction https://www.tech-coffee.net/alwayson-availability-group-introduction/ https://www.tech-coffee.net/alwayson-availability-group-introduction/#respond Sun, 27 Apr 2014 09:23:29 +0000 https://www.tech-coffee.net/?p=710 SQL Server 2012/2014 AlwaysOn Availability Groups: Article Summary Part 1 – AlwaysOn Introduction Part 2 – AlwaysOn Design Part 3 – Install and Configure Windows Server 2012 R2 in Core mode Part 4 – WSFC Cluster Creation Part 5 – Install SQL Core on Windows Core Server Part 6 – AlwaysOn Availability Groups Creation Part ...

The post AlwaysOn Availability Group Introduction appeared first on Tech-Coffee.

]]>
SQL Server 2012/2014 AlwaysOn Availability Groups:


This part describes the new SQL High Availability feature introduced with SQL Server 2012 version: AlwaysOn Availability Group.

 

 

 

 

AlwaysOn Features

First of all, do not confuse “AlwaysOn Availability Group” and “AlwaysOn FCI”. This is two distinct solutions:

 

AlwaysOn FCI (Failover Cluster Instance)

This is the classic SQL Cluster based on the WSFC (Windows Server Failover Clustering) functionality. FCI provide local high availability through redundancy at the server-instance level (a single instance installed across multiple nodes). In case of failure of a node, the instance will start on another node. Clients connect to this instance from a VNN (Virtual Network Name) which is a Cluster resource.

FCI required Shared Storage (SAN, SMB…) for database data and logs. This storage must be configured on all nodes participating to an FCI. In the FCI solution, Shared Storage is a SPOF (Single Point Of Failure).

SQL Services (Instance) can failover between WSFC nodes (so the loss of a server is covered). If the Storage fails the service stops.

Note:

  • For FCI on the same site it’s possible to eliminate the Storage SPOF with SAN Replication.
  • For FCI across remote sites you need to implement SAN Replication.

Implementing “SAN Replication” Cons:

  • generates additional costs (this is also the case for AAG; FCI is available on the SQL Standard version, AAG required an SQL Enterprise version) except if it’s included in your SAN license.
  • it’s more complicated to implement on remote geographic sites.
  • it’s require additional storage skills for the operation team.
  • the Availability Group offer more options (like asynchronous replica, backup on secondary replica, ..)

The choice of use FCI or AAG depends of your Business requirement (RTO, RPO, DRP, Remote sites …)

For comparison, AlwaysOn Availability Groups doesn’t require Shared Storage.

I will write an article about AlwaysOn FCI with Windows 2012 R2 SOFS Storage (Scaled-Out File Server).

 

Part1-AlwaysOn-FCI

AlwaysOn Availability Group

The Availability Group feature is a mix of SQL Clustering and SQL Mirroring (it is also presented by MS as an alternative to SQL Mirroring which is deprecated since SQL Server 2012).
The AG is also based on a WSFC cluster; the difference is that on each node a SQL instance is installed and active.

AAG is composed of replicas (a replica is a group of one or more database). There is one Primary Replica and one to four Secondary Replicas (eight for SQL 2014) (a Secondary Replica is a copy of databases from the Primary Replica, when a DB is modified, changes are replicated on all Secondary replica). An AAG is a WSFC cluster resource group (which contains at least the VNN and VIP cluster resources on which the clients will connect). At time T, the AAG is hosted by an instance, so this is the primary replica (database(s) accessible in R/W) and all other replicas synchronize thereon. There are two types of synchronization: synchronous and asynchronous.

If the instance that hosts the primary replica becomes unavailable the AG (the cluster group resource) will switch to another instance and the secondary replica on this instance will become the Primary replica (this failover requires that the secondary replica is set in “synchronous” mode and the status is “Synchronized”).

Automatically failover cannot be done to an asynchronous secondary replica. In asynchronous mode only “forced manual failover” (with possible Data loss) is allowed, this action must be performed by a DBA. This mode is generally used for a DRP on one or more remote site or if the maximum number of replica in synchronous mode is reaches – Max for SQL 2012/2014: 3 (1x Primary + 2x Secondary)

A Cluster Resource Group (for SQL the AG) can be hosted only by one instance at a time. So, on a given AG only one instance at a time can be “active” (active = which hosts Database(s) accessible in R/W = the Primary Replica).

On all replicas in an Availability Group only one can be “Primary Replica” at a time.

For example, with an AG composed of two nodes and containing two databases, it’s impossible to have one Database active on one node and the second DB active on the second node. To achieve this configuration we need to create two AG (on the same two nodes) with one Database in each AG (so there are two Primary Replica, this is the configuration that I will do in this article).

 

Use the both features

It’s possible to used AlwaysOn FCI in an AlwaysOn Availability Group solution. In this case a SQL Failover Clustering Instance cans host an Availability Replica for Availability Group

Note for Failover Mode: SQL FCIs do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.

The implementation of a FCI in an AG will be cover in another article.

Overview (from TechNet):

 


http://technet.microsoft.com/en-us/library/hh270278.aspx

 

License

 

High Availability features for SQL Server 2012 Licenses:

Feature Name

Enterprise

Business Intelligence

Standard

Web

Express

Server Core support Yes Yes Yes Yes Yes
Log Shipping Yes Yes Yes Yes  
Database mirroring Yes Yes (Safety Full Only) Yes (Safety Full Only) Witness only Witness only
Backup compression Yes Yes Yes    
Alwayson Failover Cluster Instances Yes (Node support: OS maximum) Yes (Node support: 2) Yes (Node support: 2)    
AlwaysOn Availability Groups Yes (up to 4 secondary replicas, including 2 synchronous secondary replicas)        
         

 

 

High Availability features for SQL Server 2014 Licenses:

Feature Name

Enterprise

Business Intelligence

Standard

Web

Express

Server Core support Yes Yes Yes Yes Yes
Log Shipping Yes Yes Yes Yes  
Database mirroring Yes Yes (Safety Full Only) Yes (Safety Full Only) Witness only Witness only
Backup compression Yes Yes Yes    
Alwayson Failover Cluster Instances Yes (Node support: Operating system maximum Yes (Node support: 2) Yes (Node support: 2)    
AlwaysOn Availability Groups Yes (up to 8 secondary replicas, including 2 synchronous secondary replicas)        
         

 

For more information on Features/Licenses:

 

Terms and Definitions

 

Term Definition
availability group A container for a set of databases, availability databases, that fail over together.
availability database A database that belongs to an availability group. For each availability database, the availability group maintains a single read-write copy (the primary database) and one to four read-only copies (secondary databases).
primary database The read-write copy of an availability database.
secondary database A read-only copy of an availability database.
availability replica An instantiation of an availability group that is hosted by a specific instance of SQL Server and maintains a local copy of each availability database that belongs to the availability group. Two types of availability replicas exist: a single primary replica and one to four secondary replicas.
primary replica The availability replica that makes the primary databases available for read-write connections from clients and, also, sends transaction log records for each primary database to every secondary replica.
secondary replica An availability replica that maintains a secondary copy of each availability database, and serves as a potential failover targets for the availability group. Optionally, a secondary replica can support read-only access to secondary databases can support creating backups on secondary databases.
availability group listener A server name to which clients can connect in order to access a database in a primary or secondary replica of an AlwaysOn availability group. Availability group listeners direct incoming connections to the primary replica or to a read-only secondary replica.

Source TechNet: http://technet.microsoft.com/en-us/library/aa427606-8422-4656-b205-c9e665ddc8c1#TermsAndDefinitions

 

 

Overview of an AAG

Part1-AlwaysOn-Availability-Group

 

Availability Group

An AG consists of:

  • Two or more Availability Replica (max for SQL Server 2012: 5 / max for SQL Server 2014: 9)
  • One (or more) Availability Group listener

 

Availability Replica

An Availability Replica contains:

  • A set of Databases (at least one) (there are no maximum for a set; this depends on the load and Server Performances).

          A Database add to an AG is known as Availability Database

Each availability replica is hosted by an instance of SQL Server residing on different nodes of a WSFC cluster (All nodes members of the same Cluster).

 

Role:

An Availability Replica can have the role of:

  • Primary Replica – Database(s) is accessible in Read/Write
  • Secondary Replica – Database(s) is accessible in Read Only (if it’s configured)

On a given AAG, only one availability replica can be “Primary” at a time, others are “Secondary”. Secondary Replica contains a “copy” of databases from Primary (during creation a backup is created from the Primary DB and imported on all secondary).

 

Availability Mode:

An Availability Replica can be configured in mode:

  • Asynchronous-commit mode – Under asynchronous-commit mode, the primary replica commits transactions without waiting for acknowledgement that an asynchronous-commit secondary replica has hardened the log. Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making some data loss possible.
  • Synchronous-commit mode – Under synchronous-commit mode, before committing transactions, a synchronous-commit primary replica waits for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log. Synchronous-commit mode ensures that once a given secondary database is synchronized with the primary database, committed transactions are fully protected. This protection comes at the cost of increased transaction latency.

 

Allow Readable Secondary:

When you configure the AAG, you can configure this option (Known as “Active Secondary Replica”):

With this option you can do the following action:

 

Availability Group listener

An availability group listener is a Virtual Network Name (VNN) to which clients can connect to access a database (without knowing the name of the instance). Availability group listeners direct incoming connections to the primary replica or to a read-only secondary replica. The listener provides fast application failover after an availability group fails over.

A VNN it’s a WSFC cluster resource and consists of:

  • A DNS Name (a VNN)
  • A Port Number
  • An IP Address (a VIP)

The Listener is always owned by the SQL Server instance where the primary replica resides.

Note about Port:

A Listener can share a same port with an Instance (for example default instance port is used: 1433, and the Listener is also configured with the 1433 port) or use a different port.

For more information:

Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)

http://msdn.microsoft.com/en-us/library/hh213417.aspx

 

Database Mirroring Endpoint (SQL Server)

Instances participating to an AlwaysOn Availability Group (or a Database Mirroring) use “Database Mirroring Endpoints” to communicate among themselves.

Each Instance must have its own dedicated Endpoint (only one per instance, you cannot create several endpoints for a same instance). After SQL Server Instance installation, the endpoint is not created.

Note: An endpoint is a SQL Server object that enables SQL Server to communicate over the network. “Database Mirroring Endpoint” is a specify endpoint use by AAG or SQL Mirroring for instances communications.

To host an availability replica an instance must have a Database mirroring endpoint (when you create a Replica you have to specify the Endpoint URL of the instance that will host the replica).

The instance uses this endpoint to listen messages from availability replicas hosted by other instances.

Database mirroring endpoints use TCP protocol to send and receive messages between the server instances. The Endpoint URL is composed with the Server FQDN (can be also the Server name, an IPv4 or IPv6 address) and a defined port number. The port number uniquely identifies an instance.

Example: Two instances on one server, you can have two endpoints:

TCP://sql-srv1.ad.corp:5022 => refers to sql-srv1\i1

TCP://sql-srv1.ad.corp:5023 => refers to sql-srv1\i2

Authentication Mode

Two types of Authentication are available for database mirroring endpoints:

  • Certificate-based authentication (If any server instance is running under a built-in account, such as Local System, Local Service, or Network Service, or a non-domain account, you must use certificates for endpoint authentication).

    This part is not covered in this article, for more information see:
    Use Certificates for a Database Mirroring Endpoint (SQL Server)
    http://technet.microsoft.com/en-us/library/ms191477.aspx
  • Windows Authentication
    • If all instances use the same domain account, no extra configuration is required.
      (Microsoft recommends using the same account)
    • If instances use different domain accounts, the login of each account must be created in master on each of the other server instances, and that login must be granted CONNECT permissions on the endpoint.

 

Data Encryption

By default encryption is configured to “Required” on a DB Mirroring Endpoint. You can change this (not recommended) to “Disabled” or “Supported”

Encryption algorithms:

You can also change encryption algorithms. By default on an AlwaysOn instance encryption is configured with AES algorithm.

TechNet:

For more information, see TechNet article “Choose an Encryption Algorithm“: http://technet.microsoft.com/en-us/library/ms345262.aspx

 

 

WSFC (Windows Server Failover Clustering)

The AlwaysOn Availability Group (and also the AlwaysOn FCI) feature is based on the WSFC service. All SQL Server nodes participating to an AAG are members of a WSFC Cluster.

On each node an SQL Server 2012/2014 Enterprise Instance must be deployed.

An AAG is register as a cluster Resource Group in the WSFC Cluster (Resource Group name is the AAG Name). The corresponding Listener (*) of AAG is also register as resource in the Resource Group:

  • Resource – AAG-Listener Name (VNN)
  • Resource – AAG-Listener IP (VIP)

(*) By default one Listener per AAG is sufficient, but if need, it’s possible to create additional Listener (only via PowerShell or WSFC Console)

The WSFC Cluster is responsible of Resources monitoring, in comparison with the SQL Mirroring solution there is not SQL Witness, the WSFC Quorum is used.

It is best practice to always have an odd number of quorum votes in a WSFC cluster.

 

AAG Heath Monitoring

The WSFC Cluster monitors the health of the AlwaysOn Availability Group (physical and logical cluster resources). Few points about WSFC Monitoring:

  • The active SQL Server instance periodically reports a set of component diagnostics to the WSFC resource group.
  • Issues at the database level, such as a database becoming suspect due to the loss of a data file, deletion of a database, or corruption of a transaction log, do not cause an availability group to failover.

 

Note: For “Automatic Failover” a Failover Policy is defined and can be customized:

 

A flexible failover policy provides granular control over the conditions that cause automatic failover for an availability group. By changing the failure conditions that trigger an automatic failover and the frequency of health checks, you can increase or decrease the likelihood of an automatic failover to support your SLA for high availability.

For more Information see TechNet article: Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server): http://technet.microsoft.com/en-us/library/hh710061.aspx

 

Failover

During a failover, a Secondary Replica becomes the Primary Replica.

There are three Failover Mode:

  • Planned manual failover (without data loss) – DBA action
  • Automatic failover (without data loss) – In case of failure

For these two modes, the Primary and Secondary Replica must be configured in “Synchronous Availability Mode” and the Secondary must be synchronized.

  • Forced manual failover (with possible data loss)

       This is a Disaster Recovery option; it can only be initiated manually.

It is the only form of failover that is possible when:

          – the target secondary replica is not synchronized with the primary replica.

the target secondary replica is in “Asynchronous availability mode”

Note: All manual failover actions must be done through the SQL Management Studio, PowerShell or Transact-SQL. No action should be done through the WSFC console.

 

Restrictions

Availability Replica:

  • Availability replicas must be hosted by different nodes of one WSFC cluster
  • One primary replica and up to four secondary replicas per AAG
  • All of the replicas can run under asynchronous-commit mode, or up to three of them can run under synchronous-commit mode.

Maximum number of availability groups and availability databases per computer:

  • No Limitation, depends of Server Performances
  • Microsoft has extensively tested with 10 AGs and 100 DBs per physical machine

Database (To be eligible to be added to an availability group):

  • Use the full recovery model
  • Possess at least one full database backup (After setting a database to full recovery mode, a full backup is required to initiate the full-recovery log chain.)
  • Be a read-write database. Read-only databases cannot be added to an availability group.
  • System databases cannot belong to an availability group.

TDE Protected Databases:

If you use transparent data encryption (TDE), the certificate or asymmetric key for creating and decrypting other keys must be the same on every server instance that hosts an availability replica for the availability group. For more information, see Move a TDE Protected Database to Another SQL Server.

You can find here a FAQ about AlwaysOn capabilities: SQL Server 2012: Always On FAQs

http://blogs.msdn.com/b/srgolla/archive/2012/09/17/sql-server-2012-always-on-faqs.aspx

 

TechNet Resources

AlwaysOn Availability Groups (SQL Server)

http://technet.microsoft.com/en-us/library/aa427606-8422-4656-b205-c9e665ddc8c1

 

 

Next

Next part covers the AlwaysOn environment design: AlwaysOn Availability Group – Part 2 – Design

The post AlwaysOn Availability Group Introduction appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/alwayson-availability-group-introduction/feed/ 0 710
SQL Server 2012-2014 AlwaysOn Availability Group Series https://www.tech-coffee.net/sql-server-2012-2014-alwayson-availability-group/ https://www.tech-coffee.net/sql-server-2012-2014-alwayson-availability-group/#comments Sun, 27 Apr 2014 09:01:29 +0000 https://www.tech-coffee.net/?p=702 This article will present the SQL Server 2012-2014 AlwaysOn Availability Group feature and describe how-to implement a virtualized AlwaysOn Cluster with four WS2012 R2 Core nodes and four Availability Groups. I will post later articles about Administration, Troubleshooting and Monitoring. All nodes will be Virtualized on Hyper-V 2012 R2 For the demonstration of AlwaysOn Availability ...

The post SQL Server 2012-2014 AlwaysOn Availability Group Series appeared first on Tech-Coffee.

]]>
This article will present the SQL Server 2012-2014 AlwaysOn Availability Group feature and describe how-to implement a virtualized AlwaysOn Cluster with four WS2012 R2 Core nodes and four Availability Groups. I will post later articles about Administration, Troubleshooting and Monitoring.

AlwaysOn Availability Groups DesignAll nodes will be Virtualized on Hyper-V 2012 R2

For the demonstration of AlwaysOn Availability Groups capabilities, the Cluster will be configured with four Availability Groups dispatch on four nodes (with this configuration, all SQL instances can be active at the same time, the workload is balanced and the environment supports the loss of one datacenter)

AlwaysOn Availability Groups Cluster Schema

Parts:

Part 1 – Introduction

This part presents the AlwaysOn Availability Group feature (how it works, license, restriction, description of components …).

 

Part 2 – Environment Design

This part covers the AlwaysOn AG Environment Preparation (Design, Configuration, Services Accounts, Storage, Network, Security requirements …

 

Part 3 – Install and Configure Windows Server 2012 R2 in Core mode

This part covers the installation and configuration of Windows Server 2012 R2 in core mode.

 

Part 4 – WSFC Cluster Creation

This part covers the WSFC Cluster creation and configuration (Quorum, Guest Clustering tuning, CNO/VSO AD Prestage …)

 

Part 5 – Install SQL Server on Core Server

This part covers:

  • SQL Server Installation (automation with configuration file)
  • SQL Server Configuration through PowerShell (network, memory, security, AlwaysOn …)

Part 6 – Create AlwaysOn Availability Groups

In this part I will create Availability Group from the Wizard. This AAG will be configured to communicate over the default network (Public).

 

Part 7 – Create AlwaysOn Availability Groups (Advanced, with dedicated replication network)

This part covers the creation of an empty AG from Transact-SQL with communication configure on a dedicated network and the configuration of SCOM and SCO databases in the Availability Group

 

Part 8 – Methods to add Database to Availability Groups (SCOM example)

This part covers the configuration of database in Availability Group through SQL Management Studio, Y-SQL or PowerShell. Example will be realized with the SCOM Databases.

 

Part 9 – Check Availability Group through PowerShell

PowerShell commands to check Availability Group (Copy status, etc…)

ANNEX (Part 6/7) – Manage SQL Endpoint

How-to manage SQL Mirroring Endpoint with PowerShell commands or Transact-SQL queries.

The post SQL Server 2012-2014 AlwaysOn Availability Group Series appeared first on Tech-Coffee.

]]>
https://www.tech-coffee.net/sql-server-2012-2014-alwayson-availability-group/feed/ 1 702