Date: 9 2 月, 2018
遷移到雲中的潛在成本節約幾乎是不可能的。但是，當你停止計算你將要存儲的資金之後，你就開始考慮安全性和可用性等問題，並想知道云計算是否適合你。但是不要害怕，我們只有正確的解決方案 – 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/