Keepalived VRRP ile Yedekli Gateway ve VIP Kurulumu

Tek bir gateway sunucusunun çökmesi tüm ağı durdurur. VRRP bunu çözer: iki makine aynı sanal IP üzerinde konuşur, biri düşünce diğeri saniyeler içinde devralır. Keepalived bu protokolün Linux tarafındaki en olgun uygulaması, yıllardır LVS kümesi izleme göreviyle doğdu, bugün saf VRRP failover aracı olarak da yaygın kullanılıyor.

VRRP RFC 3768 (sürüm 2) ve RFC 5798 (sürüm 3) ile tanımlı. Aynı LAN üzerinde bir sanal router kimliği paylaşılır, bu kimliğin sahibi tek bir MASTER olur. Diğer düğümler BACKUP olarak dinler ve MASTER reklam göndermeyi bıraktığında önceliği en yüksek olan kendini yükseltir. IPv4 için varsayılan multicast adresi 224.0.0.18, protokol numarası 112.

Kurulum ve ilk yapılandırma

Dağıtım paketleri genelde yeterli. RHEL ailesinde dnf install keepalived, Debian tarafında apt install keepalived. Ardından servis etkinleştirilir:

sudo dnf install -y keepalived
sudo systemctl enable --now keepalived

Ayrıca keepalived --version ile sürümü kontrol etmekte fayda var. Dağıtım deposundaki sürüm bazen eski kalıyor; kaynak derleme gerekiyorsa bağımlılıklar gcc openssl-devel, adımlar standart ./configure && make && make install dizisi.

Yapılandırma tek dosyada toplanıyor: /etc/keepalived/keepalived.conf. İki düğümlü temel bir MASTER/BACKUP çifti için şöyle bir şey yeterli:

! /etc/keepalived/keepalived.conf - MASTER düğüm
global_defs {
    router_id gw-a
    script_user keepalived_script
    enable_script_security
}

vrrp_instance VI_GATEWAY {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass gizli-sifre
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0
    }
}

BACKUP tarafında neredeyse aynı dosya, sadece state BACKUP ve daha düşük priority:

! /etc/keepalived/keepalived.conf - BACKUP düğüm
global_defs {
    router_id gw-b
    script_user keepalived_script
    enable_script_security
}

vrrp_instance VI_GATEWAY {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass gizli-sifre
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0
    }
}

virtual_router_id iki tarafta birebir aynı olmalı ve aynı LAN üzerinde başka bir VRRP grubuyla çakışmamalı. 1 ile 255 arasında değer alıyor. priority yüksek olan kazanır, 255 üst sınır. advert_int reklam aralığı, saniye cinsinden; varsayılan 1.

Servis her iki düğümde de başlatılınca VIP yüksek öncelikli tarafa düşer. Doğrulamak basit:

ip -br addr show eth0
# gw-a üzerinde: eth0 UP 192.168.1.10/24 192.168.1.100/24
# gw-b üzerinde: eth0 UP 192.168.1.11/24

Failover testi ve preemption davranışı

MASTER üzerinde systemctl stop keepalived çalıştırınca BACKUP üç reklam periyodu bekler (advert_int 1 ise yaklaşık 3 saniye) ve VIP'yi kendi üzerine alır. Yüksek öncelikli düğüm geri geldiğinde varsayılan davranış preemptif: VIP hemen eski sahibine döner. Bu bazen gereksiz ikinci bir kesintiye yol açıyor, çünkü geri dönen makine stabil olmayabilir.

Flapping'i engellemek için iki tarafı da BACKUP olarak başlatıp nopreempt koymak yaygın pratik:

vrrp_instance VI_GATEWAY {
    state BACKUP
    nopreempt
    interface eth0
    virtual_router_id 51
    priority 150
    ...
}

Böylece VIP el değiştirdiğinde eski sahibi geri gelince geri almaya çalışmaz. Hangi davranışın doğru olduğu senaryoya bağlı; bakım penceresi olan ortamlarda preempt makul, kararsız ağlarda nopreempt daha güvenli.

Servis sağlığı ile entegrasyon

Sadece VRRP reklamı izlemek yetersiz. Makine ayakta ama üzerindeki HAProxy ölmüş olabilir, bu durumda VIP yerinde durur ve trafik çöp kutusuna gider. vrrp_script bloğuyla uygulama seviyesinde kontrol yapılır:

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight -30
    fall 2
    rise 2
}

vrrp_instance VI_GATEWAY {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass gizli-sifre
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
    track_script {
        chk_haproxy
    }
}

Script başarısız olduğunda priority değerinden weight kadar düşülür. Yukarıdaki örnekte HAProxy düşerse 150'den 120'ye iner, BACKUP'ın 100'ü hâlâ daha düşük. BACKUP priority değerini 110 civarı tutarsak HAProxy krizi VIP'yi taşırıyor. Weight, düşürme yerine çıkarma yapıyor; doğru rakam iki düğümün priority farkına göre hesaplanmalı.

