我們目前有一個具有兩個節點的故障轉移sql羣集。對於我們確定爲關鍵業務的新大型項目，我們的開發團隊正在請求一個新的2節點故障轉移sql羣集。SQL羣集或VM映像
我們的服務器部門已經回覆說他們不想爲我們實現一個集羣，而是僱傭了多個虛擬機，每個虛擬機都安裝了SQL服務器，指向同一個磁盤，所以如果一個失敗了，他們要麼移動它到一個新的主機，或另一個鏡像，因爲它指向同一個磁盤，數據將保持不變。
我沒有SQL服務器專家，才明白一個基本級別的集羣，但東西告訴我，這個VM「觀念」，他們想出了不完全的企業解決方案。這聽起來很漂亮Micky Mouse給我。我在這裏吃午飯嗎？我可以用什麼樣的論據來支持我的觀點？
爲了確定是否與虛擬或集羣解決方案需要進行詳細的容錯能力的要求去。該解決方案是否需要適應硬件故障，存儲故障或實例故障？如果服務器出現故障，恢復過程如何簡單/複雜？計劃的硬件資源利用率是多少？
虛擬和集羣解決方案都將提供硬件故障容錯功能。 SAN存儲可能會覆蓋存儲容差。
應用程序是否需要在出現故障後立即啓動？如果在半夜出現故障，需要進行什麼級別的交互才能使應用程序備份。它應該是自動還是手動？如果它需要是自動的，這應該被嵌入到技術中還是被編碼的東西？
根據對上述問題的回答，虛擬或羣集解決方案可能適合高可用性需求。我建議您佈置需求，並且經常會指出適合的解決方案。
對不起，答案主要是問題，但他們會指出適當的解決方案。
我同意你的觀點 - 如果它們指向同一個磁盤，如果（當）該磁盤發生故障，會發生什麼？
如果他們是在談論一個SAN雖然，而不是實際的磁盤，然後如果你假設SAN是正確的容錯它可能是一個確定的解決方案。
這完全是關於錢！如果你有一臺擁有大量虛擬機的ESX服務器，那麼虛擬機通常也位於一個有多個羣集節點的SAN上。因此，如果您有一個具有SAN後端的4節點VM集羣，那麼您可能會在那裏安裝40個VM。你還在容錯等
，但通過SQL Server的虛擬化已經走了，它是緩慢的，純粹而簡單。我們沒有獲得IOPS或足夠的內存和CPU。如果你需要體面的表現，比如說，對於高容量壓力測試，那就去集羣。請記住，您需要2臺服務器，SAN存儲以及SQL/Windows許可，因此您需要付出艱苦的努力。 :-(
我想我對這個問題非常感興趣作爲一名DBA，我喜歡我的服務器來執行我們的測試服務器仍然需要這個，但是我們的開發服務器通常不會太忙。 ？。性能（當然，誰也說不）
其實這是很常見的，可行的虛擬機的羣集解決方案便宜部署更，SQL Server實際上是正式supported on Hyper-V：
SQL服務器2008在 虛擬機環境中運行 支持Windows Server中的Hyper-V角色 2008 R2和Windows Server 2008 標準版，企業版和數據中心版 版本。
唯一的問題是性能。很顯然，基於Hyper-V的部署將比裸機上的部署慢，但我發現許多網站在虛擬機上運行得很好。
這是一個SAN磁盤，但是因爲啓動一個虛擬機需要有人來完成它，並且需要一點時間（儘管不是很多），並且集羣自動進行故障切換，這是一個更好的解決方案。 – Jeremy 2009-08-20 17:10:04