Elasticsearch-Split Brain Problem

Safe is Better than Sorry

Berpakah banyak node yang harus dimiliki oleh cluster elasticsearch ?Pertanyaan ini merupakan pertanyaan yang sering dan umum ditanyakan ketika membangun suatu search engine berbasiskan elasticsearch. Untuk menjawabnya bukanlah suatu yang mudah dan termasuk pertanyaan sulit untuk dijawab. Solusinya bukan sekadar teori tetapi lebih ke proses analisis dan membutuhkan jawaban dari seseorang yang berpengalaman menggunakan elasticsearch.

Pertanyaan di atas biasanya bermuara pada pertanyaan-pertanyaan berikut.

1. Berapa banyak data yang Ada gunakan dan kerjakan?
2. Berapa banyak pencarian yang akan Anda proses?
3. Sebarapa susah, rumit, dan kompleks pecarian yang terjadi?
4. Seberapa banyak resource yang akan digunakan untuk tiap nodenya?
5. Berapa banyak index yang akan digunakan?

Sebernarnya ada permasalahan mendasar yang perlu diperhatikan bukan sekadar performance yang di kejar, tetapi safety first yang harus didahulukan. Problem utama yang harus ditanggulangi adalah terjadinya Split Brain pada elasticsearch.

Apa itu Split Brain?

Apabila sebuah node down atau ada jeda waktu komunikasi antar node yang dikarenakan oleh banyak alsan, biasanya mengakibatkan ada node slave yang tidak dapat berkomunikasi dengan node master. Node master baru akan dipilih dari node-node yang tersabung dengan node yang tidak bisa terhubung ke node master tadi.

Node master baru akan mengambil alih tugas node master sebelumnya. Jika node master lama terhubung kembali maka node master baru akan menjadi node slave kembali untuk menghindarkan konflik. Bisanya proses ini dilakukan dengan sangat mulus dan langsung berfungsi dengan lancar.

Namun, ada kondisi-kondisi yang mengakibatkan proses di atas tidak terjadi dengan mulus malah menimbulkan permasalahann yang besar. Contoh umum adalah ketika elasticsearch cuma memiliki satu node. Jelaslah syarat minimal avalability juga tidak terpenuhi.

Contoh kedua, jika elastic cluster terdiri dari dua node yaitu satu master dan satu slave.Jika komunikasi antara keduanya terganggu atau bahkan salah satu node mati, maka node yang masih hidup akan dipilih sebagai node master. Apabila kominikasi sudah pulih atau node yang mati telah hidup kembali permasalahan akan muncul. Node master lama akan mengaanggap node master baru telah menjadi slave dan bergabung sebagi slave. Akan tetpai ternyata node master baru menganaggap pula node master lama bergabung menjadi slave. Dengan demikian, terjadi dua master yang masing-masing berjalan sendiri-sendiri. Ini lah yang disebut Split Brain Problem.

Misalkan cluster di atas memiliki satu index dengan satu shard primari dan satu shard replika. Node A di delegasikan sebagai node master dan memegang 0P (primary shard) dan Node B sebagai slave dan memegang 0R (replica shard)

Apabila komunikasi antar node tergannggu atau master node mati, atau salah satu node tidak responsip maka akan terjadi seperti berikut.

Kedua node akan merasa node yang lainya mati. Node A tidak akan bertindak apapun karena dirinya sudah merupakan master node sedangkan Node B akan manjadi master node karena merasa master node mati.

Dengan demikian, kondisi cluster kita menjadi ada dua master yang satu sama lain terpisah. Cluster dalam kondisi state yang tidak konsisten atau status merah. Dalam kondisi ini ke dua node datanya tidak sama alias tidak singkron jalan yang bisa diambil satu-satunya adalam melakukan reindex dari awal dan ini d bayar dengan cost yang sangat mahal yaitu sistem menjadi offline dengan lama waktu tergantung ukuran dan banyaknya index yang harus di buat baru. Bayangkan jika ukuran index di atas 10 Gega, maka bisa dibayangkan sistem kita akan down selama itu pula.

Pemilihan Master Node

Properti discovery.zen.minimum_master_nodes pada elasticsearch.yml akan menentukan jumlah minimum master node yang eligible atau berhak untuk di pilih. Nilai default nya adalah 1. Aturan praktisnya adalan (N/2)+1 dengan N adalah jumlah node. Misalkan jumlah node yang ada adalah 3 maka nilai minimun master node adalah 3/2+1=2 (dibulatkan ke bawah).

