Linux HA Cluster-HeartBeat

Linux HA Cluster HeartBeat
    HA Cluster能夠解決單點故障問題，增長應用服務的可用性；
    故障場景：
        設計缺陷(bug)：軟件或服務器硬件設計或者製造時固有的問題；
        使用太久，硬件損耗；
        認爲故障：管理人員的誤操做，或者遭受攻擊；
        ……
    可用性公式：可用性=平均無端障時間/(平均無端障時間+平均修復時間)
        一般咱們使用百分比來描述某服務的可用性：90%，95%，99%，99.9%，99.99%，99.999%；
    heartbeat，心跳：集羣中的各個主機間檢測彼此是否處於理想狀態，即用來探測對方是否在線，若是不在線本身就會取而代之；
    HA中的各個節點沒法探測彼此的心跳信息時，就會誤覺得對方故障掉線，從而本身取而代之，這種狀態咱們稱之爲partitioned cluster（split brain）；
    若是集羣中的主機爲單數（大於等於3個）時，若是發生腦裂通常會採用少數服從多數的機制（投票機制：每一個主機有一票），將資源分給分裂後子集羣中主機個數多的一方，而另外一方就會被down掉；若是是雙節點的集羣能夠經過引入仲裁機制來決定分裂後將資源分配給哪一方，好比當heartbeat信息沒法互通時，可讓兩臺主機ping網關，誰能夠ping通，誰就多一票；
    當一臺主機宕機，其餘主機頂上以後，若是以前的主機修好上線之後是否會將資源從新轉回去呢？根據狀況的不一樣，處理方法不一樣，若是兩臺主機性能同樣的話就無需轉移資源，由於資源的切換會致使延遲和抖動，形成鏈接中斷；可是有時候咱們由於成本問題，通常都是使用一臺性能通常的主機來當作備用主機，它的性能是不如主主機的，因此咱們要進行資源轉移；當原來活動主機發生故障，而致使資源轉移至備用主機的過程咱們稱之爲：failover；而當原來活動主機上線之後，要將資源要回的過程咱們稱之爲failback；
    上面說的都是主機硬件的可用性，其實咱們在生產環境中發生的大多數問題都是出如今各類服務上的，好比當web服務出現問題了，咱們經過這種ping網關的機制能夠檢測到web故障嗎？顯然是不能的，因此咱們就須要一種能檢測應用程序的狀態信心的機制來解決這個問題；（各類服務、IP地址、文件系統等在Cluster中均可稱之爲資源）
其實Cluster中的各個主機之間探測心跳信息能夠理解成在各個主機上都運行一個程序，這些程序彼此之間能夠互相通訊（互相經過向對方的地址和端口來發送心跳信息），完成各主機狀態信息的檢測；咱們能夠將這些程序統一塊兒來看作一個公共層（集羣事務信息層，message layer），而後咱們就能夠經過這個層來傳遞信息，從而實現當服務故障時進行資源的轉移；可是這只是提供了各個主機中間傳遞心跳信息的方法而已，並無說明當服務出現故障之後怎麼轉移資源的具體過程，根據什麼信息（好比cpu的性能，內存的大小等）將資源轉移到哪臺合適的主機上等等的細節過程；因此必需要有一種機制來斷定資源在最開始時和活動節點故障後應該運行在那個節點上，這種機制須要依賴集羣事物信息層來收集各類信息，可是各類應用服務程序自己並不支持這個集羣事務信息層（也就是說設計的時候沒有調用這個層提供的API接口），也就是沒法運行在集羣中，實現高可用的，好比httpd；爲了解決這個問題，有人就在這個集羣事務信息層之上又提供了一個層次，這個層能夠幫助各類服務調用集羣事務信息層提供的API接口，實現發送心跳信息的功能，從而使之支持高可用功能，這個層咱們稱之爲集羣資源管理器（CRM）；這個CRM能夠根據管理員指定的配置將服務運行在某一指定節點上，它還會經過定時發送探測信息監控這個資源（服務）是否可用，若是通過指定次數的探測之後沒有獲得迴應，則將資源（ip、文件系統、服務等）轉移至其餘節點；從而使這些不具備高可用功能的服務，也可以在高可用集羣上運行了；
集羣中主機之間能夠經過單播、組播、廣播來傳遞心跳信息，使用組播或者廣播時主機能夠主動發送通告信息，來通知其餘主機本身還「活着」；
服務資源類型：
    HA-aware：資源自身可直接調用HA集羣底層的HA功能；
    none-HA-aware：必須藉助於CRM來完成在HA集羣上實現HA功能；
