URL перезаписи HAProxy при ошибке 404


9

Как сделать так, чтобы HAProxy переписывал на другой бэкэнд, когда в первом отсутствует файл? Мне нужно errorlocтолько переписать вместо перенаправления, чтобы клиент не знал о перенаправлении.

Мы разработали приложение с учетом NginX, которое было одновременно балансировкой нагрузки обратного прокси-сервера и веб-сервера для статических файлов. Приложение основано на платформе Opa, для которой требуются липкие сеансы на основе файлов cookie, поддерживаемые как NginX, так и HAproxy. Особенностью приложения, с которым мы сталкиваемся, является динамическая генерация контента. Он генерирует изображения по запросу, но после генерации он сохраняется на диске и может быть доступен статически с детерминированным путем.

Проблема была легко решена с помощью NginX - он пытается прочитать локальный файл и использовать серверную часть с балансировкой нагрузки, только если файл отсутствует (еще не создан):

server {
  server_name wkaliszu.pl;
  location /thumb {
    root /path_on_disk/to_cached_content;
    expires 7d;
    # try to access already generated content
    try_files $uri @wkaliszu;
  }
  location / {
    # reverse proxy to the application
    [...]
  }
  location @wkaliszu {
    # reverse proxy to the application
    [...]
  }
}

Сервер был перенесен и теперь использует HAPproxy для балансировки нагрузки, который не является веб-сервером и не поддерживает эту функцию. Теперь динамическая генерация программного обеспечения выполняется каждый раз, когда клиент пытается получить доступ к ресурсу, что намного медленнее и тратит ресурсы впустую. Было бы хорошо, если бы он мог использовать следующий back-end, если первый (простой кеширующий веб-сервер для статических файлов) завершился ошибкой 404, но я не могу найти способ сделать это простым способом. Перенаправление /thumbна NginX, который пытается прочитать статический файл и снова перезаписывает на HAproxy с новым заголовком HTTP, только приходит мне в голову, но я хотел бы найти что-то лучшее.


Какой стек приложений вы используете на серверах приложений?
Jeffatrackaid

Ответы:


1

Бэкэнды HAProxy находятся либо вверх, либо вниз (или на пути вверх / вниз).

Существуют различные способы проверки работоспособности бэкэнда, но я не знаю ни одного, обеспечивающего отслеживание по запросу. Как только запрос завершается неудачей, этот бэкэнд будет помечен как выключенный или будет неуспешным (на пути к тому, чтобы считаться неработающим).

Это очень отличная логика от вашей установки Nginx, которая направляла запросы на основе запросов.

Я вижу пару вариантов здесь:

  • Nginx как кеширующий прокси
  • Используйте серверы приложений для статического контента
  • Используйте CDN

Кэширующий прокси

В HAProxy вы будете использовать ACL для маршрутизации запросов статического содержимого к определенному бэкэнду. Эти внутренние узлы будут запускать nginx с кеширующим прокси. Если бы у nginx был кешированный файл, он бы его обслуживал. Если нет, это вызвало бы ваш бэкэнд.

Используйте серверы приложений для статического контента

Если ваши серверы приложений эффективны в обслуживании статического контента, вам может не потребоваться разделять запрос по haproxy. Просто отправьте все запросы к вашему приложению. Создайте в них логику для обслуживания статического содержимого, если оно доступно, а если нет, отправьте запрос на сервер

Опция CDN

Если вы можете использовать выделенный домен для статического контента, вы можете использовать CDN. В CDN вы просто указываете исходный URL-адрес ваших узлов приложения. Затем вы можете контролировать кэширование на уровне CDN. Это похоже на кэширование Nginx, описанное выше, за исключением того, что поставщик CDN обрабатывает его для вас.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.