راه‌اندازی لودبالانسر HAProxy و Keepalived با VIP و VRRP

در این تمرین یک نقطهٔ ورود HTTP با دو لودبالانسر فعال/آماده‌به‌کار می‌سازیم؛ قرار نیست قابلیت IP شناور اختصاصی سرویس‌دهندهٔ ابری را شبیه‌سازی کنیم. بررسی را جداگانه روی LB-01 و LB-02، در یک نشست مدیریتی پایدار انجام بده. هر دو سرور باید در یک شبکهٔ لایهٔ دوم باشند یا ارائه‌دهندهٔ شبکه انتقال VIP و به‌روزرسانی همسایه‌ها را صریحاً پشتیبانی کند.

در مثال، نشانی LB-01 برابر 10.20.30.11، نشانی LB-02 برابر 10.20.30.12 و IP مجازی برابر 10.20.30.100 است؛ ماسک /24 و نام کارت شبکه ens18 در نظر گرفته شده‌اند. این مقادیر فقط نمونه‌اند. همهٔ نشانی‌ها و نام کارت شبکه را در فایل‌های هر دو نود هماهنگ با محیط خودت تغییر بده و VIP را به‌صورت دائمی به هیچ نودی اختصاص نده.

نسخهٔ واقعی سیستم‌عامل را با گزینهٔ انتخاب‌شده در بالای مقاله مقایسه کن. وجود یک ترمینال لینوکس به معنی اجراشدن systemd نیست. اگر از قبل روی این سرورها VRRP یا سرویس دیگری روی پورت 80 داری، این سناریوی نصب تازه را بدون طراحی مهاجرت اجرا نکن.

cat /etc/os-release
ps -p 1 -o comm=
ip -br -4 address
ip -4 route
sudo ss -ltnp | grep -E ":80[[:space:]]" || true

پیش از تنظیم جابه‌جایی خودکار، دو برنامهٔ HTTP مستقل و دارای سرویس مدیریتی آماده داشته باش: app1 روی 10.20.30.21:8080 و app2 روی 10.20.30.22:8080. هر دو باید برای درخواست GET به مسیر /healthz با Host نمونهٔ lab.internal دقیقاً پاسخ 200 بدهند و در مسیر / هم پاسخ کاربردی داشته باشند. نشانی‌ها، پورت، Host و مسیر سلامت را با شرایط برنامهٔ واقعی هماهنگ کن؛ این آموزش یک وب‌سرور آزمایشی ناامن را راه‌اندازی نمی‌کند.

این درخواست‌ها را از هر دو لودبالانسر بفرست. بازبودن پورت TCP کافی نیست؛ اگر مسیر سلامت به صفحهٔ ورود، ریدایرکت یا پاسخ خطا می‌رسد، ابتدا آن را اصلاح کن. موفقیت این بخش هنوز انتقال VIP را ثابت نمی‌کند.

curl --noproxy '*' -i --max-time 4 -H 'Host: lab.internal' http://10.20.30.21:8080/healthz
curl --noproxy '*' -i --max-time 4 -H 'Host: lab.internal' http://10.20.30.22:8080/healthz
curl --noproxy '*' --fail --silent --show-error --max-time 4 -H 'Host: lab.internal' http://10.20.30.21:8080/

EXAMPLE ONLY — supplied by an application, not measured on WIUNIX production:
HTTP/1.1 200 OK
Content-Type: text/plain

OK

با مسئول شبکه هماهنگ کن که VIP و شناسهٔ VRID در این شبکه تکراری نباشند. پیام‌های VRRP در حالت unicast از پروتکل IP شمارهٔ 112 استفاده می‌کنند، نه از پورت 112 در TCP یا UDP. دریافت این پروتکل را فقط بین نشانی اصلی دو نود مجاز کن. دسترسی کاربران آزمایش به TCP/80 و دسترسی هر دو لودبالانسر به TCP/8080 بک‌اندها باید برقرار باشد. اگر شبکهٔ ابری IP ثانویه یا اعلان ARP هنگام انتقال را نمی‌پذیرد، ادامه نده و از قابلیت رسمی همان ارائه‌دهنده استفاده کن.

دستورهای این بخش فقط وقتی اجرا می‌شوند که UFW نصب و فعال باشد. دسترسی HTTP مثال به زیرشبکهٔ آزمایش محدود می‌شود و اجازهٔ VRRP نیز فقط برای دو همتای نمونه روی ens18 است. در سایر فایروال‌ها چیزی خودکار تغییر نمی‌کند؛ قواعد nftables، تجهیزات شبکه و سرویس‌دهنده را جداگانه بررسی کن. فایروال موجود را خاموش نکن.

