SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

如何在多站點群集中使用異步複製？數據不同步？

by Leave a Comment

我被問過這個問題不止幾次，所以我想我會在我的第一篇博客文章中回答這個問題。基本答案是肯定的，在多站點集群中使用異步複製時，可能會導致意外失敗的數據丟失。在一個理想的世界裡，每個公司都會有一個到他們災難恢復站點的暗光纖連接，並使用與他們的多站點集群同步複製，消除數據丟失的可能性。但是，現實情況是，在許多情況下，到災難恢復站點的廣域網連接有太多的延遲來支持同步複製。在這種情況下，異步複製是一個很好的選擇。選擇WSFC多站點群集使用的異步複製解決方案時，有多種選擇，包括來自EMC，IBM，HP等公司的基於陣列的解決方案。以及基於主機的解決方案，就像“SteelEye DataKeeper Cluster Edition”中那樣近乎親愛的解決方案。由於我最了解DataKeeper，所以我將解釋DataKeeper的這一切是如何工作的。當使用SteelEye DataKeeper和異步複製時，我們允許將一定數量的寫入存儲在異步隊列中。可以排隊的寫入次數由“高位標記”確定，“高位標記”是DataKeeper用來確定鏡像狀態從“鏡像”更改為“暫停”之前隊列中有多少數據的可調整值。。當輔助服務器和主服務器之間發生通信故障時，也會進入“暫停”狀態。處於暫停狀態時，多站點群集中的自動故障轉移將被禁用，從而限制意外故障中可能丟失的數據量。如果原始數據集被認為是“永久丟失”，則可以手動解鎖目標服務器上的剩餘數據，然後可以使集群節點投入使用。在“暫停”狀態下，DataKeeper允許異步隊列耗盡，直到達到“低水位”，此時鏡像將進入“重新同步”狀態，直到所有數據再次同步。此時，鏡像再次處於“鏡像”狀態，並且自動故障轉移再次啟用。只要你的廣域網鏈路沒有飽和或破壞，在這個異步隊列中的任何時候，你永遠不應該看到更多的寫入。如果出現意外的故障（請拔掉電源線），您將失去異步隊列中的任何寫入。當您需要使用多站點群集實現的卓越恢復點目標（RPO）和恢復時間目標（RTO）時，這是您所做的交易，但是您的WAN鏈路有太多的延遲來有效支持同步複製。如果您需要花時間通過Windows性能日誌和警報來監視DataKeeper異步隊列，那麼由於DataKeeper複製引擎的高效性，我認為您會驚喜地發現大部分時間異步隊列都是空的。即使在大量寫入的時候，異步隊列也很少會變得非常大，並且幾乎立即就會排空，所以在任何給定時間處於風險的數據量都是最小的。如果考慮到災難中的備選方案可能是從昨晚的備份中恢復，那麼使用異步複製可能導致意外故障的寫入次數極少！當然，也有一些情況下，即使丟失一個單一的寫是不可容忍的。在這種情況下，建議在高速，低延遲的LAN或WAN連接上使用SteelEye DataKeeper的同步複製選項。轉載https://clusteringformeremortals.com/2009/07/的許可

為什麼我應該把我的#AZURE集合轉換為管理磁盤今天！

by Leave a Comment

您可能已經聽說過最近的存儲中斷，影響了美國東部地區在3月16日的一些情況。 停電的根本原因分析在這裡張貼。

3月16日美國東部存儲中斷

客戶影響：在美國東部地區使用Storage的客戶的一小部分可能在單個存儲量表單元訪問其存儲帳戶時遇到錯誤和超時

您可能會問：“什麼是單個存儲量表單元”。 那麼，你可以把它看成一個單一的存儲集群，或是一個SAN，或者你想要考慮它。 我不認為Azure發布其精確的基礎架構，但是您可以假設幕後使用的是擴展文件服務器來進行後端存儲。

所以問題是，如何以最短的停機時間在這種停電中倖存下來？如果你進一步閱讀根本原因分析，你會遇到這個小塊。

在可用性集中使用託管磁盤的虛擬機將在此事件期間保持可用性。

什麼是託管磁盤你問？那麼就在2月8日，科里·桑德斯（Corey Sanders）宣布管理磁盤陣列。 您可以在這裡閱讀有關託管磁盤的所有信息。 https://azure.microsoft.com/en-us/services/managed-disks/

