Какие балансировщики нагрузки вам известны? Какой у вас был опыт работы с ними и какие технологии вы использовали?

Известны следующие типы балансировщиков нагрузки:

• Аппаратные (Hardware Load Balancers): Специализированные устройства. Пример: F5 BIG-IP.
• Программные (Software Load Balancers): Работают как программное обеспечение. Примеры: HAProxy, Nginx, AWS Elastic Load Balancing (ELB), Google Cloud Load Balancing, Azure Load Balancer.

Имеется опыт работы с HAProxy и Nginx как программными балансировщиками, а также с облачными решениями AWS ELB (Application Load Balancer и Network Load Balancer).

HAProxy:

• Использовался для балансировки TCP и HTTP трафика.
• Настройки производились через конфигурационные файлы.
• Применялся для:
  • Распределения HTTP-запросов между web-серверами.
  • Обеспечения высокой доступности баз данных (TCP-трафик).
• Реализованы:
  • Алгоритмы балансировки (round-robin, leastconn).
  • Проверки работоспособности (health checks) серверов.
  • SSL-терминация.

# Пример конфигурации HAProxy
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

defaults
    log     global
    mode    http # или tcp
    option  httplog
    option  dontlognull
    timeout connect 5000ms
    timeout client  50000ms
    timeout server  50000ms
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin # Алгоритм балансировки
    server s1 192.168.1.10:80 check # Сервер 1 с проверкой работоспособности
    server s2 192.168.1.11:80 check # Сервер 2 с проверкой работоспособности

Nginx:

• Использовался как reverse proxy и балансировщик HTTP(S) трафика.
• Настройки производились в файлах nginx.conf или включаемых файлах.
• Применялся для:
  • Распределения нагрузки на web-серверы и микросервисы.
  • Кэширования, компрессии, SSL-терминации.
• Реализованы:
  • Различные методы балансировки (round-robin, least_conn, ip_hash).
  • Проверки работоспособности в коммерческой версии (Nginx Plus) или с модулями.
  • Конфигурация виртуальных хостов.

# Пример конфигурации Nginx
http {
    upstream backend_servers {
        server 192.168.1.20:8080 weight=1; # Сервер 1 с весом
        server 192.168.1.21:8080 weight=1; # Сервер 2 с весом
        # least_conn; # Другой метод балансировки
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend_servers; # Проксирование на группу серверов
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            # Другие настройки проксирования
        }
    }
}

AWS ELB:

• Application Load Balancer (ALB): Использовался для балансировки HTTP/HTTPS трафика. На уровне L7.
  • Маршрутизация запросов на основе URL, заголовков и методов HTTP.
  • Интеграция с Auto Scaling Groups.
  • SSL-терминация, Web Application Firewall (WAF).
• Network Load Balancer (NLB): Использовался для балансировки TCP/UDP трафика на уровне L4.
  • Высокая производительность и низкая задержка.
  • Используется для балансировки трафика к базам данных, игровым серверам и другим приложениям, чувствительным к задержке.

Опыт включал настройку Listeners, Target Groups, health checks и интеграцию с другими сервисами AWS через AWS Management Console, AWS CLI и Terraform.

Технологии:

• Конфигурация: Ручное редактирование файлов, Ansible, Chef, Puppet.
• Инфраструктура-как-код: Terraform для автоматического развертывания и управления балансировщиками в облаке.
• Мониторинг: Prometheus, Grafana с экспортерами для HAProxy/Nginx или через CloudWatch для AWS ELB.
• CIDI: Включение конфигурации и перенастройки балансировщиков в CI/CD пайплайны.

В целом, выбор балансировщика зависел от требований приложения (тип трафика, производительность, функциональность), инфраструктуры (облако или on-premise) и бюджета.