پیش از ویرایش قوانین شبکه، اتصال کنسول یا مسیر مدیریتی جایگزین داشته باش. این سرویس HTTP بدون TLS صرفاً برای شبکهٔ خصوصی آزمایش است.

if command -v ufw >/dev/null && sudo ufw status | grep -q '^Status: active'; then
  sudo ufw allow in on ens18 from 10.20.30.0/24 to any port 80 proto tcp comment 'Academy HA HTTP lab'
  sudo ufw allow in on ens18 from 10.20.30.11 to any proto vrrp comment 'Academy VRRP LB01'
  sudo ufw allow in on ens18 from 10.20.30.12 to any proto vrrp comment 'Academy VRRP LB02'
  sudo ufw status numbered
else
  printf '%s\n' 'UFW not active: check your actual host/provider firewall manually'
fi

روی هر دو نود از مخزن رسمی همان Ubuntu یا Debian استفاده کن؛ برای این راهنما مخزن متفرقه اضافه نکن. پیش از تأیید نصب، فهرست تغییرات بسته‌ها را بخوان. نسخهٔ جزئی ممکن است با به‌روزرسانی امنیتی تغییر کند، پس نسخهٔ نصب‌شده را بررسی کن و به عدد ثابت متکی نباش.

اگر هنگام نصب یک سرویس خودکار فعال شد، آن را نشانهٔ آماده‌بودن HA در نظر نگیر. تنظیمات کامل HAProxy و VRRP در مراحل بعد نوشته می‌شود.

sudo apt update
sudo apt install haproxy keepalived curl iproute2 tcpdump
haproxy -v
keepalived --version 2>&1 | head -n 2

این سناریو فایل‌های نمونه را روی دو سرور اختصاصی می‌نویسد. از پیکربندی فعلی HAProxy و در صورت وجود از Keepalived روی هر نود نسخهٔ پشتیبان با دسترسی محدود root بگیر. اگر سرویس دیگری در حال استفاده از این فایل‌هاست، به‌جای جایگزینی مستقیم، ابتدا طرح مهاجرت داشته باش.

پشتیبان را در فضای امن نگه دار. بازگشت به وضعیت پیشین فقط وقتی مطمئن است که فایل‌های اولیه را حفظ کرده باشی.

sudo install -d -m 0700 /root/wiunix-academy-ha-backup
sudo cp -a /etc/haproxy/haproxy.cfg /root/wiunix-academy-ha-backup/haproxy.cfg.before
if sudo test -f /etc/keepalived/keepalived.conf; then
  sudo cp -a /etc/keepalived/keepalived.conf /root/wiunix-academy-ha-backup/keepalived.conf.before
fi

محتوای زیر را روی هر دو لودبالانسر ذخیره کن. HAProxy روی همهٔ نشانی‌های IPv4 همان میزبان گوش می‌دهد؛ بنابراین نود آماده‌به‌کار حتی قبل از مالکیت VIP می‌تواند پاسخ محلی بدهد. فرانت‌اند فقط HTTP روی پورت 80 است و توزیع درخواست میان دو برنامهٔ موجود به‌صورت round-robin انجام می‌شود.

بررسی سلامت با درخواست GET انجام می‌شود و فقط پاسخ 200 پذیرفته است. نشانی و پورت دو بک‌اند و مقدار Host را متناسب با برنامهٔ خودت اصلاح کن؛ مسیر سلامت روی دو نود باید یکی باشد. بازبودن پورت یا فعال‌بودن سرویس به‌تنهایی جای این بررسی را نمی‌گیرد.

این نمونه عمداً فقط HTTP در شبکهٔ خصوصی است. برای سرویس اینترنتی باید HTTPS، کنترل دسترسی، محدودیت درخواست و اعتماد به هدرهای پراکسی را در یک تغییر جداگانه بررسی کنی؛ این پورت آزمایشی را عمومی نکن.

global
    log /dev/log local0
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend public_http
    bind 0.0.0.0:80
    default_backend web_apps

backend web_apps
    balance roundrobin
    option httpchk
    http-check send meth GET uri /healthz ver HTTP/1.1 hdr Host lab.internal
    http-check expect status 200
    server app1 10.20.30.21:8080 check inter 2s fall 3 rise 2
    server app2 10.20.30.22:8080 check inter 2s fall 3 rise 2

