Nginx實現負載均衡 + Keepalived實現Nginx的高可用

時間  2019-12-02
標籤 nginx 實現 負載 均衡 keepalived 可用 欄目 Nginx 简体版
原文   原文鏈接

前言

　　使用集羣是大中型網站解決高併發、海量數據問題的經常使用手段。當一臺服務器的處理能力、存儲空間不足時，不要企圖去換更強大的服務器，對大型網站而言，無論多麼強大的服務器，都知足不了網站持續增加的業務需求和用戶量。這種狀況下，更恰當的作法是增長一臺或多臺服務器去分擔原有服務器的訪問及存儲壓力。經過負載均衡調度服務器，未來自瀏覽器的訪問請求分發到應用服務器集羣中的任何一臺服務器上，若是有更多的用戶，就在集羣中加入更多的應用服務器，使應用服務器的負載壓力再也不成爲整個網站的瓶頸。javascript

環境準備

　　192.168.0.221：nginx + keepalived   master  (主)css

　　192.168.0.222：nginx + keepalived   backup  slave (從)html

　　192.168.0.223：tomcat前端

　　192.168.0.224：tomcatjava

　　虛擬ip(VIP):192.168.0.200，對外提供服務的ip，也可稱做浮動ipnode

　　各個組件之間的關係圖以下：linux

                                         

Tomcat作應用服務器

　　tomcat的安裝不在本博客範圍以內，具體例子網上不少在此就不講解，tomcat的webapps下記得放本身的應用，個人是myWeb，若是你們也用個人myWeb，那麼index.jsp中的ip須要換成本身的nginx

　　將192.168.0.22三、192.168.0.224上的tomcat啓動起來，tomcat的路徑可能和個人不一致，須要寫成本身的web

　　# cd /usr/local/tomcat7/bin算法

　　# ./startup.sh

　　訪問myWeb以下

Nginx作負載均衡

　　nginx的安裝，本文就不講述了，具體可參考LVS + keepalived + nginx + tomcat 實現主從熱備 + 負載均衡

　     一、在任意一臺虛擬機上所安裝的nginx的nginx.conf配置文件中配置upstream以下：

user  root;            #運行用戶
worker_processes  1;        #啓動進程,一般設置成和cpu的數量相等

#全局錯誤日誌及PID文件
error_log  /usr/local/nginx/logs/error.log;
error_log  /usr/local/nginx/logs/error.log  notice;
error_log  /usr/local/nginx/logs/error.log  info;
pid        /usr/local/nginx/logs/nginx.pid;

# 工做模式及鏈接數上線
events 
{
    use epoll;            #epoll是多路複用IO(I/O Multiplexing)中的一種方式,可是僅用於linux2.6以上內核,能夠大大提升nginx的性能

    worker_connections  1024;    #單個後臺worker process進程的最大併發連接數
}

#設定http服務器,利用它的反向代理功能提供負載均衡支持
http 
{
    include       mime.types;
    default_type  application/octet-stream;

    #設定請求緩衝
    server_names_hash_bucket_size  128;
    client_header_buffer_size   32K;
    large_client_header_buffers  4 32k;
    # client_max_body_size   8m;
    
    #sendfile 指令指定 nginx 是否調用 sendfile 函數（zero copy 方式）來輸出文件，對於普通應用，
    #必須設爲 on,若是用來進行下載等應用磁盤IO重負載應用，可設置爲 off，以平衡磁盤與網絡I/O處理速度，下降系統的uptime.
    sendfile        on;
    tcp_nopush     on;
    tcp_nodelay    on;

    #鏈接超時時間
    keepalive_timeout  65;

    #開啓gzip壓縮，下降傳輸流量
    gzip  on;
    gzip_min_length    1k;
    gzip_buffers    4 16k;
    gzip_http_version  1.1;
    gzip_comp_level  2;
    gzip_types  text/plain application/x-javascript text/css  application/xml;
    gzip_vary on;

    #添加tomcat列表，真實應用服務器都放在這
    upstream tomcat_pool 
    {
       #server tomcat地址:端口號 
　　　　server 192.168.0.223:8080  max_fails=2 fail_timeout=30s;
    　 server 192.168.0.224:8080  max_fails=2 fail_timeout=30s;

    }

    server 
    {
        listen       80;        #監聽端口    
        server_name  localhost;
    
    #默認請求設置
    location / {
        proxy_pass http://tomcat_pool;    #轉向tomcat處理
    }
    
    #全部的jsp頁面均由tomcat處理
    location ~ \.(jsp|jspx|dp)?$
    {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://tomcat_pool;    #轉向tomcat處理
    }
    
    #全部的靜態文件直接讀取不通過tomcat,nginx本身處理
    location ~ .*\.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|pdf|xls|mp3|wma)$ 
    { 
        expires  30d;
    }
    location ~ .*\.(js|css)?$
    {
       expires  1h;
    }

    #定義錯誤提示頁面
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

    }
}

