埠監測

   nmap  命令進行測試
    需要裝包 nmap
    可以進行檢測具體的IP的某個埠
nmap -sS -n -p 埠 檢測的主機IP | grep open
[ $? -eq 0 ] && echo  埠開放  ||  echo 埠未開放

HA 高可用叢集

    軟體名：keepalived
    服務： keepalived
    主配置檔案：/etc/keepalived/keepalived.conf(可以在進行配置修改前做個備份)

  keepalived可以做兩種高可用叢集，一個是就單個服務解決單點故障問題的高可用，另一個是結合LVS實現分發器的高可用(起初設計keepalived的目的)

   1. 對於普通服務的高可用，也就是在已經搭建了具體服務的伺服器上進行操作
      先是裝包、再配置、最後啟服務
      對於配置就是修改配置檔案，主要修改裡面的：
       global_defs 全域性配置(主要是登出一個設定)
       vrrp_instance  具體服務配置
              --  修改HA伺服器名
              --  修改是 主、輔 伺服器
              --  修改優先順序
              --  修改密碼
              --  修改VIP
         刪除後面所有無用的配置

   2. 對於 Keepalived + LVS 服務的配置
      首先要安裝包兩個服務的包都要安裝 Keepalived 和 ipvsadm ，如果之前有做過LVS服務需要清除其中的所有配置和策略。
      然後進行配置，還是要先進行和為普通服務配置高可用一樣的操作，再在進行一些特殊配置代替ipvsadm命令的操作，實現讓 keepalived 根據具體情況具體配置
      最後啟動服務(如果設定開機自啟動需要把ipvsadm也開啟，不過啟動服務的時候只需要啟動keepalived)
       virtual_server  具體的ipvsadm的規則
              --  修改排程演算法
              --  修改工作模式
              --  修改各個真實伺服器的RIP、權重
              --  開啟健康性檢查，如果真實伺服器出現問題就自動將其移除，如果恢復了自動加回

     對於配置檔案詳細解釋(有！結尾的是必須修改的部分內容)

! Configuration File for keepalived

