lvs-nat模式

LVS-nat模式

lvs-dr模式下：修改數據包的mac地址、數據包出去的時候是由真實服務器直接發送給客戶端
lvs-nat模式下：修改數據包的ip地址、數據包出去的時候是由真實服務器發送給調度服務器，而後由調度服務器再轉發給客戶端。
lvs-nat模式：因爲nat模式下在調度服務器常常修改數據包內的ip，數據包進來和出去都要修改ip，集羣系統中的真實服務器若不少，數據量就很大，那麼對調度服務器的性能要求就高，因此調度服務器會成爲瓶頸。
工做原理：

（1）客戶端向防火牆（開啓路由轉發）發送請求數據包（源ip是客戶端、目標ip是防火牆）
 防火牆---->調度服務器（源ip是客戶端目標ip是調度服務器）

（2）調度服務器根據調度算法選擇一臺真實服務器，將數據包轉發給它（源ip是客戶端，目標ip是真實服務器）

（3）真實服務器收到數據包以後進行處理，而後再將回應數據包發送給調度服務器（源ip是真實服務器，目標ip是客戶端）
調度服務器-->防火牆（源ip是真實服務器，目標ip是客戶端）

（4）調度服務器再轉發給客戶端（源ip是真實服務器，目標ip是客戶端）

防火牆爲何要開啓路由轉發，調度服務器爲何要開啓路由轉發？
 不一樣網段通訊交給路由器。跨網段了，必須得查找路由，若沒有路由，則只能是默認路由，那默認路由在這裏就是網關的呀，網關通常有兩個ip，若是不開啓路由 轉發功能，就不會有路由表，不會有另外一個網段的路由記錄，也就不知道應該如何走，那麼就只能和另外一個網段的網卡上的ip通訊，而另外一個網段上的全部的其餘 ip都不能通（結合圖理解）。因此要開啓路由轉發功能。

   路由轉發：路由器 把IP數據包的目IP地址和路由表對比，找到匹配的路由表項以後，根據這個路由表項的指示將數據包轉發給下一個網絡設備或PC。

（1）dnat--->數據包進去時：目標地址轉發dnat，即客戶端要訪問防火牆上的某個ip的某個端口，它就會把這個ip該爲後面調度服務器上的ip的某個端口（結合圖理解）dnat就是外網訪問內網時，修改成內網的一個ip
如上圖：客戶端能訪問到防火牆的eth0,可是訪問不到防火牆的eth1，由於那是內網了，eth1是私有地址。（能夠搞成公網地址可是一、公網地址浪費財力二、公網地址少），那麼問題來了，它也要訪問調度服務器，而調度服務器也是私有地址，如何才能訪問呢。
 當你訪問到防火牆（保護做用）的eth0時，它就轉發到調度服務器的eth0或者某個端口好比（192.168.10.6：80）訪問其餘端口不轉發。也就是說dnat其實就是寫一條防火牆規則，匹配該規則就轉發，不匹配就不轉發。
（2）snat--->數據包出來時：源地址轉發snat,即當內網的某個網絡或某個ip要訪問外網的時候就把它改成網關上的另外一個ip（結合圖理解） snat就是內網訪問外網時，修改成外網的一個ip
如：# iptables -t nat -A POSTROUTING -s192.168.0.0/24 -j SNAT --to 1.1.1.1 將內網192.168.0.0/24的源地址修改成外網的1.1.1.1，用於NAT

LVS+Heartbeat+Ldirectord

（1）客戶端發送請求包給load balancer的虛擬ip（vip，是在網卡上設置虛擬ip）（源ip是客戶端，目標ip是load balancer的vip），
 （爲何數據包要發送給load balancer的vip而不是發給實際的ip呢？那怎麼作高可用呀，高可用就是一個掛了，另外一個還能夠繼續提供服務，即就是作熱備。你把數據包給了這個實際ip，那麼問題來了，這個調度服務器掛了，訪問不了了。heartbeat就是利用心跳線作高可用的，一旦收不到另外一臺的心跳就會得到vip，對呀， 主掛了，那麼能夠用備的實際ip啊。這樣就能夠提供服務了啊，能夠人家不知道你是備用的調度服務器啊怎麼訪問你。再說你的實際ip也和主的實際ip不同 啊。那我能夠用arp廣播啊，告訴客戶端個人ip是多少，它就能夠訪問了啊。那你不用heartbeat心跳線，你怎麼知道主掛了呢。我能夠用arp廣播 啊或者用ping啊，主若是一直不迴應我，那不就是掛了嗎那我就能夠用備的實際ip來提供服務啊。你是要有客戶端吧，客戶端只訪問一個ip,arp廣播 啊，告訴客戶端備ip是什麼。個人天。你訪問的淘寶的時候，www.baidu.com，你點擊連接而後域名解析到一個ip，你只知道一個ip，怎麼會知 道另外一個ip，就算是arp，你也只能根它是同一個局域網才能知道。）

