高可用集群之corosync+pacemaker

1、概念

　　在傳統Linux集群種類，主要分了三類，一類是LB集群，這類集群主要作用是對用戶的流量做負載均衡，讓其后端每個server都能均衡的處理一部分請求；這類集群有一個特點就是前端調度器通常是單點，后端server有很多臺，即便某一臺后端server掛掉，也不影響用戶的請求；其次就是HA集群，所謂ha集群就是高可用集群，這類集群的主要作用是對集群中的單點做高可用，所謂高可用就是在發生故障時，能夠及時的將故障轉移，從而使故障修復時間最??；這類集群的特點是在多臺節點上，各空閑節點會一直盯著工作節點，工作節點也會基于多播或廣播的方式把自己的心跳信息發送給其他空閑節點，一旦工作節點的心跳信息在一定時間內空閑節點沒有收到，那么此時就會觸發資源搶占，先搶到資源的成為新的工作節點，而其他節點又會一直盯著新的工作節點，直到它掛掉，然后再次觸發資源搶占；這類集群的特點就是一個節點工作，其他節點看著它工作，一旦工作節點掛了，立刻會有其他節點上來頂替它的工作；最后就是HP集群，HP集群主要用于在復雜計算中場景中，把多臺server的算力綜合一起，對復雜計算要求比較高的環境中使用；在生產環境中常見的LB和HA集群較多；

　　2、衡量系統的可用性

　　A=MTBF/(MTBF+MTTR)

　　MTBF（Mean Time Between Failure）平均無故障工作時間；MTTR（Mean Time to Repair）平均修復時長；也就是說衡量一個系統的可用性是系統無故障運行時間除以系統無故障運行時間+故障修復時間；我們知道一個系統完全沒有故障，這是不可能的，這也意味著A的取值是小于1；如果說一個系統的可用性為0，那么我們會認為該系統沒有任何用，所以系統可用性通常是大于0小于1，通常我們用一個百分比來描述系統的可用性；從上面的公式，如果我們要提升系統的可用性我們有兩種辦法，第一種就是無限提升mtbf的值，讓mtbf的值大到可以忽略mttr的值，當然這種方式理想中可行，在現實中，我們的系統一旦發生故障，修復的時間都不會是很少，也就說這種增大MTBF的方式，不是可行的；其次就是降低MTTR的值，降低MTTR的值就是縮短故障修復時間；通常我們降低MTTR的方式是通過冗余主機的方式；就是在容易發生故障的關鍵性業務上，提前給它配置好相同的服務，然后這臺空閑的server就一直盯著工作的server，一旦工作server發生故障，此時空閑的server就立刻把工作的server的IP 地址給搶過來，然后把服務啟動了，后端如果有共享存儲，此時把共享存儲掛載到自己對應的目錄；如果有必要我們還需要通過某些機制讓之前的server“爆頭”，以免發生死灰復燃的場景；

　　3、HA解決方案

　　我們知道高可用的是服務，但是通常一個服務該有的多組件也會高可用，比如httpd服務，對于httpd對外它一定會有一個ip地址在對外提供服務，其次就是httpd服務自身的進程，如果業務需要，我們可能還會用到共享存儲；通過上述描述，對于高可用httpd服務，我們需要在備份節點上對httpd的ip地址做高可用，服務進程，以及后端的共享存儲；對于ip地址的高可用通常是在備份節點上探測到活動節點故障時，第一時間把活動節點的ip地址配置到備份節點上，通常這個ip地址是一個虛擬的ip地址，所以我們叫它vip；對應用程序進程的高可用，通常是我們在備份節點上直接把對應服務提前啟動起來；后端共享存儲的高可用也是通過某種機制探測活動節點發生故障后，然后把共享存儲掛載到備份節點，使得整個httpd服務可用；我們把httpd從一個節點遷移到另一個節點的過程叫故障轉移（failover）；這里需要注意，在發生故障轉移后，之前活動節點有可能發生故障恢復的情況，此時為了不讓之前活動的節點對現有的服務資源發生爭用，我們在發生故障轉移時，應該讓其之前的節點“死”的更徹底一些，我們會讓備份節點對活動節點“開一槍”，讓發生故障的節點更徹底的故障；這種是為了避免資源爭用而導致服務的不可用；