global_defs {
   notification_email {
     [email protected]                   //設定報警收件人郵箱
   }
   notification_email_from [email protected]  //設定發件人的具體資訊
   smtp_server 127.0.0.1                   //定義郵件伺服器
   smtp_connect_timeout 30
   router_id LVS_DEVEL                //設定路由ID號
   vrrp_skip_check_adv_addr
 # vrrp_strict                    //必須將其註釋 ！
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance HA伺服器名字 {                //名字
  state MASTER                         //主伺服器為MASTER、輔伺服器為BACKUP ！
  interface eth0                    //定義網路介面
  virtual_router_id 50                //主輔VRID號必須一致
  priority 100                     //伺服器優先順序,優先順序高優先獲取VIP ！
  advert_int 1                    //每多少秒檢視一次
  authentication {
    auth_type pass
    auth_pass 密碼                       //主輔伺服器密碼必須一致 ！
  }
  virtual_ipaddress { 預備定義的VIP  }    //誰是主伺服器誰獲得該VIP ！
}

virtual_server 預備定義的VIP 埠 {       //設定ipvsadm的VIP規則 ！
  delay_loop 6
  lb_algo wrr                          //設定LVS排程演算法為WRR ！
  lb_kind DR                           //設定LVS的模式為DR ！
  persistence_timeout 50              //多長時間內同一個客戶的訪問，將分發給同一個伺服器，可以註釋掉關閉該功能
  protocol TCP

  real_server 真實伺服器的RIP1 埠 {          //設定後端web1伺服器真實IP ！
    weight 權重值                                 //設定權重 ！
    TCP_CHECK {                    //對後端web2伺服器的TCP協議進行檢查，如果其相關服務如HTTP出問題了，就會自動刪除相關的ipvs的配置，如果伺服器重新可用了就會再新增到ipvs配置中
    connect_timeout 3
    nb_get_retry 3
    delay_before_retry 3
    }
  }
  real_server 真實伺服器的RIP2 埠 {          //設定後端web2伺服器真實IP ！
    weight 權重值                                 //設定權重 ！
    TCP_CHECK {                    //對後端web2伺服器的TCP協議進行檢查，如果其相關服務如HTTP出問題了，就會自動刪除相關的ipvs的配置，如果伺服器重新可用了就會再新增到ipvs配置中
    connect_timeout 3
    nb_get_retry 3
    delay_before_retry 3
    }
  }
}

注：
   1. 如果先開啟的是輔伺服器，那時候還沒開主伺服器，輔伺服器並不會立刻獲得vip 進行工作，需要等待一段時間，原因是他要反覆確認主伺服器不可用，不過也有可能。
   2. 每個關鍵字間，與大括號間都是有空格的
   3. 做 Keepalived + LVS 服務的時候需要安裝ipvsadm，設定開機自啟動的時候，ipvsadm也需要開啟
   4. 做一些服務的HA高可用的時候，比如HTTP等，如果整個主伺服器down機了，那麼輔伺服器的keepalived就會起作用，搶奪服務，這樣保證服務的穩定，可是如果主伺服器的核心服務突然出現出問題掛了的時候，keepalived就不會轉移服務，這時候需要寫指令碼,結合nmap檢測來實現，基本演算法就算nmap發現某個服務掛了就把自己的keepalived關閉，這樣服務就會被輔伺服器取走從而繼續提供服務
      但是對於lvs服務的高可用的時候不需要，因為只需要配置中開啟檢測 keepalived 就會自動完成該功能

HTTP的協議模型

  1. HTTP close 一次連線一個請求，依次訪問
       客戶端傳送請求建立連線，然後服務端迴應請求後斷開連線
       適用於： 網頁資訊完整性高，安全性高的網頁，每個資料都要認真傳遞，丟包率低
       缺點： 每次服務端只會響應一次請求，每次請求都要消耗資源建立TCP三次握手，導致延遲較大

  2. Keep-alive 一次連線多個請求，依次迴應
       客戶端傳送請求建立連線，然後服務端迴應請求，然後客戶端可以繼續傳送請求，服務端繼續迴應，直到客戶端請求斷開
       適用於： 一般網頁資料的傳遞
       缺點： 服務端必須讓客戶端知道傳輸資料的長度以避免無限期的等待，一個一個請求處理，效率不高

  3. Pipelining 一次連線多次請求，同步迴應
       客戶端傳送請求建立連線，然後客戶端可以傳送多個請求，服務端多執行緒同步回覆資料
       適用於： 大量圖片視訊的網頁，效率極高，延遲低
       缺點： 安全性不如前面，丟包率也相對略高

HAProxy

    LVS是基於埠的LB負載均衡服務，如果像HTTP他具體域名想給不同的伺服器負責，那LVS是不能實現的，這時候就要用HAProxy來實現基於uri的負載均衡
    url 是網路地址，也就是從協議http開始，裡面有域名，還有具體訪問的檔案所在網路位置，
    uri 是資源位置，一般在web網頁名中指的就是域名後面新增的網頁檔案所在的位置，不過和url關係比較複雜，就不細說了。

   搭建HAProxy的步驟：裝包配置起服務
   裝包 yum install haproxy
   修改配置檔案：/etc/haproxy/haproxy.cfg
   啟動服務：systemctl restart haproxy

   有三個工作模式
       mode http    客戶端被深度分析後發給伺服器
       mode tcp     客戶端和伺服器建立對話，不檢查第七層協議
       mode health  只做健康狀態檢查

配置檔案組成
    default  後面所有部分沒有設定的引數就用這個預設的引數
    frontend 根據接受客戶端的資料包進行分類處理
    backed  根據連線的後端伺服器，進行分類部署
    listen   吧fronted的基本配置和backed結合起來配置

配置檔案內容的詳細解釋：

global                # 採用全域性配置
 log 127.0.0.1 local2
 chroot /usr/local/haproxy
 pidfile /var/run/haproxy.pid        # 記錄haproxy程序的pid資訊的檔案存放路徑
 maxconn 4000            # 最大連線數，預設4000
 user haproxy
 group haproxy
 daemon               # 建立1個程序進入deamon模式執行

defaults                # 預設配置引數，當下面沒有具體配置的時候所有配置引數的預設引數
 mode http            # 預設的模式mode { tcp|http|health } 
 log global             # 採用全域性定義的日誌
 option dontlognull      # 不記錄健康檢查的日誌資訊
 option httpclose        # 每次請求完畢後主動關閉http通道
 option httplog           # 日誌類別http日誌格式
 option forwardfor      # 後端伺服器可以從Http Header中獲得客戶端ip
 option redispatch      # serverid伺服器掛掉後強制定向到其他健康伺服器
 timeout connect 10000              # 如果backend沒有指定，預設為10s
 timeout client 300000               # 客戶端連線超時時間
 timeout server 300000              # 伺服器連線超時
 maxconn  60000              # 最大連線數
 retries  3              # 3次連線失敗就認為服務不可用，也可以通過後面設定

 stats refresh 5s             # 統計頁面自動重新整理時間
 stats uri /網路路徑              # 自定義統計頁面的uri
# 例如： stats uri /status       客戶端訪問 http://域名/status 就可以檢視叢集狀態

# 建立負載均衡服務
listen  weblb  172.25.10.100:80     # 分發服務，建立一個叫weblb的叢集，對客戶端開放訪問的VIP是172.25.10.100，埠是80
    cookie  SERVERID rewrite        # 設定cookie-session服務
    balance roundrobin            # 指定負載均衡演算法
    server  web1 172.25.10.110:80 cookie cook1 check inter 2000 rise 2 fall 5
    server  web2 172.25.10.120:80 cookie cook2 check inter 2000 rise 2 fall 5
   # 上面是配置server的真實伺服器，配置了兩個真實web伺服器名字分別為web1，web2，後面就是真實伺服器的RIP，設定了cookie名，然後每2000ms連線一次，如果出現失敗後，就每2ms連線一次，連續連線5次失敗就預設該裝置有問題，就不傳送請求給他了，然後還是每2000ms連線一次，如果某個時候連上了，就再恢復其服務。

# 基於uri進行負載均衡配置的接受資料端配置，建立網路地址分組
frontend  netlb  192.168.10.100:80    # 建立一個叫netlb的叢集，對客戶端開放訪問的VIP是192.168.10.100，埠是80
    acl url_boy       path_beg    -i /boy        # 客戶輸入的網路地址是/boy開頭的所有請求放入自定義名為url_boy組中
    acl url_girl      path_beg    -i /girl

    acl url_html     path_end    -i .html        # 客戶輸入的網路地址是.html開頭的所有請求放入自定義名為url_html組中
    acl url_php      path_end    -i .php

    use_backend   htmlgrp     if url_html        # url_html組的請求轉發給 htmlgrp的真實伺服器組中的伺服器
    use_backend   phpgrp      if url_php
    use_backend   boygrp      if url_boy
    use_backend   girlgrp      if url_girl    

    default_backend      htmlgrp        # 當用戶輸入的uri特點不滿足上面任意一個uri組，就預設發給htmlgrp伺服器組內所有的伺服器，然後把完整的uri發給這些伺服器，如果伺服器中沒有網頁就不會返回，HAProxy只是做一個轉發

# 基於uri進行負載均衡配置的傳送資料端配置，建立真實伺服器組
backend htmlgrp        # 建立一個名為htmlgrp的真實伺服器組，上面宣告的每個真實伺服器組都要建立            
    balance     roundrobin    # 分佈演算法
    server   weba  192.168.10.110:80 check        # 把真實伺服器的RIP為192.168.10.110的80埠加入htmlgrp真實伺服器組
    server   webb  192.168.10.111:80 check

總結：

   1. 排程伺服器只是把請求進行分發，不過也沒有資料返回取決於後端真實伺服器，他有相應的資料就有返回，如果沒有，那就沒有，如果客戶端訪問的時候不是一個具體的檔案，那請求轉發後，網站伺服器能響應就可以返回，不能就不會響應

   2. 如果想做個簡單的負載均衡，就直接寫一個listen即可，如果想做基於uri等按照職能需求區分的負載均衡就需要分別編輯frontend(把接受的資料包分類)、backend(把後端伺服器進行分類)

  用HAProxy做基於uri的LB負載均衡服務

    0.準備網站伺服器(web主機，不過負載均衡叢集中會有很多web主機，每個主機都要做一樣的部署)，LB排程器(haproxy)

       0.1 裝包(apache軟體包、資料庫軟體包、php解析軟體包、php連線資料庫軟體包)

[[email protected] ~]# yum install httpd mariadb-server php php-mysql

       0.2 啟動服務

[[email protected] ~]# for i in httpd mariadb
do
systemctl restart $i
systemctl enable $i
done

       0.3. 測試web服務的html和php解析情況(編寫一個html檔案和php檔案，讓客戶端訪問一下即可)

[[email protected] ~]# echo "$HOSTNAME" > /var/www/html/test.html
[[email protected] ~]# echo '<?php
$x=mysql_connect("localhost","root","資料庫root密碼(剛剛建立的資料庫root密碼是空，這引號內什麼都不寫即可)");
if ($x) {echo "'$HOSTNAME' mariab OK";} else {echo "'$HOSTNAME' mariab error";}
' > /var/www/html/test.php

    1. 搭建haproxy伺服器
       1.1 安裝軟體包haproxy

[[email protected] ~]# yum install -y haproxy

       1.2 修改配置檔案/etc/haproxy/haproxy.cfg(配置如上，如果要動靜分離就根據uri的結尾來分，如果做基於功能模組的負載均衡就按照uri開頭分)

       1.3 啟動服務

[[email protected] ~]# systemctl restart haproxy

    2. 客戶端訪問測試

對比Nginx、LVS、HAProxy的負載均衡作用的區別

Nginx
   用來做HTPP的web服務的情況最多

  優點：
    1. 不單單可以做LB，還可以HA高可用叢集，也可以做web服務
    2. 支援拓展正則，可以根據業務需求做調整，可以做動靜結合
    3. 可以支援極高的併發量
  缺點：
    1. 只支援http協議
    2. 監控檢查只能通過埠
    3. 效率和負載最低

LVS
   LVS/DR 作為LB負載均衡中，用的最多的叢集結構

  優點：
    1. 負載能力強，效率最高
    2. 應用面廣，幾乎可以用在所有應用提供負載均衡
  缺點：
    1. 本身不能做健康檢查，但是可以配合keepalived
    2. 只能記錄埠的，不能做動靜分離等
    3. 如果架構龐大，LVS/DR配置會很繁瑣

HAProxy
    通常作為web網站的負載均衡服務
  優點：
    1. 支援cookie、session功能
    2. 有友好的檢查伺服器健康性的功能
    3. 可以根據業務需求做區分，效率和負載中等
    4. 支援TCP，可以對資料庫做負載
  缺點：
    1. 不支援拓展正則，匹配能力不強，只能勉強做點區分
    2. 不支援apache日誌