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