EC2 Elastik Yük Dengeleyici DNS ve yönlendirme ile ilgili sorunlar


19

Amazon Elastik Yük Dengeleyici'nin (ELB) arkasında bulunan birkaç HTTP sunucusu olan Amazon EC2'de oldukça basit bir kurulum yapmaya çalışıyoruz.

Alanımız Route53'te yönetiliyor ve ELB'yi işaret edecek şekilde ayarlanmış bir CNAME kaydımız var.

Bazılarının - hepsi olmasa da - bazılarının yük dengeleyiciye zaman zaman bağlanamadığı bazı sorunlar yaşadık; Görünüşe göre bu, ELB'nin alan adının çözümü olabilir.

Amazon desteği, yük dengeleyicinin temelindeki Elastik IP'nin değişmekte olduğunu ve sorunun bazı ISS'lerin DNS sunucularının TTL'yi onurlandırmamasını önerdi. Bu açıklamadan memnun değiliz, çünkü sorunu bir EC2 örneğindeki Amazon'un kendi DNS sunucularını, Avustralya'daki yerel ISS'lerde ve Google'ın DNS sunucusu ( 8.8.8.8) üzerinden çoğalttık .

Amazon ayrıca, bazı konumlardan zamanın aşağıya indiğini fark ettiğimiz dönemde, ELB'den geçen trafiğin önemli ölçüde azaldığını doğruladı - bu nedenle sorun uç noktalarımızda değil.

İlginç bir şekilde, etki alanı bağlanamayan sunuculardaki doğru IP'ye çözümlenmiş gibi görünüyor - ancak TCP bağlantısı kurma girişimi başarısız oluyor.

ELB'ye bağlı tüm örnekler her zaman sağlıklı olmuştur. Hepsi

Bu sorunu nasıl daha derinden teşhis edebileceğimizi bilen var mı? Elastik Yük Dengeleyici ile bu sorunu yaşayan başka biri var mı?

Teşekkürler,


Etki alanımızın her zaman doğru EIP'ye çözüldüğünü söyleyebildiğimiz kadarıyla, DNS veya yönlendirme ile ilgili gibi görünmesine rağmen, başka bir not eklemeliyim - hostyardımcı programı çalıştırmak, bağlanabileceğimiz sistemler ve sistemlerdeki aynı adrese çözüyor yapamayız.
Cera

Yanıtlar:


21

