?heartbeat原理介紹?

HeartBeat運行于備用主機上的Heartbeat可以通過以太網(wǎng)連接檢測主服務(wù)器的運行狀態(tài)，一旦其無法檢測到主服務(wù)器的"心跳"則自動接管主服務(wù)器的資源。通常情況下，主、備服務(wù)器間的心跳連接是一個獨立的物理連接，這個連接可以是串行線纜、一個由"交叉線"實現(xiàn)的以太網(wǎng)連接。Heartbeat甚至可同時通過多個物理連接檢測主服務(wù)器的工作狀態(tài)，而其只要能通過其中一個連接收到主服務(wù)器處于活動狀態(tài)的信息，就會認為主服務(wù)器處于正常狀態(tài)。從實踐經(jīng)驗的角度來說，建議為Heartbeat配置多條獨立的物理連接，以避免Heartbeat通信線路本身存在單點故障。 1、串行電纜：被認為是比以太網(wǎng)連接安全性稍好些的連接方式，因為hacker無法通過串行連接運行諸如telnet、ssh或rsh類的程序，從而可以降低其通過已劫持的服務(wù)器再次侵入備份服務(wù)器的幾率。但串行線纜受限于可用長度，因此主、備服務(wù)器的距離必須非常短。 2、以太網(wǎng)連接：使用此方式可以消除串行線纜的在長度方面限制，并且可以通過此連接在主備服務(wù)器間同步文件系統(tǒng)，從而減少了從正常通信連接帶寬的占用。 基于冗余的角度考慮，應(yīng)該在主、備服務(wù)器使用兩個物理連接傳輸heartbeat的控制信息；這樣可以避免在一個網(wǎng)絡(luò)或線纜故障時導(dǎo)致兩個節(jié)點同時認為自已是唯一處于活動狀態(tài)的服務(wù)器從而出現(xiàn)爭用資源的情況，這種爭用資源的場景即是所謂的"腦裂"（split-brain）或"partitioned cluster"。在兩個節(jié)點共享同一個物理設(shè)備資源的情況下，腦裂會產(chǎn)生相當(dāng)可怕的后果。 為了避免出現(xiàn)腦裂，可采用下面的預(yù)防措施： 1、如前所述，在主、備節(jié)點間建立一個冗余的、可靠的物理連接來同時傳送控制信息； 2、一旦發(fā)生腦裂時，借助額外設(shè)備強制性地關(guān)閉其中一個節(jié)點； 第二種方式即是俗稱的"將其它節(jié)點'爆頭'（shoot the other node in the head）"，簡稱為STONITH。基于能夠通過軟件指令關(guān)閉某節(jié)點特殊的硬件設(shè)備，Heartbeat即可實現(xiàn)可配置的Stonith。但當(dāng)主、備服務(wù)器是基于WAN進行通信時，則很難避免"腦裂"情景的出現(xiàn)。因此，當(dāng)構(gòu)建異地"容災(zāi)"的應(yīng)用時，應(yīng)盡量避免主、備節(jié)點共享物理資源。 Heartbeat的控制信息： "心跳"信息: （也稱為狀態(tài)信息）僅150 bytes大小的廣播、組播或多播數(shù)據(jù)包。可為以每個節(jié)點配置其向其它節(jié)點通報"心跳"信息的頻率，以及其它節(jié)點上的heartbeat進程為了確認主節(jié)點出節(jié)點出現(xiàn)了運行等錯誤之前的等待時間。 集群變動事務(wù)（transition）信息：ip-request和ip-request-rest是相對較常見的兩種集群變動信息，它們在節(jié)點間需要進行資源遷移時為不同節(jié)點上heartbeat進程間會話傳遞信息。比如，當(dāng)修復(fù)了主節(jié)點并且使其重新"上線"后，主節(jié)點會使用ip-request要求備用節(jié)點釋放其此前從因主節(jié)點故障而從主節(jié)點那里接管的資源。此時，備用節(jié)點則關(guān)閉服務(wù)并使用ip-request-resp通知主節(jié)點其已經(jīng)不再占用此前接管的資源。主接點收到ip-request-resp后就會重新啟動服務(wù)。 重傳請求：在某集群節(jié)點發(fā)現(xiàn)其從其它節(jié)點接收到的heartbeat控制信息"失序"（heartbeat進程使用序列號來確保數(shù)據(jù)包在傳輸過程中沒有被丟棄或出現(xiàn)錯誤）時，會要求對方重新傳送此控制信息。 Heartbeat一般每一秒發(fā)送一次重傳請求，以避免洪泛。 上面三種控制信息均基于UDP協(xié)議進行傳送，可以在/etc/ha.d/ha.cf中指定其使用的UDP端口或者多播地址（使用以太網(wǎng)連接的情況下）。 此外，除了使用"序列號/確認"機制來確保控制信息的可靠傳輸外，Heartbeat還會使用MD5或SHA1為每個數(shù)據(jù)包進行簽名以確保傳輸中的控制信息的安全性。 資源腳本： 資源腳本（resource scripts）即Heartbeat控制下的腳本。這些腳本可以添加或移除IP別名（IP alias)或從屬IP地址（secondary IP address），或者包含了可以啟動/停止服務(wù)能力之外數(shù)據(jù)包的處理功能等。通常，Heartbeat會到/etc/init.d/或/etc/ha.d/resource.d/目錄中讀取腳本文件。Heartbeat需要一直明確了解"資源"歸哪個節(jié)點擁有或由哪個節(jié)點提供。在編寫一個腳本來啟動或停止某個資源時，一定在要腳本中明確判斷出相關(guān)服務(wù)是否由當(dāng)前系統(tǒng)所提供。 Heartbeat的配置文件： /etc/ha.d/ha.cf 定義位于不同節(jié)點上的heartbeat進程間如何進行通信； 1.3.1 配置ha.cf文件 ha.cf是heartbeat的主要配置文件，可以對heartbeat的多數(shù)性能和狀態(tài)進行配置。大部分選項的取值可以采用默認值，其中的主要選項及配置方法說明如下： debugfile /var/log/ha-debug：該文件保存heartbeat的調(diào)試信息 logfile /var/log/ha-log：heartbeat的日志文件 keepalive 2：心跳的時間間隔，默認時間單位為秒 deadtime 30：超出該時間間隔未收到對方節(jié)點的心跳，則認為對方已經(jīng)死亡。 warntime 10：超出該時間間隔未收到對方節(jié)點的心跳，則發(fā)出警告并記錄到日志中。 initdead 120：在某些系統(tǒng)上，系統(tǒng)啟動或重啟之后需要經(jīng)過一段時間網(wǎng)絡(luò)才能正常工作，該選項用于解決這種情況產(chǎn)生的時間間隔。取值至少為deadtime的兩倍。 udpport 694：設(shè)置廣播通信使用的端口，694為默認使用的端口號。 baud 19200：設(shè)置串行通信的波特率。 serial /dev/ttyS0：選擇串行通信設(shè)備，用于雙機使用串口線連接的情況。如果雙機使用以太網(wǎng)連接，則應(yīng)該關(guān)閉該選項。 bcast eth0：設(shè)置廣播通信所使用的網(wǎng)絡(luò)接口卡。 auto_failback on：heartbeat的兩臺主機分別為主節(jié)點和從節(jié)點。主節(jié)點在正常情況下占用資源并運行所有的服務(wù)，遇到故障時把資源交給從節(jié)點并由從節(jié)點運行服務(wù)。在該選項設(shè)為on的情況下，一旦主節(jié)點恢復(fù)運行，則自動獲取資源并取代從節(jié)點，否則不取代從節(jié)點。 ping ping-node1 ping-node2：指定ping node，ping node并不構(gòu)成雙機節(jié)點，它們僅僅用來測試網(wǎng)絡(luò)連接。 respawn hacluster /usr/lib/heartbeat/ipfail：指定與heartbeat一同啟動和關(guān)閉的進程，該進程被自動監(jiān)視，遇到故障則重新啟動。最常用的進程是ipfail，該進程用于檢測和處理網(wǎng)絡(luò)故障，需要配合ping語句指定的ping node來檢測網(wǎng)絡(luò)連接。 /etc/ha.d/haresources 定義對某個資源來說哪個服務(wù)器是主節(jié)點，以及哪個節(jié)點應(yīng)該擁有客戶端訪問資源時的目標IP地址。 authkeys文件用于heartbeat的鑒權(quán)設(shè)置，共有三種可用的鑒權(quán)方式：crc、md5和sha1。三種方式安全性依次提高，但同時占用的系統(tǒng)資源也依次擴大。crc安全性最低，適用于物理上比較安全的網(wǎng)絡(luò)，sha1提供最為有效的鑒權(quán)方式，占用的系統(tǒng)資源也最多。 其配置語句格式如下： auth <number> <number> <authmethod> [<authkey>] 舉例說明： auth 1 1 sha1 key-for-sha1 其中鍵值key-for-sha1可以任意指定，number設(shè)置必須保證上下一致。 auth 2 2 crc crc方式不需要指定鍵值。 /etc/ha.d/authkeys 定義Heartbeat包在通信過程中如何進行加密。 當(dāng)ha.cf或authkeys文件發(fā)生改變時，需要重新加載它們就可以使用之生效；而如果haresource文件發(fā)生了改變，則只能重啟heartbeat服務(wù)方可使之生效。 盡管Heartbeat并不要求主從節(jié)點間進行時鐘同步，但它們彼此間的時間差距不能超過1分鐘，否則一些配置為高可用的服務(wù)可能會出異常。 Heartbeat當(dāng)前也不監(jiān)控其所控制的資源的狀態(tài)，比如它們是否正在運行，是否運行良好以及是否可供客戶端訪問等。要想監(jiān)控這些資源，冉要使用額外的Mon軟件包來實現(xiàn)。 haresources配置文件介紹： 主從節(jié)點上的/etc/ra.d/raresource文件必須完全相同。文件每行通常包含以下組成部分： 1、服務(wù)器名字：指正常情況下資源運行的那個節(jié)點（即主節(jié)點），后跟一個空格或tab；這里指定的名字必須跟某個節(jié)點上的命令"uname -n"的返回值相同； 2、IP別名（即額外的IP地址，可選）：在啟動資源之前添加至系統(tǒng)的附加IP地址，后跟空格或tab；IP地址后面通常會跟一個子網(wǎng)掩碼和廣播地址，彼此間用"/"隔開； 3、資源腳本：即用來啟動或停止資源的腳本，位于/etc/init.d/或/etc/ha.d/resourcd.d目錄中；如果需要傳遞參數(shù)給資源腳本，腳本和參數(shù)之間需要用兩個冒號分隔，多個參數(shù)時彼此間也需要用兩個冒號分隔；如果有多個資源腳本，彼此間也需要使用空格隔開； haresources文件用于指定雙機系統(tǒng)的主節(jié)點、集群IP、子網(wǎng)掩碼、廣播地址以及啟動的服務(wù)等。其配置語句格式如下： node-name network-config <resource-group> 其中node-name指定雙機系統(tǒng)的主節(jié)點，取值必須匹配ha.cf文件中node選項設(shè)置的主機名中的一個，node選項設(shè)置的另一個主機名成為從節(jié)點。 network-config用于網(wǎng)絡(luò)設(shè)置，包括指定集群IP、子網(wǎng)掩碼、廣播地址等。resource-group用于設(shè)置heartbeat啟動的服務(wù)，該服務(wù)最終由雙機系統(tǒng)通過集群IP對外提供。 格式如下： primary-server [IPaddress[/mask/interface/broadcast]] resource1[::arg1::arg2] resource2[::arg1::arg2] 例如： primary-server 221.67.132.195 sendmail httpd HA的LVS集群有兩臺Director，在啟動時，主節(jié)點占有集群負載均衡資源（VIP和LVS的轉(zhuǎn)發(fā)及高度規(guī)則），備用節(jié)點監(jiān)聽主節(jié)點的"心跳"信息并在主節(jié)點出現(xiàn)異常時進行"故障轉(zhuǎn)移"而取得資源使用權(quán)，這包括如下步驟： 1、添加VIP至其網(wǎng)絡(luò)接口； 2、廣播GARP信息，通知網(wǎng)絡(luò)內(nèi)的其它主機目前本Director其占有VIP； 3、創(chuàng)建IPVS表以實現(xiàn)入站請求連接的負載均衡； 4、Stonith； 棄用resource腳本，改用ldirecotord來控制LVS： ldirectord用來實現(xiàn)LVS負載均衡資源的在主、備節(jié)點間的故障轉(zhuǎn)移。在首次啟動時，ldirectord可以自動創(chuàng)建IPVS表。此外，它還可以監(jiān)控各Realserver的運行狀態(tài)，一旦發(fā)現(xiàn)某Realserver運行異常時，還可以將其從IPVS表中移除。 ldirectord進程通過向Realserver的RIP發(fā)送資源訪問請求并通過由Realserver返回的響應(yīng)信息來確定Realserver的運行狀態(tài)。在Director上，每一個VIP需要一個單獨的ldirector進程。如果Realserver不能正常響應(yīng)Directord上ldirectord的請求，ldirectord進程將通過ipvsadm命令將此Realserver從IPVS表中移除。而一旦Realserver再次上線，ldirectord會使用正確的ipvsadm命令將其信息重新添加至IPVS表中。 例如，為了監(jiān)控一組提供web服務(wù)的Realserver，ldirectord進程使用HTTP協(xié)議請求訪問每臺Realserver上的某個特定網(wǎng)頁。ldirectord進程根據(jù)自己的配置文件中事先定義了的Realserver的正常響應(yīng)結(jié)果來判斷當(dāng)前的返回結(jié)果是否正常。比如，在每臺web服務(wù)器的網(wǎng)站目錄中存放一個頁面".ldirector.html"，其內(nèi)容為"GOOD"，ldirectord進程每隔一段時間就訪問一次此網(wǎng)頁，并根據(jù)獲取到的響應(yīng)信息來判斷Realserver的運行狀態(tài)是否正常。如果其返回的信息不是"GOOD"，則表明服務(wù)不正常。 ldirectord需要從/etc/ha.d/目錄中讀取配置文件，文件名可以任意，但建議最好見名知義。 實現(xiàn)過程： 創(chuàng)建/etc/ha.d/ldirectord-192.168.0.219.cf，添加如下內(nèi)容： Global Directives checktimeout=20 ldirectord等待Realserver健康檢查完成的時間，單位為秒； 任何原因的檢查錯誤或超過此時間限制，ldirector將會將此Realserver從IPVS表中移除； checkinterval=5 每次檢查的時間間隔，即檢查的頻率； autoreload=yes 此項用來定義ldirectord是否定期每隔一段時間檢查此配置文件是否發(fā)生改變并自動重新加載此文件； logfile="/var/log/ldirectord.log" 定義日志文件存放位置； quiescent=yes 當(dāng)某臺Realserver出現(xiàn)異常，此項可將其設(shè)置為靜默狀態(tài)（即其權(quán)重為"0"）從而不再響應(yīng)客戶端的訪問請求； For an http virtual service virtual=192.168.0.219:80 此項用來定義LVS服務(wù)及其使用的VIP和PORT real=192.168.0.221:80 gate 100 定義Realserver，語法：real=RIP:port gate|masq|ipip [weight] real=192.168.0.223:80 gate 300 fallback=127.0.0.1:80 gate 當(dāng)IPVS表沒有任何可用的Realserver時，此"地址：端口"作為最后響應(yīng)的服務(wù)； 一般指向127.0.0.1，并可以通過一個包含錯誤信息的頁面通知用戶服務(wù)發(fā)生了異常； service=http 定義基于什么服務(wù)來測試Realserver； request=".ldirectord.html" receive="GOOD" scheduler=wlc #persistent=600 #netmask=255.255.255.255 protocol=tcp 定義此虛擬服務(wù)用到的協(xié)議； checktype=negotiate ldirectord進程用于監(jiān)控Realserver的方法；{negotiate|connect|A number|off} checkport=80 在/etc/hd.d/haresources中添加類似如下行： node1.example.com 192.168.0.219 ldirectord::ldirectord-192.168.0.219.cf? DRBD詳細說明 一、主要功能 DRBD實際上是一種塊設(shè)備的實現(xiàn),主要被用于Linux平臺下的高可用(HA)方案之中。他是有內(nèi)核模塊和相關(guān)程序而組成，通過網(wǎng)絡(luò)通信來同步鏡像整個設(shè)備，有點類似于一個網(wǎng)絡(luò)RAID的功能。也就是說當(dāng)你將數(shù)據(jù)寫入本地的DRBD設(shè)備上的文件系統(tǒng)時,數(shù)據(jù)會同時被發(fā)送到網(wǎng)絡(luò)中的另外一臺主機之上，并以完全相同的形式記錄在一個文件系統(tǒng)中（實際上文件系統(tǒng)的創(chuàng)建也是由DRBD的同步來實現(xiàn)的）。本地節(jié)點（主機）與遠程節(jié)點（主機）的數(shù)據(jù)可以保證實時的同步，并保證IO的一致性。所以當(dāng)本地節(jié)點的主機出現(xiàn)故障時,遠程節(jié)點的主機上還會保留有一份完全相同的數(shù)據(jù),可以繼續(xù)使用，以達到高可用的目的。 在高可用(HA)解決方案中使用DRBD的功能,可以代替使用一個共享盤陣存儲設(shè)備。因為數(shù)據(jù)同時存在于本地主機和遠程主機上,在遇到需要切換的時候,遠程主機只需要使用它上面的那份備份數(shù)據(jù),就可以繼續(xù)提供服務(wù)了。 二、底層設(shè)備支持 DRBD需要構(gòu)建在底層設(shè)備之上，然后構(gòu)建出一個塊設(shè)備出來。對于用戶來說，一個DRBD設(shè)備，就像是一塊物理的磁盤，可以創(chuàng)建文件系統(tǒng)。DRBD所支持的底層設(shè)備有以下這些類： 1、一個磁盤，或者是磁盤的某一個分區(qū)； 2、一個soft raid 設(shè)備； 3、一個LVM的邏輯卷； 4、一個EVMS（Enterprise Volume Management System，企業(yè)卷管理系統(tǒng)）的卷； 5、其他任何的塊設(shè)備。 三、配置簡介 1、全局配置項（global） 基本上我們可以做的也就是配置usage-count是yes還是no了，usage-count參數(shù)其實只是為了讓linbit公司收集目前drbd的使用情況。當(dāng)drbd在安裝和升級的時候會通過http協(xié)議發(fā)送信息到linbit公司的服務(wù)器上面。 2、公共配置項（common） 這里的common，指的是drbd所管理的多個資源之間的common。配置項里面主要是配置drbd的所有resource可以設(shè)置為相同的參數(shù)項，比如protocol，syncer等等。 3、資源配置項（resource） resource項中配置的是drbd所管理的所有資源，包括節(jié)點的ip信息，底層存儲設(shè)備名稱，設(shè)備大小，meta信息存放方式，drbd對外提供的設(shè)備名等等。每一個resource中都需要配置在每一個節(jié)點的信息，而不是單獨本節(jié)點的信息。實際上，在drbd的整個集群中，每一個節(jié)點上面的drbd.conf文件需要是完全一致的。 另外，resource還有很多其他的內(nèi)部配置項： net：網(wǎng)絡(luò)配置相關(guān)的內(nèi)容，可以設(shè)置是否允許雙主節(jié)點（allow-two-primaries）等。 startup：啟動時候的相關(guān)設(shè)置，比如設(shè)置啟動后誰作為primary（或者兩者都是primary：become-primary-on both） syncer：同步相關(guān)的設(shè)置。可以設(shè)置"重新"同步（re-synchronization）速度（rate）設(shè)置，也可以設(shè)置是否在線校驗節(jié)點之間的數(shù)據(jù)一致性（verify-alg 檢測算法有md5，sha1以及crc32等）。數(shù)據(jù)校驗可能是一個比較重要的事情，在打開在線校驗功能后，我們可以通過相關(guān)命令（drbdadm verify resource_name）來啟動在線校驗。在校驗過程中，drbd會記錄下節(jié)點之間不一致的block，但是不會阻塞任何行為，即使是在該不一致的 block上面的io請求。當(dāng)不一致的block發(fā)生后，drbd就需要有re-synchronization動作，而syncer里面設(shè)置的rate 項，主要就是用于re-synchronization的時候，因為如果有大量不一致的數(shù)據(jù)的時候，我們不可能將所有帶寬都分配給drbd做re- synchronization，這樣會影響對外提提供服務(wù)。rate的設(shè)置和還需要考慮IO能力的影響。如果我們會有一個千兆網(wǎng)絡(luò)出口，但是我們的磁盤 IO能力每秒只有50M，那么實際的處理能力就只有50M，一般來說，設(shè)置網(wǎng)絡(luò)IO能力和磁盤IO能力中最小者的30%的帶寬給re- synchronization是比較合適的（官方說明）。另外，drbd還提供了一個臨時的rate更改命令，可以臨時性的更改syncer的rate 值：drbdsetup /dev/drbd0 syncer -r 100M。這樣就臨時的設(shè)置了re-synchronization的速度為100M。不過在re-synchronization結(jié)束之后，你需要通過 drbdadm adjust resource_name 來讓drbd按照配置中的rate來工作。 四、資源管理 1、增加resource的大小： 當(dāng)遇到我們的drbd resource設(shè)備容量不夠的時候，而且我們的底層設(shè)備支持在線增大容量的時候（比如使用lvm的情況下），我們可以先增大底層設(shè)備的大小，然后再通過 drbdadm resize resource_name來實現(xiàn)對resource的擴容。但是這里有一點需要注意的就是只有在單primary模式下可以這樣做，而且需要先在所有節(jié)點上都增大底層設(shè)備的容量。然后僅在primary節(jié)點上執(zhí)行resize命令。在執(zhí)行了resize命令后，將觸發(fā)一次當(dāng)前primary節(jié)點到其他所有secondary節(jié)點的re-synchronization。 如果我們在drbd非工作狀態(tài)下對底層設(shè)備進行了擴容，然后再啟動drbd，將不需要執(zhí)行resize命令（當(dāng)然前提是在配置文件中沒有對disk參數(shù)項指定大小），drbd自己會知道已經(jīng)增大了容量。 在進行底層設(shè)備的增容操作的時候千萬不要修改到原設(shè)備上面的數(shù)據(jù)，尤其是drbd的meta信息，否則有可能毀掉所有數(shù)據(jù)。 2、收縮resource容量： 容量收縮比擴容操作要危險得多，因為該操作更容易造成數(shù)據(jù)丟失。在收縮resource的容量之前，必須先收縮drbd設(shè)備之上的容量，也就是文件系統(tǒng)的大小。如果上層文件系統(tǒng)不支持收縮，那么resource也沒辦法收縮容量。 如果在配置drbd的時候?qū)eta信息配置成internal的，那么在進行容量收縮的時候，千萬別只計算自身數(shù)據(jù)所需要的空間大小，還要將drbd的meta信息所需要的空間大小加上。 當(dāng)文件系統(tǒng)收縮好以后，就可以在線通過以下命令來重設(shè)resource的大小：drbdadm -- --size=***G resize resource_name。在收縮的resource的大小之后，你就可以自行收縮釋放底層設(shè)備空間（如果支持的話）。 如果打算停機狀態(tài)下收縮容量，可以通過以下步驟進行： a、在線收縮文件系統(tǒng) b、停用drbd的resource：drbdadm down resourcec_name c、導(dǎo)出drbd的metadata信息（在所有節(jié)點都需要進行）：drbdadm dump-md resource_name > /path_you_want_to_save/file_name d、在所有節(jié)點收縮底層設(shè)備 e、更改上面dump出來的meta信息的la-size-sect項到收縮后的大小（是換算成sector的數(shù)量后的數(shù)值） f、如果使用的是internal來配置meta-data信息，則需要重新創(chuàng)建meta-data:drbdadm create-md resource_name g、將之前導(dǎo)出并修改好的meta信息重新導(dǎo)入drbd（摘錄自linbit官方網(wǎng)站的一段導(dǎo)入代碼）： drbdmeta_cmd=$(drbdadm -d dump-md test-disk) ${drbdmeta_cmd/dump-md/restore-md} /path_you_want_to_save/file_name h、啟動resource：drbdadm up resource_name 五、磁盤損壞 1、detach resource 如果在resource的disk配置項中配置了on_io_error為pass_on的話，那么drbd在遇到磁盤損壞后不會自己detach底層設(shè)備。也就是說需要我們手動執(zhí)行detach的命令（drbdadm detach resource_name），然后再查看當(dāng)前各節(jié)點的ds信息。可以通過cat /proc/drbd來查看，也可以通過專有命令來查看：drbdadm dstat resource_name。當(dāng)發(fā)現(xiàn)損壞的那方已經(jīng)是Diskless后，即可。如果我們沒有配置on_io_error或者配置成detach的話，那么上面的操作將會由自動進行。 另外，如果磁盤損壞的節(jié)點是當(dāng)前主節(jié)點，那么我們需要進行節(jié)點切換的操作后再進行上面的操作。 2、更換磁盤 當(dāng)detach了resource之后，就是更換磁盤了。如果我們使用的是internal的meta-data，那么在換好磁盤后，只需要重新創(chuàng)建mata-data（drbdadm create-md resource_name），再將resource attach上（drbdadm attach resource_name），然后drbd就會馬上開始從當(dāng)前primary節(jié)點到本節(jié)點的re-synchronisation。數(shù)據(jù)同步的實時狀況可以通過 /proc/drbd文件的內(nèi)容獲得。 不過，如果我們使用的不是internal的meta-data保存方式，也就是說我們的meta-data是保存在 resource之外的地方的。那么我們在完成上面的操作（重建meta-data）之后，還需要進行一項操作來觸發(fā)re- synchnorisation，所需命令為：drbdadminvalidate resource_name 。 六、節(jié)點crash（或計劃內(nèi)維護） 1、secondary節(jié)點 如果是secondary接待你crash，那么primary將臨時性的與secondary斷開連接，cs狀態(tài)應(yīng)該會變成 WFConnection，也就是等待連接的狀態(tài)。這時候primary會繼續(xù)對外提供服務(wù)，并在meta-data里面記錄下從失去secondary 連接后所有變化過的block的信息。當(dāng)secondary重新啟動并連接上primary后，primary -> secondary的re-synchnorisation會自動開始。不過在re-synchnorisation過程中，primary和 secondary的數(shù)據(jù)是不一致狀態(tài)的。也就是說，如果這個時候primary節(jié)點也crash了的話，secondary是沒辦法切換成 primary的。也就是說，如果沒有其他備份的話，將丟失所有數(shù)據(jù)。 2、primary節(jié)點 一般情況下，primary的crash和secondary的crash所帶來的影響對drbd來說基本上是差不多的。唯一的區(qū)別就是需要多操作一步將secondary節(jié)點switch成primary節(jié)點先對外提供服務(wù)。這個switch的過程drbd自己是不會完成的，需要我們?nèi)藶楦深A(yù)進行一些操作才能完成。當(dāng)crash的原primary節(jié)點修復(fù)并重新啟動連接到現(xiàn)在的primary后，會以secondary存在，并開始re-synchnorisation這段時間變化的數(shù)據(jù)。 在primary節(jié)點crash的情況下，drbd可以保證同步到原secondary的數(shù)據(jù)的一致性，這樣就避免了當(dāng) primary節(jié)點crash之后，secondary因為數(shù)據(jù)的不一致性而無法switch成primary或者即使切換成primary后因為不一致的數(shù)據(jù)無法提供正常的服務(wù)的問題。 3、節(jié)點永久性損壞（需要更換機器或重新安裝相關(guān)軟件的情況） 當(dāng)某一個節(jié)點因為硬件（或軟件）的問題，導(dǎo)致某一節(jié)點已經(jīng)無法再輕易修復(fù)并提供服務(wù)，也就是說我們所面對的是需要更換主機（或從 OS層開始重新安裝）的問題。在遇到這樣的問題后，我們所需要做的是重新提供一臺和原節(jié)點差不多的機器，重新開始安裝os，安裝相關(guān)軟件，從現(xiàn)有整提供服務(wù)的節(jié)點上copy出drbd的配置文件（/etc/drbd.conf），創(chuàng)建meta-data信息，然后啟動drbd服務(wù)，以一個 secondary的身份連接到現(xiàn)有的primary上面，后面就會自動開始re-synchnorisation。 七、split brain的處理 split brain實際上是指在某種情況下，造成drbd的兩個節(jié)點斷開了連接，都以primary的身份來運行。當(dāng)drbd某primary節(jié)點連接對方節(jié)點準備發(fā)送信息的時候如果發(fā)現(xiàn)對方也是primary狀態(tài)，那么會會立刻自行斷開連接，并認定當(dāng)前已經(jīng)發(fā)生split brain了，這時候他會在系統(tǒng)日志中記錄以下信息："Split-Brain detected,dropping connection!"當(dāng)發(fā)生split brain之后，如果查看連接狀態(tài)，其中至少會有一個是StandAlone狀態(tài)，另外一個可能也是StandAlone（如果是同時發(fā)現(xiàn)split brain狀態(tài)），也有可能是WFConnection的狀態(tài)。 如果我們在配置文件中配置了自動解決split brain（好像linbit不推薦這樣做），drbd會自行解決split brain問題，具體解決策略是根據(jù)配置中的設(shè)置來進行的。 如果沒有配置split brain自動解決方案，我們可以手動解決。首先我們必須要確定哪一邊應(yīng)該作為解決問題后的rimary，一旦確定好這一點，那么我們同時也就確定接受丟失在split brain之后另外一個節(jié)點上面所做的所有數(shù)據(jù)變更了。當(dāng)這些確定下來后，我們就可以通過以下操作來恢復(fù)了： a、首先在確定要作為secondary的節(jié)點上面切換成secondary并放棄該資源的數(shù)據(jù)： drbdadm secondary resource_name drbdadm -- --discard-my-data connect resource_name b、在要作為primary的節(jié)點重新連接secondary（如果這個節(jié)點當(dāng)前的連接狀態(tài)為WFConnection的話，可以省略） ?drbdadm connect resource_name 當(dāng)作完這些動作之后，從新的primary到secondary的re-synchnorisation會自動開始。 八、meta data存放地點的比較 1、internal meta-data（meta-data和數(shù)據(jù)存放在同一個底層設(shè)備之上） 優(yōu)點：一旦meta-data創(chuàng)建之后，就和實際數(shù)據(jù)綁在了一起，在維護上會更簡單方便，不用擔(dān)心meta-data會因為某些操作而丟失。另外在硬盤損壞丟失數(shù)據(jù)的同時，meta-data也跟著一起丟失，當(dāng)更換硬盤之后，只需要執(zhí)行重建meta-data的命令即可，丟失的數(shù)據(jù)會很容易的從其他節(jié)點同步過來。 缺點：如果底層設(shè)備是單一的磁盤，沒有做raid，也不是lvm等，那么可能會造成性能影響。因為每一次寫io都需要更新meta- data里面的信息，那么每次寫io都會有兩次，而且肯定會有磁頭的較大尋道移動，因為meta-data都是記錄在dice設(shè)備的最末端的，這樣就會造成寫io的性能降低。 2、external meta data（meta-data存放在獨立的，與存放數(shù)據(jù)的設(shè)備分開的設(shè)備之上） 優(yōu)點：與internal meta-data的缺點完全相對，可以解決寫io的爭用問題。 缺點：由于meta-data存放在與數(shù)據(jù)設(shè)備分開的地方，就意味著當(dāng)磁盤損壞更換磁盤之后，必須手動發(fā)起全量同步的操作。也就是管理維護會稍微麻煩那么一點點，很小的一點點。 如果我們希望在已經(jīng)存在數(shù)據(jù)的設(shè)備上面建立drbd的資源，并且不希望丟失該設(shè)備上面的數(shù)據(jù)，又沒辦法增大底層設(shè)備的容量，而且上層文件系統(tǒng)又沒辦法收縮的話，我們就只能將meta data創(chuàng)建成external方式。

轉(zhuǎn)載于:https://blog.51cto.com/ace105/716172

總結(jié)

以上是生活随笔為你收集整理的heartbeat原理介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。