Как создать проверку работоспособности MongoDB в HAProxy?

Прежде всего, стоит отметить, что вам нужно будет запустить HAProxy 1.5 или новее, чтобы использовать tcp-check функция (на момент написания этого ответа 1.5.3 является текущей стабильной версией). К сожалению, Ubuntu 14.04 (например) поставляется с версией 1.4, поэтому вам нужно будет установить из другого источника. Лично я использовал пакеты отсюда чтобы я мог все установить через apt.

Пример, приведенный в блоге, является хорошей отправной точкой. Используя его в качестве шаблона, все, что нам нужно сделать, это выбрать соответствующую команду для запуска, затем разбить эту команду на шестнадцатеричный код и построить соответствующую проверку для MongoDB. В MongoDB проводной протокол задокументирован и опубликован, поэтому теоретически вы можете построить его на основе спецификации, но есть более простые способы деконструировать такую ​​команду. Есть встроенные диссекторы в Wireshark которые позволяют вам проверять трафик MongoDB и обеспечивают удобный просмотр шестнадцатеричного кода с выделением, чтобы помочь нам в наших усилиях.

Здесь мы будем использовать команду команда ping. Как и следовало ожидать, он должен быть легким и возвращаться даже с сервера при большой нагрузке, что делает его хорошо подходящим для команды проверки работоспособности. Любая такая команда может быть написана с использованием той же методологии, если вы хотите использовать что-то еще, но всегда будьте осторожны с использованием команды, которая требует блокировки любого типа или может добавить нагрузку в вашу базу данных.

Чтобы проиллюстрировать, как перейти от выполняемой вами команды к гексагону, вот небольшой снимок созданной мной команды, выделенной в Wireshark, будучи декодированы:

Основываясь на этой информации, давайте создадим наш TCP проверка здоровья. Я прокомментирую различные части, чтобы объяснить, откуда они взялись, и каждую из них должно быть достаточно легко найти на рисунке выше:

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

Было бы неплохо использовать полное двоичное совпадение и в ответе, но, к сожалению, нет способа предсказать идентификатор запроса, сгенерированный сервером для каждого ответа, поэтому такое полное совпадение не удастся (нет возможности выборочно игнорировать части двоичного совпадения).

РЕДАКТИРОВАТЬ: 8 сентября 2014 г. Благодаря комментариям из этого вопроса и ответа от Батист и Феликс Я вернулся, чтобы повторно протестировать частичное двоичное совпадение, которое, казалось, изначально не удалось - похоже, это был просто случай, когда я неправильно расшифровал двоичный файл для ответа, поэтому я изменил ответ, чтобы отразить это.

Строка «ok» - это просто проверка ОК - любой такой ответ будет означать, что рассматриваемый сервер все еще отвечает, но ограниченная проверка в некоторой степени неудовлетворительна. Хотя полная проверка ответа невозможна, можно использовать все, что находится после идентификатора запроса.

Следовательно, вот рабочая бинарная проверка пригодной для использования части ответа с разбивкой, снова с использованием 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

Все вышеперечисленное было успешно протестировано с MongoDB 2.6.4 и HAProxy 1.5.3.

Ответ Адама правильный, и я тоже использую процедуру. Тем не менее, не уверен, что ответ правильный, поскольку сервер также должен отвечать на двоичные строки. Адам, вы можете подтвердить, что это работает на вашем примере? В противном случае совпадение 6f6b тоже должно помочь:

tcp-check ожидает двоичный 6f6b

Батист