Tek-sinyalli DC seçimi gerçekten önemli olan soruyu kaçırır.
Ç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.
Yaklaşımımız
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 host kaynağı — platform-düzeyi sağlık
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 kaynağı — uygulama performansı
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.
İstemci kaynağı — talep edene ağ yolu
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.
Dağıtım algoritmasıyla Pick-N seçimi
`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.
Yetenekler
DC modunda her DNS kaydı sinyal kaynağını, kriterini ve dağıtım davranışını bağımsız seçer.
DC host: beş platform-düzeyi metrik
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: sekiz uygulama-düzeyi metrik
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: dört ağ-yolu ölçümü
İ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.
Eski veya basit durumlar için statik DC seçimi
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.
Operatör tanımlı kriter ifadesi
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.
Çoklu-DC yanıtlar için Pick-N sayımı
`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.
Dokuz kayıt dağıtım algoritması
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.
Uygulamaya-özgü DC'ler için servis-adı yönlendirme
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.
Fail-safe kayıtlarla birleştirilmiş
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.
Kayıt başına seçim — farklı kayıtlar, farklı kaynaklar
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.
Operasyonel derinlik
Ç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.
Sinyal toplama kadansı
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.
Kriterler çatıştığında kaynak önceliği
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 gerçek-kaynağı
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 hesaplama
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.
Daha az DC mevcut olduğunda Pick-N
`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.
Algoritmanın seçimle etkileşimi
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.
Ne zaman kullanılır
Sadece DC erişilebilirliği değil, uygulama kapasitesine göre yönlendir
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.
İstemci ağ deneyimine göre yönlendir
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.
Birden fazla sağlıklı DC arasında yük dengele
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.
Yüksek-bahisli iş yükleri için katmanlı seçim
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.
Sıkça sorulan sorular
Bu F5 topoloji kayıtlarından nasıl farklı?
Birden çok kaynaktan sinyalleri birleştirebilir miyim?
Bir DC için metrik mevcut değilse ne olur?
healthyBackends servisler arasında nasıl sayılır?
İstemci-kaynaklı seçim özel istemci altyapısı gerektirir mi?
Gerçekten önemli olan sinyallerle veri merkezini seçin.
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.