　　vrrp協議的實現：keepalived

　　基于OpenAIS規范的實現：corosync；所謂AIS（application interface standard）是指用來定義應用程序接口標準，openais就是開放的應用程序接口標準，它是有SA Forum發布的一套規范；這些規范的主要目的就是為了提高中間件可移植和應用程序的高可用；

　　4、corosync+pacemaker架構

　　corosync的主要作用是提供messaging Layer，這個消息傳遞層的主要作用是，把個主機間的各狀態信息，空閑信息等等一系列信息通過消息傳遞層互相傳遞，使得托管在corosync上的服務能夠根據底層各主機傳遞的消息來決定該服務該運行到那臺主機上，一旦運行的服務所在主機發生故障時，它們又能夠根據消息傳遞層的消息來判斷該把服務遷移到那臺主機上運行；這樣一來托管在corosync上的服務能夠高可用；簡單點講，托管在corosync之上的服務對底層主機上不可見的，這也意味著托管在corosync上的服務是能夠調用和理解Messaging Layer中的消息；這樣一來托管在上面的服務就必須得提供接口來調用messaging Layer對外提供的接口，然后實現服務的遷移；而對于大多數程序來講，它根本就沒有這樣的接口，這樣一來我們要使用corosync實現服務高可用變得困難；為了解決托管在corosync的服務能夠調用corosync提供的接口，我們需要開發一個中間件，讓這個中間件能夠向下理解和調用coroysnc提供的接口，向上能夠托管服務；這個中間層就是pacemaker；它的主要作用是通過調用corosync提供的接口，來判斷把集群資源該怎么分配，服務該怎么遷移和運行；同時pacemaker還提供一個管理界面，能夠讓管理員來管理這些集群資源；而對于pacemaker來講，它主要有3各層次，其中CRM（cluster resource manager）的主要作用是通過調用messaging Layer提供的接口和各節點的狀態信息來決策集群資源的管理；然后通過接口把決策信息傳遞給LRM（local resource manager）；LRM的主要作用是對本地的資源做各種管理；而對于LRM來講，它要怎么管理本地資源呢？它通常不會自己去管理本地的資源，而是通過RA去管理，所謂RA（resource agent）就是資源代理；它會根據LRM發送的信息來對本地的資源進行管理，而這種管理通常是基于各種服務提供的起停腳本來實現的；比如，我們要把httpd服務托管在corosync+pacemaker這個架構上，首先我們得提供一個管理httpd的服務的腳本，比如centos7上的httpd.service，centos6上的/etc/init.d/httpd來實現；而這些腳本通常在我們使用yum安裝都會提供，這樣一來，我們要托管httpd服務就變得尤為簡單，我們只需要在pacemaker上配置，把httpd識別成集群資源即可；只要配置httpd為集群的資源，此時我們就可以在各主機上遷移httpd服務來實現httpd服務的高可用；要實現httpd服務在各節點主機上遷移，我們需要要注意各主機上必須有httpd服務；對于其他服務也是同樣的邏輯；簡單講corosync主要提供底層各主機消息狀態，集群狀態信息，而pacemaker主要對托管在其上的服務進行管理；當然pacemaker也可以通過調用corosync的接口來管理底層的主機，比如讓某一臺主機下線上線等等操作；

 　　5、corosync集群的投票系統

