Kami mencoba menjalankan pengaturan yang cukup mudah di Amazon EC2 - beberapa server HTTP yang berada di belakang Amazon Elastic Load Balancer (ELB).

Domain kami dikelola di Route53, dan kami memiliki catatan CNAME yang diatur untuk mengarah ke ELB.

Kami telah mengalami beberapa masalah di mana beberapa - tetapi tidak semua - lokasi secara intermiten tidak dapat terhubung ke load balancer; tampaknya ini mungkin merupakan resolusi dari nama domain ELB.

Dukungan Amazon memberi tahu kami bahwa IP Elastis yang mendasari load balancer telah berubah, dan masalahnya adalah bahwa beberapa server DNS ISP tidak menghormati TTL. Kami tidak puas dengan penjelasan ini, karena kami mereplikasi masalah menggunakan server DNS Amazon sendiri dari instance EC2, serta pada ISP lokal di Australia dan melalui server DNS Google ( 8.8.8.8).

Amazon juga mengkonfirmasi bahwa selama periode di mana kami memperhatikan waktu henti dari beberapa lokasi, lalu lintas yang melewati ELB turun secara signifikan - sehingga masalahnya bukan pada titik akhir kami.

Menariknya, domain tersebut tampaknya menyelesaikan ke IP yang benar pada server yang tidak dapat terhubung - tetapi upaya untuk membuat koneksi TCP gagal.

Semua instance yang melekat pada ELB telah sehat setiap saat. Mereka semua

Adakah yang tahu bagaimana kita bisa mendiagnosis masalah ini lebih dalam? Adakah orang lain yang mengalami masalah ini dengan Elastic Load Balancer?

Terima kasih,

Saya menemukan pertanyaan ini ketika mencari di Google untuk cara mendiagnosis Amazon Elastic Load Balancers (ELBs) dan saya ingin menjawabnya untuk orang lain seperti saya yang mengalami masalah ini tanpa banyak panduan.

Properti ELB

ELB memiliki beberapa sifat menarik. Contohnya:

• ELB terdiri dari 1 atau lebih node
• Node-node ini diterbitkan sebagai catatan A untuk nama ELB
• Node ini dapat gagal, atau dimatikan, dan koneksi tidak akan ditutup dengan anggun
• Seringkali membutuhkan hubungan yang baik dengan dukungan Amazon ($$$) untuk membuat seseorang menggali masalah ELB

CATATAN: Properti lain yang menarik tetapi sedikit kurang relevan adalah bahwa ELB tidak dirancang untuk menangani lonjakan lalu lintas yang tiba-tiba. Mereka biasanya membutuhkan 15 menit lalu lintas yang padat sebelum dapat ditingkatkan atau mereka dapat dipanaskan berdasarkan permintaan melalui tiket dukungan

Pemecahan masalah ELB (secara manual)

Pembaruan: AWS sejak itu telah memigrasikan semua ELB untuk menggunakan Rute 53 untuk DNS. Selain itu, semua ELB sekarang memiliki all.$elb_namecatatan yang akan mengembalikan daftar lengkap node untuk ELB. Misalnya, jika nama ELB Anda elb-123456789.us-east-1.elb.amazonaws.com, maka Anda akan mendapatkan daftar lengkap node dengan melakukan sesuatu seperti dig all.elb-123456789.us-east-1.elb.amazonaws.com. Untuk node IPv6, all.ipv6.$elb_namejuga berfungsi. Selain itu, Rute 53 dapat mengembalikan hingga 4KB data yang masih menggunakan UDP, jadi menggunakan +tcpbendera mungkin tidak diperlukan.

Mengetahui hal ini, Anda dapat melakukan sedikit pemecahan masalah sendiri. Pertama, atasi nama ELB ke daftar node (sebagai catatan A):

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

