將存儲複製與故障轉移群集集成

在本系列的第1部分中，我們介紹了構建多站點群集所需的第一步。我們達到了使用節點和文件共享大多數法定人數的雙節點群集的地步，沒有定義任何資源。

我們繼續吧

在本節中，我們將從停止的地方開始，看看您的複制解決方案如何與故障轉移群集集成。由於每個供應商的複制解決方案將以不同方式實施，因此很難有一個文檔來描述它們。需要記住的重要一點是，您希望購買與故障轉移群集集成並由Microsoft認證的複制解決方案。您的選擇基本上是基於陣列，基於設備或基於主機的複制解決方案。EMC同時提供基於設備和基於陣列的複制解決方案，似乎在這兩方面都做得很好。EMC的John Toner維護著一個專門針對地理位置分散的群集的博客，如果您要採用EMC路線，我相信他可以引導您朝著正確的方向前進。所有的主要供應商都有解決方案，您只需要聯繫他們獲取詳細信息。

SIOS DataKeeper

在本次演示中，我將使用我公司SteelEye Technology的基於主機的複制解決方案SteelEye DataKeeper Cluster Edition。這是如此簡單，以至於我不想寫一篇長篇文章，而只是記錄步驟，並在視頻中與您分享。基於主機的複制的一個優點是可以利用現有存儲，無論是本地連接的磁盤，iSCSI還是昂貴的SAN。基於主機的複制可以跨任何存儲設備進行複制。

以下是您將在視頻中看到的內容摘要。

• 啟動SteelEye DataKeeper MMC管理單元
  • 創建一個新的DataKeeper作業，定義鏡像端點，網絡，壓縮等
• 啟動故障轉移群集MMC管理單元
  • 創建一個Hyper-V資源
  • 添加一個DataKeeper卷資源
  • 編輯DataKeeper Volume資源的屬性，將其與先前創建的鏡像相關聯
  • 使虛擬機配置依賴於新的DataKeeper卷資源

而已！你現在完成了。坐下來享受新的Hyper-V多站點群集。

點擊觀看視頻

在本系列的第3部分中，我們將討論Windows Server 2008 R2上的SQL 2008多站點群集。還有幾個步驟，一些技巧和訣竅，你一定要知道，所以請確保你檢查了解所有的細節。在此期間，如果您需要幫助，請給我留言或通過SIOS與我聯繫，我很樂意幫助您。

 介紹

歡迎閱讀我的系列文章“逐步：在Windows Server 2008 R2上配置雙節點多站點群集”的第1部分。在我們深入細節之前，讓我們花點時間來討論一個多站點集群是什麼以及為什麼要實現這個集群。微軟有一個偉大的網頁和白皮書，你會想要下載所有的細節，所以我不會在這裡重複一切。但基本上，多站點集群是一個災難恢復解決方案，而高可用性解決方案則集成在一個中。多站點群集為您的關鍵應用程序提供了最高的恢復點目標（RTO）和恢復時間目標（RTO）。隨著Windows Server 2008故障轉移群集的引入，通過引入交叉子網故障轉移和支持高延遲網絡通信，多站點群集變得更加可行。

我提到“跨子網故障轉移”是Windows Server 2008故障轉移群集的一個很棒的新功能，它是一個很棒的新功能。但是，SQL Server尚未支持此功能，這意味著您仍然需要在跨多個站點的SQL Server多站點群集中跨越子網。從Tech-Ed 2009開始，SQL Server團隊就報告說他們計劃支持這個功能，但是他們說在SQL Server 2008 R2發布後的某個時候。在可預見的未來，您將被困在一個SQL Server多站點群集的跨站點跨越您的子網。還有一些與網絡有關的其他問題需要考慮，例如冗餘通信路徑，帶寬和文件共享見證安置。

網絡考慮

所有Microsoft故障轉移群集都必須具有冗餘的網絡通信路徑。這可確保任何一個通信路徑的故障不會導致錯誤的故障轉移，並確保您的群集保持高可用性。多站點群集也有這個要求，所以你需要考慮到你的網絡規劃。通常有兩件事情需要在節點之間傳輸：複製流量和群集心跳。除此之外，您還需要考慮客戶端連接和集群管理活動。你將要確定，無論你有什麼網絡，你都不會壓倒網絡，否則你將會有不可靠的行為。您的複制流量很可能需要最大的帶寬;您將需要與您的複制供應商合作以確定需要多少帶寬。

通過冗餘的通信路徑，您需要考慮的最後一件事情就是仲裁模式。對於雙節點多站點群集配置，Microsoft推薦的配置是節點和文件共享多數法定人數。有關法定類型的詳細說明，請參閱本文。

