Bagaimana saya bisa menggunakan haproxy cluster terukur dan andal di Amazon EC2?

25

Kami membutuhkan beberapa fungsionalitas yang lebih maju daripada yang disediakan ELB (kebanyakan inspeksi L7), tetapi tidak jelas bagaimana menangani hal-hal seperti detak jantung dan ketersediaan tinggi dengan sesuatu seperti haproxy menggunakan EC2. Ada kemungkinan besar kita membutuhkan 3 atau lebih haproxy node dalam cluster, jadi detak jantung yang sederhana antara dua node tidak akan bekerja.

Sepertinya memiliki lapisan detak jantung di depan node haproxy akan menjadi cara untuk pergi, mungkin menggunakan IPVS, tetapi menangani perubahan konfigurasi sebagai perubahan EC2 cluster (baik melalui perubahan yang disengaja, seperti ekspansi, atau tidak disengaja, seperti kehilangan sebuah Node EC2) tampaknya tidak sepele.

Lebih disukai solusi akan menjangkau setidaknya dua Zona Ketersediaan.

Sebagai jawaban untuk Qs: Tidak, sesi tidak lengket. Dan ya, kami membutuhkan SSL, tetapi secara teori bisa ditangani oleh pengaturan lain sepenuhnya - kami dapat mengarahkan lalu lintas SSL ke lokasi yang berbeda dari lalu lintas non-SSL.

Don MacAskill
sumber
Saya sedang meneliti bagaimana melakukan penyebaran kenari dengan persentase lalu lintas yang perlahan-lahan naik ke versi baru dari perangkat lunak, dan saya sangat ingin tahu tentang di mana Anda berakhir dengan ini. Apakah Anda akhirnya mencoba saran Jesper?
Iain

Jawaban:

14

OK, saya tidak pernah membangun solusi penyeimbangan beban AWS dengan lalu lintas pada tingkat SmugMug sendiri, tetapi hanya memikirkan teori dan layanan AWS, beberapa ide muncul di benak saya.

Pertanyaan awal hilang beberapa hal yang cenderung berdampak pada desain penyeimbangan beban:

  1. Sesi lengket atau tidak? Sangat disukai untuk tidak menggunakan sesi sticky, dan biarkan semua load balancers (LB's) menggunakan round robin (RR) atau seleksi backend acak. Pilihan backend RR atau acak sederhana, dapat diukur, dan memberikan distribusi beban yang merata dalam semua keadaan.
  2. SSL atau tidak? Apakah SSL sedang digunakan atau tidak, dan atas persentase permintaan yang mana, umumnya berdampak pada desain penyeimbangan beban. Seringkali lebih baik untuk mengakhiri SSL sedini mungkin, untuk menyederhanakan penanganan sertifikat dan menjaga beban CPU SSL dari server aplikasi web.

Saya menjawab dari perspektif bagaimana menjaga layer load balancing itu sendiri sangat tersedia. Menjaga server aplikasi HA hanya dilakukan dengan pemeriksaan kesehatan yang dibangun ke penyeimbang beban L7 Anda.

OK, beberapa ide yang seharusnya bisa digunakan:

1) "Cara AWS":

  • Lapisan pertama, di bagian paling depan, menggunakan ELB dalam mode L4 (TCP / IP).
  • Lapisan kedua, gunakan instance EC2 dengan penyeimbang beban L7 pilihan Anda (nginx, HAProxy, Apache dll).

Manfaat / ide: Penyeimbang beban L7 dapat berupa EC2 AMI yang cukup sederhana, semuanya diklon dari AMI yang sama dan menggunakan konfigurasi yang sama. Dengan demikian alat Amazon dapat menangani semua kebutuhan HA: ELB memonitor penyeimbang beban L7. Jika L7 LB mati atau menjadi tidak responsif, ELB & Cloudwatch bersama-sama menelurkan instance baru secara otomatis dan membawanya ke kumpulan ELB.

2) "The round robin DNS dengan cara pemantauan:"

  • Gunakan round robin dasar DNS untuk mendapatkan distribusi beban berbutir kasar pada beberapa alamat IP. Katakan saja Anda mempublikasikan 3 alamat IP untuk situs Anda.
  • Masing-masing dari 3 IP ini adalah AWS Elastic IP Address (EIA), terikat ke instance EC2, dengan penyeimbang beban L7 pilihan Anda.
  • Jika EC2 L7 LB mati, agen pengguna yang sesuai (browser) hanya harus menggunakan salah satu IP lainnya .
  • Siapkan server pemantauan eksternal. Pantau masing-masing 3 EIP. Jika seseorang menjadi tidak responsif, gunakan alat baris perintah AWS dan beberapa skrip untuk memindahkan EIP ke instance EC2 lainnya.

