《雙機房災備架構搭建實踐》要點：
本文介紹了雙機房災備架構搭建實踐，希望對您有用。如果有疑問，可以聯系我們。

1. 背景

作為運維哥,每逢佳節倍擔心,除了定期到機房貼符拜拜,我們還有什么辦法,保障我們的服務不受硬件故障的困擾呢.

對很多互聯網企業來說,服務長時間停擺,意味著無法估量的損失.接下來我們介紹一個簡單快捷的方法,搭建雙機房災備服務.當業務所在機房發生網絡或者機器故障時,能夠迅速轉移并恢復我們的服務.

2.?雙機房災備架構

不同產品的組件和架構差別很大.下面是基于lnmp的web站點,最基本的雙機房災備服務架構, 僅供參考.

M機房為主機房,S機房為冷備機房,滿足現有業務,并且方便未來擴展的前提下,我們盡可能把架構設計得越簡單越好.華麗而復雜的組件,通常也伴隨著可觀的維護成本.

3.?一步步搭起來

3.1 web程序同步

web程序同步其實就是文件的同步,最簡單的就是定時rsync.不過這個方式太古老,后來我們測試了lsyncd和sersync兩款基于inotify的實時同步工具.最終選定整體性能和穩定性表現更好的lsyncd作為我們的代碼同步工具.

這里簡單貼下適合我們使用場景的測試條件和結果：

• 測試目錄包含8215個子目錄,51587個文件,共 4.3G.
• 源機和目標機均為標配8核16G內存146G硬盤,內網通過1000M交換機互聯.
• 源機服務開啟sshd,lsyncd/sersync.
• 目標機服務開啟sshd,rsync daemon.

測試結果如下：

lsyncd的官網： https://github.com/axkibe/lsyncd

rsync daemon和lsyncd的安裝方法就不再贅述.這里給一個lsyncd同步web程序的參考配置(lua語法)：

settings ?{ ? logfile = “/usr/local/lsyncd/logs/lsyncd.log”, ? statusFile = “/usr/local/lsyncd/logs/lsyncd.status”, ? maxDelays = 100, ? delay = 5, ? exitcodes = {[0] = “ok”, [1] = “again”, [2] = “die”}, ? maxProcesses = 5, ? statusInterval = 5 } — 同步到主機 sync { ? ?default.rsync, ? ?source ? ?= “/opt/web/ser”, ? ?target ? ?= “rsy_user@19.68.111.222::ser_master”, ? — 排除隱藏文件及臨時文件,可以按具體需求修改 ? ?exclude={ “.*”, “*.tmp”, “*.bak”, “*.swp” }, ? ?rsync ? ? = { ? ? ? ?compress = false, ? ? ? ?archive = true, ? ? ? ?verbose = true, ? ? ?— _extra用于手動指定rsync參數,默認建議設置超時,避免rsync進程卡死 ? ? ?_extra = {“–timeout=3600”}, ? ? ? ?password_file = “/usr/local/lsyncd/etc/ser_master.pas” ? ?} }

還可以把web服務端的配置文件(比如nginx vhost配置文件)也加到lsyncd自動同步中,然后定義觸發重新加載配置的命令,這個就交給你自己發揮了.

3.2 mysql數據同步

mysql數據同步,是利用mysql雙向主從來完成的,俗稱mysql主主同步.

兩個機房之間mysql數據同步,要考慮數據傳輸安全性和避免數據沖突.

(1) 數據傳輸安全性

可以參考之前我們的文章《遠程訪問mysql?教你為數據傳輸再加把安全鎖!》. 下面介紹基于ssl進行數據加密同步.

首先使用openssl或者easyrsa配置生成ca、私鑰和證書等.生成好證書后,配置到my.cnf中：

master

[mysqld] server-id=1 ssl ssl-ca=/opt/ssl/cacert.pem ssl-cert=/opt/ssl/srv.crt ssl-key=/opt/ssl/srv.key

slave

[mysqld] server-id=2 ssl ssl-ca=/opt/ssl/cacert.pem ssl-cert=/opt/ssl/srv.crt ssl-key=/opt/ssl/srv.key

(2) 避免數據沖突

mysql采用奇偶分離的配置,表在設計時以自增id為主鍵,一邊寫入id為奇數,一邊寫入為偶數,即使發生兩邊同時寫入的情況,也能保證主鍵不沖突.在前面的配置,繼續增加下面內容：

master

[mysqld] ##自動增量為2,允許最多2臺數據庫實例加入. auto_increment_increment = 2 ##表示偏移值,每個數據庫的偏移值必須唯一,且在1和auto_increment_increment之間. auto_increment_offset ? = 1

slave

[mysqld] auto_increment_increment = 2 auto_increment_offset ? = 2

3.3?cache數據同步

稍有點用戶量的網站,web程序直接讀寫mysql,機器很快會撐不住,這時就少不了緩存技術的使用.

我們選用安裝簡單(rpm方式)、配置管理(web方式)同樣簡單的couchbase,而且完全兼容memcached的使用.

官網下載鏈接：https://www.couchbase.com/downloads

安裝方案參考官網文檔.

安裝完成后,可以看到我們兩個機房兩臺機器在同一個集群里,緩存數據就能夠相互同步了.

異地服務兩個節點：

memcached實例：

3.4 使用dnspod配置D監控

dnspod為我們解析站點域名,同時有一個D監控功能,在我們的雙機房災備中,起到自動進行故障轉移,切換到其他正常運行機器的作用.

4.?結語和新的開始

到這里,我們已經明白搭建雙機房災備服務的關鍵步驟.不過想想這套冷備方案也有一些明顯的缺點,比如

(1) 備機一直空跑,雖然可以拿來做定時數據備份,但是否還是有點浪費資源.

(2) 如果運氣不錯,一年半載都沒切換過備機,如果下次真的需要切換時,是否有信心立即切換過去.

(3) dns切換期間,域名解析大概需要5分鐘生效時間,其實用戶是受影響的,可否把影響再繼續降低些.

要解答這些問題,我們需要更高級的設計架構.冷備讓我們心中有了保障,然而異地雙活才是優雅的遠方.

在異地雙活改造時,一開始想著把冷備激活就可以了.然后發現有些業務必須依賴于兩地數據的強一致性.就算拉個專線,或者提供多線路的切換容災,但因為網絡延時的不穩定,數據的一致性還是沒法絕對保證.甚至有可能被利用來惡意重復刷取站點資源.

在茫然無解的時候,因為一個不完美思想的指導,重新找回了方向.接下來將從這幾個方面進行異地雙活的實現：

(1) 從業務層面,梳理出重點核心業務,優先考慮核心業務的異地雙活.

(2) 再按雙活實現難易程度,把既核心又容易實現的業務排在第一位實現.

(3) 同時一個業務流程下來,中間涉及的小業務模塊也跟著實現異地雙活,保證核心流程在一個地方就能獨立順利完成.

舉個例子,有一個站點包括注冊、登錄、充值3個服務.

從業務量和影響面來分析,我們發現登錄請求占90%以上,然后登錄剛好也是最不依賴于數據實時一致性的業務,用戶注冊完,資料就開始進行同步了,以后再登錄的時候,數據早已經兩地同步完成,就算在兩地快速切換,最多因為緩存的丟失,只是要求用戶重新登錄一次,不會出現登錄失敗的情況.

而注冊或者充值平時業務量小,如果做了雙活,在出現故障,快速進行兩地切換時,可能存在注冊信息沖突不一致,或者兩地重復充值的情況.所以平時我們只要給登錄、充值做好冷備服務就可以了.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/1962.html