The tcpflag disarankan sebagai ELB Anda bisa memiliki terlalu banyak catatan untuk fit dalam paket UDP tunggal. Saya juga diberitahu, tetapi belum dikonfirmasi secara pribadi, bahwa Amazon hanya akan menampilkan hingga 6 node kecuali Anda melakukan ANYkueri. Menjalankan perintah ini akan memberi Anda output yang terlihat seperti ini (dipangkas untuk singkatnya):

;; 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

Sekarang, untuk masing-masing Arekaman gunakan mis curluntuk menguji koneksi ke ELB. Tentu saja, Anda juga ingin mengisolasi tes Anda hanya ke ELB tanpa terhubung ke backend Anda. Satu properti terakhir dan sedikit fakta yang diketahui tentang ELB:

• Ukuran maksimum dari metode permintaan (kata kerja) yang dapat dikirim melalui ELB adalah 127 karakter . Yang lebih besar dan ELB akan membalas dengan HTTP 405 - Metode tidak diizinkan .

Ini berarti bahwa kita dapat memanfaatkan perilaku ini untuk menguji hanya bahwa ELB merespons:

$ 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

Jika Anda melihat HTTP/1.1 405 METHOD_NOT_ALLOWEDmaka ELB merespons dengan sukses. Anda mungkin juga ingin menyesuaikan batas waktu curl dengan nilai yang dapat Anda terima.

Memecahkan masalah ELB menggunakan elbping

Tentu saja, melakukan ini bisa sangat membosankan, jadi saya telah membangun alat untuk mengotomatisasi elbping ini . Ini tersedia sebagai permata ruby, jadi jika Anda memiliki rubygems maka Anda dapat menginstalnya hanya dengan melakukan:

$ gem install elbping

Sekarang Anda dapat menjalankan:

$ 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

Ingat, jika Anda melihat code=405maka itu berarti ELB merespons.

Langkah selanjutnya

Metode apa pun yang Anda pilih, Anda setidaknya akan tahu apakah node ELB Anda merespons atau tidak. Berbekal pengetahuan ini, Anda dapat mengubah fokus Anda menjadi pemecahan masalah bagian-bagian lain dari tumpukan Anda atau dapat membuat kasus yang cukup masuk akal bagi AWS bahwa ada sesuatu yang salah.

Semoga ini membantu!

Cara mengatasinya sebenarnya sederhana: Gunakan Acatatan daripada CNAMEdi Route53.

Di Konsol Manajemen AWS, pilih "Catatan" dan kemudian pindahkan tombol radio berlabel "Alias" ke "Ya." Kemudian pilih ELB Anda dari menu dropdown.

Ada beberapa solusi potensial yang dapat Anda coba di forum pengembang AWS ini. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Sebagai contoh:

perbaikan potensial # 1

Kami memiliki masalah yang sama ketika kami pindah ke ELB, kami menyelesaikan ini dengan mengurangi nama ELB kami menjadi satu karakter. Bahkan 2 karakter char untuk ELB menyebabkan masalah acak dengan solusi jaringan resolusi DNS.

Nama DNS ELB Anda harus seperti -> X. <9chars> .us-east-1.elb.amazonaws.com

perbaikan potensial # 2

Saya poster aslinya. Terima kasih atas semua tanggapannya. Kami dapat mengurangi frekuensi kami mengalami masalah DNS dengan menyetel TTL sangat tinggi (sehingga mereka akan di-cache oleh server Solusi non-Jaringan). Namun, kami masih mendapatkan masalah yang cukup di mana kami tidak bisa lagi menggunakan Network Solutions. Kami berpikir untuk pindah ke UltraDNS berdasarkan laporan yang baik tentang layanan ini, tetapi sepertinya Rute 53 (yang akan menggunakan UltraDNS di balik selimut, akan terlihat) akan lebih murah bagi kami. Sejak beralih ke Rute 53, kami tidak lagi memiliki masalah DNS, dan nama ELB kami juga bagus dan panjang.

Ada hal-hal lain untuk dicoba di pos itu tetapi itu tampaknya menjadi petunjuk terbaik.