精华内容
下载资源
问答
  • upstream

    2021-05-18 14:18:33
    upstream linuxidc { server 10.0.6.108:7080; server 10.0.0.85:8980; } 2. 将server节点下的location节点中的proxy_pass配置为:http:// + upstream名称,即“ http://linuxidc”. location / { root html; ...

    详细配置步骤例如以下:

    upstream还能够为每一个设备设置状态值,这些状态值的含义分别例如以下:

    down 表示单前的server临时不參与负载.

    weight 默觉得1.weight越大,负载的权重就越大。

    max_fails :同意请求失败的次数默觉得1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误.

    fail_timeout : max_fails次失败后。暂停的时间。

    backup: 其他全部的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

    upstream bakend{ #定义负载均衡设备的Ip及设备状态 

          ip_hash; 

          server 10.0.0.11:9090 down; 

          server 10.0.0.11:8080 weight=2; 

          server 10.0.0.11:6060; 

          server 10.0.0.11:7070 backup; 

    }

    展开全文
  • git pull upstream同步上游更新 在使用git管理项目的时候,不管是gitlab还是github项目,都可以通过fork将上游仓库的项目复制到自己仓库中,但是上游的仓库变更时,怎么同步更新自己仓库里的变化呢? 一般有两种方式...

    git pull upstream同步上游更新

    在使用git管理项目的时候,不管是gitlab还是github项目,都可以通过fork将上游仓库的项目复制到自己仓库中,但是上游的仓库变更时,怎么同步更新自己仓库里的变化呢?

    一般有两种方式,一种方式是将上游的仓库提merge request到自己的仓库去合并;另一种方式是每次在修改自己仓库复制的项目之前,先通过git pull upstream master去同步上游项目的更新。

    git pull origin与git pull upstream区别

    git pull origin是拉取自己或团队项目的更新到本地;git pull upstream是拉取fork的外部上游项目的更新到本地自己仓库中的项目中。

    git pull origin

    origin指的是源仓库,一般为git clone的仓库,如xxx/fastjson,是克隆后默认提交和拉取的仓库地址。

    git pull upstream

    upstream意指上游仓库,一般是fork 出的上游仓库,如alibaba/fastjson。

    fork操作

    无论是github还是gitlab都有fork操作,该操作相当于把外部的仓库里面的项目复制到自己仓库下。例如,对alibaba/fastjson项目进行fork,会在自己仓库出现tomcat/fastjson项目,这里的tomcat代指自己github或gitlab的用户名。

    git clone ssh://git@github.com/tomcat/fastjson.git
    git pull // 默认是 git pull origin master,从bannidaer/fastjson的master分支拉代码
    git pull upstream master // 从上游alibaba/fastjson的master分支拉代码
    

    git pull upstream遇到 ‘upstream’ does not appear to be a git repository问题

    在进行本地fork出的项目修改之前,想要先同步上游的更新,于是进行git pull upstream操作,出现如下问题:

    fatal: 'upstream' does not appear to be a git repository
    fatal: Could not read from remote repository.
     
    Please make sure you have the correct access rights and the repository exists.
    

    通过 git remote -v 检查,发现错误原因是 upstream repository 的地址是 ssh协议,而不是 https,并且没有指定upstream上游仓库地址而是自己origin的tomcat仓库。

    origin  ssh://git@github.com/tomcat/fastjson.git (fetch)
    

    解决方案:

    如果想要使用https协议的仓库地址,可以利用 git remote remove upstream ssh://…仓库地址 的方式移除掉原来的 upstream repository,再 git remote add upstream https://… 添加上新的地址。

    % git remote add upstream ssh://git@github.com/alibaba/fastjson.git
    origin  ssh://git@github.com/tomcat/fastjson.git (fetch)             // 自己仓库的origin源项目
    origin  ssh://git@github.com/tomcat/fastjson.git (push)
    upstream        ssh://git@github.com/alibaba/fastjson.git (fetch)     // 外部上游仓库的项目
    upstream        ssh://git@github.com/alibaba/fastjson.git (push)
    

    添加完上游仓库地址后,再次执行git pull upstream命令如下:

    % git pull upstream master
    remote: Enumerating objects: 3, done.
    remote: Counting objects: 100% (3/3), done.
    remote: Compressing objects: 100% (3/3), done.
    remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (3/3), 764 bytes | 76.00 KiB/s, done.
    From ssh://git@github.com/alibaba/fastjson
     * branch            master     -> FETCH_HEAD
     * [new branch]      master     -> upstream/master
    Updating xxxxxx
    Fast-forward
    

    由于之前配置了GOPRIVATE,项目中引用私有仓库的项目,就将之前https协议拉取代码的方式改成了ssh方式,这里指定ssh协议的上游仓库地址,如果你使用的是https协议可以指定https协议的上游仓库。

    参考

    Git:Origin和upstream的区别
    ‘git pull upstream master‘遇到的问题

    展开全文
  • 下面针对Nignx负载均衡upstream容错机制的使用做一梳理性说明: 一、nginx的upstream容错 1)nginx 判断节点失效状态 Nginx默认判断失败节点状态以connect refuse和time out状态为准,不以HTTP错误状态进行判断...

    熟练掌握Nginx负载均衡的使用对运维人员来说是极其重要的!下面针对Nignx负载均衡upstream容错机制的使用做一梳理性说明:

    一、nginx的upstream容错

    1)nginx 判断节点失效状态
    Nginx默认判断失败节点状态以connect refuse和time out状态为准,不以HTTP错误状态进行判断失败,因为HTTP只要能返回状态说明该节点还可以正常连接,所以nginx判断其还是存活状态;除非添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理,在next_upstream过程中,会对fails进行累加,如果备用机处理还是错误则直接返回错误信息(但404不进行记录到错误数,如果不配置错误状态也不对其进行错误状态记录),综述,nginx记录错误数量只记录timeout 、connect refuse、502、500、503、504这6种状态,timeout和connect refuse是永远被记录错误状态,而502、500、503、504只有在配置proxy_next_upstream后nginx才会记录这4种HTTP错误到fails中,当fails大于等于max_fails时,则该节点失效;

    2)nginx 处理节点失效和恢复的触发条件
    nginx可以通过设置max_fails(最大尝试失败次数)和fail_timeout(失效时间,在到达最大尝试失败次数后,在fail_timeout的时间范围内节点被置为失效,除非所有节点都失效,否则该时间内,节点不进行恢复)对节点失败的尝试次数和失效时间进行设置,当超过最大尝试次数或失效时间未超过配置失效时间,则nginx会对节点状会置为失效状态,nginx不对该后端进行连接,直到超过失效时间或者所有节点都失效后,该节点重新置为有效,重新探测;

    3)所有节点失效后nginx将重新恢复所有节点进行探测
    如果探测所有节点均失效,备机也为失效时,那么nginx会对所有节点恢复为有效,重新尝试探测有效节点,如果探测到有效节点则返回正确节点内容,如果还是全部错误,那么继续探测下去,当没有正确信息时,节点失效时默认返回状态为502,但是下次访问节点时会继续探测正确节点,直到找到正确的为止。

    4)通过proxy_next_upstream实现容灾和重复处理问题
    ngx_http_proxy_module 模块中包括proxy_next_upstream指令
    语法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...; 
    默认值: proxy_next_upstream error timeout; 上下文: http, server, location

    其中:
    error   表示和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现错误。
    timeout   表示和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现超时。
    invalid_header   表示后端服务器返回空响应或者非法响应头 
    http_500   表示后端服务器返回的响应状态码为500 
    http_502   表示后端服务器返回的响应状态码为502 
    http_503   表示后端服务器返回的响应状态码为503 
    http_504   表示后端服务器返回的响应状态码为504 
    http_404   表示后端服务器返回的响应状态码为404 
    off   表示停止将请求发送给下一台后端服务器

    运用场景

    1)proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;
    当其中一台返回错误码404,500...等错误时,可以分配到下一台服务器程序继续处理,提高平台访问成功率,多可运用于前台程序负载,设置
    
    2、proxy_next_upstream off
    因为proxy_next_upstream 默认值: proxy_next_upstream error timeout;
    
    场景:
    当访问A时,A返回error timeout时,访问会继续分配到下一台服务器处理,就等于一个请求分发到多台服务器,就可能出现多次处理的情况,
    如果涉及到充值,就有可能充值多次的情况,这种情况下就要把proxy_next_upstream关掉即可
    proxy_next_upstream off
    
    案例分析(nginx proxy_next_upstream导致的一个重复提交错误):
    一个请求被重复提交,原因是nginx代理后面挂着2个服务器,请求超时的时候(其实已经处理了),结果nigix发现超时,有把请求转给另外台服务器又做了次处理。
    
    解决办法:
    proxy_next_upstream:off

    二、nginx负载均衡
    Nginx的负载均衡方式这里介绍4种:rr(轮询模式)、ip_hash、fair、url_hash;
    Nginx自带的2种负载均衡为rr和ip_hash,fair和url_hash为第三方的插件,nginx在不配置负载均衡的模式下,默认采用rr负载均衡模式。
    1)RR负载均衡模式:
    每个请求按时间顺序逐一分配到不同的后端服务器,如果超过了最大失败次数后(max_fails,默认1),在失效时间内(fail_timeout,默认10秒),该节点失效权重变为0,超过失效时间后,则恢复正常,或者全部节点都为down后,那么将所有节点都恢复为有效继续探测,一般来说rr可以根据权重来进行均匀分配。
    2)Ip_hash负载均衡模式:
    每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题,但是ip_hash会造成负载不均,有的服务请求接受多,有的服务请求接受少,所以不建议采用ip_hash模式,session共享问题可用后端服务的session共享代替nginx的ip_hash。
    3)Fair(第三方)负载均衡模式:
    按后端服务器的响应时间来分配请求,响应时间短的优先分配。
    4)url_hash(第三方)负载均衡模式:
    和ip_hash算法类似,是对每个请求按url的hash结果分配,使每个URL定向到一个同 一个后端服务器,但是也会造成分配不均的问题,这种模式后端服务器为缓存时比较好。

    三、Nginx负载均衡配置
    Nginx的负载均衡采用的是upstream模块,其中默认的采用的负载均衡模式是轮询模式rr(round_robin),具体配置如下:
    1)指令:
    ip_hash
    语法:ip_hash 
    默认值:none 
    使用字段:upstream 
    这个指令将基于客户端连接的IP地址来分发请求。
    哈希的关键字是客户端的C类网络地址,这个功能将保证这个客户端请求总是被转发到一台服务器上,但是如果这台服务器不可用,那么请求将转发到另外的服务器上,这将保证某个客户端有很大概率总是连接到一台服务器。
    无法将权重(weight)与ip_hash联合使用来分发连接。如果有某台服务器不可用,你必须标记其为"down",如下例:

    upstream backend {
      ip_hash;
      server   backend1.kevin.com;
      server   backend2.kevin.com;
      server   backend3.kevin.com  down;
      server   backend4.kevin.com;
    }

    server
    语法:server name [parameters] 
    默认值:none 
    使用字段:upstream 
    指定后端服务器的名称和一些参数,可以使用域名,IP,端口,或者unix socket。如果指定为域名,则首先将其解析为IP。
    [1]  weight = NUMBER - 设置服务器权重,默认为1。
    [2]  max_fails = NUMBER - 在一定时间内(这个时间在fail_timeout参数中设置)检查这个服务器是否可用时产生的最多失败请求数,默认为1,将其设置为0可以关闭检查,这些错误在proxy_next_upstream或fastcgi_next_upstream(404错误不会使max_fails增加)中定义。
    [3]  fail_timeout = TIME - 在这个时间内产生了max_fails所设置大小的失败尝试连接请求后这个服务器可能不可用,同样它指定了服务器不可用的时间(在下一次尝试连接请求发起之前),默认为10秒,fail_timeout与前端响应时间没有直接关系,不过可以使用proxy_connect_timeout和proxy_read_timeout来控制。
    [4]  down - 标记服务器处于离线状态,通常和ip_hash一起使用。
    [5]  backup - (0.6.7或更高)如果所有的非备份服务器都宕机或繁忙,则使用本服务器(无法和ip_hash指令搭配使用)。

    实例配置

    upstream  backend  {
      server   backend1.kevin.com    weight=5;
      server   127.0.0.1:8080          max_fails=3  fail_timeout=30s;
      server   unix:/tmp/backend3;
    }

    注意:如果你只使用一台上游服务器,nginx将设置一个内置变量为1,即max_fails和fail_timeout参数不会被处理。
    结果:如果nginx不能连接到上游,请求将丢失。
    解决:使用多台上游服务器。

    upstream
    语法:upstream name { … } 
    默认值:none 
    使用字段:http 
    这个字段设置一群服务器,可以将这个字段放在proxy_pass和fastcgi_pass指令中作为一个单独的实体,它们可以可以是监听不同端口的服务器,并且也可以是同时监听TCP和Unix socket的服务器。
    服务器可以指定不同的权重,默认为1。
    示例配置

    upstream backend {
      server kevin.com weight=5;
      server 127.0.0.1:8080       max_fails=3  fail_timeout=30s;
      server unix:/tmp/backend3;
    }

    请求将按照轮询的方式分发到后端服务器,但同时也会考虑权重。
    在上面的例子中如果每次发生7个请求,5个请求将被发送到backend1.kevin.com,其他两台将分别得到一个请求,如果有一台服务器不可用,那么请求将被转发到下一台服务器,直到所有的服务器检查都通过。如果所有的服务器都无法通过检查,那么将返回给客户端最后一台工作的服务器产生的结果。

    2) 变量
    版本0.5.18以后,可以通过log_module中的变量来记录日志:
    log_format timing '$remote_addr - $remote_user [$time_local]  $request '
        'upstream_response_time $upstream_response_time '
        'msec $msec request_time $request_time';

    log_format up_head '$remote_addr - $remote_user [$time_local]  $request '
        'upstream_http_content_type $upstream_http_content_type';

    $upstream_addr
    前端服务器处理请求的服务器地址

    $upstream_cache_status
    显示缓存的状态

    nginx在web应用上的占用率越来越高,其带的模块也越来越来。nginx_cache算是一个,虽和专业的cache工具相比略逊一筹,但毕竟部署简单,不用另装软件
    和资源开销,所以在web cache中也占了比重不小的一席。不过像squid和varnish等cache软件都自带的有cache查看工具,而且还可以方便的在http header上
    显示出是否命中。nginx主要还是做web使用。所以想要得出命中率的大小,还需要通过日志进行统计,不过想要增加header查看倒很简单
     
    1)在http header上增加命中显示
    nginx提供了$upstream_cache_status这个变量来显示缓存的状态,我们可以在配置中添加一个http头来显示这一状态,达到类似squid的效果。
    location  / {
            proxy_redirect          off;
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_connect_timeout   180;
            proxy_send_timeout      180;
            proxy_read_timeout      180;
            proxy_buffer_size       128k;
            proxy_buffers           4 128k;
            proxy_busy_buffers_size 128k;
            proxy_temp_file_write_size 128k;
            proxy_cache cache;
            proxy_cache_valid 200 304 1h;
            proxy_cache_valid 404 1m;
            proxy_cache_key $uri$is_args$args;
            add_header  Nginx-Cache "$upstream_cache_status";
            proxy_pass http://backend;
        }
     
     
    而通过curl或浏览器查看到的header如下:
    HTTP/1.1 200 OK
    Date: Mon, 22 Apr 2013 02:10:02 GMT
    Server: nginx
    Content-Type: image/jpeg
    Content-Length: 23560
    Last-Modified: Thu, 18 Apr 2013 11:05:43 GMT
    Nginx-Cache: HIT
    Accept-Ranges: bytes
    Vary: User-Agent
     
     
    $upstream_cache_status包含以下几种状态:
    ·MISS 未命中,请求被传送到后端
    ·HIT 缓存命中
    ·EXPIRED 缓存已经过期请求被传送到后端
    ·UPDATING 正在更新缓存,将使用旧的应答
    ·STALE 后端将得到过期的应答
    =======================================================================================================================
    nginx比较强大,可以针对单个域名请求做出单个连接超时的配置. 可以根据业务的:
    
    proxy_connect_timeout :后端服务器连接的超时时间_发起握手等候响应超时时间
    proxy_read_timeout:连接成功后,等候后端服务器响应时间_其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间)
    proxy_send_timeout :后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

    $upstream_status
    前端服务器的响应状态。

    $upstream_response_time
    前端服务器的应答时间,精确到毫秒,不同的应答以逗号和冒号分开。

    $upstream_http_$HEADER
    随意的HTTP协议头,如:$upstream_http_host

    $upstream_http_host

    3) Proxy指令
    proxy_next_upstream
    语法:proxy_next_upstream
    [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]

    默认值:proxy_next_upstream error timeout 
    使用字段:http, server, location

    确定在何种情况下请求将转发到下一个服务器:
    error     在连接到一个服务器,发送一个请求,或者读取应答时发生错误。
    timeout     在连接到服务器,转发请求或者读取应答时发生超时。
    invalid_header    服务器返回空的或者错误的应答。
    http_500    服务器返回500代码。
    http_502    服务器返回502代码。
    http_503    服务器返回503代码。
    http_504    服务器返回504代码。
    http_404    服务器返回404代码。
    off    禁止转发请求到下一台服务器。

    转发请求只发生在没有数据传递到客户端的过程中。
    其中记录到nginx后端错误数量的有500、502、503、504、timeout,404不记录错误。

    proxy_connect_timeout
    语法:proxy_connect_timeout timeout_in_seconds 
    默认值:proxy_connect_timeout 60s 
    使用字段:http, server, location 
    指定一个连接到代理服务器的超时时间,单位为秒,需要注意的是这个时间最好不要超过75秒。
    这个时间并不是指服务器传回页面的时间(这个时间由proxy_read_timeout声明)。
    如果你的前端代理服务器是正常运行的,但是遇到一些状况(如没有足够的线程去处理请求,请求将被放在一个连接池中延迟处理),那么这个声明无助于服务器去建立连接。
    可以通过指定时间单位以免引起混乱,支持的时间单位有”s”(秒), “ms”(毫秒), “y”(年), “M”(月), “w”(周), “d”(日), “h”(小时),和 “m”(分钟)。
    这个值不能大于597小时。

    proxy_read_timeout
    语法:proxy_read_timeout time 
    默认值:proxy_read_timeout 60s 
    使用字段:http, server, location 
    决定读取后端服务器应答的超时时间,单位为秒,它决定nginx将等待多久时间来取得一个请求的应答。超时时间是指完成了两次握手后并且状态为established的超时时间。
    相对于proxy_connect_timeout,这个时间可以扑捉到一台将你的连接放入连接池延迟处理并且没有数据传送的服务器,注意不要将此值设置太低,某些情况下代理服务器将花很长的时间来获得页面应答(例如如当接收一个需要很多计算的报表时),当然你可以在不同的location里面设置不同的值。
    可以通过指定时间单位以免引起混乱,支持的时间单位有”s”(秒), “ms”(毫秒), “y”(年), “M”(月), “w”(周), “d”(日), “h”(小时),和 “m”(分钟)。
    这个值不能大于597小时。

    proxy_send_timeout
    语法:proxy_send_timeout seconds 
    默认值:proxy_send_timeout 60s 
    使用字段:http, server, location 
    设置代理服务器转发请求的超时时间,单位为秒,同样指完成两次握手后的时间,如果超过这个时间代理服务器没有数据转发到被代理服务器,nginx将关闭连接。
    可以通过指定时间单位以免引起混乱,支持的时间单位有”s”(秒), “ms”(毫秒), “y”(年), “M”(月), “w”(周), “d”(日), “h”(小时),和 “m”(分钟)。
    这个值不能大于597小时。

    四、Nginx upstream负载均衡获取后端服务器的流程
    GET_RR_PEER: 通过RR算法获取后端流程

    K:是判断peer是否宕机和判断失效状态算法

    FAIL:尝试次数用尽有,跳转到失败流程,如果有备机,备机再尝试监听,如果监听失败则返回NGX_BUSY,成功则返回当前状态。

    五、验证环境部署
    Web服务器: nginx
    Web应用服务器:tomcat(2台)

    Nginx反向代理tomcat,即通过upstream将请求负载到后端两台tomcat的对应服务端口上。部署过程此处省略......

    六、验证结果说明
    1)设置tomcat1超时时间,造成超时状态(总有一台server为有效状态)
    Tomcat1的connectionTimeout 设置为-1,永远超时,nginx设置tomcat1和tomcat2权重为10,tomcat1的max_fails为10,fail_timeout=120;在连接tomcat1的10次后,返回给nginx为10次超时,ngxin判断tomcat1为失效,然后将tomcat1超时时间恢复为1000重新启动tomcat1,在这段时间内nginx判断tomcat1还是失效状态,所以在2分钟后,nginx继续监听到tomcat1正常后,那么nginx会将tomcat1判断为有效,将连接继续均匀分配到2个tomcat上。

    2)设置tomcat1连接数量,造成超时状态(总有一台server为有效状态)
    Tomcat1的线程数量设置为1,nginx设置tomcat1和tomcat2权重为10,tomcat1的max_fails为10,fail_timeout=120;在连接tomcat1超过线程接受数量后,tomcat1会返回超时状态,在返回给nginx10次超时状态后,ngxin判断tomcat1为失效,然后将tomcat线程数量恢复为700,重新启动tomcat1,在这段时间内nginx判断tomcat1还是失效状态,超过2分钟失效后,nginx继续监听到tomcat1正常后,那么nginx会将tomcat1判断为有效,将连接继续均匀分配到2个tomcat上。

    3)设置tomcat1关闭,造成拒绝状态(总有一台server为有效状态)
    Tomcat1为关闭,nginx设置tomcat1和tomcat2权重为10,tomcat1的max_fails为10,fail_timeout=120;在连接tomcat1的10次后,nginx收到tomcat1返回connect refuse状态,ngxin判断tomcat1为失效,然后重新启动tomcat1,在这段时间内nginx判断tomcat1还是失效状态,超过2分钟失效后,nginx继续监听到tomcat1正常后,那么nginx会将tomcat1判断为有效,将连接继续均匀分配到2个tomcat上。

    4)设置tomcat1在nginx1标记失效,tomcat1恢复正常,在nginx失效范围内,将全部服务变为失效,然后重启
    Tomcat1为关闭,nginx设置tomcat1和tomcat2权重为10,tomcat1的max_fails为10,fail_timeout=120;在连接tomcat1的10次后,nginx收到tomcat1返回connect refuse状态,ngxin判断tomcat1为失效,然后重新启动tomcat1,在这段时间内nginx判断tomcat1还是失效状态,然后将tomcat2关闭,然后重启tomcat2,由于所有服务均失效,所以nginx 将所有服务重新置为有效进行监听,然后将2连接均匀分布到了tomcat1和tomcat2上。

    5)http错误状态,nginx是否记录失效
    nginx设置tomcat1和tomcat2权重为10,tomcat1的max_fails为10,fail_timeout=120;配置proxy_next_upstream 500、404、502、503、504、timeout后,当HTTP状态为500、502、503、504(timeout和refuse默认是记录失效的)时,nginx会判断该次请求为失败记录失败状态,其他所有HTTP均不记录失败。

    ©著作权归作者所有:来自51CTO博客作者80民工的原创作品,如需转载,请注明出处,否则将追究法律责任

    展开全文
  • nginx_upstream_check_module模块 一个更专业的模块,来专门提供负载均衡器内节点的健康检查的。这个就是淘宝技术团队开发的 nginx 模块nginx_upstream_check_module,通过它可以用来检测后端 realserver 的健康状态...


    nginx_upstream_check_module模块
    一个更专业的模块,来专门提供负载均衡器内节点的健康检查的。这个就是淘宝技术团队开发的 nginx 模块nginx_upstream_check_module,通过它可以用来检测后端 realserver 的健康状态。如果后端realserver不可用,则所有的请求就不会转发到该节点上。
    在淘宝自己的 tengine 上是自带了该模块的,大家可以访问淘宝tengine的官网来获取该版本的nginx,官方地址:http://tengine.taobao.org
    如果我们没有使用淘宝的 tengine 的话,可以通过补丁的方式来添加该模块到我们自己的 nginx 中。我们业务线上就是采用该方式进行添加的。
    下面是部署流程!

    1、下载nginx_upstream_check_module模块
    [root@localhost ~]# cd /usr/local/src
    wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master
    unzip master
    [root@localhost /usr/local/src]# ll -d nginx_upstream_check_module-master
    drwxr-xr-x. 6 root root 4096 Dec  1 02:28 nginx_upstream_check_module-master

    2、为nginx打补丁
    [root@localhost /usr/local/src]# cd nginx-1.6.0 # 进入nginx的源码目录
    [root@localhost nginx-1.6.0]# patch -p1 < ../nginx_upstream_check_module-master/check_1.5.12+.patch
    [root@localhost nginx-1.6.0]# ./configure --user=nginx --group=nginx --prefix=/usr/local/nginx-1.6.0 --with-http_ssl_module --with-openssl=/usr/local/src/openssl-0.9.8q --with-pcre=/usr/local/src/pcre-8.32 --add-module=/usr/local/src/nginx_concat_module/ --add-module=../nginx_upstream_check_module-master/
    make (注意:此处只make,编译参数需要和之前的一样)
    [root@localhost nginx-1.6.0]# mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx-1.6.0.bak
    [root@localhost nginx-1.6.0]# cp ./objs/nginx /usr/local/nginx/sbin/
    [root@localhost nginx-1.6.0]# /usr/local/nginx/sbin/nginx -t  # 检查下是否有问题
    [root@localhost nginx-1.6.0]# kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`

    3、在nginx.conf配置文件里面的upstream加入健康检查,如下:

    upstream name {
           server 192.168.0.21:80;
           server 192.168.0.22:80;
           check interval=3000 rise=2 fall=5 timeout=1000 type=http;
             
    }
    上面配置的意思是,对name这个负载均衡条目中的所有节点,每个3秒检测一次,请求2次正常则标记 realserver状态为up,如果检测 5 次都失败,则标记 realserver的状态为down,超时时间为1秒。

    这里列出nginx_upstream_check_module模块所支持的指令意思:
    Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]
    Default: 如果没有配置参数,默认值是:interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
    Context: upstream
    该指令可以打开后端服务器的健康检查功能。

    指令后面的参数意义是:
        - interval:向后端发送的健康检查包的间隔。
        - fall(fall_count): 如果连续失败次数达到fall_count,服务器就被认为是down。
        - rise(rise_count): 如果连续成功次数达到rise_count,服务器就被认为是up。
        - timeout: 后端健康请求的超时时间。
        - default_down: 设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的。
        - type:健康检查包的类型,现在支持以下多种类型
            - tcp:简单的tcp连接,如果连接成功,就说明后端正常。
            - ssl_hello:发送一个初始的SSL hello包并接受服务器的SSL hello包。
            - http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活。
            - mysql: 向mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活。
            - ajp:向后端发送AJP协议的Cping包,通过接收Cpong包来判断后端是否存活。
        - port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口,比如后端提供的是443端口的应用,你可以去检查80端口的状态来判断后端健康状况。默认是0,表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0。

    Syntax: check_keepalive_requests request_num
    Default: 1
    Context: upstream
    该指令可以配置一个连接发送的请求数,其默认值为1,表示Tengine完成1次请求后即关闭连接。

    Syntax: check_http_send http_packet
    Default: "GET / HTTP/1.0\r\n\r\n"
    Context: upstream
    该指令可以配置http健康检查包发送的请求内容。为了减少传输数据量,推荐采用"HEAD"方法。

    当采用长连接进行健康检查时,需在该指令中添加keep-alive请求头,如:"HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n"。 同时,在采用"GET"方法的情况下,请求uri的size不宜过大,确保可以在1个interval内传输完成,否则会被健康检查模块视为后端服务器或网络异常。

    Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]
    Default: http_2xx | http_3xx
    Context: upstream
    该指令指定HTTP回复的成功状态,默认认为2XX和3XX的状态是健康的。

    Syntax: check_shm_size size
    Default: 1M
    Context: http
    所有的后端服务器健康检查状态都存于共享内存中,该指令可以设置共享内存的大小。默认是1M,如果你有1千台以上的服务器并在配置的时候出现了错误,就可能需要扩大该内存的大小。

    Syntax: check_status [html|csv|json]
    Default: check_status html
    Context: location
    显示服务器的健康状态页面。该指令需要在http块中配置。

    在Tengine-1.4.0以后,你可以配置显示页面的格式。支持的格式有: html、csv、 json。默认类型是html。

    你也可以通过请求的参数来指定格式,假设‘/status’是你状态页面的URL, format参数改变页面的格式,比如:

    /status?format=html
    /status?format=csv
    /status?format=json
    同时你也可以通过status参数来获取相同服务器状态的列表,比如:

    /status?format=html&status=down
    /status?format=csv&status=up
    下面是一个状态也配置的范例:

    http {
          server {
                location /nstatus {
                       check_status;
                       access_log off;
                       #allow IP;
                       #deny all;
                }
          }
    }
     

    nginx.conf配置案例

    #user  nobody;
    worker_processes  10;
    worker_rlimit_nofile 65535;
    pid        /data/soft/nginx/nginx.pid;

    events {
        use epoll;
        worker_connections 65535;
    }


    http {
        log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" "$upstream_addr"  "$request_body"';
        access_log /data/soft/nginx/log/access_log main;
        error_log  /data/soft/nginx/log/error_log  debug_http;
        client_max_body_size 30m;
        include       mime.types;
        default_type  application/octet-stream;


        sendfile        on;
        keepalive_timeout  65;


        server {
            listen       8080;
            server_name  localhost;


            location / {
               root html;
               index index.html index.htm;
               proxy_pass http://demo1;
               proxy_redirect off;
               proxy_set_header Host $host:$server_port;
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            }

            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }

            location /nstatus {
                check_status;
                access_log off;
                #allow IP;
                #deny all;
            }

        }

        upstream demo1 {
           sticky name=demo01 path=/;
           server 127.0.0.1:18080;
           
           #http健康检查相关配置
           check interval=3000 rise=2 fall=3 timeout=3000 type=http;
           #/health/status为后端健康检查接口
           check_http_send "GET / HTTP/1.0\r\n\r\n";
           check_http_expect_alive http_2xx http_3xx;
          
        }


    }

     

     

     

    http://192.168.23.101:8080/nstatus

    http://192.168.23.101:8080/

     


     

    展开全文
  • nginx upstream 健康检查

    千次阅读 2021-02-06 17:49:39
    使用 nginx_upstream_check_module 模块来对来专门提供负载均衡器内节点的健康检查的,这个模块是淘宝开发的,在tengine中这个模块是默认自带的,这个模块的作用就是用来检测后端realserver是否存活。如果后端 real...
  • 由于该指令只支持 worker 级别的操作,为使得 Nginx 的所有 worker 都生效,此处通过编写 Lua 脚本与 lua-resty-upstream-healthcheck 模块做了简单的集成,利用 lua-resty-upstream-healthcheck 模块的共享内存...
  • if (u->conf->next_upstream_tries && u->peer.tries > u->conf->next_upstream_tries) { u->peer.tries = u->conf->next_upstream_tries; } // 发起连接 ngx_http_upstream_connect(r, u); ... } void ngx_...
  • upstream 指令参数

    2021-04-12 21:54:25
    限制每台server的连接数,用于保护...upstream tomcats { server 192.168.1.173:8080 max_conns=2; server 192.168.1.174:8080 max_conns=2; server 192.168.1.175:8080 max_conns=2; } 使用jmeter可以测试出。 ...
  • 一、upstream模块简介   Nginx的负载均衡功能依赖于ngx_http_upsteam_module模块,所支持的代理方式包括proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass和grpc_pass。ngx_http_upstream_module...
  • 一、关于nginx upstream 在nginx的模块中,分为3种类型,分别是handler,filter和upstream,其中upstream可以看做一种特殊的handler,它主要用来实现和后端另外的服务器进行通信,由于在nginx中全部都是使用非...
  • #!/bin/bash###################################################### Name: change_nginx_upstream_conf.sh# Version: V1.# Author: 运维菜鸟# Description: 更改nginx upstream...
  • upstream模块 nginx的负载均衡功能依赖于http_upstream_module模块,所支持的代理方式包括proxy_pass、fastcgi_pass、memcached_pass等。 http_upstream_module模块允许nginx定义一组或多组节点服务器组,使用时可以...
  • 注:本文提到的所有变量,如果需要区分,则均为ngx_http_upstream_module中的变量,不再做释义。如需要使用其他module中的参数,请参考nginx官方文档 1、Nginx内时间定义 1.1、request_time 单位为秒。 官网描述:...
  • 开源世界里的重要理念:UpStream First
  • }} } 发现报错upstream prematurely closed connection while reading response header from upstream,然后去网上找答案,有的说是ngxin缓存目录权限问题,有的说是 keepalive_timeout 时间设置太短,试了以后,...
  • 发现报upstream prematurely closed connection while reading response header from upstream在从上游读取响应头时,上游过早关闭连接 这里猜测上游应该指的是服务器,因为后端架构是 nginx+gunicron 3.....
  • 开发中,经常要求我们fork一个自己的仓库,然后,在自己仓库中开发,最后,merge到upstream仓库。 但是,由于,upstream仓库可能会被很多人修改,因此,你自己fork的仓库就会落后。 此时,就需要和upstream仓库同步...
  • 先来了解一下upstream的淘宝技术团队开发的nginx模快nginx_upstream_check_module来检测后方realserver的健康状态,如果后端服务器不可用,则所有的请求不转发到这台服务器。 以下为参数意义 #server default: max_...
  • upstream中下划线(_)取消 或者 换成 横线(-) 分析原因: 升级了SpringBoot版本,tomcat是遵循的RFC1-1034的规范,​所以带有下划线的Host的http请求,​新版本的tomcat会对heard进行校验,旧版本没有...
  • upstream的指令参数

    2021-01-04 19:27:15
    文章目录一、upstream是什么?二、指令1.max_conns2.slow_start3.down4.backup5.max_fails,fail_timeout 一、upstream是什么? upstream也称为上游服务器,是在Nginx进行集群开发时配置服务器的称呼。 二、指令 1....
  • upstream 参数 nginx关于upstream参数官方文档:http://nginx.org/en/docs/http/ngx_http_upstream_module.html 英文 https://www.kancloud.cn/louis1986/nginx-web/527874 中文 upstream参数 ...
  • nginx中upstream参数配置

    2021-07-14 16:38:36
    1.max_conns 用于限制每台server的连接数,起到避免过载,可起到...upstream tomcats { server 192.168.1.100:8080 max_conns=2; server 192.168.1.101:8080 max_conns=2; server 192.168.1.102:8080 max_conn...
  • Nginx通过反向代理做负载均衡时,如果被代理的其中一个服务发生错误或者超时的时候,通常希望Nginx自动重试其他的服务,从而...实际上Nginx本身默认会有错误重试机制,并且可以通过proxy_next_upstream来自定义配置。
  • 2021/01/11 12:39:06 [error] 62859#62859: *78173 upstream sent invalid chunked response while reading upstream, 2021/01/11 12:39:13 [error] 62859#62859: *78197 upstream sent invalid chunked response ...
  • 基于指定的key的hash表来实现对请求的调度,此处的key可以直接文本、变量或二者的组合 作用:将请求分类,同一类请求将发往同一个upstream server If the consistent parameter is specified the ketama consistent...
  • 2、upstream配置示例 upstream linuxe_backend { server 192.168.1.110 down; #该节点不可用 server 192.168.1.120 backup; #其他节点挂了后该节点自动上线 server 192.168.1.130 max_failes=1 fail_timeout=10s ...
  • UpstreamCacheManager里面有两个属性,UPSTREAM_MAP里面存储的是admin同步过来的upstreamUPSTREAM_MAP_TEMP里面存储的是探活机制探到的存活的upstream。不过因为 soul-plugin-divide里面的探活机制默认是关闭的,...
  • nginx配置-upstream 方式1: 轮询 upstream xxx_server_name{ server 192.168.10.1:80; server 192.168.10.2:80; server 192.168.10.3:80; } 方式2: 权重轮询 upstream xxx_server_name{ server 192....
  • nginx upstream和轮询策略 注:提供基础讲解示例,生产环境请根据自身情况并参照nginx官方配置 一、nginx upstream nginx upstream语法配置 #upstream后面跟服务名 # server 后面跟域名、端口、权重等配置,...
  • 比如以第一台服务器为主,其他两台为辅,则就是这样: 1.upstream myfastcgi { 2.server 172.16.236.110:9000 weight=1; 3.server 172.16.236.111:9000 weight=2; 4.server 172.16.236.112:9000 weight=2; } 然后...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 124,443
精华内容 49,777
关键字:

upstream