Requirements

• A working SQL Server cluster using AlwaysOn (cf. this topic)
• A working Windows Azure Pack installation (cf. this topic)

Run this script on each SQL Server node:

sp_configure 'contained database authentication', 1;
GO
RECONFIGURE;
GO

SQL Server extension installation

On each node that hosts admin Windows Azure Pack services, run the Web Platform Installer. Next select Windows Azure Pack: SQL Server Extension and click on Add.

When the configuration webpage is opened, specify your database server settings.

At the end of installation, you should have something as below :

SQL Server group creation

Open your Administrative Console of Windows Azure Pack and navigate to SQL Servers. Navigate to Groups and click on Create a new SQL Server Group. In group type, select High Availability (Always on enabled). Specify a group name and a share to store database backup.

I have created two groups: one called Bronze and the other called Gold.

Add SQL Servers to Windows Azure Pack

Next we have to associate SQL Servers to the groups that we have previously created. So navigate to SQL Servers and select servers. Click on Add a new SQL Server. Specify the group, the AAG listener name, the credentials and size of hosting server.

Repeat the operation to add others SQL Servers.

So in my example I have two groups and two SQL Servers AAG.

Add the service to a hosting plan

Now we have to add the service to a hosting plan. Select a hosting plan and click on Add Service.

Select the SQL Servers service and click on next.

Then click on SQL Servers service to configure it.

Specify the settings regarding your needs and click on ok.

Now the service status should be Active.

Trying the service

To use the service, connect to the tenant portal and click on SQL Server Databases. Then select Add a new database.

Specify a database name and choose an edition.

Specify database credentials and click on ok.

Once the database is created, you can connect to your SQL Server with the management studio and open the AAG dashboard. As you can see below, the database is automatically added to the AAG.

The post Windows Azure Pack – SQL Server in AlwaysOn as a Service appeared first on Tech-Coffee.

This whitepaper explains how to implement a Private Cloud with Windows Azure Pack in high availability from scratch. So I talk about Scale-Out File Servers, SQL AlwaysOn, Virtual Machine Manager, Service Provider Foundation, NVGRE Gateway, RD Gateway and Windows Azure Pack.

I start this implementation just after to have deployed the Active Directory and a PKI and so almost from scratch. I hope this document will help you to implement your own private cloud.

Merry Christmas everyone

The post Whitepaper: Implement a highly available private cloud to host virtual machines 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 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.