RAC heartbeat 心跳機制

世界上最遙遠的距離,不是生與死。而是咱們同一個集羣的兩個節點,你卻聽不到個人心跳。
必要性:維持集羣的⼀致性
RAC⼼跳機制 – 集羣⼼跳
基本機制:
一、 肯定節點和節點間的連通性,達到彼此瞭解
二、⽤共享的位置保持節點的連通訊息,及時記錄和更新
三、本地節點的⾃我監控 (保證本身是能夠對外提供服務的,正常運行的。若是可以自我監控,在本身遇到問題的時候可以本身處理,這樣就能夠更好的把握節點的一致性)
 
節點須要本身有一個自我監控的功能,因此經過本地心跳,將本身的狀態發送給cssdagent,cssdmonitor兩個進程實現自我監控。那麼碰到問題的時候就不須要等待別人去發現。
 
 
⽹絡⼼跳
介紹:⽹絡⼼跳主要是確保集羣節點間的連通性,以便節點之間可以瞭解彼此的狀態。
原理: ocssd.bin進程每秒向其餘節點發送⽹絡⼼跳,經過⼼跳狀況確認節點的連通性,以及當⽹絡⼼跳出現問題時作出處理。
2018-07-23 22:59:07.495: [    CSSD][3535726336]clssnmSendingThread: sending status msg to all nodes
 
相關進程:
這個功能主要是由守護進程 ocssd.bin 完成的。 ocssd.bin守護進程包含如下線程:
發送線程(clssnmSending Thread): 每秒向集羣中其餘節點發送⽹絡⼼跳信息
(在ocssd的log裏面能夠看到:2018-07-23 23:08:17.727: [    CSSD][3535726336]clssnmSendingThread: sending status msg to all nodes)
分析線程(clssnmPolling Thread): 分析收到的⽹絡⼼跳信息並進⾏處理,若是發現某⼀些節點持續丟失⽹絡⼼跳,就會通知集羣進⾏從新配置。
集羣從新配置線程(clssnmRcfgMgrThread): 當接收到分析線程的從新配置的通知時,該進程進⾏從新配置。
派遣線程(clssnmClusterListener): 負責接收從遠程傳遞過來的消息,以後,根據信息的種類發給相關的線程進⾏處理。 (須要接受節點其餘節點傳來的各類信息,在接受信息的時候若是發現接受的信息是網絡心跳的信息,那麼就會派給分析線程,若是是其餘信息就會派發給相應的處理進程)
 
 
磁盤⼼跳
腦裂就是節點1和節點2因爲種種緣由私有網絡出現問題了,兩個節點之間不能互相訪問,若是各自的節點狀態正常只是交互出現了問題,這個時候兩個節點都會認爲是這個集羣當中惟一的倖存者,做爲惟一的倖存者要承擔管理集羣的責任,那麼全部的節點都會想要去修改磁盤上面的數據,經過修改數據來達到管理集羣的目的,因此節點之間都想將對方踢出去達到本身管理集羣。出現腦裂以後就會出現機制決定將誰踢出集羣,這個時候就要經過磁盤心跳了。
介紹:若是因爲⽹絡⼼跳異常,致使集羣出現腦裂的發⽣,磁盤⼼跳則幫助解決該問題。
原理: Oracle集羣的每⼀個節點每秒都會向集羣中全部的表決盤註冊本地節點的磁盤⼼跳信息,也就是說,全部的VF的信息是相同的。同時會將⾃⼰可以聯繫的到的集羣中的其餘節點的信息,或者說本地節點認爲集羣中的成員列表信息填⼊到表決盤中。⼀旦發⽣腦裂, CSS的從新配置線程就會經過表決盤的信息瞭解集羣節點間的連通性,從⽽決定集羣會分裂成⼏個⼦集羣,以及每一個⼦集羣所包含的節點狀況和每一個節點的狀態。
相關進程(這些都是OCSSD.bin進程下面的線程完成的)
磁盤⼼跳線程(clssnmvDiskPing Thread): 該線程負責向集羣的表決盤中發送磁盤⼼跳,同時,該線程也負責讀取表決盤中的kill block的信息,以肯定本地節點是否須要從新啓動。
磁盤⼼跳監控線程(clssnmvDiskPingMonitor Thread): 監控磁盤⼼跳線程是否可以正常地發送⼼跳,是否能正確讀取kill block的信息。
Kill block線程(clssnmv KillBlock Thread): 負責監控VF的 kill block信息(只負責監控,若是發現kill block信息是針對該節點的,那麼就會告知磁盤心跳線程去讀取kill block)
(kill bock:在一個集羣當中當,若是節點之間交互出現了問題,會產生集羣從新配置的主節點,集羣配置的主節點是如何將部分集羣殺掉呢?集羣配置主節點也是一個節點,它不可以將其餘節點幹掉,若是要將節點驅逐出集羣,作法就是向voting盤當中寫入一些kill block的信息,這些kill block也能夠稱爲Posion package有毒的信息,這個有毒的信息是有針對性的,針對要踢出的節點是有毒的,將誰給殺死,而不是對全部節點都是有效的)
 
 
(1)若是一個節點在規定的一段時間內,持續的不能訪問多個voting盤裏面的其中一個,那麼voting盤會從節點中離線掉。
(2)若是一個節點和一半以上voting盤不能作交互,就認爲這個節點出現了問題,會將該節點離線掉。
(3)在多個節點下不能確保都能訪問到全部voting盤的時候,要確保集羣中全部的節點都能訪問到一塊voting盤。當一塊voting盤能被全部的節點訪問到纔可以記錄到全部節點的互相連通的信息。節點向voting盤寫入的信息包括本身節點的狀態信息和其餘能夠連通節點的信息。因此任什麼時候候都要有一塊正常狀態的能夠被全部節點訪問到的voting盤。任什麼時候候都要保證這個機制。
 