　　在集群發生網絡分區以后，怎樣確定該那一方繼續代表集群工作呢？所謂集群分區就表示，集群中的某一臺主機或一些主機不能檢測到其他主機的心跳；當集群發生分區以后，到底哪一方能夠繼續代表集群工作呢？如果是2臺主機組成的集群，當其中一臺host不能夠正常檢測到另一臺host的心跳時，它們都會認為對方故障了，此時就會存在一個資源爭用的問題，A認為B掛了，B認為A掛了，此時集群資源就會來回在A和B上飄動，使得整個服務都不可用；為了解決這樣的問題，我們必須有一個系統來來決定到底誰該代表集群工作；通常情況在一個分布式集群中，投票系統尤為重要，它決定了整個集群是否能夠正常工作；假如我們的集群有3臺主機組成，當其中一臺主機掛掉了，那么到底誰來代表集群工作呢？如果是A那么整個集群將不可用，那么是B C，誰來當領導呢？這個時候就需要投票系統來決策了；默認情況我們的集群各host都會有選票在自己手中，當發生分區以后，各host會根據自己檢測到的心跳信息發送給集群其他節點，根據選票的數量來決定誰故障了，誰能夠代表集群工作，如上面的例子，如果A掛了，那么B會把對A的檢測的心跳信息，發送給C，然后C也會把對A的檢測心跳信息發送給B，此時投票就是A掛了2票，而整個集群總共3票，已經有過半的選票都認為A掛了，那么A此時就不會繼續代表集群工作了；剩下的B和C可繼續代表集群工作；我們把能夠繼續代表集群工作的一方叫with quorum，就是選票大于總選票一半的一方；而對于選票小于或等于總選票的一方我們稱為without quorum；此時A就是without quorum一方，它會遵循no_quorum_policy指定的行為，通常no_quorum_policy默認是stop行為，意思就是without quorum一方會停止代表集群工作，當然它還有ignore、suicide、freeze行為；ignore表示忽略自己是without quorum一方的選票結果，繼續代表集群工作，suicide表示自殺，就是一旦不是with quorum一方就自我毀滅，freeze表示凍結，所謂凍結就是繼續服務老的請求，拒絕新的請求；B和C就是with quorum一方，它們會利用某種機制來挑選一個領導，然后根據消息傳遞層的消息決定把A上的資源搶過來跑在那個節點上繼續代表集群工作；而對于BC來講它們只是聯系不到A，A是否真的掛了呢？如果A沒有真的掛，那么BC此時把A上的ip地址搶過來，繼續代表集群工作，A可能再把ip地址搶過去，這樣一來集群就不能夠正常工作，為了解決BC的后顧之憂，BC會通過其他機制把A干掉（比如爆頭，stonith機制“shoot the other node in the head”），讓A即便是存活的也讓其掛掉，這樣做的目的就是為了保證集群資源不再受A的干擾，正常提供服務；在corosync+pacemaker這種架構中，領導的角色稱為DC（disignated coordinator指派的協調員）；DC的主要作用是接收管理員的配置信息和更新集群各狀態事務信息，并指派對應節點上的LRM對其集群資源操作，并通過消息傳遞層把管理配置信息同步給集群其他節點；這樣一來，在下一次集群發生分區以后，能夠在集群其他節點上選出新的DC，從而繼續代表集群工作；集群中的各狀態事務、配置信息，通常保存在CIB（cluster information base）中，而對于CIB中的各狀態事務信息由DC去更新，然后再同步到集群各節點中去；通常DC節點上會運行CRM、CIB、PE（policy engine）、LRM這四個組件；而非DC節點會運行CRM、CIB、LRM這三個組件；而PE的作用就是調度指揮DC把配置信息應用后的結果通過消息傳遞層發送給其他非DC節點并保存至各非DC節點的CIB中；

　　6、資源類型

