Tips Mengatasi Masalah DRBD Split-Brain : WFConnection & StandAlone

Kemarin saya melakukan pengecekan melalui SSH pada salah satu server Linux High Availability di kantor klien yang menggunakan DRBD & Heartbeat untuk menjalankan Zimbra & Samba PDC.

DRBD dan Heartbeat adalah 2 service yang saya gunakan untuk membuat server backup online yang mampu secara otomatis menggantikan fungsi server utama jika server utama down, dengan data yang sama persis hingga menit terakhir :-).

Dari hasil pengecekan, ternyata ada masalah sinkronisasi antar node sehingga service DRBD menjadi StandAlone, seperti tampilan status berikut ini :
[code language=’cpp’]
zcspdc1:~ # service drbd status
drbd driver loaded OK; device status:
version: 8.2.7 (api:88/proto:86-88)
GIT-hash: a1b440e8b3011a1318d8bff1bb7edc763ef995b0 build by lmb@hermes, 2009-02-20 13:35:59
m:res  cs          st                 ds                 p  mounted  fstype
0:r0   StandAlone  Secondary/Unknown  UpToDate/DUnknown  –
1:r1   Connected   Primary/Secondary  UpToDate/UpToDate  C  /opt     ext
[/code]

Lihat status untuk resource r0, statusnya adalah StandAlone, Secondary/Unknown, berbeda dengan status resource r1 yang statusnya Connected Primary Secondary. Status StandAlone ini tidak boleh terjadi karena itu berarti data di server utama tidak akan disinkronisasi ke server kedua. Seharusnya statusnya connected sehingga data di server utama akan secara otomatis tersalin ke server kedua/backup

Masalah ini dikenal dengan istilah Split-Brain. Kondisi ini terjadi jika service DRBD sempat down dan saat up kembali, keduanya terdeteksi sama-sama sebagai primary. Ada 2 kemungkinan yang akan terjadi, yaitu status StandAlone jika DRBD mendeteksi keduanya dalam kondisi Split-Brain, atau bisa juga status WFConnection jika salah satu node sudah keburu down sebelum dideteksi oleh node partnernya (peernya).

Pada hakikatnya, Split-Brain berarti si DRBD bingung menentukan node mana yang akan menjadi primary. Jika node utama sempat mati dan kemudian service sinkronisasi data diambil alih oleh node kedua, ada kemungkinan kita harus menjadikan node kedua sebagai primary (karena mungkin sudah ada data yang tersimpan/terupdate dibanding node utama) dan membatalkan kemungkinan update data yang sempat terjadi di node utama saat service DRBD kembali berjalan.

Pada contoh berikut, saya mengorbankan kemungkinan perubahan data pada node kedua dan menggunakan node utama sebagai node primary.

Untuk mengatasi masalah Split-Brain secara manual dan menjadikan kedua node kembali melakukan sinkronisasi, lakukan hal sebagai berikut :

  1. Jadikan node kedua sebagai secondary node dan batalkan perubahan yang sempat terjadi
    [code language=’cpp’]
    drbdadm secondary r0
    drbdadm — –discard-my-data connect r0
    [/code]
  2. Jadikan node utama sebagai primary dan lakukan koneksi ulang agar node utama langsung melakukan sinkronisasi data
    [code language=’cpp’]
    drbdadm primary r0
    drbdadm connect r0
    [/code]

Jangan lupa menyesuaikan nama resource (r0) dengan resource yang ingin dikoneksikan dan disinkronisasi ulang. Proses sinkronisasi biasanya jauh lebih cepat daripada sinkronisasi awal saat DRBD disetup, karena proses koneksi ulang ini hanya melakukan sinkronisasi block device yang bermasalah saja.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.