（2）load balancer根據調度算法選擇集羣系統中的一臺真實服務器，而後將該請求包發送給真實服務器。
（ 源ip是客戶端，目標ip是真實服務器的vip，因爲兩臺load balancer和全部真實服務器的vip都是同一個虛擬ip，因此此時要修改mac地址爲真實服務器的mac）

（當調度服務器把數據包發給真實服務器時，因爲全部真實服務器的vip都是同樣的，因此數據包就不知道要到哪臺服務器上，因此此時用到mac地址。）
（兩臺調度服務器，一個主，一個備。主和備的虛擬ip也是同一個是浮動的ip，當備經過heartbeat得知主失效後，就會自動成爲主，而後接管主調度上的服務或者資源）
（兩臺調度服務器得設置實際的ip,而不能只有vip，由於兩臺機器上的vip是同一個vip，那怎麼通訊啊。因此仍是得設置實際的ip）
（調度服務器和真實服務器之間通訊能夠經過vip嗎？哎又是同一個問題，全部的vip都是同樣的。再說了，ipvsadm也要用到實際的ip。 ipvsadm指明的是調度的算法和調度的ip。不設置實際的ip，調度服務器把數據包調度給誰呀。不是修改來mac地址了嗎。那也得知道實際ip才能用arp獲得mac地址啊。。因此真實服務器也得有實際的ip才能夠。）
（heartbeat最核心的包括兩個部分：心跳檢測部分和資源接管部分。心跳檢測能夠經過網絡鏈路和串口進行，並且支持冗餘鏈路，它們之間相互發送報文來告訴對方本身當前的狀態，若是在指定時間內未收到對方發送的報文，那麼就認爲對方失效，這時啓動資源接管模塊來接管運行在對方主機上的資源或服務等。)
（抑制arp廣播：由於全部真實服務器的vip都是同樣的。禁arp就是不讓交換機知道它有這個vip。由於交換機會記錄ip和mac。進來的時候是根據 交換機找內網主機的。交換機也是有條目的。交換機記錄了整個局域網內全部的ip和mac的映射，雖然主機上也會有ip和mac的映射，可是隻記錄的是經過 信的主機的ip和mac。防止內網ip衝突。）
（自路由：就是真實服務器上的vip要和本身的實際ip進行通訊,數據包出去的時候就是在vip那個網口上，而vip要發數據出去必需要讀路由嘛。問題是 它沒有路由。設置vip的時候，它是32位的子網掩碼，也就是說它本身是一個網段也就它一個ip。設置vip時就必須給它設置爲32位的子網掩碼，讓它不 能和別人進行通訊。那真實服務器的vip是怎麼和它的實際ip進行通訊的呢。添加自路由route add -host ip dev eth0:0 最好把它寫進rc.local讓它開機啓動 ip指的是真實ip，vip是在dev eth0:0 準確的說是vip經過真實ip往外通訊）

（3）真實服務器對該請求包進行處理以後，將數據包發送給客戶端（源ip是vip，目標ip是客戶端）

heartbeat的調度服務器超過兩臺怎麼實現的？

Heartbeat只能是兩臺調度服務器，不能有多臺。心跳線嘛

若是用keepalive就能夠：

調度服務器能夠爲多臺，一主多備，或者 互爲主主。用到的是vrrp協議。如果互爲主主的話，剛開始的那一臺主調度服務器，是根據受權值來判斷剛開始誰是那臺主調度。這個就是受權值 。這個是規定這臺機器是主仍是備

VRRP虛擬路由冗餘協議(Virtual RouterRedundancy Protocol，簡稱VRRP) 容錯協議

Keepalived就是用的這個vrrp協議。

VRRP的工做過程以下：

1.       路由器開啓VRRP功能後，會根據優先級肯定本身在備份組中的角色。優先級高的路由器成爲主用路由器，優先級低的成爲備用路由器。主用路由器按期發送VRRP通告報文，通知備份組內的其餘路由器本身工做正常；備用路由器則啓動定時器等待通告報文的到來。

2.       VRRP在不一樣的主用搶佔方式下，主用角色的替換方式不一樣：

l在搶佔方式下，當主用路由器收到VRRP通告報文後，會將本身的優先級與通告報文中的優先級進行比較。若是大於通告報文中的優先級，則成爲主用路由器；不然將保持備用狀態。