資源的約束關係：
    location：位置約束，定義資源更傾向於運行在哪一個節點上；使用數值來表示這個傾向性：-∞（不管如何也不會被選擇），+∞（只要可運行就選擇）
    colocation：排列約束，定義多個資源運行於同一節點上的傾向性；依然是-∞（不能在一塊兒的，互相排斥），+∞（必須在一塊兒的）
        group：分組，將過個資源定義在一個組中，而後將這個組約束在某個節點上；先定義組後添加各個資源；
    order：順序約束，定義資源在同一個節點上的啓動順序；
資源類型：
    primitive：只能運行於集羣內的某單個節點上；（也稱做native資源）
    group：相似一種容器，組中包含一個或多個資源，能夠經過調度這個組來統一管理這些資源；
    clone：這種資源在同一集羣中的多個節點上都會運行一份；
    master/slave：主從資源，在同一集羣內部的兩個節點上運行兩份資源，一個爲主，一個爲輔；
由於不一樣的資源啓動的方式不一樣，咱們配置的方式可能不一樣，好比：ip地址是經過配置命令ifconfig或者ip配置到網卡上的，各類服務程序能夠直接使用服務器自己提供的二進制程序啓動或者使用/etc/init.d/中的服務腳原本啓動，文件系統經過mount和umount來掛卸載等；因此咱們就又面臨一個麻煩了，就是使用CRM沒法對這些不一樣資源的不一樣使用方法來進行統一的配置，爲了不這種麻煩的配置，在CRM上面又提供了一個層次，叫作本地資源管理器（LRM）；本地資源管理器依然不能直接決定一個資源該如何啓動和關閉，而是藉助於資源代理（RA）的協助來實現；資源代理就是幫助啓動、關閉、監控資源的腳本，這些腳本有的是安裝的集羣軟件自帶的，它就能夠實現自動配置以及刪除ip地址操做；能夠將RA看作是運行在LRM上的又一個層次； 
通常當節點故障之後，運行在這個節點上的資源就要作fireover，而且肯定其是否真的故障了，若是主活動節點沒「死透」，替代的別用節點還要去「補一刀」；這就是下面的資源隔離機制；
資源隔離：
    級別：
        節點級別的隔離：STONITH，Shooting The Other Node In The Head
            power switch ：能夠實現直接將節點斷電來down掉這個節點；
        資源級別的隔離：fencing
            FC SAN switch ：切斷某種資源正常使用所必須的行爲，好比經過將交換機上鍊接web服務器的接口阻塞，從而達到阻止web服務訪問文件系統的行爲；
