Kurumsal NAT arkasından gelen tüm kullanıcılar tek sunucuya gidiyor; neden?

Kısa cevap

NAT, kurumdaki bütün kullanıcıları dışarıya tek bir kaynak IP ile çıkarır. IP'ye dayalı her yöntem bu kullanıcıları tek istemci sayar ve hepsini aynı sunucuya gönderir: Source algoritması, Hash key'i istemci IP adresi olan Hash persistence, Network vService'te L4 Persistence ve Source Hash. Çözüm, kalıcılığı IP yerine kullanıcıya özgü bir değere bağlamaktır: HTTP'de New cookie, Current cookie ya da Session Affinity Manager (SAM); IP dışı Hash key'li Hash; HDR ya da URL Param algoritması; RDP için RDP Cookie.

Sorun: Bir Kurumun Bütün Kullanıcıları Tek Sunucuda

Kurumsal ağlar, mobil operatörler ve bazı proxy'ler binlerce kullanıcıyı tek bir genel IP adresinin arkasına toplar. TR7'ye göre bu kullanıcıların hepsi aynı istemcidir. Kalıcılık istemci IP'sine dayanıyorsa kurumun bütün trafiği tek sunucuya yığılır, diğer sunucular boş kalır ve o sunucu aşırı yüklenir. Durum vService'in Live Stats → Source IP Statistics bölümünde trafiğin birkaç kaynak IP'den geldiği görülerek doğrulanır.

Neden Olan Ayarlar

Ayar	vService tipi
LB Algorithm → Source	HTTP
Persistence → Hash, Hash Key = istemci IP adresi	HTTP, L7 TCP
L4 Persistence	Network
LB Algorithm → Source Hash	Network

Çözüm: Sekiz Yöntem

Yöntemler birbirinin alternatifidir; vService tipine ve istekte kullanıcıyı tanıtan değere göre biri seçilir. Hiçbirinde Kurum Servisi tarafında değişiklik gerekmez (Current cookie'de uygulamanın zaten oturum cookie'si üretmesi gerekir).

Durumunuz	Uygun yöntem
HTTP; uygulamadan bağımsız kalıcılık	Yöntem 1: New cookie
HTTP; uygulama zaten oturum cookie'si üretiyor	Yöntem 2: Current cookie
HTTP; oturumları izlemek ve yeniden dengelemek	Yöntem 3: Session Affinity Manager (SAM)
HTTP ya da L7 TCP; kullanıcıyı tanıtan bir header, cookie ya da değer var	Yöntem 4: IP dışı Hash key'li Hash
HTTP; kullanıcı kimliği bir header'da ya da URL parametresinde	Yöntem 5: HDR / URL Param algoritması
L7 TCP; RDP sunucu çiftliği	Yöntem 6: RDP Cookie
Network vService	Yöntem 7: L4 persistence ve Source Hash'i kaldırmak
Ayarlar komut satırından yapılsın	Yöntem 8: WEB-CLI

Yöntem 1: New cookie Önerilen

• Nasıl çalışır TR7 ilk yanıta kendi persistence cookie'sini (varsayılan adı TR-C) ekler; her kullanıcının tarayıcısı ayrı cookie taşıdığı için aynı IP'den gelen kullanıcılar farklı sunuculara dağılır ve kendi sunucularında kalır.
• Nerede açılır vService → Details → LB Algorithm → Persistence → New cookie
• Gereksinim İstemcinin cookie saklaması; self-persistent olmayan bir algoritma
• vService tipi HTTP

Adım adım yapılandırma

1

Adım 1 vService'in düzenleme formunu aç

Load Balancer → Load Balancer vService List adımları izlenir, vService seçilir ve Edit butonuna tıklanır.

2

Adım 2 LB Algorithm kutusunu aç

Details anahtarı açılır; LB Algorithm kutusu işaretli değilse işaretlenir.

3

