Nginx+upstream针对后端服务器容错的运维笔记

Nginx+upstream针对后端服务器容错的运维笔记

精通Nginx负载均衡的操作对于系统管理员而言至关重要。以下将就Nginx负载均衡的故障转移功能进行系统性的阐述和解释：

一、nginx的容错

Nginx在判定节点失效时，主要以连接超时和时间超时作为判断标准，而非HTTP错误状态。因为HTTP错误状态的返回意味着节点仍能正常连接，故Nginx将其视为存活状态。除非用户添加特定指令，将404、502、503、504、500以及time out等错误状态转发至备用机处理。在此过程中，会对错误次数进行累计。若备用机处理依旧出错，则直接返回错误信息（但404错误不纳入错误计数，若未配置错误状态，则同样不记录）。总结来说，Nginx仅记录502、500、503、504这四种状态和time out，作为固定记录的错误状态。而502、500、503、504这四种HTTP错误，只有在用户进行配置后，才会被记录到错误计数中。当错误计数达到一定阈值时，该节点将被判定为失效。

nginx在处理节点失效与恢复时，可通过对最大尝试失败次数的设定以及失效时间的配置来调整节点失败尝试的频率和节点失效的时间段。具体而言，当节点失败尝试次数超过预设的最大值，或者节点在达到最大尝试失败次数后，在指定的时间范围内未能恢复，nginx将节点状态标记为失效。在此期间，nginx不会与该后端建立连接。只有在超过失效时间或所有节点均失效后，该节点才会被重新设置为有效状态，并重新进行探测。

一旦所有节点均出现故障，nginx将重新启动对所有节点的探测工作。若所有节点均无法探测Nginx+upstream针对后端服务器容错的运维笔记，且备用节点同样失效，nginx将把所有节点标记为有效，并再次尝试探测。一旦发现有效节点，即返回正确内容。若所有节点依然显示错误，则持续进行探测。在没有获取到正确信息的情况下，当节点出现故障时，系统默认返回502状态码。然而，在后续访问该节点时，系统将继续探测，直至找到正常节点。

实现容灾与重复处理机制的问题模块内，囊括了指令语法：error | | | | | | | | off...；其预设值为error；适用场景为http, 。

error指代在连接后端服务器、发送请求至后端服务器，或是接收后端服务器的响应头过程中发生的错误。同时，也表示在上述过程中，连接、发送请求或接收响应头时出现了超时情况。后端服务器可能给出空响应或带有不合法的响应头，此外，它还可能抛出500、502、503、504等不同的状态码错误，而404 off则意味着不再将请求传递至后续的后端服务器。

运用场景

二、在介绍Nginx的负载均衡功能时，我们将阐述四种不同的均衡方法：轮询模式（rr）、加权轮询（fair）以及其他两种；其中，Nginx本身内置了两种负载均衡机制nginx upstream，即轮询模式（rr）和加权轮询（fair），而另外两种则需借助第三方插件来实现。若Nginx未进行负载均衡模式的配置，系统将默认启用轮询模式（rr）进行负载均衡。RR负载均衡模式下，每个请求依次按照时间序列被分配至不同的后端服务器。若遇到超过预设的最大失败次数（默认为1次），在该节点失效的默认时间限制（10秒）内，其权重将归零。失效时间过后，该节点将恢复正常工作，或者当所有节点均处于不可用状态时，系统将重新启用所有节点进行探测。通常情况下，RR模式还能根据权重实现资源的均衡分配。负载均衡的机制是依据访问IP的哈希值来分配每个请求，确保每位用户始终访问同一台后端服务器。这种做法能有效解决用户固定访问的问题，然而Nginx+upstream针对后端服务器容错的运维笔记，它也可能导致负载分配不均，使得某些服务请求承受的负载远大于其他服务。鉴于此，不建议使用这种模式。对于共享问题，我们可以通过后端服务的共享机制来替代nginx的共享功能。3）采用第三方负载均衡模式时，请求的分配依据后端服务器的响应速度进行，速度较快的服务器将优先获得请求。4）此模式与算法相仿，它根据每个请求的URL进行hash计算，确保每个URL都指向同一后端服务器，尽管如此，这种分配方式也可能导致不均衡的问题。当后端服务器用于缓存时，这种模式表现得尤为出色。

