Kādus slodzes līdzsvarotājus jūs zināt? Kāda ir jūsu…

Zināmi šādi slodzes līdzsvarotāju veidi:

Aparatūras (Hardware Load Balancers): Specializēti ierīces. Piemērs: F5 BIG-IP.
Programmatūras (Software Load Balancers): Darbojas kā programmatūra. Piemēri: HAProxy, Nginx, AWS Elastic Load Balancing (ELB), Google Cloud Load Balancing, Azure Load Balancer.

Ir pieredze ar HAProxy un Nginx kā programmatūras slodzes līdzsvarotājiem, kā arī ar AWS ELB mākoņrisinājumiem.

HAProxy:

Tika izmantots TCP un HTTP trafika līdzsvarošanai.
Konfigurācijas tika veiktas ar konfigurācijas failiem.
Tika izmantots:
- HTTP pieprasījumu sadalīšanai starp tīmekļa serveriem.
- Augstas pieejamības nodrošināšanai datu bāzēm (TCP trafiks).
Realizēti:
- Līdzsvarošanas algoritmi (round-robin, leastconn).
- Serveru darbības pārbaudes.
- SSL terminācija.

# HAProxy konfigurācijas piemērs
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 # vai 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 # Līdzsvarošanas algoritms
    server s1 192.168.1.10:80 check # Darbojošs serveris 1
    server s2 192.168.1.11:80 check # Darbojošs serveris 2

Nginx:

Tika izmantots kā reverse proxy un HTTP(S) trafika līdzsvarotājs.
Konfigurācijas tika veiktas nginx.conf failā vai iekļautajos failos.
Tika izmantots:
- Slodzes sadalīšanai starp tīmekļa serveriem un mikropakalpojumiem.
- Kešatmiņai, kompresijai, SSL terminācijai.
Realizēti:
- Dažādi līdzsvarošanas metodes (round-robin, least_conn, ip_hash).
- Darbības pārbaudes.
- Virtuālo hostu konfigurācija.

# Nginx konfigurācijas piemērs
http {
    upstream backend_servers {
        server 192.168.1.20:8080 weight=1; # Servers 1
        server 192.168.1.21:8080 weight=1; # Servers 2
        # least_conn; # Cits līdzsvarošanas veids
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend_servers; # Proxy grupa
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            # Citas proxy konfigurācijas
        }
    }
}

AWS ELB:

Application Load Balancer (ALB): Tika izmantots HTTP/HTTPS trafika līdzsvarošanai. L7 līmenī.
- Maršrutizē pieprasījumus pēc URL, galvenes un HTTP metodes.
- Integrācija ar Auto Scaling grupām.
- SSL terminācija, Web Application Firewall (WAF).
Network Load Balancer (NLB): Tika izmantots TCP/UDP trafika līdzsvarošanai. L4 līmenī.
- Augstas veiktspējas un zema aizkave.
- Tiek izmantots datu bāzu, spēļu serveru un citu aizkavi jutīgu lietojumprogrammu līdzsvarošanai.

Pieredze ietvēra Listeners, Target Groups, veselības pārbaudes un integrāciju ar citiem AWS pakalpojumiem, izmantojot AWS Management Console, AWS CLI un Terraform.

Tehnoloģijas:

Konfigurācija: Rokas darbs ar failiem, Ansible, Chef, Puppet.
Infrastruktūra kā kods: Terraform automātiskai izvietošanai un pārvaldībai mākoņā.
Uzraudzība: Prometheus, Grafana ar eksportētājiem HAProxy/Nginx vai CloudWatch AWS ELB.
CIDI: Konfigurācijas aktivizēšana un pārkonfigurēšana CI/CD pipeline'os.

Kopumā izvēle balstījās uz lietojuma prasībām (trafika veids, veiktspēja, funkcionalitāte), infrastruktūru (mākoņs vai on-premise) un budžetu.

Kādus slodzes līdzsvarotājus jūs zināt? Kāda ir jūsu pieredze ar tiem un kādas tehnoloģijas esat izmantojis?