Adım 3 Self-persistent olmayan bir algoritma seç

Algorithm listesinde Source gibi self-persistent bir algoritma seçiliyse kalıcı olmayan bir algoritmaya (ör. Round Robin, Least Connection) geçilir. Self-persistent bir algoritma seçiliyken Persistence alanı görünmez.

4

Adım 4 New cookie seç

Persistence alanında New Cookie seçilir. Cookie Name boş bırakılırsa TR-C kullanılır; Cookie Max-Idle (varsayılan 30 dakika) ve Cookie Max-Life (varsayılan 8 saat) gerekirse değiştirilir.

5

Adım 5 Kaydet

Save butonuna tıklanır. Değişikliğin uygulanması ekranın sağ altındaki senkron göstergesinden izlenir. Cluster kurulumunda varsayılan auto-sync ile değişiklik eş cihaza da gönderilir; Manual Sync Mode açıksa Synchronize ile elle gönderilir. Mevcut kullanıcılar bir sonraki isteklerinde cookie alır ve dağılmaya başlar.

Doğrulama

1DağılımTR7 tarafı

vService'in Live Stats ekranında Kurum Servislerinin Current Sessions değerleri karşılaştırılır.

BeklenenOturumlar birden fazla sunucuda

2Cookieİstemci tarafı

Tarayıcının geliştirici araçlarında yanıt header'larına bakılır.

BeklenenSet-Cookie: TR-C=…

Yöntem 2: Current cookie

• Nasıl çalışır Uygulamanın ürettiği oturum cookie'si (ör. JSESSIONID, PHPSESSID) kullanılır; her kullanıcının oturumu kendi sunucusunda kalır.
• Nerede açılır vService → Details → LB Algorithm → Persistence → Current Cookie
• Gereksinim Uygulamanın oturum cookie'si üretmesi; self-persistent olmayan bir algoritma
• vService tipi HTTP

Adım adım yapılandırma

1

Adım 1 Algoritmayı hazırla

Yöntem 1'in 1–3. adımları uygulanır: vService düzenlemeye açılır, LB Algorithm kutusu işaretlenir ve self-persistent olmayan bir algoritma seçilir.

2

Adım 2 Current cookie seç

Persistence alanında Current Cookie seçilir ve zorunlu Cookie Name alanına uygulamanın oturum cookie'sinin adı (ör. JSESSIONID) yazılır.

3

Adım 3 Kaydet

Save butonuna tıklanır.

Doğrulama

1DağılımTR7 tarafı

vService'in Live Stats ekranında Kurum Servislerinin Current Sessions değerleri karşılaştırılır.

BeklenenOturumlar birden fazla sunucuda

Yöntem 3: Session Affinity Manager (SAM)

• Nasıl çalışır Cookie tabanlı, durum tutan kalıcılıktır; oturumlar bir eşleme tablosunda izlenir ve gerektiğinde sunucular arasında yeniden dengelenebilir.
• Nerede açılır vService → Details → LB Algorithm → Persistence → Session Affinity Manager (SAM)
• Gereksinim Self-persistent olmayan bir algoritma; vService'te en az iki Kurum Servisi
• vService tipi HTTP

Adım adım yapılandırma

1

Adım 1 Algoritmayı hazırla

Yöntem 1'in 1–3. adımları uygulanır.

2

Adım 2 SAM seç

Persistence alanında Session Affinity Manager (SAM) seçilir. Cookie Source varsayılan olarak TR7 Generates'tir; zorunlu Cookie Name alanına cookie adı yazılır (yer tutucu TR7SID). Diğer alanlar SAM yapılandırma parametreleri bölümündedir.

3

Adım 3 Kaydet

Save butonuna tıklanır.

Doğrulama

1DağılımTR7 tarafı

vService'in Live Stats ekranında Kurum Servislerinin Current Sessions değerleri karşılaştırılır.

BeklenenOturumlar birden fazla sunucuda

