У меня есть три экземпляра Tomcat, работающих за HAProxy. Когда я выкладываю изменения в свои веб-приложения, я хотел бы выполнить скользящее развертывание (т. Е. Отказываться от одного Tomcat за раз), чтобы пользователи не видели простоев.
Как мне это сделать? Я вижу, что работающий экземпляр haproxy можно перенастроить в горячем режиме (что хорошо для добавления или удаления новых серверов пула), но как HAProxy реагирует, когда один из его целевых серверов временно не работает?
Если есть лучшее решение, чем HAProxy, я бы тоже хотел взглянуть на него.
Спасибо!
Я отправил электронное письмо Вилли Тарро и получил следующие варианты:
Вы можете использовать горячую реконфигурацию или команды socat для сервера статистики, чтобы установить вес вашего целевого сервера равным 0. Это предотвратит балансировку новых сеансов с этим сервером, но не повлияет на существующие соединения.
Вы можете установить опцию http-check disable-on-404 в сочетании с опцией httpcheck / myurl, а затем заставить целевые серверы отвечать на / myurl так, чтобы они отправляли статус 200, если все в порядке, 404, если сервер должен перестать получать новые запросы и 500, если сервер не должен ничего получать (т.е. когда вы готовы отскочить от сервера). haproxy выполнит повторную проверку на сервере с интервалом, указанным в строке вашего сервера.
Таким образом, HAProxy не поддерживает удаление без перенастройки согласно @Эрнест Мюллер в его ответ, Я предоставлю вам альтернативу, если вы запросили и другие сценарии.
я использую LVS, который является одним из моих любимых решений для балансировки нагрузки, поскольку его можно использовать не только для HTTP.
С LVS вы можете использовать ipvsadm для добавления и удаления серверов вручную. Пример удаления - следующая команда:
/sbin/ipvsadm -e -t VIP:443 -r SERVERIP:443 -g -w WEIGHT
В отличие от добавления и удаления вручную, взаимодействуя с LVS, я часто предпочитаю использовать request вариант с ldirectord. ldirector - это демон, который опрашивает вашу конфигурацию ipvs и управляет ею. Вы можете указать файл с путем URI, используя этот параметр. Во время развертывания вы удаляете файл и ждете, пока к серверу прекратится доступ. На этом этапе вы можете развернуть код, не затрагивая рабочих клиентов.
Во многом это зависит от того, выполняете ли вы какое-либо управление сеансом / состоянием на Tomcats. Если сеанс пользователя разрушен перезапуском, то прокатка не предотвращает воздействия на пользователя (это может помешать им увидеть 500, но не начинать сеанс заново). Если вы не используете липкие сеансы, вам, вероятно, не стоит об этом беспокоиться.
У HAproxy и других балансировщиков нагрузки есть способы довольно быстро определить, работает ли сервер, стоящий за ним, и перенаправить трафик на основе этого («проверка работоспособности» в HAProxy). Однако сделать это идеально для них невозможно. В Tomcat нет только «вверх» и «вниз»; есть «вверх, как при ответе на порт, но пока что не готово». Таким образом, вам не следует полагаться на LB, чтобы полностью предотвратить воздействие на пользователя - даже при хорошей проверке работоспособности будет интервал, когда вы будете получать трафик на плохой узел.
Что мы делаем при скользящем развертывании, так это активно выводим сервер из балансировщика нагрузки, затем вмешиваемся / перезапускаем узел, ждем, пока он пройдет автоматический тест / монитор, затем вставляем его обратно, а затем переходим к следующему серверу. Это проще с балансировщиком нагрузки, у которого есть API, который вы можете вызвать удаленно (например, из сценария) для отключения сервера - наш старый Netscaler делал это, а HAProxy - нет. С HAProxy вам либо нужно отредактировать конфигурацию и перезапустить (грустно), либо вы можете изменить проверку работоспособности так, чтобы вы могли ею манипулировать - например, может быть, она проверяет волшебный файл, который вы переименовываете, когда вы хотите, чтобы он пропустил этот узел. Вам нужно подождать, пока сработает проверка работоспособности и узел не выйдет из кластера, но тогда все будет в порядке.
Я наткнулся эта почта у которого есть решение этой проблемы, связанное с iptables ...