← Назад к статьям

Настройка балансировки нагрузки для Jira Data Center

Load balancer — критичный компонент кластера Jira Data Center. Он распределяет запросы между узлами, обеспечивает отказоустойчивость, позволяет выполнять обновления без простоя. Правильная настройка балансировщика критична для производительности и стабильности кластера. В этой статье разберу практические подходы к настройке балансировки нагрузки.

Зачем нужен load balancer

Балансировщик нагрузки решает несколько задач:

  • Распределение нагрузки между узлами кластера
  • Обеспечение высокой доступности (автоматическое исключение неработающих узлов)
  • Поддержка zero-downtime обновлений
  • SSL termination (расшифровка HTTPS на балансировщике)

Sticky Sessions (Session Affinity)

Jira требует, чтобы запросы одного пользователя обрабатывались одним узлом в рамках сессии. Это достигается через sticky sessions — балансировщик должен направлять все запросы пользователя на тот же узел.

Cookie-based Sticky Sessions

Балансировщик использует cookie для определения узла. Пример для HAProxy:

backend jira_backend
    balance roundrobin
    cookie JSESSIONID prefix nocache
    server node1 10.0.1.10:8080 check cookie node1
    server node2 10.0.1.11:8080 check cookie node2

Балансировщик устанавливает cookie с именем узла, и последующие запросы направляются на этот узел.

Health Checks

Health checks позволяют балансировщику автоматически исключать неработающие узлы из балансировки.

HTTP Health Check

Балансировщик периодически проверяет доступность узла через HTTP запрос. Используйте endpoint /status для проверки:

backend jira_backend
    option httpchk GET /status
    http-check expect status 200
    server node1 10.0.1.10:8080 check
    server node2 10.0.1.11:8080 check

SSL Termination

SSL termination на балансировщике упрощает управление сертификатами и снижает нагрузку на узлы Jira. Балансировщик расшифровывает HTTPS и отправляет HTTP на узлы.

Конфигурация для разных балансировщиков

HAProxy

global
    log /dev/log local0
    maxconn 4096

defaults
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend jira_frontend
    bind *:443 ssl crt /path/to/certificate.pem
    default_backend jira_backend

backend jira_backend
    balance roundrobin
    cookie JSESSIONID prefix nocache
    option httpchk GET /status
    http-check expect status 200
    server node1 10.0.1.10:8080 check cookie node1
    server node2 10.0.1.11:8080 check cookie node2

Nginx

upstream jira_backend {
    ip_hash; # Sticky sessions based on IP
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}

server {
    listen 443 ssl;
    server_name jira.company.com;
    
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/key.key;
    
    location / {
        proxy_pass http://jira_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Выводы

Правильная настройка балансировки нагрузки критична для работы кластера Data Center. Используйте sticky sessions для обеспечения корректной работы сессий, настройте health checks для автоматического исключения неработающих узлов.

Если нужна помощь с настройкой балансировки нагрузки — свяжитесь со мной.