遷移到雲中的潛在成本節約幾乎是不可能的。但是，當你停止計算你將要存儲的資金之後，你就開始考慮安全性和可用性等問題，並想知道云計算是否適合你。但是不要害怕，我們只有正確的解決方案 – SIOS Datakeeper Cluster Edition。在傳統的數據中心，您可以控制並部署您喜歡的任何安全性和高可用性解決方案。但是，一旦決定將服務器移到雲中，您的選擇就會變得更加有限。無論您是在亞馬遜，Google還是微軟，無論是在雲端出現故障還是出現故障，您都需要盡一切可能來緩解這些風險。

亞馬遜網絡服務

我們來仔細看一下Amazon Web Services（AWS）。有什麼選項可以確保您的SQL Server數據庫能夠在意外中斷的情況下生存下來？雖然有些應用程序可以跨多個可用區域以負載平衡配置進行部署，但SQL Server通常不會以負載平衡配置進行部署。這意味著SQL Server本身駐留在單個可用區域中，如果該區域不可用，則整個應用程序堆棧可能會陷入癱瘓。

SQL Server 2008 R2及其限制

如果您閱讀Miles Ward撰寫的這篇文章，您將看到，使用SQL Server 2008 R2，您的可用性選項非常有限。在第11頁的那篇文章中，有一個很好的圖表，列出了您的高可用性選項。正如你所看到的，這些選擇是非常有限的，大部分都不屬於被稱為醫管局的類別。日誌傳送，鏡像和事務複製幾乎是您擁有的唯一選項，它們更多是數據保護選項而不是HA選項。如果您希望Microsoft故障轉移群集，那麼由於AWS中的某些網絡限制（客戶端無法連接到群集IP地址）以及缺少傳統SQL群集所需的共享磁盤資源，您將發現自己不幸運。

AWS

如果你正在尋找部署SQL Server 2012，你的選擇會好一點。正如Jeremy Peschka所述，只需少量手動干預，您就可以在AWS中部署AlwaysOn可用性組，以便從數據中心到AWS甚至是AWS可用性組之間進行異步複製。當然，這假定您擁有AlwaysOn可用性組所需的SQL 2012 Enterprise許可證。唯一的問題是AWS實際上不支持將群集IP地址從一個服務器移到另一個服務器，所以客戶端重定向必須使用ec2-unassign-private-ip-addresses和ec2-assign-private-ip手動完成在佩斯卡在他的文章中所描述的轉換之後的地址命令。總而言之，這是一個非常手動的過程，這再一次不適合描述高度可用的系統。

解決方案的局限性

如果您可以在沒有自動恢復的情況下運行，並且可以在之前的博客文章中描述的AlwaysOn可用性組限制，那麼您可能只想繼續嘗試AWS中的AlwaysOn可用性組部署。但是，如果您正在尋找更簡單，更實惠，更強大的高可用性解決方案，那麼我有一些非常好的消息。SIOS技術公司一直在研究這個問題，並開發了一種解決方案，克服了前面所述的所有限制，並且將作為AMI提供，以便於部署。這個解決方案目前處於內部測試階段，但將在今年晚些時候廣泛推出。

SIOS DataKeeper集群版

SIOS解決方案基於使用DataKeeper Cluster Edition主機複製的Microsoft故障轉移群集中的SQL Server。通過使用基於託管的複制，他們已經克服了EC2中集群的第一個障礙 – 缺乏共享存儲。SIOS必須克服的第二個障礙是Peschka描述的客戶端重定向問題;客戶端訪問點需要在EC2內進行操作，而不是故障轉移群集。SIOS在他們的AMI解決方案中建立了智能，使得IP地址的重新分配作為集群故障轉移過程的一部分被自動化，有效地模擬了您通常期望從集群獲得的行為。因為所有這些都是建立在故障轉移群集之上的，所以可以使用SQL 2008/2008 R2或2012進行部署。即使是SQL Server的標準版也將支持雙節點集群，因此與部署SQL 2012 AlwaysOn可用性組相比，成本節約可能會相當大。讓我知道你的想法。SIOS Datakeeper Cluster Edition聽起來有趣嗎？今天你在做什麼來確保你的SQL Server EC2實例的可用性？轉載https://clusteringformeremortals.com/2013/01/11/sql-server-high-availability-in-aws-cloud/