　以上是負載均衡的基本配置，當前模式採用的是輪詢的方式負載。除了輪詢，還有weight（權重）、ip_hash（根據訪

問ip，解決session問題）、第三方。

     二、根據weight負載

     upstream blog {
        server 192.168.28.128:8081 weight=2;
        server 192.168.28.129:8081 weight=1;
    }

     說明：以上配置表示三次訪問的時候weight=2的服務被訪問兩次，weight=1的服務只被訪問一次。weight表示權值，權值越大，被分配的概率越大;

   

   三、根據ip_hash負載

     upstream blog {
        ip_hash;
        server 192.168.28.128:8081;
        server 192.168.28.129:8081;
    }
    說明：用戶第一次訪問落在128上，那麼之後該用戶的訪問都會在128的服務器上，如此便可解決session問題。

     四、fair第三方

這種方式是按後端服務的響應時間來分配請求，相應時間短的優先分配。

  upstream blog {
        server 192.168.28.128:8081;
        server 192.168.28.129:8081;

        fair;
    }

   五、url_hash第三方

這種方式是按url的hash結果來分配請求，使沒一個url請求定向到同一個後端服務器。也可解決session問題，但需

要注意，使用這種方式後，server語句中不能寫入weight等其餘參數。

  upstream blog {
        server 192.168.28.128:8081;
        server 192.168.28.129:8081;

        hash $request_uri;

        hash_method crc32;  #使用crc32 hash算法
    }

 

主機和從機的nginx的配置文件徹底同樣，nginx.conf配置可複雜可簡單，你們根據本身的狀況自行配置，照搬上述配置也是能夠的。

　　配置好後，啓動nginx，路徑要寫本身的

　　# cd /usr/local/nginx/sbin

　　# ./nginx

　　訪問nginx，效果以下：

兩臺nginx服務器服務正常，此時是沒有主從之分的，二者級別同樣高，當配置keepalived以後就有了主從之分了。

 

keepalived實現nginx高可用(HA)

　　keepalived的安裝本文就不講述了，具體可參考主從熱備+負載均衡（LVS + keepalived）

　　keepalived做用其實在第一張圖中已經有所體現，主要起到兩個做用：實現VIP到本地ip的映射； 以及檢測nginx狀態。　　

  簡介

        Keepalived的做用是檢測服務器的狀態，若是有一臺web服務器宕機，或工做出現故障，Keepalived將檢測到，並將有故障的服務器從系統中剔除，同時使用其餘服務器代替該服務器的工做，當服務器工做正常後Keepalived自動將服務器加入到服務器羣中，這些工做所有自動完成，不須要人工干涉，須要人工作的只是修復故障的服務器。
   

  工做原理

        Layer3,4,5工做在IP/TCP協議棧的IP層，TCP層，及應用層,原理分別以下：
        Layer3：Keepalived使用Layer3的方式工做式時，Keepalived會按期向服務器羣中的服務器發送一個ICMP的數據包（既咱們平時用的Ping程序）,若是發現某臺服務的IP地址沒有激活，Keepalived便報告這臺服務器失效，並將它從服務器羣中剔除，這種狀況的典型例子是某臺服務器被 非法關機。Layer3的方式是以服務器的IP地址是否有效做爲服務器工做正常與否的標準。
       Layer4:若是您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP端口的狀態來決定服務器工做正常與否。如web server的服務端口通常是80，若是Keepalived檢測到80端口沒有啓動，則Keepalived將把這臺服務器從服務器羣中剔除。
       Layer5：Layer5對指定的URL執行HTTP GET。而後使用MD5算法對HTTP GET結果進行求和。若是這個總數與預期值不符，那麼測試是錯誤的，服務器將從服務器池中移除。該模塊對同一服務實施多URL獲取檢查。若是您使用承載多個應用程序服務器的服務器，則此功能頗有用。此功能使您可以檢查應用程序服務器是否正常工做。MD5摘要是使用genhash實用程序（包含在keepalived軟件包中）生成的。
       SSL_GET與HTTP_GET相同，但使用SSL鏈接到遠程Web服務器。
       MISC_CHECK：此檢查容許用戶定義的腳本做爲運行情況檢查程序運行。結果必須是0或1.該腳本在導演盒上運行，這是測試內部應用程序的理想方式。可使用完整路徑（即/path_to_script/script.sh）調用能夠不帶參數運行的腳本。那些須要參數的須要用雙引號括起來（即「/path_to_scrip t/script.sh arg 1 ... arg n」）

 

     master上的keepalived.conf內容以下：

