Trafik desenleri neden farklı algoritmalar gerektirir
Klasik algoritmaların her biri, hizmet ettiği vServis hakkında bir varsayıma dayanır. Round-robin, kurum servislerinin birbirinin yerine geçtiğini varsayar. Least-connections, oturum sayısının kurum servisi yüküyle örtüştüğünü varsayar. Source-IP, açık süreklilik olmadan kullanıcı-kurum servisi yapışkanlığını varsayar. Önbellek-yakınlık hashleri, istek anahtarının — URL, başlık veya oturum — kararlı olduğunu varsayar. Varsayım geçerli olduğunda algoritma doğru cevaptır.
Daha zorlu durumlar bu varsayımların geçerliliğini yitirdiği yerlerdir: iş günü içinde kurum servisleri performansta kayar, rolling yükseltmede donanım nesilleri karışır, bölgesel gecikme istek-istek değişir veya iş yükünün kendisinde ham istek sayısıyla örtüşmeyen ağır sorgu patlamaları vardır. Bu senaryolarda istek başına teorik olarak en iyiyi değil gerçekten en hızlı kurum servisini seçmek — veya kurum servisi değişikliklerini her şeyi yeniden bölmeden absorbe etmek için tasarlanmış bir hash algoritması kullanmak — kullanıcıya görünen gecikmeyi korur.
Doğru cevap, algoritmayı iş yüküne eşlemek — global değil vServis başına.
Algoritma seçimi, vServis başına
vServis, TR7'de frontend dinleyici, trafik kuralları, sağlık denetimleri ve kurum servisi grubunu tek bir yapılandırma nesnesinde birleştirir — bu bileşenleri ayrı yerlere bölen klasik pool kavramından daha geniştir. Her vServis kendi algoritmasını açılır menüden seçer — yeniden derleme yok, yeniden başlatma yok. Tek bir TR7 örneğinde karıştırıp eşleştirin: statik içerik vServis'inde round-robin, API vServis'inde Fastest+, önbellek katmanı vServis'inde Maglev hash. Servis-türü filtreleme otomatik gerçekleşir; UI yalnızca vServis protokolüne uygun algoritmaları gösterir.
vServis başına algoritma
Algoritma seçimi global ADC yapılandırmasında değil, vServis nesnesinde yaşar. Farklı vServisler aynı TR7 örneğinde farklı algoritmalar çalıştırır.
Protokol-farkındalıklı filtreleme
UI yalnızca vServis protokolüne uygun algoritmaları gösterir — HTTP, TCP veya ağ-katmanı vServisler her biri ilgili alt kümeyi alır, operatör tahmini gerekmiyor.
Oturum sürekliliğiyle birleşir
Algoritma ilk istek için kurum servisini seçer; oturum sürekliliği ardından aynı kullanıcı için sonraki istekleri sabitler. Her iki katman vServis başına bağımsız yapılandırılabilir.
Hot-swap (yeniden başlatma yok)
Canlı bir vServis'in algoritmasını değiştirin, trafik anında yeni mantığa kayar. Servis yeniden başlatması yok, bağlantı drain'i gerekmiyor.
TR7 ADC ile gelen 14 algoritma
Her klasik algoritma, iki modern consistent-hash varyantı, bir shortest-delay algoritması, artı TR7'nin özel Fastest+ motoru. Hepsi vServis başına mevcut — açılır menüden seçilir, yapılandırma kodu gerekmiyor.
Round-robin (ağırlıklı + statik)
vServis boyunca eşit dağıtım, ağırlıklı veya ağırlıksız. Her kurum servisinin aynı kapasiteye sahip olduğu tek tip vServisler için standart varsayılan.
Least-connections (ağırlıklı)
Şu an en az açık bağlantısı olan kurum servisine yönlendirir. Oturum sayısının yükle örtüştüğü uzun ömürlü oturumlarda son derece etkilidir. Ağırlıklı varyant kapasite farklarını hesaba katar.
En kısa yanıt süresi
Şu anda en hızlı yanıt veren arka uca yönlendirir; ölçüm örnekleme değil, sürekli. Kapasitenin eşit olduğu ama düğüm başına gecikmenin kaydığı havuzlar için uygundur — ısınan bir önbellek, GC baskısı altındaki bir düğüm, gürültülü bir komşu.
En düşük bant genişliği
O an en az trafik taşıyan arka uca yönlendirir. Yanıtların sayıca değil boyutça farklılaştığı yerlerde — medya, dosya indirme, rapor çıktısı — doğru ölçüt budur; bağlantı sayısı gerçek yükü anlatmaz.
First-available (ilk uygun)
Daima listelenen ilk kapasiteli kurum servisine yönlendirir; aşırı yüklendiğinde sonrakine düşer. Sıcak-sonra-soğuk kurum servisi sıralaması veya kademeli dağıtımlar için kullanışlıdır.
Random (rastgele)
Sağlıklı kurum servisleri arasından rastgele seçim. Durumsuz, istatistiksel olarak eşit — büyük ve tek tip vServisler için kullanışlıdır. Düşük yük altında en-az-yüklü seçim için power-of-two random desteklenir.
Source-IP hash
Aynı istemci IP'si her zaman aynı kurum servisine yönlendirilir. Uygulama açık oturum sürekliliği yönetmediğinde durumlu akışlar için kullanışlıdır.
URL hash (URI / URL-parametresi)
URL bileşeni üzerinde hash — URL uzunluğu, URI yolu veya belirli bir sorgu parametresi (örn. ?user_id). Önbellek yakınlığı için aynı URL veya kullanıcıyı aynı kurum servisine yönlendirir.
Header hash
Özel bir HTTP başlığı üzerinde hash. Çok-kiracılı yönlendirme (tenant-id başlığı), feature flag veya A/B test senaryoları için kullanışlıdır.
RDP cookie hash
Kurum servisi seçimi için RDP oturum çerezini okur. Oturum yakınlığının gerekli olduğu RDP ağ geçitleri ve uzak masaüstü çiftlikleri için kullanışlıdır.
Consistent hash
Kurum servisleri vServis'e katıldığında veya ayrıldığında bozulmayı en aza indiren modern hash modu — anahtarların yalnızca küçük bir kısmı yeniden bölünür, tüm vServis değil. Kurum servisi değişikliğinin tüm önbelleği geçersiz kılmaması gereken cache katmanları için doğru.
Maglev hash
Google'ın yazılım yük dengeleyiciler için tasarlanmış ölçek odaklı consistent-hashing algoritması. Klasik consistent hash'ten daha düşük varyans, replikalar arasında deterministik. Tahmin edilebilir kurum servisi ataması gereken durumsuz servisler için mükemmel.
SED — Shortest Expected Delay
Aktif bağlantıları ve kurum servisi başına ağırlığı hesaba katarak en düşük beklenen bekleme süresine sahip kurum servisine yönlendirir. Kurum servisi kapasiteleri belirgin farklı olduğunda least-connections'ın gelişmiş hâli — Fastest+'ın tüm karmaşıklığı olmadan.
Fastest
En düşük yakın yanıt süresine sahip kurum servisine yönlendirir. Sadece yanıt süresi önemli olduğunda daha basit gecikme-farkındalıklı bir seçenek.
Fastest+
TR7'nin özel iki aşamalı motoru. Operatör sekiz canlı servis sinyalinden ikisini seçer — yanıt süresi, bağlantı süresi, kuyruk yoğunluğu, hata oranları ve daha fazlası; Fastest+ önce birincil sinyale göre adayları daraltır, ardından ikincil sinyalle bağa kalanları ayrıştırır. Aşağıdaki ayrıntılar bölümüne bakın.
Fastest+ — TR7'nin iki aşamalı, operatör tarafından ayarlanan motoru
Çoğu uyarlanır algoritma tek bir sinyali izler — yanıt süresi veya bağlantı sayısı. Fastest+, operatörün sekiz canlı servis sinyalinden ikisini seçmesine olanak tanır: birincil sinyal adayları en iyi skora sahip kurum servislerine daraltır, ikincil sinyal ise bağa kalanları aralarından ayrıştırır. Bakım modundaki ve sağlık durumu uygun olmayan kurum servisleri otomatik olarak elenir; tek kriter yeterliyse tek sinyalli mod da kullanılabilir. Seçebileceğiniz on sinyal şunlardır:
Yanıt süresi
Kurum servisinden ortalama yanıt gecikmesi, sürekli örneklenir. Ana sinyal — yanıtı uzayan bir kurum servisi anında sıralamada düşer.
Bağlantı süresi
TCP/TLS bağlantısı kurma süresi. Bağlantı süresi uzayan bir kurum servisi doygunluğa yaklaşıyordur — yanıt süresi hâlâ iyi görünse bile.
Kuyruk süresi
İsteklerin kurum servisine ulaşmadan önce kuyrukta geçirdiği süre. Yükselen kuyruk süresi, bir kurum servisinin yetişemediğinin en erken uyarısıdır.
Aktif oturumlar
Kurum servisi başına şu an açık oturumlar. Geçmiş toplamların gürültüsü olmadan kapasite-farkındalıklı yönlendirme.
Aktif kuyruk derinliği
Şu an bekleyen istekler. Kuyruğunda 0 olan bir kurum servisi, 50 bekleyeni olan eşit hızlı bir kurum servisine tercih edilir.
Bağlantı hataları
Yakın geçmişteki başarısız bağlantılar. Son 10 denemesinden 3'ünü reddeden bir kurum servisi, sağlık denetimi yakalayamadan sıralamada düşer.
Sunucu tarafı iptaller
Yakın pencerede kurum servisi tarafından başlatılan oturum iptalleri. Kurum servisi ayakta ama yarı yolda başarısız oluyorsa bunu yakalar.
Kullanılan bağlantılar
Bağlantı havuzu kullanımı — her kurum servisinin keep-alive havuzunun kapasiteye ne kadar yakın olduğu. Havuz tükenmesini kullanıcıya görünür hâle gelmeden tespit eder.
Layer 7'de on dört, paket seviyesinde on bir
Layer 7'de karar isteğin içeriğine bakarak verilir: başlık, yol, çerez, canlı yanıt süresi. Layer 4'te karar paket seviyesinde, trafik uygulama katmanına hiç çıkmadan verilir — en yüksek hız oradadır. Hangi katman olursa olsun algoritma servis başına seçilir ve cihaz çalışırken değişir.
Layer 7 — 14 seçim ölçütü
Layer 4 — 11 paket seviyesi zamanlayıcı
Her algoritmanın parladığı senaryolar
Tek tip vServisler
Aynı kurum servisleri, aynı kapasite — round-robin matematiği basit ve yükü simetrik tutar. Büyük durumsuz vServisler için random eklenebilir.
Uzun ömürlü oturumlar
WebSocket'ler, akış servisleri, video aramalar — oturumlar dakikalarca veya saatlerce açık kalır. Least-connections veya SED aktif yükü istek sayısından çok daha iyi takip eder.
Önbellek katmanı vServisler
Kurum servisi değişiminin tüm önbelleği geçersiz kılmaması gerekir. Consistent hash veya Maglev, kurum servisleri değiştiğinde anahtarların yalnızca küçük bir kısmını yeniden böler.
Heterojen veya kayan yük
Karışık donanım, rolling dağıtımlar, bölgesel gecikme varyansı — Fastest+ kurum servislerini canlı olarak puanlar, yönlendirme teorik olarak en iyiyi değil gerçekten en hızlıyı seçer.
Sık sorulan sorular
Algoritmayı servisi yeniden başlatmadan değiştirebilir miyim?
Fastest+ ile least-connections nasıl ilişkili?
Consistent hash ile Maglev hash arasında nasıl seçim yaparım?
SED, least-connections'ın yapmadığı neyi yapar?
Algoritma seçimi dış izleme veya APM entegrasyonu gerektirir mi?
Varsayılan algoritma nedir?
Algoritmayı iş yüküyle eşleştirin
TR7 ADC'nin algoritmayı vServis başına ayarlamanıza nasıl izin verdiğini ve Fastest+'ın diğerlerinin başa çıkamadığı iş yüklerini nasıl yönettiğini görün.