與節點和文件共享多數法定人數混淆的最常見原因是文件共享見證的放置。我應該在哪裡放置承載文件共享的服務器？讓我們看看選項。

方案1 – 將文件分享到主要網站。

這當然是災難恢復的有效選擇，但不是高可用性。如果整個站點發生故障（包括主節點和文件共享見證），則輔助站點中的輔助節點將不會自動啟動，您需要手動強制仲裁。這是因為它將是集群中唯一剩下的選票。三分之一不佔多數！現在，如果您可以在發生災難時採取手動步驟進行恢復，那麼此配置對您而言可能是正常的。

方案2 – 將文件分享到第二網站。

這不是一個好主意。雖然它可以解決完全丟失網站時自動恢復的問題，但卻可能導致錯誤的故障轉移。考慮這個…如果你的輔助網站出現故障，會發生什麼？在這種情況下，您的主服務器（Node1）也將脫機，因為現在只有主站點中的單個節點，並且不再具有節點多數。由於涉及的風險太大，我看不出有什麼好的理由來實施這種配置。

方案3 – 把文件放在第三個地理位置

這是首選配置，因為它允許在完全丟失站點的情況下自動進行故障切換，並消除輔助站點導致主節點脫機的任何故障的可能性。通過讓第三方站點託管文件共享見證，您已經消除了任何一個站點作為單點故障，所以現在集群將按照您的預期運行，並且在站點丟失的情況下可以自動進行故障切換。識別第三個地理位置對於一些公司來說可能是一個挑戰，但隨著Amazon EC2和GoGrid等基於雲的效用計算的出現，所有公司都可以將文件共享見證放在雲中，並具有所需的恢復能力為有效的多站點群集。事實上，您可能會將雲本身視為您的輔助數據中心，並在發生災難時將其轉移到雲端。我認為基於雲計算和災難恢復配置的可能性是非常誘人的，事實上，我打算在不久的將來完成一個完整的博客文章。

配置集群

現在我們已經掌握了基礎知識，現在讓我們開始使用集群的實際配置。您需要將故障轉移群集功能添加到群集的兩個節點。為了簡單起見，我已經調用了我的節點PRIMARY和SECONDARY。這通過添加功能嚮導非常容易地完成，如下所示。

接下來，您將需要查看您的網絡連接。如果您重命名每個服務器上的連接以反映它們代表的網絡，那麼最好。這將使以後更容易記住。

您還需要進入每個服務器的網絡連接的高級設置（點擊Alt以查看高級設置菜單），並確保公共網絡在列表中位於第一位。

您的專用網絡應只包含一個IP地址和子網掩碼。不應該定義默認網關或DNS服務器。您的節點需要能夠通過此網絡進行通信，因此請確保服務器可以通過此網絡進行通信;如有必要添加靜態路由。

配置完網絡之後，即可開始構建群集。第一步是“驗證配置”。打開故障轉移群集管理器並單擊驗證配置。

“驗證嚮導”將啟動並顯示如下所示的第一個屏幕。在群集中添加兩台服務器，然後單擊下一步繼續。

多站點群集不需要通過存儲驗證（請參閱Microsoft文章）。Toskip存儲驗證過程中，單擊“只運行我選擇的測試”，然後單擊繼續。

在測試選擇屏幕中，取消選擇“存儲”，然後單擊“下一步”

您將看到以下確認屏幕。單擊下一步繼續。

如果你所做的一切正確，你應該看到一個如下所示的摘要頁面。請注意，黃色感嘆號表示並非所有測試都已運行。這是在多站點群集中預期的，因為存儲測試被跳過了。只要其他一切都檢查好，你可以繼續。如果報告顯示有任何其他錯誤，請修復問題，重新運行測試並繼續。

您現在已經準備好創建您的群集。在故障轉移群集管理器中，單擊創建群集。

下一步詢問您是否要驗證您的群集。既然你已經這樣做了，你可以跳過這一步。請注意，如果安裝SQL，稍後會引起一些問題，因為這需要在繼續之前通過驗證。當我們到達這一點時，我將向您展示如何通過SQL Server安裝程序中的命令行選項旁路此檢查。現在，選擇否和下一步。

下一步是您必須為此群集和IP創建一個名稱來管理此群集。這將是您將用於管理群集的名稱，而不是稍後將創建的SQL群集資源的名稱。輸入唯一的名稱和IP地址，然後單擊下一步。

注意：這也是需要文件共享見證權限的計算機名稱，如本文後面所述。

確認您的選擇並單擊下一步。

恭喜，如果你已經做好了所有的事情，你會看到下面的總結頁面。注意黃色感嘆號;顯然有些不完美。點擊查看報告，找出問題可能是什麼。

