Я планирую новую инфраструктуру для нашего веб-приложения. У нас есть два сервера JBossAS5, работающих в кластере. Состояние сеанса будет реплицировано через JBoss Cache.
Перед этим должен быть какой-то кеш, чтобы ускорить доставку статических элементов. Однако большая часть трафика в наше приложение будет проходить через HTTPS.
До сих пор я думал о двух кэшах Varnish перед JBossAS, каждый из которых был настроен для балансировки нагрузки между двумя JBossAS через циклический перебор. Так как Varnish не обрабатывает HTTPS, то перед Varnish должны быть прокси на два фунта, которые работают с HTTPS. Эти два фунта будут доступны с Heartbeat / LinuxHA.
Затем трафик на www.example.com будет проходить через наш брандмауэр, оттуда на виртуальный IP-адрес фунта, оттуда на Varnish, а оттуда на JBossAS.
Вопрос 1: Есть ли в этом смысл? Или это слишком сложно, и та же цель может быть достигнута более простыми методами?
Вопрос 2: Если мой макет в порядке, как мне настроить шаг фунт -> лак? Должен ли я а) сделать сервис Varnish высокодоступным через Heartbeat / LinuxHA и направить трафик с фунта на виртуальный IP-адрес Varnishs, или лучше б) Настроить два независимых Varnish и использовать балансировку нагрузки в фунтах для адресации разные лаки?
К сожалению, аппаратная балансировка нагрузки невозможна из-за затрат. Это не корпоративная система, а система НПО, и у нас всегда не хватает денег ... Все это не критично, но я бы хотел, чтобы она была максимально надежной, потому что наши ИТ не всегда доступны в короткие сроки (у нас нет штатных ИТ-специалистов ...).
Большое спасибо за понимание!
Андреас.
Думаю, ваш подход имеет смысл. Если у вас нет необходимости в расширенном кэшировании динамических объектов, я бы предложил использовать nginx, поскольку он способен кешировать, https и балансировать нагрузку. Мне очень нравится Varnish, и я думаю, что большинство сайтов могут многого добиться от него, но, судя по вашей информации, было бы разумнее использовать nginx (+ сердцебиение или карп).
Удачи! :)
Я бы сказал, что предложенное решение чрезмерно спроектировано. Существует множество технологий, которые подойдут для вашей ситуации.
Я использую LVS для балансировки нагрузки и SQUID для кеширования, особенно в отношении Jboss. Для статического контента обычно лучше использовать Apache. Вы по-прежнему можете использовать сердцебиение или кардиостимулятор для дублирования с этими технологиями.
Основная причина, по которой я использую SQUID, - это перезапись, но большая часть контента, с которым я работаю, является динамическим. Кеширование - это бонус. Большинство моих Java-приложений практически не имеют статического содержимого, поэтому я часто пропускаю часть, посвященную mod_jk. Дело в том, что ваши требования могут значительно упростить даже предложенное мной решение.
Возможный пример:
NAT в SQUID (с кластером -> КАЛЬМАР прозрачно прокси для LVS VIP -> LVS VIP в кластер Apache -> mod_jk в Jboss
Добавление большего количества слоев определенно усложняет обслуживание, но я не думаю, что есть что-то плохое в базовом подходе. Моя первая мысль заключалась в том, что Squid делает то, что вы хотите, для кеширования HTTP- и HTTPS-соединений. Я успешно использовал его около 4 лет на сайте фотохостинга.
Кальмар здесь: http://www.squid-cache.org/. Очевидно, есть некоторые соображения по производительности: http://deserialized.com/reverse-proxy-performance-varnish-vs-squid-part-2/, но, возможно, эти недостатки компенсируются поддержкой https.
По какой причине вы не хотите использовать аппаратный балансировщик нагрузки?
Поскольку вы описываете дизайн высокой доступности, я предполагаю, что это критически важный сайт и, возможно, с высоким трафиком. Таким образом, у вас может быть бюджет на такое устройство или устройства для обеспечения высокой доступности на этом уровне.
Такое устройство, как F5 BigIP, предоставит вам больше функций и надежности, чем фунт. Вы сможете выполнять разгрузку ssl для обработки https, а также кэширования и сжатия.