Aruba Controller Cluster ve VRRP: Cluster Varken VRRP Gerçekten Gerekli mi?

01 / KISA CEVAP

Kısa Cevap

Cluster ve VRRP aynı şeyi çözmez. Bu nedenle “cluster varsa VRRP gereksizdir” demek de, “cluster olan her yerde VRRP şarttır” demek de doğru değildir.

Basitçe:

Cluster
  -> AP / client servis sürekliliği
  -> yük dağılımı
  -> controller node kaybına karşı dayanıklılık

VRRP
  -> ortak bir Virtual IP (VIP)
  -> IP seviyesinde aktif/standby sahiplik
  -> belirli servis veya gateway adresinin sürekliliği

Asıl soru şudur:

Bu tasarımda VRRP ile hangi IP adresini yedeklemek istiyoruz?

Bu sorunun cevabı yoksa yalnızca “HA olsun” düşüncesiyle VRRP eklemek mimariyi gereksiz yere karmaşıklaştırabilir.

02 / CLUSTER NE ÇÖZER?

Cluster Ne Çözer?

ArubaOS 8 controller cluster yapısının temel amacı, Managed Device'lar arasında servis sürekliliği ve yük paylaşımı sağlamaktır.

Basitleştirilmiş görünüm:

                 Aruba Cluster

          +-------------------------+
          |                         |
          v                         v
   Controller-A               Controller-B
      AP / Client                AP / Client
          |                         |
          +-----------+-------------+
                      |
                  Wireless

Cluster tasarımı sayesinde AP ve istemci yükü birden fazla controller arasında dağıtılabilir. Bir node kaybedildiğinde sağlıklı cluster üyeleri servis yükünü devralabilir.

Bu nedenle cluster'ın cevap verdiği ana sorular şunlardır:

Bir controller devre dışı kalırsa AP'ler ne olacak?
Client servis sürekliliği nasıl korunacak?
Yük tek controller üzerinde mi kalacak, yoksa paylaşılacak mı?
Cluster üyeleri arasında state ve servis bilgileri nasıl korunacak?

Cluster tasarımının odağı controller servis katmanıdır.

03 / VRRP NE ÇÖZER?

VRRP Ne Çözer?

VRRP'nin yaklaşımı daha farklıdır.

İki cihaz aynı sanal IP adresini paylaşır ve bu adresin sahipliği aktif cihaza verilir.

             Virtual IP
          <VRRP_VIRTUAL_IP>
                 |
        +--------+--------+
        |                 |
        v                 v
 Controller-A        Controller-B
    MASTER              BACKUP

Aktif cihaz kullanılamaz hale geldiğinde VIP diğer cihaz tarafından devralınabilir.

Bu yüzden VRRP'nin temel sorusu:

Belirli bir IP adresine erişim, cihazlardan biri kaybolduğunda devam etmeli mi?

VRRP tek başına AP/client load balancing mekanizması değildir. Aynı şekilde controller cluster'ın yaptığı stateful servis sürekliliğinin yerini de tek başına tutmaz.

04 / NEDEN CLUSTER ILE VRRP BIRBIRININ ALTERNATIFI DEĞILDIR?

Neden Cluster ile VRRP Birbirinin Alternatifi Değildir?

İki teknolojinin çalışma katmanını ayırmak konuyu çok daha anlaşılır hale getirir.

Özellik	Controller Cluster	VRRP
AP/client servis sürekliliği	Ana kullanım alanlarından biri	Tek başına çözmez
Controller yük dağılımı	Sağlayabilir	Sağlamaz
Node kaybına karşı servis devamlılığı	Cluster mekanizmasıyla	VIP sahipliğini değiştirir
Ortak Virtual IP	Her kullanımda gerekli değil	Temel çalışma prensibi
Default gateway yedekliliği	Cluster olmanın doğal sonucu değil	Gateway cihazlarında kullanılabilir
AP'nin ilk cluster discovery noktası	Tasarıma bağlı	L2 cluster'da VIP kullanılabilir