如圖,有兩個節點,三個voting盤,在某一個時刻,node1和voting盤1不能交互了,即不能連通了。node2和voting盤3也不能交互了,這個時候最須要保證的是voting盤2能夠和全部節點交互。
 
若是沒有這個機制:當一個節點不能訪問一半的以上的voting盤就將其掛掉,可能會產生什麼問題呢?仍是上面圖,好比node1和voting盤1,2出現了問題,node2和voting盤3出現了問題,那麼就致使集羣當中任何一個voting盤都不能存放節點全部的信息,這樣會出現嚴重的問題。不容許任何一個節點和超過一半以上的voting盤不能連通的狀況而且節點還處於存活狀態。
要將voting盤設置爲奇數個,而且保證一半以上voting盤能夠被訪問到才認爲該節點是正常的。
 
本地心跳是用來實現自我監控。經過自我監控OCSSD.bin進程狀態來確認本身是否有問題。
本地⼼跳
介紹:監控ocssd.bin進程以及本地節點的狀態
原理: Oracle每⼀秒在向遠端節點發送⽹絡⼼跳的同時,同⼀進程向cssdagentd代理和cssdmonitor代理髮送本地ocssd.bin進程的狀態。
相關進程:
實現過程
發送線程: 每秒向集羣中其餘節點發送⽹絡⼼跳信息的同時,同⼀進程(clssnmsending Thread)發送本地ocssd.bin進程的狀態)
------------>cssdagent
------------>cssdmonitor
10g+11.1
11.2+
 
 集羣節點從新配置
 
1.當集羣中某⼀個節點連續⼀段時間丟失⽹絡⼼跳以後,分析線程決定發起集羣從新配置,在從新配置的過程中會產生主節點來控制集羣,網絡心跳斷了以後並不會馬上將有問題的節點踢出集羣,而是產生RM,以後由RM來處理。
2.集羣的從新配置管理節點(Reconfiguration Master)向集羣中全部節點發送從新配置消息,全部收到此消息的節點會回覆該消息,並通知RM節點⾃⼰的狀態。
3.接下來, RM節點基於每一個節點的狀態進⾏投票並檢查是否有腦裂發⽣
4.對於檢查腦裂, RM會查看⽹絡⼼跳⽆法訪問的節點的磁盤⼼跳信息,以便確認這些節點的狀態,若是這些狀態本⾝是正常的,須要避免。
5. RM節點向表決盤中寫⼊「有毒的(poison package) 」的信息,須要重啓的節點在訪問到表決盤的時候讀取到該信息,完成本節點的重啓,重啓以後加入集羣,也有可能踢出去了,不加入集羣了。
6. RM節點修改集羣節點列表,從新配置完成。 (集羣被踢出去或者加入都是要從新分配資源的)
 
 
 
集羣從新配置的幾種狀況:
 
丟失本地心跳:本地的一些進程出現了一些問題不須要等待別人來處理,會經過本身重啓來保證集羣的一致性。
 
 
RAC 節點管理
概念:負責維護數據庫集羣的節點列表,確保只有集羣的節點可以數據庫,而且在節點加⼊集羣或者離開集羣時,更新集羣列表;負責數據庫節點與集羣管理軟件的通訊,向集羣軟件中註冊數據庫的信息。
節點列表:記錄集羣中節點的狀態 (對集羣節點的管理是怎麼實現的呢?是經過節點列表的位圖信息來肯定節點是否正常,1表明正常,0表明不正常)
 
經過什麼機制保證集羣列表是實時更新的呢,好比一個節點的加入和節點的踢出。由於列表是放在共享存儲上面,能夠供全部節點訪問,由於是共享的,爲了保證在修改列表的過程是一致的,oracle控制機制就是當一個節點要加入到集羣裏面或者從集羣裏面出去,發生變化的這個節點會以獨佔的方式佔用這個列表資源,修改完資源信息以後來分發給其餘節點。這樣就能保持集羣的一致性。
 
實例的啓動發生了什麼?節點和節點之間要相互溝通,實例要和集羣管理軟件溝通,即要將實例信息註冊到集羣管理軟件當中。
假如說實例1啓動了,第一個步驟就是實例1向集羣管理軟件當中註冊信息,即以前的視圖上面增長了一位是1,以後集羣管理軟件通知實例2和實例3,告訴他們集羣當中有新加進來的節點,通知完成以後,實例1,2,3都達成共識,都是集羣當中的一員了,這個時候要進行資源的從新分配。
上面圖中日誌信息記入一個節點加入產生的信息。
相關文章
相關標籤/搜索