伺服器鏡像策略題 SQL Server複製、MySQL複製、文件複製等
我在一家公司工作了一段時間，是一名應用程序開發人員。企業希望將其現有的 Windows 伺服器（伺服器 A）鏡像到新的伺服器（伺服器 B），主要目的是在任一伺服器不可用的情況下提供冗餘。硬體負載平衡器將管理到任一伺服器的流量方向。旨在在任何給定時間只有一台伺服器正在接收流量。在每台伺服器上，執行所有應用程序所需的所有資源都在一台機器上。
需要在兩台機器上進行雙向同步的數據是：
- 幾個 MySQL 數據庫。
- 兩個 SQL Server 數據庫。
- .NET 應用程序和經典 ASP 網站的原始碼。
- 電子郵件伺服器。文件。
- 其他應用程序、備份常式等。
- 伺服器設置（如果可能）。
託管公司在船上，他們有負載平衡和複製的想法，但我被要求管理這個。
我對此有一些普遍的擔憂，即：
- 這不是我在流程方面工作過的最結構化的公司（公司很少有原始碼控制經驗，可以免費訪問配置定期更改的實時伺服器，沒有文件等）。這可能需要比目前更多的技術紀律。
- 沒有一個應用程序是集群感知的。大多數數據庫操作都是非事務性的。
我的具體問題是：
- 兩台伺服器故障轉移配置是我在這裡描述的常見地方嗎？有什麼優點/缺點嗎？
- 雙向數據複製的潛在陷阱是什麼，其中兩個數據庫伺服器都需要同時是發布者和訂閱者？如何審計有關數據並發的風險？
- 他們是否有任何用於複製伺服器軟體安裝/設置的工具？（成像可能是不可能的，因為兩台伺服器的硬體和規格不同）。我想保持作業系統設置/數據庫模式/原始碼/版本控制伺服器/電子郵件伺服器等可能是一個很大的成本？
- 考慮到我前面提到的擔憂，我是否應該建議我們放慢速度，直到我們能夠帶來更好的系統管理並在繼續之前解決任何潛在的應用程序弱點，或者你認為一旦第二台伺服器，必要性將成為這些變化的最佳驅動力正在玩嗎？
對不起，如果這有點漫無邊際。歡迎任何有關如何管理此問題的見解或“您應該將其留給知道他們在做什麼的人”的評論！
這個問題太大了；你可能不會得到具體的答案。
為了實現“多主機”複製，即兩台伺服器都響應，您需要分別為每個協議（SQL、SMB、HTTP 等）解決該問題。更簡單的方法是在主動-被動場景中一次僅使用一台伺服器，但您仍在談論一種高度複雜的解決方案，以確保所有這些應用程序和協議的數據失去為零。
最簡單但不太可能最好的解決方案是讓它成為故障轉移主機集群上的虛擬機，但如果您有計劃外的故障轉移，我相信您會在虛擬機重新啟動時失去記憶體中的內容。
Windows 文件服務、IIS 和 SQL Server 都有不同級別的冗餘，但每一個都是獨一無二的，需要根據您的特定應用需求進行評估。
如果是我，我會根據正常執行時間和數據的重要性做出這個決定。如果你能忍受虛擬機集群主動-被動的場景，那就去做吧。我認為試圖讓它成為一個多主機，在一個盒子上擁有所有這些不同的技術是一場噩夢。我知道沒有人這樣做。他們/我們有 SQL 伺服器做鏡像，電子郵件在不同的伺服器上做自己的事情，等等。你添加的每個應用程序都是它自己的高可用性“解決方案”（對我來說）。