Alternatif untuk Detak Jantung, Alat Pacu Jantung dan CoroSync?

26

Apakah ada alternatif utama untuk failover otomatis di Linux selain kombinasi Heartbeat / Pacemaker / CoroSync yang khas? Secara khusus, saya menyiapkan failover pada instance EC2, yang hanya mendukung unicast - tidak ada multicast atau siaran. Saya secara khusus mencoba menangani beberapa perangkat lunak yang kami miliki yang belum memiliki failover otomatis dan tidak mendukung lingkungan multi-master. Ini termasuk alat-alat seperti HAProxy dan Solr.

Saya memiliki Heartbeat + Pacemaker bekerja, tetapi saya tidak senang dengan itu. Inilah beberapa masalah saya:

  • Detak Jantung - Dengan sendirinya, terbatas pada dua node. Saya ingin memiliki 3+.
  • Alat pacu jantung - Tidak mungkin untuk mengkonfigurasi secara otomatis. Cluster harus berjalan dengan kuorum dan kemudian masih membutuhkan konfigurasi manual.
  • CoroSync - Tidak mendukung unicast.

Alat pacu jantung bekerja dengan sangat baik, meskipun kekuatannya membuat pengaturan sulit. Masalah sebenarnya dengan alat pacu jantung adalah bahwa tidak ada cara mudah untuk mengotomatisasi konfigurasi. Saya benar-benar ingin meluncurkan instance EC2, menginstal Chef / Puppet dan memiliki seluruh peluncuran cluster tanpa campur tangan saya.

sayuran organik
sumber

Jawaban:

17

Saya lebih suka menggunakan keepalived untuk ketersediaan tinggi. Saya merasa lebih mudah untuk mengatur (satu daemon dan konfigurasi) daripada detak jantung dan perusahaan. Satu-satunya kelemahan yang saya temui, adalah keepalived tidak memiliki opsi unicast secara default, dan hanya menggunakan VRRP untuk komunikasi (Penulis HAProxy telah menulis patch unicast untuk keepalived namun)

JimB
sumber
Unicast adalah suatu keharusan, tetapi saya akan melihat patchnya.
organicveggie
4
+1 Saya telah terbiasa menggunakan detak jantung dalam semua situasi "failover", sampai saya membaca posting (di suatu tempat) oleh penulis haproxy mengapa saya melakukan kesalahan (atau setidaknya tidak efisien) dan harus menggunakan keepalived saja . Itu semua tergantung pada apakah hal yang penting gagal-melalui jalur jaringan (misalnya memindahkan IP ke server yang berbeda - tetap disimpan), atau perlu memastikan hanya akses tunggal ke sumber daya (misalnya koneksi SAN - detak jantung).
Coops
5
Ini adalah surat yang diacu oleh @Coops, saya percaya formilux.org/archives/haproxy/1003/3259.html
Henrik
4
Sejak rilis 1.2.8 (2013-08-05) Keepalived mendukung Unicast ( keepalived.org/changelog.html ).
Dynom
Artikel pengantar: opentodo.wordpress.com/2012/04/29/…
Vadzim
14

Saya benar-benar mengerjakan sesuatu yang sangat mirip dengan apa yang Anda gambarkan (gagal-gugus pada EC2), dan setelah mencoba Heartbeat, memilih Corosync sebagai lapisan olahpesan saya. Corosync akan berjalan di beberapa server dan mendukung Unicast (UDPU) pada versi 1.3.0 (mulai November 2010). Saya telah menyiapkan dan menguji Corosync di cloud EC2 Amazon (menggunakan AMI Linux Amazon) dan dapat mengonfirmasi bahwa itu berfungsi tanpa masalah.

Contoh file udpu diinstal ke / etc / corosync.

Tambahkan satu blok anggota ke bagian antarmuka untuk setiap node, dan tentukan transport sebagai updu. (Saya telah menggunakan port yang sama dengan detak jantung pada contoh di bawah ini, tetapi Anda dapat mengubahnya sesuai keinginan).

misalnya:

totem {
        version: 2
        secauth: off
        interface {
                member {
                        memberaddr: 10.xxx.xxx.xxx
                }
                member {
                        memberaddr: 10.xxx.xxx.xxx
                }
                ringnumber: 0
                bindnetaddr: 10.xxx.xxx.xxx
                mcastport: 694
        }
        transport: udpu
}

(Detak jantung seharusnya mendukung 3+ kluster simpul di versi 1.2.3+, walaupun, saya belum pernah mencobanya secara pribadi, dan tidak tahu apakah itu akan bekerja dengan Unicast).