解決方案：各層的實現方法
    Message layer：實現傳遞心跳信息，完成主機狀態信息的檢測；
        heartbeat：v1，v2，v3
        corosync（主流）
        cman（Redhat，RHCS）
        keepalived（工做方式徹底不一樣於上述三種）
    CRM：負載在哪一個節點上激活資源
        heartbeat v1 ：haresources
            經過同名配置文件來實現功能；
        heartbeat v2 ：crm
            在各個節點上運行一個crmd進程，經過命令行工具crmsh，或者GUI工具hb_gui來配置各類資源關係；
        heartbeat v3 ：pacemaker
            能夠以獨立服務運行，也能夠以插件形式運行（corosync）；經過命令行工具crmsh，pcs或者GUI工具hawk（web頁面的），LCMC，pacemaker-mgmt；
        cman ：rgmanager
            經過命令行工具clustat，cman_tool或者GUI工具Conga（luci+ricci）
    LRM：通常CRM都會附帶LRM，相似CRM的一個子組件；負責激活RA腳本
    組合方式：
        heartbeat v1 ：全棧的，v1版本自己就能夠完成全部功能；
        heartbeat v2 ：也能夠獨立完成全部功能；
        heartbeat v3 + pacemaker ：由於pacemaker後來被獨立出來了，因此來另行安裝；
        corosync + pacemaker
        cman + rgmanager（RHCS）
        cman + pacemaker
    RA：實現資源的啓動，關閉，狀態查看等等
        heartbeat legacy：heartbeat傳統類型的RA，一般位於/etc/ha.d/haresources.d/目錄下，根據安裝方式不一樣可能位於其餘目錄中；
        LSB：Linux Stardard Base，位於/etc/rc.d/init.d/目錄中的服務腳本；這些腳本通常都有四個參數：{start|status|stop|restart}；→Centos6
        OCF：Open Cluster Framework，開放集羣框架
            子類別：provider
        STONITH ：專用於實現調用STONITH設備功能的資源；一般爲clone類型；
HeartBeat心跳信息傳遞機制：
能夠經過以太網網線或者串口；最好是使用專門的一條網線來實現心跳信息的傳遞；不太推薦串口；只有兩個節點時可使用UDP Unicast來發送心跳信息，若是是多節點的話建議使用UDP Multicast來發送心跳信息，不建議使用廣播（UDP Broadcast）；
        組播地址：用於標識一個IP組播域；IANA將D類地址空間分配給組播使用，其範圍時224.0.0.0-239.255.255.255；
        永久組播地址：224.0.0.0-224.0.0.255，用來給某種協議或程序使用
        臨時組播地址：224.0.1.0-238.255.255.255，能夠自定義使用的，構建高可用集羣時就是使用這一塊的地址；
        本地組播地址：239.0.0.0-239.255.255.255，只在特定場景下有用
