SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 產品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 伺服器集群简单化
  • 成功案例
    • 台灣成功案例
  • 聯繫我們
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Google雲平台中的Sanless SQL Server故障轉移群集實例

7 9 月, 2018 by Jason Aw Leave a Comment

如何在谷歌云平台上構建一個sanless sql server故障轉移群集實例

如何在Google Cloud Platform中構建Sanless SQL Server故障轉移群集實例

如果您要在Google Cloud Platform(GCP)上託管SQL Server,您需要確保它具有高可用性。最好和最經濟的方法之一是在Google Cloud Platform中構建一個Sanless SQL Server故障轉移群集實例。

成本效益

由於SQL Server Standard Edition支持故障轉移群集,因此我們可以避免與永遠在線可用性組所需的SQL Server Enterprise Edition相關的成本。此外,SQL Server故障轉移群集是一種更強大的解決方案,因為它可以保護整個SQL Server實例。它在DTC(分佈式事務處理協調器)支持方面沒有限制,並且更易於管理。此外,它支持您可能仍然擁有的早期版本的SQL Server,例如SQL 2012到最新的SQL 2017。遺憾的是,由於缺乏對跨子網故障轉移的支持,因此不支持SQL 2008 R2。

與SIOS Datakeeper有何不同?

傳統上,SQL Server FCI要求您擁有SAN或某種類型的共享存儲設備。在雲中,沒有群集感知共享存儲。代替SAN,我們將使用SIOS DataKeeper Cluster Edition(DKCE)構建SANless集群。DKCE使用塊級複製來確保每個實例上的本地連接存儲保持彼此同步。它還通過稱為DataKeeper Volume的自己的存儲類資源與Windows Server Failover Clustering集成,後者取代了物理磁盤資源。就集群而言,SIOS DataKeeper卷看起來像物理磁盤,而不是控制SCSI保留。它控製鏡像方向,確保只有活動服務器寫入磁盤,並且被動服務器同步或異步接收所有更改。

Google雲平台中的Sanless SQL Server故障轉移群集實例入門

在本指南中,我們將介紹在同一區域中的兩個實例之間構建雙節點故障轉移群集的步驟,但是在GCP內的不同區域中,如圖1所示。Google雲平台中的Sanless SQL Server故障轉移群集實例 要了解有關Sanless SQL Server故障轉移群集實例的更多信息,請訪問https://us.sios.com/sios-resources/white-paper-build-sql-server-failover-cluster-gcp/了解有關SIOS DataKeeper的更多信息經Clusteringformeremortals.com許可轉載

Filed Under: Datakeeper, 伺服器集群简单化

Linux上的MS SQL Server v.Next的高可用性故障轉移群集

24 8 月, 2018 by Jason Aw Leave a Comment

MS SQL Server V.Next在Linux上具有復制和高可用性

微軟最近發布了在Linux上運行的MS SQL Server的第一個公開預覽版。 我想知道他們會為高可用性做些什麼。了解AlwaysOn可用性組和故障轉移群集與Windows操作系統的緊密耦合,我很確定它們不是選項。我是對的 – Linux上的MS SQL Server v.Next的高可用性故障轉移群集。 好吧,LinuxClustering.Net上的人們回答了我關於如何使用這個偉大的Step by Step文章為Linux上的MS SQL Server v.Next提供高可用性故障轉移群集的問題。http://www.linuxclustering.net/2016/11/18/step-by-step-sql-server-v-next-for-linux-public-preview-high-availability-azure/不僅如此,他們還做了考慮到一些網絡限制,我們知道Azure中的一切都很棘手。Linux上的MS SQL Server v.Next的高可用性故障轉移群集 我很想知道您是否對在Linux上為MS SQL Server v.Next創建高可用性故障轉移群集感到興奮。或者,如果你認為這只是一個小科學實驗。對於興奮的人來說,Linux上的SQL Server會給開源數據庫的錶帶來什麼?既然你非常喜歡SQL Server,為什麼不在Windows上運行呢?我在這裡不是很滑稽。老實說,我想知道Linux上的SQL Server令你興奮的是什麼。我很期待你的意見。經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化