cyberx86
sumber
Saya telah menyiapkan sekelompok 3 mesin menggunakan udpu, dan itu berfungsi dengan baik. Anda terus menambahkan blok anggota ke dalamnya.
devicenull
11

Maaf, tetapi bagian tentang alat pacu jantung tidak benar. Uji regresi dan rilis alat pacu jantung menggunakan otomasi secara ekstensif.

Untuk mengonfigurasi tanpa cluster aktif, awali semua perintah dengan CIB_file=/var/lib/heartbeat/crm/cib.xmlatau atur di lingkungan Anda. Pastikan Anda menghapus file .sig sebelum memulai cluster.

Untuk cluster tanpa kuorum, sebagian besar jika tidak semua alat harus mendukung -fatau --forceyang akan memerintahkan cluster untuk menerima perubahan. Jika Anda menemukan alat yang tidak - silakan ajukan bug.

Andrew Beekhof
sumber
Maaf, pendapat saya didasarkan pada umpan balik yang saya dapatkan dari milis Pacemaker. Saya akan mencoba saran Anda.
organicveggie
3

Di dunia open source, ada RedHat Cluster Suite . Sudah beberapa tahun sejak saya menerapkan RHCS jadi saya tidak punya banyak hal yang relevan untuk dikatakan tentang hal itu hari ini.

Secara komersial, ada Veritas Cluster Server . Tidak ada pengalaman dengannya.

Alat HA sumber yang jauh lebih sederhana dan open source adalah UCARP . UCARP tidak menyediakan "infrastruktur" yang hampir sama dengan Heartbeat / Pacemaker / CoroSync tetapi Anda dapat membangun solusi HA di sekitarnya.

Anda juga dapat membangun infrastruktur yang sangat tersedia dengan teknologi virtualisasi tetapi solusi ini cenderung berfokus pada ketersediaan di tingkat host dibandingkan dengan ketersediaan di tingkat aplikasi.

rthomson
sumber
Terima kasih. Saya akan melihat RHcS, VCS dan UCARP. Saya telah memperbarui pertanyaan saya untuk mencerminkan fakta bahwa saya menggunakan Amazon EC2, jadi ketersediaan tingkat host bukanlah sesuatu yang saya kendalikan ... oleh karena itu mengapa saya mencari ketersediaan tingkat aplikasi.
organicveggie
1

Ada Oracle Clusterware untuk Oracle Unbreakable Linux, meskipun saya belum menggunakannya.

Kendall
sumber
1

Jika Anda sudah menggunakan EC2, mengapa tidak menggunakan Elastic Load Balancing ? Ini akan memungkinkan Anda mencapai ketersediaan tingkat aplikasi tanpa harus mengkonfigurasi failover sendiri.

manku
sumber
Ada beberapa alasan mengapa ELB tidak cocok. Pertama, ELB hanya berfungsi untuk permintaan yang datang dari Internet publik - ini tidak dapat digunakan untuk permintaan internal, kecuali jika Anda mengarahkan permintaan Anda ke alamat publik ELB dan kemudian membayar semua lalu lintas. Kedua, ELB adalah penyeimbang yang sangat sederhana - Anda tidak dapat menerapkan aturan atau pola apa pun tentang cara kerjanya dan Anda tidak dapat memiliki server siaga. Misalnya, Anda tidak ingin dua instance HAProxy terpisah aktif menunjuk ke server web yang sama karena mereka tidak akan memiliki gagasan tentang beban aktual di server web target.
organicveggie
1

Veritas Cluster sangat bagus (dibandingkan dengan Linux-Heartbeat, AIX-hacmp, HP-Serviceguard dan Sun cluster), tetapi membutuhkan banyak uang. Terakhir kali saya melihatnya harga didasarkan pada cpu-core cluster. Vendor Saat Ini d ...

Nils
sumber
0

Saya menulis manajer kluster failover di posix shell: https://github.com/nackstein/back-to-work

lihat itu, saya mencari seseorang yang ingin mencobanya dan membantu dalam pengembangan.

Luigi
sumber
0

opensvc ( https://www.opensvc.com ) mendukung beberapa driver detak jantung:

  • unicast
  • multicast
  • disk bersama
  • Relai situs ke-3

dan juga memiliki mekanisme kuorum jika otak terpecah.

Saya berhasil secara otomatis menyiapkan 4 node cluster yang terbuat dari 2 google cloud instance + 2 amazon instance dengan terraform + ansible.

Chaoxiang N
sumber