Keepalived + VRRP: wysoka dostępność na VPS

Opublikowano: 9 kwietnia 2026 · Kategoria: VPS / High Availability

Keepalived to demon implementujący protokół VRRP, który pozwala przypisać jeden wirtualny adres IP do dwóch lub więcej serwerów. Gdy aktywny węzeł (master) przestaje odpowiadać, backup automatycznie przejmuje adres IP — bez ingerencji administratora, w ciągu zaledwie kilku sekund. To fundament każdej architektury high availability na VPS.

Jak działa VRRP i floating IP

VRRP (Virtual Router Redundancy Protocol) definiuje grupę serwerów współdzielących jeden wirtualny adres IP. Tylko jeden serwer w grupie (master) aktywnie obsługuje ten adres — pozostałe (backup) nasłuchują heartbeatów. Jeśli heartbeat nie dotrze przez określony czas, backup przejmuje adres i rozsyła gratuitous ARP, informując przełączniki sieciowe o zmianie przypisania MAC → IP.

Floating IP (nazywany też wirtualnym IP lub VIP) to adres przypisywany przez dostawcę VPS jako dodatkowy adres, który można przepinać między węzłami. Dostawcy tacy jak Hetzner czy Contabo oferują floating IP jako osobny zasób — płacisz za IP niezależnie od serwera, a routing można zmieniać przez API lub przez VRRP.

Instalacja Keepalived

Keepalived instalujesz na obu węzłach — zarówno na masterze jak i na backupie. Przed instalacją upewnij się, że kernel ma załadowany moduł ip_vs (LVS — Linux Virtual Server), jeśli planujesz load balancing warstwy 4.

# Ubuntu / Debian
apt update && apt install -y keepalived

# CentOS / RHEL / AlmaLinux
dnf install -y keepalived

# Sprawdź wersję
keepalived --version

# Włącz i uruchom
systemctl enable keepalived
systemctl start keepalived

Konfiguracja mastera i backupa

Główny plik konfiguracyjny to /etc/keepalived/keepalived.conf. Poniżej przykład dla dwóch węzłów z wirtualnym IP 192.168.1.100 na interfejsie eth0.

Węzeł MASTER (serwer 1, IP: 192.168.1.10):

vrrp_script chk_nginx {
    script "/usr/bin/systemctl is-active nginx"
    interval 2
    weight -20
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass secretpassword123
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        chk_nginx
    }

    notify_master "/etc/keepalived/notify.sh MASTER"
    notify_backup "/etc/keepalived/notify.sh BACKUP"
    notify_fault  "/etc/keepalived/notify.sh FAULT"
}

Węzeł BACKUP (serwer 2, IP: 192.168.1.11):

vrrp_script chk_nginx {
    script "/usr/bin/systemctl is-active nginx"
    interval 2
    weight -20
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass secretpassword123
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        chk_nginx
    }

    notify_master "/etc/keepalived/notify.sh MASTER"
    notify_backup "/etc/keepalived/notify.sh BACKUP"
    notify_fault  "/etc/keepalived/notify.sh FAULT"
}

Kluczowe parametry: priority (wyższa wartość = master, różnica minimum 10), virtual_router_id (musi być identyczny na obu węzłach, 1–255), auth_pass (wspólne hasło uwierzytelniające VRRP — zapobiega fałszywym masterom w sieci).

Health checks — monitorowanie usługi

Blok vrrp_script definiuje sprawdzenie zdrowia usługi. Gdy skrypt zwróci kod niezerowy przez fall kolejnych sprawdzeń, Keepalived obniża priorytet węzła o wartość weight. Jeśli priorytet mastera spadnie poniżej priorytetu backupa, następuje failover.

Możesz sprawdzać port HTTP zamiast statusu systemd — to bardziej precyzyjne:

# Skrypt health check: /etc/keepalived/check_http.sh
#!/bin/bash
# Sprawdza czy Nginx odpowiada na HTTP
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 http://127.0.0.1/health)

if [ "$HTTP_CODE" = "200" ]; then
    exit 0
else
    exit 1
fi

# Nadaj uprawnienia wykonania
chmod +x /etc/keepalived/check_http.sh

Następnie w konfiguracji zmień script na:

vrrp_script chk_http {
    script "/etc/keepalived/check_http.sh"
    interval 3
    timeout 5
    weight -30
    fall 2
    rise 3
}

Skrypt notify — powiadomienia o failover

Dyrektywy notify_master, notify_backup i notify_fault wywołują skrypt przy każdej zmianie stanu. Możesz wysyłać alerty na email lub Telegram, a także synchronizować dane (np. reload PHP-FPM po przejęciu IP).

#!/bin/bash
# /etc/keepalived/notify.sh
STATE=$1
HOSTNAME=$(hostname)
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

case $STATE in
    MASTER)
        echo "[$TIMESTAMP] $HOSTNAME przeszedl w tryb MASTER" >> /var/log/keepalived-events.log
        # Opcjonalnie: wyslij alert na Telegram / email
        # curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
        #   -d "chat_id=$CHAT_ID&text=KEEPALIVED: $HOSTNAME jest teraz MASTER"
        ;;
    BACKUP)
        echo "[$TIMESTAMP] $HOSTNAME przeszedl w tryb BACKUP" >> /var/log/keepalived-events.log
        ;;
    FAULT)
        echo "[$TIMESTAMP] $HOSTNAME: FAULT — sprawdz usluge" >> /var/log/keepalived-events.log
        ;;
esac

chmod +x /etc/keepalived/notify.sh

Weryfikacja i testowanie failover

Po uruchomieniu Keepalived na obu węzłach sprawdź, który przejął floating IP. Następnie zasymuluj awarię mastera i obserwuj czas przejęcia.

# Sprawdz czy floating IP jest przypisany (na masterze)
ip addr show eth0 | grep 192.168.1.100

# Sprawdz status Keepalived
systemctl status keepalived

# Logi w czasie rzeczywistym
journalctl -fu keepalived

# Symulacja awarii — zatrzymaj Keepalived na masterze
systemctl stop keepalived

# Na backupie — sprawdz czy przejal IP (powinno pojawic sie w ciagu 3-5s)
ip addr show eth0 | grep 192.168.1.100

# Symulacja awarii uslugi (nginx)
systemctl stop nginx
# Keepalived wykryje po fall*interval sekundach i obniy priorytet

Parametry konfiguracji — tabela referencyjna

Najczęstsze pytania