HA案例：web services
    資源：ip，httpd，filesystem
    約束關係：使用group資源，或者經過排列約束讓資源運行在同一節點；
              順序約束，有次序的啓動資源，ip-filesystem-httpd
    使用heartbeat v2 + haresources搭配 → heartbeat v1
    配置HA集羣的前提：
        1.節點間時間必須同步，使用ntp協議同步;
            crontab -e
        */2 * * * * /usr/sbin/ntpdate ntp.api.bz &> /dev/null
    實驗環境中能夠這麼操做，若是是生產環境中建議使用ntp服務同步時間，由於ntpdate同步時間時是跳躍性的，好比你的時間比服務器上的時間慢了五分鐘，那麼他會直接將你的時間增長五分鐘，這五分鐘的間隔是瞬間設置上的，這樣會給你的服務器形成五分鐘的空檔期，服務器不會有任何關於這五分鐘的記錄；若是是使用ntp服務同步的話，若是你慢了，它會將你的時間設置的走快一點，慢慢遇上，若是你快了，它會將你的時間走慢一點，等待它遇上；
        2.節點須要經過主機名互相通訊，必須能解析主機名至IP地址；
            a.建議名稱解析使用hosts文件來實現；若是使用DNS服務的話，DNS就是一個單點，還會給總體架構添加維護上的不便；任什麼時候候依賴的外部資源越少越好；
                vim /etc/hosts
                    192.168.80.133 clone6
                    192.168.80.131 clone5
            b.通訊中使用的名字與節點名字必須保持一致，也就是hostname命令輸出的結果要和hosts文件中的配置相同；
            c.若是是兩節點的集羣，要考慮引入仲裁設備；
            d.建議各節點之間的root用戶可以基於祕鑰認證完成自動登陸；
                ssh-keygen –t rsa
                cd .ssh/
                touch authorized_keys
                chmod 600 authorized_keys
                ssh-copy-id –i .ssh/id_rsa.pub root@IP_ADDR
        Note：定義成爲集羣服務中的資源，必定不能開機自動啓動；由於他們將由crm管理；
    安裝程序包：Centos6
        依賴關係：
            yum install net-snmp-libs.x86_64  libnet.x86_64 PyXML.x86_64
        安裝程序包：
            rpm -ivh heartbeat-2.1.4-12.el6.x86_64.rpm heartbeat-pils-2.1.4-12.el6.x86_64.rpm heartbeat-stonith-2.1.4-12.el6.x86_64.rpm
    配置文件：
        /etc/ha.d/目錄下
            ha.cf：主配置文件，定義各節點上的heartbeat HA集羣的基本屬性；
            authkeys：集羣內各節點間彼此傳遞消息時使用的加密算法及祕鑰；
            haresources：heartbeat v1版本的資源管理器（CRM）配置接口；v1專用；
        Note：默認安裝之後上面的三個文件在/etc/ha.d/目錄中是沒有的，能夠將/usr/share/doc/heartbeat-2.1.4/中的案例複製到本目錄中，對其進行配置；
        cp /usr/share/doc/heartbeat-2.1.4/{haresources,ha.cf,authkeys} /etc/ha.d/
        cd /etc/ha.d/
        chmod 600 authkeys
        vim authkeys
            #auth 2
            #2 sha1 HI!     
            將2和auth以前的「#」去掉；其中2表示序號，sha1表示加密算法，HI!爲祕鑰，能夠更換，建議換一個隨機得、複雜一點的（openssl rand -base64 16）；auth 2 表示啓用2號加密方式對傳遞的消息加密，想使用哪一種加密算法auth後面就填寫其前面的序號；
        vim ha.cf
            logfacility     local0
            mcast eth2 225.12.12.12 694 1 0
                若是你的網卡不支持組播，能夠經過ip link set eth2 multicast on啓用；
            node    clone5
            node    clone6       添加節點
            ping 192.168.80.130    仲裁機制
        vim /etc/rsyslog.conf
            local0.*                /var/log/heartbeat.log
        service rsyslog restart
        vim haresources
            clone5  192.168.80.12/24/eth2/192.168.80.255 httpd   設置主節點，以及集羣所使用的IP地址等資源；其中IP地址爲fip（流動IP），網卡根據主機的不一樣設置不一樣，主節點是不變的；
        將這個節點的配置文件複製到其餘節點一份，而後根據狀況作細微修改；
        scp -p ha.cf authkeys haresources clone5:/etc/ha.d/
        在各個節點上啓動資源服務和heartbeat：
        service httpd start
        service httpd stop      測試httpd是否可用
        service heartbeat restart ; ssh clone6 'service heartbeat restart'     
        能夠經過中止heartbeat來查看資源是否轉移至備用節點；
    HA Cluster的工做模型：
        A/P：兩節點集羣，active，passive；工做於主備模式；
            HA Service一般只有一個，HA Resource可能會有多個；
        A/A：兩節點集羣，active/active，工做於雙主模式；
            每一個節點運行不一樣的服務，當其中一個服務出錯時，能夠轉移至其餘節點繼續工做；也能夠是運行相同的服務，使用DNS作負載均衡，當其中一個節點上的服務出錯時，將其IP地址轉移到另外一臺運行相同服務的節點上繼續工做；
        N/M：N個節點，M個服務，一般N>M；
            這種模型適能夠多個節點運行不一樣服務，留一個節點做爲備用，當有節點出現故障時，就將其轉移至備用節點上；
        Note資源轉移方式：當一個節點發生故障時，咱們以上作的實驗都是使其轉移到另外一個節點上，可是咱們還要考慮一種狀況：也就是若是執行資源轉移，那麼運行在故障節點內存中的數據就會丟失，會給咱們在成損失的；因此咱們經過如下幾種方式提供了一些是否轉移的選擇：
            stopped：使故障節點中止運行，暫時不作轉移；若是有須要再作轉移
            ignore：忽略故障，繼續運行；可能會形成資源徵用
            freeze：凍結，此前被分配到這個節點上的用戶還能夠繼續訪問，直到其推出爲止，可是不會接收新請求進來；
            suicide：自殺，一旦故障就直接退出；
    資源運行的傾向性：
        rgmanager：
            failover domain：爲故障資源的轉移指定範圍，即故障節點上的資源只能轉移到指定範圍內的節點上；
            node priority：節點優先級；
        pacemaker：
            資源粘性：運行於當前節點的傾向性；
            資源約束：上面已經提過了；
    DC：Designated Coordinator
        由啓動集羣后選舉產生，能夠控制節點故障後是否轉移，怎麼轉移，轉移至哪一個節點上，集羣分裂後由哪一個子集羣繼續提供服務等等的操做；
    使用heartbeat v2（crm）
        crm默認在每一個節點上運行一個守護進程（mgmtd，監聽在5560端口上），經過命令行工具還進行設置，並經過DC（首先會經過投票系統來選出DC）來向各節點進行同步設置；
        信息傳遞過程：假設本節點被選爲DC，DC經過crm向message layer通知信息，而後讓本節點的message layer向其餘節點的message layer發送信息，其收到信息後會經過message mayer經過crm，在由crm將消息傳遞給lrm，使其調用ra完成資源的啓用；
        配置：每一個節點都要配置
            在配置文件中添加如下一行就能夠啓用crm
            vim ha.cf
                crm on
            Note：啓用crm後須要禁用v1版的haresources資源管理器；
            service heartbeat start
        工具：
            rpm -ivh heartbeat-gui-2.1.4-12.el6.x86_64.rpm
            能夠經過crm_mon查看節點狀態
            因爲其餘命令行工具使用比較麻煩因此建議使用hb_gui這個GUI圖形工具配置集羣信息；
            使用xshell（須要配套安裝xmanager）和Centos6本身的圖形界面均可以打開這個圖形界面，可是其餘的貌似就不能夠了；
            使用hb_gui須要給用戶（hacluster）設置一個密碼：
                echo 「admin」 | passwd --stdin hacluster
            hb_gui &
                鍵入剛纔設置的密碼就能夠開始設置啦！
 

