1.一、數據鏡像軟件DRBD介紹
分佈式塊設備複製(Distributed Relicated Block Deivce,DRBD),是一種基於軟件、基於網絡的塊複製存儲解決方案,主要用於對服務器之間的磁盤、分區、邏輯卷等進行數據鏡像,當用戶將數據寫入本地磁盤時,還會將數據發送到網絡中另外一臺主機的磁盤上,這樣的本地主機(主節點)與遠程主機(備節點)的數據就能夠保證明時同步,當本地主機出現問題,遠程主機上還保留着一份相同的數據,能夠繼續使用,保證了數據的安全
node
1.二、DRBD的基本功能
DRBD的核心功能就是數據的鏡像,其實現方式是經過網絡來鏡像整個磁盤設備或者磁盤分區,將一個節點的數據經過網絡實時地傳送到另一個遠程節點,保證兩個節點間數據的一致性,這有點相似於一個網絡RAID1的功能,對於DRBD數據鏡像來講,它具備以下特色:
實時性: 當應用對磁盤數據有修改操做時,數據複製當即發生。
透明性: 應用程序的數據存儲在鏡像設備上是透明和獨立的。數據能夠存儲在基於網絡不一樣服務器上。
同步鏡像: 當本地應用申請寫操做時,同時也在遠程主機上開始進行寫操做
異步鏡像: 當本地寫操做已經完成時,纔開始對遠程主機上進行寫操做。
linux
1.三、DBRD的構成
DRBD是Linux內存存儲層中的一個分佈式存儲系統,具體來講兩部分構成,
(1) 一部分:內核模板,主要用於虛擬一個塊設備;
(2) 一部分:是用戶控件管理程序,主要用於和DRBD內核模塊通訊,以管理DRBD資源,
在DRBD中,資源主要包含DRBD設備,磁盤配置,網絡配置等。
一個DRBD系統有兩個以上的節點構成,分爲主節點和備節點兩個角色,在主節點上,能夠對DRBD設備進行不受限制的讀寫操做,能夠用初始化、建立、掛在文件系統,在備節點上,DRBD設備沒法掛載,只能用來接收主節點發送過來的數據,也就是說備節點不能用於讀寫訪問,這樣的目的是保證數據緩衝區的一致性。
主用節點和備用節點不是一成不變的。能夠經過手工的方式改變節點的角色,備用節點能夠升級爲主節點,主節點也降級爲備節點。
DRBD設備在整個DRBD系統中位於物理塊設備上,文件系統之下,在文件系統和物理磁盤之間造成了一箇中間層,當用戶在主節點的文件系統中寫入數據時,數據被正式寫入磁盤前會被DRBD系統截獲,同時,DRBD在捕捉到有磁盤寫入的操做時,就會通知用戶控件管理程序把這些數據複製一份。寫入遠程主機的DRBD鏡像,而後存入DRBD鏡像全部映射的遠程主機磁盤,
DRBD負責接收數據,把數據寫到本地磁盤,而後發送給另外一臺主機,另外一臺主機再將數據存到本身的磁盤中,目前,DRBD每次只容許對一個節點進行讀寫訪問,這對於一般的故障切換高可用性集羣來說已經足夠用了,
算法
1.四、DRBD與集羣的關係
DRBD由兩個或者兩個以上節點構成,與HA集羣相似,也有主節點和備節點之分,於是常常用於高可用集羣和負載集羣系統中做,因爲DRBD系統是在IP網絡運行,因此,在集羣中使用DRBD做爲共享存儲設備,不須要任何硬件投資,能夠節約不少成本,由於在價格上IP網絡要比專用的存儲網絡更加經濟。另外DRBD也能夠用於數據備份、數據容災等方面。
vim
1.五、DRBD的主要特性
DRBD系統在實現數據鏡像方面有不少有用的特性,咱們能夠根據本身的需求和應用環境,選擇合適本身的功能特性。下面一次介紹DRBD幾個很是重要的特性:
(1)、單主模式:
這是使用最頻繁的一種模式,主要用於在高可用集羣的數據存儲方面,解決集中數據共享的問題,在這種模式下,集羣中只有一個主節點能夠對數據進行讀寫操做,能夠用在這種模式下的文件系統有EXT3 EXT4 XFS等。
(2)、雙主模式:
這種模式只能在DRBD8.0之後的版本使用,主要用於負載均衡集中,解決數據共享和一致性問題,在這種模式下,集羣中存在兩個主節點,因爲兩個主節點都有可能對數據進行併發操做的讀寫操做,所以單一的文件系統就沒法知足需求了,所以須要共享的集羣文件系統來解決併發讀寫問題,經常使用在這種模式下的文件系統有GFS,OCFS2等,經過集羣文件系統的分佈式鎖機制就能夠解決集羣中兩個主節點同時操做數據的問題。
(3)、複製模式
DRBD提供了三種不一樣的複製方式,分別是;
協議A: 只要本地磁盤寫入已經完成,數據包已經在發送隊列中,則認爲一個寫操做過程已經完成,
這種方式在遠程節點故障或者網絡故障時,可能形成數據丟失,由於要寫入到遠程節點的數據可能還在發送隊列中。
協議B:只要本地磁盤寫入已經完成,而且數據包已經到達遠程節點,則認爲一個寫操做過程已經完成。
這種方式在遠程節點發生故障時,肯能形成數據丟失。
協議C: 只有本地和遠程節點的磁盤已經都確認了
寫操做完成,則認爲一個寫操做過程已經完成,
這種方式沒有任何數據丟失,就目前而已應用最多,最普遍的就是協議C,旦在此方式下磁盤的I/O的吞吐量依賴於網絡帶寬,建議在網絡帶寬比較好的狀況下使用這種方式。
protocol C; #使用drbd的同步協議
(4)、傳輸的完整性校驗
這個特性在DRBD8.20及之後版本中可使用,DRBD使用MD五、SHA-1,或者CRC 32C等加密算法對信息進行終端到終端的完整性驗證,利用這個特性,DRBD對每個複製到遠程節點數據都生成信息摘要,同時,遠程節點也採用一樣的方式對複製的數據塊進行完成性驗證,若是驗證信息不對,就請求主節點從新發送,經過這種方式保證鏡像數據的完整性和一致性。
(5)、腦裂通知和自動修復。
因爲集羣節點之間的網絡鏈接臨時故障、集羣軟件管理干預或者人爲錯誤,致使DRBD兩個節點都切換爲主節點而斷開鏈接,這就是DRBD的腦裂問題,發生腦裂意味着數據不能同步從主節點複製到備用節點,這樣致使DRBD兩個節點的數據不一致,而且沒法合併。
在DRBD8.0以及更高的版本,實現了腦裂自動修復功能,在DRBD8.2.1以後。又實現了腦裂通知特性,在出現腦裂後,通常建議經過手工方式修復腦裂問題,
安全
2.一、環境描述
系統版本:redhat x64(內核2.6.32)
DRBD版本: DRBD-8.4.3
node1: 192.168.1.138(主機名:master)
node2: 192.168.1.139 (主機名:slave)
(node1)爲僅主節點配置 Primary
(node2)爲僅從節點配置Secondary
(node1,node2)爲主從節點共同配置
服務器
2.二、服務器時間同步以及關閉防火牆Selinux
#/etc/init.d/iptables stop 關閉防火牆
#setenforce 0 關閉Selinux
# cat /etc/selinux/config
SELINUX=disabled
#ntpdate -u asia.pool.ntp.org 真實環境這樣同步
# date –s 「2014-09-24 15:55:33」 測試時間。臨時能夠這樣同步,兩臺機器都迅速執行此命令
網絡
2.三、修改主機名
#:vim /etc/sysconfig/network 主節點 138
HOSTNAME=master
#:vim /etc/sysconfig/network 從節點139
HOSTNAME=slave
若是使用虛擬機器作測試。尚未增長硬盤的的話。請關閉虛擬機器。
開始增長一塊硬盤,若是原有的虛擬機硬盤還有空間的話。拿出一塊空間,作一個分區。也行。
併發
2.四、全部節點增長硬盤
在主節點138 和從節點139上。劃分增長的/dev/sdb 硬盤。進行分區
# fdisk /dev/sdb
分一個叫作/dev/sdb1分區出來。就能夠。注意千萬不要格式化它。劃分出來就好了。不須要格式化。
負載均衡
2.五、全部的節點安裝
在主節點138和從節點139上同時安裝
# wget http://oss.linbit.com/drbd/8.4/drbd-8.4.3.tar.gz
# tar zxvf drbd-8.4.3.tar.gz
# cd drbd-8.4.3
# ./configure --prefix=/usr/local/drbd --with-km --with-heartbeat km表明開啓內核模塊
./configure命令中添加--with-heartbeat,安裝完成後會在/usr/local/drbd/etc/ha.d /resource.d生成drbddisk和drbdupper文件,把這兩個文件複製到/usr/local/heartbeat/etc/ha.d /resource.d目錄,命令cp -R /usr/local/drbd/etc/ha.d/resource.d/* /etc/ha.d/resource.d。
# make KDIR=/usr/src/kernels/2.6.32-279.el6.x86_64/
# make install
# mkdir -p /usr/local/drbd/var/run/drbd
# cp /usr/local/drbd/etc/rc.d/init.d/drbd /etc/rc.d/init.d
# chkconfig --add drbd
# chkconfig drbd on
加載DRBD模塊:
# modprobe drbd
查看DRBD模塊是否加載到內核:
# lsmod |grep drbd
異步
在主節點138和從節點139 配置文件保持一致。
# /usr/local/drbd/etc/drbd.conf
drbd.conf 包含了2個類型的文件。爲了方便起見全局配置和資源配置分開了。global_common.conf爲固定全局配置文件,*.res 能夠包含多個,跟Nginx虛擬機器同樣。*.res 帶包含了全部的資源文件。
(1) 修改全局配置文件:
global {
usage-count yes; #是否參加drbd的使用者統計,默認此選項爲yes
# minor-count dialog-refresh disable-ip-verification
}
common {
protocol C; #使用drbd的同步協議
handlers {
# These are EXAMPLE handlers only.
# They may have severe implications,
# like hard resetting the node under certain circumstances.
# Be careful when chosing your poison.
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f"; #默認是註釋的開啓來
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f"; #默認是註釋的開啓來
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f"; #默認是註釋的開啓來
# fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
# split-brain "/usr/lib/drbd/notify-split-brain.sh root";
# out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
# before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
# after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
}
startup {
# wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb
}
options {
# cpu-mask on-no-data-accessible
}
disk {
on-io-error detach; #配置I/O錯誤處理策略爲分離
# size max-bio-bvecs on-io-error fencing disk-barrier disk-flushes
# disk-drain md-flushes resync-rate resync-after al-extents
# c-plan-ahead c-delay-target c-fill-target c-max-rate
# c-min-rate disk-timeout
}
net {
# protocol timeout max-epoch-size max-buffers unplug-watermark
# connect-int ping-int sndbuf-size rcvbuf-size ko-count
# allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
# after-sb-1pri after-sb-2pri always-asbp rr-conflict
# ping-timeout data-integrity-alg tcp-cork on-congestion
# congestion-fill congestion-extents csums-alg verify-alg
# use-rle
}
syncer {
rate 1024M; #設置主備節點同步時的網絡速率
}
}
(2)建立資源配置文件
資源文件須要本身手工建立,目錄是在/usr/local/drbd/etc/drbd.d下面
#cd /usr/local/drbd/etc/drbd.d
# vim drbd.res
resource r1 { #這個r1是定義資源的名字
on master{ #on開頭,後面是主機名稱
device /dev/drbd0; #drbd設備名稱
disk /dev/sdb1; #drbd0使用的磁盤分區爲sdb1
address 192.168.1.138:7789; #設置drbd監聽地址與端口
meta-disk internal;
}
on slave{ #on開頭,後面是主機名稱
device /dev/drbd0; #drbd設備名稱
disk /dev/sdb1; #drbd0使用的磁盤分區爲sdb1
address 192.168.1.139:7789; #設置drbd監聽地址與端口
meta-disk internal;
}
}
在主節點138 從節點139 作一樣的操做
(1)、激活和建立設備塊
# mknod /dev/drbd0 b 147 0
# drbdadm create-md r1 資源名稱爲r1
等待片刻,顯示success表示drbd塊建立成功
Writing meta data...
initializing activity log
NOT initializing bitmap
New drbd meta data block successfully created.
(2)、準備啓動服務: 啓動DRBD服務:(node1,node2)
注:須要主從共同啓動方能生效
# service drbd start
(3)、查看狀態:(node1,node2)
# cat /proc/drbd 或 # service drbd status
(4)受權節點201爲,主節點
# drbdsetup /dev/drbd0 primary --force
(5)、分別查看主從DRBD狀態:
# service drbd status (主節點)
# service drbd status(從節點)
---------------------
ro在主從服務器上分別顯示 Primary/Secondary和Secondary/Primary
ds顯示UpToDate/UpToDate
表示主從配置成功。
從剛纔的狀態上看到mounted和fstype參數爲空,因此咱們這步開始掛載DRBD到系統目錄
# mkdir /data
# mkfs.ext4 /dev/drbd0
# mount /dev/drbd0 /data
注:Secondary節點上不容許對DRBD設備進行任何操做,包括只讀,全部的讀寫操做只能在Primary節點上進行,只有當Primary節點掛掉時,Secondary節點才能提高爲Primary節點繼續工做
(1)、(節點138 node1) 故障
# cd /data
# touch 1 2 3 4 5
# cd ..
# umount /data
# drbdsetup /dev/drbd0 secondary 故障後。降級爲從
注:這裏實際生產環境若DRBD1宕機,在DRBD2狀態信息中ro的值會顯示爲Secondary/Unknown,只須要進行DRBD提權操做便可。
# service drbd status
(節點139 node2 提權爲主)
# drbdsetup /dev/drbd0 primary 提權爲主
# mount /dev/drbd0 /data
# cd /data
# touch 6 7 8 9 10
# ls
1 10 2 3 4 5 6 7 8 9 lost+found
# service drbd status
不過如何保證DRBD主從結構的智能切換,實現高可用,這裏就須要Heartbeat來實現了。
Heartbeat會在DRBD主端掛掉的狀況下,自動切換從端爲主端並自動掛載/data分區
假設你把Primary的eth0擋掉,而後直接在Secondary上進行主Primary主機的提高,而且mount上,你可能會發如今 Primary上測試考入的文件確實同步過來了,以後把Primary的eth0恢復後,看看有沒有自動恢復 主從關係。通過查看,發現DRBD檢測出了Split-Brain的情況,也就是兩個節點都處於standalone狀態,故障描述以下:Split- Brain detected,dropping connection! 這就是傳說中的「腦裂」
(node2)
# drbdadm secondary r0
# drbdadm disconnect all
# drbdadm --discard-my-data connect r0
(node1)
# drbdadm disconnect all
# drbdadm connect r0
# drbdsetup /dev/drbd0 primary
3.一、HeartBeat簡單介紹
Heartbeat 項目是 Linux-HA 工程的一個組成部分,它實現了一個高可用集羣系統。心跳服務和集羣通訊是高可用集羣的兩個關鍵組件,在 Heartbeat 項目裏,由 heartbeat 模塊實現了這兩個功能。下面描述了 heartbeat 模塊的可靠消息通訊機制,並對其實現原理作了一些介紹。
Ø HeartBeat的組成:
Heartbeat內部結構由三大部分組成
(1)集羣成員一致性管理模塊(CCM)
CCM用於管理集羣節點成員,同時管理成員之間的關係和節點間資源的分配。Heartbeat模塊負責檢測主次節點的運行狀態,以決定節點是否失效。ha-logd模塊用於記錄集羣中全部模塊和服務的運行信息。
(2)本地資源管理器(LRM)
LRM負責本地資源的啓動、中止和監控,通常由LRM守護進程lrmd和節點監控進程Stonith Daemon組成。lrmd守護進程負責節點間的通訊;Stonith Daemon一般是一個Fence設備,主要用於監控節點狀態,當一個節點出現問題時處於正常狀態的節點會經過Fence設備將其重啓或關機以釋放IP、 磁盤等資源,始終保持資源被一個節點擁有,防止資源爭用的發生。
REDHAT的fence device有兩種,內部fence設備(如IBM RSAII卡,HP的iLO卡,Dell的DRAC,還有IPMI的設備等)和外部fence 設備(如UPS,SAN SWITCH,NETWORK SWITCH等)。
對於外部fence 設備,能夠作拔電源的測試,由於備機能夠接受到fence device返回的信號,備機能夠正常接管服務,
對於內部fence 設備,不能作拔電源的測試,由於主機斷電後,備機接受不到主板芯片作爲fence device返備的信號,就不能接管服務,clustat會看到資源的屬主是unknow,查看日誌會看到持續報fence failed的信息
(3)集羣資源管理模塊(CRM)
CRM用於處理節點和資源之間的依賴關係,同時,管理節點對資源的使用,通常由CRM守護進程crmd、集羣策略引擎和集羣轉移引擎3個部分組成。 集羣策略引擎(Cluster policy engine)具體實施這些管理和依賴;集羣轉移引擎(Cluster transition engine)監控CRM模塊的狀態,當一個節點出現故障時,負責協調另外一個節點上的進程進行合理的資源接管
。
Ø 原理:
heartbeat (Linux-HA)的工做原理:heartbeat最核心的包括兩個部分,心跳監測部分和資源接管部分,心跳監測能夠經過網絡鏈路和串口進行,並且支持 冗 餘鏈路(心跳通常會接2條跳線,1條冗餘),它們之間相互發送報文來告訴對方本身當前的狀態,若是在指定的時間內未收到對方發送的報文,那麼就認爲對方失效,這時需啓動資源接管模塊來接管運 行在對方主機上的資源或者服務