Yöntem 4: IP Dışı Hash Key'li Hash

• Nasıl çalışır Hash persistence, kalıcılık anahtarını Hash Key listesindeki Smart Variable'lardan üretir; istemci IP adresi yerine kullanıcıya özgü bir değer (ör. bir header ya da cookie) kullanılır.
• Nerede açılır vService → Details → LB Algorithm → Persistence → Hash → Hash Key
• Gereksinim İstekte kullanıcıya özgü bir değer bulunması; self-persistent olmayan bir algoritma
• vService tipi HTTP, L7 TCP

Adım adım yapılandırma

1

Adım 1 Algoritmayı hazırla

Yöntem 1'in 1–3. adımları uygulanır.

2

Adım 2 Hash seç

Persistence alanında Hash seçilir.

3

Adım 3 Hash key'i değiştir

Hash Key listesinden istemci IP adresi kaldırılır ve yerine kullanıcıya özgü bir Smart Variable (ör. bir header ya da cookie değeri) eklenir. Hash Key List Size (varsayılan 3.000.000) ve Hash Key Expire Time (varsayılan 7 gün) gerekirse değiştirilir.

4

Adım 4 Kaydet

Save butonuna tıklanır.

Doğrulama

1DağılımTR7 tarafı

vService'in Live Stats ekranında Kurum Servislerinin Current Sessions değerleri karşılaştırılır.

BeklenenOturumlar birden fazla sunucuda

Yöntem 5: HDR / URL Param Algoritması

• Nasıl çalışır Algoritma, kullanıcı kimliğini taşıyan bir HTTP header'ının ya da URL parametresinin değerinin hash'iyle sunucu seçer; aynı kullanıcı aynı sunucuya gider.
• Nerede açılır vService → Details → LB Algorithm → Algorithm → HDR / URL Param
• Gereksinim Kimliğin her istekte header'da ya da parametrede bulunması
• vService tipi HTTP

Adım adım yapılandırma

1

Adım 1 LB Algorithm kutusunu aç

Yöntem 1'in 1–2. adımları uygulanır.

2

Adım 2 Algoritmayı seç

Algorithm listesinden HDR ya da URL Param seçilir. HDR için zorunlu HDR Name alanına header adı (ör. X-User-ID), URL Param için zorunlu URL Parameter to Use alanına parametre adı yazılır. Header ya da parametre içermeyen istekler sunuculara sırayla dağıtılır ve bu isteklerde kalıcılık olmaz.

3

Adım 3 Kaydet

Save butonuna tıklanır.

Doğrulama

1DağılımTR7 tarafı

vService'in Live Stats ekranında Kurum Servislerinin Current Sessions değerleri karşılaştırılır.

BeklenenOturumlar birden fazla sunucuda

Yöntem 6: RDP Cookie

• Nasıl çalışır RDP bağlantısının ilk paketindeki kullanıcı adı cookie'sine göre sunucu seçilir; aynı NAT IP'sinden gelen farklı kullanıcılar farklı sunuculara gider.
• Nerede açılır L7 TCP vService → Details → LB Algorithm → Algorithm → RDP Cookie
• Gereksinim RDP istemcisinin cookie göndermesi
• vService tipi L7 TCP

Adım adım yapılandırma

1

Adım 1 LB Algorithm kutusunu aç

Yöntem 1'in 1–2. adımları L7 TCP vService'te uygulanır.

2

Adım 2 RDP Cookie seç

Algorithm listesinden RDP Cookie seçilir ve zorunlu RDP Cookie Name alanına mstshash yazılır.

3

Adım 3 Kaydet

Save butonuna tıklanır.

Doğrulama

1DağılımTR7 tarafı

vService'in Live Stats ekranında Kurum Servislerinin Current Sessions değerleri karşılaştırılır.

BeklenenOturumlar birden fazla sunucuda

Yöntem 7: L4 Persistence ve Source Hash'i Kaldırmak

