Ana içeriğe geç
Çözüm

Her iş yükü için doğru algoritmayı seçin

Klasik round-robin'den Maglev hashing'e ve TR7'nin özel iki aşamalı Fastest+ motoruna — 14 algoritma hazır

Farklı iş yükleri farklı yönlendirme mantığı gerektirir. Aynı web sunucularından oluşan tek tip bir vServis mi? Round-robin. Kapasitenin belirleyici olduğu uzun ömürlü oturumlar mı? Least-connections. Önbellek yakınlığı senaryoları mı? Consistent hash veya Maglev. Heterojen donanım veya kayan yük mü? Fastest+. TR7 ADC, her standart algoritmayı — artı üç modern hash varyantını ve bir özel motoru — vServis başına seçili olarak sunar, yeniden başlatma olmadan değiştirilir.

14
Layer 7 seçim ölçütü
11
Layer 4 zamanlayıcısı
vServis başına
Algoritma seçimi — yeniden başlatma olmadan canlı değişir

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:

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

07

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.

08

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.

İKİ KATMAN, TEK POLİTİKA

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ü

Round robin — sırayla; ağırlıklı ya da tam eşit
Ağırlıklı round robin — kapasite farkı gözetilir
En az bağlantı — açık bağlantısı en az olan kazanır
En kısa yanıt süresi — şu anda en hızlı yanıt veren
En düşük bant genişliği — o an en az trafik taşıyan
İlk uygun — bir arka uç dolmadan diğerine geçilmez
Rastgele — istatistiksel olarak düz, durum tutmaz
Fastest — tek canlı sinyal, en düşüğü kazanır
Fastest+ — iki canlı sinyal; birincisi daraltır, ikincisi eşitliği bozar
Kaynak IP — aynı istemci, aynı arka uç
URI — aynı yol, aynı arka uç; önbellek sıcak kalır
URL parametresi — sorgu dizesindeki bir değere göre yönlendirme
Başlık — kendi başlığınız dahil herhangi bir başlığa göre
RDP çerezi — masaüstü oturumları kendi aracısına düşer

Layer 4 — 11 paket seviyesi zamanlayıcı

rr — round robin
wrr — ağırlıklı round robin
lc — en az bağlantı
wlc — ağırlıklı en az bağlantı
lblc — yerellik tabanlı en az bağlantı
lblcr — çoğaltmalı yerellik tabanlı en az bağlantı
sh — kaynak hash
dh — hedef hash
sed — en kısa beklenen gecikme
nq — asla kuyruğa alma
mh — Maglev hash; havuz değişince en az yeniden eşleme

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?
Evet. Algoritma vServis başına bir açılır menüdür. Canlı bir vServis'te değiştirin, trafik anında yeni mantığa kayar — servis yeniden başlatması yok, bağlantı drain'i gerekmiyor.
Fastest+ ile least-connections nasıl ilişkili?
Least-connections birçok vServis için son derece etkilidir — özellikle oturum sayısının kurum servisi yükünü yakından takip ettiği uzun ömürlü oturumlarda. Fastest+, resmi sekiz canlı sinyalle genişletir — kuyruk derinliği, yakın yanıt süresi, bağlantı süresi, hata oranları ve daha fazlası — ve bunlardan ikisini iki aşamalı bir seçimle kullanır. Kullanım senaryoları farklıdır: least-connections tahmin edilebilir oturum şekillerine sahip tek tip vServisler için çoğu zaman doğru tercihtir; Fastest+ ise yalnızca oturum sayısının bir kurum servisinin gerçekten ne kadar meşgul olduğunu yansıtmadığı durumlarda parlar — değişken sorgu süreleri, karışık donanım nesilleri veya rolling dağıtımlar.
Consistent hash ile Maglev hash arasında nasıl seçim yaparım?
Her ikisi de kurum servisleri değiştiğinde yeniden bölmeyi en aza indirir. Consistent hash klasik algoritmadır — basit, tahmin edilebilir, iyi anlaşılmış. Maglev, ölçek odaklı yazılım yük dengeleyiciler için tasarlanmış Google'ın varyantıdır — yük dağılımında daha düşük varyans, replikalar arasında deterministik. Çoğu iş yükü için consistent hash yeterli; sıkı yük tekdüzeliği gerektiğinde veya yönlendirme üzerinde anlaşması gereken birden fazla TR7 örneği çalıştırıldığında Maglev'i seçin.
SED, least-connections'ın yapmadığı neyi yapar?
SED (Shortest Expected Delay) hem aktif bağlantıları hem de kurum servisi başına ağırlığı hesaba katarak sıradaki isteğe en hızlı yanıt verecek kurum servisini tahmin eder. Ağırlıklı least-connections'ın gelişmiş hâlidir — kurum servisi kapasiteleri belirgin farklı olduğunda ve yönlendirmenin bunu hesaba katmasını istediğinizde, Fastest+'ın tüm karmaşıklığı olmadan kullanışlıdır.
Algoritma seçimi dış izleme veya APM entegrasyonu gerektirir mi?
Hayır. Tüm sinyaller — her Fastest+ girdisi dahil — TR7 tarafından zaten proxy'lediği trafikten ölçülür. Ajan yok, APM kancası yok, dış metrik boru hattı yok.
Varsayılan algoritma nedir?
Round-robin, mevcut dağıtımlarla geriye uyumluluk için varsayılandır. Farklı bir algoritmaya geçmek, vServis yapılandırmasında tek-açılır-menü değişikliğidir.

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.