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 stream context, 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:

  1. In the upstream group, specify a shared memory zone with the zone directive – a special area where the NGINX Plus worker processes share state information about counters and connections. In the zone directive, specify the zone name (dns_zone in the example) and the zone size (64k in 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;
    }
    ...
    }
  2. In the server block that forwards traffic to the upstream group (via proxy_pass), specify the udp parameter to the health_check directive:

    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 the match {} block and set its name, for example, udp_test:

    stream {
    ...
    match udp_test {
    ...
    }
    }
  • Refer to the block from the health_check directive by including the match parameter to specify the name of the match {} 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 with send and expect parameters:

    • send – The text string or hexadecimal literals (“/x” followed by two hex digits) to send to the server
    • expect – 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 send and one expect parameter 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的更多相关文章

  1. HTTP Health Checks

    This article describes how to configure and use HTTP health checks in NGINX Plus and open source NGI ...

  2. Kong(V1.0.2) Health Checks and Circuit Breakers Reference

    介绍 您可以让Kong代理的API使用ring-balancer,通过添加包含一个或多个目标实体的 upstream 实体进行配置,每个 target指向不同的IP地址(或主机名)和端口.ring-b ...

  3. TCP Health Checks

    This chapter describes how to configure health checks for TCP. Introduction NGINX and NGINX Plus can ...

  4. Zookeeper Health Checks

    Short Description: The article talks about the basic health checks to be performed when working on i ...

  5. Service Discovery And Health Checks In ASP.NET Core With Consul

    在这篇文章中,我们将快速了解一下服务发现是什么,使用Consul在ASP.NET Core MVC框架中,并结合DnsClient.NET实现基于Dns的客户端服务发现 这篇文章的所有源代码都可以在G ...

  6. 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 ...

  7. 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 ...

  8. 11g新特性:Health Monitor Checks

    一.什么是Health Monitor ChecksHealth Monitor Checks能够发现文件损坏,物理.逻辑块损坏,undo.redo损坏,数据字典损坏等等.Health Monitor ...

  9. About Health Monitor Checks

    About Health Monitor Checks Health Monitor checks (also known as checkers, health checks, or checks) ...

随机推荐

  1. 从零开始学安全(二十三)●用PHP编写留言板

    <?php include("test.php"); ?> <!DOCTYPE html> <html> <head> <me ...

  2. [android] 内容观察者

    拦截短信,比如当发短信的时候,就把短信读取出来,当系统的短信发生变化的时候,大叫一声,把数据发送到公共的消息邮箱里面,我们的应用通过内容观察者观察公共的消息邮箱 获取ContentResolver对象 ...

  3. PHP程序员解决问题的能力

    这个话题老生长谈了,在面试中必然考核的能力中,我个人认为解决问题能力是排第一位的,比学习能力优先级更高.解决问题的能力既能看出程序员的思维能力,应变能力,探索能力等,又可以看出他的经验.如果解决问题能 ...

  4. Netty实战三之Netty的组件和设计

    有关Netty,我们可以从两个视角来讨论Netty:类库的视角以及框架的视角,对于使用Netty编写高效的.可重用的和可维护的代码来说,两者缺一不可. Netty解决了两个响应的关注领域,可以大致标志 ...

  5. 【Spring】29、SpringBoot中@SpringBootApplication的使用

    之前用户使用的是3个注解注解他们的main类.分别是@Configuration,@EnableAutoConfiguration,@ComponentScan.由于这些注解一般都是一起使用,spri ...

  6. GitHub上fork一个项目贡献代码以及同步原作者的修改【转】

    如何贡献自己的力量 首先你总得有自己的github帐号吧,注册一个,非常简单,只需用户名,邮箱,密码,邮箱只是用来找回密码的,不做验证.因此注册后立即能用!比如我现在新注册一个叫JsLouvre的示范 ...

  7. js 面向对象 ES5 AND ES6

    1. ES5实现 父类: // 职员类 function Employees(id,name,salary) { // 属性 this.id = id; this.name = name; this. ...

  8. canvas-8searchLight4.html

    <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8&quo ...

  9. K8S 调度器,预选策略,优选函数

    Kubernetes Scheduler 提供的调度流程分三步: 预选策略(predicate) 遍历nodelist,选择出符合要求的候选节点,Kubernetes内置了多种预选规则供用户选择. 优 ...

  10. springboot 开发 Tars

    1,创建 springboot 项目,并在启动类添加 @EnableTarsServer 注解 @SpringBootApplication @EnableTarsServer public clas ...