數據庫HA
一般把數據庫層面的HA,和應用層面HA分開考慮
數據庫一般采用數據庫產品提供的HA方案,比如Oracle的RAC,mysql的集群,mongodb的replica set等
無HA的運維
在應用層面不做HA,我們產品有試過,后果十分慘重。無論是應用down了,還是硬件故障,都會造成業務中斷。而且這時候想定位問題就十分糾結,因為保留現場去定位問題比較理想,但是業務一直不恢復客戶又有意見,所以不做HA在生產環境是強烈不推薦的
如果真的沒有HA,那運維也就是人工觀察,發現業務中斷了,就趕快把應用再啟起來。好一點的話,可以做一點自動拉起引用的腳本,實現自動化。但是因為硬件始終只有一台,所以有時候沒有辦法啟起來,只能臨時遷移,業務中斷時間會很長。而且只有一套環境,會發生應用一起來馬上又down掉
冷備
基本上就是准備兩套硬件,一套跑業務,另一套備用。第一套壞了,就把備用的那套啟起來。這樣基本可以抗硬件故障,因為2套硬件同時壞的幾率比較低。也可以把2套硬件放在不同的網段,這樣還可以抗網絡故障
不過也有幾個問題:
1、成本高,硬件成本,以及相應的機櫃場租、電費也跟着上去了
2、第二套啟動需要時間,所以業務還是會中斷一會,如果是對可用性要求很嚴格的服務,冷備的方案基本無法滿足
一般會搭配一些HA管理軟件,業界比較有名的是VERITAS,可以自動改IP,自動啟應用等,不過也比較貴
N:1備份
也是冷備的一種,不過比硬件double的方案能省一些成本。前提是應用是分布式的,那么可以只准備一台額外的機器,把所有分布式組件都部署上,然后哪個組件壞了就啟哪個。如果同時2個組件壞了,那就沒辦法了。啟動過程中的業務中斷也是無法避免的。總的來說,可靠性不如完全的冷備方案,不過能省點成本
熱備負載均衡
這種方案是可用性最高的方案,同時啟動2套應用,在上層加一個負載均衡。如果一套壞了,就把請求發到好的那一台,再嘗試恢復壞的那一套。業務是不中斷的,但是只剩一套應用的那段時間,壓力會突然大很多
前提是應用需要是無狀態的,否則壞了那台機的請求,也沒法轉發到別的機器上。基本上應用只要滿足這個條件,都會選擇熱備,選擇冷備一般是無奈的選擇(無狀態改造短期做不到),因為消耗的硬件是一樣的,熱備的效果明顯要更好HA