Manfaat / ide: Agen pengguna yang patuh harus secara otomatis beralih ke alamat IP lain jika seseorang menjadi tidak responsif. Jadi, dalam kasus kegagalan, hanya 1/3 dari pengguna Anda yang akan terpengaruh, dan sebagian besar dari mereka tidak akan melihat apa-apa karena UA mereka secara diam-diam gagal ke IP lain. Dan kotak pemantauan eksternal Anda akan melihat bahwa EIP tidak responsif, dan memperbaiki situasi dalam beberapa menit.

3) DNS RR ke pasangan server HA:

Pada dasarnya ini adalah saran Don sendiri tentang detak jantung sederhana antara sepasang server, tetapi disederhanakan untuk beberapa alamat IP.

  • Menggunakan DNS RR, publikasikan sejumlah alamat IP untuk layanan ini. Mengikuti contoh di atas, anggap saja Anda menerbitkan 3 IP.
  • Masing-masing IP ini masuk ke sepasang server EC2, jadi totalnya 6 EC2.
  • Masing-masing pasangan ini menggunakan Heartbeat atau solusi HA lainnya bersama-sama dengan alat AWS untuk menjaga 1 alamat IP tetap hidup, dalam konfigurasi aktif / pasif.
  • Setiap instance EC2 memiliki load balancer L7 Anda yang terpasang.

Manfaat / ide: Dalam lingkungan AWS yang sepenuhnya tervirtualisasi, sebenarnya tidak semudah itu untuk mempertimbangkan layanan L4 dan mode failover. Dengan menyederhanakan satu pasang server identik yang menjaga hanya 1 alamat IP hidup, itu menjadi lebih mudah untuk dipikirkan dan diuji.

Kesimpulan: Sekali lagi, saya belum benar-benar mencoba semua ini dalam produksi. Hanya dari firasat saya, opsi satu dengan ELB dalam mode L4, dan instance EC2 yang dikelola sendiri karena L7 LBs tampaknya paling selaras dengan semangat platform AWS, dan di mana Amazon kemungkinan besar akan berinvestasi dan mengembangkannya nanti. Ini mungkin akan menjadi pilihan pertama saya.

Jesper M
sumber
1
Jadi saya suka pendekatan # 1, itulah arah yang saya condongkan, tetapi masih ada beberapa gotcha yang menarik - tidak sedikit di antaranya adalah bahwa ELB tidak menangani seluruh AZ yang gagal dengan sangat baik (sesuatu yang telah kami alami sudah terjadi ). 'Solusi' yang mudah, tapi yucky, adalah memiliki haproxies di belakang ELB yang dikonfigurasikan untuk melintasi AZ (mungkin dengan cluster cadangan di AZ lain) jadi jika setidaknya satu haproxy di setiap AZ, kita harus baik-baik saja. Tapi itu hanya meniru, tidak menghilangkan masalah. Adakah ide untuk masalah ini?
Don MacAskill
@Don MacAskill: Saya tahu AWS telah mengalami beberapa kali downtime layanan skala besar, tetapi melakukan lebih baik daripada keandalan AZ pada AWS sulit. Pindah ke operasi multi-AZ dari frontend dapat dengan mudah menjadi langkah pertama menuju operasi multi-AZ dari seluruh tumpukan, dan itu adalah ketel seluruh ular ...
Jesper M
@Don MacAskill: Salah satu opsi adalah resolusi DNS yang sadar-geografis seperti DynDNS Dynect -> ELB + L7 LBs dalam satu AZ, dengan ELB + L7 lainnya pada siaga panas di AZ lain. (Selain menjadi geo-aware, Dynect juga memiliki beberapa pemeriksaan kesehatan.) DynDNS memiliki track record yang bagus untuk uptime, tetapi meskipun demikian, menambahkan DNS yang sadar geo adalah SPOF lain. Apakah penyeimbangan muatan Dynect + dalam 2 AZ memiliki waktu kerja jangka panjang yang lebih baik daripada hanya satu AWS AZ tidak jelas bagi saya. Lihat ini untuk ikhtisar tentang apa yang saya maksud, tanpa database multi-AZ: dev.bizo.com/2010/05/improving-global-application.html
Jesper M
@ Don MacAskill: Hanya satu hal terakhir - perlu diingat bahwa satu instance ELB dapat menjangkau beberapa AZ. Itu tidak dapat menjangkau seluruh wilayah EC2 . Tetapi jika hanya menggunakan ELB ke L7 LB di dua AZ di wilayah yang sama dapat diterima, ini akan menjadi yang paling sederhana ... Anda menulis "ELB tidak menangani seluruh AZ gagal dengan sangat baik", mungkin Anda sudah tahu lebih dari Saya lakukan.
Jesper M
Ya, jika ELB merentang beberapa AZ dan memiliki beberapa jenis kegagalan di mana ia tidak dapat mencapai salah satu node backend dalam AZ (mereka kelebihan beban, turun, mengembalikan 503, apa pun), pengguna akhir melihat kesalahan itu - tidak t rute ulang ke AZ lainnya. Saya berharap itu sudah direncanakan, tetapi sudah pernah menggigit kita.
Don MacAskill
2