三、Nginx在负载均衡方面的配置，基于模块实现，其中默认选用的负载均衡模式为轮询模式rr。具体配置细节如下：指令语法为：默认值为none，使用字段为：该指令负责根据客户端的IP地址来分配请求。哈希算法的核心要素在于识别客户端的C类IP地址，此机制确保了客户端的请求能够持续定向至同一台服务器。然而，若该服务器无法提供服务，请求将自动切换至备用服务器，从而确保客户端有较高几率持续连接到固定的服务器。需要注意的是，无法将权重与该机制结合以实现连接的分配。一旦发现某服务器无法使用，必须将其状态标记为“不可用”，例如：

upstream backend {
  ip_hash;
  server   backend1.kevin.com;
  server   backend2.kevin.com;
服务器端backend3.kevin.com目前处于关闭状态；
  server   backend4.kevin.com;
}

语法： name

默认值设定为无，选用字段包括指定后端服务器名称及若干参数，这些参数可包括域名、IP地址、端口号，亦或Unix路径。若选用域名，系统将优先将其转换成IP地址。服务器权重设定值默认为1。在指定的时间段内（该时间段由参数设定），对服务器可用性进行检查时，记录下出现次数最多的失败请求数量，其默认值为1。若将此值设为0，则可停止进行该检查。相关错误类型在或m（不包括404错误）中进行了明确定义。当服务器在指定的时间内连续遭遇预设数量的失败连接尝试后，可能会出现不可用状态，同时，它也设定了服务器不可用的时间段（即从最后一次尝试连接开始至下一次尝试连接发起之间），此默认时长为10秒。这一时间与前端响应时间并无直接联系，但用户可以通过t和来调整。此外，down标志用于表示服务器离线状态，通常与其它状态标志一同使用。当所有非备份服务器均出现故障或过于繁忙时，应启用本服务器进行操作（请注意，本服务器无法与指令相结合使用）。

实例配置

upstream  backend  {
服务器端地址为backend1.kevin.com，其权重设置为5。
服务器地址为127.0.0.1，端口号为8080，最大失败次数设置为3次，每次失败的超时时间为30秒。
  server   unix:/tmp/backend3;
}

留意：若仅依赖一台上游服务器，nginx将自动设定一个内部变量值为1，意味着相关参数将不予处理。其后果是：一旦nginx无法与上游服务器建立连接，相关请求便会丢失。对策：应采用多台上游服务器以规避此问题。

语法规定：字段名为“name”，其默认值为“none”。此字段应用于“http”部分，用于配置一组服务器。这些服务器可以独立存在，并监听不同的端口，甚至可以同时监听TCP和Unix协议。每个服务器还可以分配不同的权重，默认权重为1。以下是一个示例配置：

upstream backend {
  server kevin.com weight=5;
服务器地址设为127.0.0.1，端口号为8080，最大失败次数限定为3次，每次失败的超时时间为30秒。
  server unix:/tmp/backend3;
}

请求将依照轮询机制分配至后端服务器，并且会同时考量权重分配。以先前示例为例，若每次共有7个请求，其中5个将分配至特定服务器，剩余的两台服务器各获得一个请求。若某台服务器出现故障，请求将自动转至下一台服务器，此过程将持续进行，直至所有服务器均通过检查。若所有服务器均未通过审查，客户端将收到最后成功运作的服务器所输出的结果。

自版本0.5.18起，用户能够利用特定变量进行日志的记录；例如，可以使用“$ - $”这一变量。

$

我，我，自身，自身，执行nginx upstream，执行，毫秒，毫秒，分号，分号。

'$ - $

$

$ '    ' $';

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

$s显示缓存的状态

