HAProxy URL перепишіть на помилку 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 для врівноваження завантаження, яке не є веб-сервером і не підтримує цю функцію. Зараз динамічне генерування програмного забезпечення здійснюється кожного разу, коли клієнт намагається отримати доступ до ресурсу, що значно повільніше і витрачає ресурси. Було б добре, якщо він міг би використовувати наступний бек-енд, якщо перший (простий веб-сервер кешування для статичних файлів) не вдався до помилки 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.