在企業私有雲端應用程式的架構設計中，其背後的資料庫運作之高可用性設計，已成為了整體雲端作業的靈魂所在，因此在許多企業中的私有雲端關鍵應用系統，其後端的資料庫系統都會被規劃成高可用性的建置，然而不同資料庫系統廠商所提供的資料庫高可用性的能力都太一樣。有些企業IT在規劃時，便會選擇整合第三方協力廠商的產品，來解決雲端資料庫高可用性的建置需求。

Microsoft SQL Server從過去的版本以來，無論是資料庫的備份還是高可用性的備援機制，嚴格來說都是不太需要整合第三方軟體來達成目標的，只要您也和筆者一樣熟悉SQL Server的管理，相信您也會有著同樣的認知。然而隨著企業資料量的快速增長以及系統永續運作的嚴酷考驗下，資料庫的大小必須隨著儲存設備容量的快速增長，不斷提升其資料庫存取的速度。此外高可性的架構設計，還必須能夠根據企業資訊環境的不同，而提供相對的架構部署支援。SQL Server從早期須結合共用儲存區的叢集架構支援，到後來在SQL Server 2005版本中所新增加的資料庫鏡像（Database Mirroring）功能，如今又在SQL Server 2012與SQL Server 2014版本中提供了更為強大的AlwaysOn功能。

AlwaysOn所提供的四個複寫節點相較於Database Mirroring的一個鏡像節點，顯然提供了更具高可用性的延展能力，除此之外筆者也發現到，若採用Database Mirroring資料庫在後端的其它主機中，其前端的應用程式的連線字串便需要修改，但若採用AlwaysOn的架構設計，則前端的應用程式的連線字串一開始就指向可有性群組的接聽位址即可，這是因為AlwaysOn是架構在Windows Server 2008 R2（也支援Windows Server 2012/R2）的容錯移轉叢集（WSFC）基礎之上。

由於AlwaysOn是架構在WSFC的基礎上，因此與Database Mirroring的資料庫層級同步備援機制有很大的不同。首先它所建立的每一個可用性群組中（Availability Groups），可以加入多個符合要求的應用程式資料庫來進行同步，並且提供一個共用接聽程式（位址）來讓前端應用程式連線存取。接著AlwaysOn的複本資料庫僅呈現唯讀狀態，讓應用程式可以進行讀取來進行諸如報表的資料收集等作業，不像AlwaysOn的鏡像節點還得結合資料庫快照的方式來進行。最後則是AlwaysOn並非是資料庫層級的備援機制，因此不會像Database Mirroring的架構，會有伺服器層級物件必須自行手動建立於每一部SQL Server的問題。

若您想架構Database Mirroring的高可用性環境，最低需求在SQL Server 2012中同樣只需要採用標準版（包含Windows Server 2008 R2也一樣）即可，便可以建置出雙節點的手動容錯備援架構。然而如果是想要架構最新的AlwaysOn高可用性環境，則不僅Windows Server 2008 R2需要是企業版，就連同SQL Server 2012也需要是企業版才可以，如此才能有WSFC與AlwaysOn功能的完美結合。

感恩 ~