• Nasıl çalışır Network vService istek içeriğini görmediği için kullanıcıya özgü kalıcılık kuramaz; IP'ye dayalı kalıcılık kaldırılarak kullanıcılar bağlantı başına dağıtılır.
• Nerede açılır Network vService → Details → LB Algorithm → L4 persistence / algoritma listesi
• Gereksinim Uygulamanın bağlantılar arasında kalıcılık gerektirmemesi
• vService tipi Network

Adım adım yapılandırma

1

Adım 1 vService'in düzenleme formunu aç

Load Balancer → Load Balancer vService List adımları izlenir, Network vService seçilir ve Edit butonuna tıklanır; Details anahtarı açılır.

2

Adım 2 L4 persistence'ı kapat

LB Algorithm kutusundaki L4 Persistence anahtarı Disabled yapılır.

3

Adım 3 Algoritmayı değiştir

Algoritma listesinde Source Hash seçiliyse Round-Robin, Weighted Round-Robin, Least-Connection ya da Weighted Least-Connection seçilir.

4

Adım 4 Kaydet

Save butonuna tıklanır. Network vService'te her kayıt vService'i yeniden başlatır (Network vService · Save); değişiklik düşük trafikli bir zamanda yapılır. Kalıcılık gerekiyorsa servis HTTP ya da L7 TCP vService ile yayınlanıp Yöntem 1–6'dan biri kullanılır.

Doğrulama

1Bağlantı dağılımıTR7 tarafı

vService'in Live Stats ekranında Kurum Servislerinin New Connection/s değerleri karşılaştırılır.

BeklenenBağlantılar birden fazla sunucuda

Yöntem 8: WEB-CLI

• Nasıl çalışır Algoritma ve Persistence komut satırından yazılır; --persistence alanı tr7Cookie (New cookie), serverCookie (Current cookie), dynamicPersistence (Hash) ya da sam (SAM) değerini alır.
• Nerede açılırWEB-CLI → lb service update
• Gereksinim WEB-CLI erişimi; vService'in kimliği (lb service list ile görülür)
• vService tipi HTTP (L7 TCP'de yalnızca dynamicPersistence)

Adım adım yapılandırma

1

Adım 1 Algoritmayı ve Persistence'ı yaz

Self-persistent olmayan bir algoritma ile New cookie birlikte yazılır; <vService> yerine vService'in kimliği yazılır:

lb service update id <vService> --algorithm roundrobinNoWeight --persistence tr7Cookie

Doğrulama

1KayıtWEB-CLI

vService kaydı görüntülenir.

Komutlb service show <vService>

Beklenenpersistence alanının değeri tr7Cookie

Sık Yapılan Hatalar

• Source seçiliyken Persistence aramak. Self-persistent algoritma seçiliyken Persistence alanı görünmez; önce algoritma değiştirilir.
• Hash persistence'ı istemci IP adresi anahtarıyla bırakmak. Hash key istemci IP adresiyse sorun sürer.
• Cookie saklamayan istemcilerde cookie beklemek. API istemcileri ve bazı mobil uygulamalar cookie saklamaz; bunlar için header tabanlı Hash ya da HDR kullanılır.
• Trusted Proxy ile çözmeye çalışmak. Düz NAT, X-Forwarded-For header'ı eklemez; gerçek kullanıcı IP'si istekte bulunmaz.

Dokümantasyonda nasıl yapılır

• HTTP (L7) vService · Oturum sürekliliği (Persistence)
• HTTP (L7) vService · Session Affinity Manager (SAM)
• Network vService · L4 Persistence
• Live Stats · Source IP Statistics

İlgili sorular

• Source algoritması persistence yerine kullanılabilir mi?
• Cookie desteklemeyen istemciler (mobil uygulama, API client) için persistence nasıl sağlanır?
• Trafik sunuculara neden eşit dağılmıyor?