一個小回顧

在之前的文章中，我介紹了構建雙節點集群的過程，直到我們準備好開始在Windows Server 2012上集群SQL Server 2012。如果您已完成這些步驟，則可以繼續前進，並使用建議的SIOS Datakeeper Cluster Edition實際創建群集應用程序。

下一步，集群SQL Server 2012

首先，我們有SQL Server 2012。SQL Server 2012群集安裝與SQL 2008/2008 R2群集安裝非常相似，所以即使使用SQL 2008/2008 R2，也會應用大部分此類群集。有關SQL Server 2012集群的術語會變得有些複雜。您將會聽到SQL Server AlwaysOn的提及，這實質上可能意味著兩種不同的東西之一：AlwaysOn可用性組或AlwaysOn故障轉移群集實例。由於這兩種解決方案都需要與Windows Server故障轉移群集進行一定程度的集成，並且由於您可以部署AlwaysOn可用性組和AlwaysOn故障轉移群集的組合，所以更令人困惑，但這是另一個話題！

簡單易懂地將其打破

本質上，AlwaysOn可用性組是以前在SQL 2008 R2和更早版本中稱為數據庫鏡像的。它有一些新的功能可以克服早期版本的數據庫鏡像的一些限制，所以值得一試。AlwaysOn故障轉移群集實例就是以前稱為SQL Server故障轉移群集的東西。這是自SQL Server早期版本以來的相同集群技術的最新版本。SQL Server 2012 AlwaysOn故障切換群集實例的最佳新功能之一是可以在不同子網中擁有節點。這是早期版本的SQL Server中的主要限制。在之前的一篇博客文章中，我討論了AlwaysOn可用性組的一些限制，在做出關於部署哪種技術的決定之前，您應該檢查一下。

開始吧

這就是說，本文將重點介紹部署SQL Server 2012 AlwaysOn故障轉移群集實例的分步說明。

步驟1

確保您的集群存儲已準備就緒。如果你按照我以前的文章的說明，你會知道，而不是共享磁盤資源，我們將使用第三方軟件DataKeeper Cluster Edition的複制磁盤資源。如果您正在使用共享存儲並添加了存儲，則可以跳到步驟2開始SQL安裝。否則，請按照以下步驟將軟件配置為複製本地磁盤以用於SQL群集。

配置DataKeeper Cluster Edition

1. 安裝和配置DataKeeper Cluster Edition
   1. 運行DK安裝程序
      
   2. 瀏覽整個安裝過程，選擇所有的默認值。
      
      
      
      
      
      
      
      
   3. 按照提示完成安裝後重新啟動計算機，然後在SECONDARY服務器上重複該過程
   4. 在PRIMARY上啟動DataKeeper UI，然後單擊連接到服務器。連接到PRIMARY，然後連接到SECONDARY
      
      
   5. 單擊創建作業，然後瀏覽創建作業嚮導以創建E驅動器的鏡像
      
      
      選擇鏡像的源捲和將承載複製流量的NIC的IP地址。
      選擇鏡像的目標，然後單擊下一步
      
      在這裡你會選擇你的鏡子選項：
      壓縮 – 只能在WAN上進行複制
      異步 – 為所有廣域網複製選擇此選項
      同步 – 這是LAN複製的理想選擇
      允許使用最大帶寬 – 用於WAN複製作為限制帶寬複製量的一種方式。通常它應該保留在0，但是對於初始鏡像創建，您可能想要限制帶寬，以便複製不會使用所有可用帶寬來執行初始同步
      
      一旦你點擊完成鏡像將被創建。
      鏡像創建完成後，系統將提示您在Windows Server故障轉移群集（WSFC）中註冊該卷。單擊“是”，將在“可用存儲”中註冊一個新的DataKeeper卷資源（請參見步驟2中的圖片）。