قبل از تغییر سرویس، کل پیکربندی ذخیره‌شده را بررسی کن. فقط در صورت موفقیت اعتبارسنجی، سرویس را راه‌اندازی مجدد کن. ری‌استارت سرویس در حال استفاده می‌تواند اتصال‌ها را قطع کند؛ اینجا فرض بر راه‌اندازی اولیهٔ آزمایشگاه اختصاصی است و تغییرهای بعدی باید نوبتی انجام شوند.

از روی هر نود یک درخواست واقعی از مسیر HAProxy بفرست. وقتی بک‌اندها سالم‌اند، مسیر سلامت از پراکسی هم باید 200 برگرداند. با خطای 503 یا ریدایرکت، مرحلهٔ بعد را شروع نکن.

sudo haproxy -c -f /etc/haproxy/haproxy.cfg && sudo systemctl restart haproxy
sudo systemctl enable haproxy
systemctl is-active haproxy
status=$(curl --noproxy '*' --silent --show-error --max-time 4 \
  -o /dev/null -w '%{http_code}' -H 'Host: lab.internal' http://127.0.0.1/healthz) && {
  printf 'HTTP %s\n' "$status"
  [ "$status" = 200 ]
}

خروجی صرفاً نمونه:
Configuration file is valid
active
HTTP 200

این محتوا را در فایل اسکریپت جدید ذخیره کن. کد خروج صفر فقط وقتی برمی‌گردد که مسیر سلامت برنامه از طریق HAProxy محلی موفق شود. این روش نشان می‌دهد حداقل یک بک‌اند قابل استفاده است؛ سالم‌بودن هر دو بک‌اند یا دسترس‌پذیری VIP از بیرون را ثابت نمی‌کند.

مقدار Host و مسیر سلامت را با HAProxy و برنامه هماهنگ نگه دار. محدودیت دوثانیه‌ای و آستانه‌های خطا در Keepalived احتمال واکنش کاذب را کمتر می‌کنند اما قطعی صفر را تضمین نمی‌کنند.

کد پاسخ دقیقاً با 200 مقایسه می‌شود؛ ریدایرکت و هر کد دیگری حتی با موفقیت انتقال curl، شکست محسوب می‌شود.

