☰

Docker 容器的 Bind9 性能问题

tag-icon • tag-icon 18.04 docker dyndns
Docker 容器的 Bind9 性能问题

我们正在运行一项通过服务器上的一些 Docker 容器托管的服务。这些容器中的应用程序向大约 300 台机器的本地集群发出一些非常频繁的请求。有两个本地 DNS 服务器（主服务器和辅助服务器）运行 bind9，托管本地机器的区域文件。主服务器似乎无法处理负载，一些 DNS 查询似乎超时并溢出到辅助服务器。在辅助服务器上，我们在查询日志中看到持续缓慢的查询流。

我尝试增加主服务器上的线程数，但似乎没有帮助。Docker 容器中没有 DNS 缓存，我们试图避免触及 Docker 映像以添加任何缓存机制。DNS 服务器运行在两个六核处理器上，配有 64GB RAM。硬件似乎不是这里的瓶颈。我们想知道是否存在明显的 bind 调整参数，而我们忽略了它。

我们全部运行的是 Ubuntu Linux 18.04。

绑定版本：BIND 9.11.3-1ubuntu1.9-Ubuntu (Extended Support Version) <id:a375815>

命名的.conf.选项：

    options {
        directory "/var/cache/bind";
       forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        dnssec-validation auto;
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

答案1

因此，我完成了调查，并找到了我们在环境中观察到的行为的令人满意的答案。当我注意到辅助 DNS 服务器上的 DNS 查询时，我假设主 DNS 服务器存在性能问题。我继续挖掘这个假设，并继续尝试提高性能或查找主服务器的问题。

但经过深入研究，我发现 systemd-resolved 的工作方式是，一旦“当前”服务器出现延迟/故障，它就会切换 DNS 服务器。然后它会坚持使用较新的服务器，直到出现故障，然后再切换回原始服务器。此流量为 UDP，由于请求和客户端数量如此之多，因此很有可能出现数据包丢失的情况，并且服务器会不断切换。这似乎不会造成太多性能问题，实际上最终会将负载分散到多个服务器上。所以我就此打住。

尽管在 systemd github 上对此行为进行了激烈的讨论：https://github.com/systemd/systemd/issues/5755

此外，在我尝试提高 BIND 服务器的性能的过程中，我发现了一些可能有用的资源：

相关内容