mod_proxy vs mod_proxy_ajp vs mod_jk


9

Ми готуємося до міграції з наступного середовища:

Apache 2.0.2 --AJP -> JBoss4.2.2

до

Apache 2.2.3 - ??? -> JBoss 5.1.0

Як би ви об'єдналися вдвох?

Варіанти:

  1. Класичний AJP (означає побудову mod_jk для Apache)
  2. mod_proxy (пересилання HTTP-запитів на JBoss)
  3. mod_proxy_ajp

Варіант 2 є найпопулярнішим рішенням на даний момент, оскільки він, мабуть, означає меншу обробку через те, що більше не потрібно перекладати відповіді JBoss з AJP, а час процесора - це те, що нам потрібно пильно слідкувати в нашій інфраструктурі. Варіанти 2 і 3 також вбудовані у версію Apache, підтримувану Red Hat.

На даний момент я не бачу, як ми підемо на варіант 1, оскільки ми отримуємо AJP "безкоштовно" з опцією 3.

Отже, які плюси і мінуси варіантів 2 і 3? Чи є стурбованість завантаженням процесора справді щось, про що ми повинні турбуватися? Що ми втрачаємо при обробці двійкових даних (AJP-трафік), чи повертаємося ми зі зменшеною пропускною здатністю та IO?

Наша інфраструктура буде Apache, яка буде готувати до 9 сильно налаштованих JBosses (але зазвичай приблизно наполовину), все на тій же машині RHEL 5, яка віртуалізується в приватній хмарі.

Заздалегідь дякую за будь-які вказівки / поради.

Багатий

Відповіді:


8

2 mod_proxy_http, якщо вам не потрібен заголовок хоста від клієнта.

Я не рекомендую класичний mod_jk, оскільки його функціональність була замінена mod_proxy_ajp, і, як ви самі сказали, він вимагає самостійно створювати та підтримувати цей модуль.

Я думаю, що mod_proxy_http - це дуже чисте рішення, і це знімає ajp із зображення. Однак вам слід знати про кілька застережень щодо переходу від ajp до http. Якщо вам потрібен доступ до заголовків серверів саме так, як вони були отримані apache (включаючи заголовок Host), вам слід скористатися ajp. JBoss побачить новий http-запит, що надходить від apache, а не від оригінального клієнта. Якщо вам потрібен лише віддалений IP-клієнт, ви все одно можете отримати це за допомогою спеціального заголовка, який апаш може встановлювати для нових запитів. Однак якщо ви робите віртуальний хостинг із шару додатків, вам краще пограти з ajp.

Що стосується продуктивності, або ajp, або http вимагатиме певної обробки JBoss та деякого локального сокета TCP-трафіку. Вам доведеться спробувати обидва, щоб побачити, що є більш ефективним, але я думаю, що в цілому це дуже невеликий відсоток від загального завантаження сервера. HTTP - це складніший протокол, а ajp - спеціально розроблений для ефективної роботи між веб-рівнями та рівнями додатків, тому теоретично ajp, ймовірно, краще. При цьому я виявив, що http часто краще підтримується за межами лінії сервера додатків Tomcat.

Я використовую mod_proxy_ajp та mod_proxy_http, і у мене жодних проблем не було.


HostТема буде отримати пройшли через правильно , якщо ви використовуєтеProxyPreserveHost On
Дерф

Під час роботи з Apache mod_proxy дивіться на httpd.apache.org/docs/2.4/mod/mod_proxy.html#x-headers . Якщо ви налаштуєте RemoteIpValve як частину свого сервісу Tomcat, ваш код програми може отримати більшу інформацію прозоро tomcat.apache.org/tomcat-8.0-doc/config/…
Скотт Марклвелл,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.