nginx在Web领域的使用频率持续攀升，所搭载的模块种类也在不断增加。其中，nginx_cache便是其中之一，尽管与专业的缓存工具相比可能存在一定差距，但它的部署过程相对简便，无需额外安装其他软件。
由于涉及资源消耗，因此在该领域中也占据了相当重要的位置。然而，诸如squid和varnish之类的缓存软件均配备了查看缓存的功能，并且能够轻松地在HTTP头部进行操作。
显示命中与否。Nginx主要应用于Web服务。因此，若要计算命中率的具体数值，便需借助日志数据进行统计。然而，若要增加对header的查看功能，操作过程则相对简便。
 
1）在http header上增加命中显示
Nginx引入了$upstream_cache_status这一变量，用以展示缓存的具体状况。我们可在配置文件中增设一个HTTP头部，用以展示该状态信息，从而实现与squid相似的显示效果。
location  / {
        proxy_redirect          off;
设置代理头部信息，指定为“Host”，其值为变量$host。
设置代理头信息         X-Real-IP         为客户端的远程地址；
设置代理头信息 X-Forwarded-For 为 $proxy_add_x_forwarded_for;
        proxy_connect_timeout   180;
        proxy_send_timeout      180;
        proxy_read_timeout      180;
        proxy_buffer_size       128k;
代理缓冲区设置为4个，每个大小为128k。
        proxy_busy_buffers_size 128k;
设置代理临时文件写入大小为128KB。
        proxy_cache cache;
        proxy_cache_valid 200 304 1h;
        proxy_cache_valid 404 1m;
代理缓存键为$uri，是否传递参数由"is_args"决定，参数列表为$args。
向头部添加信息 Nginx-Cache，其值为 "$upstream_cache_status"。
        proxy_pass http://backend;
    }
 
 
而通过curl或浏览器查看到的header如下：
HTTP/1.1 200 OK
日期：星期一，四月二十二日，凌晨两点十分零二秒，格林威治标准时间。
Server: nginx
Content-Type: image/jpeg
Content-Length: 23560
修改时间：星期四，四月十八日，上午十一点零五分四十三秒，格林威治标准时间。
Nginx-Cache: HIT
Accept-Ranges: bytes
Vary: User-Agent
 
 

upstream_cache_status参数涵盖了以下几种不同的状态：
·MISS 未命中，请求被传送到后端
·HIT 缓存命中
·EXPIRED 缓存已经过期请求被传送到后端
·UPDATING 正在更新缓存，将使用旧的应答
·STALE 后端将得到过期的应答
禁止对特定内容进行修改，确保专有名词不被更改，同时严格遵循既定规范。
Nginx功能卓越，能够对特定域名的请求实施单独的连接超时设置。它还能够依据不同业务需求：
代理连接超时时间：指的是与后端服务器建立连接时，等待握手和响应的超出预定时间限制。
proxy_read_timeout：在连接建立成功之后，需等待后端服务器作出回应，而这段时间实际上是指后端服务器正在对请求进行排队处理（或者说，是后端服务器处理请求所需的时间）。
proxy_send_timeout：指的是后端服务器返回数据的总时长，即在设定的时限内，后端服务器必须完成所有数据的传输。

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

前端服务器对于请求的响应时长，精确至毫秒级，各个响应时间点通过逗号与冒号进行区分。

$$随意的HTTP协议头，如：$

$

3) Proxy指令语法:

error||||||||off

默认值： error 使用字段：http, ,

明确触发请求转发的具体条件包括：连接至服务器时，发送请求或接收响应过程中出现错误；连接至服务器，进行请求转发或读取响应时遭遇超时；服务器反馈了空白或错误的响应信息；服务器响应了500错误代码；服务器响应了502错误代码。服务器反馈了503错误码。同时，它也给出了504错误码。此外，还有404错误码的出现。因此，必须禁止将请求转发至后续的服务器。

转发请求仅在客户端未接收到数据时出现。在nginx后端记录的错误类型包括500、502、503、504，而404错误则不予记录。

