Loadbalancer и Tomcat

1) Мы хотим сгруппировать двух котов, есть ли какие-то недостатки.

Главный недостаток состоит в том, что управлять кластером сервисов сложнее, требует значительных предварительных затрат времени и требует больше ресурсов в вашем центре обработки данных. У вас также есть дополнительная сложность управления сбалансированными сеансами, в противном случае ваш клиент теряет логин и файлы cookie при каждом новом запросе (см. Ниже комментарий по этому поводу)

Однако вы торгуете этим ради увеличения емкости и устойчивости к сбоям. Я бы посмотрел на использование чего-нибудь для управления конфигурацией экземпляров tomcat, например анзибль или повар, или даже предварительно созданные контейнеры докеров для Кот. Изначально это большой объем работы, но в долгосрочной перспективе окупается.

2) Было бы недостаточно аппаратных балансировщиков нагрузки до tomcat, в чем преимущество установки серверов apache?

Я давно не использую аппаратный балансировщик нагрузки, в основном перешел на AWS и облачные сервисы, поэтому я не могу говорить о запуске собственного аппаратного балансировщика нагрузки, однако и apache, и nginx легко настроить как интерфейс прокси для tomcat7. Раньше я широко использовал apache в производстве, и есть много хороших руководств, объясняющих нюансы;
https://rvdb.wordpress.com/2012/04/26/reverse-proxying-tomcat-webapps-behind-apache/
https://wiki.apache.org/httpd/TomcatReverseProxy

С apache у вас есть опция mod_proxy или mod_proxy_ajp. Как правило, mod_proxy с http проще настроить, а ajp должен быть быстрее, поскольку он использует двоичный формат для связи. (но я на самом деле не сравнивал скорость) Другая причина использования mod_proxy_ajp заключается в том, что он также отправляет данные SSL в tomcat, поэтому, если ваше приложение использует информацию SSL для аутентификации, но вы передали HTTPS во внешнем интерфейсе, вы понадобится mod_proxy_ajp.

Дополнительные преимущества использования apache в качестве внешнего интерфейса заключаются в том, что вы получаете в качестве бонуса все возможности настройки, такие как ведение журнала и аутентификация. Таким образом, вы можете получить агрегированный журнал обоих серверов Tomcat в одном месте, вместо того, чтобы идти и получать файлы журналов с каждого узла. Таким образом, вы можете использовать любой инструмент анализа журналов, который работает с apache, для получения статистики для вашего приложения.

mod_proxy;

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_balancer modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

<VirtualHost *:80>
  ServerName mydomain 
  ServerAlias *.mydomain 
  <Proxy balancer://mycluster>
    BalancerMember http://app1.example.com:8080
    BalancerMember http://app1.example.com:8080
  </Proxy>
  ProxyPass /test balancer://mycluster
</VirtualHost>

или используя mod_proxy_ajp

<VirtualHost *:80>
  ServerName mydomain 
  ServerAlias *.mydomain 
  <Proxy "balancer://cluster">
    BalancerMember "ajp://app1.example.com:8009" loadfactor=1
    BalancerMember "ajp://app2.example.com:8009" loadfactor=2
    ProxySet lbmethod=bytraffic
  </Proxy>
  ProxyPass "/app" "balancer://cluster/app"      
</VirtualHost>

Вы также должны принять во внимание поддержание сеансов между серверами. Это зависит от вашего приложения, но вы обычно запускаете сеанс в веб-приложении, и подсистема балансировки нагрузки использует этот файл cookie для маршрутизации запросов к правильной серверной части;

ProxyPass "/app" "balancer://cluster/app"  stickysession=JSESSIONID

Здесь есть некоторые подробности того, как это работает;
https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#stickyness

3) Мы хотим разгрузить SSL в Load-Balancer, какие воздействия или проблемы мы видим в этом подходе?

Думаю, это стандартный подход. Настроить apache с сертификатами намного проще, чем tomcat, и я понимаю, что apache обрабатывает SSL намного эффективнее, чем tomcat (не уверен, что это все еще верно в 2016 году ...), и это приведет к повышению производительности.

Я предполагаю, что основная проблема приложения tomcat заключается в том, что оно находится за https: //, но не знает этого. Таким образом, вы должны быть осторожны с тем, как создаются ссылки, и быть уверенными, что они правильно представлены клиенту. Очевидно, если все ссылки относятся к серверу, например. <a href=/my/path/to/thing.html">Click</a> тогда все должно работать нормально.

Изменить: добавлен комментарий об улучшении производительности от @ tweeks200