Autor: [Robert Zasilny](/autorzy/robert-zasilny) Ekspert bezpieczeństwa i compliance · Zweryfikowano Kwiecień 2026

1.  [Strona główna](/) ›
2.  [Baza wiedzy](/baza-wiedzy/) ›
3.  Keepalived — High Availability

# Keepalived — High Availability z VRRP

Opublikowano: 10 kwietnia 2026 · Kategoria: Bezpieczeństwo

Jeden serwer to jeden punkt awarii (Single Point of Failure — SPOF). Gdy pada, pada cały serwis. Keepalived rozwiązuje ten problem przez VRRP (Virtual Router Redundancy Protocol): dwa lub więcej serwerów współdzieli jeden wirtualny adres IP, a w razie awarii głównego (MASTER) wirtualne IP automatycznie przechodzi na zapasowy (BACKUP) w ciągu kilku sekund. Klienci nic nie zauważają — łączą się cały czas z tym samym adresem IP.

## 1\. Instalacja Keepalived

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

# CentOS / Rocky Linux / AlmaLinux
sudo dnf install keepalived -y

# Uruchom i włącz przy starcie
sudo systemctl enable --now keepalived

# Sprawdz status
sudo systemctl status keepalived

## 2\. Konfiguracja VRRP — Master i Backup

Scenariusz: dwa serwery (192.168.1.10 — MASTER, 192.168.1.11 — BACKUP) z wirtualnym IP 192.168.1.100. Klienci zawsze łączą się z 192.168.1.100 — nie wiedzą który fizyczny serwer aktualnie go trzyma.

\# ===== SERWER 1 (MASTER) — /etc/keepalived/keepalived.conf =====

global\_defs {
    notification\_email {
        admin@example.com
    }
    router\_id LVS\_MASTER
}

vrrp\_instance VI\_1 {
    state MASTER
    interface eth0
    virtual\_router\_id 51
    priority 100
    advert\_int 1
    preempt

    authentication {
        auth\_type PASS
        auth\_pass TAJNEHASLO123
    }

    virtual\_ipaddress {
        192.168.1.100/24 dev eth0
    }

    notify\_master "/etc/keepalived/notify.sh MASTER"
    notify\_backup "/etc/keepalived/notify.sh BACKUP"
    notify\_fault  "/etc/keepalived/notify.sh FAULT"
}

# ===== SERWER 2 (BACKUP) — /etc/keepalived/keepalived.conf =====

vrrp\_instance VI\_1 {
    state BACKUP
    interface eth0
    virtual\_router\_id 51
    priority 90
    advert\_int 1
    nopreempt

    authentication {
        auth\_type PASS
        auth\_pass TAJNEHASLO123
    }

    virtual\_ipaddress {
        192.168.1.100/24 dev eth0
    }
}

## 3\. Health checks — monitorowanie usług

Keepalived może nie tylko monitorować dostępność serwera przez VRRP, ale też sprawdzać czy konkretna usługa (Nginx, HAProxy) działa i inicjować failover gdy usługa pada, nawet jeśli serwer fizycznie żyje:

\# /etc/keepalived/check\_nginx.sh
#!/bin/bash
if ! curl -s -f --max-time 5 http://127.0.0.1/health > /dev/null; then
    logger -t keepalived "Nginx health check FAILED"
    exit 1
fi
exit 0

chmod +x /etc/keepalived/check\_nginx.sh

# W keepalived.conf — vrrp\_script do monitorowania nginx
vrrp\_script chk\_nginx {
    script "/etc/keepalived/check\_nginx.sh"
    interval 2
    weight -50
    fall 2
    rise 2
}

# W vrrp\_instance — dodaj track\_script
vrrp\_instance VI\_1 {
    # ... reszta konfiguracji ...
    track\_script {
        chk\_nginx
    }
}

## 4\. Keepalived z HAProxy — aktywno-pasywny load balancer

