Kurumsal trafik yalnızca HTTP uygulamalarından oluşmaz. DNS, SIP, RADIUS, NTP, ham TCP servisleri, tünel protokolleri ve yüksek hacimli streaming akışları farklı davranır. Bu servislerde içerik işleme yerine düşük gecikme, düşük CPU tüketimi, hızlı karar ve doğru dönüş yolu daha kritiktir.
L4 ve L7 yük dengeleme ayrı ürünler, ayrı konsollar veya ayrı lisans katmanları gibi yönetildiğinde operasyon karmaşıklaşır. Bir ekip DNS ve UDP servisleri için ayrı ağ bileşeni, web uygulamaları için ayrı ADC, güvenlik için ayrı katman yönetmek zorunda kalır. Sorun anında hangi trafik hangi üründen geçti sorusu bile zaman kaybettirir.
UDP trafiği özel dikkat ister. Bağlantı durumu TCP kadar belirgin olmadığı için persistence, kaynak IP davranışı, NAT etkisi ve kurum servisinin cevap yolu doğru tasarlanmalıdır. SIP gibi protokollerde oturumun aynı servis üzerinde kalması gerekirken, DNS ve NTP gibi servislerde mümkün olan en düşük gecikme öne çıkar.
Doğrudan dönüş ve IP tünel gibi modlar doğru kurulduğunda büyük avantaj sağlar; fakat ağ gereksinimleri net bilinmezse problem üretir. Doğrudan yönlendirme modunda kurum servisleri üzerinde VIP loopback alias, ARP davranışı ve dönüş yolu ayarları doğru yapılmalıdır. Aksi hâlde performans kazanımı yerine ulaşılabilirlik sorunu oluşur.
TR7'nin L4 modları, çekirdek seviyesinde düşük gecikmeli trafik dağıtımını, farklı ağ topolojilerine uygun mod seçimini ve L4+L7 karma çalışmayı tek ADC yönetim modeli altında toplar.
TR7, L4 trafiği çekirdek seviyesinde işlerken mod, algoritma, sağlık kontrolü ve karma servis yönetimini merkezi olarak sunar.
TR7, L4 yük dengeleme için Linux LVS/IPVS altyapısından yararlanır. Bu yaklaşım, kullanıcı alanı işlem maliyetini azaltarak TCP ve UDP trafiğinde hızlı karar verilmesini sağlar.
Her L4 servis havuzu için protokol, algoritma, kurum servisi listesi, ağırlık, bağlantı limiti ve sağlık kontrolü yapılandırılır. TR7'nin L4 orkestrasyon katmanı, bu yapılandırmayı çalıştırılabilir L4 dengeleme davranışına dönüştürür.
NAT, SNAT, doğrudan yönlendirme, IP tünel ve genel protokol iletim modları farklı ihtiyaçlara hizmet eder. Operatör, trafiğin dönüş yolu, kaynak IP korunumu ve kurum servisi yerleşimine göre uygun modu seçer.
Aynı TR7 üzerinde HTTP/TCP tabanlı L7 servisleri ve IPVS tabanlı L4 servisleri yan yana çalışabilir. Böylece tek VIP üzerinde farklı portlar farklı işleme motorlarına yönlendirilebilir.
TR7 L4 Modları, farklı protokoller, ağ topolojileri ve servis davranışları için esnek dengeleme seçenekleri sunar.
TR7 NAT, SNAT, doğrudan yönlendirme, IP tünel ve genel protokol iletim modlarını destekler. NAT modunda dönüş trafiği yük dengeleyici üzerinden geçer. Doğrudan yönlendirme modunda dönüş yolu kurum servisinden istemciye doğrudan akar. IP tünel modu uzak lokasyon veya farklı ağ geçişi gerektiren senaryolarda kullanılabilir.
L4 servis havuzu TCP veya UDP protokolüyle tanımlanabilir. DNS, SIP, RADIUS ve NTP gibi UDP servisleri L7 işlem hattına zorlanmadan dengelenebilir. TCP servisleri ise port bazlı düşük gecikmeli dağıtım için kullanılabilir. Her havuz tek protokol mantığıyla sade ve öngörülebilir şekilde çalışır.
TR7, round robin, weighted round robin, least connection, weighted least connection, source hash ve destination hash algoritmalarını destekler. Ağırlıklı algoritmalar güçlü kurum servislerine daha fazla trafik göndermek için kullanılabilir. Hash tabanlı algoritmalar aynı kaynak veya hedefin aynı servise yönlenmesini kolaylaştırır. Bu algoritmalar L7 algoritmalarından bağımsız olarak L4 havuzlarında çalışır.
Kaynak IP tabanlı persistence için timeout değeri tanımlanabilir. Varsayılan yaklaşım, belirli süre boyunca aynı kaynağın aynı kurum servisine yönlenmesini sağlar. SIP trafiğinde call-id bazlı persistence motoru kullanılabilir. Bu yapı, UDP tabanlı oturum davranışlarının kopmasını önlemeye yardımcı olur.
L4 servis havuzları sağlık kontrolüyle birlikte yönetilebilir. L4 sağlık kontrol mekanizması, uygun olmayan kurum servislerini dağıtım dışına alabilir. HTTP tabanlı kontrol üzerinden yönetim API'si veya özel sağlık endpoint'i izlenebilir. Böylece L4 kararları yalnızca port tanımına değil, gerçek servis uygunluğuna göre verilir.
Her kurum servisi için weight değeri tanımlanabilir ve weighted algoritmalarda trafik oranı buna göre belirlenir. Bağlantı limitiyle tek bir kurum servisinin aşırı yüklenmesi sınırlandırılabilir. Bu özellik, kapasitesi farklı servislerin aynı havuzda daha dengeli kullanılmasını sağlar. Operasyon ekibi servis ekleme ve kapasite artırma süreçlerini daha kontrollü yönetir.
VRRP failover mekanizması, VIP'in HA çifti arasında taşınmasını sağlar. Bir ADC node kaybında VIP diğer node üzerinde devralınabilir. UDP servislerinde kısa süreli oturum kaybı çoğu senaryoda kabul edilebilirken, TCP servislerinde failover davranışı uygulama ve oturum yapısına göre değerlendirilmelidir. Bu model L4 servislerin yüksek erişilebilirlik mimarisine bağlanmasını sağlar.
IPVS istatistikleri üzerinden bağlantı, paket ve bant genişliği oranları izlenebilir. Anlık CPS, giriş/çıkış paket oranı ve giriş/çıkış bant genişliği değerleri takip edilebilir. TR7 bu istatistikleri platformun izleme yapısına uyumlu biçimde üretebilir. Operasyon ekibi L4 havuzlarının gerçekten nasıl trafik taşıdığını görebilir.
Genel protokol modu, TCP ve UDP dışındaki protokoller için genel L3 iletim senaryolarında kullanılabilir. ESP, GRE veya ICMP gibi trafik türlerinde klasik port bazlı L4 modeli yeterli olmayabilir. Bu modda detaylı bağlantı istatistikleri sınırlıdır; temel byte sayaçları üzerinden görünürlük sağlanır. Özel ağ geçişleri için pratik bir iletim seçeneği oluşturur.
L4 namespace ayarıyla L4 servis havuzu ayrı ağ namespace bağlamında çalıştırılabilir. Bu yapı, farklı tenant veya ağ bölgeleri arasında ayrım yapmak isteyen kurumlar için önemlidir. Aynı cihaz üzerinde birden fazla ağ bağlamı daha kontrollü yönetilebilir. İzolasyon, karma deployment tasarımlarında operasyonel güvenliği artırır.
L4 modlarının doğru çalışması için bağlantı takibi, failover davranışı, doğrudan yönlendirme gereksinimleri, istatistik sınırları ve servis yönetimi açıkça planlanmalıdır.
IPVS tabanlı L4 yük dengeleme, düşük gecikme ve yüksek throughput gerektiren servisler için uygundur. Doğrudan yönlendirme modunda dönüş trafiği yük dengeleyiciyi atladığı için özellikle yüksek hacimli yanıt üreten servislerde avantaj sağlar. Gerçek kapasite ağ kartı, CPU, mod seçimi ve kurum servisi topolojisine bağlıdır.
UDP ve yoğun L4 servislerinde Linux conntrack tablo boyutu kritik hâle gelir. Varsayılan değerler büyük ölçekli trafik için yeterli olmayabilir; trafik hacmine göre planlanması gerekir.
VIP, VRRP ile HA çifti arasında taşınabilir. Node kaybı durumunda servis diğer node üzerinde devam eder. UDP servisleri çoğu zaman stateless olduğu için daha kolay toparlanırken, TCP oturumlarında kesinti davranışı uygulama toleransına göre değerlendirilmelidir.
Doğrudan yönlendirme modunda kurum servisinin VIP'i loopback alias olarak tanıması gerekir. ARP davranışı için arp_ignore ve arp_announce ayarlarının doğru yapılması önemlidir. Bu gereksinimler karşılanmazsa dönüş yolu avantajı yerine erişim problemi oluşabilir.
Genel protokol iletim modunda per-connection detaylar sınırlıdır. Bu mod daha çok özel L3 iletim ihtiyacını karşılar ve temel byte sayaçlarıyla izlenir. Derin bağlantı analizi gereken servislerde TCP veya UDP modları daha uygun olabilir.
L4 havuz istatistikleri toplanarak platformun genel izleme biçimine uyumlu hâle getirilebilir. Bağlantı, paket ve bant genişliği değerleri geçmiş kayıt sistemlerine yazılabilir. Bu, L4 servislerin L7 servislerle aynı operasyon panelinde izlenmesini kolaylaştırır.
SIP UDP trafiğinde NAT kullanımı kaynak IP ve dönüş yolu davranışını etkileyebilir. Kurum servisi istemciye doğrudan cevap üretmek istiyorsa mod seçimi dikkatli yapılmalıdır. SIP persistence ve doğrudan yönlendirme seçenekleri bu tür senaryolarda daha uygun tasarım sağlayabilir.
Her L4 havuz için ilişkili L4 orkestrasyon servisi izlenebilir. Servis durumu, çalışma süresi ve son durum değişimi operasyonel audit açısından değerlidir. Bu bilgiler, L4 yapılandırma değişiklikleri ve failover incelemelerinde destek sağlar.
Telekom veya servis sağlayıcı, UDP 53 üzerinde birden fazla DNS recursor kurum servisini dengeleyebilir. Persistence kapatılarak düşük gecikmeli ve dengeli DNS dağıtımı sağlanır.
Kurum, UDP 1812 ve 1813 trafiğini kaynak hash algoritmasıyla aynı istemciyi aynı doğrulama servisine yönlendirebilir. Bu yapı, kimlik doğrulama akışında tutarlı servis seçimi sağlar.
Telekom ortamında UDP 5060 SIP trafiği call-id tabanlı persistence ile dengelenebilir. Aynı çağrı akışının aynı kurum servisine gitmesi, oturum davranışının korunmasına yardımcı olur.
Medya veya CDN senaryosunda TCP 80/443 trafiği doğrudan yönlendirme moduyla çalıştırılabilir. Dönüş trafiği kurum servisinden istemciye doğrudan aktığı için yük dengeleyici üzerindeki geri dönüş yükü azalır.
Altyapı servislerinde UDP 123 NTP trafiği round robin ile dengeli ve düşük gecikmeli biçimde kurum servislerine dağıtılabilir. Persistence gereksinimi olmayan bu trafik tipi için sade havuz tanımı yeterlidir.
Aynı VIP üzerinde 80 ve 443 portları L7 işleme motoruna, 53 portu ise L4 IPVS motoruna yönlendirilebilir. Tek lisans ve tek konsol altında karma trafik tiplerine yönelik ayrı optimizasyon sağlanır.
DNS, SIP, RADIUS, NTP ve streaming gibi servisler için düşük gecikmeli, mod bazlı L4 yük dengeleme. Kendi servislerinizle canlı bir kurulumda gezdirelim.