l在非搶佔方式下，只要主用路由器沒有出現故障，備份組中的路由器始終保持主用或備用狀態，備份組中的路由器即便隨後被配置了更高的優先級也不會成爲主用路由器。

3.       若是備用路由器的定時器超時後仍未收到主用路由器發送來的VRRP通告報文，則認爲主用路由器已經沒法正常工做，此時備用路由器會認爲本身是主用路由器，並對外發送VRRP通告報文。備份組內的路由器根據優先級選舉出主用路由器，承擔報文的轉發功能

 

 

1、負載均衡 
  負載均衡的目的就是將大量的負載請求經過負載均衡調度轉發將請求分發到提供相同應用的不一樣服務器上，提供一個單獨服務器所不具有的負載能力。一般將提供實際服務的服務器羣叫作real server，好比實際提供smtp、http服務的服務器。而提供負載分發功能的這個設備就是負載均衡設備，硬件的有經常使用的Radware，Alten 等，軟件的就是lvs。對於用戶來講，須要一個提供統一的入口地址來訪問，這個地址就是VIP(虛擬IP virtual ip)地址。用戶只關心VIP地址，LVS負責把VIP的請求分發給real server 
 loader balancer是整個集羣系統的前端，負責把客戶請求轉發到real server上。
 Backup 是備份調度服務器，當Load balancer不可用時接替它，成爲實際的real server。
 heartbeat安裝在load balancer和backup上，運行於active/standby模式。當load balancer失效時，Backup自動激活成爲實際的load balancer。切換到active模式時，按順序啓動virtual ip、ipvs、ldirectord；切換到standby模式時，按順序關閉ldirectord、ipvs、virtualip。
 ipvs是LVS集羣系統的核心軟件，主要做用是安裝在load balancer上，把發往virtual ip的請求轉發到真實服務器上。

2、Heartbeat

HeartBeat的做用：

經過HeartBeat，能夠將資源（IP以及程序服務等資源）從一臺已經故障的計算機快速轉移到另外一臺正常運轉的機器上繼續提供服務，通常稱之爲高可用的服務。在實際的生產應用場景中，heartbeat的功能和另外一個高可用的開源軟件keepalived有不少的相同之處，在咱們實際的生產業務中也是有區別的。

HeartBeat的工做原理：

經過修改Heartbeat的軟件的配置文件，能夠制定哪一臺Heartbeat服務器做爲主服務器，則另外一臺將自動成爲熱備服務器。而後在熱備服務器上配置Heartbeat守護程序來監聽來自主服務器的心跳消息。若是熱備服務器在指定時間內未監聽到來自主服務器的心跳，就會啓動故障轉義程序，並取得主服務器上的相關資源服務的全部權，接替主服務器繼續不間斷的提供服務，從而達到資源以及服務高可用的目的。

 以 上的描述heartbeat的主備模式，heartbeat還支持主主模式，即兩臺服務器互爲主備，這是他們之間還會互相發送報文來告訴對方本身的當前的 狀態，若是在指定的時間內未收到對方發送的心跳報文，那麼，一方就會認爲對方失效或者是已宕機了，這時每一個運行正常的主機就會啓動自身的資源接管模塊來接管運行在對方主機上的資源或者是服務，繼續爲用戶提供服務。通常狀況下，能夠較好的實現一臺主機故障後，企業業務可以不間斷的持續的提供服務。注意：所謂 的業務不間斷，在故障轉移期間也是須要切換時間的，heartbeat的切換時間是5-20秒。

切換的常見條件：1）服務器宕機  2）Heartbeat服務本故障  3）中間的鏈接線路故障

應用服務故障則不會產生切換，能夠經過服務宕機把heartbeat服務停掉。

