Çoğu GSLB uygulaması veri merkezi seçim kararlarını tek bir sinyal sınıfından alır. Coğrafi mesafe yaygın bir seçimdir; platformun ölçüm noktalarından gidiş-dönüş süresi başka bir seçimdir; statik topoloji aramaları üçüncüsüdür. Her biri faydalı bir boyutu yakalar ve diğerlerini kaçırır.
Coğrafya yükü görmezden gelir — en yakın veri merkezi, şu anda kapasite baskısı altında olan da olabilir. GSLB'nin probe'larından gelen gecikme kullanıcıyı görmezden gelir — kullanıcının gerçek ağ yolu, probe'un aldığı yol değildir. Statik topoloji, ağın yapılandırma yazıldığından beri değişmediğini varsayar.
Üretim kararlarının aynı anda üç görünüme ihtiyacı vardır: DC platformu sağlıklı mı? DC üzerindeki uygulama şu anda performans gösteriyor mu? Kullanıcıdan DC'ye giden ağ şu anda gerçekten iyi mi? Her görünümün diğerlerinin yerini alamayacağı sinyalleri vardır.
TR7 GTM üç sinyal sınıfını — host, servis, istemci — DC seçimine bağımsız girdiler olarak açar; operatörlerin iş yüklerine gerçekten uyan politikayı tanımlamasına olanak tanır.
DC seçimi DNS kaydı başına yapılandırılır. Operatörler hangi sinyal kaynağını kullanacaklarını, o kaynak içindeki hangi belirli metriği, kaç DC seçeceklerini ve seçimler arasında nasıl dağıtacaklarını seçer.
DC platformunda ölçülen beş metrik: CPU, bellek, bant genişliği, durum (yukarı/aşağı bileşik) ve paket kaybı. DC platform baskısı yönlendirme kararları için baskın sinyal olduğunda kullanışlıdır.
Servis başına ölçülen sekiz metrik: CPU, bellek, bant genişliği, istek hızı, bağlantı sayısı, yeni-oturum hızı, durum ve sağlıklı kurum servisleri. Trafiği uygulamanın gerçekte ne yaptığına göre yönlendirir, sadece host'un ayakta olup olmadığına göre değil.
Talep eden istemciye ağ yolundan ölçülen dört metrik: hop'lar, MOS (Mean Opinion Score), paket kaybı ve TTL. DC-tarafı probe'ların göremediği kullanıcı-tarafı deneyimi yakalar.
`pickDcCount` kaç DC döndürüleceğini seçer. `balanceAlgorithm` seçimler arasında dağıtır — tüm, top-N, round-robin, ağırlıklı round-robin, rastgele, ağırlıklı rastgele veya en yakın.
DC modunda her DNS kaydı sinyal kaynağını, kriterini ve dağıtım davranışını bağımsız seçer.
DC host kaynağı cpu, mem, bw, status ve packetLoss sunar. Status, DC'nin WAN ve LAN erişim noktalarından hesaplanan bileşik erişilebilirlik/sağlık durumudur. Host-düzeyi kapasitenin baskın yönlendirme sinyali olduğunda kullanışlıdır.
Servis kaynağı cpu, mem, bw, request, connection, session_new, status ve healthyBackends sunar. healthyBackends sayısı özellikle yük taşıyıcıdır — trafiği uygulamanın şu an en çok çalışan kapasiteye sahip olduğu DC'ye yönlendirir, sadece platformu ayakta olan DC'ye değil.
İstemci kaynağı hops (yol uzunluğu), mos (VoIP/gerçek-zamanlı trafik kalitesi için Mean Opinion Score), packetLoss ve ttl sunar. Bu sinyaller istemci ağına karşı ölçülür ve DC-tarafı sağlık probe'larının görmediği kullanıcı deneyimini yakalar.
Statik mod çoklu-kaynak seçimini atlar ve operatör tanımlı kurallara göre DC'leri atar. Eski DNS kayıtları, uyum-tetikli yönlendirme (belirli istemciler için belirli DC'ler) ve testler için kullanışlıdır.
Seçim kriteri operatör kontrollüdür: en düşük değer kazanır, en yüksek değer kazanır, değer hedefe eşit veya değer marjla farklı. Aynı DSL kriter değerlendirmesini her üç sinyal kaynağı boyunca yönetir.
`pickDcCount` varsayılan 1'dir ama DNS yanıtında birden çok DC döndürmek için daha yüksek ayarlanabilir. Bu, her zaman-bir-seç yönlendirmesi yerine gerçek çoklu-DC yük dengelemeyi etkinleştirir — DNS istemcileri birden çok yanıt alır ve istemci-tarafı çözümleyici veya stub aralarında seçim yapar.
DC'ler seçildikten sonra her DC içindeki kayıtlar `balanceAlgorithm`'a göre dağıtılır: tüm (her kaydı döndür), top-1/2/3 (üst N'yi döndür), round-robin, ağırlıklı round-robin, rastgele, ağırlıklı rastgele veya en yakın (talep edene yakınlık). Doğru algoritma geniş dağıtım mı, top-N yoğunlaşma mı yoksa yapışkanlık mı istediğinize bağlıdır.
Servis kaynağı kullanırken operatörler servis adını belirtir — aynı DC fleet'inde çalışan farklı uygulamalar farklı yönlendirme kurallarına sahip olabilir. Servis A ve servis B için healthyBackends sayısı ayrı DC seçimlerini yönlendirebilir.
Seçim sağlıklı DC döndürmezse, kaydın fail-safe listesi son-çare yanıtlar sağlar — çoklu-kaynak sinyalleri tümü başarısız olduğunda her zaman döndürülen operatör tanımlı IP'ler. NXDOMAIN'in nihai yanıt olmasını önler.
DC seçimi DNS kaydı başına yapılandırılır. Aynı domain'in service.healthyBackends ile yönlendirilen bir A kaydı, host.status ile yönlendirilen bir MX kaydı ve client.packetLoss ile yönlendirilen bir CNAME'i olabilir. Operatörler her kaydı kendi iş yüküne göre ayarlar.
Çoklu-kaynaklı seçim DC tanımları, sağlık denetim senaryoları, ağırlıklı DNS algoritmaları ve fail-safe kayıtlarla birlikte çalışır.
Her sinyal kaynağının kendi ölçüm kadansı vardır. Host ve servis metrikleri GTM'in metrik toplama döngüsünde yenilenir (tipik olarak her 30-60 saniyede). İstemci metrikleri çözümleyici oturumu başına güncellenir. Operatörler kadansı DC topolojisine karşı kaynak başına ayarlar.
Seçim kayıt başına bir kaynak kullanır. Operatörler host sinyallerinin servis sinyallerine kapı açmasını istediğinde ("yalnızca host sağlıklıysa servis metriklerini değerlendir"), servis-kaynaklı kayda host-tabanlı bir senaryo bağlarlar. Katmanlama açıktır.
healthyBackends sayısı, harici probe'lardan yaklaşılmadan her DC'deki uygulamanın yük dengeleme katmanından doğrudan okunur. Sayı, o anda servisin arkasındaki sağlıklı kurum servisi havuzunun gerçek değerini yansıtır.
MOS, talep eden istemci ağına karşı ağ-kalite ölçümlerinden (jitter, paket kaybı, gecikme) hesaplanır. Devam eden istemci oturumları için en doğrudur ve ilk-kez istemciler için birkaç ölçüm penceresi içinde yakınsar.
`pickDcCount` mevcut sağlıklı DC sayısından büyükse, mevcut sağlıklı DC'lerin tümü döndürülür. Platform sayım hedefini karşılamak için asla sahte DC üretmez — operatörler hangi gerçek DC'lerin uygun olduğunu tam olarak görür.
Seçim ve dağıtım algoritmaları birleşir: seçim uygun DC'leri kritere göre seçer; dağıtım her DC içindeki kayıtların nasıl döndürüleceğini belirler. Bir kayıt service.healthyBackends ile 3 DC seçebilir, sonra her DC içindeki kayıtları ağırlıklı rastgele ile döndürebilir.
healthyBackends kriteriyle servis kaynağı, trafiği uygulamanın en çok çalışan kapasiteye sahip olduğu DC'ye yönlendirir. Host'u ayakta ama uygulama kurum servisleri kötü durumda olan bir DC'nin sıcak nokta olmasını önler.
packetLoss kriteriyle istemci kaynağı her kullanıcıyı kendi ağından en temiz ağ yoluna sahip DC'ye yönlendirir. VoIP, video, oyun ve gerçek-zamanlı uygulamalar için coğrafi yakınlıktan daha önemli olan yol kalitesi gerektiğinde kullanışlıdır.
Pick-N (örn. ilk 3 DC döndür) ile ağırlıklı rastgele dağıtımı birleştirerek trafiği birden fazla sağlıklı bölge arasında paylaş. Her DNS istemcisi birden fazla seçenek alır; çözümleyiciler ve stub'lar bunlar arasında doğal olarak dağıtır.
Bir kapı olarak host-tabanlı senaryo ("DC platform-sağlıklı") ve seçici olarak servis-tabanlı kriter ("kapıdan geçen DC'ler arasında en yüksek healthyBackends sayısına sahip DC") kullan. Kritik iş yükleri scripting olmadan iki katmanlı seçim alır.
Kendi topolojiniz üzerinde çoklu-kaynaklı DC seçimini deneyin: host metrikleri, servis metrikleri ve istemci-tarafı ağ ölçümleri aynı yönlendirme kararını yönlendirir.