Bu tablo nedeniyle aşağıdaki iki ifade de eksiktir:

"Cluster var, VRRP'ye hiç gerek yok."

"İki controller varsa mutlaka VRRP gerekir."

Doğru cevap topolojiye ve VIP'nin kullanım amacına bağlıdır.

05 / LAYER-2 CLUSTER'DA VRRP'NIN YERI

Layer-2 Cluster'da VRRP'nin Yeri

Cluster üyelerinin controller IP'leri aynı Layer-2 broadcast domain içindeyse VRRP anlamlı bir rol üstlenebilir.

Aruba'nın AOS 8 clustering tasarımında aynı Layer-2 bağlantıya sahip cluster üyeleri arasında bir VRRP instance oluşturulması ve VIP'nin AP Master / ilk discovery adresi olarak kullanılması önerilen tasarımlardan biridir.

Örnek:

                  AP
                  |
                  | Discovery
                  v
        <CLUSTER_DISCOVERY_VIP>
                  |
             VRRP VIP
          +-------+-------+
          |               |
          v               v
   Controller-A      Controller-B
          \               /
           \             /
              Cluster

AP ilk kez cluster'ı bulurken tek bir fiziksel controller IP'sine bağımlı kalmak yerine VIP'yi kullanabilir.

Buradaki önemli ayrım:

VRRP AP'nin cluster'ı ilk bulduğu adresin sürekliliğine yardımcı olur; AP'nin cluster içindeki nihai çalışma ve yük dağılımını tek başına VRRP yönetmez.

AP cluster'a katıldıktan sonra cluster node bilgileri AP'nin sonraki controller davranışında daha önemli hale gelir.

06 / LAYER-3 CLUSTER'DA DURUM DEĞIŞIR

Layer-3 Cluster'da Durum Değişir

Cluster üyeleri farklı Layer-3 ağlarda bulunuyorsa aynı broadcast domain paylaşılmaz.

Bu durumda cluster üyeleri arasında klasik VRRP VIP oluşturmak mümkün değildir.

Örnek:

Controller-A
10.x.x.x
    |
   L3 Network
    |
Controller-B
20.x.x.x

Burada AP discovery için farklı bir yöntem gerekir.

Aruba'nın önerdiği yaklaşımlardan biri DNS discovery kullanarak birden fazla controller adresini AP'lere sunmaktır.

                AP
                |
                v
        DNS: aruba-master
          /             \
         v               v
 Controller-A        Controller-B
        \               /
             Cluster

Bu nedenle:

Layer-3 cluster tasarımında “VRRP nerede?” diye aramak yanlış sorudur; topoloji VRRP kullanımına zaten izin vermeyebilir.

07 / GATEWAY REDUNDANCY AYRI BIR KONUDUR

Gateway Redundancy Ayrı Bir Konudur

En çok karışan noktalardan biri budur.

Controller cluster kurulduğunda kullanıcı VLAN'larının default gateway'i otomatik olarak yedeklenmiş sayılmaz.

Önce gateway'in nerede olduğunu belirlemek gerekir.

Senaryo 1 — Gateway Core / Distribution Switch Üzerinde

Birçok kampüs tasarımında istemci VLAN'larının gateway'i core veya distribution switch üzerinde bulunur.

Wireless Client
      |
      v
 Aruba Controllers
      |
      v
 Core / Distribution
      |
      +-- Client VLAN Gateway

Bu yapıda client default gateway redundancy controller cluster'ın görevi değildir.

Gateway yedekliliği gerekiyorsa core/distribution katmanında kullanılan HA/FHRP tasarımı bunu çözmelidir.

Controller tarafına ayrıca VRRP eklemek, kullanıcı gateway redundancy'sine otomatik bir katkı sağlamaz.

Senaryo 2 — Controller L3 Gateway Rolünde