ldirectord是heartbeat中的一部分，當咱們安裝了heartbeat就帶了ldirectord（1）heartbeat最核心的包括兩個部分，心跳監測部分和資源接管部分，心跳監測能夠經過網絡鏈路和串口進行，並且支持冗餘鏈路，它們之間相互發送報文來告訴對方本身當前的狀態，若是在指定的時間內未收到對方發送的報文，那麼就認爲對方失效，這時需啓動資源接管模塊來接管運行在對方主機上的資源或者服務。

  Heartbeat僅僅是個HA軟件，它僅能完成心跳監控和資源接管，不會監視它控制的資源或應用程序。要監控資源和應用程序是否運行正常，必須使用第三方的插件，例如ipfail、Ldirector等 

 Ldirector是一個監控集羣服務節點運行狀態的插件。Ldirector若是監控到集羣節點中某個服務出現故障，就屏蔽此節點的對外鏈接功能，同時將後續請求轉移到正常的節點提供服務。這個插件常常用在LVS負載均衡集羣中。

 Ldirector自動檢測後臺Realserver的運行情況，並採起響應的措施。

  （2）HeartBeat 運行於備用主機上的Heartbeat能夠經過以太網鏈接檢測主服務器的運行狀態，一旦其沒法檢測到主服務器的"心跳"則自動接管主服務器的資源。一般情 況下，主、備服務器間的心跳鏈接是一個獨立的物理鏈接，這個鏈接能夠是串行線纜、一個由"交叉線"實現的以太網鏈接。Heartbeat甚至可同時經過多 個物理鏈接檢測主服務器的工做狀態，而其只要能經過其中一個鏈接收到主服務器處於活動狀態的信息，就會認爲主服務器處於正常狀態。從實踐經驗的角度來講，建議爲Heartbeat配置多條獨立的物理鏈接，以免Heartbeat通訊線路自己存在單點故障。

一、串行電纜：被認爲是比以太網鏈接安全性稍好些的鏈接方式，由於hacker沒法經過串行鏈接運行諸如telnet、ssh或rsh類的程序，從而能夠下降其經過已劫持的服務器再次侵入備份服務器的概率。但串行線纜受限於可用長度，所以主、備服務器的距離必須很是短。

二、以太網鏈接：使用此方式能夠消除串行線纜的在長度方面限制，而且能夠經過此鏈接在主備服務器間同步文件系統，從而減小了從正常通訊鏈接帶寬的佔用。

基 於冗餘的角度考慮，應該在主、備服務器使用兩個物理鏈接傳輸heartbeat的控制信息；這樣能夠避免在一個網絡或線纜故障時致使兩個節點同時認爲自已經是惟一處於活動狀態的服務器從而出現爭用資源的狀況，這種爭用資源的場景便是所謂的"腦裂"（split-brain）或"partitionedcluster"。在兩個節點共享同一個物理設備資源的狀況下，腦裂會產生至關可怕的後果。

爲了不出現腦裂，可採用下面的預防措施：

一、如前所述，在主、備節點間創建一個冗餘的、可靠的物理鏈接來同時傳送控制信息；

二、一旦發生腦裂時，藉助額外設備強制性地關閉其中一個節點；

第 二種方式便是俗稱的"將其它節點'爆頭'（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爲每一個數據包進行簽名以確保傳輸中的控制信息的安全性。

heartbeat的心跳鏈接：

要部署heartbeat服務，至少須要兩臺主機才能完成。那麼，要實現高可用服務，這兩臺主機之間，是如何作到互相通訊互相監控的呢/

下面是兩臺heartbeat主機之間通訊的一些經常使用的可行的方法：

1）串行電纜，即所謂的串口（首選，缺點是距離不能太遠）

2）一根以太網電纜量網口直連（生產環境中經常使用的方式）

3）以太網電纜，經過交換機等網絡設備鏈接

（次選，緣由是增長了故障點，很差排查故障，同時，線路不是專用的心跳線，容易受其餘數據傳輸的影響，致使心跳報文發送問題）

Heartbeat裂腦：  什麼是裂腦？

由 於兩臺高可用服務器之間在指定的時間內，沒法互相檢測到對方心跳而各自啓動故障轉移功能，取得了資源以及服務的全部權，而此時的兩臺高可用服務器對都還活着並做正常運行，這樣就會致使同一個IP湖綜合服務在兩端同時啓動而發生衝突的嚴重問題，最嚴重的就是兩臺主機同時佔用一個VIP的地址，當用戶寫 入數據的時候可能會分別寫入到兩端，這樣可能會致使服務器兩端的數據不一致或形成數據的丟失，這種狀況就本成爲裂腦，也有的人稱之爲分區集羣或者大腦垂直分隔

致使裂腦發生的緣由：

通常來講，裂腦的發生，主要是由如下的幾個緣由致使的：

