This topic introduces a way to try to choose the right CPU to balance the infrastructure cost (hardware and software) and performance. This is a feedback from a real case study that I have done.

Theoretical case study values

For this topic, I’ll use the theoretical values to show you the cost difference between several CPUs. To make this study, I’ll use the following required values:

• 500 vCPUs
• 3TB of RAM
• 20TB of Storage

Remind about the Windows Server 2016 license

For this topic, I’ll focus on Windows Server 2016 Datacenter license because Storage Spaces Direct requires this edition. Windows Server 2016 is a per-core basis. The Windows Server 2016 license covers up to two sockets of 8 physical cores (16 cores per server). Beyond these 16 cores, you have to acquire license pack. Each license pack covers up to two physical cores.

For example, if you have two CPU of 14 cores, the server has 28 cores. So, you buy the Windows Server 2016 Datacenter which covers up to 16 cores. For the 12 cores remaining, you have to buy 6 additional license packs.

The public cost of Windows Server 2016 Datacenter is:

• 6155$ for Windows Server 2016 Datacenter
• 760$ for a license pack

Selected CPU

For this topic, I have Selected two CPUs:

• Intel Xeon E5-2630v4 (667$): 10 Cores
  • 25MB cache, 2,20GHz
• Intel Xeon E5-2683v4 (1846$): 16 Cores
  • 40MB cache, 2,10GHz

The Intel Xeon E5-2683v4 has more cache but 100MHz less than Intel Xeon E5-2630v4. But the higher number of cores enable to support more vCPUs.

Calculate the required hardware

For this infrastructure, 500 vCPUs are required. Because we will host server workloads, we can define the consolidation rate to 4:

Number of Cores = 500vCPUs / 4 (consolution rate)

So, we need 125 cores. For the calculation, I never consider the Hyperthreading. Below, please find the number of servers required depending of the server. The column #Node is the number of nodes (Raw) round up with an additional node for the N+1. To find the number of nodes, I have divided the required cores per the number of cores per node. As you can see, with the E5-2630v4, you need two additional nodes.

Now that we have the number of nodes, we can calculate the required memory. To calculate the required memory per node, I take the number of nodes – 1 to support a node failure. With the CPU E5-2630v4, you need 500GB per node and you’ll have 3,5TB of RAM for the cluster. With E5-2683v4, you need 750GB of RAM per node and you’ll have 3,75TB of RAM for the cluster. You need more RAM per cluster for E5-2683v4 because you have less nodes.

Finally, for the storage, we need 20TB. We use Storage Spaces Direct and to host virtual machines, we need 3-way mirroring. I have selected the following configuration:

• Intel Xeon E5-2630v4 (7 nodes) – Total 22TB with 4TB of reservation
  • 4xSSD 400GB (Cache)
  • 6x HDD 2TB (Capacity)
• Intel Xeon E5-2683v4 (5Nodes) – Total 24TB with 8TB of reservation
  • 4xSSD 400GB (Cache)
  • 4xHDD 4TB (Capacity)

To make the price comparison related to the selected hardware, I have used Dell hardware (Dell R730xd):

The total hardware cost for E5-2683v4 solution is 14K$ less expensive than the solution with E5-2630v4. Now, let’s see the license cost

Windows Server 2016 Datacenter licenses

With the E5-2630v4 solution, we have 20 cores per node and with E5-2683v4 solution we have 32 cores per node.

As you can see, you need to spend more money for E5-2683v4 solution than E5-2630v3 in Windows Server 2016 licenses.

Total solution cost

Below you can find the total cost for both solutions:

So, the total cost for E5-2630v4 solution is almost 243K$ and 236K$ for E5-2683v4 solution. As you can see, even if the bigger CPU is more expensive and even if you have to acquire more Windows Server 2016 licenses, the E5-2683v4 solution is less expensive. Moreover the E5-2683v4 solution has a better consolidation because we can host more VMs in each node. So this solution is more scalable.

Conclusion

I have written this topic to show you that a bigger CPU doesn’t mean a more expensive solution. So for your hyperconverged solution with Storage Spaces Direct, you should evaluate several type of CPU. By taking time in the planning phase, you can save money and implement a more scalable solution.

The post Choose properly your CPU for Storage Spaces Direct 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.