,所以我在nginx的
OK設立一個負載均衡的配置爲我們的web應用程序的過程
我將最有可能與粘性會話,以避免會話問題去在負載均衡設置
所以你不會與負載平衡,你正在尋找負載分流?
不要。
處理得當,負載均衡意味着你的服務損失的機會是由節點的數量呈指數降低。假設單個節點的概率爲0.05(即95%的正常運行時間),則丟失兩個節點的概率爲0.05×0.05 = 0.0025(正常運行時間爲99.75%)。 OTOH,如果你按照你的建議拆分負載,那麼你失去可用性的1/N,每當一個節點發生故障,在失去一個節點的概率爲N * 0.05,所以你只得到2個節點的96.75%的可用性。
關於跨多個節點部署,我以前做的方式是: 1)取一個節點,稱之爲節點1,離線 2)應用發佈到node1 3)驗證部署是否成功 4 )再次從節點1把節點1重新聯機 5)取節點2脫機 6)的rsync到節點 7)運行rsync的檢查已經完成 8)把節點2恢復聯機 然後重複5-8每個附加節點
什麼是最好的方法跨所有Web服務器同步這些用戶文件?
上述方法適用於部署 - 對於用戶提交的數據,您需要在提交內容時分發內容。我爲此使用自定義腳本。如果更新發生時某個節點處於脫機狀態,則可在重新使用之前將其重新同步(步驟6 + 7)。
腳本我用發送到請求它從請求的發起者複製節點的請求 - 所以它可以用較短的超時運行,並保證源內容是可用的。
在實現負載平衡方面 - 儘管您可以花費大量資金購買複雜的硬件,但由於許多原因,我還沒有看到任何比循環法更好的工作 - 不僅僅是透明地實現故障轉移在客戶端。
HTH
C.
請注意,對於2臺服務器,您沒有解決裂腦問題的法定人數 - 根據您的數據庫設置,這可能是個問題 – symcbean 2010-06-11 12:26:00