bolt Valebyte VPS від $4/міс — NVMe, запуск за 60 секунд.

Отримати VPS arrow_forward
eco Початковий Туторіал

Налаштування HAProxy на VPS:

calendar_month Jul 05, 2026 schedule 23 хв. читання visibility 17 переглядів
info

Потрібен сервер для цього гайду? Ми пропонуємо виділені сервери та VPS у 50+ країнах з миттєвим налаштуванням.

Потрібен сервер для цього гайду?

Розгорніть VPS або виділений сервер за хвилини.

Налаштування HAProxy на VPS: високопродуктивне балансування навантаження та відмовостійкість

TL;DR

У цьому докладному посібнику ми налаштуємо HAProxy на VPS для ефективного балансування навантаження між кількома бекенд-серверами, забезпечуючи високу доступність та відмовостійкість ваших веб-додатків. Ви дізнаєтеся, як встановити, сконфігурувати HAProxy для HTTP та HTTPS трафіку, додати SSL-термінацію, налаштувати перевірку стану бекендів та моніторинг, а також впровадити базові заходи безпеки та резервного копіювання.

  • Встановимо та сконфігуруємо HAProxy для розподілу вхідного трафіку.
  • Налаштуємо балансування HTTP та HTTPS з SSL-термінацією на HAProxy.
  • Забезпечимо відмовостійкість за допомогою перевірок стану бекенд-серверів.
  • Впровадимо базові заходи безпеки та моніторинг стану HAProxy.
  • Розглянемо резервне копіювання конфігурації та стратегії обслуговування.
  • Отримаємо практичний досвід розгортання високодоступної архітектури на VPS.

Що ми налаштовуємо і навіщо

У сучасному світі доступність та продуктивність веб-сервісів відіграють ключову роль. Одиночний сервер, яким би потужним він не був, завжди є точкою відмови. Якщо він виходить з ладу, весь ваш сервіс стає недоступним. Крім того, при зростанні навантаження один сервер може не справлятися з обсягом запитів, що призводить до уповільнення роботи або повної відмови.

Саме ці проблеми вирішує балансування навантаження. Ми будемо налаштовувати HAProxy — високопродуктивний, надійний та широко використовуваний балансувальник навантаження з відкритим вихідним кодом. HAProxy здатний ефективно розподіляти вхідний трафік між кількома бекенд-серверами. Це не тільки покращує продуктивність за рахунок рівномірного розподілу запитів, але й значно підвищує відмовостійкість: якщо один із бекендів виходить з ладу, HAProxy автоматично виключає його з ротації та спрямовує трафік на решту працездатних серверів.

В результаті цього туторіалу ви отримаєте повністю функціонуючу систему, де HAProxy виступатиме в ролі "воротаря" перед вашими додатками. Він прийматиме всі вхідні запити, термінуватиме SSL (що знімає це навантаження з бекендів), перевірятиме стан ваших реальних серверів і спрямовуватиме запити лише до тих, які працюють коректно. Це дозволить вам легко масштабувати ваш додаток, додаючи нові бекенди за необхідності, та забезпечить безперервну роботу сервісу навіть при часткових відмовах.

Альтернативи: Cloud-managed vs. Self-hosted на VPS

Коли йдеться про балансування навантаження, існує два основні підходи: використання керованих хмарних сервісів (наприклад, AWS ELB, Google Cloud Load Balancer, Azure Load Balancer) або самостійне налаштування на власному VPS/dedicated сервері.

Cloud-managed балансувальники пропонують зручність, автоматичне масштабування та глибоку інтеграцію з іншими хмарними сервісами. Вам не потрібно турбуватися про управління інфраструктурою, оновлення або високу доступність самого балансувальника — все це бере на себе провайдер. Однак за цю зручність доводиться платити, і вартість таких рішень може бути значно вищою, особливо для проектів з помірним навантаженням або фіксованими бюджетами. Крім того, ви прив'язані до екосистеми конкретного хмарного провайдера.

Self-hosted балансувальник на VPS, такий як HAProxy, дає вам повний контроль над конфігурацією, оптимізацією та безпекою. Це значно економічніше рішення, особливо якщо у вас вже є кілька VPS для бекендів. Ви можете точно налаштувати HAProxy під свої унікальні вимоги, використовуючи розширені функції, які можуть бути недоступні або дорогі в хмарних аналогах. Цей підхід ідеально підходить для тих, хто хоче максимально ефективно використовувати свої ресурси, має досвід адміністрування серверів або бажає уникнути вендор-локу (vendor lock-in). Налаштування HAProxy на VPS дозволяє створити надійну та високопродуктивну архітектуру, яка за гнучкістю та вартістю часто перевершує хмарні рішення для багатьох завдань.

Який VPS-конфіг потрібен для цього завдання

Вибір відповідного VPS для HAProxy залежить від очікуваного навантаження, кількості бекенд-серверів та типу трафіку (HTTP/HTTPS). HAProxy сам по собі дуже легкий та ефективний, але при обробці великої кількості з'єднань, особливо з SSL-термінацією, йому знадобиться більше ресурсів.

