OpenVPN NFS 性能不佳

Question

我在弹性负载均衡器后面有 EC2 应用程序服务器。所有应用服务器都可以访问共享存储服务器，特别是用于集中缓存文件、日志记录等。共享存储服务器通过 OpenVPN 实现 NFS 来完成其工作。所有服务器都在同一个可用区中，并通过内部网络相互通信。但是，共享存储解决方案会导致异常高的 CPU 和延迟，如果存储是 100% 本地，则通常不存在这种情况。预计此设置会导致性能略有下降，但在这种情况下，CPU 已上升且输出已减慢 2-3 倍

所以，这是一个两部分的问题：

1. 我该怎么做才能更好地了解罪魁祸首是什么？我知道它是 OpenVPN 和 NFS 的组合，但是我可以确定读取和写入最多的特定文件吗？或者我可以很容易地说出瓶颈在哪里？

2. 有没有人仅仅根据上述信息提出建议？有没有更好的方法在基于云的环境中跨服务器共享文件？（请不要回复“使用 S3”，因为这不适合即时/临时文件要求）

谢谢！

Answer 1

确保 openvpn 隧道的链接 MTU 设置准确，以免出现两次碎片（一次在主机上从 8192 字节到 1500 字节，一次在 openvpn 上从 1500 字节到 1400 字节或其他）。openvpn 处理设置接口 mtu 的能力非常差（积极阻碍正确设置 mtu 的尝试）。

检查通过和绕过隧道的不同数据包大小的延迟。绘制并寻找问题。

在隧道外设置一个测试 NFS 并进行一些性能测量，以确定 openvpn 是否是问题所在。

尝试不同版本的 NFS，包括 TCP 和 UDP。

尝试启用主动缓存和异步 I/O。

以下是关于openvpn WRT MTU的“主动阻碍”的吐槽（由“请求”添加）

是的。设置 tun-mtu 会导致 openvpn 生成WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1413). I don't use--mssfix或--fragment.

此外，在配置中设置静态 MTU 是愚蠢且容易出错的，它需要是动态的。所以，你使用“mtu-disc yes”，对吗？当然，除了它传递给启动脚本的值是 off-by-14（尽管我使用 TAP 来支持 IPv6，这可能会神秘地混淆它）。所以我需要/sbin/ifconfig $1 mtu $(($2-14)) up获得正确的值（正确的意思是一个值，它将导致隧道数据包不会因为它们太大而成为碎片或丢弃）。

我很难想象这样一种情况，即将接口 MTU 设置为正确的值不是一个好主意，至少如果您没有设置片段（并且您永远不应该设置片段，至少您的网络罪孽会困扰您）。如果稍后由于初始化后的网络更改而出现需要片段的错误，它也应该动态更改接口 MTU。

MSS 完全是错误的网络层来完成这项工作。如果您正确配置了接口 MTU，Path-MTU 发现、MSS 和一切都可以正常工作。如果你不这样做，有些事情可能有点工作，有些事情不会，哪些工作取决于真正的数据包是从 openvpn 主机还是其他主机发送的。哦，如果 MTU 是不对称的（并非完全不常见），请不要让我开始讨论什么会失败。

我认为 OpenVPN 是由没有很多网络和系统管理员经验的人编写的，他们糟糕的选择在配置和数据结构/API 中被硬编码。他们在灵活和健全的网络配置和集成方面确实做得不好（这只是几个例子之一）。可悲的是，它比其他解决方案好数百倍，这使我成为 OpenVPN 的支持者。例如，Cisco VPN 就是一个缺陷。