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

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.

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.

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.

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