Azure自動關閉虛擬機

23 8 月, 2018 by Jason Aw Leave a Comment

Azure自動關閉虛擬機

我嘗試使我的Azure MSDN訂閱信用延長整個月。但是通過Azure Auto Shutdown For Virtual Machines,我的神經可以承受一點點休息。我通常只是構建實驗室來試用新功能或在Azure中演示SQL Server故障轉移群集。很多時候我正在測試一些非常大的實例大小和大量高級存儲。可以想像,運行幾個GS5實例可以快速燒掉150美元。我嘗試注意並在完成後關閉或銷毀實例。偶爾我會因為其他業務被拉開,只能在第二天登錄並看到我的信用已過期,因為我忘了關閉虛擬機。我很高興看到現在很容易為虛擬機配置Azure自動關機。Azure自動關閉虛擬機 但請記住,這只是關閉實例。如果您附加了高級存儲,即使實例關閉,您仍將繼續為存儲付費。

經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化

在Azure中部署2節點文件服務器故障轉移群集

22 8 月, 2018 by Jason Aw Leave a Comment

使用SIOS Datakeeper在Azure IAAS中部署高可用性文件服務器

使用SIOS DataKeeper在Azure IAAS(ARM)中部署高可用性文件服務器

在本文中,我們將詳細介紹使用Azure Resource Manager在Azure的單個區域中在Azure中部署雙節點文件服務器故障轉移群集所需的特定步驟。我將假設您熟悉基本的Azure概念以及基本的故障轉移群集概念。在本文中,我們將介紹在Azure中部署文件服務器故障轉移群集的獨特之處。使用DataKeeper Cluster Edition,您可以獲取本地連接的存儲,無論是高級存儲還是標準磁盤,並在兩個或多個集群節點之間同步,異步或混合或同時復制這些磁盤。此外,DataKeeper Volume資源在Windows Server故障轉移群集中註冊,該資源取代了物理磁盤資源。DataKeeper Volume不是像物理磁盤資源那樣控制SCSI-3保留,而是控製鏡像方向,確保活動節點始終是鏡像源。就故障轉移群集而言,它的外觀,感覺和氣味就像物理磁盤一樣,其使用方式與物理磁盤資源的使用方式相同。

在Azure中部署雙節點文件服務器故障轉移群集的先決條件

  • 您之前使用過Azure Portal,並且很樂意在Azure IaaS中部署虛擬機。
  • 已獲得SIOS DataKeeper的許可證或eval許可證

使用Azure門戶部署文件服務器故障轉移群集實例

要在Azure中部署雙節點文件服務器故障轉移群集,我們假設您擁有基於Azure資源管理器的基本虛擬網絡,並且至少有一個虛擬機已啟動並運行並配置為域控制器。配置虛擬網絡和域後,您將配置兩個新虛擬機,它們將充當群集中的兩個節點。我們的環境將如下所示:DC1 – 我們的域控制器和文件共享見證SQL1和SQL2 – 我們的文件服務器群集的兩個節點

配置兩個群集節點(SQL1和SQL2)

使用Azure門戶,我們將以完全相同的方式配置SQL1和SQL2。有多種選擇可供選擇,包括實例大小,存儲選項等。本指南並不是在Azure中部署服務器的詳盡指南,因為有一些非常好的資源,每天都有更多的資源發布。但是,在創建實例時要記住幾個關鍵事項,尤其是在群集環境中。可用性集 – SQL1,SQL2和DC1都位於同一可用性集中非常重要。通過將它們放在相同的可用性集中,我們確保每個群集節點和文件共享見證駐留在不同的故障域和更新域中。這有助於確保在計劃維護和計劃外維護期間,群集將繼續能夠維持法定人數並避免停機。在Azure中部署2節點文件服務器故障轉移群集 圖3 – 確保將群集節點和文件共享見證添加到同一可用性集