\# Architektura:
# Klienci -> Wirtualne IP (192.168.1.100)
#            -> MASTER: HAProxy (192.168.1.10)
#               |-> App Server 1 (192.168.1.20:8080)
#               |-> App Server 2 (192.168.1.21:8080)
#            (BACKUP: HAProxy 192.168.1.11 — gotowy)

# /etc/haproxy/haproxy.cfg — NA OBU SERWERACH
frontend http\_front
    bind \*:80
    bind \*:443 ssl crt /etc/haproxy/certs/
    default\_backend http\_back

backend http\_back
    balance roundrobin
    option httpchk GET /health
    server app1 192.168.1.20:8080 check inter 2s
    server app2 192.168.1.21:8080 check inter 2s

# W keepalived.conf — monitoruj HAProxy
vrrp\_script chk\_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight -50
    fall 3
    rise 2
}

vrrp\_instance VI\_1 {
    state MASTER
    interface eth0
    virtual\_router\_id 51
    priority 100

    authentication {
        auth\_type PASS
        auth\_pass HAPROXY\_SECRET
    }

    virtual\_ipaddress {
        192.168.1.100/24
    }

    track\_script {
        chk\_haproxy
    }
}

## 5\. VRRP Unicast — praca w chmurze bez multicast

\# Standardowy VRRP uzywa multicast 224.0.0.18
# W wiekszosci chmur multicast jest zablokowany — uzywaj unicast

vrrp\_instance VI\_1 {
    state MASTER
    interface ens3
    virtual\_router\_id 51
    priority 100
    advert\_int 1

    # Unicast zamiast multicast
    unicast\_src\_ip 192.168.1.10
    unicast\_peer {
        192.168.1.11
    }

    authentication {
        auth\_type PASS
        auth\_pass SECRET
    }

    virtual\_ipaddress {
        192.168.1.100/24
    }
}

# Dla Hetzner Cloud — skrypt przenoszacy Floating IP przez API
# /etc/keepalived/hetzner-failover.sh
#!/bin/bash
HETZNER\_TOKEN="YOUR\_API\_TOKEN"
FLOATING\_IP\_ID="123456"
SERVER\_ID="654321"

if \[ "$1" == "MASTER" \]; then
    curl -s -X POST \\
        "https://api.hetzner.cloud/v1/floating\_ips/${FLOATING\_IP\_ID}/actions/assign" \\
        -H "Authorization: Bearer ${HETZNER\_TOKEN}" \\
        -H "Content-Type: application/json" \\
        -d "{\\"server\\": ${SERVER\_ID}}"
fi

## 6\. Monitorowanie i testowanie failover

\# Sprawdz czy wirtualne IP jest aktywne na tym serwerze
ip addr show eth0 | grep 192.168.1.100
# Jesli IP pojawia sie w wyniku — ten serwer jest MASTER

# Logi VRRP (zmiany stanu, failovery)
journalctl -u keepalived -f
systemctl status keepalived

# Test failover — zatrzymaj usługe na MASTER
sudo systemctl stop nginx
# Obserwuj na BACKUP: ip addr show (wirtualne IP powinno pojawic sie na BACKUP)
sudo systemctl start nginx  # Przywroc usluge

# Skrypt powiadomien — /etc/keepalived/notify.sh
#!/bin/bash
STATE=$1
INSTANCE=$2
PRIORITY=$3

logger -t keepalived "State change: $STATE on $INSTANCE"

# Powiadomienie Discord
curl -s -X POST "https://discord.com/api/webhooks/YOUR\_HOOK" \\
    -H "Content-Type: application/json" \\
    -d "{\\"content\\": \\"Keepalived: Node przeszedl w stan $STATE\\"}"

## Porównanie rozwiązań High Availability

Rozwiązanie

Typ HA

Złożoność

Kiedy używać

Keepalived + VRRP

Active/Passive IP failover

Niska

2 serwery, prosta HA bez load balancingu

Keepalived + HAProxy

HA + Load Balancing

Średnia

Produkcja: HA load balancer przed aplikacjami

Pacemaker + Corosync

Klaster ogólnego przeznaczenia

Wysoka

Złożone klastry (bazy danych, NFS, SAP)

Kubernetes

