Trafiği uygulama sunucularıma yönlendirmek için birden fazla yük dengeleyici kullanmak mümkün müdür?

Dengelemeyi yüklemek için yeniyim ve trafiği uygulama sunucularıma yönlendirmek için birden fazla yük dengeleyici kullanmanın mümkün olup olmadığını merak ediyorum. Bunun nasıl yapılabileceğini gerçekten anlamıyorum. Bir alan adı, belirli bir sunucunun IP adresiyle (bu durumda bir yük dengeleyicisinin IP'si) birebir eşleşmemeli mi? Her yük dengeleme sunucusu farklı bir IP'ye sahipse, istek her iki yük dengeleyici (veya 10 yük dengeleyici veya 50 veya 100) tarafından nasıl alınabilir?

Round robin DNS kullanmak yüksek kullanılabilirlik için o kadar da iyi değildir - bir sunucu çevrimdışı olursa, istemciler yine de ona bağlanmaya ve bir zaman aşımı beklemeye çalışırlar.

Bunu başarmanın başka yolları da var.
1) Aktif / Pasif yük dengeleyiciler
Temelde bir yük dengeleyici bir IP adresi için tüm trafiği işler.
Bu dengeleyici aşağı inerse, pasif düğüm zıplar ve IP'yi devralır.
Yük dengeleyicilerin sadece trafiği yönlendirdiğini unutmayın, bu nedenle küçük ve orta ölçekli siteler için bu sorun yaratabilir.

2) Aktif / Aktif yük dengeleyicileri
Aynı trafik IP'si (veya daha birçok) yük dengeleyicisinde yapılandırılır.
Gelen trafik tüm yük dengeleyicilere gönderilir, ancak bir algoritma hangi dengeleyicinin yanıt vermesi gerektiğini seçer, diğerleri bu trafiği atar.
Bunu düşünmenin basit bir yolu, iki yük dengeleyiciniz var:
İstenen IP çift bir sayı ile sona erdiğinde, yük dengeleyici A cevaplar, aksi takdirde yük dengeleyici B cevaplar.

Tabii ki altyapınız bunu desteklemeli ve gönderilen ancak atılan trafik nedeniyle ek yük var.
Daha fazla bilgi, örneğin burada: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

Yük dengeleyicilerle Yüksek Kullanılabilirlik, genellikle birkaç ana bilgisayarın (yani yük dengeleyiciler) ortak bir ip adresine birkaç olası yoldan (etkin / pasif, etkin / etkin varyasyonlar) cevap vermesini sağlayan sanal bir ip adresi (VIP) protokolü kullanılarak uygulanır. .

Bu protokollerin çok sayıda vardır, en çok düzenli yük dengeleyiciler ile gördüklerim VRRP ve NLB'dir (ayrıca cihazlarda çok sayıda sıradan kara kutu protokolü). Yönlendiricilere ve güvenlik duvarlarına genişleme , örneğin CARP , HRSP , GLSP ile de karşılaşabilir .

Bu stratejinin, daha basit bir strateji olan (ve başka bir yanıtta halledilen) DNS yük dengelemesine göre bir takım avantajları vardır.

DNS yük dengeleme, örneğin aşağıdakilerle yüklenir:

• dns önbellekleme mekanizmalarının yavaş devir hızı
• sınırlı yük dengeleme algoritmaları (genellikle sadece yuvarlak)
• yük dengeleme kararının müşteriye dış kaynak kullanımı (dns kaydının önbelleğe alınması yoluyla)
• Bir sunucu (yani bir yük dengeleyici) rotasyondan çıkarıldığında servis kuyruklarının yavaş boşalması ( ISP'ler ve istemciler tarafından işlenen dns kayıt TTL'lerine dayanarak )
• Yük dengeleyici arızasında yavaş yük devretme

HA için bir sanal ip protokolü kullanmak, örneğin:

• Yük dengeleyiciler arasında yük dengeleme algoritmasının seçimi
• Sunucu merkezli yük dengeleme kararları (örneğin hizmet sağlığına dayalı önlemler ve yönlendirme gibi büyüleyici)
• Bir yük dengeleyici dönüşten çıkarıldığında servis kuyruklarının daha hızlı boşaltılması.
• Yük dengeleyici arızasında anında yük devretme

Senaryoya en uygun stratejiyi ve protokolü yalnızca siz bilirsiniz.

Gereksinimler: bulut veya donanım yük dengeleyicilerine, BGP protokollerine ve diğer her şeye erişemeyen her türlü ortam için çalışan pratik bir çözüme sahip olun.

