Loadbalancing Nasıl Yapıyoruz?

Artık bulut bilişimin standart hale geldiği bu günlerde, elden loadbalancer konfigürasyonu yapmanın ve loadbalancer sunucuları işletmenin çağın gerisinde kalmışlığa işaret ettiğini düşünenler olacaktır. Buna kısaca şu şekilde cevap verebiliriz:

• Bulut bilişim defakto standart değildir, sadece böyle olduğu söylemleri ile satılmaktadır.
• Bulut bilişim kullananlar yüksek derecede kullandıkları platformlara bağımlı hale gelirler, başka bir bulut bilişim platformuna geçmeleri imkansızdır ya da çok zordur.
• Bulut bilişim kullanımı bazı konularda altyapı oluşturma bilgisinin kaybolmasına sebep olacaktır.

Bulut bilişim pahalıdır. Bu yüzden biz kendi altyapımızı kendi sunucularımızda kendimiz yönetiyoruz ve bu yüzden altyapı giderlerimiz bulut bilişime kıyasla çok daha az. Bu hiçbir zaman bulut bilişim kullanmayacağız anlamına gelmiyor.

Şimdi tekrar konumuza geri dönelim. Biz loadbalancing nasıl yapıyoruz? Öncelike bir loadbalancing sistemini yüksek kullanılabilirlik (high avaılability) sağlayan bir altyapının parçası olarak düşünmek gerekir. Eğer 7/24 hizmet vermek amacıyla yola çıkılıyorsa, loadbalancing işlemi için en az iki sunucuya ihtiyaç duyulmaktadır.

Bu iki sunucu sadece loadbalancing yapmak üzere şu iki parçadan oluşmaktadır:

• Keepalıved (multicast enabled sunucular gerektirir)
• Nginx ya da HaProxy (reverse proxy)

Yukarda yer alan resimde lb1 master, lb2 backup loadbalancer olarak kullanılmaktadır. Her iki sunucu fiziksel bir İP adresine sahiptir. Keepalıved ile sanal bir ip adresi (vip = virtual ip address) görevini yerine getirdiği sürece master olan lb1 sunucunda oluşturulur. Bu yüzden lb1 hem 201.0.0.10 hem de 201.0.0.9 ip adreslerine sahiptir. Aynı keepalıved konfigürasyonu lb2 bünyesinde de bulunmaktadır. Lb2 backup olduğu sürece sadece 201.0.0.11 ip adresine sahip olacaktır. Lb1 kullanım dışı kaldığında, lb2 bünyesindeki keepalıved 201.0.0.9 ip numarasını lb2 bünyesinde aktif hale getirir. Bu durumda domain.com her daim 21.0.0.9 ip adresine işaret ettiği için kullanıcı istekleri bu sefer lb2.domain.com üzeriinden uygulama sunucularına aktarılır.

Master olan lb1 konfigürasyonu şu şekildedir:

vrrp_instance lb1 {
    state MASTER
    interface enp1s0f0
    virtual_router_id 101
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
       201.0.0.9/32
    }
}

Lb2 aşağıda yer alan konfigürasyona sahiptir:

vrrp_instance lb2 {
    state BACKUP
    interface enp1s0f0
    virtual_router_id 101
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
       201.0.0.9/32
    }
}

Keepalıved sunucular arasında (lb1, lb2) iletişimi sağlayabilmek için VRRP protokolünü kullanıyor. Bu yüzden sunucular bünyesinde multicast iletişime izin verilmiş olması gerekmektedir.

Gelelim reverse proxy konusuna. Nginx ya da HaProxy reverse proxy olarak kullanılabilir. Bunlar gelen kullanıcı isteklerini arkalarında yer alan uygulama sunucularına aktarırlar. Örneğin nginx aşağıda yer alan konfuğurasyon sayesinde domain.com adresine gelen kullanıcı isteklerini round robin yönetimi ile web1 ve web2 uygulama sunucularına aktarır. Burada da yine yüksek kullanılabilirlik ön plana çıkmaktadır. Uygulama sunucularından bir tanesinin devre dışı kalması, verilen hizmetin devam ettirilmesini engellemez.

upstream backend {
    server web1:8080 weight=1 max_fails=2 fail_timeout=5s;
    server web2:8080 weight=1 max_fails=2 fail_timeout=5s;
}

EOF (End Of Fun)
Özcan Acar