global_defs {
    notification_email {
        997914490@qq.com
    }
    notification_email_from sns-lvs@gmail.com
    smtp_server smtp.hysec.com
    smtp_connection_timeout 30
    router_id nginx_master        # 設置nginx master的id，在一個網絡應該是惟一的
}
vrrp_script chk_http_port {
    script "/usr/local/src/check_nginx_pid.sh"    #最後手動執行下此腳本，以確保此腳本可以正常執行
    interval 2                          #（檢測腳本執行的間隔，單位是秒）
    weight 2
}
vrrp_instance VI_1 {
    state MASTER            # 指定keepalived的角色，MASTER爲主，BACKUP爲備
    interface eth0            # 當前進行vrrp通信的網絡接口卡(當前centos的網卡)
    virtual_router_id 66        # 虛擬路由編號，主從要一直
    priority 100            # 優先級，數值越大，獲取處理請求的優先級越高
    advert_int 1            # 檢查間隔，默認爲1s(vrrp組播週期秒數)
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    track_script {
    chk_http_port            #（調用檢測腳本）
    }
    virtual_ipaddress {
        192.168.0.200            # 定義虛擬ip(VIP)，可多設，每行一個
    }
}

  backup上的keepalived.conf內容以下：

global_defs {
    notification_email {
        997914490@qq.com
    }
    notification_email_from sns-lvs@gmail.com
    smtp_server smtp.hysec.com
    smtp_connection_timeout 30
    router_id nginx_backup              # 設置nginx backup的id，在一個網絡應該是惟一的
}
vrrp_script chk_http_port {
    script "/usr/local/src/check_nginx_pid.sh"
    interval 2                          #（檢測腳本執行的間隔）
    weight 2
}
vrrp_instance VI_1 {
    state BACKUP                        # 指定keepalived的角色，MASTER爲主，BACKUP爲備
    interface eth0                      # 當前進行vrrp通信的網絡接口卡(當前centos的網卡)
    virtual_router_id 66                # 虛擬路由編號，主從要一直
    priority 99                         # 優先級，數值越大，獲取處理請求的優先級越高
    advert_int 1                        # 檢查間隔，默認爲1s(vrrp組播週期秒數)
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    track_script {
        chk_http_port                   #（調用檢測腳本）
    }
    virtual_ipaddress {
        192.168.0.200                   # 定義虛擬ip(VIP)，可多設，每行一個
    }
}

　　nginx檢測腳本check_nginx_pid.sh內容以下：

#!/bin/bash
A=`ps -C nginx --no-header |wc -l`        
if [ $A -eq 0 ];then                            
    /usr/local/nginx/sbin/nginx                #重啓nginx
    if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then    #nginx重啓失敗
        exit 1
    else
        exit 0
    fi
else
    exit 0
fi

啓動keepalived

　　# service keepalived start

　　訪問VIP，效果以下：

咱們來看下keepalived的日誌信息

　　　　master（192.168.0.221）：

   backup的（192.168.0.222）：

當咱們把master上的keepalived停掉（模擬宕機），再來看下keepalived日誌

　　　　原master（192.168.0.221）：

      原backup（192.168.0.222）：

經過VIP能夠正常訪問服務，前端請求感覺不到後端nginx的切換；從新喚醒原master（192.168.0.221）的測試這裏就不進行了，你們自行測試

注意點

　　一、執行腳本時報錯：/bin/sh^M: bad interpreter: 沒有那個文件或目錄 

　　　  由於操做系統是windows，我在windows下編輯的腳本，因此有可能有不可見字符。腳本文件是DOS格式的, 即每一行的行尾以回車符和換行符來標識, 其ASCII碼分別是0x0D, 0x0A。能夠有不少種辦法看這個文件是DOS格式的仍是UNIX格式的, 仍是MAC格式的

         解決方法：

　　　　　　vim filename

　　　　　　:set ff? #能夠看到dos或unix的字樣. 若是的確是dos格式的。

　　　　　　:set ff=unix #把它強制爲unix格式的, 而後存盤退出。

　　　　　　再次運行腳本。

　　　　從windows編輯文件再拷貝到linux時要特別注意，另外，腳本須要賦予可執行權限才能執行，可執行文件的一種直觀表現就是文件自己呈綠色。

     

         二、負載均衡最好進行多瀏覽器測試，有些瀏覽器會緩存，會產生沒有負載均衡的效果，例如我此次測試中谷歌瀏覽器就出現了相似的狀況(還沒搞清楚是不是緩存的緣由)，火狐，360、IE瀏覽器都是正常的負載均衡效果。

　　三、請求走向

　　　　訪問虛擬IP(VIP)，keepalived將請求映射到本地nginx，nginx將請求轉發至tomcat，例如：http://192.168.0.200/myWeb/，被映射成http://192.168.0.221/myWeb/，端口是80，而221上nginx的端口正好是80；映射到nginx上後，nginx再進行請求的轉發。

　　　　keepalived服務器的ip狀況    

             

              VIP總會在keepalived服務器中的某一臺上，也只會在其中的某一臺上；VIP綁定的服務器上的nginx就是master，當VIP所在的服務器宕機了，keepalived會將VIP轉移到backup上，並將backup提高爲master。

　　四、VIP也稱浮動ip，是公網ip，與域名進行映射，對外提供服務； 其餘ip通常而言都是內網ip， 外部是直接訪問不了的。

     部分轉載學習自:http://www.javashuo.com/article/p-tvndjcey-u.html

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程