Source algoritması persistence yerine kullanılabilir mi?

Kısa cevap

Evet, ama sınırlı bir kalıcılık sağlar. Source, istemcinin IP adresinin hash'iyle sunucu seçer ve aynı IP'yi hep aynı sunucuya gönderir; bu yüzden self-persistent'tır ve seçilince Persistence alanı gizlenir. Ancak NAT arkasındaki bütün kullanıcılar tek sunucuya gider, IP'si değişen istemci (ör. mobil) sunucu değiştirir ve çalışan sunucu sayısı değiştiğinde istemcilerin çoğu başka sunucuya kayar (Hash Consistency açıksa yalnızca küçük bir kısmı). Oturum kopmasının sorun olduğu uygulamalarda Persistence (New cookie, Current cookie, Hash, Session Affinity Manager (SAM)) tercih edilir. Source yalnızca HTTP vService'te vardır.

Nasıl Çalışır?

• Her istekte istemci IP'si hash'lenir ve sonuç çalışan sunucuların toplam Weight'ine bölünerek bir sunucu seçilir; Weight değerleri dağılıma yansır.
• Eşleme bir tabloda tutulmaz; aynı IP her istekte aynı hesapla aynı sunucuya gider.
• Çalışan sunucu sayısı değişirse (sunucu eklenir, health check'te düşer ya da bakıma alınır) hesap değişir ve istemcilerin çoğu farklı sunucuya gider. Hash Consistency açıksa sunucu çıkınca yalnızca o sunucunun istemcileri, sunucu eklenince istemcilerin küçük bir kısmı yer değiştirir (Hash tabanlı algoritmalardaki Hash Consistency seçeneği ne işe yarar?).

Source ile Persistence Karşılaştırması

	Source algoritması	Persistence (ör. New cookie, istemci IP anahtarlı Hash)
Kalıcılık kaynağı	Her istekte yeniden hesaplanan hash	Cookie ya da TR7'deki eşleme tablosu
İlk dağıtım	Hash belirler	Seçilen algoritma belirler (ör. Least Connection)
Sunucu eklenince	İstemcilerin çoğu yer değiştirir (Hash consistency açıksa küçük bir kısmı)	New cookie, Current cookie ve SAM'de mevcut kullanıcılar sunucularında kalır; yeni sunucu yeni istemcileri alır
NAT arkası	Hepsi tek sunucuya	New cookie, Current cookie ve SAM ile her kullanıcı ayrı sunucuya gidebilir
vService tipi	Yalnızca HTTP	HTTP; L7 TCP'de yalnızca Hash

Ne Zaman Yeterlidir?

• Kalıcılık "olsa iyi olur" düzeyindeyse (ör. sunucu önbelleğinden yararlanmak).
• İstemciler farklı, sabit IP'lerden geliyorsa (ör. iç ağ istemcileri).
• Oturum bilgisi paylaşılan bir depoda tutuluyor ve sunucu değişimi kullanıcıyı etkilemiyorsa.

Alternatifler

• HTTP: Persistence → New Cookie (TR7 kendi cookie'sini ekler), Current Cookie (uygulamanın cookie'si), Hash ya da Session Affinity Manager (SAM).
• L7 TCP: Source algoritması yoktur; Persistence → Hash seçilir ve Hash Key olarak istemci IP adresi eklenir (L7 TCP · Persistence).
• Network: Source Hash algoritması ya da L4 Persistence.

TR7'de

• Seçim: vService → Details → LB Algorithm → Algorithm → Source (Self-persistent); aynı kutuda Hash Consistency anahtarı görünür (varsayılan kapalı).
• İzleme: vService'in Load Balancer Management ekranında algoritmanın istemciyi kendiliğinden bir sunucuya sabitlediği yazar.

Sık Karıştırılan Noktalar

• "Source, cookie persistence kadar güvenilirdir." Çalışan sunucu sayısı değişince kalıcılık bozulabilir; cookie tabanlı Persistence'ta mevcut kullanıcılar sunucularında kalır.
• "Source ile birlikte cookie persistence açarım." Source seçilince Persistence alanı gizlenir.
• "L7 TCP'de Source seçebilirim." Yalnızca HTTP'de vardır.
• "Kurumsal kullanıcılar dengeli dağılır." NAT arkasından gelenler tek IP'de toplandığı için tek sunucuya gider.

Dokümantasyonda nasıl yapılır

• HTTP (L7) vService · Algoritmalar
• HTTP (L7) vService · Oturum sürekliliği (Persistence)
• HTTP (L7) vService · Algoritmaya özgü ek alanlar
• Network vService · L4 Persistence

İlgili sorular

• Kurumsal NAT arkasından gelen tüm kullanıcılar tek sunucuya gidiyor; neden?
• Hangi persistence yöntemleri var?
• Hash tabanlı algoritmalardaki Hash Consistency seçeneği ne işe yarar?