?heartbeat原理介紹?

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

轉載于:https://blog.51cto.com/ace105/716172

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。