託管磁盤有助於中斷這一原因是通過利用可用性集合與託管磁盤組合，您可以確保可用性集中的每個實例都連接到不同的“存儲量表單元”。 因此，在這種特殊情況下，只有一個集群節點將失敗，剩下的節點才能接管工作負載。

在託管磁盤可用之前（任何部署在2/8/2016之前），沒有辦法確保連接到您的服務器的存儲位於不同的存儲容量單位上。 當然，您可以為每個實例使用不同的存儲帳戶，但實際上並不能保證這些存儲帳戶在不同的存儲量表單元上配置存儲。

因此，當可用性集確保您的實例駐留在不同的故障域和更新域中以確保實例本身的可用性時，附加到每個實例的額外存儲確實代表了單點故障。 雖然存儲本身俱有高度的靈活性，但可以使用三個數據副本和地理冗餘選項，在這種情況下，電源故障，整個存儲量表單元與連接的所有服務器一起下降。

這麼長的故事簡短…盡快遷移到託管磁盤，以幫助最小化停機時間

https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to-managed-disks

如果您真的想減少停機時間，那麼您應該考慮跨雲提供商的混合雲部署或云計算的一體機。

使用 arm 在 azure 中部署2節點檔案伺服器容錯移轉叢集

by Leave a Comment

使用 arm 在 azure 中部署2節點檔案伺服器容錯移轉叢集

在這篇文章中我們將詳細介紹部署在 Azure 使用 Azure 資源管理器的單個區域的 2 節點檔案伺服器容錯移轉叢集所需的具體步驟。我將假設你熟悉蔚藍的基本概念，以及容錯移轉叢集的基本概念和這篇文章在什麼是獨特的部署檔案伺服器容錯移轉叢集在 Azure 將焦點。

與 DataKeeper 集群版你是能夠採取本地連接的儲存體，是否它是溢價或標準的磁片，以及無論是同步、非同步複製這些磁片或混合或兩個，兩個或多個叢集節點之間。此外，Windows 伺服器容錯移轉叢集的實體磁碟資源發生在註冊 DataKeeper 卷資源。而不是控制 SCSI 3 保留像實體磁碟資源，DataKeeper 音量控制鏡子方向，確保主動節點始終鏡像的源。容錯移轉叢集而言，它看起來、感覺和聞起來像物理磁片和用同樣的方式將使用實體磁碟資源。

必備條件

使用 azure 門戶部署檔案伺服器容錯移轉叢集實例

打造 Azure 中 2 節點檔案伺服器容錯移轉叢集實例，我們將假定您有一個基本的虛擬網路基於 Azure 資源管理器上和你有至少一個虛擬機器啟動運行且配置為網域控制站。一旦你有一個虛擬的網路和域配置，您要提供兩個新的虛擬機器將作為我們的集群中的兩個節點。

我們的環境將如下所示：

DC1 — — 我們的網域控制站和檔案共用見證
SQL1 和 SQL2 — — 我們檔案伺服器群集中的兩個節點

設置兩個叢集節點 (sql1 和 sql2)

使用 Azure 門戶，我們將提供 SQL1 及 SQL2 完全相同的方式。有許多選項可供選擇的包括實例的大小、存儲選項等。本指南不是要部署在 Azure 伺服器，因為有一些很好的資源和更多公佈的每一天的詳盡指南。然而，有幾個關鍵的事情，要牢記心中，特別是在集群環境中創建您的實例時。

可用性組 — — 重要的是 SQL1、SQL2 和 DC1 駐留在相同的可用性設置。把它們放在同一可用性設置為了確保每個叢集節點和檔案共用見證的檔駐留在不同故障和更新域。這有助於確保在計畫的維護和群集將繼續能夠維持仲裁併避免停機時間的額外的維護期間。

3
圖 3 — — 一定要添加叢集節點和檔案共用見證到相同的可用性設置

靜態 IP 位址

一旦被提供每個 VM，要進入設置和更改的設置，是靜態的 IP 位址。我們不想改變我們叢集節點的 IP 位址。

4
圖 4 — — 確保每個叢集節點使用一個靜態的 ip 位址

存儲

存儲而言，你會想要請教，SQL Server 在 Azure 虛擬機器的性能最佳做法。在任何情況下，你將微需要添加到每個叢集節點至少一個額外的磁片。DataKeeper 可以使用基本磁碟、保費存儲或甚至組成的存儲池中的多個磁片的存儲池。只是存儲的一定要將相同數量添加到每個叢集節點並將其配置完全相同。另外，一定要使用一個不同的存儲帳戶，為每個虛擬機器以確保在同一時間同一個存儲帳戶的問題不會影響這兩個虛擬機器。