Jika Anda tidak melakukan sesi lengket, atau jika Anda menggunakan gaya kucing jantan / apache (tambahkan ID simpul ke sessionid, sebagai lawan dari status penyimpanan di LB), maka saya akan menggunakan ELB di depan sekelompok haproxies. ELB memiliki pemeriksaan kesehatan bawaan, sehingga Anda dapat memantau haproxies dan mengeluarkan yang turun dari kolam. Jauh lebih sedikit untuk diatur daripada gagal jantung.

Sejauh menyebarkan perubahan, saya tidak punya jawaban yang bagus. Wayang sangat bagus untuk konfigurasi awal dan menerapkan perubahan, tetapi untuk menambah / menghapus node Anda cenderung menginginkan respons yang lebih cepat daripada interval polling 30 menit-nya.

Ben Jencks
sumber
1
Itu solusi yang bagus (dan pertanyaan yang bagus!) Anda dapat menggunakan Amazon SNS untuk menyebarkan perubahan konfigurasi secara push. Anda memerlukan sistem notifikasi untuk menambah / menghapus node dari konfigurasi haproxy.
Rafiq Maniar
Pilihan lain untuk mengelola server backend (yang haproxy diteruskan) adalah meminta setiap server backend mengirim semua haproxies, atau server konfigurasi, pendaftaran berkala (sekitar 30 detik). Jika seseorang mati, ia tidak terdaftar dengan cepat (dan haproxy tetap akan memperhatikannya); jika yang baru muncul secara otomatis akan dimasukkan ke dalam rotasi. Inilah yang tampaknya dilakukan Netflix.
Ben Jencks
1

Saya belum menggunakannya sendiri tetapi saya telah melihat banyak orang menyebutkan menggunakan boneka untuk menangani masalah seperti ini pada EC2

JamesRyan
sumber
Ya, Puppet on EC2 membuat mengelola sebuah cluster cukup mudah. Cukup buat instance mikro dan gunakan itu sebagai dalang Anda.
Tom O'Connor
1
Kami menggunakan boneka di pusat data kami, tetapi belum mencoba EC2. Apakah boneka EC2-entah bagaimana sadar, sehingga dapat menemukan node menggunakan contoh-contoh ec2-menggambarkan atau sesuatu, dan secara otomatis mengkonfigurasi / mengkonfigurasi ulang berdasarkan output itu? Dan bagaimana Anda menangani kepala boneka pergi tiba-tiba?
Don MacAskill
Kenapa tiba-tiba hilang begitu saja?
Tom O'Connor
Ini bukan EC2-aware, tetapi Anda dapat mengaturnya sehingga node baru akan ditandai untuk ditandatangani saat Anda memulainya, dan menggunakan skrip node eksternal untuk menggambarkannya. Saya menulis beberapa python untuk melakukan ini dengan SimpleDB (node ​​eksternal) dan SQS (antrian menandatangani permintaan untuk node baru); seorang ubuntu dev menulis skrip menggunakan S3: ubuntumathiaz.wordpress.com/2010/04/07/…
Ben Jencks
Jika kepala boneka pergi tiba-tiba, itu hanya tidak menjalankan manifes, yaitu meninggalkan simpul dalam keadaan apa pun mereka berada.
Ben Jencks