HTTP seviyesinde kontrol gerekiyorsa özel bir betik yazılabilir:

#!/bin/bash
# /usr/local/bin/check_nginx.sh
if curl -sf http://127.0.0.1/health >/dev/null 2>&1; then
    exit 0
else
    exit 1
fi

Dosya çalıştırılabilir olmalı ve enable_script_security açıksa root dışı kullanıcıya ait, herkes tarafından yazılabilir olmamalı. Script'i elle çalıştırıp exit koduna bakmak testin en kolay yolu.

Unicast, güvenlik duvarı ve garp detayları

Varsayılan multicast çalışıyor ama bazı bulut ortamları multicast trafiğine izin vermiyor. Bu durumda unicast tanımlanır:

vrrp_instance VI_GATEWAY {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    unicast_src_ip 10.0.0.11
    unicast_peer {
        10.0.0.12
    }
    authentication {
        auth_type PASS
        auth_pass gizli-sifre
    }
    virtual_ipaddress {
        10.0.0.100/24 dev eth0
    }
}

Unicast kurulumu yapılandırma yükünü artırıyor, yeni düğüm eklerken her tarafın config'ini güncellemek gerekiyor. Kararlı topolojilerde multicast daha az kırılgan.

Güvenlik duvarı araya girerse VRRP geçmeli. firewalld tarafında:

sudo firewall-cmd --permanent --add-protocol=vrrp
sudo firewall-cmd --reload

ufw kullanan sistemlerde sudo ufw allow proto vrrp yeterli. Protokol 112 numaralı IP protokolü, TCP veya UDP değil; bu yüzden kural yazarken isimlendirme önemli.

Failover anında istemciler eski ARP kaydını tutuyor, paketler ölen makineye yöneliyor. Keepalived bu yüzden durum değişiminde gratuitous ARP gönderiyor. Zamanlaması vrrp_garp_master_delay ve vrrp_garp_master_repeat ile ayarlanabiliyor; varsayılanlar çoğu yerde yeterli ama büyük L2 domainlerinde birkaç tekrar eklemek güvenli.

Active-active ve çift VIP

Tek VIP active-passive kalıyor. İki VIP tanımlayıp her düğümü birinin MASTER ı diğerinin BACKUP ı yaparsanız yük dağılımı elde ediliyor:

! gw-a üzerinde
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    virtual_ipaddress { 192.168.1.100/24 }
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth0
    virtual_router_id 52
    priority 100
    virtual_ipaddress { 192.168.1.101/24 }
}

! gw-b üzerinde
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress { 192.168.1.100/24 }
}
vrrp_instance VI_2 {
    state MASTER
    interface eth0
    virtual_router_id 52
    priority 150
    virtual_ipaddress { 192.168.1.101/24 }
}

DNS round-robin ya da istemci tarafı yük dengeleme ile her iki VIP'ye trafik bölünür, tek düğüm düşse bile iki sanal adres de ayakta kalır. vrrp_sync_group ile iki instance'ın aynı anda tek tarafa geçmesi sağlanabilir, aksi hâlde durumlar ayrışabilir.

Bildirim betikleri ve izleme

Durum geçişlerine bağlanmak için notify direktifleri var:

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

Betik parametre olarak yeni durumu alıyor; log yazma, Slack bildirimi, monitoring hook ekleme buradan dönüyor. Günlük takip için journalctl -u keepalived -f yeterli, VRRP reklamlarını canlı görmek isteyenler tcpdump -i eth0 vrrp ile paketleri izleyebilir.

Sık rastlanan sorunlardan biri split-brain: iki düğüm de kendini MASTER sanıyor. Nedeni genelde kalp atış trafiğinin kesilmesi, fiziksel olarak ayrılmış ağlarda VRRP multicast'in bir tarafa ulaşmaması ya da güvenlik duvarının protokol 112'yi bloklaması. Çözüm önce tcpdump ile trafiğin gerçekten karşı tarafa ulaşıp ulaşmadığını doğrulamak. Üretim ortamında kalp atışını VIP trafiğiyle aynı fiziksel arayüze koymamak, mümkünse yönetim arayüzü üzerinden ayrı bir path sağlamak split-brain riskini düşürüyor.

Auth_pass trafik üzerinde düz metin gidiyor; VRRP kimlik doğrulaması yanlış yapılandırmayı önler, aktif bir saldırgana karşı koruma sağlamaz. AH modu biraz daha dayanıklı ama yine de L2 izolasyonu ve ACL ile desteklenmeli. Güvenlik kritikse VRRP trafiğini ayrı VLAN'a kısıp yalnızca küme üyelerinin konuşmasına izin vermek doğru yaklaşım.

Keepalived basit görünen ama ince ayar ister bir araç. Doğru priority hesabı, sağlık kontrolleri, preempt politikasının bilinçli seçimi ve garp zamanlamasıyla birkaç sunucudan saniyeler içinde fail-veren yedekli gateway çıkarıyor.