Мінімальні вимоги для HAProxy (один інстанс):

  • CPU: 1 ядро. HAProxy чудово використовує одне ядро, але для високого навантаження або SSL-термінації може бути корисно 2 ядра.
  • RAM: 512 MB - 1 GB. Самому HAProxy потрібно небагато пам'яті, але операційна система та кеші можуть використовувати більше. Якщо ви плануєте термінувати SSL, 1 GB буде комфортнішим.
  • Диск: 20 GB SSD. HAProxy практично не використовує дисковий простір, але для ОС, логів та потенційних бекапів конфігурацій цього буде достатньо. SSD важливий для швидкого завантаження та операцій з файлами.
  • Мережа: 100 Mbps - 1 Gbps. Пропускна здатність мережі — критичний фактор для балансувальника. Переконайтеся, що ваш VPS має достатній мережевий канал.

Рекомендований VPS-план для HAProxy (актуально на 2026 рік):

Для більшості середніх проектів, де HAProxy оброблятиме до кількох тисяч одночасних з'єднань та термінуватиме SSL, рекомендується наступний конфіг:

  • CPU: 2 ядра (наприклад, Intel Xeon E5 або AMD EPYC)
  • RAM: 2 GB
  • Диск: 40 GB NVMe SSD (для максимальної продуктивності дискових операцій)
  • Мережа: 1 Gbps порт з гарантованою пропускною здатністю 200-500 Mbps.

Такої конфігурації буде достатньо для обробки значного обсягу трафіку та забезпечення стабільної роботи. Ви можете розглянути VPS із зазначеними характеристиками, щоб орендувати відповідний сервер.

Коли потрібен dedicated, а не VPS

Dedicated сервер стає необхідним, коли:

  • Екстремально високе навантаження: Якщо ви очікуєте десятки або сотні тисяч одночасних з'єднань, і ваш HAProxy стає вузьким місцем через обмеження віртуалізації.
  • Вимоги до продуктивності: Для додатків з дуже низькою затримкою або високим обсягом трафіку, де навіть невеликі затримки, властиві віртуалізації, неприпустимі.
  • Спеціалізоване обладнання: Якщо вам потрібні специфічні апаратні компоненти (наприклад, дуже швидкі NVMe RAID-масиви, GPU) або повний контроль над апаратним забезпеченням.
  • Суворі вимоги до безпеки/ізоляції: Для деяких регуляторних вимог або політик безпеки, де повна фізична ізоляція є обов'язковою.

Для HAProxy, який сам по собі дуже ефективний, dedicated сервер зазвичай потрібен лише в найбільш високонавантажених сценаріях, коли він стає єдиною точкою входу для величезного кластера бекендів.

Локація VPS: на що впливає

Вибір географічної локації вашого VPS для HAProxy критично важливий і впливає на кілька факторів:

  • Затримка (Latency): Розміщуйте HAProxy якомога ближче до вашої цільової аудиторії. Чим менша відстань між користувачем та балансувальником, тим нижча затримка та швидша відповідь.
  • Затримка до бекендів: HAProxy повинен бути розташований максимально близько до ваших бекенд-серверів, щоб мінімізувати затримку при пересиланні запитів. В ідеалі вони повинні знаходитися в одному дата-центрі або регіоні.
  • Геополітичні фактори та законодавство: У деяких випадках вибір локації може залежати від вимог до зберігання даних, регулювання або політичних міркувань.
  • Вартість: Ціни на VPS можуть варіюватися залежно від регіону.

Оптимальна стратегія — розмістити HAProxy в тому ж дата-центрі або регіоні, де знаходяться ваші основні бекенд-сервери, і який географічно близький до основної маси ваших користувачів.

Підготовка сервера

Перед встановленням та налаштуванням HAProxy необхідно виконати базову підготовку сервера. Ці кроки підвищать безпеку та зручність адміністрування.

1. Підключення до сервера

Підключіться до вашого нового VPS через SSH як користувач root (якщо не вказано інше вашим провайдером).


ssh root@ВАШ_IP_АДРЕС_VPS

2. Оновлення системи

Завжди починайте з оновлення пакетного менеджера та встановлених пакетів до актуальних версій, щоб забезпечити стабільність та безпеку. Ми будемо використовувати Ubuntu 24.04 LTS як основу для нашого туторіалу (актуально для 2026 року).


sudo apt update             # Оновлення списку пакетів
sudo apt upgrade -y         # Оновлення всіх встановлених пакетів
sudo apt autoremove -y      # Видалення невикористовуваних пакетів

3. Створення нового користувача з правами sudo

Робота під користувачем root небезпечна. Створіть нового користувача та надайте йому права sudo.


adduser ваш_пользователь     # Створення нового користувача
usermod -aG sudo ваш_пользователь # Додавання користувача до групи sudo

Тепер вийдіть із сесії root та увійдіть під новим користувачем:


exit                        # Вихід із root-сесії
ssh ваш_пользователь@ВАШ_IP_АДРЕС_VPS # Вхід під новим користувачем

4. Налаштування SSH-ключів (рекомендується)

Для підвищення безпеки та зручності використовуйте SSH-ключі замість паролів. Якщо ви ще не зробили цього, згенеруйте ключі на локальній машині та скопіюйте публічний ключ на VPS.