1）高可用服務器對 之間心跳線路故障，致使沒法正常的通訊。緣由好比：

  （1）心跳線自己就壞了（包括斷了，老化）

  (2）網卡以及相關驅動壞了,IP配置及衝突問題

  （3）心跳線間鏈接的設備故障（交換機的故障或者是網卡的故障）

  （4）仲裁的服務器出現問題

2）高可用服務器對上開啓了防火牆阻擋了心跳消息的傳輸

3）高可用服務器對上的心跳網卡地址等信息配置的不正確，致使發送心跳失敗。

4）其餘服務配置不當等緣由，如心跳的方式不一樣，心跳廣播衝突，軟件出現了BUG等

防止腦裂發生的方法總結：

  發生腦裂的時候，對業務的影響是及其嚴重的，有時甚至致命。

如： 兩臺高可用的服務器對之間發生腦裂，致使互相競爭同一個IP資源，就如同咱們局域網內常見的IP地址衝突同樣，兩個機器就會有一個或者兩個不正常，影響用戶正常訪問服務器。若是是應用在數據庫或者是存儲服務這種極重要的高可用上，那就致使用戶發佈的數據間斷的寫在兩臺服務器上的惡果，最終數據恢復困難或者 是難已恢復。

實際的生產環境中，咱們能夠從如下幾個方面來防止裂腦的發生：

1）同時使用串行電纜和以太網電纜鏈接，同時用兩條心跳線路，這樣一條線路壞了，另外一個線路仍是好的，依然能傳送消息（推薦的）

2）檢測到裂腦的時候強行關閉一個心跳節點（須要特殊的節點支持，如stonith，fence），至關於程序上備節點發現心跳線故障，發送關機命令到主節點。

3）作好對裂腦的監控報警（如郵件以及手機短信等），在問題發生的時候可以人爲的介入到仲裁，下降損失。固然，在實施高可用方案的時候，要根據業務的實際需求肯定是否可以容忍這樣的損失。對於通常的網站業務，這個損失是可控的（公司使用）。

4） 啓用磁盤鎖。正在服務一方鎖住共享磁盤，腦裂發生的時候，讓對方徹底搶不走共享的磁盤資源。但使用鎖磁盤也會有一個不小的問題，若是佔用共享盤的一方不主動解鎖，另外一方就永遠得不到共享磁盤。若服務節點忽然死機或者崩潰，另外一方就永遠不可能執行解鎖命令。後備節點也就接管不了共享的資源和應用服務。因而有 人在HA中涉及了「智能」鎖，正在服務的一方只在發現心跳線所有斷開時才啓用磁盤鎖，平時就不上鎖了。

5）報警報在服務器接管以前，給人員處理留足夠的時間就是1分鐘內報警了，可是服務器不接管，而是5分鐘以後接管，接管的時間較長。

數據不會丟失，但就是會致使用戶沒法寫數據。

6）報警後，不直接自動服務器接管，而是由人員接管。

7）增長仲裁的機制，肯定誰該得到資源，這裏面有幾個參考的思路：

 （1）增長一個仲裁機制。例如設置參考的IP，小心跳徹底斷開的時候，2個節點各自都ping一下參考的IP，不一樣則代表斷點就出如今本段，這樣就主動放棄競爭，讓可以ping通參考IP的一端去接管服務。

 （2）經過第三方軟件仲裁誰該得到資源，這個在阿里有相似的軟件應用。

3、Ldirectord

  Ldirector是一個監控集羣服務節點運行狀態的插件。Ldirector若是監控到集羣節點中某個服務出現故障，就屏蔽此節點的對外鏈接功能，同時將後續請求轉移到正常的節點提供服務。這個插件常常用在LVS負載均衡集羣中。

 Ldirector自動檢測後臺Realserver的運行情況，並採起響應的措施。

 

 ldirectord守護進程經過向每臺real server ip(RIP)上的集羣資源發送訪問請求來實現對真實服務器的監控，這對全部類型的LVS集羣都是成立的：LVS-DR  LVS-NAT LVS-TUN

正常狀況下，爲每一個Director上的VIP地址運行一個ldirectord守護進程，當真實服務器不響應運行在Director上的 ldirectord守護進程時，ldirectord守護進程運行適當的ipvsadm命令將VIP地址從IPVS表中移除。(之後，當真實服務器回到在線狀態時，ldirectord使用適當的ipvsadm命令將真實服務器從新添加到IPVS表中 )

 爲了監視web集羣內的真實服務器，ldirectord守護進程使用HTTP協議向每一個真實服務器請求一個專用的web頁面，若真實服務器是健康 的，Director知道將從真實服務器接收到什麼內容，若真實服務器返回應答字串或者web頁面的時間太長，或根本沒有返回任何內容，或返回的內容不是 預期的，Director就知道該真實服務器出錯了，並從IPVS表中將這個真實服務器移除。 
   ldirectord工做原理：ldirtctord將鏈接到每個真正的服務器，每隔一段時間就請求測試網頁文件，若是返回的內容和測試的內容不匹配，則代表測試失敗，則真實服務器將從Ipvs表中被刪除。若再次測試時，成功，則將real server從新添加到ipvs表中。