靜態IP地址

配置每個VM後,您將需要進入設置並更改設置,以使IP地址為靜態。我們不希望更改群集節點的IP地址。在Azure中部署2節點文件服務器故障轉移群集 圖4 – 確保每個群集節點都使用靜態IP

存儲

就存儲而言,您將需要參考Azure虛擬機中SQL Server的性能最佳實踐。在任何情況下,您至少需要為每個群集節點添加至少一個額外的磁盤。DataKeeper可以使用基本磁盤,高級存儲甚至是存儲池中包含多個磁盤的存儲池。只需確保為每個群集節點添加相同數量的存儲並以相同方式對其進行配置。此外,請確保為每個虛擬機使用不同的存儲帳戶,以確保一個存儲帳戶的問題不會同時影響兩個虛擬機。在Azure中部署2節點文件服務器故障轉移群集 圖5 – 確保為每個群集節點添加額外的存儲

創建群集

假設已按上述方式配置了兩個群集節點(SQL1和SQL2)並將其添加到現有域中,我們就可以創建群集了。在創建群集之前,需要啟用一些功能。這些功能是.Net Framework 3.5和故障轉移群集。需要在兩個群集節點上啟用這些功能。您還需要啟用FIle服務器角色。在Azure中部署2節點文件服務器故障轉移群集 圖6 – 在兩個群集節點上啟用.Net Framework 3.5和故障轉移群集功能以及文件服務器一旦啟用了該角色和這些功能,您就可以構建群集了。我要向您展示的大多數步驟都可以通過PowerShell和GUI執行。但是,我將建議您在第一步中使用PowerShell創建群集。如果您選擇使用故障轉移群集管理器GUI來創建群集,您會發現群集正在發出重複的IP地址。

要注意的細節

在不詳細介紹的情況下,您會發現Azure VM必須使用DHCP。通過在Azure門戶中創建VM時指定“靜態IP”,我們所做的就是創建一種DHCP預留。它不完全是DHCP保留,因為真正的DHCP保留會從DHCP池中刪除該IP地址。相反,在Azure門戶中指定靜態IP只是意味著如果VM請求它時該IP地址仍然可用,Azure將向其發出該IP。但是,如果您的VM處於脫機狀態且另一台主機在同一子網中聯機,則可能會發出相同的IP地址。Azure實施DHCP的方式還有另一個奇怪的副作用。在主機使用DHCP(必須使用DHCP)時使用Windows Server Failover Cluster GUI創建群集時,無法指定群集IP地址。相反,它依靠DHCP來獲取地址。奇怪的是,DHCP將發出重複的IP地址,通常與請求新IP地址的主機具有相同的IP地址。群集通常會完成,但您可能會遇到一些奇怪的錯誤,您可能需要從其他節點運行Windows Server Failover Cluster GUI才能運行它。一旦運行它,您將需要將群集IP地址更改為網絡上當前未使用的地址。

避免混亂

只需通過Powershell創建集群並指定集群IP地址作為PowerShell命令的一部分來創建集群,就可以避免這種混亂。您可以使用New-Cluster命令創建集群,如下所示:

New-Cluster -Name cluster1 -Node sql1,sql2 -StaticAddress 10.0.0.101 -NoStorage

群集創建完成後,您還需要運行以下命令來運行群集驗證:

測試群集

在Azure中部署2節點文件服務器故障轉移群集 圖7 – 集群創建的輸出和集群驗證命令

創建文件共享見證

由於沒有共享存儲,因此您需要在與兩個群集節點相同的可用性集中的另一台服務器上創建文件共享見證。通過將其置於相同的可用性集中,您可以確保在任何給定時間僅從您的法定人數中失去一票。如果您不確定如何創建文件共享見證,可以查看本文http://www.howtonetworking.com/server/cluster12.htm。在我的演示中,我將文件共享見證放在域控制器上。我已經在https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-上發布了對群集仲裁的詳盡解釋。在窗口服務器-2012-R2 /

安裝DataKeeper