# На вашій локальній машині:
ssh-keygen -t rsa -b 4096   # Генерування пари ключів (якщо ще немає)
ssh-copy-id ваш_пользователь@ВАШ_IP_АДРЕС_VPS # Копіювання публічного ключа на VPS

Після успішного копіювання ключів рекомендується відключити авторизацію за паролем для root і, можливо, для всіх користувачів, дозволивши лише авторизацію за ключами. Відредагуйте /etc/ssh/sshd_config:


sudo nano /etc/ssh/sshd_config

Знайдіть та змініть наступні рядки (або додайте, якщо відсутні):


# ...
PermitRootLogin no
PasswordAuthentication no
# ...

Збережіть зміни (Ctrl+O, Enter) та вийдіть (Ctrl+X). Перезапустіть службу SSH:


sudo systemctl restart sshd

ВАЖЛИВО: Переконайтеся, що ви можете увійти по SSH з новим користувачем та ключем, перш ніж закривати поточну сесію, щоб не втратити доступ до сервера.

5. Налаштування брандмауера (UFW)

Налаштуйте простий брандмауер UFW (Uncomplicated Firewall) для дозволу лише необхідного трафіку. За замовчуванням дозволимо SSH, HTTP та HTTPS.


sudo apt install ufw -y     # Встановлення UFW
sudo ufw allow OpenSSH      # Дозволити SSH-з'єднання
sudo ufw allow http         # Дозволити HTTP (порт 80)
sudo ufw allow https        # Дозволити HTTPS (порт 443)
sudo ufw enable             # Увімкнення UFW
sudo ufw status verbose     # Перевірка статусу брандмауера

HAProxy також може використовувати додаткові порти для статистики або інших цілей, які ми відкриємо пізніше за необхідності.

6. Встановлення Fail2Ban (рекомендується)

Fail2Ban допомагає захиститися від брутфорс-атак, автоматично блокуючи IP-адреси, з яких відбуваються численні невдалі спроби входу.


sudo apt install fail2ban -y # Встановлення Fail2Ban
sudo systemctl enable fail2ban # Увімкнення автозапуску Fail2Ban
sudo systemctl start fail2ban  # Запуск служби Fail2Ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Копіювання конфігу для кастомізації

Fail2Ban за замовчуванням захищає SSH. Ви можете налаштувати його для захисту інших сервісів за необхідності.

Встановлення ПЗ — покроково

Тепер, коли сервер підготовлено, приступимо до встановлення HAProxy та допоміжних компонентів.

1. Встановлення HAProxy

HAProxy доступний у стандартних репозиторіях Ubuntu. Ми встановимо останню стабільну версію, доступну для Ubuntu 24.04 LTS, яка на 2026 рік буде підтримуватися та оновлюватися.


sudo apt install haproxy -y # Встановлення HAProxy з репозиторіїв

Перевірте встановлену версію HAProxy. Очікується версія 2.9 або вище, оскільки Ubuntu 24.04 LTS зазвичай постачається з актуальними версіями.


haproxy -v                  # Перевірка версії HAProxy

Вивід має бути приблизно таким (версія може відрізнятися, але буде актуальною):


HAProxy version 2.9.x-x ...

Після встановлення HAProxy буде запущено як системний сервіс. Перевірте його статус:


sudo systemctl status haproxy # Перевірка статусу служби HAProxy

Якщо його не запущено, ви можете запустити його командою:


sudo systemctl start haproxy  # Запуск служби HAProxy
sudo systemctl enable haproxy # Увімкнення автозапуску під час завантаження системи

2. Встановлення допоміжних бекенд-серверів (для тестування)

Для демонстрації балансування навантаження нам знадобляться щонайменше два бекенд-сервери. Ми встановимо Nginx на двох різних портах на тому ж VPS, щоб імітувати два окремі бекенди. У реальному середовищі це будуть окремі сервери.


sudo apt install nginx -y   # Встановлення Nginx, якщо ще не встановлено

Створимо два окремі конфігураційні файли для Nginx, щоб вони слухали на різних портах. Для простоти будемо використовувати порти 8080 та 8081.


sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/backend1.conf
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/backend2.conf

Відредагуйте /etc/nginx/sites-available/backend1.conf:


sudo nano /etc/nginx/sites-available/backend1.conf

Змініть блок server на:


server {
    listen 8080 default_server;
    listen [::]:8080 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
        add_header X-Backend-Server "Backend 1";
        try_files $uri $uri/ =404;
    }
}

Відредагуйте /etc/nginx/sites-available/backend2.conf:


sudo nano /etc/nginx/sites-available/backend2.conf

Змініть блок server на:


server {
    listen 8081 default_server;
    listen [::]:8081 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
        add_header X-Backend-Server "Backend 2";
        try_files $uri $uri/ =404;
    }
}

Створіть символічні посилання для активації цих конфігурацій та видаліть типову:


sudo rm /etc/nginx/sites-enabled/default # Видалення типового посилання Nginx
sudo ln -s /etc/nginx/sites-available/backend1.conf /etc/nginx/sites-enabled/backend1.conf
sudo ln -s /etc/nginx/sites-available/backend2.conf /etc/nginx/sites-enabled/backend2.conf

