Samba & Zimbra High Availability & Fail Over Server

10 thoughts on “Samba & Zimbra High Availability & Fail Over Server”

1. 1. Saya sebetulnya skeptis sama DRBD, apakah dia sanggup catch up dengan perubahan data yang ada di file server dan mail server? Lalu kalau misalkan replikasi putus di tengah, misalkan karena link terputus, apa yang terjadi?
   2. Harga NIC itu murah, apalagi kalo cuman 100BaseT, mungkin ada baiknya dalam satu node, dibuat failover NIC dulu, agar tidak memancing failover (yang mahal secara proses) kalo ada kabel atau switch yang mogok. Baru kalo semua public NIC down, failover baru terjadi
   3. Ini nanya : Linux HA itu melakukan process monitoring terhadap jalannya daemon smbd, nmbd, winbindd dan Zimbra daemon? Apa yanag terjadi kalo misalkan daemonnya mati, atau jalan tapi jadi zombie? Ada probe testnya tidak?

2. @Dedhi,

   1. Yang terjadi bisa dicheck pada status, apakah data di node1 & node2 sama2 update atau tidak? Sial-sialnya adalah data di node 2 kurang lengkap dibanding yang ada di node 1 tapi replikasi bisa diproses ulang (jika force majeur)

   2. Sarannya akan dipertimbangkan. BTW, failover secara NIC keperluannya buat apa ? Soalnya si Heartbeat itu sebenarnya fail over NIC.

   3. Heartbeat dalam mode R1 hanya monitor status dirinya, jadi jika heartbeat mati atau server mati baru fail over berlaku. Kalau mau fail over untuk service daemon, mesti memasang package lain yang mampu melakukan monitoring service dan seperti MON package. Jika salah satu service mati, si MON ini bisa diperintahkan untuk mematikan HeartBeat.

3. 1. Replikasinya block device atau file based replication? Kalo misalkan ada satu file, di header dinyatakan ukurannya 100MB, tapi karena replikasinya baru jalan 50% lalu tiba tiba DRBD fail. Ntar itu file dinyatakan corrupt atau bagaimana? Apakah “sane state” yang terdefinisikan untuk kondisi seperti itu? Maju kena mundur kena kan? Apa lalu fsck?
   Itu makanya di solusi HA yang lain, biasanya gak pakai DRBD, tapi pakai dual port atau multi port storage. SCSI hard disk misalkan, bisa dibikin dual ported kok. 1st node pakai SCSI initiator ID 7, lalu 2nd node pakai SCSI initiator ID 6. Pada satu saat cluster framework hanya mengijinkan 1 node aja yang mount the shared storage at any given time. Jadi ndak perlu replikasi, lha wong storage cuman 1, dipake berdua
   2. Ah, berarti hear beatnya masuk lewat public network juga yah. Begini, failover antara 1st node ke 2nd node itu kan sebetulnya costly yah. Ada down time selama transition, belum kalo replikasinya gagal. Nah kalo misalkan service mati karena NIC mati, sebetulnya kan bisa ditanggulangi pakai NIC teaming atau network multipathing. Jadi paling tidak ada 2 NIC yg menghadap ke public network. Ketika primari NIC mati, standby NIC kicks in. Jadi ndak perlu ada node failover tho, kalo semata hanya masalah 1 NIC mati, atau 1 kabel network copot, atau 1 switch mati.
   3. Hmm, berarti cluster frameworknya masih kudu dilengkapi lagi dengan data service monitoring yah. In another word, clustering yang dipakai sekarang baru terbatas ke total hardware failure failover.

4. @Dedhi
   1. Betul, saya sempat implementasi juga DRBD + Heartbeat walau cuma sekala kecil2an aja, namun sialnya datanya walaupun kecil tapi backend dari database & sialnya lagi data finansial pula… Bukan mahal infrastrukturnya sich, namun mahal di resikonya.

   saya tertarik soal multi port storage, bisa dijelaskan lebih lanjut?

   2. Kalau soal Network Teaming / Eth Bonding kalo di linux, memang saya rasakan sangat efektif.

   3.Kalau saya ngakalinya file exits / process checking + port Monitoring

5. mas.. mau nanya, sya udh bikin drbd+heartbeat + zimbra
   saya melakukan failover dngn bbrpa cara
   1. saya matiin heartbeat dinode 1 tapi failovernya lama banget, skitar 2 menit lebih,kmudian sya start lg heartbeat di node1 , failbacknya jg sama waktu pindhnya jg 2 mnit lebih..
   emang lama mas ya??
   2. saya cabut kabel lan di node1, failovernya lbih cepat skitar antara 10-15 detik, tapi pas di pasang lg jdnya split brain, padahal klau komputer di matiin gk terjadi split brain,,
   mohon pencerahannya mas

6. @Ehan,

   1. Check di log, lambatnya karena melakukan apa saja?
   2. Kalau kabel dicabut akan selalu split-brain karena heartbeat hanya mendeteksi problem jika service si heartbeat mati. Kalau kabel LAN yang dicabut tidak akan terdeteksi sebagai fail over, meski akibatnya keduanya menganggap sama2 primary

7. berikut adlah log ketika saya mematikan heartbeat di node 1
   proses di log di node 1 yg memakan waktu lama
   1. mematikan proses zimbra (makan waktu 4 menit)
   2. no pkts missing from slave (node 2) makn waktu 2 mnit
   klau yg lainnya normal mas..

8. mas vavai, sistem yang sudah saya bikin, ketika failover dari node-1 ke node-2 dns (bind) nya tidak jalan karena ip virutal yg saya jadikan ip domain zimbra baru pindah, sehingga saya harus me-restart manual bind di node-2 terlebih dahulu, baru setelah itu dns (bind) nya bisa jalan.
   ada solusi gak mas, jika failover pindah ketika heartbeatnya sudah memberikan ip virtual ke node-2 maka bind nya restart sndiri secara otomatis.
   terima kasih

9. saya baca komen mas vavai diatas mengenai MON package.. saya udh coba googling, cuman saya bingung di servicenya, saya menggunakan zimbra, nah zimbra sndiri tidk terdaftar di service yg bisa MON monitor
   kalau kita hendak monitor zimbra dengan menggunakan mon, service apa yang dipakai dalam konfigurasi mon??

10. Mas.. mau nanya,

    untuk bagian konfigurasi, langkah no 4. dan no 7 dilakukan di kedua server atau server utamanya saja ? thnx

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