Eğer ilgili VLAN'ın Layer-3 gateway adresi doğrudan controller üzerinde bulunuyorsa durum farklıdır.

Client VLAN
     |
     v
 <VIRTUAL_GATEWAY_IP>
     |
    VRRP
   /    \
  v      v
Ctrl-A  Ctrl-B

Bu durumda gateway adresinin cihaz kaybına karşı devam etmesi gerekiyorsa VRRP gibi bir first-hop redundancy yaklaşımı anlamlı hale gelebilir.

Yani karar şu soruyla verilmelidir:

Client'ın default gateway'i gerçekten controller üzerinde mi?

Cevap hayırsa yalnızca controller cluster var diye gateway amacıyla VRRP kurmak gerekli değildir.

08 / KAMPÜS AĞINDA EN SIK GÖRÜLEN AYRIM

Kampüs Ağında En Sık Görülen Ayrım

Tipik bir kampüs mimarisinde sorumlulukları ayırmak faydalıdır:

                   Campus Network

        Wireless Service / AP Termination
                   |
                   v
         Aruba Controller Cluster

                   |
                   v

          Routing / Default Gateway
                   |
                   v
          Core / Distribution

Bu tasarımda:

Controller cluster → wireless servis sürekliliğini sağlar.
Core/distribution HA → routing ve client gateway sürekliliğini sağlar.
VRRP → yalnızca gerçekten bir VIP ihtiyacı olan noktada kullanılır.

Bu ayrım mimariyi daha sade tutar.

09 / EDGE / ÖZEL SENARYOLARDA NEYE BAKILMALI?

Edge / Özel Senaryolarda Neye Bakılmalı?

Her ortam klasik kampüs yapısı değildir.

Bazı senaryolarda controller'ların farklı görevleri veya discovery ihtiyaçları olabilir. VRRP kararı verilmeden önce aşağıdaki sorular sorulmalıdır:

AP'ler controller cluster'ı nasıl keşfediyor?
             |
             v
Cluster üyeleri aynı L2 ağında mı?
             |
             v
Bir ortak VIP ihtiyacı var mı?
             |
             v
Client gateway controller üzerinde mi?
             |
             v
CoA / başka servisler belirli bir VIP'ye mi yönleniyor?

Bu soruların hiçbiri VRRP gerektirmiyorsa, sırf iki controller bulunduğu için ek bir VRRP instance oluşturmak tasarımı gereksiz karmaşıklaştırabilir.

10 / CLUSTER + VRRP İÇIN BASIT KARAR TABLOSU

Cluster + VRRP İçin Basit Karar Tablosu

Senaryo	VRRP Değerlendirmesi
L2 bağlı cluster ve AP'ler için tek discovery VIP isteniyor	Evet, anlamlı / önerilen kullanım
L3 bağlı cluster üyeleri	Hayır; VRRP uygulanamaz, DNS gibi discovery yöntemleri değerlendirilir
Client gateway core/distribution üzerinde	Controller tarafında gateway amacıyla gerekli değil
Client gateway controller üzerinde ve gateway VIP yedekliliği gerekiyor	Evet, değerlendirilmeli
Amaç AP/client load balancing yapmak	Hayır; bunu VRRP değil cluster çözer
Amaç yalnızca “HA eklemek” ama VIP'nin görevi tanımlı değil	Önce gereksinim netleştirilmeli

11 / YANLIŞ TASARIM YAKLAŞIMI: “NE OLUR NE OLMAZ VRRP EKLEYELIM”

Yanlış Tasarım Yaklaşımı: “Ne Olur Ne Olmaz VRRP Ekleyelim”

High Availability tasarımlarında fazla mekanizma her zaman daha fazla dayanıklılık anlamına gelmez.

Gereksiz VRRP instance'ları:

Troubleshooting'i zorlaştırabilir.
VIP'nin hangi servis için kullanıldığını belirsizleştirebilir.
AP discovery, gateway ve cluster rollerinin birbirine karıştırılmasına neden olabilir.
Operasyon ekibinin failover davranışını anlamasını zorlaştırabilir.

Daha sağlıklı yaklaşım:

Önce gereksinimi belirle
        |
        v
Hangi servis yedeklenecek?
        |
        v
Cluster bunu zaten çözüyor mu?
        |
        v
Ortak bir IP adresi gerekiyor mu?
        |
      +---+---+
      |       |
     EVET    HAYIR
      |       |
      v       v
VRRP/FHRP   Ek VRRP
 değerlendir  ekleme

12 / MIMARI ÖRNEK 1 — L2 CAMPUS CLUSTER

Mimari Örnek 1 — L2 Campus Cluster

                         AP'ler
                           |
                           v
                <AP_DISCOVERY_VIP>
                           |
                          VRRP
                     /             \
                    v               v
            Controller-A       Controller-B
                    \             /
                       Cluster
                          |
                          v
                 Core / Distribution
                          |
                          v
                  Client Gateways

Burada VRRP'nin görevi AP discovery için ortak VIP sağlamaktır.

Client VLAN gateway redundancy ise core/distribution tarafında çözülür.

13 / MIMARI ÖRNEK 2 — L3 BAĞLI CLUSTER

Mimari Örnek 2 — L3 Bağlı Cluster

                         AP'ler
                           |
                           v
                     DNS Discovery
                      /           \
                     v             v
             Controller-A     Controller-B
               Network-A       Network-B
                     \           /
                       L3 Cluster

Burada controller'lar aynı Layer-2 domain içinde olmadığı için VRRP discovery VIP kullanımı uygun değildir.

Discovery mekanizması topolojiye uygun şekilde DNS gibi yöntemlerle tasarlanır.

14 / EN KRITIK ÇIKARIM

En Kritik Çıkarım

Bu konuyu tek cümleyle özetlemek gerekirse:

Cluster controller servis sürekliliğini ve yük paylaşımını çözer; VRRP ise belirli bir IP adresinin sürekliliğini çözer. Bir tasarımda ikisine de ihtiyaç olabilir, yalnızca cluster'a ihtiyaç olabilir veya VRRP tamamen gereksiz olabilir.

Bu nedenle VRRP kararı şu şekilde verilmelidir:

"Cluster var mı?"

yerine:

"Hangi Virtual IP'yi, hangi servis için ve hangi arıza senaryosuna karşı yedeklemek istiyorum?"

sorusu sorulmalıdır.

15 / SONUÇ

Sonuç

Aruba controller cluster ve VRRP birbirini dışlayan teknolojiler değildir; ancak aynı işi de yapmazlar.

Sağlıklı bir kampüs tasarımında roller açık olmalıdır:

Cluster → AP/client servis sürekliliği ve controller yük paylaşımı
VRRP → gerçekten ihtiyaç duyulan ortak Virtual IP'nin sürekliliği
Core/Distribution HA → istemci routing ve default gateway sürekliliği, eğer gateway bu katmandaysa

Özellikle AOS 8 tasarımında cluster üyeleri aynı Layer-2 ağındaysa AP discovery için VRRP VIP kullanılabilir. Cluster üyeleri Layer-3 olarak ayrılmışsa ise VRRP yerine topolojiye uygun discovery yöntemi kullanılmalıdır.

Sonuç olarak en doğru yaklaşım:

VRRP'yi “cluster'ın yanında olması gereken ikinci HA özelliği” olarak değil, belirli bir VIP ihtiyacını çözen bağımsız bir mimari araç olarak değerlendirmektir.

GERİ BİLDİRİM

Bu içerik faydalı oldu mu?

Tek tıkla görüşünü bırak. Geri bildirimler yeni içerikleri ve mevcut rehberleri geliştirmek için kullanılır.

Yorum / düzeltme gönder →

MAKALEAruba Wireless

← Makale arşivi