Перевірте конфігурацію Nginx та перезапустіть його:


sudo nginx -t                 # Перевірка синтаксису конфігурації Nginx
sudo systemctl restart nginx  # Перезапуск Nginx

Тепер відкрийте порти 8080 та 8081 в UFW, щоб HAProxy міг до них звертатися (ці порти не будуть доступні ззовні, тільки для локального HAProxy).


sudo ufw allow 8080/tcp       # Дозволити доступ до порту 8080
sudo ufw allow 8081/tcp       # Дозволити доступ до порту 8081
sudo ufw reload               # Перезавантаження правил UFW

У реальній ситуації бекенди будуть на окремих IP-адресах, і вам потрібно буде відкрити лише порти 80 та 443 на HAProxy, а на бекендах — порти для внутрішніх з'єднань тільки з IP HAProxy.

Конфігурація

Основний конфігураційний файл HAProxy знаходиться за шляхом /etc/haproxy/haproxy.cfg. Перед внесенням змін завжди робіть резервну копію оригінального файлу.


sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
sudo nano /etc/haproxy/haproxy.cfg

Очистіть вміст файлу haproxy.cfg та вставте наступну конфігурацію. Цей конфіг включає глобальні налаштування, налаштування за замовчуванням, frontend для HTTP та HTTPS, а також backend для наших Nginx-серверів.

Приклад конфігурації HAProxy для HTTP та HTTPS з SSL-термінацією

Ми налаштуємо HAProxy для обробки HTTP-трафіку (перенаправлення на HTTPS) та HTTPS-трафіку з SSL-термінацією. Для SSL-сертифікатів будемо використовувати Let's Encrypt через Certbot.

Отримання SSL-сертифіката за допомогою Certbot

Перш ніж налаштовувати HTTPS, нам потрібен SSL-сертифікат. Встановимо Certbot та отримаємо сертифікат для вашого домену (замініть your_domain.com на ваш реальний домен).


sudo apt install certbot -y   # Встановлення Certbot
sudo certbot certonly --standalone -d your_domain.com -d www.your_domain.com --agree-tos --email [email protected] --non-interactive # Отримання сертифіката

Certbot за замовчуванням використовує порт 80 для standalone-режиму. Переконайтеся, що порт 80 вільний на момент виконання цієї команди (тимчасово зупиніть Nginx, якщо він вже слухає на 80).


sudo systemctl stop nginx # Тимчасово зупиняємо Nginx, якщо він слухає на 80
# ... виконуємо команду certbot ...
sudo systemctl start nginx # Запускаємо Nginx назад

Сертифікати будуть розташовані в /etc/letsencrypt/live/your_domain.com/. HAProxy вимагає сертифікат у форматі PEM, який об'єднує приватний ключ та повний ланцюжок сертифікатів. Створимо такий файл:


sudo mkdir -p /etc/haproxy/certs/
sudo cat /etc/letsencrypt/live/your_domain.com/fullchain.pem /etc/letsencrypt/live/your_domain.com/privkey.pem | sudo tee /etc/haproxy/certs/your_domain.com.pem > /dev/null
sudo chmod -R go-rwx /etc/haproxy/certs # Встановлення строгих прав

Тепер HAProxy зможе використовувати цей файл /etc/haproxy/certs/your_domain.com.pem для SSL-термінації.

Файл конфігурації HAProxy (/etc/haproxy/haproxy.cfg)

global
    log /dev/log    local0
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    # Оновлення HAProxy до версії 2.9+ дозволяє використовувати більше ядер CPU
    # nbthread 2 # Використовує 2 потоки/ядра CPU, якщо доступно
    cpu-map 1 0 # Прив'язка потоку 1 до ядра 0
    cpu-map 2 1 # Прив'язка потоку 2 до ядра 1 (якщо nbthread 2)
    maxconn 20000 # Максимальна кількість одночасних з'єднань

defaults
    mode http
    log global
    option httplog
    option dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option redispatch
    retries 3
    timeout http-request 10s
    timeout queue 1m
    timeout connect 10s
    timeout client 1m
    timeout server 1m
    timeout http-keep-alive 20s
    timeout check 10s
    maxconn 5000 # Максимальна кількість з'єднань на frontend/backend

# Frontend для HTTP-трафіку (перенаправлення на HTTPS)
frontend http_in
    bind *:80
    mode http
    redirect scheme https code 301 if !{ ssl_fc } # Перенаправляємо весь HTTP на HTTPS

# Frontend для HTTPS-трафіку з SSL-термінацією
frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/your_domain.com.pem # Замініть на ваш домен
    mode http
    option httplog
    # ACL для визначення, який бекенд використовувати
    acl url_static path_beg /static /images /css /js
    acl url_admin path_beg /admin
    # Використання ACL для вибору бекенда
    use_backend bk_static if url_static
    use_backend bk_admin if url_admin
    default_backend bk_webservers

# Backend для статичного контенту (опціонально)
backend bk_static
    mode http
    balance roundrobin # Метод балансування: по черзі
    server static_server 127.0.0.1:8082 check # Приклад статичного сервера, якщо є

