Amazon EC2'de ölçeklenebilir, güvenilir bir haproxy kümesini nasıl kurabilirim?

ELB'nin sağladığından daha fazla işlevselliğe ihtiyacımız var (çoğunlukla L7 muayenesi), ancak EC2 kullanarak kalp atışı ve yüksek kullanılabilirlik gibi şeylerle nasıl başa çıkılacağı belli değil. Kümede 3 veya daha fazla haproxy düğümüne ihtiyaç duymamız ihtimalinin yüksek olması nedeniyle, iki düğüm arasındaki basit kalp atışı işe yaramayacak.

Görünüşe göre, bir kalp atışı katmanı haproxy düğümlerinin önünde, muhtemelen IPVS kullanarak, ancak EC2 küme değiştikçe (ya kasıtlı değişiklikler, genişleme gibi ya da istemeden, bir kaybedilme gibi kasıtlı değişiklikler yoluyla) yapılandırma yolunu kullanmanın yolu olacak gibi görünüyordu. EC2 düğümü) önemsiz görünüyor.

Tercihen, çözelti en az iki Müsaitlik Alanını kapsayacaktır.

Soru cevaplarına cevaben: Hayır, seanslar yapışkan değildir. Ve evet, SSL’ye ihtiyacımız olacak, ancak teoride bu tamamen başka bir kurulum tarafından ele alınabilir - SSL trafiğini SSL olmayan trafikten farklı bir yere yönlendirebiliriz.

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:

1. 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.
2. 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.

Yapışkan oturumlar yapmıyorsanız ya da tomcat / apache stilini kullanıyorsanız (LB'de durumu saklamak yerine, oturum kimliğine düğüm kimliği ekleyin), o zaman ELB'yi bir grup halojenin önünde kullanırdım. ELB yerleşik bir sağlık kontrolüne sahiptir, böylece haksirleri izlemenizi ve havuzdan aşağı olanları almasını sağlayabilirsiniz. Kalp atışı yük devretme yerine kurmak için çok daha az.

Değişikliklere gelince, benim çok iyi bir cevabım yok. Kukla ilk yapılandırma ve değişikliklerin uygulanması için mükemmeldir, ancak düğüm eklemek / kaldırmak için 30 dakikalık yoklama aralığından daha hızlı yanıt alma eğilimindedir.

Kendim kullanmadım ama EC2'de bu tür problemleri çözmek için kukla kullandığını söyleyen birçok insan gördüm.