Pengelompokan J2EE, Bagian 1

Perusahaan memilih Java 2, Edisi Perusahaan (J2EE) untuk mengirimkan aplikasi penting mereka melalui Web. Dalam kerangka J2EE, cluster menyediakan layanan penting untuk memastikan waktu henti minimal dan skalabilitas maksimum. Sebuah cluster adalah sekelompok server aplikasi yang secara transparan menjalankan aplikasi J2EE Anda seolah-olah itu adalah satu entitas. Untuk menskalakan, Anda harus menyertakan mesin tambahan di dalam cluster. Untuk meminimalkan waktu henti, pastikan setiap komponen cluster redundan.

Pada artikel ini kita akan mendapatkan pemahaman dasar tentang clustering, metode clustering, dan layanan cluster penting. Karena pendekatan pengelompokan bervariasi di seluruh industri, kami akan memeriksa manfaat dan kelemahan dari setiap pendekatan. Selanjutnya, kita akan membahas fitur-fitur penting terkait cluster yang harus dicari di server aplikasi.

Untuk menerapkan pengetahuan pengelompokan yang baru kita peroleh ke dunia nyata, kita akan melihat bagaimana HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7, dan BEA WebLogic Server 6.0 masing-masing mengimplementasikan cluster.

Di Bagian 2 seri ini, kami akan membahas strategi pemrograman dan failover untuk cluster, serta menguji empat produk server aplikasi kami untuk melihat bagaimana mereka menskalakan dan failover.

Kluster ditentukan

Vendor server aplikasi J2EE mendefinisikan cluster sebagai sekelompok mesin yang bekerja bersama untuk secara transparan menyediakan layanan perusahaan (dukungan untuk JNDI, EJB, JSP, HttpSession dan failover komponen, dan seterusnya). Mereka membiarkan definisi tidak jelas karena setiap vendor menerapkan pengelompokan secara berbeda. Di salah satu ujung spektrum, vendor lain yang menempatkan dispatcher di depan sekelompok mesin independen, tidak ada yang memiliki pengetahuan tentang mesin lain dalam kluster. Dalam skema ini, petugas operator menerima permintaan awal dari pengguna dan membalas dengan header pengalihan HTTP untuk menyematkan klien ke server anggota cluster tertentu. Di ujung lain spektrum berada vendor yang menerapkan federasi mesin yang terintegrasi erat,dengan setiap mesin benar-benar menyadari mesin lain di sekitarnya bersama dengan objek pada mesin tersebut.

Selain mesin, cluster dapat terdiri dari redundan dan berkemampuan failover:

  • Penyeimbang beban: Titik masuk tunggal ke cluster dan lalu lintas direktur ke server Web atau aplikasi individu
  • Server web
  • Router gateway: Titik keluar dari jaringan internal
  • Sakelar multilayer: Filter paket dan bingkai untuk memastikan bahwa setiap mesin dalam cluster hanya menerima informasi yang berkaitan dengan mesin itu
  • Firewall: Pelindung cluster dari peretas dengan memfilter akses level port ke cluster dan jaringan internal
  • Sakelar SAN (Storage Area Networking): Menghubungkan server aplikasi, server Web, dan database ke media penyimpanan backend; mengelola disk fisik mana untuk menulis data; dan failover
  • Database

Terlepas dari bagaimana penerapannya, semua cluster memberikan dua manfaat utama: skalabilitas dan ketersediaan tinggi (HA).

Skalabilitas

Skalabilitas mengacu pada kemampuan aplikasi untuk mendukung peningkatan jumlah pengguna. Cluster memungkinkan Anda menyediakan kapasitas ekstra dengan menambahkan server ekstra, sehingga memastikan skalabilitas.

Ketersediaan tinggi

HA dapat diringkas dalam satu kata: redundansi. Sebuah cluster menggunakan banyak mesin untuk melayani permintaan. Oleh karena itu, jika ada mesin dalam cluster yang gagal, mesin lain dapat mengambil alih secara transparan.

