При создании архитектуры на основе обратного прокси-сервера с балансировкой нагрузки, как бы они были размещены?
Это правильная архитектура? First LB server, then proxy: - Когда клиент обращается к URL-адресу, это в основном балансировщик нагрузки, за которым находятся несколько обратных прокси-серверов. Он вызывает обратный прокси-сервер, который, в свою очередь, собирает данные с нескольких серверов и выполняет запрос.
Есть ли возможность First proxy server then LB server?
Или я полностью упускаю сюжет?
Как сказал Джеспер, вам нужно больше деталей.
Какова роль обратного прокси в этой ситуации? Это желаемая производительность, высокая доступность или и то, и другое?
Некоторые балансировщики нагрузки выполняют фильтрацию URL-адресов, поэтому, если прокси-сервер просто маршрутизирует трафик (не кэширует), вам может вообще не понадобиться прокси.
Какой объем трафика можно кэшировать? Где ваши узкие места?
В последнее время я использую этот стек с хорошими результатами для приложения на основе PHP:
HAProxy --> Varnish --> Nginx --> PHP-FPM --> MySQL/NFS server
Мы обнаружили, что около 70% всех запросов могут обслуживаться из кеша Varnish. Мы рассматривали возможность размещения Varnish на переднем крае, но один сервер Varnish не может справиться с нагрузкой. Так что нам в любом случае потребуется балансировка нагрузки.
Это создает единую точку отказа на уровне LB, но нашего клиента это устраивает, поскольку мы можем запустить новый экземпляр примерно за 5 минут. Они готовы рискнуть 5-10-минутным отключением, а не иметь более сложную инфраструктуру с двумя HA-прокси-серверами.
Каждый вариант использования отличается, и только путем тестирования вы можете найти лучшее решение, соответствующее бюджету.
Вот что я обычно делаю.
Имейте 2 сервера Varnish с общим IP через keepalive на случай, если один из них умрет. как мой обратный прокси.
За ним (или на том же сервере) сидит haproxy, выполняющий балансировку нагрузки.
Varnish также поддерживает балансировку нагрузки на бэкенды, но вы не получаете хорошей статистики или контроля, как с haproxy. Если вы выберете аппаратный балансировщик нагрузки ... скорее всего, он будет первым, поскольку он также может быть вашим межсетевым экраном.
В конце концов .. это действительно зависит от того, как вы хотите это выложить.
Это зависит от ваших более подробных и конкретных потребностей, поэтому на самом деле невозможно ответить на основе предоставленной вами информации. Оба ваших предложения являются действительными и хорошими решениями в определенных случаях.
Как всегда ... профилируйте производственную нагрузку в реальном времени и протестируйте устройства / программное обеспечение, с которыми вы работаете, для проксирования и балансировки нагрузки.
В основном:
Если вам нужен SSL, многое будет зависеть от того, какой протокол SSL лучше всего обрабатывает LB или прокси. Как правило, вы хотите использовать SSL на границе вашей сети, то есть на первом сервере (ах).
Если вам нужно несколько прокси-серверов для обработки нагрузки, это подтолкнет к LB --> proxie(s) --> LB --> App Servers (или использование грубого DNS Round Robin для грубого распределения нагрузки на несколько прокси-серверов).
Если тебе надо последовательное хеширование перед вашими прокси, то это подтолкнет к LB --> proxie(s) --> LB --> App Servers и балансировщик нагрузки, который поддерживает согласованное хеширование.
Если один прокси может справиться с вашей нагрузкой, тогда proxy --> LB --> App Servers самый простой. Некоторые прокси, например Varnish, даже имеют встроенный базовый балансировщик нагрузки.
Вилли Тарро, автор превосходного HAProxy, написал хорошую статью о общие архитектуры балансировки нагрузки внешнего интерфейса / разгрузки SSL / проксирования.