5
圖 5 — — 一定要向每個叢集節點中添加額外的存儲

創建群集

假設兩個叢集節點 （SQL1 和 SQL2） 有調配如上文所述，添加到您現有的域，我們準備創建群集。我們在創建群集之前，有幾個功能，需要啟用。這些功能是.Net Framework 3.5 和容錯移轉叢集。需要在兩個叢集節點上啟用這些功能。您還將需要啟用檔案伺服器角色。

6
圖 6 — — 啟用這兩個.Net Framework 3.5 和容錯移轉叢集功能和檔案伺服器上兩個叢集節點

一旦已啟用了這一作用和那些功能，你就可以打造您的群集。大部分的通過 PowerShell 和 GUI 正要顯示您可以執行兩個步驟。然而，我要去推薦，對於這第一步你使用 PowerShell 創建您的群集。如果你選擇使用容錯移轉叢集管理器圖形化使用者介面來創建群集，你會發現，風正在問題重複的 IP 位址的群集。

沒有繼續深入，你會發現是 Azure Vm 必須使用 DHCP。通過指定靜態 ip 位址，當我們在 Azure 門戶中創建 VM 我們所做的一切是創造某種 DHCP 保留。它不完全是 DHCP 保留，因為真正的 DHCP 保留將從 DHCP 池中刪除該 IP 位址。相反，這在 Azure 門戶中指定一個靜態 ip 位址只是意味著，如果該 IP 位址是仍然可用，VM 請求它時，Azure 將向它發出該 IP。然而，如果你的虛擬機器處於離線狀態，另一台主機連線，同一子網中它很好能發出那相同的 IP 位址。

還有另一個奇怪的副作用到 Azure 已實現 DHCP 的方式。當創建的群集與 Windows 伺服器容錯移轉叢集 GUI 時主機使用 DHCP （其中他們有到），不是選項，以指定一個群集 IP 位址。相反，它依賴 DHCP 獲取位址。奇怪的是，DHCP 將發出一個重複的 IP 位址，通常主機請求一個新的 IP 位址相同的 IP 位址。群集通常將完成，但你可能有一些奇怪的錯誤，您可能需要從不同的節點運行 Windows 伺服器容錯移轉叢集 GUI，為了得到它來運行。一旦你有要走你會想要將群集 IP 位址更改為當前未在網路上使用的位址。

通過簡單地創建群集通過 Powershell 和指定的群集 IP 位址作為 PowerShell 命令以創建群集的一部分，可以避免這一團糟。

您可以創建群集使用新群集命令，如下所示：

新群集-名稱 cluster1-節點 sql1，sql2-StaticAddress 10.0.0.101-NoStorage

群集創建完成後，你還想要運行群集驗證通過運行以下命令：

測試群集

7
圖 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-in-windows-server-2012-r2/ 群集仲裁

安裝資料管理員

它創建群集後是時間要安裝 DataKeeper。它是重要安裝 DataKeeper 後以便與群集可以註冊的自訂群集資源類型創建初始群集。如果在創建群集之前，你安裝 DataKeeper 你只需要再次運行安裝程式並修復安裝。

8
圖 8 — — 安裝 DataKeeper 後創建群集

在安裝過程中，你可以帶走所有預設選項。 您使用的服務帳戶必須是域帳戶，而且必須在群集中每個節點上的本地管理員組。

9
圖 9 — — 服務帳戶必須是在每個節點上的本地管理員組中的域帳戶

一旦 DataKeeper 是安裝和許可您將需要重啟伺服器，每個節點上。

創建資料管理員卷資源

要創建 DataKeeper 卷資源，您需要啟動 DataKeeper UI 並連接到兩個伺服器。
10連接到 SQL1
11

連接到 SQL2
12

一旦你連接到每個伺服器，你是準備好創建您的 DataKeeper 卷。在工作崗位上右擊並選擇"創建作業"
13

給這份工作的名稱和說明。
14

選擇你的源伺服器，IP 和卷。IP 位址是是否複製交通出行。
15-檔案伺服器容錯移轉叢集

選擇您的目標伺服器。
16

選擇您的選項。我們的目的而言，兩個虛擬機器在同一地理區域在哪裡，我們會選擇同步複製。對於更長的距離複製要使用非同步和啟用一些壓縮。
17