Sebuah cluster hanya menyediakan HA di tingkat server aplikasi. Agar sistem Web menunjukkan HA yang sebenarnya, itu harus seperti bahtera Nuh yang memuat setidaknya dua dari semuanya, termasuk server Web, router gateway, infrastruktur switching, dan sebagainya. (Untuk informasi lebih lanjut tentang HA, lihat Daftar Periksa HA.)

Jenis cluster

Cluster J2EE biasanya memiliki dua jenis: shared nothing dan shared disk. Dalam cluster tanpa-bersama, setiap server aplikasi memiliki sistem filenya sendiri dengan salinan aplikasinya sendiri yang berjalan di cluster. Pembaruan dan peningkatan aplikasi memerlukan pembaruan di setiap node di cluster. Dengan penyiapan ini, cluster yang besar menjadi mimpi buruk dalam pemeliharaan saat dorongan kode dan pembaruan dirilis.

Sebaliknya, cluster disk bersama menggunakan perangkat penyimpanan tunggal yang digunakan semua server aplikasi untuk mendapatkan aplikasi yang berjalan di cluster. Pembaruan dan peningkatan terjadi dalam satu sistem file dan semua mesin di cluster dapat mengakses perubahan. Sampai saat ini, sisi negatif dari pendekatan ini adalah satu-satunya titik kegagalannya. Namun, SAN memberikan satu antarmuka logis ke dalam media penyimpanan yang redundan untuk menyediakan pengalihan, pengulangan, dan skalabilitas. (Untuk informasi selengkapnya tentang SAN, lihat bilah sisi Infrastruktur Penyimpanan.)

Saat membandingkan implementasi cluster server aplikasi J2EE, penting untuk mempertimbangkan:

  • Implementasi cluster
  • Layanan pengalihan cluster dan komponen
  • Pengalihan HttpSession
  • Titik tunggal kegagalan dalam topologi cluster
  • Tata letak topologi yang fleksibel
  • Pemeliharaan

Nanti kita akan melihat bagaimana empat server aplikasi populer dibandingkan di berbagai area. Tapi pertama-tama, mari kita periksa setiap item lebih detail.

Implementasi cluster

Server aplikasi J2EE menerapkan pengelompokan di sekitar implementasi JNDI (Penamaan Java dan Antarmuka Direktori). Meskipun JNDI adalah layanan inti yang diandalkan oleh aplikasi J2EE, sulit untuk diterapkan dalam cluster karena tidak dapat mengikat beberapa objek ke satu nama. Tiga metode pengelompokan umum ada dalam kaitannya dengan implementasi JNDI setiap server aplikasi:

  • Independen
  • Terpusat
  • Berbagi global

Pohon JNDI mandiri

HP Bluestone Total-e-Server dan SilverStream Application Server menggunakan pohon JNDI independen untuk setiap server aplikasi. Server anggota dalam cluster pohon JNDI independen tidak mengetahui atau peduli tentang keberadaan server lain di cluster. Oleh karena itu, failover tidak didukung atau disediakan melalui layanan perantara yang mengarahkan permintaan HTTP atau EJB. Layanan perantara ini dikonfigurasi untuk mengetahui di mana setiap komponen dalam kluster berada dan cara mendapatkan komponen alternatif jika terjadi kegagalan.

Satu keuntungan dari cluster pohon JNDI independen: konvergensi cluster yang lebih pendek dan kemudahan penskalaan. Konvergensi cluster mengukur waktu yang diperlukan cluster untuk sepenuhnya menyadari semua mesin di cluster dan objek terkaitnya. Namun, konvergensi bukanlah masalah dalam cluster pohon JNDI independen karena cluster mencapai konvergensi segera setelah dua mesin dijalankan. Keuntungan lain dari cluster pohon JNDI independen: penskalaan hanya memerlukan penambahan server tambahan.

