SIOS SANless clusters High-availability Machine Learning monitoring
請查看有關如何使用Windows Server故障轉移群集和SteelEye DataKeeper Cluster Edition在不久的將來跨數據中心和/或無共享存儲配置DHCP的分步文章。在此期間，請查看此視頻，演示使用複制的DHCP數據庫而不是群集中的共享磁盤的DHCP群集。
經https://clusteringformeremortals.com/2009/11/23/dhcp-cluster-without-shared-storage-andor-across-data-centers/許可轉載
最近有很多新聞，關於在長途數據中心執行虛擬機實時遷移，這預示著VMware對數據中心內vMotion的有限支持，或者我所見過的“遠程vMotion”。解決方案的細節可以在思科的網站上找到。雖然我認為這太好了，但我想提醒大家的是，Microsoft Hyper-V今天具有相同的功能，比VMware的遠程vMotion要求和限制要少得多。
在VMware有VMwareHA，vMotion和Site Recovery Manager（SRM）來處理虛擬機可用性的情況下，Microsoft提供了與Windows Server Failover Clustering相同的功能，實際上在某些情況下超出了VMware可以提供的虛擬機可用性我在之前的文章中描述過。
我今天想要關注的是微軟提供“長途vMotion”的競爭力。要在Hyper-V中實現相同的功能，您只需使用Windows Server故障轉移群集和您最喜愛的基於主機或存儲的複制解決方案部署多站點Hyper-V群集，該解決方案經過認證可在Windows Server 2008多站點群集中運行。通過這樣做，您可以使用現有的網絡基礎架構和現有的存儲基礎架構來跨數據中心進行實時遷移。至於要求，它們實際上與任何多站點群集相同，除了我建議您跨越子網以避免在將虛擬機移動到新子網時發生的客戶端重新連接問題，因為客戶端可以緩存到舊的TTL到期前的IP地址。
可以在此處看到使用Windows Server 2008 R2 Hyper-V和SteelEye DataKeeper Cluster Edition跨數據中心進行實時遷移的演示視頻。
經https://clusteringformeremortals.com/2009/09/17/hyper-v-live-migration-across-data-centers/許可轉載
構建高可用性群集配置時，您的應用程序可用性僅與其最薄弱的鏈接一樣好。這意味著，如果您購買了具有冗餘一切（CPU，風扇，電源，RAID，RAM等）和具有多路徑連接的超豪華SAN的優質服務器。與多個SAN交換機配合使用，並將您的應用程序與您喜歡的群集軟件集中在一起。 你可能有一個非常可靠的應用程序 – 對吧？嗯，不一定。服務器是否插入同一台UPS？它們是否在同一個網絡交換機上？它們是否由同一個交流單元冷卻？他們在同一棟樓裡嗎？您的SAN真的可靠嗎？其中任何一個問題都是高可用性群集配置中的單點故障。
當然，你必須知道什麼時候“足夠好”是“足夠好”的。你的預算和你的SLA將有助於決定什麼是好的。但是，我擔心人們可能正在掠過的一個領域是存儲領域。隨著廉價或免費的iSCSI目標軟件解決方案的出現，我看到一些人建議你只是將一些iSCSI目標軟件放在備用服務器上，並且即時共享存儲。
請注意，我不是在談論內置故障轉移技術和/或其他可用性功能的OEM iSCSI解決方案;甚至是FalconStor等存儲虛擬化解決方案。我正在談論那些運行Windows Server 2008的服務器，他裝載了存儲並希望將其變成iSCSI目標。這在實驗室很棒。但如果你認真對待醫管局，你應該再考慮一下。即使是微軟也只提供他們的iSCSI目標軟件給合格的OEM製造商，他們在提供企業級存儲陣列上經驗豐富。
首先，這是Windows。 沒有一些經過強化的操作系統只能用於存儲。這將需要維護，安全更新，硬件修復等。它基本上與您要保護的應用程序服務器具有相同的可靠性。集群應用程序服務器是否有意義。然而，使用相同類別的服務器和操作系統來託管您的存儲？您基本上已將單點故障從應用程序服務器移開並將其移至存儲服務器。就我而言，這不是一個聰明的舉動。
某些企業級iSCSI目標軟件包括同步和/或異步複製軟件和快照功能。此功能肯定有助於恢復點目標（RPO）。雖然它不會幫助您恢復時間目標（RTO），除非故障轉移是自動且無縫到您的群集軟件。假設主iSCSI存儲陣列在半夜失敗。誰將在那裡激活複製副本？在您意識到存在問題之前，您可能已經停機了很長時間。再次，這可能是“足夠好”;你只需要知道你正在註冊的東西。這是您正在尋找的高可用性群集配置嗎？
為提高iSCSI目標服務器的可靠性，您可以做的一件事是使用SteelEye DataKeeper Cluster Edition等複制產品來消除單點故障。讓我來說明一下。
如果我們採用上面顯示的相同配置並使用SteelEye DataKeeper Cluster Edition添加熱備用iSCSI目標來執行複制和自動故障轉移，那麼您剛剛為iSCSI目標解決方案提供了全新的可用性級別。這個解決方案看起來非常像這樣。
使用SteelEye DataKeeper Cluster Edition的解決方案與某些iSCSI目標供應商提供的複制解決方案的主要區別在於與WSFC的集成。要問你的iSCSI解決方案供應商的問題是這樣的…
如果我拔下活動的iSCSI目標服務器上的電源線，會發生什麼情況？
如果恢復過程是手動過程，則不是真正的HA解決方案。但是如果它是自動的並且與WSFC完全集成呢？然後，您可以獲得更高級別的可用性，並將iSCSI陣列作為單點故障排除在外。
與我們聊天也可以實現高可用性群集配置
經Clusteringformortals許可轉載。
我很高興地宣布，Windows IT Pro授予SteelEye DataKeeper Cluster Edition兩個類別的最佳高可用性和災難恢復產品;社區選擇金獎和編輯最佳銀獎。
作為SteelEye DataKeeper團隊的一員，我感到非常自豪，我很欣賞在社區選擇獎中為我們投票的所有Windows IT Pro社區！
轉載https://clusteringformeremortals.com/2009/11/20/steeleye-datakeeper-cluster-edition-wins-windows-it-pro-best-high-availabilitydisaster-recovery-awards/的許可
我被問過這個問題不止幾次，所以我想我會在我的第一篇博客文章中回答這個問題。基本答案是肯定的，在多站點集群中使用異步複製時，可能會導致意外失敗的數據丟失。在一個理想的世界裡，每個公司都會有一個到他們災難恢復站點的暗光纖連接，並使用與他們的多站點集群同步複製，消除數據丟失的可能性。但是，現實情況是，在許多情況下，到災難恢復站點的廣域網連接有太多的延遲來支持同步複製。在這種情況下，異步複製是一個很好的選擇。選擇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/的許可