#!/bin/sh
status=$(/usr/bin/curl --noproxy '*' --silent --show-error \
  --connect-timeout 1 --max-time 2 -o /dev/null -w '%{http_code}' \
  -H 'Host: lab.internal' http://127.0.0.1/healthz) || exit 1
[ "$status" = 200 ]

مالک فایل باید root باشد ولی کاربر کم‌دسترسی اجازهٔ خواندن و اجرای آن را داشته باشد. وجود حساب nobody و گروه nogroup را بررسی کن. سپس همان آزمون را با این هویت اجرا کن؛ تا وقتی نتیجهٔ HTTP سالم نیست، VIP را فعال نکن.

پوشهٔ بالادستی اسکریپت را برای کاربران عادی قابل‌نوشتن نکن و برای دورزدن خطای مجوز، دسترسی root به چک سلامت نده.

getent passwd nobody
getent group nogroup
sudo chown root:root /usr/local/sbin/wiunix-check-haproxy
sudo chmod 0755 /usr/local/sbin/wiunix-check-haproxy
sudo -u nobody /usr/local/sbin/wiunix-check-haproxy
printf "health-check exit=%s\n" "$?"

EXAMPLE OUTPUT ONLY:
health-check exit=0

این فایل را فقط روی LB-01 ذخیره کن. در زیرشبکهٔ مشترک، اولویت این نود 150 است و اعلان‌های VRRP با پروتکل IP شمارهٔ 112 مستقیم برای LB-02 ارسال می‌شوند. چون وزن اسکریپت صفر است، سه شکست پیاپی نود را وارد وضعیت FAULT می‌کند و فقط عدد اولویت را کاهش نمی‌دهد.

گزینهٔ nopreempt مانع پس‌گرفتن خودکار مالکیت پس از بازگشت نود ترجیحی است. این رفتار به معنی Failback کنترل‌شده است، نه تضمین انتقال بدون وقفه.

global_defs {
    router_id WIUNIX_LB01
    enable_script_security
    script_user nobody nogroup
}

vrrp_script chk_haproxy {
    script "/usr/local/sbin/wiunix-check-haproxy"
    interval 2
    timeout 2
    fall 3
    rise 2
}

vrrp_instance VI_HTTP {
    state BACKUP
    interface ens18
    virtual_router_id 51
    priority 150
    advert_int 1
    nopreempt
    unicast_src_ip 10.20.30.11
    unicast_peer {
        10.20.30.12
    }
    virtual_ipaddress {
        10.20.30.100/24 dev ens18
    }
    track_script {
        chk_haproxy
    }
}

این نسخه را فقط روی LB-02 ذخیره کن. نشانی محلی نمونه 10.20.30.12 و همتا 10.20.30.11 است. اولویت 100 آن را در حالت عادی نود آماده‌به‌کار می‌کند، اما پس از خرابی مالک فعلی می‌تواند VIP را بگیرد.

نشانی‌ها نمونه هستند؛ اگر فقط فایل نود اول یا فقط نشانی مبدأ را اصلاح کنی، ممکن است ارتباط VRRP قطع شود و هر دو نود هم‌زمان VIP را تصاحب کنند.

global_defs {
    router_id WIUNIX_LB02
    enable_script_security
    script_user nobody nogroup
}

vrrp_script chk_haproxy {
    script "/usr/local/sbin/wiunix-check-haproxy"
    interval 2
    timeout 2
    fall 3
    rise 2
}

vrrp_instance VI_HTTP {
    state BACKUP
    interface ens18
    virtual_router_id 51
    priority 100
    advert_int 1
    nopreempt
    unicast_src_ip 10.20.30.12
    unicast_peer {
        10.20.30.11
    }
    virtual_ipaddress {
        10.20.30.100/24 dev ens18
    }
    track_script {
        chk_haproxy
    }
}

Keepalived حالت بررسی پیکربندی دارد. دستور را روی هر نود اجرا کن و هشدارها را هم بخوان، نه فقط کد خروج. نام اینترفیس، مجوز اجرای اسکریپت و جهت نشانی مبدأ/همتا را بررسی کن. فایل بدون خطای نگارشی هنوز تضمین نمی‌کند که شبکه اعلان VRRP یا جابه‌جایی VIP را می‌پذیرد.

هشدارهای مربوط به امنیت اسکریپت و مجوز فایل باید قبل از انتخابات VRRP رفع شوند.

sudo keepalived --config-test -f /etc/keepalived/keepalived.conf
sudo -u nobody /usr/local/sbin/wiunix-check-haproxy
printf "script exit=%s\n" "$?"

وقتی HAProxy روی هر دو نود سالم است و ارتباط همتاها در شبکه آماده شده، Keepalived را روی LB-01 و LB-02 فعال و راه‌اندازی مجدد کن. شروع هر دو با BACKUP عمدی است. در شرایط معمول نود سالم با اولویت بالاتر مالک اولیه می‌شود، اما زمان شروع و وضعیت قبلی می‌تواند روی نتیجه اثر بگذارد.

در گزارش سرویس به تغییرهای MASTER، BACKUP و FAULT توجه کن. فعال‌بودن پردازش Keepalived در هر دو نود طبیعی است و به معنی مالکیت VIP در هر دو نیست.

sudo systemctl enable keepalived
sudo systemctl restart keepalived
systemctl is-active keepalived
sudo journalctl -u keepalived -n 40 --no-pager

EXAMPLE OUTPUT ONLY — host names and log timestamps vary:
LB-01: (VI_HTTP) Entering MASTER STATE
LB-02: (VI_HTTP) Entering BACKUP STATE

نشانی‌های کارت شبکهٔ مربوط به HA را جداگانه در LB-01 و LB-02 مشاهده کن. فقط یکی باید نشانی VIP را علاوه بر IP اصلی خودش داشته باشد. فعال‌بودن پردازش Keepalived را به‌جای این بررسی قبول نکن.

اگر هر دو نود VIP را دارند، احتمال قطع اعلان‌های همتا، اشتباه‌بودن VRID یا اینترفیس و Split-brain وجود دارد. تا زمان رفع علت، ترافیک کاربر را به این نشانی نفرست.

ip -br -4 address show dev ens18
sudo journalctl -u keepalived -n 25 --no-pager

EXAMPLE ONLY — separate observations:
LB-01: ens18 UP 10.20.30.11/24 10.20.30.100/24
LB-02: ens18 UP 10.20.30.12/24

درخواست را از دستگاه سومی بفرست که دسترسی شبکهٔ مجاز دارد؛ تست روی خود نود فعال کافی نیست. یک درخواست واقعی به VIP ارسال کن و موفق‌بودن پاسخ HTTP و تعلق آن به برنامهٔ موردنظر را بررسی کن.

ترکیب مالکیت یکتای VIP، پاسخ موفق از دستگاه بیرونی و محتوای واقعی برنامه نشان می‌دهد مسیر فعلی کار می‌کند. این نتیجه هنوز Failover یا حفظ اتصال‌های باز هنگام خرابی سرور را ثابت نمی‌کند.

result=$(curl --noproxy '*' --silent --show-error --connect-timeout 3 --max-time 8 \
  -H 'Host: lab.internal' -o /dev/null -w '%{http_code} %{remote_ip}' \
  http://10.20.30.100/) && {
  printf 'HTTP status and peer: %s\n' "$result"
  case "$result" in
    2[0-9][0-9]\ *) true ;;
    *) printf '%s\n' 'FAIL: expected HTTP 2xx without a redirect' >&2; false ;;
  esac
}

