چظور میتونیم بفهمیم وب سایتی از لود بالانسینگ استفاده میکند یا نه ؟‌
با استفاده از lbd می توانیم بدانیم که یک دامین خاص از قابلیت Load-Balancing در حالت http و DNS استفاده می کند یا خیر، خروجی این برنامه را خط فرمان لینوکس کالی مشاهده می کنید:

# lbd

lbd - load balancing detector 0.1 - Checks if a given domain uses load-balancing.
Written by Stefan Behte (http://ge.mine.nu)
Proof-of-concept! Might give false positives.
usage: /usr/bin/lbd [domain]

در مثالی روش استفاده از این فرمان را مشاهده می کنید:

# lbd example.com

lbd - load balancing detector 0.1 - Checks if a given domain uses load-balancing.
Written by Stefan Behte (http://ge.mine.nu)
Proof-of-concept! Might give false positives.

Checking for DNS-Loadbalancing: NOT FOUND
Checking for HTTP-Loadbalancing [Server]:
ECS (sea/55ED)
ECS (sea/1C15)
FOUND
#security #lbd #load_balancing @unixmens

مقاله Dynamic Load Balancing of Virtual Machines using qemu /kvm
https://www.dropbox.com/s/7poaqts5yzvytq8/Dynamic%20Load%20Balancing%20of%20Virtual%20Machines%20using%20kvm_qemu.pdf?dl=0
#virtualization #kvm #load_balancing @unixmens

زمانیکه تعداد کاربران سایت بیشتر میشود و ترافیک سایت افزایش می‌یابد عموما یک نمونه ( instance ) از برنامه نمیتواند پاسخگوی همه درخواست‌ها باشد و مجبور هستیم چندین نمونه برنامه را بر روی چند سرور اجرا کنیم. با این حال نیازمند یک وب سرور هستیم که درخواست‌های ارسال شده را در بین instance های موجود پخش کند. با انجام این کار تعداد ریکوئست‌ها در بین instance ها تقسیم میشوند. برای انجام اینکار میتوانیم از nginx استفاده کنیم. nginx قابلیت load balancing را دارد. برای پیاده سازی load balancing در nginx باید در فایل nginx.conf یک گروه از نوع upstream ایجاد کنید در کانتکست http.

http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
}

در کانفیگ بالا یک گروه به نام backend ایجاد کرده‌ایم ...

#nginx #proxy #reverseproxy #reverse_proxy #load #loadbalancing #load_balancing

▎Introduction

Health checks are vital for ensuring high availability and fault tolerance in web applications. NGINX, a powerful web server, provides various methods for implementing health checks. This guide explores how to configure NGINX for both active and passive health checks, enhancing the robustness and reliability of your services.

▎What are Health Checks?

Health checks are tests conducted by load balancers or reverse proxies to assess if a backend server can handle requests. Active health checks proactively test servers at regular intervals, while passive health checks monitor ongoing traffic and flag servers as unhealthy when errors exceed a specified threshold.

▎Active Health Checks

Here's a basic configuration for active health checks in NGINX:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "HEAD /health HTTP/1.1rnHost: localhostrnConnection: closernrn";
        check_http_expect_alive http_2xx http_3xx;
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

In this setup, NGINX sends a HEAD request to the /health endpoint every 3 seconds. A server is deemed healthy if it returns a 2xx or 3xx HTTP status code twice in succession (rise=2). If it fails to respond correctly 5 times consecutively (fall=5), it is marked unhealthy.

▎Passive Health Checks

For passive health checks, NGINX analyzes live traffic. Here’s the configuration:

stream {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com max_fails=2 fail_timeout=30s;
    }

    server {
        listen 80;
        proxy_pass backend;
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    }
}

In this configuration, if a backend server fails to respond correctly twice within 30 seconds (max_fails=2, fail_timeout=30s), it is temporarily removed from the pool. The proxy_next_upstream directive specifies which errors will trigger a retry with a different server.

▎Advanced Health Check Configurations

For more complex scenarios, consider this advanced configuration using shared memory zones and custom failure detection:

http {
    upstream backend {
        zone backend 64k;
        server backend1.example.com;
        server backend2.example.com;

        health_check
        match=healthy
        interval=2000
        fails=3
        passes=1
        uri=/custom_check;
    }

    match healthy {
        status 200-399;
    }

    server {
        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
        }
    }
}

This example includes a health_check block that conducts checks every 2 seconds, with specific conditions for failing and passing. The status codes that indicate a healthy server are defined in a separate match block labeled healthy.

▎Testing and Troubleshooting Health Checks

To verify your health checks, use NGINX’s logging capabilities:

server {
    location / {
        proxy_pass http://backend;
        access_log /var/log/nginx/backend_access.log;
        error_log /var/log/nginx/backend_error.log;
    }

    location /health {
        access_log /var/log/nginx/health_access.log;
        proxy_pass http://backend;
    }
}

By directing access logs for the health check endpoint to a separate file, you can easily monitor their status. The error log is useful for troubleshooting any issues.

▎Automating Health Checks with NGINX Plus

NGINX Plus users benefit from dynamic health checks and an intuitive dashboard for management. The configuration process is straightforward:

[Continue with configuration details specific to NGINX Plus.]





#nginx #ha #load #balancing #linux #net

https://t.me/unixmens