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: https://azure.microsoft.com/en-us/marketplace/partners/starwind/starwindvirtualsan-starwindbyol/

Overview of Architecture:

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:

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 …)

• 1x Azure Storage Account (required to host VM VHDX):

• 1x Virtual Network (VNET) with three subnets:

• 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.
  

• 3x Virtual Machine

• 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:

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: https://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.

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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:

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:

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.

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.

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

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

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

Check status on the secondary node:

Note: You can check the copy Status from PowerShell

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

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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:

IP use for Instances Endpoints (subnet 10.0.20.0/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.

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') <> 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') <> 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“: https://technet.microsoft.com/en-us/library/hh213540.aspx

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

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:

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:

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.

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:

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.

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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: https://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):

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

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)

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

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

https://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

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.

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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:

• –  New-ADServiceAccount
• https://technet.microsoft.com/en-us/library/hh852236.aspx

• –  Add-ADComputerServiceAccount
• https://technet.microsoft.com/en-us/library/hh852266.aspx

• –  Install-ADServiceAccount
• https://technet.microsoft.com/en-us/library/hh852196.aspx

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: https://support.microsoft.com/kb/2772858/en-us)

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

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:

https://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):

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):

Startup type values:

• Automatic
  
• Manual
  
• Disabled
  

For more information, see TechNet article “Install SQL Server 2012 from the Command Prompt“: https://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):

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:

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

• *   1 – Execute the script “SQL_Get-Instance-Network-Cfg.ps1” to retrieve SQL Configuration:
  

• *  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“: https://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:

If you need to add additional TempDB files:

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:

Another way to list Database Files:

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

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:

• –  PS-SQL_Set-AuditMode.ps1
  

• –  PS-SQL_Get-AuditMode.ps1
  

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.

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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:

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:

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.
  

• Add temporarily the SQL Admin Account to the “Domain Admins” group (I use this for the lab)
  
• Pre-stage the CNO before installation (see TechNet)
  
  Prestage Cluster Computer Objects in Active Directory Domain Services:
  https://technet.microsoft.com/en-us/library/dn466519.aspx
  

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.

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:

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:

Check if Dynamic Quorum is enabled:

View the “Dynamic Node Weight” status for nodes:

For more information about Quorum Configuration see TechNet Article:

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

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

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):

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:

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.

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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 – 1^st 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:

Enable Remote Management Rules

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

Create Firewall Rules for SQL

You have to create these inbound rules:

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:

Browser will be disabled.

For more information (other port for SSRS, AS …) see TechNet article “Configure the Windows Firewall to Allow SQL Server Access“: https://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

Or via PowerShell:

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:

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

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

TechNet Resources:

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:

https://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.

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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 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)

LAB Requirements

Three Networks are required.

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:

SQL Servers / Instances Configuration

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

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.

• 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:

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-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: 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: 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:

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) – https://technet.microsoft.com/en-us/library/hh213151

Readable Secondary Option:

For future tests, I enable Readable Secondary option.

Primary Role Connections:

I use the default settings (Allow all connections).

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.

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

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

Group Managed Service Accounts Overview

https://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 – https://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.

Permission needed for Service Account:

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

Storage

Disk configuration per node:

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

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:

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

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:
https://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: https://www.sqlskills.com/blogs/paul/the-accidental-dba-day-27-of-30-troubleshooting-tempdb-contention/

Another “General” Recommendation:

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.

https://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:

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

Antivirus Exclusion

Configure these exclusions on your Antivirus:

Exclusions for Cluster:

Exclusions for SQL Server:

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.

• 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 7 – AlwaysOn Availability Groups Creation (Advanced, with dedicated Replication Network)
• Part 8 – Methods to add Database on Availability Groups (SCOM Example)
• Part 9 – AlwaysOn Availability Groups – PowerShell Monitoring
• ANNEX (Part 6/7) – Manage SQL Endpoint

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).

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):

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

License

High Availability features for SQL Server 2012 Licenses:

High Availability features for SQL Server 2014 Licenses:

For more information on Features/Licenses:

• SQL Server 2012 Features: https://msdn.microsoft.com/en-us/library/cc645993.aspx#High_availability
  

• SQL Server 2014 Features: https://msdn.microsoft.com/en-us/library/cc645993%28v=sql.120%29.aspx#High_availability
  

Terms and Definitions

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

Overview of an AAG

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:

• Performing backup operations on secondary replicas – The secondary replicas support performing log backups and copy-only backups of a full database, file, or filegroup. You can configure the availability group to specify a preference for where backups should be performed.
  
  For more information, see Technet: Active Secondaries: Backup on Secondary Replicas (AlwaysOn Availability Groups).
  
• Read-only access to one or more secondary replicas (readable secondary replicas) – Any availability replica can be configured to allow read-only access to its local databases when performing the secondary role, though some operations are not fully supported. Also, if you would like to prevent read-only workloads from running on the primary replica, you can configure the replicas to allow only read-write access when running under the primary role.
  
  For more information, see Active Secondaries: Readable Secondary Replicas (AlwaysOn Availability Groups).
  If an availability group currently possesses an availability group listener and one or more readable secondary replicas, SQL Server can route read-intent connection requests to one of them (read-only routing).
  For more information, see Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing) : https://technet.microsoft.com/en-us/library/hh213417.aspx#ConnectToSecondary
  An excellent TechNet article about Read-Only Routing:
  Read-Only Routing with SQL Server 2012 Always On Database Availability Groups
  https://social.technet.microsoft.com/wiki/contents/articles/13503.read-only-routing-with-sql-server-2012-always-on-database-availability-groups.aspx?Sort=MostUseful&PageIndex=1
  

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)

https://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)
  https://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“: https://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:

For more Information see TechNet article: Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server): https://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

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

TechNet Resources

AlwaysOn Availability Groups (SQL Server)

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

• Overview of AlwaysOn Availability Groups (SQL Server)
  https://technet.microsoft.com/en-us/library/ff877884.aspx

• Failover and Failover Modes (AlwaysOn Availability Groups)
  https://technet.microsoft.com/en-us/library/hh213151

• Availability Modes (AlwaysOn Availability Groups)
  https://technet.microsoft.com/en-us/library/ff877931

• Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)
  https://technet.microsoft.com/en-us/library/ff878487.aspx#NetworkConnect

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.

All 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)

Parts:

Part 1 – Introduction

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

• Download PDF

Part 2 – Environment Design

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

•  Download PDF

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.

•  Download PDF
• Download Scripts

Part 4 – WSFC Cluster Creation

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

•  Download PDF

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 …)
  

• Download PDF
• Download Scripts

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.