В настоящее время у нас есть конфигурация, которая на самом высоком уровне выглядит так:
[Трафик] -> Varnish (кеширование) -> HaProxy (балансировка нагрузки) -> Apache (контент и сервисы)
Существует (очевидно?) Несколько серверов Apache, и в целом они предоставляют два типа услуг ... один набор серверов предоставляет более традиционные типы веб-контента (по большей части страницы с возможностью навигации), а другой набор - конечные точки сервиса ( и они, в свою очередь, подключаются к базе данных и другим внутренним функциям).
Запросы на обслуживание отфильтровываются на ранней стадии в Varnish (определенные домены и т. Д. Идентифицируются в VCL и передаются непосредственно в HAProxy - нет необходимости кэшировать какие-либо из этих вызовов).
Запросы «Контент» действительно кешируются Varnish.
Необходимо добавить поддержку SSL. Первоначально из-за необходимости добавлять запросы (и ответы) защищенных служб, хотя я ожидал, что в конечном итоге мне также понадобятся HTTPS-вызовы на сервер (ы) контента.
В настоящее время я экспериментирую с stunnel, и пока он работает, модель, которую я эффективно использую, просто использует stunnel для расшифровки входящих запросов, а затем передает их через HAProxy как обычно *: 80 трафика (так что не использует mod_ssl и т. Д. В Apache ). Так эффектно теперь все выглядит так:
[Трафик] -> Varnish (кеширование) -> HaProxy (балансировка нагрузки) -> Apache (контент и службы) -----------> STunnel ------------- ---------------- ^
Так что это работает, но мое чутье подсказывает мне, что это не долгосрочное решение. Одна из возможностей - просто полностью разделить трафик):
[Трафик] -> Varnish (кеширование) -> HaProxy (балансировка нагрузки) -> Apache (контент и сервисы)
[Трафик] -> Фунт (или что-то еще?) ------------------------> Apache (контент и услуги SSL)
Серверы Apache, вероятно, будут общими (трафик SSL будет обрабатываться по-другому), но системы, которые направляют трафик на серверы контента / услуг, будут разными ...
Поиски порождают множество мнений / вариантов (включая nginx и т. Д.), Но вопрос первого порядка состоит в том, имеет ли смысл архитектура в целом (перенаправление входящего трафика на отдельные подсистемы) или существует более унифицированная модель, которую я следует смотреть (и, вероятно, проще). Если архитектура имеет смысл, то последующим шагом будет то, что использовать для поддержки SSL этого чудовища.
Вау, этот стек становится все сложнее и сложнее. Сложность - враг времени безотказной работы и вообще враг производительности. Каждая из этих частей должна управлять подключениями, анализировать заголовки HTTP и т. Д.
Я предлагаю вам упростить. Использовать nginx для SSL, балансировки нагрузки, кэширования, поскольку он поддерживает все три со встроенными модулями. Вы также можете постепенно развертывать его в своей инфраструктуре, используя сначала только SSL, затем заменяя HAproxy для балансировки нагрузки служб и т.д. Вы можете потенциально отказаться от Apache и заставить nginx делать почти все, если ваши службы написаны на каком-либо языке. с приличным веб-сервером или FastCGI-сервером.
Мой небольшой магазин SaaS использует плоский уровень nginx SSL / прокси / кеш / статический перед серверными службами Tomcat, IIS и PHP-fastCGI и статическими веб-серверами. Мы наблюдаем пики в 2000 запросов в секунду, и nginx даже не изо всех сил справляется с такой нагрузкой, имея всего две одноядерные виртуальные машины VMware на переднем конце всего.
имеет ли смысл архитектура в целом (перенаправление входящего трафика
На предоставленных вами диаграммах не отображается любой ветви. Я немного сбит с толку, почему у вас лак перед HA-Proxy, а не наоборот.
но мои кишки говорят мне, что это не долгосрочное решение
Инкапсуляция SSL должна выполняться перед кешированием HTTP (в противном случае содержимое не может быть кэшировано).
Конечно, было бы лучше уменьшить количество переходов, но объединение SSL на один из существующих уровней не дало бы такого большого выигрыша в производительности (по крайней мере, если предположить, что хотя бы один конец stunnel подключен через localhost). Это архитектура, которую обычно рекомендуют Oracle, Cisco, f5 и т. Д. (То есть с SSL во внешнем интерфейсе, хотя за исключением того, что они думают, что вы должны запустить их комплект где-то там!).
Если бы это был я, я бы разделил кешируемый / не кэшируемый контент на разные URL-адреса, ориентированные на клиента. (даже лучше использовать CDN для всего кешируемого контента!)
Важные вопросы, на которые вы не ответили, включают сколько у вас IP-адресов, сколько у вас веб-серверов и разделение между кэшируемыми / некэшируемыми и http / https.
+--->(cacheable:80)->--------------+
| |
+--->(cacheable:443)---> stunnel->-+->Varnish ->-+
HAProxy ->-+ |
+-->(non-cacheable:443)--> stunnel->-----+-------+---->Apache
| |
+--->(non-cacheable:80)->-----------------+
Очевидно, если вы откажетесь от varnish (при желании с помощью mod_proxy в Apache), это станет намного проще ...
+--->(:80)->------------+
HAProxy ->-+ |
+--->(:443)---> stunnel-+---->Apache
Учитывая цену на оборудование, я далек от уверенности в том, что использование обратного прокси-сервера с кешированием - это хороший компромисс между ценой и производительностью - если только у вас нет огромных объемов трафика и большая его часть не кэшируется. OTOH, если вы реализуете логику (например, ESI), то ее не очень практично не иметь прокси, и в этом случае вопрос становится может Varnish обеспечивает необходимую балансировку нагрузки вместо использования HAPProxy?
(:443)-->stunnel--+
|
(:80)-------------+-->varnish-->Apache
Вы можете попробовать «режим tcp» (по умолчанию) и «option ssl-hello-chk». Взгляните на Руководство по настройке HAProxy. Таким образом, вы не получите возможности проверять http-заголовки с помощью HAProxy, но, возможно, вам это просто не нужно.
Таким образом, вы предоставляете HAProxy все ресурсы для балансировки нагрузки, а ssl-дешифрование, кеширование и предоставление динамического или статического контента выполняется в серверной части, где вы можете легко масштабироваться.
HAProxy может обрабатывать HTTP / 1.1, может поддерживать множество длительных соединений, поэтому в вашем приложении могут использоваться такие методы, как длительный опрос или веб-сокеты. Например, в настоящее время это невозможно с nginx.