1.    點擊上面的那個「+」開始添加資源
能夠選擇native（基本資源），group（組資源），location（位置），order（順序），colocation（排序）
 

2.Resource ID爲資源名稱，Belong to group 指定所屬組，Type指定資源種類（ip，各類服務（好比httpd）；經過Name選擇其對應的RA，Class/Provider建議使用lsb），Parameter指定資源的屬性（好比若是資源爲IP地址，就會要求輸入IP地址，能夠手動指定網卡設備，子網掩碼等）；
 

3.點擊添加之後就會回到以前的主頁面，在Resources選項中會出現剛纔設置的資源名稱；默認資源是未啓動的，能夠點擊右鍵而後選擇啓動，而且默認運行在DC上；
    使用ifconfig命令在DC上就能夠看見一個地址資源已經設置完畢了；
4.循環以上過程，添加須要的資源種類；好比集羣的是web服務就須要添加IP、FileSystem、httpd；
5.接下來能夠經過group或者各類約束條件來限制資源運行在哪一個節點上，哪些資源要在同一個節點上，以及資源的啓動順序爲什麼；若是使用group須要先定義組後添加資源；
    操做：在Constraints中選擇各類約束類型，對其進行詳細設置；
 

6.ID指定約束類型的名字，From指定以前設置的資源的名字，To也是以前設置的資源的名字，Score指定資源在同一節點的的傾向性；From爲跟隨者，To爲被跟隨者；Symmetrical指定集羣的類型是夠爲對稱結構（默認不運行在任何節點上，只能運行在指定節點），默認爲非對稱（能夠運行在任何節點）；←Colocation
    Note：Order（啓動順序）以及Location（啓動在哪一個節點上）設置與Colocation相似；

   

    注：根據馬哥視頻作的學習筆記，若有錯誤，歡迎指正；侵刪；