　　在corosync+pacemaker架構上，最為核心的就是資源，前邊說了那么多，最終目的是為了管理托管在上面的資源；而對于資源來講資源是有類型的；簡單講就是可以用來調配的服務稱為資源，比如一個httpd服務，一個ip地址，一個后端共享存儲等等，這些都叫做資源；而對于一個完整的服務來講，它是由多個單一的資源組合而成；比如一個完整的httpd服務它應該由ip地址、httpd服務進程、在特殊場景中很有可能會有后端共享存儲；而這些資源在corosync+pacemaker上每個資源是有類型的，不同的類型運行方式個不相同；

　　primitive：基本資源，主資源；通常僅能運行為一份，運行在單個節點上的資源；

　　group：組；將一個或多個資源組織成一個可統一管理的單一單位資源；什么意思呢？默認情況托管在corosync+pacemaker上的資源會負載均衡的運行在多個主機之上，如果我們不將這些資源邏輯的關聯在一起，就會存在，ip地址在A主機上，服務進程在B主機上，后端存儲在C主機上，這樣一來，我們托管的服務就沒有辦法向外提供服務，為了解決各依賴資源分散的問題，我們需要將多個有關聯依賴的資源邏輯的組織成一個組，然后根據這個組為單位進行調度和管理；

　　clone：克??；一個資源可以在集群中運行多個副本，可以運行于多個節點；

　　mutil-state(master/slave)：是clone類型的資源的特殊表現，可以存在多個副本，副本間存在主從關系；

　　7、資源傾向性

　　什么叫資源傾向性呢？我們知道一個資源托管在corosync+pacemaker上，最終都會把資源落在某一個節點上運行，而我們怎么來限制這些資源在那個或那些各節點上運行呢？這個就需要我們配置資源對節點的傾向性了；所謂傾向性就是該資源更加傾向在那個節點運行或更加討厭在那個幾點上運行；在corosync+pacemaker集群上運行資源的方式有3中，N-1、N-M、N-N，其中N表示節點數量，M表示資源數量；N-1表示N個幾點上運行1各資源；這也意味這有N減1各節點上處于空先狀態，這對于服務器的資源利用率有點浪費；所以對于corosync+pacemaker集群和keepalived來講，keepalived更加輕量化；N-M表示N個幾點上運行M個資源通常M小于N；這意味著有N減M個節點冗余；N-N表示N個節點上運行N個資源，沒有冗余節點，這意味著一旦一個資源掛掉，那么對應就會遷移到其他節點，對于其他節點遷移到的節點只要提供的ip地址，進程，端口不沖突就不會有很大的問題，只不過相對壓力要大一點；對于不同運行方式，冗余的節點數量也是不同的；而對于資源該運行到那個節點我們可以通過定義資源對節點的傾向性來決定；默認情況每個資源都能夠在任意節點上運行；也就說默認情況當A資源掛掉以后，它的故障轉移范圍是其他節點，為了不讓A服務運行到B節點，我們可以定義A資源的對B資源的傾向性為負無窮，所謂負無窮就是只要有其他節點可運行就絕不在B節點上運行；通過定義資源對節點的傾向性，從而來限制資源在那些節點上進行轉移；這種限制資源對節點的傾向性我們叫做定義資源的故障轉移域；除了能夠定義資源對節點的傾向性，我們還可以定義資源與資源的傾向性，其邏輯都是相似的；對于資源傾向性通常我們會用分數來表示，其取值范圍是真無窮到負無窮；正無窮表示無限喜歡到某個節點或資源，只要對應節點正常存在就一定在該節點上，負無窮相反；

　　8、資源代理

