UDP Health Checks
This chapter describes how to configure different types of health checks for UDP servers in a load-balanced upstream server group.
Prerequisites
You have configured an upstream group of servers that handles UDP network traffic (DNS, RADIUS, syslog) in the
streamcontext, for example:stream {
...
upstream dns_upstream {
server 192.168.136.130:53;
server 192.168.136.131:53;
server 192.168.136.132:53;
}
...
}You have configured a server that passes UDP datagrams to the upstream server group:
stream {
...
server {
listen 53 udp;
proxy_pass dns_upstream;
proxy_timeout 1s;
proxy_responses 1;
error_log logs/dns.log;
}
...
}
See TCP and UDP Load Balancing for details.
Passive UDP Health Checks
NGINX can mark the server as unavailable and stop sending UDP datagrams to it for some time if the server replies with an error or times out.
The number of consecutive failed connection attempts within a certain time period is set with the max_fails parameter for an upstream server (default value is 1).
The time period is set with the fail_timeout parameter (default value is 10 seconds). The parameter also sets the amount of time that NGINX considers the server unavailable after marking it so.
So if a connection attempt times out or fails at least once in a 10‑second period, NGINX marks the server as unavailable for 10 seconds. The example shows how to set these parameters to 2 failures within 60 seconds:
upstream dns_upstream {
server 192.168.136.130:53 fail_timeout=60s;
server 192.168.136.131:53 fail_timeout=60s;
}
Active UDP Health Checks
Active Health Checks allow testing a wider range of failure types and are available only for NGINX Plus. For example, instead of waiting for an actual TCP request from a DNS client to fail before marking the DNS server as down (as in passive health checks), NGINX Plus will send special health check requests to each upstream server and check for a response that satisfies certain conditions. If a connection to the server cannot be established, the health check fails, and the server is considered unhealthy. NGINX Plus does not proxy client connections to unhealthy servers. If more than one health check is defined, the failure of any check is enough to consider the corresponding upstream server unhealthy.
To enable active health checks:
In the upstream group, specify a shared memory zone with the
zonedirective – a special area where the NGINX Plus worker processes share state information about counters and connections. In thezonedirective, specify the zone name (dns_zonein the example) and the zone size (64kin the example):stream {
...
upstream dns_upstream {
zone dns_zone 64k;
server 192.168.136.130:53;
server 192.168.136.131:53;
server 192.168.136.132:53;
}
...
}In the
serverblock that forwards traffic to the upstream group (viaproxy_pass), specify theudpparameter to thehealth_checkdirective:stream {
...
server {
listen 53 udp;
proxy_pass dns_upstream;
health_check udp;
}
...
}
A basic UDP health check assumes that nginx sends the “nginx health check” string to an upstream server and expects the absence of ICMP “Destination Unreachable” message in response. You can configure your own health check tests in the match {} block. See The “match {}” Configuration Block for details.
Fine-Tuning UDP Health Checks
You can fine-tune the health check by specifying the following parameters to the health_check directive:
interval– How often (in seconds) NGINX Plus sends health check requests (default is 5 seconds)passes– Number of consecutive health checks the server must respond to to be considered healthy (default is 1)fails– Number of consecutive health checks the server must fail to respond to to be considered unhealthy (default is 1)
server {
listen 53 udp;
proxy_pass dns_upstream;
health_check interval=20 passes=2 fails=2 udp;
}
In the example, the time between UDP health checks is increased to 20 seconds, the server is considered unhealthy after 2 consecutive failed health checks, and the server needs to pass 2 consecutive checks to be considered healthy again.
The “match {}” Configuration Block
You can verify server responses to health checks by configuring a number of tests. These tests are defined within the match {} configuration block.
In the top-level
stream{}context, specify thematch{}block and set its name, for example,udp_test:stream {
...
match udp_test {
...
}
}Refer to the block from the
health_checkdirective by including thematchparameter to specify the name of thematch{}block:stream {
...
server {
listen 53 udp;
proxy_pass dns_upstream;
health_check match=udp_test udp;
}
...
}In the
match{}block, specify conditions or tests under which a health check succeeds. This is done withsendandexpectparameters:send– The text string or hexadecimal literals (“/x” followed by two hex digits) to send to the serverexpect– Literal string or regular expression that the data returned by the server needs to match
These parameters can be used in different combinations, but no more than one
sendand oneexpectparameter can be specified at a time.
Example Test for NTP
To fine-tune health checks for NTP, you should specify both send and expect parameters with the following text strings:
match ntp {
send \xe3\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00;
expect ~* \x24;
}
Example Test for DNS
To fine-tune health checks for DNS, you should also specify both send and expect parameters with the following text strings:
match dns {
send \x00\x2a\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x03\x73\x74\x6c\x04\x75\x6d\x73\x6c\x03\x65\x64\x75\x00\x00\x01\x00\x01;
expect ~* "health.is.good";
}
UDP Health Checks的更多相关文章
- HTTP Health Checks
This article describes how to configure and use HTTP health checks in NGINX Plus and open source NGI ...
- Kong(V1.0.2) Health Checks and Circuit Breakers Reference
介绍 您可以让Kong代理的API使用ring-balancer,通过添加包含一个或多个目标实体的 upstream 实体进行配置,每个 target指向不同的IP地址(或主机名)和端口.ring-b ...
- TCP Health Checks
This chapter describes how to configure health checks for TCP. Introduction NGINX and NGINX Plus can ...
- Zookeeper Health Checks
Short Description: The article talks about the basic health checks to be performed when working on i ...
- Service Discovery And Health Checks In ASP.NET Core With Consul
在这篇文章中,我们将快速了解一下服务发现是什么,使用Consul在ASP.NET Core MVC框架中,并结合DnsClient.NET实现基于Dns的客户端服务发现 这篇文章的所有源代码都可以在G ...
- Using HAProxy as an API Gateway, Part 3 [Health Checks]
转自:https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-3-health-checks/ Achieving high ...
- NGINX Load Balancing – TCP and UDP Load Balancer
This chapter describes how to use NGINX Plus and open source NGINX to proxy and load balance TCP and ...
- 11g新特性:Health Monitor Checks
一.什么是Health Monitor ChecksHealth Monitor Checks能够发现文件损坏,物理.逻辑块损坏,undo.redo损坏,数据字典损坏等等.Health Monitor ...
- About Health Monitor Checks
About Health Monitor Checks Health Monitor checks (also known as checkers, health checks, or checks) ...
随机推荐
- [转]git图解(3):分支操作
本文转自:https://www.jianshu.com/p/342a9f8db004 title_img.png git 的分支是它最明显的特性, 大部分人听别人推荐使用git都会听到“git分 ...
- [转]innodb的锁时间
本文转自:https://www.cnblogs.com/sunss/p/3170132.html 观察innodb的锁时间,需要关注: mysqladmin extended-status -r - ...
- asp.net core webapi 生成导出excel
/// <summary> /// 下载订单 /// </summary> /// <param name="model"></param ...
- axios 中文文档(转载)
axios中文文档 转载来源:https://www.jianshu.com/p/7a9fbcbb1114 原始出处:lewis1990@amoy axios 基于promise用于浏览器和node. ...
- Spring中的JDBC模板类入门
1.Spring框架中提供了很多持久层的模板类来简化编程,使用模板类编写程序会变的简单 2.提供了JDBC模板,Spring框架提供的 *JdbcTemplate类 3.Spring框架可以整合Hib ...
- js 数据类型具体分析
复习 点运算符 xxx.sss xxx是对象 sss是属性和方法.任何数据类型都是拥有属性和方法的.字符串 String var st=“hello world”.字符串的定义 ...
- linux 中的单引号 和双引号有什么区别吗
单引号与双引号的最大不同在于双引号仍然可以保有变量的内容,但单引号内仅能是一般字符 ,而不会有特殊符号.我们以底下的例子做说明:假设您定义了一个变量, name=VBird ,现在想以 name 这个 ...
- Android Studio 学习(五)网络
HttpURLConnection OkHttp 添加依赖 编辑 app/build.gradle 在dependencies闭包中添加 implementation 'com.squareup.ok ...
- VM扩展磁盘大小
1.通过扩展磁盘的方法增大磁盘大小 2.然后开启Linux 此时查看磁盘 df -h 并没有增加,使用 fdisk -l 查看发现已经扩展 使用 root 用户,进入到 ~ 家目录下面. 3.使用 ...
- div添加cursor:pointer;失效问题。
如果你不小心给其它盒子设置了z-index属性显示在最上层而又没有将该盒子进行隐藏. <style> .bottom { position: absolute; width:100px; ...