Comments 12
Я бы не стал внутри сети закрывать «HTTP/HTTPS за ненадобностью», так как банально может пригодится доступ к внутреннему интерфейсу для внутренних пользователей — зачем им выходить в мир, что бы попасть на свой же сервис.
Так же хотел бы услышать, как при такой конфигурации происходит деплой приложений. Возможно ли это сделать «на лету»?
Так же хотел бы услышать, как при такой конфигурации происходит деплой приложений. Возможно ли это сделать «на лету»?
Вообще, JBoss вроде бы умеет нормально редеплоить приложения, т.е. практически на лету. У нас на работе аналогичная конфигурация с томкатами — стопится первый, закидывается новый варник, стартует первый, стопится второй итд. Даунтайм равен нулю, не вижу проблем, кроме необходимости легкой автоматизации администратором.
Ну, закрытие HTTP/HTTPS скорее подсказка необычного решения, а не руководство к действию — кому-то интересно, кому-то нет. Да, вы правы, с доступом внутренних пользователей возникнут проблемы, особенно если они хотят посмотреть что происходит на конкретном сервере приложений, а не абстрактном, выбранном балансировщиком. С другой стороны, например, наши админы редко пользуются той же jmx-консолью, так что лично я серьезно подумываю о том, чтобы таки закрыть коннекторы.
Насчет деплоя — зависит от вашей бизнес-логики. У меня есть система, в которой данное решение дало возможность выполнять «на горячую» любые действия (обновление, изменение конфигурации) с перезапуском JBoss-а, при этом оставаясь онлайн. Останавливается один узел, Apache это видит, перенаправляет запросы на другой узел, все прозрачно для внешних клиентов. При обновлении, после запуска ранее остановленного узла, он включается в кластер, НО важный момент — в этот период времени на разных узлах запросы обрабатывает разная версия вашего ПО. После обновления и перезапуска второго узла, версии соответственно уравниваются. Это пример для режима standalone, именно поэтому я его использую. Насколько я понял, режим domain использует совсем другие принципы, там обновлением управляет главный узел, а не человек. Для нас такой подход к версионности промышленного ПО приемлем, для кого-то — нет. Система обрабатывает не связанные между собой запросы к веб-сервисам, поэтому после восстановления работоспособности обоих узлов нагрузка сразу равномерно распределяется по мере поступления новых запросов.
С «приклеенными» сессиями такого не будет: если посреди рабочего дня перезапустить один узел, все пользователи приклеятся к другому, и останутся там пока не выйдут из системы, перезапущенный будет простаивать. Что делать с этим во второй нашей системе я еще не думал, скорее всего, такого вольного обращения с серверами приложений в этом случае уже не получится.
Насчет деплоя — зависит от вашей бизнес-логики. У меня есть система, в которой данное решение дало возможность выполнять «на горячую» любые действия (обновление, изменение конфигурации) с перезапуском JBoss-а, при этом оставаясь онлайн. Останавливается один узел, Apache это видит, перенаправляет запросы на другой узел, все прозрачно для внешних клиентов. При обновлении, после запуска ранее остановленного узла, он включается в кластер, НО важный момент — в этот период времени на разных узлах запросы обрабатывает разная версия вашего ПО. После обновления и перезапуска второго узла, версии соответственно уравниваются. Это пример для режима standalone, именно поэтому я его использую. Насколько я понял, режим domain использует совсем другие принципы, там обновлением управляет главный узел, а не человек. Для нас такой подход к версионности промышленного ПО приемлем, для кого-то — нет. Система обрабатывает не связанные между собой запросы к веб-сервисам, поэтому после восстановления работоспособности обоих узлов нагрузка сразу равномерно распределяется по мере поступления новых запросов.
С «приклеенными» сессиями такого не будет: если посреди рабочего дня перезапустить один узел, все пользователи приклеятся к другому, и останутся там пока не выйдут из системы, перезапущенный будет простаивать. Что делать с этим во второй нашей системе я еще не думал, скорее всего, такого вольного обращения с серверами приложений в этом случае уже не получится.
А рассматривали ли вы вариант с Nginx вместо Apache? Какие плюсы/минусы могут быть в данном случае?
Отвечу за автора — nginx не умеет AJP, но для связи с бэкендами по HTTP — вполне подойдёт. У него есть балансировка, и она будет работать честно. В случае с описанной конфигурацией (с репликацией сессий по всем аппсерверам) — все будет работать правильно.
Спасибо за подсказку, я незнаком с nginx. Слышал, что nginx более производителен в сравнении с Apache. На личном опыте скажу, что и Apache очень шустр. У нас когда-то при переходе на кластер, Apache поставили на тот же сервер, что и один из узлов. Каких-то проблем с производительностью замечено не было, несмотря на то, что в обычном режиме работы JBoss-а на этом сервере, он забирает 80-95% процессорного времени. Думаю, что до тех пор, пока количество запросов в сутки не перевалило семизначные цифры, можно не беспокоиться о производительности Apache.
Всегда пожалуйста.
В ближайшем рассмотрении, подумайте о том, что nginx-ом стоит отдавать статику — он делает это гораздо лучше апача — экономя память, и CPU. А «динамику» в таком случае можно отдавать цепочкой nginx -> Apache -> JBoss. Это сохранит имеющуюся конфигурацию, и добавит снаружи от неё лишь один элемент — сервер с nginx-ом.
Настроить это достаточно просто — если у вас есть коллеги/друзья, хотя бы более-менее знающие nginx, то за полдня-день неспешно можно всё понять и сделать.
А в JBoss видимо так и остался тяжеловесным на сетевые соединения, что печально :(
Успехов!
В ближайшем рассмотрении, подумайте о том, что nginx-ом стоит отдавать статику — он делает это гораздо лучше апача — экономя память, и CPU. А «динамику» в таком случае можно отдавать цепочкой nginx -> Apache -> JBoss. Это сохранит имеющуюся конфигурацию, и добавит снаружи от неё лишь один элемент — сервер с nginx-ом.
Настроить это достаточно просто — если у вас есть коллеги/друзья, хотя бы более-менее знающие nginx, то за полдня-день неспешно можно всё понять и сделать.
А в JBoss видимо так и остался тяжеловесным на сетевые соединения, что печально :(
Успехов!
Печально что полезная техническая статья за пару часов набрала 0 рейтинга и далека до попадания в захабренные.
Спасибо за моральную поддержку! Но я при написании статей думаю не только о хабросообществе или своем личном рейтинге (хотя и об этом тоже, конечно), но и о любых IT-специалистах, бродящих по Сети в поисках нужной информации. Я сам по крупинкам собирал рецепты для этой статьи из источников, в которых даже не зарегистрирован. Надеюсь, что немало людей, не зарегистрированных на Хабре прочитают статью и узнают из нее что-то новое. Я это к тому, что рейтинг любых статей на Хабре — это лишь часть их жизни в Сети, и даже будучи глубоко в архивах они могут приносить немало пользы.
В качестве бесплатного балансировщика я бы посоветовал использовать более гибкий и быстрый haproxy + heartbeat он умеет много больше того, что умее nginx или apache + mod_ajp, плюс умеет ssl offloading. Скажите, у меня вопрос больше по предыдущей статье, любое приложение написанное под jboss 7 имеет репликацию сессий на все ноды кластера?
Вот тут пишут что с heartbeat могут быть проблемы. Не исключаю того, что это только с Apache (или вообще, конкретно их конфигурация неудачная), и с haproxy проблем нет. У вас есть практический опыт применения haproxy + heartbeat, скажите, как работает — стабильно?
По поводу ssl offloading (насколько я понял, более употребимый термин SSL acceleration) — стыдно признавать, впервые услышал о существовании подобной технологии. Опять же, если есть опыт применения, черканёте пару слов?
Любое стандартное веб-приложение (обычно, с расширением .war), развернутое на JBoss 7, в случае добавления в web.xml тэга <distributable/> получит репликацию сессий.
По поводу ssl offloading (насколько я понял, более употребимый термин SSL acceleration) — стыдно признавать, впервые услышал о существовании подобной технологии. Опять же, если есть опыт применения, черканёте пару слов?
Любое стандартное веб-приложение (обычно, с расширением .war), развернутое на JBoss 7, в случае добавления в web.xml тэга <distributable/> получит репликацию сессий.
Sign up to leave a comment.
Кластер JBoss 7 — балансировка нагрузки с помощью Apache