　　所謂資源代理，就是指幫助去啟動一個資源的；在corosync+pacemaker集群上，資源代理就是指的是能夠幫助我們去啟動一個資源的腳本或程序，對于不同的資源代理，用到的腳本或程序不同；對于不同的資源在不同的系統，資源代理的類型也有不同，比如在centos6上，各服務的啟動腳本通常在/etc/init.d/下，所以通常會把/etc/init.d/目錄下的各腳本當作資源代理的腳本；這種資源類型叫做LSB的資源類型，通常這些腳本都支持start|stop|restart|status等等參數；對于LSB類型的資源代理，前提是代理的資源一定不能開機啟動，如果開機啟動對于托管corosync+pacemaker就無意義了，所以資源的啟動一定要交給corosync+pacemaker來管理不能開機啟動；對于centos7來說，它使用的是systemd方式來管理各服務的啟動，停止；它默認的存放unit file的路徑是/usr/lib/systemd/system/目錄下；而對于systemd類型的資源代理，我們一定要把托管為集群的服務 enable起來，可以理解為corosync+pacemaker它會到/etc/systemd/system/目錄下對應資源啟動腳本；而只有把對應服務enable來以后，它才會在/etc/systemd/system/目錄下存在；除了以上兩種資源代理還有OCF和stonith，OCF類型資源代理類似LSB腳本，當支持start,stop,status,monitor,mata-data等參數；stonith類型的資源代理專用配置stonith設備RA；service類型，以上4種都不符合的其他類型的資源代理；

　　9、corosync+pacemaker的安裝配置

　　前提：

　　1、各host時間同步；

　　2、各hosts文件能夠解析其他節點的主機名；選擇一各不和其他集群沖突的多播地址；

　　3、有需要可配置各節點ssh互信；

　　驗證：各主機上的時間和主機名以及hosts文件；

　　提示：為這里以兩主機演示特殊的兩節點集群；node01和node02都把時間服務器地址指向內網192.168.0.99這個時間服務器上；有關時間服務器的配置請參考https://www.cnblogs.com/qiuhom-1874/p/12079927.html；有關ssh互信配置可以參考https://www.cnblogs.com/qiuhom-1874/p/11783371.html；

　　配置好時間同步和ssh戶型以及host主機名解析以后，接下來安裝pacemaker

　　提示：安裝pacemaker會依賴corosync這個包，所以直接安裝pacemaker這一個包就可以了；對于node02也是同樣的操作；

　　配置corosync

　　查看corosync的程序環境

　　提示：/etc/corosync這個目錄用來存放corosync配置文件；其中corosync.conf.example是corosync的文本格式配置文件示例；corosync.conf.example.udpu這個是corosync使用udpu方式提供服務的配置文件示例；corosync.xml.example是xml格式的配置文件示例；/usr/lib/systemd/system/corosync.service這個是corosync unit file文件；/usr/sbin/corosync二進制程序文件；/usr/sbin/corosync-keygen這個工具用于生成corosync的密鑰文件；/var/lib/corosync這個目錄主要存放CIB數據庫文件；/var/log/cluster/目錄用于存放日志相關文件；

　　復制/etc/corosync/corosync.conf.example文件為/etc/corosync.conf

　　編輯配置文件

　　提示：對于totem這個配置段主要用于配置totem協議的相關屬性，其中version表示使用的版本，默認是2這個不用更改，保持默認就好；下面的crypto_cipher和crypto_hash這兩項用于配置是否啟用加密，這里默認是none，這意味這只要是在相同多播域內，它都會識別成集群成員；所以為了安全建議啟用集群事務消息通信加密；默認情況crypto_cipher支持aes256, aes192, aes128 and 3des這些加密算法，隨便配置一個加密算法即可；crypto_hash支持md5, sha1, sha256, sha384，sha512這些加密算法，隨便選一個即可；如果啟用以上兩項加密，我們需要在/etc/corosync/目錄下創建一個密鑰文件，且權限是600或著400的權限；并且集群各節點的密鑰文件必須相同；

　　創建密鑰文件

　　提示：可以現在把密鑰文件復制給node02也可以待會把配置文件配置好以后一并復制給node02都行；

　　繼續編輯配置文件