創建集群後,就可以安裝DataKeeper了。在創建初始群集後安裝DataKeeper非常重要,這樣可以向群集註冊自定義群集資源類型。如果在創建群集之前安裝了DataKeeper,則只需再次運行安裝並執行修復安裝。在Azure中部署2節點文件服務器故障轉移群集 圖8 – 創建集群後安裝DataKeeper在安裝過程中,您可以使用所有默認選項。 您使用的服務帳戶必須是域帳戶,並且位於群集中每個節點上的本地管理員組中。在Azure中部署2節點文件服務器故障轉移群集 圖9 – 服務帳戶必須是每個節點上Local Admins組中的域帳戶一旦在每個節點上安裝DataKeeper並獲得許可,您將需要重新啟動服務器。

創建DataKeeper卷資源

要創建DataKeeper Volume Resource,您需要啟動DataKeeper UI並連接到這兩個服務器。在Azure中部署2節點文件服務器故障轉移群集 連接到SQ在Azure中部署2節點文件服務器故障轉移群集L1連接到S在Azure中部署2節點文件服務器故障轉移群集QL2連接到每個服務器後,您就可以創建DataKeeper捲了。右鍵單擊Jobs並選擇“Creat在Azure中部署2節點文件服務器故障轉移群集e Job”為作業命名和描述。在Azure中部署2節點文件服務器故障轉移群集 選擇源服務器,IP和卷。IP地址是複制流量是否會傳播。在Azure中部署2節點文件服務器故障轉移群集 選擇目標服務器。在Azure中部署2節點文件服務器故障轉移群集 選擇你的選擇。對於兩個VM位於同一地理區域的目的,我們將選擇同步複製。對於更長距離的複制,您將需要使用異步並啟用一些壓縮。在Azure中部署2節點文件服務器故障轉移群集 通過在上次彈出窗口中單擊“是”,您將在故障轉移群集中的可用存儲中註冊新的DataKeeper卷資源。您將在可用存儲中看到新的DataKeeper卷資源。在Azure中部署2節點文件服務器故障轉移群集

創建文件服務器群集資源

要創建文件服務器群集資源,我們將再次使用Powershell而不是故障轉移群集接口。原因在於,再次因為虛擬機配置為使用DHCP,基於GUI的嚮導不會提示我們輸入群集IP地址,而是發出重複的IP地址。為避免這種情況,我們將使用簡單的powershell命令創建FIle Server群集資源並指定IP地址

Add-ClusterFileServerRole -Storage“DataKeeper Volume E” 
-Name FS2 -StaticAddress 10.0.0.201

記下您在此處指定的IP地址。它必須是網絡上唯一的IP地址。我們稍後在創建內部負載均衡器時將使用相同的IP地址。

創建內部負載均衡器

以下是Azure中的故障轉移群集與傳統基礎結構的不同之處。Azure網絡堆棧不支持免費ARPS。 客戶端無法直接連接到群集IP地址。相反,客戶端連接到內部負載平衡器並重定向到活動群集節點。我們需要做的是創建一個內部負載均衡器。這可以通過Azure門戶完成,如下所示。首先,創建一個新的Load 在Azure中部署2節點文件服務器故障轉移群集Balancer如果您的客戶端通過公共Internet連接,您可以使用公共負載均衡器,但假設您的客戶端位於同一個vNet中,我們將創建一個內部負載均衡器。需要注意的重要一點是,虛擬網絡與群集節點所在的網絡相同。此外,您指定的專用IP地址將與用於創建SQL群集資源的地址完全相同。在Azure中部署2節點文件服務器故障轉移群集 創建內部負載均衡器(ILB)後,您需要對其進行編輯。我們要做的第一件事就是添加一個後端池。通過此過程,您將選擇SQL Cluster VM所在的可用性集。但是,當您選擇要添加到後端池的實際VM時,請確保不要選擇文件共享見證。我們不希望將SQL流量重定向到您的文件共享見證。在Azure中部署2節點文件服務器故障轉移群集 在Azure中部署2節點文件服務器故障轉移群集 接下來我們要做的就是添加一個Probe。我們添加的探針將探測端口59999。此探針確定群集中哪個節點處於活動狀態。在Azure中部署2節點文件服務器故障轉移群集 最後,我們需要一個負載平衡規則來重定向SMB流量,TCP端口445。在下面的屏幕截圖中需要注意的重要事項是直接服務器返回已啟用。確保你做出改變。在Azure中部署2節點文件服務器故障轉移群集