如果你查看報告，你應該看到幾行看起來像這樣的。

別煩惱這是在多站點集群中預期的。記得我們之前說過，我們將實施一個節點和文件共享多數法定人數。我們將從當前節點多數集群（在兩節點集群中不是一個好主意）中將法定類型更改為節點和文件共享多數法定人數。

實現一個節點和文件共享多個定量

首先，我們需要確定將持有我們的文件共享見證的服務器。請記住，正如我們前面所討論的，這個文件共享見證應該位於第三個位置，群集的兩個節點都可以訪問這個位置。一旦您確定了服務器，就像平常共享一個文件夾一樣共享一個文件夾。就我而言，我在名為DEMODC的服務器上創建一個名為MYCLUSTER的共享。

要記住這個共享的關鍵是您必須授予共享級別和NTFS級別權限的集群計算機名稱對共享的讀/寫權限。如果你回想一下圖13，我創建了我的集群並給它起了名字“MYCLUSTER”。您將需要確保提供群集計算機帳戶的讀/寫權限，如以下屏幕截圖所示。

現在使用共享文件夾並分配了適當的權限，即可準備更改您的仲裁類型。在故障轉移群集管理器中，右鍵單擊群集，選擇更多操作並配置群集仲裁設置。

在下一個屏幕上選擇節點和文件共享多數，然後單擊下一步。

在此屏幕中，輸入您先前創建的文件共享的路徑，然後單擊下一步。

確認信息是否正確，然後單擊下一步。

假設你做的一切正確，你應該看到下面的總結頁面。

現在，當您查看群集時，Quorum配置應該如下所示說“節點和文件共享多數”。

我列出的步驟直到適用於任何多站點群集，無論是SQL，Exchange，文件服務器還是其他類型的故障轉移群集。創建多站點群集的下一步是將存儲和復制解決方案集成到故障轉移群集中。這一步將根據您的複制解決方案而有所不同，所以您確實需要與復制供應商保持密切聯繫才能做到正確。在本系列的第2部分中，我將演示SteelEye DataKeeper Cluster Edition如何與Windows Server故障轉移群集集成，以便您了解其中一種複制供應商的解決方案是如何工作的。

本系列的其他部分將詳細介紹如何在多站點群集中安裝SQL，文件服務器和Hyper-V。我還會在三節點或更多節點的多節點集群上發表一個注意事項。

隨著Windows Server 2008 R2的發布，其中一項增強功能是改善了動態VHD文件的性能。在R2之前，由於元數據緩存有限，寫入動態擴展VHD文件的速度可能比寫入固定大小的VHD文件慢3倍。總的來說，微軟聲稱動態VHD文件與固定大小的VHD文件的性能幾乎是相同的。配置Hyper-V虛擬機時，通過磁盤是另一種選擇。根據我的研究結果，傳遞磁盤的性能比VHD文件略好。但是，如果使用pass-through磁盤，則會失去VHD文件的所有優點，例如便攜性，快照和精簡配置。考慮到這些折衷，如果您需要大於2TB的磁盤，或者如果您的應用程序受I / O限制，並且您真的可以從另一個.1毫秒刮掉的情況下使用傳遞磁盤，則應該只考慮使用傳遞磁盤你的平均響應時間。我認為，不要用微軟的話來說，我會把這些不同類型的磁盤作為自己的測試。我設置了在Windows Server 2008 R2之上運行的Hyper-V Windows Server 2008 R2虛擬機。對於我的虛擬機管理程序，我使用連接到Dell AX150 SAN的Dell PowerEdge 1950服務器，並分割出三個10 GB的LUN用於測試。在Hyper-V管理器中，我添加了三個新磁盤，一個直通，一個動態VHD和一個固定大小的VHD。然後，我使用IOMeter來測試磁盤的性能。測試參數和原始數據可以在這個CSV文件中找到。下面的圖表總結了我的結果。正如您所看到的，在極限（最大值/最小值）上，傳遞磁盤在大多數情況下都會勝出。但是，平均來說，三種不同類型的磁盤的性能幾乎沒有區別。

精簡配置的好處，意思是構建一個VHD文件或多個VHD文件，其總大小大於可用磁盤空間，以及VHD文件的可移植性，這使得動態擴展VHD文件成為大多數Windows Server 2008 R2虛擬機的顯而易見的選擇。總之，我強烈建議在Windows Server 2008 R2上使用動態擴展的VHD文件進行下一個Hyper-V部署。轉載https://clusteringformeremortals.com/2009/09/25/hyper-v-pass-through-disk-performance-vs-fixed-size-vhd-files-and-dynamic-vhd-files-in- Windows的服務器-2008-R2 /