Namun, ada beberapa kelemahan. Pertama, failover biasanya merupakan tanggung jawab pengembang. Artinya, karena pohon JNDI setiap server aplikasi bersifat independen, proxy jarak jauh yang diambil melalui JNDI disematkan ke server tempat pencarian dilakukan. Dalam skenario ini, jika panggilan metode ke EJB gagal, pengembang harus menulis kode tambahan untuk menyambung ke operator, mendapatkan alamat server aktif lain, melakukan pencarian JNDI lain, dan memanggil metode gagal lagi. Bluestone mengimplementasikan bentuk yang lebih rumit dari pohon JNDI independen dengan membuat setiap permintaan melalui layanan proxy EJB atau Proxy LBB (Load Balance Broker). Layanan proxy EJB memastikan bahwa setiap permintaan EJB masuk ke instans UBS yang aktif. Skema ini menambahkan latensi ekstra ke setiap permintaan tetapi memungkinkan failover otomatis di antara panggilan metode.

Pohon JNDI terpusat

Sybase Enterprise Application Server mengimplementasikan cluster pohon JNDI terpusat. Di bawah penyiapan ini, cluster pohon JNDI terpusat menggunakan layanan CosNaming CORBA untuk JNDI. Server nama menampung pohon JNDI terpusat untuk kluster dan melacak server mana yang aktif. Saat startup, setiap server dalam cluster mengikat objeknya ke dalam pohon JNDI serta semua server nama.

Mendapatkan referensi ke EJB dalam cluster pohon JNDI terpusat adalah proses dua langkah. Pertama, klien mencari objek rumah dari server nama, yang mengembalikan referensi objek interoperable (IOR). IOR menunjuk ke beberapa mesin aktif di cluster yang memiliki objek rumah. Kedua, klien memilih lokasi server pertama di IOR dan mendapatkan home dan remote. Jika ada kegagalan di antara pemanggilan metode EJB, rintisan CORBA mengimplementasikan logika untuk mengambil rumah atau jarak jauh lain dari server alternatif yang terdaftar di IOR yang dikembalikan dari server nama.

Server nama itu sendiri menunjukkan kelemahan cluster pohon JNDI terpusat. Secara khusus, jika Anda memiliki cluster yang terdiri dari 50 mesin, yang lima di antaranya adalah server nama, cluster tersebut menjadi tidak berguna jika kelima server nama mati. Memang, 45 mesin lainnya dapat aktif dan berjalan tetapi kluster tidak akan melayani satu klien EJB saat server penamaan tidak aktif.

Masalah lain muncul dari menghadirkan server nama tambahan secara online jika terjadi kegagalan total server nama asli cluster. Dalam kasus ini, server nama terpusat yang baru mengharuskan setiap mesin yang aktif di kluster untuk mengikat objeknya ke pohon JNDI server nama baru. Meskipun dimungkinkan untuk mulai menerima permintaan saat proses pengikatan berlangsung, hal ini tidak disarankan, karena proses pengikatan memperpanjang waktu pemulihan cluster. Lebih lanjut, setiap pencarian JNDI dari aplikasi atau applet benar-benar mewakili dua panggilan jaringan. Panggilan pertama mengambil IOR untuk suatu objek dari server nama, sedangkan panggilan kedua mengambil objek yang diinginkan klien dari server yang ditentukan di IOR.

Akhirnya, cluster pohon JNDI terpusat mengalami peningkatan waktu untuk konvergensi seiring dengan bertambahnya ukuran cluster. Artinya, saat Anda menskalakan cluster, Anda harus menambahkan lebih banyak server nama. Perlu diingat bahwa rasio yang diterima secara umum dari mesin server nama terhadap mesin klaster total adalah 1:10, dengan jumlah minimal dua server nama. Oleh karena itu, jika Anda memiliki cluster 10 mesin dengan dua server nama, jumlah total pengikatan antara server dan server nama adalah 20. Dalam kluster 40 mesin dengan empat server nama, akan ada 160 pengikatan. Setiap pengikatan mewakili proses di mana server anggota mengikat semua objeknya ke pohon JNDI dari server nama. Dengan pemikiran tersebut, cluster pohon JNDI terpusat memiliki waktu konvergensi terburuk di antara semua implementasi cluster JNDI.