Bir uygulamanın gelir talebi numarası bilinmiyor, ancak artan yük beklentisini korkmadan karşılayacak kadar yüksek olmalıdır.

Benzer bir yükleme niteliğine sahip bir uygulama bulalım, örneğin günlük kaydı deposu ve arama uygulaması. Bulduğum tane .

Ne istiyorlar:

1. Kolektörler arasındaki yükü dengeleyin
2. Toplayıcılardan biri ölürse veya sorun yaşıyorsa veri almaya devam etmemize izin veren hata toleransı sunun
3. Günlük hacimlerimizdeki büyümeyle yatay ölçeklendirme

ELB hakkında ne denediler ve öğrendiler:

1. Beklendiği gibi çalışmıyor
2. Artan yük nedeniyle gecikme sorunları
3. Yeterli izleme tesisi yok
4. Çok fazla sınırlama (açık bağlantı noktaları ve protokol sayısı)

Route53 ile neden seçtiler:

1. "Round robin oldukça basit bir yük dengeleme, ama bizim için verimlilik açısından iyi çalışıyor"
2. "Route 53 yük devretme sağlık denetimlerinden yararlanıyoruz."
3. "Bir koleksiyonerle ilgili bir sorun varsa, Route 53 bunu otomatik olarak hizmet dışı bırakır; müşterilerimiz herhangi bir etki görmez."
4. Route 53 ile Ön Isınma Gerekmez

Route 53, büyük kütük hacimlerimiz, öngörülemeyen varyasyonlarımız ve işimizdeki sürekli büyüme göz önüne alındığında, Loggly'nin yüksek performanslı koleksiyonculardan yararlanmasının en iyi yolu olduğu ortaya çıktı. Toplayıcıların temel amaçlarına uyum sağlar: Ağ hattı hızında sıfır kayıpla veri toplamak ve Loggly'de kullandığımız tüm AWS hizmetlerinin esnekliğinden yararlanmamızı sağlar.

Bu özel örnek, bazı senaryolarda (günlük toplayıcı, reklam servisi veya benzeri) yük dengeleyicinin gereksiz olduğunu ve "DNS sağlık kontrolü yuvarlak Robin çözümünün" işini çok iyi yaptığını gösterir.

AWS'nin DNS yük devretme konusunda ne dediğini görelim :

DNS Yük Devretme ile Route 53, web sitenizdeki bir kesintiyi tespit edebilir ve son kullanıcılarınızı belirttiğiniz alternatif veya yedek konumlara yönlendirebilir. Route 53 DNS Yük Devretme, uygulamanızın her bir uç noktasının yukarı veya aşağı olup olmadığını belirlemek için düzenli aralıklarla uygulamalarınıza dünyanın her yerinden uç noktalardan Internet istekleri yaparak sağlık kontrollerine dayanır.

Bu teknik aynı zamanda ELB'yi (sadece bir not için gerekli değildir) daha sağlam hale getirir, yine RR + Sağlık Kontrolü'ne dayanır:

Route 53 DNS Yük Devretme, bu hata senaryolarının tümünü ELB ile perde arkasına entegre ederek işler. Etkinleştirildiğinde, Route 53 her bir ELB düğümü için sağlık denetimlerini otomatik olarak yapılandırır ve yönetir.

Şimdi sahne arkasında nasıl çalıştığını görelim . Açık olan soru, DNS önbelleği ile nasıl başa çıkılacağıdır:

Ancak, TTL istemciniz ve Route 53 arasındaki tüm katmanlar tarafından saygı görmüyorsa, DNS önbelleğe alma burada yine de bir sorun olabilir ("uzun kuyruk" sorununun ele alındığı önceki yazımıza bakın). Sonra bir "önbellek bozma" tekniği uygulayabilirsiniz: benzersiz bir alan adına istek gönderme

("http://<unique-id>.<your-domain>") 

ve joker karakter kaynağı tanımlayın

Record "*.<your-domain>" to match it.

Algolia , müşteriniz ( davanızdaki JS) bununla başa çıkabiliyorsa oldukça iyi çalışan "müşteri yeniden deneme stratejisi" ni tanıttı :

API istemcilerimizde temel bir yeniden deneme stratejisi uyguladık. Her API istemcisi üç farklı makineye erişebilmek için geliştirilmiştir. Her kullanıcıyı üç farklı DNS kaydı temsil eder: USERIDID-1.algolia.io, USERID-2.algolia.io veUSERID-3.algolia.io. İlk uygulamamız, kayıtlardan birini rastgele seçip başarısızlık durumunda farklı bir kayıt ile yeniden denemekti.