通過按一下在上一個快顯視窗將在容錯移轉叢集中可用的存儲中註冊新的 DataKeeper 卷資源。
18

您將看到新的 DataKeeper 卷資源的可用存儲空間。
19

創建檔案伺服器群集資源

若要創建檔案伺服器群集資源, 我們將再次使用 powershell, 而不是容錯移轉叢集介面。這是當虛擬機器配置為使用 dhcp 時, 基於 gui 的嚮導不會提示我們輸入群集 ip 位址。 相反, 它將發出一個重複的 ip 位址。為了避免這種情況, 我們將使用一個簡單的 powershell 命令來創建 file 伺服器叢集資源並指定 ip 位址

添加 ClusterFileServerRole-存儲"DataKeeper 卷 E"-名稱 FS2-StaticAddress 10.0.0.201

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

創建內部負載等化器

這裡是容錯移轉叢集在 Azure 是不同于傳統的基礎設施。蔚藍網路堆疊不支援 ARP，因此用戶端不能直接連接到群集 IP 位址。相反，用戶端連接到內部負載平衡器和被重定向到活動叢集節點。我們需要做的是創建內部負載平衡器。這都可以通過 Azure 門戶，如下所示。

首先，創建新的負載平衡器
30

如果您的用戶端通過公共互聯網連接, 則可以使用公共負載等化器。但是, 假設您的用戶端駐留在同一個 vnet 中, 我們將創建一個內部負載等化器。重要的是要注意到這裡是虛擬網路是的網路叢集節點駐留相同。此外，您指定的私人 IP 位址將完全用於創建 SQL 群集資源的位址相同。
31

創建內部負載平衡器 (ILB) 後，您將需要對其進行編輯。我們會做的第一件事是添加一個後端池。通過這一過程，你會選擇你的 SQL 群集虛擬機器所在的可用性設置。然而，當你選擇實際的 Vm 將添加到後端池，要確定你不選擇你檔案共用見證。我們不想 SQL 流量重定向到您的檔案共用見證。
32
33

我們將做的下一件事是添加一個探測器。我們將添加該探測器將探測埠 59999。此探測器確定哪個節點是活躍的在我們的群集。
34

然後最後，我們需要一個負載平衡規則，重定向 SMB 流量，重要的是要注意，在下面的截圖是直接伺服器返回啟用了 TCP 埠 445。請確保進行了此更改。

445_ilb

修復檔案伺服器 ip 資源

在配置中的最後一步是在一個叢集節點上運行下面的 PowerShell 腳本。這將允許群集 IP 位址回應 ILB 探頭，並確保群集 IP 位址和 ILB 之間沒有 IP 位址衝突。請注意;您將需要編輯此腳本，以適應您的環境。子網路遮罩設置為 255.255.255.255，這不是一個錯誤，將其保持原樣。這將創建主機的特定路由，以避免與 ILB IP 位址衝突。

# 定義變數
$ClusterNetworkName ="" 
# 群集網路名稱 
(在 Windows 伺服器上使用 ClusterNetwork 2012, 以查找名稱)
$IPResourceName ="" 
# IP 位址資源名稱 
$ILBIP ="" 
# (ILB) 內部負載平衡器的 IP 位址
導入模組 FailoverClusters
# 如果你使用的 Windows Server 2012 或更高版本：
ClusterResource $IPResourceName |設置-ClusterParameter 
-多個 @ {位址 = $ILBIP;ProbePort=59999;SubnetMask = "255.255.255.255";
網路 = $ClusterNetworkName;EnableDhcp=0}
# 如果你使用的 Windows Server 2008 R2 使用該操作： 
#cluster res $IPResourceName/priv enabledhcp=0 位址 = $ILBIP probeport=59999  
subnetmask = 255.255.255.255

創建檔共用

你會發現在容錯移轉叢集管理器中使用檔共用嚮導不能。相反，您將簡單地創建檔共用在 Windows 資源管理器在主動節點上。容錯移轉叢集自動拾取這些股票並放在群集中。

請注意，在此配置中不支援的檔共用的"連續可用性"選項。

結論

你現在應該有正常運作的檔案伺服器容錯移轉叢集。如果您有任何問題, 請在微博上聯繫我 @daveberm。 需要一個資料管理員評估金鑰填寫的表格在 HTTP://us.sios.com/clustersyourway/cta/14-day-trial 和 sios 將發送一個評估金鑰發送給您。

經群集表單的許可複製