Di bagian pertama blog ini, kami menyiapkan HAProxy pada node Virtual Load Balancer di E2E Cloud. Kami juga mengonfigurasi HAProxy untuk merutekan permintaan ke server web back-end menggunakan kebijakan round-robin.
Di bagian kedua dan penutup blog ini, kita akan menjalankan beberapa pengaturan konfigurasi lanjutan yang dibutuhkan sebagian besar situs web:kekakuan sesi, dan akses aman ke situs web menggunakan SSL. Namun sebelum kita melakukannya, kita akan menunjukkan bagaimana instans HAProxy tunggal kita dapat melayani situs web besar dengan banyak aplikasi web, berdasarkan ACL. Sementara itu, kami akan menampilkan beberapa opsi konfigurasi tambahan, seperti kebijakan round robin berbobot, dan menyimpulkan dengan petunjuk pertimbangan penting lainnya untuk penerapan produksi.
Pengaturan Load-balancer Untuk Beberapa Aplikasi Web
Banyak situs web besar terdiri dari beberapa klaster server web, setiap klaster menampung aplikasi web yang berbeda. Misalnya, mungkin ada situs web dengan konten utama bersama dengan situs web untuk kesenangan dan hiburan. HAProxy mampu merutekan permintaan ke cluster yang tepat berdasarkan pola URL dan Daftar Kontrol Akses (ACL).
Untuk mengilustrasikan kemampuan ini, pertama-tama kita buat dua node server web baru di E2E Cloud, bernama 'webserver3' dan 'webserver4'. Seperti biasa, kami menginstal server web Apache dan paket PHP pada dua node baru. Kemudian kami menerapkan aplikasi PHP kedua di URL ‘/fun/films.php‘ di hanya dua node yang baru ditambahkan ini . (Aplikasi kedua menggunakan ketekunan sesi dan fungsinya akan dijelaskan di bagian berikutnya.)
Jadi, kami memiliki node berikut (4 server web dan penyeimbang beban) yang terlihat di Dasbor kami:
Gambar 1:Server-Web untuk Beberapa Aplikasi Web
Jadi HAProxy harus mengarahkan permintaan klien untuk URL ‘/fun/films.php‘ ke salah satu node ‘webserver3‘ dan ‘webserver4‘ saja, atau permintaan tidak dapat dilayani sama sekali. Untuk memenuhi persyaratan ini, kami memodifikasi konfigurasi HAProxy (/etc/haproxy/haproxy.cfg) dan membuat satu backend lagi (bernama 'film') yang terdiri dari dua node server web baru saja. Ini merupakan tambahan untuk backend yang ada bernama 'situs'.
Gambar 2:Konfigurasi backend untuk aplikasi baru
Kemudian, pada konfigurasi frontend yang ada, kami memperkenalkan ACL seperti yang ditunjukkan di bawah ini. Artinya, setiap jalur URL yang dimulai dengan '/ fun' akan dirutekan ke backend bernama 'films', sedangkan secara default semua permintaan lainnya akan mendarat di backend (yang sudah ada) bernama 'site' (terdiri dari node 'websrv1' dan 'websrv2' saja).
Gambar 3:Konfigurasi frontend dengan ACL
Gambar 4:HAProxy Load-balancing dengan ACL
Setelan Konfigurasi Lanjut
Kebijakan Round Robin Tertimbang :Saat membuat modifikasi untuk ACL, kami memperkenalkan bobot ke setiap server. Dalam produksi, server yang berbeda mungkin memiliki daya komputasi yang berbeda, jadi menggunakan bobot memungkinkan HAProxy untuk mengarahkan lebih banyak permintaan ke server yang lebih kuat. (Dalam kasus kami, semua node server web serupa, dan semua bobotnya sama, tetapi kami dapat menggunakan ini sebagai template dan mengubahnya dalam skenario yang berbeda.)
Koneksi Maks Per Server :Kedua, kami juga menggunakan parameter ‘maxconn‘ di tingkat server backend , sehingga setiap server dapat membatasi jumlah koneksi yang sesuai dengan kekuatan pemrosesannya. Global 'maxconn' harus lebih besar dari jumlah total nilai tingkat server parameter ini (meninggalkan beberapa ruang untuk lebih banyak node server web yang akan ditambahkan untuk skalabilitas).
Kelengketan sesi
Aplikasi PHP baru kebetulan menggunakan sesi PHP. Setiap kali klien mengakses aplikasi ini, ia memberikan nama film favorit (melalui parameter HTTP GET bernama 'fav'), yang ditambahkan ke sesi PHP. Server merespons dengan daftar film favorit (unik untuk setiap klien) yang dikumpulkan sejauh ini.
- session_start();
- $fav =$_GET['fav'];
- if ( isset( $_SESSION['favorites'] ) ) {
- $_SESSION[‘favorit’] .=‘ , ‘;
- $_SESSION[‘favorit’] .=$fav;
- } lain
- $_SESSION[‘favorit’] =$fav;
- }
- $msg ='Film Favorit Saya:'. $_SESSION['favorit'];
- ?>
-
Film Favorit Saya - echo $msg;
- ?>
Sesi PHP mungkin bersifat lokal untuk instance server web (kecuali jika persistensi atau replikasi sesi diaktifkan). Jadi, jika klien yang sama dirutekan secara acak ke instance server web backend yang berbeda pada waktu yang berbeda, ketika membuat serangkaian permintaan, data sesinya mungkin menjadi tidak dapat diprediksi. Tapi klien bisa dipaksa untuk 'tetap ' ke satu instance server web dalam durasi sesi.
Salah satu cara untuk menyiapkan ini di HAProxy adalah dengan memperkenalkan parameter 'appsession' pada konfigurasi backend yang relevan ('film' , dalam kasus kami). Berbagai jenis aplikasi menggunakan Cookie HTTP yang berbeda untuk manajemen sesi. Dalam hal aplikasi PHP, Cookie ini diberi nama 'PHPSESSID'. Dengan menyetel 'appsession', HAProxy mengaitkan satu server web dengan masing-masing 'PHPSESSID' (tempat sesi ini dibuat), dan merutekan permintaan klien berulang yang berisi id sesi yang sama ke server web yang sama, selama masih aktif dan berjalan atau waktu sesi habis .
- appsession PHPSESSID len 32 batas waktu 1 jam
Tentu saja, jika server web tersebut menjadi tidak tersedia karena alasan apa pun, HAProxy harus bebas merutekan permintaan dengan id sesi yang sama ke instance server aktif yang berbeda. Ini dapat dipastikan dengan menambahkan opsi 'redispatch' di bagian 'default' dari file konfigurasi HAProxy.
- pengiriman ulang opsi
Pengujian
Sekarang kita dapat menguji ACL dan kekakuan sesi. Kita dapat mengekor log HAProxy pada node load-balancer:
- tail -f /var/log/haproxy.log
Kami juga mengekor log akses server web pada setiap node 'webserver3' dan 'webserver4'.
1. tail -f /var/log/Apache2/access.log
Dari dua mesin klien yang berbeda, kami mengirim permintaan ke URL berikut dari browser:http://
Dalam setiap permintaan, kami dapat menetapkan nilai yang berbeda untuk parameter kueri bernama ‘fav‘.
Dari klien pertama, kami mengirimkan permintaan berurutan berikut:
- http://
/fun/films.php?fav=avengers - http://
/fun/films.php?fav=jurassicworld
Jendela browser pada klien pertama akan menampilkan:
Gambar 5:Satu sesi klien
Dari klien kedua, kami mengirimkan permintaan berurutan berikut:
- http://
/fun/films.php?fav=race3 - http://
/fun/films.php?fav=gold
Jendela browser di klien kedua akan menampilkan:
Gambar 6:Sesi klien lain
Dari respons yang ditampilkan di setiap browser klien, jelas bahwa sesi dipertahankan dengan benar di setiap kasus. Di Firefox, dari konsol web, kami juga dapat memeriksa nilai PHPSESSID.
Kita dapat membuat dua pengamatan berikut dari HAProxy dan log server web:
- Permintaan dengan pola URL '/fun' ini diarahkan ke backend bernama 'film' saja (kebijakan ACL)
- Permintaan dari alamat IP klien yang sama mendarat di node server web yang sama (kelengketan sesi)
Gambar 7:HAProxy log dengan sesi sticky
Gambar 8:Akses log pada node webserver3 dengan sesi sticky
Gambar 9:Akses log pada node webserver4 dengan sesi sticky
Keamanan:Penghentian SSL
Satu konfigurasi terakhir namun penting yang ingin kami ambil adalah terkait dengan keamanan. Server web Apache dapat dikonfigurasi untuk mendukung HTTPS, tetapi ketika kami telah menginstal HAProxy di frontend, permintaan klien akan mendarat di penyeimbang beban terlebih dahulu.
Jadi, direkomendasikan agar kami mengonfigurasi HAProxy untuk mendukung HTTPS. Ini adalah proses empat langkah:
- Dapatkan sertifikat SSL untuk situs web kami. Untuk tujuan eksperimental, kami membuat sertifikat yang ditandatangani sendiri bernama haproxy.pem menggunakan openssl
- Ikat frontend ke port HTTPS (secara default 443) dan tetapkan sertifikat SSL ke frontend ini
- Aktifkan HAProxy untuk mengalihkan permintaan klien yang dikirim melalui HTTP ke port HTTPS
- Tambahkan atau setel header yang diperlukan ke permintaan HTTP di setiap dari backend yang dikonfigurasi
Tiga langkah pertama di atas diterapkan di tingkat frontend. (Kami telah mengganti nama frontend kami sebagai 'alltraffic' bukan 'httptraffic'.)
Gambar 10:Konfigurasi frontend untuk SSL
Langkah keempat di atas diterapkan di setiap bagian belakang:
Gambar 11:Konfigurasi backend untuk SSL
Biasanya header X-Forward-Port dan X-Forward-Proto membantu aplikasi membuat URL dengan benar saat permintaan HTTP dan HTTPS memungkinkan.
Mengakhiri SSL di node load-balancer memang membuat beberapa pemrosesan overhead pada node ini (dibandingkan dengan menyampaikan permintaan terenkripsi ke backend). Ada parameter yang terkait dengan algoritma enkripsi yang digunakan. Nilai yang lebih tinggi meningkatkan overhead pemrosesan pada node HAProxy. Itu dapat diatur di bagian 'global' dari konfigurasi HAProxy:
- tune.ssl.default-dh-param 2048
Jadi, permintaan terenkripsi SSL berakhir di load-balancer, yang merutekan permintaan HTTP yang tidak terenkripsi ke server web backend.
Gambar 12:Penghentian SSL
Setelan Firewall
Kita perlu membuka port 443 pada node virtual load balancer (berjalan di CentOS), dengan menjalankan perintah:
- iptables -A INPUT -i eth0 -p tcp –dport 443 -m state –state BARU,ESTABLISHED -j ACCEPT
- systemctl restart iptables
Pengujian
Kami sekarang mencoba mengakses aplikasi PHP Greeter kami melalui browser (Firefox), dengan menunjuk ke HTTP tidak aman URL:
http://
Meskipun demikian, Firefox akan meminta kami untuk menambahkan pengecualian keamanan, yang menunjukkan bahwa klien diteruskan ke URL HTTPS aman . Ini juga ditunjukkan di bilah alamat pada browser itu sendiri.
Gambar 13:Mengakses Aplikasi Web melalui SSL
Membuat Gambar dan Pemantauan Mesin
Kiat :Banyak upaya telah dihabiskan untuk mengonfigurasi instance penyeimbang beban virtual. Gambar mesin dari node ini dapat disimpan sehingga instance load-balancer serupa dapat dibuat di masa mendatang dengan menggunakannya sebagai template. Di E2E Cloud, ini dapat dicapai dengan terlebih dahulu mematikan node HAProxy dan kemudian menyimpan gambar node ini dari Dasbor.
Gambar 14:Menyimpan image mesin HAProxy
Gambar 15:Membuat image mesin dari node HAProxy
Secara opsional, image mesin dari instance server web juga dapat disimpan.
Memantau Menggunakan Zabbix :Node HAProxy, seperti node virtual lainnya di E2E Cloud, dapat dipantau menggunakan Zabbix. Kita harus memanfaatkan kemampuan ini.
Gambar 16:Memantau Kesehatan Load Balancer
Kesimpulan dan Langkah Selanjutnya
E2E Cloud menawarkan node Virtual Load Balancer untuk menyiapkan load-balancing menggunakan HAProxy. Dalam dua blog ini kami meninjau bagaimana penginstalan HAProxy di E2E Cloud dapat dikonfigurasi untuk mendukung penyeimbangan beban round-robin untuk situs web multi-aplikasi sederhana dan besar dengan kekakuan sesi dan akses aman melalui HTTPS.
Kami akan mengakhiri blog ini dengan memperhatikan beberapa pertimbangan lain untuk penerapan produksi:
- Pertama node Virtual Load Balancer (dan secara opsional node server web) harus diikat ke domain menggunakan pengaturan DNS yang sesuai
- Dengan demikian, sertifikat SSL untuk akses aman ke instance HAProxy harus diikat ke domain yang sama
- Akhirnya, penyeimbang beban tidak boleh menjadi satu titik kegagalan. Jadi, penerapan HAProxy secara aktif-pasif mungkin direkomendasikan.