　　提示：interface配置段主要用于定義集群事務信息通信接口相關參數；其中ringnumber: 0表示第一塊網卡，如果有第二卡和第三塊，可以在totem配置段繼續用interface配置段來指定；bindnetaddr: 192.168.0.0用于配置用于集群事務信息通信的網絡地址，它默認會根據我們配置的網絡地址去本地主機上找對應的網卡；當然我們也可以配置ip地址也行，通常建議使用網絡地址；mcastaddr：是用來指定多播通信地址；這個如果在實驗環境中可以不用該，只要在集群中的各節點都是同一個多播地址即可；在生產中一定要注意不能和其他集群的多播通信地址沖突；mcastport用于指定多播通信的端口，默認是5405，這個通常不需要更改，保持默認即可；ttl: 1這個是配置多播通信的報文生存時長，默認配置為1，是為了防止其他節點收到多播報文后再次轉發；

　　提示：logging配置段主要用于定義日志相關；其中fileline: off表示不開啟fileline；所謂fileline就是記錄源文件和消息所在的行； to_stderr: no表示不把日志輸出到標準錯誤控制臺；to_logfile: yes表示把日志輸出到文件；logfile: /var/log/cluster/corosync.log用于指定日志文件路徑； to_syslog: yes是否將日志發送給syslog，默認是允許；debug: off是否關閉調試信息；默認是關閉的；timestamp: on是否加上時間戳，默認是開啟；如果我們只玩syslog中發送日志，可以將這一項關閉，因為syslog會自動將時間給我們補上；logger_subsys用于定義日志子系統，subsys指子系統的名稱，debug指定是否開啟調試信息；上面的subsys: QUORUM 表示開啟記錄quorum的日志信息；

　　提示：quorum用于配置投票系統相關配置，這里面默認是注釋了，我們只需要打開provider： corosync_votequorum即可；

　　提示：nodelist這段配置在默認的配置文件中沒有，我們加上這段配置就是告訴corosync我們期望的集群中的節點有兩個，他們的ip地址是那些；這里的ip地址可以寫主機名，也可以寫ip地址，建議使用主機名；

　　復制/etc/corosync/corosync.conf 和authkey文件到其他節點

　　啟動corosync

　　提示：如果啟動corosync服務以后，能夠看到udp的5405端口和5404端口處于監聽狀態和我們配置的多播地址，則說明corosync服務就配置好了；

　　驗證：查看corosync的日志，看看是否識別到兩個節點

　　提示：在node01上可以看到對應的集群成員有2個；

　　提示：在node02的日志文件中也能看到node01加入到集群，對應集群成員有兩個；

　　驗證：使用corosync-cfgtool命令來查看當前節點的初始化信息

　　提示：-s表示查看當前節點各ring上的狀態信息；從上面的信息可以看到node01上節點id為1，ring0上的id為192.168.0.41，狀態是活躍沒有發現錯誤；

　　提示：同樣在node02上使用corosync-cfgtool -s 可以看到當前node02上的ring0的狀態信息；從上面的截圖可以看到兩個節點都已經處于活躍狀態；

　　驗證：使用corosync-cmaptools查看成員

　　提示：默認不跟任何選項表示答應當前CIB中保存的配置內容；

　　提示：通過grep過濾，可以看到有兩個成員，他們的ip地址分別是192.168.0.41和42；到此corosync就配置并啟動成功了；

　　完整的corosync.conf配置文件內容

　　啟動pacamaker服務

　　提示：pacemaker默認不需要怎么配置就可以啟動，啟動以后，我們可以通過管理接口來配置；默認才開始啟動pacemaker時都會有一個pengine的進程啟動，但是通常只有DC上的pengine才會生效；

　　驗證：查看DC節點所在節點/集群狀態信息

　　提示：在集群任何一個幾點執行crm_mon就可以看到當前集群的狀態信息；上面截圖中可以看到node01.test.org是dc節點，在線的節點有兩個，分別是node01.test.org和node02.test.org；

　　到此corosync+pacemaker高可用集群就搭建好了，后續我們就直接可以在上面托管服務；