Tamam, hiçbir zaman kendimi SmugMug seviyelerinde trafiğe sahip bir AWS yük dengeleme çözümü inşa etmedim, ancak sadece teoriyi ve AWS'in hizmetlerini düşünerek, birkaç fikir aklıma geldi.
Orijinal soru, yük dengeleme tasarımını etkileme eğiliminde olan birkaç şeyi kaçırıyor:
- Yapışkan oturumlar ya da değil? Yapışkan oturumu kullanmamak ve tüm yük dengeleyicilerin (LB'ler) yuvarlak robin (RR) veya rasgele arka uç seçimi kullanmasına izin vermek çok tercih edilir. RR veya rasgele arka uç seçimleri basit, ölçeklenebilirdir ve her koşulda yük dağılımı sağlar.
- SSL mi değil mi? SSL'nin kullanımda olup olmadığı ve talep yüzdesinin bu oranın genellikle yük dengeleme tasarımı üzerinde etkisi vardır. Sertifika işlemeyi basitleştirmek ve SSL CPU'yu web uygulama sunucularından uzak tutmak için SSL'yi mümkün olduğunca erken sonlandırmak genellikle tercih edilir.
Yük dengeleme katmanının kendisini nasıl yüksek oranda erişilebilir tutacağı perspektifinden cevap veriyorum . Uygulama sunucularının korunması HA, L7 yük dengeleyicinize yerleştirilmiş sağlık kontrolleri ile yapılır.
Tamam, çalışması gereken birkaç fikir:
1) "AWS yolu":
- İlk katman, en ön tarafta, LB (TCP / IP) modunda ELB kullanın.
- İkinci katman, seçtiğiniz L7 yük dengeleyicinizle EC2 örneklerini kullanın (nginx, HAProxy, Apache vb.).
Faydaları / fikri: L7 yük dengeleyicileri, hepsi aynı AMI'den klonlanmış ve aynı konfigürasyonu kullanarak oldukça basit EC2 AMI'ler olabilir. Böylece Amazon'un araçları tüm HA ihtiyaçlarını karşılayabilir: ELB, L7 yük dengeleyicilerini izler. Bir L7 LB ölür veya tepkisizleşirse, ELB ve Cloudwatch birlikte yeni bir örneği otomatik olarak oluşturur ve ELB havuzuna getirir.
2) "İzleme yolu ile DNS turu robin:"
- Birkaç IP adresi üzerinden kaba taneli bir yük dağılımı elde etmek için basit DNS yuvarlak robin kullanın. Siteniz için 3 IP adresi yayınladığınızı varsayalım.
- Bu 3 IP'nin her biri, bir EC2 örneğine bağlı bir AWS Elastik IP Adresidir (EIA), seçtiğiniz bir L7 yük dengeleyicisine sahiptir.
- Bir EC2 L7 LB ölürse, uyumlu bir kullanıcı aracısı (tarayıcı) gerekir sadece diğer IP adreslerine birini kullanın yerine.
- Harici bir izleme sunucusu kurun. 3 EIP'nin her birini izleyin. Biri yanıt vermezse, EIP'yi başka bir EC2 örneğine taşımak için AWS'nin komut satırı araçlarını ve bazı komut dosyalarını kullanın.
Yararları / fikri: Uyumlu olmayan kullanıcı temsilcileri yanıt vermezse, otomatik olarak başka bir IP adresine geçmelidir. Bu nedenle, bir arıza durumunda, kullanıcılarınızın sadece 1 / 3'ü etkilenmeli ve UA'ları sessizce başka bir IP'ye geçemediğinden bunların çoğu hiçbir şey fark etmemelidir. Ve harici izleme kutunuz bir EIP'nin yanıt vermediğini fark edecek ve durumu birkaç dakika içinde düzeltecektir.
3) DNS RR - HA sunucu çifti:
Temel olarak, Don'un bir çift sunucu arasında basit bir kalp atışı önerisi olması, ancak birden fazla IP adresi için basitleştirilmesi.
- DNS RR'yi kullanarak, hizmet için birkaç IP adresi yayınlayın. Yukarıdaki örnekten sonra 3 IP yayınladığınızı varsayalım.
- Bu IP'lerin her biri bir çift EC2 sunucusuna gider , yani toplamda 6 EC2 örneği.
- Bu çiftlerin her biri, aktif / pasif bir konfigürasyonda 1 IP adresini canlı tutmak için AWS araçlarıyla birlikte Heartbeat veya başka bir HA çözümü kullanır.
- Her EC2 örneğinde, kurulu L7 yük dengeleyiciniz vardır.
Yararları / fikri: AWS'nin tamamen sanallaştırılmış ortamında, L4 servisleri ve yük devretme modları hakkında düşünülmesi gerçekten kolay değil. Sadece 1 IP adresini canlı tutan bir çift özdeş sunucuya basitleştirilmesiyle, mantıklı olması ve test edilmesi daha kolay hale gelir.
Sonuç: Yine üretimde bunların hiçbirini denemedim. İçimden gelen hislerime göre, L4 modunda ELB ile bir seçenek ve L7 LB olarak EC2 örnekleri AWS platformunun ruhu ile uyumlu görünüyor ve Amazon'un daha sonra yatırım yapıp genişlemesi muhtemel. Bu muhtemelen benim ilk tercihim.