修復文件服務器IP資源

幾乎可以在Azure中部署2節點文件服務器故障轉移群集!配置的最後一步是在其中一個群集節點上運行以下PowerShell腳本。這將允許群集IP地址響應ILB探測並確保群集IP地址和ILB之間不存在IP地址衝突。請注意;您需要編輯此腳本以適合您的環境。子網掩碼設置為255.255.255.255,這不是錯誤,保持原樣。這將創建一個特定於主機的路由,以避免與ILB發生IP地址衝突。

#定義變量
$ ClusterNetworkName =“” 
#群集網絡名稱 
(在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名稱)
$ IPResourceName =“” 
#IP地址資源名稱 
$ ILBIP =“” 
#內部負載均衡器的IP地址(ILB)
導入模塊FailoverClusters
#如果您使用的是Windows Server 2012或更高版本:
Get-ClusterResource $ IPResourceName | SET-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”;
網絡= $ ClusterNetworkName; EnableDHCP時= 0}
#如果您使用的是Windows Server 2008 R2,請使用以下命令: 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
子網掩碼= 255.255.255.255

創建文件共享

您會發現在故障轉移群集管理器中使用文件共享嚮導不起作用。相反,您只需在活動節點上的Windows資源管理器中創建文件共享。故障轉移群集會自動獲取這些共享並將其放入群集中。請注意,此配置不支持文件共享的“連續可用性”選項。

結論

您已設法在Azure中部署雙節點文件服務器故障轉移群集。  如果您有任何問題,請通過Twitter @daveberm聯繫我,我很樂意提供幫助。如果您需要DataKeeper評估密鑰,請填寫http://us.sios.com/clustersyourway/cta/14-day-trial上的表格,SIOS將發送一份發送給您的評估密鑰。經Clusteringformeremortals.com許可轉載

Filed Under: Datakeeper, 伺服器集群简单化

SQL Server 2016支持分佈式事務

21 8 月, 2018 by Jason Aw Leave a Comment

SQL Server 2016支持使用AlwaysOn可用性組的分佈式事務

SQL Server 2016對具有Always On Availability Groups的分佈式事務的支持聽起來非常有前景。 他們確實在這方面做了一些改進,但尚未完全支持。分發事務源示例 – 可用性組中的SQL Server 2016 DTC支持[/ caption]僅在事務處理時支持SQL Server 2016支持分佈式事務分佈在多個SQL Server實例中。如果事務在同一SQL Server實例中的不同數據庫之間分發,則不支持它。因此,在上圖中,如果數據庫位於不同的SQL實例上,它將起作用。但是,如果數據庫駐留在更可能的同一實例上,則不會。如果在同一SQL Server實例中的不同數據庫之間需要分佈式事務支持並且需要高可用性,則仍必須使用傳統的SQL Server Always On Failover Cluster或使用DataKeeper的SANLess Cluster。經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化 Tagged With: AlwaysOn故障轉移群集

  • « Previous Page
  • 1
  • …
  • 74
  • 75
  • 76
  • 77
  • 78
  • …
  • 98
  • Next Page »

最近的帖子

  • 在 Nutanix 環境中選擇高可用性解決方案的 10 個注意事項
  • 我的伺服器是一次性的嗎?高可用性軟體如何適應雲端最佳實踐
  • 災難頻傳世界的資料復原策略
  • DataKeeper 與棒球:災難復原的策略性舉措
  • SQL Server 停機風險預算

最熱門的帖子

加入我們的郵件列表

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in