t语法设定了默认值t为60秒，涉及到的使用字段包括http，该参数用于指定与代理服务器建立连接的超时时间，其单位为秒。需注意的是，此超时时间不宜超过75秒。需明确的是，这并非指服务器传输页面内容所需的时间（该时间由其他声明决定）。若前端代理服务器运作正常，却遭遇某些问题（例如，线程数量不足以应对请求，导致请求需在连接池中等待处理），则此声明对服务器建立连接并无实际帮助。[]

语法设置中，默认的超时时间为60秒，该值适用于http请求。这一设置决定了nginx在等待后端服务器响应时将保持多长时间。具体来说，这个超时时间是从两次握手完成且服务器状态稳定之后开始计算的。在t这个时间节点，能够监测到一台服务器，该服务器会将你的网络连接加入连接池进行延迟处理，同时不进行数据传输。需要注意的是，不应将此参数设定得过于低，因为有些情况下，代理服务器在获取页面响应时会耗费较长时间（比如在接收需要进行大量计算的报表时）。当然，你也可以在不同的场景中设定不同的参数值。[]

设置代理服务器请求转发的超时时间为60秒，此时间同样适用于完成两次握手后的过程。若代理服务器在规定时间内未能将数据成功转发至被代理服务器，nginx将自动断开连接。为避免混淆，可设定具体的时间计量单位，例如“秒”、“毫秒”、“年”、“月”、“周”、“日”、“小时”或“分钟”，但数值需控制在597小时以内。

四、Nginx负载均衡获取后端服务器的过程涉及RR算法，该算法负责确定服务器的调用顺序。

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

尝试次数达到上限，需转入失败处理流程。若配备有备用设备，则由备机尝试进行监听。若监听操作未能成功，则需返回；若监听成功，则返回当前设备的状态。

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

Nginx实现反向代理功能，具体做法是将请求分配至后端两台服务器上各自对应的服务端口。部署的具体步骤在此处并未详细展开。

六、验证结果说明：首先，设定超时时间为特定值，导致系统进入超时状态（其中一台始终保持有效）。对于这些设置为-1的配置，系统将永久处于超时状态。在nginx配置中，权重被设定为10，而超时时间则被设置为120秒。当连接尝试达到10次时，nginx将记录10次超时nginx upstream，并判定该服务为失效。随后，系统将超时时间重置为1000毫秒并重启。在此期间，nginx依旧认为该服务处于失效状态。然而，在2分钟后，一旦nginx检测到服务恢复正常，它将重新判定该服务为有效，并将连接请求均匀分配至两个服务实例。

将导致超时并保持至少一台线程有效运行的连接数设定为1，nginx配置权重为10，即10个权重单位等于120；当连接数超出线程最大接受量时，系统将显示超时，随后nginx将其判定为失效。此时，线程数量将恢复至700，并重新启动。在此期间，若nginx持续判定为失效状态，超过2分钟后，一旦nginx监听到正常状态，它将重新判定为有效，并将连接均匀分配至两个线程上。

将关闭设置导致拒绝状态（其中一台始终处于有效状态）设置为关闭，nginx的配置权重设定为10，即等于120；在连接进行10次之后，nginx接收到响应状态，判定为失效，随即启动重启。在此期间，nginx持续判定为失效状态，若超过2分钟仍未恢复，一旦监听到正常状态，nginx将重新将其判定为有效，并将连接均匀分配至两个节点。

当标记失效或恢复正常时，若nginx处于失效状态，则将所有服务标记为失效，并重启至关闭状态。此时，nginx的配置权重设为10，即等于120。在连接尝试10次后，若nginx接收到返回状态，并判断为失效，则会重新启动。在此期间，若nginx持续判断为失效，则会关闭并重启。由于所有服务均失效，nginx将它们重新设置为有效状态以监听，并将2个连接均匀分配至各服务。

当遇到HTTP错误状态时，nginx会记录那些设置权重为10的失效nginx配置，权重值分别为10和120。在配置了500、404、502、503、504等状态码之后，一旦HTTP状态码为500、502、503、504（以及默认情况）时，nginx会认定该请求为失败并记录其失败状态；而对于其他所有HTTP状态码，则不会记录为失败。