Я настраиваю кластер HA (высокая доступность) с использованием nginx, haproxy и apache.
Я много читал о nginx и haproxy. Люди склонны выбирать то или другое, но мне нравятся оба. Haproxy более гибок для балансировки нагрузки, чем простой циклический перебор nginx (даже с патчем upstream-fair). Но я бы хотел, чтобы nginx перенаправлял не https на https, среди прочего, прямо в точке входа в кластер.
С другой стороны, nginx намного быстрее обслуживает статическое содержимое и снизит нагрузку на мощный apache, который любит потреблять много оперативной памяти!
Вот моя запланированная установка:
Балансировщик нагрузки: nginx прослушивает порт 80/443 и proxy_forwards для haproxy на 8080 на том же сервере для балансировки нагрузки между несколькими узлами.
Узлы: nginx на узле прослушивает запросы, поступающие от haproxy на 8080, если контент статический, обслуживайте его. Но если это внутренний скрипт (в моем случае PHP), прокси-сервер пересылает apache2 на тот же сервер узла, прослушивая другой номер порта.
Технически эта настройка работает, но меня беспокоит, не замедлит ли запросы, проходящие через несколько прокси, запросы? Большинство запросов будут PHP-запросами, поскольку серверные части - это сервисы (что означает переход от nginx -> haproxy -> nginx -> apache).
Мысли? Ура
С чисто точки зрения производительности, позвольте бенчмаркингу принимать эти решения за вас, а не предполагать - используя такой инструмент, как httperf бесценен при внесении изменений в архитектуру.
С точки зрения архитектурной философии мне немного любопытно, почему на серверах приложений есть и nginx, и apache. Nginx использует статический контент и эффективно обрабатывает большинство серверных фреймворков / технологий (Rails, PHP через FastFCGI и т. Д.), Поэтому я бы отказался от последнего уровня Apache. Опять же, это происходит из-за ограниченного понимания технологий, которые вы используете, поэтому у вас может возникнуть потребность в этом, чего я не ожидаю (но в этом случае вы всегда можете сбросить nginx на серверы приложений и просто используйте apache - при правильной настройке статического контента это не так уж плохо).
В настоящее время я использую nginx -> haproxy на серверах балансировки нагрузки и nginx на серверах приложений с большим успехом. Как заявил Вилли Тарро, nginx и haproxy - это очень быстрая комбинация, поэтому я бы не стал беспокоиться о скорости наличия обоих на интерфейсе, но имейте в виду, что добавление дополнительных слоев увеличивает сложность, а также количество точек неудача.
Помните, что сложность может быть таким же (если не большим) препятствием для масштабирования, как и код / дизайн. По мере того, как вы разбрасываете детали внедрения по все большему количеству сервисов и конфигурационных файлов, вы создаете нечто, что сложнее масштабировать, требует большего обучения для всех, кто новичок в команде, требует больше программного обеспечения / пакетов для управления, усложняет устранение неполадок больше потенциальных точек отказа и т. д. Настройка стека с 4-мя уровнями прокси для сайта, который был бы хорош с just-apache или just-nginx, по сути, является версией системного администратора для «преждевременной оптимизации».
Ваша установка становится все более распространенной. Тебе не о чем беспокоиться. И nginx, и haproxy чрезвычайно быстро обрабатывают и пересылают HTTP-запросы. Оба очень хорошо сочетаются друг с другом и очень хорошо выполняют свою работу. Не нужно выбирать. Установите их оба и будьте счастливы. Таким образом вы сможете очень быстро доставить статические файлы, а также обеспечить плавное масштабирование динамических серверов.
Не беспокойтесь о количестве прокси. Часто проблема заключается в том, «могу ли я использовать прокси». Иногда это непрактично. Если у вас есть один, вы можете иметь два или три. Многие сложные архитектуры включают до 5-6 уровней прокси и при этом очень хорошо масштабируются. Вы должны быть осторожны с одной вещью: не устанавливайте на одну машину больше таких прокси, чем на этой машине ядер ЦП, иначе прокси-серверы должны будут совместно использовать свое процессорное время при высоких нагрузках, что увеличит время отклика. Но для того, чтобы это произошло с nginx и haproxy на машине, это будет означать загрузку десятков тысяч запросов в секунду, что не является проблемой сегодня для всех.
Также избегайте смешивания однопоточных прокси с многопоточным / многопроцессорным программным обеспечением, таким как apache, java и т. Д. В одной системе.
После того, как вы примете эти правила во внимание, просто нарисуйте архитектуру, которая соответствует вашим потребностям, напишите имена в коробки, объедините их разумным образом и установите их.
Обновление для 2020, это стандартная рекомендуемая настройка, с которой вы должны столкнуться для приложений PHP.
LOAD BALANCER SERVER A
haproxy -+---------> nginx -+---> /app/ ------> PHP application
| |
| +---> /static/ ---> local files
|
|
| SERVER B
+---------> nginx -+---> /app/ ------> PHP application
|
+---> /static/ ---> local files
Это обслуживает приложение и статические файлы с нескольких хостов, каждый хост идентичен. nginx может запускать приложения PHP (поверх fastcgi) и обслуживать локальные файлы.
Если это старое приложение PHP, оно может быть разработано с учетом Apache вместо nginx. Все хорошо. Apache также может запускать приложения PHP (cgi, fastcgi или mod_php) и обслуживать локальные файлы.
Можно перейти с Apache на nginx, но для устаревших систем это не обязательно. Apache сложно создавать и настраивать, но если он уже запущен, это не проблема. Apache неэффективен, но PHP намного медленнее, и узким местом всегда будет приложение.
Спереди для этого нужен уровень балансировщиков нагрузки для распределения трафика между серверами. Обычно один из HAProxy, AWS ALB, F5 или CloudFlare.
Можно добавить бесконечное количество промежуточных слоев, но это не дает никаких преимуществ. Исходный вопрос устарел по своим соображениям. Все это программное обеспечение поддерживает SSL в течение почти десяти лет, установка может запускать сквозной протокол SSL. Локальные файлы обслуживаются эффективно благодаря sendfile (), недавно добавленному в ядро Linux.
Почему бы не использовать Лак? Таким образом вы объединяете кеширование, проксирование и балансировку нагрузки в одном приложении, и это намного удобнее с точки зрения архитектуры.
Масштабирование с горизонтальным масштабированием просто феноменально. Также есть преимущество, заключающееся в том, что балансировщик нагрузки может принимать более разумные решения на основе фактического состояния узлов.
Файл конфигурации позволит вам изучить заголовки и принять решение о том, откуда подавать статический и динамический контент.
Если вы действительно прогнозируете обслуживать МНОГО статического контента, возможно, перенаправление большей части этого контента на CDN будет экономически эффективным решением?
«Технически эта установка работает, но меня беспокоит то, не замедлит ли запросы, проходящие через несколько прокси, запросы?»
Да, но ненамного, особенно если обратить внимание на сетевую составляющую масштабируемой системы. Это должно быть надежно.
Как правило, чтобы получить возможность масштабирования и распределения работы по многим машинам, вы обычно должны жертвовать производительностью некоторых или всех отдельных машин. Это неизбежно, и обычно не стоит о чем беспокоиться (помимо тестирования, которое вы всегда должны проводить, чтобы убедиться, что производительность всего паразита). Оптимизация частей - не обязательно лучший способ оптимизировать целое.