خروجی صرفاً نمونه؛ حاصل آزمون عملی نیست:
HTTP status and peer: 200 10.20.30.100

در زمان نگهداری هماهنگ‌شده، ابتدا از مرحلهٔ قبل مالک واقعی VIP را پیدا کن. فقط روی همان نود HAProxy را متوقف کن، نه Keepalived را؛ در این حالت چک HTTP شکست می‌خورد و Keepalived می‌تواند VIP را به همتا منتقل کند. دستور زیر فرض می‌کند LB-01 مالک فعلی است؛ اگر LB-02 مالک بود، توقف را روی همان LB-02 اجرا کن.

در مدت شکست‌های پیاپی چک، انتخابات VRRP و به‌روزرسانی ARP ممکن است وقفهٔ کوتاه رخ دهد. این آزمایش عمداً سرویس فعال را مختل می‌کند؛ بدون مجوز، امکان بازگشت و مانیتورینگ روی کاربران واقعی اجرا نکن.

پس از توقف، برای گذشتن از آستانه‌های تشخیص کمی صبر کن. هر دو لودبالانسر را هم‌زمان متوقف نکن.

sudo systemctl stop haproxy
sleep 10
ip -br -4 address show dev ens18
sudo journalctl -u keepalived -n 30 --no-pager

پس از توقف HAProxy فعال قبلی، نشانی‌های کارت شبکه را جداگانه روی LB-01 و LB-02 ببین. VIP باید از نود قبلی حذف و روی همتای سالم ثبت شده باشد؛ مالکیت هم‌زمان هر دو نود نشانهٔ Split-brain است.

این بررسی فقط انتقال مالکیت IP را ثابت می‌کند. برای اطمینان از پاسخ‌گویی برنامه، درخواست HTTP را از دستگاه سوم تکرار کن.

ip -br -4 address show dev ens18

خروجی صرفاً نمونه؛ پس از توقف LB-01:
LB-01: ens18 UP 10.20.30.11/24
LB-02: ens18 UP 10.20.30.12/24 10.20.30.100/24

حالا همان درخواست برنامه را از دستگاه سومی بیرون از دو لودبالانسر بفرست. معیار موفقیت، پاسخ HTTP از خود VIP قبلی و برنامهٔ موردنظر پس از تغییر مالک است.

انتقال VIP یا تغییر وضعیت Keepalived به‌تنهایی بازیابی دسترسی کاربر را ثابت نمی‌کند. در صورت timeout، ابتدا ARP و قابلیت انتقال نشانی در شبکهٔ بالادستی را بررسی کن.

result=$(curl --noproxy '*' --silent --show-error --connect-timeout 3 --max-time 8 \
  -H 'Host: lab.internal' -o /dev/null -w '%{http_code} %{remote_ip}' \
  http://10.20.30.100/) && {
  printf 'HTTP status and peer: %s\n' "$result"
  case "$result" in
    2[0-9][0-9]\ *) true ;;
    *) printf '%s\n' 'FAIL: expected HTTP 2xx without a redirect' >&2; false ;;
  esac
}

خروجی صرفاً نمونه؛ حاصل آزمون عملی نیست:
HTTP status and peer: 200 10.20.30.100

روی همان نودی که برای آزمایش متوقف کرده بودی، HAProxy را دوباره اجرا کن و سلامت محلی را تأیید کن. با nopreempt در هر دو همتا، معمولاً VIP روی MASTER سالم فعلی باقی می‌ماند و صرفاً به‌خاطر اولویت بیشتر به نود قبلی برنمی‌گردد.

نشانی‌های هر دو نود و پاسخ دستگاه سوم را دوباره ببین. برای بازگرداندن عمدی مالکیت در آینده، زمان نگهداری مشخص کن و فقط پس از اطمینان از سلامت نود بازیابی‌شده، Keepalived را روی MASTER فعلی متوقف کن. راه‌افتادن دوبارهٔ پردازش با بازپس‌گیری VIP یک چیز نیست.

sudo systemctl start haproxy
systemctl is-active haproxy
sudo -u nobody /usr/local/sbin/wiunix-check-haproxy
ip -br -4 address show dev ens18