SQL Server all on configuration process

SQL Server All-on is a new solution for high availability and disaster recovery. You can configure one or more secondary replicas to support read-only access to the secondary database, and you can configure any secondary replicas to allow backups of the secondary database. This provides the efficiency of the use of the hardware.

An availability group supports a failover environment for a discrete set of user databases, known as availability databases, which collectively implement failover. an availability group supports a set of primary databases and a corresponding secondary database of one to four groups. the availability group fails over at the availability replica level. failover is not caused by database issues such as database corruption due to loss of data files or transaction log, which makes databases a suspect database.

Each set of availability databases is hosted by an availability replica. There are two types of availability replicas: one primary replica and one to four secondary replicas. The former is used to host the primary database, which hosts a set of secondary databases and acts as a potential failover target for the availability group. The primary replica makes the primary database available to read and write connections to clients. In addition, it is used in the process called "Data Synchronization" and is synchronized at the database level. The primary replica sends transaction log records for each primary database to each secondary database. each secondary replica caches transaction log records ("hardened" logs) and then applies them to the appropriate secondary database. The primary database synchronizes data independently with each connected secondary database. Therefore, one secondary database can hang or fail without affecting other secondary databases, and one primary database can hang or fail without affecting other primary databases.

Alternatively, you can configure one or more secondary replicas to support read-only access to the secondary database, and you can configure any secondary replicas to allow backups of the secondary database. Deploying an AlwaysOn availability group requires a Windows server failover cluster (WSFC) cluster.

The figure shows an availability group that contains the maximum number of availability replicas, one primary replica and four secondary replicas.

From: http://msdn.microsoft.com/zh-cn/library/ff877884.aspx

While always on is WSFC-based, it does not require shared storage, so the configuration is straightforward.

Here are my installation steps:

Need at least three machines (I created three VMs, one as a dc,dns server, two Nod3)

Machine name	Role	OS	IP Address
DC	Domain Controller	Windows 2008R2	192.168.1.10
Node1	Cluster Node 1	Windows 2008R2	192.168.1.11 Public
			192.168.2.1
			Heart jumper
Node2	Cluster Node 2	Windows 2008R2	192.168.1.12 Public
			192.168.2.2
			Heart jumper Form Bottom

First configure the Windows cluster:

1. Install. NETFramework 3.5.1 Features and failover clustering

2. Install Windows KB 2494036

3. Create a new cluster

4. Select a server to join the cluster:

5. Detection configuration:

6. No need to select Detect shared disk (AlwaysOn not required)

7. Start Detection:

8. Test content (You can export the report after detection is complete):

9. After entering cluster name and IP Click Next to create success, open Server Manager after success to view the cluster configuration (you can see that there is no shared disk, and the traditional cluster is still different):

Since we only use two machines, when a machine is down, there is no quorum and cannot be transferred successfully. When using multi-node quorum, three nodes can be used, so that the other two can be arbitrated after the one is down. If two node, do not use a shared disk can use the share file, the specific configuration can refer to: http://www.sqlskills.com/blogs/jonathan/ failover-clustering-without-a-san-sql-server-2012-and-smb-for-shared-storage/(This step was not previously configured, although the AlwaysOn level can be failover , but the real one node down after the fall, thank @struggle1 pointed out the problem. ）

Now that our cluster has been configured, the next step is to install SQL Server and configure always on.

part2:http://blog.csdn.net/smithliu328/article/details/7886513

part3:http://blog.csdn.net/smithliu328/article/details/7886656

SQL Server all on configuration process