Mari kita bayangkan apa yang akan terjadi dalam kasus yang dijelaskan di atas jika kita menyetel discovery.zen.minimum_master_nodes ke 2 (2/2 + 1). Ketika komunikasi antara dua node hilang, Node 1 akan kehilangan status masternya sementara Node 2 tidak akan pernah terpilih sebagai master. Tak satu pun dari node akan menerima permintaan pengindeksan atau pencarian, membuat masalah segera terlihat jelas untuk semua client. Selain itu, tidak ada shard yang berada dalam kondisi tidak konsisten. Dengan demikian, kita bakal mendapatkan allert bahwa sistem cluster elastic dalam masalah dan kita tingal melakukan restart cluster elasticnya.

Kondisi di atas lebih baik jiga dibandingkan dengan kondisi split brain terjadi, yakti cluster node masih beroperasi bisa memberikan balikan data akan tetapi kedua node dalam konfdisi data yang tidak singkron.

Pengaturan ini harus selalu dikonfigurasi ke kuorum (mayoritas) node yang memenuhi syarat master Anda. Kuorum adalah (number of master-eligible nodes / 2) + 1. Berikut beberapa contohnya:

• Jika Anda memiliki 10 node reguler (dapat menyimpan data, dapat menjadi master), kuorumnya adalah 6.
• Jika Anda memiliki 3 node master khusus dan seratus node data, kuorumnya adalah 2, karena Anda hanya perlu menghitung node yang memenuhi syarat master.
• Jika Anda memiliki 2 node biasa, Anda berada dalam ketidakpastian. Kuorum adalah 2, tetapi ini berarti hilangnya satu node akan membuat cluster Anda tidak dapat beroperasi. Pengaturan 1 akan memungkinkan cluster Anda berfungsi, tetapi itu tidak melindungi dari split brain dan yang terbaik adalah memiliki minimal 3 node dalam situasi seperti ini.

Parameter lain yang bisa Anda ubah adalah discovery.zen.ping.timeout . Nilai default-nya adalah 3 detik dan menentukan berapa lama node akan menunggu respon dari node lain di cluster sebelum mengasumsikan bahwa node telah gagal. Sedikit meningkatkan nilai default jelas merupakan ide bagus dalam kasus jaringan yang lebih lambat. Parameter ini tidak hanya melayani latensi jaringan yang lebih tinggi, tetapi juga membantu dalam kasus node yang merespons lebih lambat karena kelebihan beban.

Minimum Master Node

Jika menurut Anda salah (atau setidaknya tidak intuitif) untuk menyetel parameter minimum_master_nodes ke 2 dalam kasus dua cluster node, Anda mungkin benar. Dalam kasus ini saat node gagal, seluruh cluster gagal. Meskipun ini menghilangkan kemungkinan terjadinya split-brain, ini juga meniadakan salah satu fitur hebat dari elasticsearch — mekanisme high avaibiklity bawaan melalui penggunaan shard replika.

Jika Anda baru memulai dengan elasticsearch, rekomendasinya adalah merencanakan cluster 3 node. Dengan cara ini Anda dapat menyetel minimum_master_nodes ke 2, membatasi kemungkinan split brain , tetapi tetap mempertahankan high availability.

Kesimpulan

Masalah split-brain tampaknya sulit diselesaikan secara permanen. Di github elasticsearch masih ada issue tentang hal ini, yang menjelaskan kasus dimana dengan nilai yang benar dari parameter minimum_master_nodes pun, split-brain masih terjadi.

Tim elasticsearch saat ini sedang mengerjakan implementasi yang lebih baik dari algoritme pemilihan master, tetapi jika Anda sudah menjalankan cluster elasticsearch, penting untuk menyadari potensi masalah ini.

Sangat penting juga untuk mengidentifikasinya sesegera mungkin. Cara mudah untuk mendeteksi bahwa ada sesuatu yang salah adalah dengan menjadwalkan pemeriksaan untuk respons endpoint nodes untuk setiap node. Endpoint ini mengembalikan laporan status singkat dari semua node di cluster. Jika dua node melaporkan komposisi cluster yang berbeda, itu adalah tanda bahwa situasi split-brain telah terjadi.