Bir ADC katmanında ikinci cihazın bulunması tek başına yüksek erişilebilirlik anlamına gelmez. Kritik soru, arıza anında VIP'in hangi düğümde aktif olacağı, iki düğümün aynı konfigürasyonu kullanıp kullanmadığı, oturum yapışkanlığı tablolarının ve güvenlik sayaçlarının failover anında korunup korunmadığıdır. Bu parçalar birlikte çalışmazsa failover gerçekleşir, fakat kullanıcı deneyimi ve güvenlik davranışı bozulur.
Klasik VRRP yaklaşımı çoğu senaryoda yeterlidir; ancak her problemi çözmez. Düğüm çalışıyor görünebilir, VRRP peer hâlâ canlı olabilir, fakat ilgili arayüz link kaybetmiş veya gateway erişilemez hale gelmiş olabilir. Bu durumda cihaz VIP'i tutmaya devam ederse trafik canlı görünen ama dış dünyaya ulaşamayan düğüme akar.
Elle yönetilen yapılarda konfigürasyon senkronizasyonu da ayrı bir risk oluşturur. Bir düğümde yapılan değişikliğin diğerine taşınıp taşınmadığı, sertifika ve kural setlerinin eşit olup olmadığı veya logların hangi cihazda kaldığı sürekli kontrol gerektirir. "İki düğüm gerçekten aynı mı?" sorusunun net cevabı yoksa küme, güven veren bir yapı değil, ertelenmiş bir arıza noktası olur.
Donanım uyumsuzluğu ise en tehlikeli sessiz hatalardan biridir. Yenilenen bir düğümde farklı ağ arayüzü adı, farklı CPU çekirdek seti veya farklı bellek kapasitesi varsa cluster davranışı en kötü anda bozulabilir. Bu farklar failover sırasında değil, cluster kurulumunda yakalanmalıdır.
TR7 Yüksek Erişilebilirlik Kümeleme bu riskleri birlikte ele alır: VIP geçişini, TR7 kontrollü link/gateway kararını, senkronizasyonu, manuel bakım akışını ve donanım eşleşme kontrolünü tek modelde yönetir.
TR7, iki düğümlü kümelemeyi VIP düzlemi, aktif izleme, senkronizasyon, donanım doğrulaması ve kontrollü değişiklik yönetimiyle birlikte uygular.
Küme ayarları iki düğüm arasında ortak topolojiyle tanımlanır. Yönetim arayüzü, bu düğüm ve eş düğüm durumunu aynı modelde gösterir; kural, sertifika ve servis değişiklikleri cluster davranışı dikkate alınarak yönetilir.
VIP sahipliği klasik VRRP ile yönetilebilir veya TR7'nin link, gateway ya da link+gateway izleme kararlarıyla desteklenebilir. Bu sayede yalnızca peer canlılığına değil, gerçek ağ erişilebilirliğine göre failover yapılabilir.
CPU çekirdek listesi, ağ arayüzü isimleri ve bellek miktarı iki düğüm arasında karşılaştırılır. Uygunsuz donanım eşleşmeleri cluster'a katılım sırasında yakalanır ve failover anına bırakılmaz.
Otomatik senkronizasyon geçici olarak durdurulabilir. Operatör bir düğümde değişiklik yapar, sonucu test eder ve doğruladıktan sonra tüm değişiklikleri eş düğüme bilinçli biçimde taşır.
HA Kümeleme, VIP sahipliğinden durum replikasyonuna kadar yerel yüksek erişilebilirlik davranışını tek arayüzde yönetir.
TR7, VRRP modeliyle VIP adreslerinin hangi düğümde aktif olacağını yönetir. Her ilgili arayüz için MASTER ve BACKUP davranışı otomatik üretilir. Aktif düğüm devre dışı kaldığında VIP eş düğüme geçer ve kullanıcı trafiği aynı adres üzerinden devam eder. Bu model, kanıtlanmış Linux altyapısını TR7 yönetim modeliyle kullanılabilir hale getirir.
TR7, cluster IP geçişi için yalnızca VRRP moduna bağlı kalmaz; link, gateway veya link+gateway yöntemleri de seçilebilir. Link modunda arayüzün carrier durumu, gateway modunda upstream erişilebilirliği dikkate alınır. Link+gateway modunda iki sinyal birlikte değerlendirilerek daha güçlü failover kararı verilir. Bu, düğüm canlı görünse bile ağ çıkışı bozuksa VIP'in yanlış yerde kalmasını engellemeye yardımcı olur.
Aktif-Pasif yapıda bir düğüm servis VIP'lerini taşırken diğeri standby olarak bekler. Aktif-Aktif yapıda farklı VIP'ler iki düğüm arasında dağıtılabilir ve iki cihaz da canlı trafik alabilir. Bir düğüm devre dışı kaldığında diğer düğüm ilgili VIP'leri sahiplenir. Bu yaklaşım, cihaz kapasitesinin kullanımını ve failover stratejisini mimari tercihe göre şekillendirmeye izin verir.
Otomatik senkronizasyon açıkken insert, update ve delete işlemleri eş düğüme aktarılır. Operatör ayrı otomasyon, elle dosya kopyalama veya zamanlanmış senkronizasyon işi yazmak zorunda kalmaz. Kural, sertifika ve servis yapılandırmalarının iki düğümde tutarlı kalması kolaylaşır. Bu, failover anında "eş cihaz gerçekten aynı mı?" belirsizliğini azaltır.
Oturum yapışkanlığı tabloları, hız sınırlama sayaçları ve kaynak IP temelli durum bilgileri eş düğüme replike edilebilir. Failover olduğunda kullanıcı davranışı tamamen sıfırdan başlamaz. Captcha, hız sınırı veya oturum yönlendirme gibi kararlar arıza sonrası daha tutarlı devam eder. Bu özellik, yalnızca VIP geçişini değil, karar durumunun da korunmasını hedefler.
Cluster'a katılacak düğümlerin CPU çekirdek seti, ağ arayüzleri ve RAM bilgisi karşılaştırılır. Farklı arayüz adı, eksik NIC veya bellek uyumsuzluğu daha baştan hata olarak ele alınır. Bu, sessiz donanım farklarının failover anında ortaya çıkmasını engellemeye yardımcı olur. Özellikle donanım yenileme ve yedek cihaz değişimi süreçlerinde operasyon riskini azaltır.
Manuel sync etkinleştirildiğinde otomatik değişiklik yayını durdurulur. Operatör bir düğümde yeni kuralı, sertifikayı veya servis davranışını test edebilir. Doğrulama tamamlandığında syncAll veya requestSyncAll akışıyla değişiklik eş düğüme taşınır. Bu model, yanlış bir değişikliğin anında tüm cluster'a yayılmasını engeller.
Her cluster ID için 241.0.1.0/24 yönetim ağı içinden IP atanır. Cluster içi haberleşme, kullanıcı servis trafiğiyle kavramsal olarak ayrılır. Cluster ID değeri 1-254 aralığında kullanılır ve her ID ayrı yönetim IP'sine karşılık gelir. Bu ayrım, senkronizasyon ve peer iletişim trafiğinin daha öngörülebilir yönetilmesini sağlar.
HA kümeleme; VRRP slotları, unicast iletişim, yönetim IP çiftleri, konfigürasyon farkı, failback davranışı ve GTM entegrasyonuyla birlikte planlanır.
Aktif-Aktif senaryoda her arayüz için MASTER ve BACKUP davranışını temsil eden 2 VRRP slotu üretilebilir. virtual_router_id ve priority değerleri cluster rolüne göre belirlenir. Bu yapı, aynı subnet içinde VIP sahipliğinin çakışmadan yönetilmesini sağlar.
Modern veri merkezi ağlarında multicast VRRP trafiği bazı switch politikaları tarafından filtrelenebilir. TR7, eş düğüm bilgisini unicast peer yaklaşımıyla yöneterek bu riski azaltır. Böylece VRRP trafiği beklenen eş düğüm IP'si üzerinden kontrollü akar.
Cluster IP yöntemi vrrp, link, gw veya link+gw olarak seçilebilir. Link yöntemi arayüz durumuna, gw yöntemi gateway erişilebilirliğine, link+gw yöntemi ise iki sinyalin birleşimine göre karar verir. Bu seçenekler, farklı ağ tasarımlarında VIP davranışını daha gerçekçi hale getirir.
Cluster senkronizasyonu her arayüz için tanımlı IP çifti üzerinden yürütülür. Bu IP'ler, üretim VIP'lerinden ayrı düşünülür. Böylece senkronizasyon trafiği ve kullanıcı trafiği operasyonel olarak ayrıştırılır.
nopreempt modu, eski master geri geldiğinde VIP'in otomatik olarak tekrar ona dönmesini engeller. Böylece geçici düzelme ve tekrar bozulma durumlarında ping-pong failover yaşanmaz. Failback kararı operatör tarafından kontrollü biçimde verilir.
Yerel cluster, aynı veri merkezi içinde VIP failover sağlar. Tüm veri merkezi devre dışı kalırsa GTM katmanı DNS yönlendirmesini uzak veri merkezine taşıyabilir. Böylece yerel arıza ve veri merkezi arızası iki farklı seviyede ele alınır.
Finansal kuruluşlar, mobil ve internet bankacılığı VIP'lerini iki TR7 ADC düğümü üzerinde yüksek erişilebilir çalıştırabilir. Bir düğüm bakım veya arıza nedeniyle devre dışı kaldığında diğer düğüm VIP'i sahiplenir ve servis erişimi aynı adres üzerinden devam eder.
Ağ ekipleri, düğüm canlı olsa bile gateway erişimi kaybolduğunda VIP'in diğer düğüme geçmesini sağlayabilir. Bu senaryoda failover yalnızca cihaz canlılığına değil, gerçek upstream erişilebilirliğine göre yapılır.
Devlet kurumları veya kritik işletmeler, manuel sync modunu açarak değişikliği önce tek düğümde test edebilir. Doğrulama sonrası değişiklik eş düğüme aktarılır ve kontrolsüz cluster geneline yayılım engellenir.
Operasyon ekipleri eski düğümü çıkarıp yeni donanımı cluster'a eklerken CPU, arayüz ve bellek farklarını kurulumda görebilir. Yanlış özellikte sunucu cluster'a alınmadan önce uyarı üretilir ve failover riski azaltılır.
VRRP VIP geçişi, konfigürasyon senkronizasyonu, donanım doğrulaması ve kontrollü bakım akışı — hepsini canlı bir kurulumda birlikte görelim.