Pohon JNDI global bersama

Terakhir, BEA WebLogic mengimplementasikan pohon JNDI global bersama. Dengan pendekatan ini, ketika server di cluster mulai mengumumkan keberadaannya dan pohon JNDI ke server lain di cluster melalui multicast IP (Internet Protocol). Setiap mesin yang dikelompokkan mengikat objeknya ke dalam pohon JNDI global bersama serta pohon JNDI lokalnya sendiri.

Memiliki pohon JNDI global dan lokal dalam setiap server anggota memungkinkan rumah yang dihasilkan dan rintisan jarak jauh untuk melakukan failover dan menyediakan pencarian JNDI dalam proses yang cepat. Pohon JNDI global bersama dibagikan di antara semua mesin di dalam kluster, memungkinkan mesin anggota mana pun mengetahui lokasi persis semua objek di dalam kluster. Jika sebuah objek tersedia di lebih dari satu server dalam kluster, objek rumah khusus terikat ke pohon JNDI global bersama. Rumah khusus ini mengetahui lokasi semua objek EJB yang terkait dan menghasilkan objek jarak jauh yang juga mengetahui lokasi semua objek EJB yang terkait dengannya.

Kelemahan utama pendekatan global bersama: lalu lintas jaringan awal yang besar dihasilkan saat server mulai dan waktu konvergensi cluster yang lama. Sebaliknya, dalam cluster pohon JNDI independen, konvergensi terbukti tidak menjadi masalah karena tidak ada pembagian informasi JNDI yang terjadi. Namun, kluster global atau terpusat bersama memerlukan waktu bagi semua mesin kluster untuk membangun pohon JNDI global atau terpusat bersama. Memang, karena kluster global bersama menggunakan multicast untuk mentransfer informasi JNDI, waktu yang diperlukan untuk membangun pohon JNDI global bersama bersifat linier terkait dengan jumlah server berikutnya yang ditambahkan.

Manfaat utama global bersama dibandingkan dengan pusat cluster pohon JNDI terpusat pada kemudahan penskalaan dan ketersediaan yang lebih tinggi. Dengan shared global, Anda tidak perlu mengutak-atik CPU dan RAM pada server nama khusus atau menyesuaikan jumlah server nama di cluster. Sebaliknya, untuk menskalakan aplikasi, cukup tambahkan lebih banyak mesin. Selain itu, jika ada mesin di cluster yang mati, cluster akan terus berfungsi dengan baik. Akhirnya, setiap pencarian jarak jauh memerlukan satu panggilan jaringan dibandingkan dengan dua panggilan jaringan yang diperlukan dalam cluster pohon JNDI terpusat.

Semua ini harus diambil dengan hati-hati karena JSP, servlet, EJB, dan JavaBeans yang berjalan di server aplikasi dapat memanfaatkan lokasi bersama di server EJB. Mereka akan selalu menggunakan pencarian JNDI dalam proses. Perlu diingat bahwa jika Anda hanya menjalankan aplikasi sisi server, ada sedikit perbedaan antara implementasi klaster global independen, terpusat, atau bersama. Memang, setiap permintaan HTTP akan berakhir di server aplikasi yang akan melakukan pencarian JNDI dalam proses untuk mengembalikan objek apa pun yang digunakan dalam aplikasi sisi server Anda.

Selanjutnya, kami mengalihkan perhatian kami ke pertimbangan server aplikasi J2EE penting kedua: layanan cluster dan failover.

Layanan cluster dan failover