服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 如何在HAProxy中构buildMongoDB健康检查？
Intereting Posts
尽pipe被列入黑名单，但nmap列出了主机 Route53仅适用于通配符子域 设置Google云端DNSpipe理员angular色 crontab计划每X小时 Windows 8客户端无法打开来自OSX Mountain Lion Server的SMB共享的特定文件夹 – 来自同一台服务器的所有其他共享都可以 如何有一个Web服务器解决PHP文件的URL？ 有没有办法检查lighttpd中的客户端证书颁发者？ 通过GP添加快捷方式 – 程序文件与程序文件（x86） OAS日志文件填满硬盘驱动器 apache2挂在“发送回复”/“优雅地完成” 如何从Ubuntu的RAID 1arrays删除交换分区？ 基本的nginxconfiguration（将URL映射到文件并隐藏其他所有内容） 我可以同时使用apache和nginx来为我的网站服务吗？ DOMAIN \用户名和用户login名之间的区别导致.NET授权规则的问题 不能上传.htpasswd

如何在HAProxy中构buildMongoDB健康检查？

在HAProxy博客上有一个fastcgi二进制健康检查的例子。 我将如何构build一个类似的检查MongoDB，这样我正在做一个更健壮的健康检查MongoDB – validation服务器是否真的在那里和响应，而不是只是检查端口是否打开？

如果运行状况检查足够通用以适用于各种MongoDB分片组件（configuration服务器， mongos ， mongod ），那将会很有用。

首先，值得注意的是，为了使用tcp-checkfunction，您必须运行HAProxy 1.5或更高版本（至于编写这个答案，1.5.3是当前的稳定版本）。 不幸的是Ubuntu 14.04（例如）带有1.4版本，所以你需要从另一个来源安装。 就我个人而言，我使用了来自这里的软件包，以便通过apt来保持所有的安装。

在博客上列出的例子是一个很好的起点。 使用它作为模板，我们所需要做的就是select一个合适的命令来运行，然后将该命令分解为hex，并为MongoDB构build合适的检查。 MongoDB 有线协议被logging和发布，所以理论上你可以根据规范构build它，但是有更简单的方法来解构这样的命令。 在Wireshark中build立了parsing器，允许你检查MongoDB的stream量，它提供了hex的方便的视图，突出显示，以帮助我们在这里的努力。

我们将在这里使用的命令是ping命令 。 正如您所期望的那样，它的目标是轻量级的，甚至可以在重负载的服务器上返回，这使得它非常适合用于健康检查命令。 任何这样的命令都可以使用相同的方法编写，如果你想使用其他的东西，但总是要小心使用需要任何types的锁的命令，或者可以加载到你的数据库。

为了说明如何从命令中运行到hex，下面是我在Wireshark突出显示的命令的一小部分，已经被解码：

在wireshark的ping命令

根据这些信息，我们来创build我们的TCP健康检查。 我会对各个部分发表评论，解释他们来自哪里，每个人都应该很容易在上面的抓取中find： 

 option tcp-check # MongoDB Wire Protocol tcp-check send-binary 39000000 # Message Length (57) tcp-check send-binary EEEEEEEE # Request ID (random value) tcp-check send-binary 00000000 # Response To (nothing) tcp-check send-binary d4070000 # OpCode (Query) tcp-check send-binary 00000000 # Query Flags tcp-check send-binary 746573742e # fullCollectionName (test.$cmd) tcp-check send-binary 24636d6400 # continued tcp-check send-binary 00000000 # NumToSkip tcp-check send-binary FFFFFFFF # NumToReturn # Start of Document tcp-check send-binary 13000000 # Document Length (19) tcp-check send-binary 01 # Type (Double) tcp-check send-binary 70696e6700 # Ping: tcp-check send-binary 000000000000f03f # Value : 1 tcp-check send-binary 00 # Term tcp-check expect string ok

在响应中使用完整的二进制匹配也不错，但不幸的是，没有办法预测服务器为每个响应生成的请求ID，因此这样的完全匹配将失败（没有办法有select地忽略）的二进制匹配）。

编辑：9月8日2014感谢来自Baptiste和费利克斯这个问答的评论我回去重新testing似乎最初失败的部分二进制匹配 – 看起来像只是我的抄录二进制不正确的响应，所以我已经修改了答案来反映这一点。

“OK”string只是一个OK检查 – 任何这样的响应将意味着有问题的服务器仍在响应，但有限的检查有点令人不满意。 虽然完整的响应检查是不可能的，但在请求ID之后的所有内容都是可用的。

因此，这里是工作二进制检查的响应的可用部分分解，再次使用Wireshark梳理件如上： 

 # Check for response (starting after request ID) tcp-check expect binary EEEEEEEE # Response To (from the check above) tcp-check expect binary 01000000 # OpCode (Reply) tcp-check expect binary 00000000 # Reply Flags (none) tcp-check expect binary 0000000000000000# Cursor ID (0) tcp-check expect binary 00000000 # Starting From (0) tcp-check expect binary 11000000 # Document Length (17) tcp-check expect binary 01 # Type (Double) tcp-check expect binary 6f6b # ok tcp-check expect binary 00000000000000f03f # value: 1 tcp-check expect binary 00 # term

以上所有的testing都使用了MongoDB 2.6.4和HAProxy 1.5.3

Adam的答案是正确的，程序也是我使用的。 也就是说，不确定响应是否正确，因为服务器也应该回答二进制string。 亚当，你能证实它适用于你的榜样吗？ 否则，匹配6f6b也应该做的伎俩：

tcp检查期望二进制6f6b

巴蒂斯特