1. AlwaysOn介紹
AlwaysOn是SQL Server 2012提供的全新綜合、靈活、高效經濟的高可用性和災難恢復解決方案。它整合了鏡像和群集的功能，基於OS 故障轉移群集(Windows Server FailOver Cluster)，通過在同一個WSFC的不同Node上，安裝獨立的SQL Server實例，定義AlwaysOn Group，一個數據庫最多可以部署4個鏡像。當熱備機出現故障時，可以手工或自動實現故障轉移，交換主、輔數據庫的角色。
AlwaysOn的亮點在於鏡像可讀。對於OLTP應用，可以將讀操作集中的報表等操作轉移到Read-Only的輔助庫上，極大地減少Primary DB的IO、CPU等資源占用。由於輔助庫是獨立的SQL實例，因此創建臨時表等TempDB操作不受影響。
1.1. 可用性模式
同步提交
同步提交模式下，主數據庫事務提交前，通知輔數據庫，直到輔數據庫提交成功后，主數據庫成功提交。
優點：數據受到完整保護，不會存在數據不一致。
缺點：事務執行時間延長，效率降低。
異步提交
異步提交模式下，主數據庫獨立提交事務，不必等待輔數據庫同步，同時將數據寫入日志，輔數據庫通過事務日志同步數據。
優點：事務執行時間不受輔數據庫影響，效率高。
缺點：數據同步存在延時。
*注：我們曾經測試過SQL 2008鏡像異步提交和同步提交的效率，異步模式下，延時的時間基本可以忽略，在大事務情況下，延時也僅在秒級。而同步模式下，一旦輔數據庫出現異常，如網絡連接等錯誤，那么主數據庫將掛起，對於系統的影響巨大。
考慮到報表對於數據實時性的要求在秒級以內完全可以接受，我們建議使用異步提交模式。
1.2. 故障轉移模式
手動轉移(不存在數據丟失)
主、輔庫都是同步提交模式，且故障轉移為手動，由SSMS發起FailOver命令。
自動轉移(不存在數據丟失)
主、輔庫都是同步提交模式，且故障轉移為自動，不受人為控制，由WSFC自動仲裁。
強制轉移(存在數據丟失)
主庫是異步提交模式，且故障轉移為手動，由SSMS發起FailOver命令。由於某種原因，主、輔庫數據不同步，必須使用強制模式實現故障轉移，此時可能存在數據丟失的情況，通常應用於突發的災難恢復。當主、輔庫SQL實例均從災難中恢復正常后，可以通過數據移動功能確保數據同步。
可用性模式和故障轉移模式兼容表：
1.3. 主、輔數據庫連接方式
DotNetFramework 4. 0以后版本，為了兼容新的災難恢復AlwaysOn Cluster數據庫，連接串中增加了一個屬性ApplicationIntent，用於標識應用程序連接到數據庫的方式，ApplicationIntent有三種選項：
1) Null。不設置ApplicationIntent，默認為ReadWrite，兼容.NET 4.0以前的連接串。
2) ReadWrite。
3) ReadOnly
應用程序通過AlwaysOn群集的DNS訪問數據庫群集時，首先路由到主數據庫，然后根據應用程序連接的模式(Null、ReadWrite、ReadOnly)選擇是否路由到Read-Only輔助庫。
? 主數據庫連接方式
a) 允許所有連接。當我們設置主數據庫允許所有連接時，應用程序任何時候都可以連接到數據庫群集。
b) 允許讀/寫連接。當我們設置主數據庫只允許讀/寫連接時，ApplicationIntent= ReadOnly的應用程序連接將被阻止，並拋出異常“數據庫不允許只讀連接”。
? 輔數據庫是否允許只讀
a) NO。輔數據庫不允許讀操作。
b) Read-Intent Only。輔數據庫只讀，且只允許ReadOnly連接。此選項意味着只能通過SqlCmd –K ReadOnly、PowerShell、或者ApplicationIntent=ReadOnly的應用程序連接數據庫。我們通常使用SSMS連接到該數據庫是被禁止的。
c) Yes。輔數據庫只讀，且兼容以前的連接方式。此選項意味着可以通過任何連接方式連接到輔數據庫，且輔數據庫只讀。
典型應用場景：
2. 安裝准備工作
安裝操作系統群集和MSDTC，見《SQL2008群集配置指南（windows 2008）》。
3. 配置AlwaysOn
3.1. 啟動服務
SQL服務->啟用AlwaysOn可用性組，重啟SQL服務。各群集節點相同。
3.2. 設置數據庫完整恢復模式
在主數據庫上，將數據庫設置為完整恢復模式
3.3. 完整備份數據庫
完整備份數據庫，可放在任意目錄下。
3.4. 設置共享目錄
在主數據庫上，設置網絡共享目錄，設置everyOne可寫權限。主數據庫會將Transaction Log自動備份到共享目錄，輔助庫通過Transaction Log同步數據。
3.5. 創建AlwaysOn Group
任意指定可用性組名，如U9AvailableGroup。
選中已經備份的數據庫，這里會校驗是否滿足要求，只有滿足要求的DB才能選擇。
DB1為主數據庫，一旦發生故障轉移作為輔數據庫時，我們同樣希望它可讀，設置Readable Secondary為Yes。
端點頁簽，默認值，勿修改。
備份策略，輔數據庫優先。
創建偵聽器，偵聽1433端口，設置AlwaysOn群集IP。
回到副本頁簽，點擊“添加副本”。
連接到輔數據庫。
設置輔數據庫可讀，Readable Secondary=yes。下一步。
指定3.4節中設置的共享目錄。由於我們要做集群的庫只在DB1上存在，我們希望自動在DB2上還原一個相同的庫，選擇Full。可以根據不同情況選擇其它兩項。
驗證可用性組，如果出現異常，必須按提示修復異常信息，直到成功。
點擊完成即可。
全部成功即完成。
3.6. 設置連接方式
在主數據庫上，AlwaysOn High Availability->可用性組->上一部創建的可用性組->鼠標右鍵->屬性。
設置如下，Connections In Primary Role全部為允許所有連接，Readable Secondary全部為Yes。
3.7. 檢查Read-Only Routing List
步驟1：在主數據庫->Master數據庫上，執行如下SQL:
Select * from sys.availability_read_only_routing_lists，查看返回結果，如下：
因為我們的AlwaysOn 群集有兩個Node，因此Routing List中應有兩條記錄。OK，檢查通過。否則執行步驟2：
步驟2：在主數據庫上執行以下SQL：
ALTER AVAILABILITY GROUP U9AvailableGroup
MODIFY REPLICA ON
N'DB1' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://DB1.u9erp.com:1433'));
ALTER AVAILABILITY GROUP U9AvailableGroup
MODIFY REPLICA ON
N'DB2' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://DB2.u9erp.com:1433'));
ALTER AVAILABILITY GROUP U9AvailableGroup
MODIFY REPLICA ON
N'DB1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('DB2','DB1')));
*注：U9AvailableGroup為創建的可用性組名；DB1、DB2分別為主數據庫、輔數據庫名稱。
再次檢查Routing List，應已添加了兩條記錄。
3.8. 檢查數據庫同步情況
步驟1：檢查主數據庫，使用SSMS連接到主數據庫。
主數據庫狀態應為已同步，可用性數據庫應正常運行。見圖中紅色部分。
步驟2：檢查輔助庫，使用SSMS連接到輔助庫。
由於我們選擇的是異步提交模式，因此輔助庫顯示正在同步，正常。可用性數據庫運行正常。
3.9. 測試Read-Only Routing
我們希望當已ReadOnly方式連接數據庫群集時，默認情況下，將請求轉發到Read-Only輔助庫，可以通過Sqlcmd命令測試路由情況，在命令行中執行下列命令：
步驟1：Sqlcmd –S [群集DNS] –E –d [群集庫名] –K ReadOnly
*注：注意-K大寫。
步驟2：Select @@ServerName
步驟3：Go
DB2為ReadOnly輔助庫，測試結果返回DB2，正常。
如果返回DB1，則說明輔助庫路由沒有起作用，請檢查3.6節和3.7節設置是否正確。
4. SQL Server 2012 ReportService KB
SQL Server 2012 ReportService運行在.NET 2.0下，安裝完SQL Server 2012后，再安裝微軟補丁KB2654347。
Windows 2008 R2 ，需要安裝windows 6.1補丁；Windows 2008 SP2，需要安裝windows 6.0補丁，見附件。
5. U9配置
和SQL Server 2008配置相同，在U9配置管理工具中添加SQL Server集群地址，連接數據庫服務器。U9報表等查詢負載自動轉移到從節點。
SQLServer 2012 Always on是針對高可用性和災難恢復的新解決方案。可以配置一個或多個輔助副本以支持對輔助數據庫進行只讀訪問，並且可以將任何輔助副本配置為允許對輔助數據庫進行備份。 這樣就提供了硬件的使用效率。
“可用性組”針對一組離散的用戶數據庫（稱為“可用性數據庫”，它們共同實現故障轉移）支持故障轉移環境。一個可用性組支持一組主數據庫以及一至四組對應的輔助數據庫。可用性組在可用性副本級別進行故障轉移。故障轉移不是由諸如因數據文件丟失或事務日志損壞而使數據庫成為可疑數據庫等數據庫問題導致的。
每組可用性數據庫都由一個“可用性副本”承載。有兩種類型的可用性副本：一個“主副本”和一到四個“輔助副本”。前者用於承載主數據庫，后者則承載一組輔助數據庫並作為可用性組的潛在故障轉移目標。主副本使主數據庫可用於客戶端的讀寫連接。此外，它在稱為“數據同步”的過程中使用，在數據庫級別進行同步。主副本將每個主數據庫的事務日志記錄發送到每個輔助數據庫。每個輔助副本緩存事務日志記錄（“硬化”日志），然后將它們應用到相應的輔助數據庫。主數據庫與每個連接的輔助數據庫獨立進行數據同步。因此，一個輔助數據庫可以掛起或失敗而不會影響其他輔助數據庫，一個主數據庫可以掛起或失敗而不會影響其他主數據庫。
或者，您可以配置一個或多個輔助副本以支持對輔助數據庫進行只讀訪問，並且可以將任何輔助副本配置為允許對輔助數據庫進行備份。部署 AlwaysOn可用性組需要一個Windows Server故障轉移群集 (WSFC)群集。
圖顯示一個可用性組，該組包含最大數目的可用性副本，即一個主副本和四個輔助副本。
來自：http://msdn.microsoft.com/zh-cn/library/ff877884.aspx
雖然2012 Always on是基於WSFC的，但是並不需要共享存儲，所以配置就非常簡單。
下面是我的安裝步驟：
至少需要三台機器（我創建了三台虛擬機，一台是作為DC,DNS服務器，兩台Nod3）
| 機器名 | 角色 | 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 心跳線 |
| Node2 | Cluster Node 2 | Windows 2008R2 | 192.168.1.12 Public 192.168.2.2 心跳線窗體底端 |
首先配置Windows集群：
1. 安裝.NETFramework 3.5.1 Features和Failover Clustering
2. 安裝Windows KB 2494036
3.新建集群
4.選擇加入集群的服務器：
5.檢測配置：
6.不需要選擇檢測共享磁盤（AlwaysOn不需要）
7.開始檢測：
8.檢測內容（檢測完成后可以導出Report）：
9.之后輸入Cluster名字和IP點擊下一步創建成功，成功后打開Server Manager查看集群配置(可以看到並沒有共享磁盤，跟傳統的集群還是有區別的)
由於我們只使用了兩台機器，所以當一台機器Ｄｏｗｎ掉之后就沒有仲裁了，無法成功轉移。當使用多節點做仲裁，可以使用三台Ｎｏｄｅ，這樣一台Down掉之后另外兩台可以做仲裁。如果兩個Ｎode,不使用共享磁盤可以使用Ｓｈａｒｅ文件的方式，具體的配置可以參考：http://www.sqlskills.com/blogs/jonathan/failover-clustering-without-a-san-sql-server-2012-and-smb-for-shared-storage/（之前沒有配置這一步，雖然ＡｌｗａｙｓＯｎ級別可以Ｆａｉｌｏｖｅｒ，但是真正一台Ｎｏｄｅ Ｄｏｗｎ掉之后就不行了，感謝@struggle1指出這個問題。）
現在我們集群已經配置后了，下一步是安裝SQLServer並且配置Always On.
Part1中我們已經配置了Cluster,Part2 我們安裝SQL Server 2012 評估版（要使用64位的SQLServer, X86不支持Always On）並且配置Alaways On Group.
1. 以管理員身份安裝
2.選擇單機安裝（不是集群安裝）
3.SQL Server 2012的新功能，可以在安裝的時候搜索最新的補丁，將補丁也以前安裝（這個是可選項）
4.規則檢測
5.選擇安裝組件
6.實例名：
7.計算需要的磁盤空間：
8.Service賬戶（域賬戶）：
9.排序規則（可以根據自己需要選擇）：
10.設置權限，數據庫文件備份地址以及Filestream選項：
11.安裝后需要重新啟動（可以查看安裝日志）：
12.在ConfigurationManager中對SQL Server開啟Always OnHigh Availability(可以自動檢測到前面我們創建的Cluster名字)
設置更改后需要重啟Service.現在一切都具備了，我們可以配置Always On group了。
1.創建新的可用性組（可用性組向導，也可以用下面的選型）：
2.輸入可用性組的名字：
3.選擇組中的數據庫：
4.Replica 選擇Node2（選擇自動Failover/可讀數據庫）:
5.點擊下一步，Node1將會備份數據庫到Share Folder然后還原到Node2做同步 (Node1為主,Node2為輔助)
下一步就是測試Node2數據可讀已經Failover.
可用性組我們已經創建成功了，現在測試一下Node2 上讀取數據以及Failover.
1. 數據測據：Node1上創建表test插入記錄
在Node2上訪問test數據庫，數據可以查到（在Mirror中是不可以查詢的，而且數據同步不會導致Node2的連接斷掉）：
2. Failover測試：
連接到Node2:
Failover后（Primary已經變成Node2）：
