У меня есть haproxy перед трехузловым кластером ES (elasticsearch). Пока что я проверяю каждый узел в haproxy с помощью httpcheck. Bellow - это фрагмент моей конфигурации:
backend elastic_nodes
balance roundrobin
option forwardfor
option httpchk
http-check expect status 200
server elastic1 10.88.0.101:9200 check port 9200 fall 3 rise 3
server elastic2 10.88.0.102:9200 check port 9200 fall 3 rise 3
server elastic3 10.88.0.103:9200 check port 9200 fall 3 rise 3
Пока эта проверка работает нормально, но если кластер становится красным, код ответа по-прежнему равен «200» (это правильно, поскольку узел доступен по http), что заставит haproxy считать внутренний сервер работоспособным.
С другой стороны, если я проверю состояние кластера и помечу узел как неработающий после получения статуса работоспособности «Красный», это пометит все внутренние серверы как неработающие, что приведет к отключению службы ES. Моя проблема с этим подходом заключается в том, что в прошлом мой кластер действительно был красным, но его можно было использовать, поскольку отсутствовал только один осколок (дневной журнал). Другими словами, бывают случаи, когда статус ES Red не является большой проблемой, и вы хотите по-прежнему обслуживать запросы ES (вместо того, чтобы отмечать все внутренние узлы с помощью haproxy, эту блокирующую службу ES).
Есть ли другой подход к этому?
Мы используем HAproxy для балансировки двух избыточных кластеров. При нормальной работе каждый получает ~ 50% трафика; при необходимости каждый из них может принимать 100%.
Недавно мы столкнулись с ошибкой, связанной с ошибкой, которую мы не планировали: все клиентские и главные узлы не работали, поэтому наш кластер реагировал на REST, но все узлы данных были временно отключены, все индексы выглядели красными и пустыми, а запросы к они вернули 0 результатов. Но с 200, следуя соглашению REST.
В данном случае наша простая проверка работоспособности HAproxy не удалась; он просто проверил 200 секунд.
Сейчас я изучаю использование http-check expect ! string red
с URI, который напрямую нацелен на интересующий индекс. Я не использовал более продвинутый http-check
особенности раньше.
Более дорогая проверка, но она должна правильно удалить клиентские узлы для лоботомизированного кластера из пула.
ОБНОВЛЕНИЕ (2): Я переключил нас на использование
option httpchk get /_cat/indices/<index of interest>
http-check expect rstring \b(green|yellow)\b
и это действительно похоже на лучший тест.
(Вторая редакция: использование явной проверки для green
или yellow
вместо того, чтобы просто не-красный, запоздало подумал о том, что индекс полностью отсутствует в _cat
слесарь ..._