Container orchestration HA

Bardzo wysoka

Mikroserwisy, skalowanie, GitOps

Managed Load Balancer

Chmura (AWS ALB, GCP LB)

Niska (konfiguracja)

Chmura publiczna, brak własnej infrastruktury

## Najczęstsze pytania

Co to jest VRRP i jak działa w Keepalived? +

VRRP (Virtual Router Redundancy Protocol) to protokół sieciowy pozwalający kilku serwerom współdzielić wirtualny adres IP. W Keepalived jeden serwer jest MASTER i posiada wirtualne IP, pozostałe to BACKUP i czekają gotowe do przejęcia. Keepalived monitoruje dostępność MASTER co sekundę (VRRP advertisement). Jeśli MASTER przestaje odpowiadać, BACKUP z najwyższym priority przejmuje wirtualne IP. Failover trwa zazwyczaj 2-3 sekundy.

Jaka jest różnica między Keepalived a HAProxy? +

To są różne narzędzia służące komplementarnym celom. Keepalived zapewnia wysoką dostępność (HA) na poziomie IP — gdy MASTER pada, wirtualne IP przechodzi na BACKUP. HAProxy to load balancer — rozdziela ruch między wieloma backendami. W architekturach produkcyjnych używa się obu razem: Keepalived zapewnia HA dla HAProxy (dwa serwery HAProxy z wirtualnym IP), a HAProxy balansuje ruch między aplikacjami. Sam Keepalived bez load balancera nie rozdziela ruchu.

Jak skonfigurować health check w Keepalived? +

Keepalived obsługuje kilka typów health checks: TCP\_CHECK (sprawdza czy port jest otwarty), HTTP\_GET (sprawdza odpowiedź HTTP z opcjonalnym sprawdzeniem kodu statusu), SSL\_GET (HTTPS), SMTP\_CHECK, MISC\_CHECK (własny skrypt). W konfiguracji virtual\_server zdefiniuj real\_server z blokiem TCP\_CHECK lub HTTP\_GET z connect\_timeout i nb\_get\_retry. Jeśli health check nie powiedzie się, Keepalived usuwa serwer z puli i opcjonalnie wyzwala failover VRRP.

Czy Keepalived działa w chmurze (AWS, GCP, Hetzner Cloud)? +

VRRP wymaga dostępu do multicast lub bezpośredniej komunikacji między serwerami w tej samej sieci L2. W większości chmur publicznych multicast jest zablokowany, więc klasyczny VRRP nie działa. Obejścia: (1) Keepalived z unicast VRRP (vrrp\_unicast\_peer) — działa w wielu chmurach; (2) Floating IP API — przy failover skrypt wywołuje API dostawcy (np. Hetzner Floating IP API) aby przenieść IP; (3) AWS Elastic IP z Lambda. Hetzner Cloud obsługuje Floating IP z zewnętrznym skryptem, co jest popularnym rozwiązaniem.

## Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.

Contabo

VPS do klastrów HA z Keepalived — przynajmniej 2 serwery na Master/Backup

VPS Klaster

[Aktywuj rabat →](/out/contabo)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/contabo)

Mikr.us

Dwa budżetowe VPS do testów konfiguracji Keepalived VRRP

Dev/Test

[Aktywuj rabat →](/out/mikrus)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/mikrus)

LH.pl

Hosting zarządzany z wbudowanym HA bez potrzeby konfiguracji Keepalived

Managed HA

[Aktywuj rabat →](/out/lh-pl)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/lh-pl)

## Powiązane strony

-   [Nginx jako load balancer — konfiguracja](/baza-wiedzy/nginx-load-balancer-konfiguracja)
-   [Docker na VPS — instalacja i konfiguracja](/baza-wiedzy/docker-na-vps)
-   [Bezpieczeństwo VPS — checklist](/baza-wiedzy/bezpieczenstwo-vps-checklist)
-   [Proxmox VE — wirtualizacja na VPS](/baza-wiedzy/proxmox-ve-wirtualizacja)
-   [Wszystkie artykuły](/baza-wiedzy/)