Amazon Elastik Yük Dengeleyicilerini (ELB'ler) nasıl teşhis edeceğimizi araştırırken bu soruyu buldum ve bu sorunu çok fazla rehberlik olmadan yaşayan benim gibi herkes için cevaplamak istiyorum.

ELB Özellikleri

ELB'lerin bazı ilginç özellikleri vardır. Örneğin:

  • ELB'ler 1 veya daha fazla düğümden oluşur
  • Bu düğümler ELB adı için A kayıtları olarak yayınlanır
  • Bu düğümler başarısız veya kapatmaya olacak ve bağlantıları olacaktır olabilir değil incelikle kapatılacak
  • Birinin ELB problemlerine girmesini sağlamak için genellikle Amazon desteği ($$$) ile iyi bir ilişki gerektirir.

NOT: Biraz daha az ilgili ancak ilginç olan bir başka özellik de ELB'lerin ani trafik dalgalanmalarını giderecek şekilde tasarlanmamış olmasıdır. Ölçeklendirilmeleri için genellikle 15 dakika yoğun trafiğe ihtiyaç duyarlar veya istek üzerine bir destek bileti yoluyla önceden ısıtılabilirler

ELB'lerde Sorun Giderme (manuel)

Güncelleme: AWS o zamandan beri tüm ELB'leri DNS için Route 53'ü kullanacak şekilde taşıdı. Ek olarak, tüm ELB'lerde artık all.$elb_nameELB için düğümlerin tam listesini döndürecek bir kayıt var. Örneğin, ELB adınız ise elb-123456789.us-east-1.elb.amazonaws.com, benzer bir şey yaparak düğümlerin tam listesini alırsınız dig all.elb-123456789.us-east-1.elb.amazonaws.com. IPv6 düğümleri için all.ipv6.$elb_namede çalışır. Buna ek olarak, Route 53 hala UDP kullanan 4KB'ye kadar veri döndürebilir, bu nedenle +tcpbayrağı kullanmak gerekli olmayabilir.

Bunu bilerek, kendi başınıza biraz sorun giderme yapabilirsiniz. İlk olarak, ELB adını bir düğüm listesine çözün (A kayıtları olarak):

$ dig @ns-942.amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

tcpSenin ELB tek UDP paketinin uyum içine çok fazla kaydının olmasından olarak bayrak önerilir. Ben Amazon sadece 6 düğümler kadar göstereceği de söylendi, ama şahsen teyit etmemiştir sürece bir performans ANYsorgusu. Bu komutu çalıştırmak size şöyle bir çıktı verir (kısalık için kesilmiş):

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.amazon.com. root.amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

Şimdi, Akayıtların her biri için, örneğin curlELB ile bir bağlantıyı test etmek için kullanın . Elbette, testinizi arka uçlarınıza bağlamadan sadece ELB'ye izole etmek istersiniz. Son bir mülk ve ELB'ler hakkında az bilinen gerçek:

  • Bir ELB aracılığıyla gönderilebilen istek yönteminin (fiil) maksimum boyutu 127 karakterdir . Daha büyük ve ELB bir HTTP 405 - Yönteme izin verilmiyor ile yanıt verecektir .

Bu, yalnızca ELB'nin yanıt verdiğini test etmek için bu davranıştan yararlanabileceğimiz anlamına gelir:

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

HTTP/1.1 405 METHOD_NOT_ALLOWEDGörürseniz, ELB başarıyla yanıt veriyor . Curl'un zaman aşımlarını sizin için kabul edilebilir değerlere ayarlamak da isteyebilirsiniz.

Dirsek kullanarak ELB'lerde sorun giderme

Tabii ki, bunu yapmak oldukça sıkıcı olabilir, bu yüzden elbping denilen otomatikleştirmek için bir araç inşa ettim . Bir yakut mücevher olarak kullanılabilir, bu yüzden rubygems'iniz varsa bunu yaparak yükleyebilirsiniz:

$ gem install elbping

Şimdi çalıştırabilirsiniz:

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

Unutmayın, eğer görürseniz code=405, ELB yanıt veriyor demektir.

Sonraki adımlar

Hangi yöntemi seçerseniz seçin, en azından ELB'nizin düğümlerinin yanıt verip vermediğini bileceksiniz. Bu bilgiyle donanmış olarak, odağınızı yığınızın diğer kısımlarında sorun gidermeye dönüştürebilir veya AWS'ye bir şeyin yanlış olduğuna dair oldukça makul bir durum sunabilirsiniz.

Bu yardımcı olur umarım!


1
Harika cevap için teşekkürler. Başlangıçta bunun birçoğunu deneme yanılma yoluyla anladık, ancak bu kullanışlı bir referans olacaktır.
Cera

7

Düzeltme aslında basittir: Route53'te Abir yerine bir kayıt kullanın CNAME.

AWS Yönetim Konsolu'nda "A kaydı" nı seçin ve ardından "Takma ad" etiketli radyo düğmesini "Evet" e getirin. Ardından açılır menüden ELB'nizi seçin.


1
Bu düzeltmenin arkasındaki mantığı anlamıyorum. Amazon'un ELB belgeleri özellikle bir CNAMEkayıt kullanılması gerektiğini söylüyor . Bir Akaydın yararı ne olurdu / burada ne değişiyor?
Cera

3
DNS'niz Route53 dışında bir yerde barındırılıyorsa, bir CNAME kullanmanız gerekir. Ancak bir kayıt takma adı, Route53'e özgü ve karşılaştığınız sorunu tam olarak çözmeyi amaçlayan bir özelliktir. Route53 dokümanlar daha derinlemesine açıklamak.
jamieb

@jamieb Bu dokümantasyonun bağlantısını sağlayabilir misiniz?
Till

1
Buna A kaydının aksine "Takma Ad Hedefi" denir. docs.aws.amazon.com/Route53/latest/DeveloperGuide/…
Jonny07

0

Bu AWS geliştiricileri forumunda deneyebileceğiniz bazı potansiyel çözümler var. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Örneğin:

potansiyel düzeltme # 1

ELB'ye taşındığımızda da benzer bir sorun yaşadık, bunu ELB'imizin adını tek bir karaktere indirgeyerek çözdük. ELB için 2 karakterlik bir isim bile ağ çözümleri DNS çözümlerinde rastgele sorunlara neden oldu.

ELB'nizin DNS adı -> X. <9chars> .us-east-1.elb.amazonaws.com gibi bir şey olmalıdır.

potansiyel düzeltme # 2

Ben orijinal posterim. Tüm yanıtlar için teşekkürler. TTL'yi çok yüksek ayarlayarak DNS sorunlarıyla karşılaştığımız sıklığı azaltabildik (böylece Ağ Çözümleri dışındaki sunucular tarafından önbelleğe alınacaklardı). Ancak, biz hala sadece Ağ Çözümleri ile kalamadım yeterince sorun alıyordu. Hizmetle ilgili iyi raporlara dayanarak UltraDNS'ye geçmeyi düşündük, ancak Route 53 (kapakların altında UltraDNS kullanan, göründüğü gibi) bizim için daha ucuz olurdu. Route 53'e geçiş yaptığımızdan, artık DNS sorunumuz yok ve ELB isimlerimiz de güzel ve uzun olabilir.

Bu yazıda denenecek başka şeyler vardı ama bunlar en iyi olası satışlar gibi görünüyor.


Önerileriniz için teşekkürler. Maalesef sorun, diğer adı oluşturan kayıtlarımız için değil, yalnızca ELB için ana bilgisayar adının DNS çözümlemesinde yatmaktadır. Kayıtlarımız her zaman ELB'nin ana bilgisayar adına düzgün bir şekilde çözümlenir.
Cera

@ Jaimieb'in düzeltmesi sorunu çözdü mü?
slm

Sizi doğru anlıyorsam, sorun bir CNAME / ANAME kaydı ELB'ye çözümlenen CNAME / ANAME kayıtlarına sahip olmanız ve sizin parçanız iyi bir şekilde çözülüyor, performans sorunları yok, ancak ELB'nin DNS'ine ulaştığınızda performans sorunları kaydediliyor ortaya çıkmak?
slm

@slm - 1 numaralı potansiyel düzeltme yardımcı olmuyor. Yazıdan kaldırılmasını tavsiye ederim.
Ursus
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.