# Backend для адмін-панелі (опціонально)
backend bk_admin
    mode http
    balance leastconn # Метод балансування: найменша кількість з'єднань
    server admin_server 127.0.0.1:8083 check # Приклад адмін-сервера

# Backend для основних веб-серверів
backend bk_webservers
    mode http
    balance roundrobin # Метод балансування: по черзі
    option httpchk GET /healthz # Перевірка здоров'я за URL /healthz
    # У реальному середовищі тут будуть IP-адреси та порти ваших бекенд-серверів
    # Наприклад: server web1 192.168.1.10:80 check
    #           server web2 192.168.1.11:80 check
    server web1 127.0.0.1:8080 check inter 2s fall 3 rise 2 weight 100
    server web2 127.0.0.1:8081 check inter 2s fall 3 rise 2 weight 100

# Статистика HAProxy
listen stats
    bind *:8000 # Порт для доступу до статистики HAProxy
    mode http
    stats enable
    stats uri /haproxy_stats # URL для статистики
    stats realm Haproxy\ Statistics # Назва області авторизації
    stats auth admin:PASSWORD_HA_PROXY # Логін та пароль для доступу (обов'язково змініть!)
    stats refresh 10s # Оновлення статистики кожні 10 секунд

Важливі зауваження щодо конфігурації:

  • Замініть your_domain.com на ваш реальний домен у рядку bind *:443 ssl crt /etc/haproxy/certs/your_domain.com.pem.
  • Замініть PASSWORD_HA_PROXY на надійний пароль для доступу до сторінки статистики.
  • У секції backend bk_webservers:
    • balance roundrobin: Метод балансування, що розподіляє запити по черзі. Інші популярні методи: leastconn (найменша кількість активних з'єднань), source (на основі IP-адреси клієнта для "липких" сесій).
    • option httpchk GET /healthz: HAProxy надсилатиме HTTP GET-запит за шляхом /healthz на кожен бекенд для перевірки його працездатності. Ваші бекенди повинні відповідати на цей URL 200 OK.
    • server web1 127.0.0.1:8080 check inter 2s fall 3 rise 2 weight 100:
      • web1: Ім'я сервера.
      • 127.0.0.1:8080: IP-адреса та порт бекенда. У реальному середовищі це будуть IP-адреси ваших інших VPS.
      • check: Вмикає перевірку здоров'я.
      • inter 2s: Інтервал між перевірками здоров'я (2 секунди).
      • fall 3: Сервер вважатиметься непрацездатним після 3 невдалих перевірок.
      • rise 2: Сервер вважатиметься працездатним після 2 успішних перевірок.
      • weight 100: Відносна вага сервера при балансуванні (чим вище, тим більше трафіку він отримує).

Перевірка конфігурації HAProxy

Завжди перевіряйте синтаксис конфігурації перед перезапуском HAProxy.


sudo haproxy -c -f /etc/haproxy/haproxy.cfg # Перевірка синтаксису конфіга

Якщо помилок немає, ви побачите повідомлення "Configuration file is valid". Тепер перезапустіть HAProxy:


sudo systemctl restart haproxy # Перезапуск служби HAProxy
sudo systemctl status haproxy  # Перевірка статусу

Налаштування Nginx для /healthz

Для того щоб HAProxy міг перевіряти здоров'я наших бекендів, Nginx повинен відповідати на /healthz. Додайте до кожного файлу конфігурації Nginx (/etc/nginx/sites-available/backend1.conf та backend2.conf) всередині блоку server наступний location:


location /healthz {
    return 200 'OK';
    add_header Content-Type text/plain;
}

Після зміни кожного файлу Nginx, перевірте та перезапустіть Nginx:


sudo nginx -t
sudo systemctl restart nginx

Перевірка працездатності

1. Доступ до HTTP/HTTPS

Відкрийте ваш домен (your_domain.com) у браузері. Ви повинні бути автоматично перенаправлені на HTTPS, і вміст має завантажуватися. Якщо ви кілька разів оновите сторінку, ви побачите, як X-Backend-Server змінюється між "Backend 1" та "Backend 2", підтверджуючи роботу балансування.


curl -I http://your_domain.com # Перевірка редиректу
curl -I https://your_domain.com # Перевірка HTTPS та заголовка бекенда
2. Доступ до статистики HAProxy

Відкрийте в браузері http://ВАШ_IP_АДРЕС_VPS:8000/haproxy_stats. Введіть логін admin та пароль, який ви встановили в конфігу. Ви побачите сторінку статистики, де відображатимуться стани ваших бекендів, кількість з'єднань та інші метрики. Це чудовий інструмент для моніторингу.

Резервні копії та обслуговування

Надійна система резервних копій та регулярне обслуговування є критично важливими для будь-якого продакшн-середовища.

Що резервувати

Для HAProxy основними елементами для резервного копіювання є:

  • Конфігураційні файли HAProxy: /etc/haproxy/haproxy.cfg та будь-які інші файли, на які він посилається (наприклад, списки ACL, якщо вони винесені в окремі файли).
  • SSL-сертифікати: Директорія /etc/letsencrypt/live/your_domain.com/ та об'єднаний PEM-файл /etc/haproxy/certs/your_domain.com.pem. Ці файли містять приватні ключі та повинні зберігатися в безпеці.

Простий скрипт авторезервного копіювання

Створимо простий скрипт, який буде архівувати важливі файли та надсилати їх у безпечне місце. Як приклад будемо використовувати rsync для копіювання на віддалений сервер або S3-сумісне сховище (наприклад, MinIO, Wasabi, або інший VPS). Для S3-сумісних сховищ знадобиться встановлення awscli або іншого S3-клієнта.

Припустимо, у вас є віддалений сервер для резервних копій з користувачем backupuser та налаштованим SSH-ключем.


sudo nano /usr/local/bin/backup_haproxy.sh

Вміст скрипта (замініть backupuser@backup_server_ip та /path/to/remote/backups):


#!/bin/bash

# Каталог для тимчасових резервних копій
BACKUP_DIR="/tmp/haproxy_backup"
DATE=$(date +%Y%m%d%H%M%S)
ARCHIVE_NAME="haproxy_config_${DATE}.tar.gz"
REMOTE_DEST="backupuser@backup_server_ip:/path/to/remote/backups" # Замініть на ваш віддалений сервер

mkdir -p "$BACKUP_DIR"

echo "Початок резервного копіювання конфігурації HAProxy та SSL-сертифікатів..."

# Копіювання конфігів HAProxy
cp /etc/haproxy/haproxy.cfg "$BACKUP_DIR/"
cp -R /etc/haproxy/certs "$BACKUP_DIR/" # Копіювання об'єднаного PEM-файлу
# Копіювання оригінальних Let's Encrypt сертифікатів
cp -R /etc/letsencrypt/live/your_domain.com "$BACKUP_DIR/letsencrypt_certs" # Замініть на ваш домен

# Створення архіву
tar -czf "$BACKUP_DIR/$ARCHIVE_NAME" -C "$BACKUP_DIR" .

echo "Архів створено: $BACKUP_DIR/$ARCHIVE_NAME"

# Надсилання архіву на віддалений сервер
if rsync -avz "$BACKUP_DIR/$ARCHIVE_NAME" "$REMOTE_DEST"; then
    echo "Резервна копія успішно надіслана на $REMOTE_DEST"
else
    echo "Помилка при надсиланні резервної копії на $REMOTE_DEST"
    exit 1
fi

# Очищення тимчасових файлів
rm -rf "$BACKUP_DIR"

echo "Резервне копіювання завершено."

Зробіть скрипт виконуваним:


sudo chmod +x /usr/local/bin/backup_haproxy.sh

Налаштування Cron для автоматичного запуску

Додайте скрипт у Cron для щоденного або щотижневого запуску.


sudo crontab -e

Додайте наступний рядок для щоденного запуску о 3:00 ночі:


0 3    /usr/local/bin/backup_haproxy.sh > /var/log/haproxy_backup.log 2>&1

Куди зберігати резервні копії

  • Зовнішній S3-сумісний сервіс: Хмарні сховища типу Amazon S3, DigitalOcean Spaces, Backblaze B2, MinIO (self-hosted) — це надійний та масштабований варіант.
  • Окремий VPS: Ви можете використовувати інший, менш потужний VPS спеціально для зберігання резервних копій.
  • NAS/локальне сховище: Для домашнього використання або невеликих компаній.

Головне правило: резервні копії повинні зберігатися окремо від основного сервера, бажано в іншому географічному місці.

Оновлення: Rolling vs. Maintenance Window

Регулярні оновлення ПЗ важливі для безпеки та отримання нових функцій. Для HAProxy є кілька підходів:

  • Maintenance Window (Вікно обслуговування): Традиційний підхід, при якому оновлення застосовуються в заздалегідь визначений час, коли трафік мінімальний. Це може призвести до короткочасного простою, але простіше в реалізації для одиночного HAProxy. Для цього достатньо виконати sudo apt update && sudo apt upgrade -y та перезапустити HAProxy.
  • Rolling Updates (Поступові оновлення): Для високодоступних систем з двома і більше HAProxy інстансами. Оновлюйте по одному балансувальнику за раз. Спочатку оновлюєте один, перенаправляєте на нього весь трафік, потім оновлюєте другий. Це забезпечує нульовий час простою, але вимагає більш складної архітектури з кількома HAProxy (наприклад, з використанням Keepalived для VIP).

Для одиночного VPS з HAProxy, як у цьому туторіалі, найбільш практичним є підхід з вікном обслуговування. Переконайтеся, що ви завжди перевіряєте конфігурацію HAProxy (haproxy -c) після будь-яких змін або оновлень, перш ніж перезапускати службу.

Продовження Let's Encrypt сертифікатів

Certbot автоматично налаштовує cron-завдання для продовження сертифікатів. Ви можете перевірити це:


sudo systemctl list-timers | grep certbot

Якщо сертифікати успішно продовжені, вам потрібно буде знову об'єднати їх у PEM-файл для HAProxy та перезавантажити HAProxy:


# Цей скрипт можна додати в cron після автоматичного продовження Certbot
#!/bin/bash
DOMAIN="your_domain.com" # Замініть на ваш домен
CERT_PATH="/etc/letsencrypt/live/$DOMAIN"
HAPROXY_CERT_PATH="/etc/haproxy/certs/$DOMAIN.pem"

if [ -f "$CERT_PATH/fullchain.pem" ] && [ -f "$CERT_PATH/privkey.pem" ]; then
    sudo cat "$CERT_PATH/fullchain.pem" "$CERT_PATH/privkey.pem" | sudo tee "$HAPROXY_CERT_PATH" > /dev/null
    sudo chmod -R go-rwx /etc/haproxy/certs
    sudo systemctl reload haproxy
    echo "HAProxy SSL-сертифікат оновлено та HAProxy перезавантажено."
else
    echo "Помилка: Сертифікати Let's Encrypt не знайдено для $DOMAIN."
fi

Збережіть цей скрипт, наприклад, як /usr/local/bin/renew_haproxy_cert.sh, зробіть його виконуваним та додайте в cron для запуску після продовження Certbot (наприклад, щотижня).

Вирішення проблем + FAQ

У цьому розділі ми розглянемо типові проблеми, з якими можна зіткнутися при налаштуванні HAProxy, та надамо відповіді на поширені запитання.

HAProxy не запускається або видає помилку конфігурації

Проблема: Після зміни haproxy.cfg HAProxy не запускається, або systemctl status haproxy показує помилки.

Що перевірити:

  • Синтаксис конфігурації: Це найчастіша причина. Використовуйте sudo haproxy -c -f /etc/haproxy/haproxy.cfg для перевірки синтаксису. Будь-яка друкарська помилка або неправильний відступ може призвести до помилки.
  • Логи HAProxy: Перевірте системні логи: sudo journalctl -u haproxy або sudo tail -f /var/log/syslog. HAProxy зазвичай дуже детально описує причину відмови.
  • Доступність портів: Переконайтеся, що порти, які HAProxy намагається слухати (наприклад, 80, 443), не зайняті іншим процесом (наприклад, Nginx). Використовуйте sudo ss -tulpn | grep -E "80|443".
  • Права доступу до файлів: Переконайтеся, що користувач haproxy (або той, під яким він запускається) має права на читання конфігураційного файлу та SSL-сертифікатів.

Як виправити: Виправте помилки в haproxy.cfg, звільніть зайняті порти, перевірте права. Після кожної зміни конфігурації HAProxy, виконайте sudo haproxy -c -f /etc/haproxy/haproxy.cfg і тільки потім sudo systemctl restart haproxy.

Помилка "503 Service Unavailable" або "No servers are available"

Проблема: Браузер показує помилку 503, або в логах HAProxy видно, що бекенди недоступні.

Що перевірити:

  • Стан бекендів: Перевірте, чи запущені ваші бекенд-сервери (Nginx, Apache, ваш додаток) і чи слухають вони на правильних портах. Використовуйте sudo systemctl status nginx (або ваш додаток).
  • Доступність бекендів з HAProxy: З сервера HAProxy спробуйте підключитися до бекенду напряму: curl http://127.0.0.1:8080/healthz (замініть IP та порт на реальні бекенди). Переконайтеся, що брандмауер на бекендах (якщо вони на інших VPS) дозволяє вхідні з'єднання від IP-адреси HAProxy.
  • Налаштування перевірок стану (health checks): Переконайтеся, що option httpchk та шлях /healthz налаштовані коректно як в HAProxy, так і на бекендах.
  • Сторінка статистики HAProxy: Відкрийте сторінку статистики HAProxy (http://ВАШ_IP_АДРЕС_VPS:8000/haproxy_stats) і подивіться статус бекенд-серверів. Там буде вказана причина, через яку сервери позначені як DOWN.

Як виправити: Усуньте проблеми на бекендах, перевірте мережеву зв'язність, скоригуйте налаштування перевірок стану. Якщо бекенди на окремих VPS, переконайтеся, що їхні фаєрволи дозволяють вхідні з'єднання з HAProxy.

Повільна робота або висока затримка

Проблема: Додаток працює повільно, або запити обробляються з великою затримкою при проходженні через HAProxy.

Що перевірити:

  • Навантаження на HAProxy: Перевірте використання CPU та RAM на VPS з HAProxy (htop, top). Високе навантаження на CPU може вказувати на вузьке місце, особливо при інтенсивній SSL-термінації.
  • Мережева пропускна здатність: Переконайтеся, що мережа не є вузьким місцем. Використовуйте iftop або nload.
  • Таймаути HAProxy: Перевірте налаштування timeout client, timeout server, timeout connect в haproxy.cfg. Занадто короткі таймаути можуть обривати повільні з'єднання.
  • Навантаження на бекенди: Перевірте навантаження на самих бекенд-серверах. Можливо, проблема не в HAProxy, а в недостатній кількості ресурсів на бекендах або неоптимізованому додатку.

Як виправити: Збільште ресурси VPS для HAProxy (CPU/RAM), якщо він перевантажений. Оптимізуйте налаштування таймаутів. Розгляньте додавання більшої кількості бекенд-серверів або оптимізацію вашого додатку.

Неправильна IP-адреса клієнта в логах бекендів

Проблема: У логах ваших бекенд-серверів (Nginx, Apache) відображається IP-адреса HAProxy, а не реальна IP-адреса клієнта.

Що перевірити: Переконайтеся, що в секції defaults або frontend HAProxy увімкнена опція option forwardfor. HAProxy додає заголовок X-Forwarded-For з реальною IP клієнта.

Як виправити: Налаштуйте ваш бекенд-сервер для читання заголовка X-Forwarded-For. Наприклад, для Nginx додайте в блок log_format:


log_format combined_proxy '$remote_addr - $remote_user [$time_local] '
                          '"$request" $status $body_bytes_sent '
                          '"$http_referer" "$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log combined_proxy;

Або використовуйте модуль real_ip, якщо HAProxy знаходиться у вашій внутрішній мережі.

SSL-сертифікати не працюють або закінчився термін їх дії

Проблема: Браузери показують попередження про безпеку, або HTTPS не працює.

Що перевірити:

  • Термін дії сертифіката: Перевірте термін дії сертифіката: sudo openssl x509 -in /etc/haproxy/certs/your_domain.com.pem -noout -dates.
  • Шлях до сертифіката: Переконайтеся, що шлях до PEM-файлу в haproxy.cfg (bind *:443 ssl crt /etc/haproxy/certs/your_domain.com.pem) коректний.
  • Формат сертифіката: HAProxy вимагає об'єднаний файл PEM. Переконайтеся, що ви правильно об'єднали fullchain.pem та privkey.pem.
  • Автоматичне продовження: Перевірте, чи працює cron-завдання Certbot для продовження сертифікатів та ваш скрипт для оновлення PEM-файлу HAProxy.

Як виправити: Продовжіть сертифікат за допомогою Certbot (sudo certbot renew --force-renewal, якщо потрібно терміново). Виправте шляхи або формат файлу. Переконайтеся, що скрипт оновлення сертифікатів для HAProxy запускається після продовження Certbot.

Який VPS-конфіг мінімально підійде?

Для HAProxy, що виступає в ролі балансувальника навантаження для невеликого або середнього проекту (до кількох сотень одночасних з'єднань), мінімально підійде VPS з 1 ядром CPU, 1 GB RAM, 20-40 GB SSD та мережевим каналом від 100 Mbps. Якщо планується інтенсивна SSL-термінація або дуже високий трафік, рекомендується збільшити CPU до 2 ядер та RAM до 2 GB. Важливо також переконатися, що бекенд-сервери, до яких HAProxy перенаправлятиме трафік, мають достатні ресурси.

Що вибрати — VPS чи dedicated для цього завдання?

Вибір між VPS та dedicated сервером для HAProxy залежить від масштабу та критичності вашого проекту. Для більшості веб-додатків та сервісів, навіть з тисячами одночасних користувачів, потужного VPS буде більш ніж достатньо. HAProxy дуже ефективний і може обробляти значний обсяг трафіку на віртуальній машині. Dedicated сервер варто розглядати лише у випадках крайнього навантаження (десятки та сотні тисяч одночасних з'єднань), коли продуктивність CPU або мережева пропускна здатність VPS стає вузьким місцем через обмеження віртуалізації, або коли потрібен повний контроль над апаратним забезпеченням та максимальна фізична ізоляція. Для початку завжди рекомендується почати з добре сконфігурованого VPS, а потім масштабуватися до dedicated, якщо це дійсно необхідно.

Висновки та наступні кроки

Вітаємо! Ви успішно налаштували HAProxy на вашому VPS, створивши високопродуктивну та відмовостійку архітектуру для ваших веб-застосунків. Тепер ваш сервіс здатен ефективно розподіляти навантаження між кількома бекенд-серверами, термінувати SSL-трафік та автоматично обробляти відмови окремих компонентів, значно підвищуючи доступність та стабільність.

Наступні кроки для розвитку вашої інфраструктури:

  • Додавання другого HAProxy з Keepalived: Для забезпечення повної відмовостійкості самого балансувальника, розгорніть другий інстанс HAProxy та використовуйте Keepalived для створення віртуальної IP-адреси (VIP), яка автоматично перемикатиметься між активним та пасивним HAProxy у разі відмови.
  • Моніторинг та сповіщення: Інтегруйте HAProxy із системами моніторингу, такими як Prometheus + Grafana, Zabbix або Datadog. Це дозволить вам відстежувати ключові метрики (кількість з'єднань, стан бекендів, затримки) та отримувати сповіщення про будь-які аномалії.
  • Автоматизація розгортання: Для спрощення керування та масштабування розгляньте використання інструментів автоматизації конфігурації, таких як Ansible, Puppet або Chef, для розгортання та керування HAProxy та бекенд-серверами.
  • Розширені можливості HAProxy: Вивчіть складніші функції HAProxy, такі як кешування, переписування URL, захист від DDoS-атак, інтеграція з WAF (Web Application Firewall) та динамічна зміна конфігурації без перезапуску.

Поділитися цим записом:

налаштування haproxy на VPS: високопродуктивне балансування навантаження та відмовостійкість
support_agent
Valebyte Support
Usually replies within minutes
Hi there!
Send us a message and we'll reply as soon as possible.