停機時間！誰應該承擔責任？
確保高可用性選項對於SQL Server，始終可能是我們使用雲服務的主要原因。但是，防止與雲中斷相關的停機時間是任何在任何云服務上部署的人都需要解決的問題。只需在“雲端”部署您的應用程序並假定現在管理其他人的問題很容易。雲提供商可能擁有更多資源和專業知識，以確保您的服 但確保您的關鍵應用程序可用的最終責任完全在於您。
SQL Server的高可用性選項並不像ABC那麼容易
信不信由你，只需在Windows Azure中部署你的SQL Server就不會使它“高度可用”。為了使其高度可用，您必須使用您可能在自己的數據中心中使用的傳統工具和技術。雖然對此主題有不同意見，但我認為SQL Server 2012/2014的高可用性選項如下：
無論您選擇哪個選項，您都希望熟悉Windows Azure故障域，如下所述：
“儘管如此，在Windows Azure中，一台計算機確實被確定為故障域。並且在部署時由Windows Azure確定故障域的分配。服務所有者無法控制故障域的分配，但可以通過編程方式找出服務在哪個故障域中運行。Windows Azure計算服務SLA僅在部署服務的每個角色的兩個或多個實例時才保證已部署服務的連接正常運行時間級別“
讓您的SQL Server駐留在不同的故障域中
在您開始部署Windows Azure VM時，請確保每個SQL Server和任何“見證”服務器駐留在不同的故障域中。通過將所有虛擬機置於相同的“可用性集”中來實現這一點。本質上，同一個可用性集中的每個服務器都駐留在不同的故障域中，希望能夠消除故障。
將所有虛擬機置於不同的故障域中，並配置SQL Server故障轉移群集或可用性組，以防止可能本地化為單機架服務器，即AKA故障域的常見故障類型。我已經寫了一篇文章，題為在Windows Azure IaaS中使用DataKeeper創建SQL Server 2014 AlwaysOn故障轉移群集（FCI）實例，這應該有助於您在Azure雲中為您的SQL Server構建恢復能力。
但是，如果Windows Azure發生重大中斷並導致整個地區發生什麼？
自然災害或人為錯誤可能是導致此類停電的原因。不幸的是，在這一點上，無法在兩個不同的Azure區域之間拉伸Azure虛擬專用網絡。這包括東南亞。但是，Azure虛擬專用網絡可以支持與有限數量的VPN設備進行站點到站點VPN連接。這些設備來自思科，瞻博網絡甚至微軟RRAS。
如何在Azure之外的某個地方？
這讓我們想到了Azure之外的其他位置，甚至是我們自己的私人數據中心。我最近編寫了一篇分步說明文章，介紹如何將您的內部數據中心擴展到Azure Cloud。將數據中心連接到Windows Azure，配置AlwaysOn可用性組或AlwaysOn故障轉移群集（多站點），以防止發生災難性Azure故障。我以前寫過關於多站點群集的優勢與 可用性組。 因此，在我的實驗室中，我決定在Azure中創建一個雙節點SQL故障轉移群集實例，然後在我的主數據中心添加第三個節點。我在我的博客文章中寫了詳細的配置步驟，名為“在Windows Azure中創建多站點群集以進行災難恢復”。
如果您更願意使用AlwaysOn可用性組，則可能需要訪問Windows Azure中的AlwaysOn可用性組（GUI）和Windows Azure中的AlwaysOn可用性組的Listener配置教程。如果您使用的是SQL 2008 R2或更早版本，我相信您可以配置數據庫鏡像。此時，如果您正在轉向Azure，那麼我假設您可能正在部署SQL Server 2012或2014。日誌傳送和復制等其他技術是移動數據的選項，但我不認為它們是高可用性解決方案。
經https://clusteringformeremortals.com/2014/01/15/windows-azure-high-availability-options-for-sql-server-azure-cloud-iaas/許可轉載