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