Samba & Zimbra High Availability & Fail Over Server

Libur panjang akhir pekan lalu saya isi dengan mengerjakan project implementasi migrasi sistem di salah satu klien di daerah Duren Sawit Jakarta Timur. Migrasi dilakukan dari sistem Windows Active Directory+File Server dan Microsoft Exchange Server menjadi sistem Linux Server berbasis Samba PDC & Zimbra Mail Server.

Pihak klien meminta agar sistem dibuat mampu melakukan fail over, dalam arti, jika server utama tewas, server backup langsung aktif dengan konfigurasi, data dan sistem yang sama persis. Untuk keperluan ini, pihak klien menyediakan 2 buah HP Server Proliant ML dengan memory 8 GB, 2 Network Card Gigabit dan double harddisk 1 TB pada masing-masing server. Ada 2 pilihan fail over disini, yaitu fail over berbasis Xen atau fail over berbasis Zimbra & Samba. Saya memilih opsi yang kedua. Berikut adalah urutan proses yang dilakukan, mungkin bisa bermanfaat bagi rekan-rekan lain yang membutuhkan. Detail masing-masing proses akan saya tuliskan secara terpisah.

PERSIAPAN

  1. DVD openSUSE 11.2 64 bit. Saya memilih untuk menggunakan openSUSE 11.2 64 bit atas pertimbangan versi Xen Hypervisor yang ada disini merupakan versi terbaru dibandingkan pada SLES 11. openSUSE 11.2 akan menjadi server induk (host) di masing-masing server
  2. DVD SUSE Linux Enterprise Server 11 64 bit, akan dijadikan sebagai Xen Hypervisor Guest
  3. CD SUSE Linux Enterprise Server 11 64 bit High Availability Extension. CD berukuran 25 MB ini berisi paket Linux HA seperti DRBD, OpenAIS dan PaceMaker. Saya akan menggunakan DRBD dan HeartBeat. HeartBeat diinstall dari openSUSE Build Service.
  4. Zimbra Binary versi 6.0.5 64 bit untuk SUSE Linux Enterprise Server 11

KONFIGURASI SISTEM

  • Server induk 1: Host : server1.namadomain.com, IP : 192.168.0.2
  • Server induk 2: Host : server2.namadomain.com, IP : 192.168.0.3
  • Server Zimbra 1 : Host : zcspdc1.namadomain.com, IP : 192.168.0.4
  • Server Zimbra 2 : Host : zcspdc2.namadomain.com, IP : 192.168.0.5
  • Server Zimbra yang akan digunakan : Host : mail.namadomain.com, IP : 192.168.0.1

File /etc/hosts pada server Zimbra 1 maupun server Zimbra 2 sama persis, yaitu :

192.168.0.4           zcspdc1.namadomain.com zcspdc1

192.168.0.5           zcspdc2.namadomain.com zcspdc1

192.168.0.1           mail.namadomain.com mail

INSTALASI

  1. Install openSUSE 11.2 menggunakan RAID Hardware. Panduan install ada disini : Tutorial instalasi openSUSE 11.2 Sebagai Server versi GUI
  2. Install paket Xen Hypervisor
  3. Set openSUSE bootloader agar booting menggunakan kernel Xen (YAST | System | Bootloader)
  4. Buat 1 buah Xen Hypervisor Guest, dengan memory 2 GB dan 2 buah harddisk. Harddisk 1 berukuran 20 GB sebagai basis Zimbra (bisa juga hanya 10 GB kalau tidak ada keperluan lain) dan harddisk 2 berukuran 200 GB. Harddisk 2 akan digunakan sebagai harddisk DRBD dan tidak diformat atau dimount pada saat instalasi.
  5. Install SLES 11 dalam formasi Minimal Server Selection (Text Mode Installation). Pilih harddisk 1 sebagai disk sistem dan biarkan harddisk 2 demikian adanya
  6. Selesai install SLES 11, install paket HA (DRBD dan Hearbeat) dari CD High Availability Extension
  7. Ubah nama host dan IP menjadi mail.namadomain.com dengan IP 192.168.0.1. Pengubahan ini berlaku sementara, hanya untuk proses instalasi Zimbra
  8. Setting DNS Server. MX records mengarah ke IP 192.168.0.1 dengan nama host mail.namadomain.com
  9. Install Zimbra Mail Server. Panduan ada disini : Zimbra 6.0.5 pada SUSE Linux Enterprise 11 64 bit.
  10. Ubah kembali nama server menjadi zcspdc1.namadomain.com dan IP 192.168.0.4
  11. Cloning sistem pada server server1 ke server2
  12. Ubah nama hostname dan IP pada Xen guest server 2. Ubah menjadi zcspdc2.namadomain.com dengan IP 192.168.0.5

KONFIGURASI

  1. Setting integrasi Samba PDC+Zimbra Mail Server. Panduan ada disini : Panduan Integrasi Samba PDC & Zimbra Mail Server
  2. Folder share Samba akan diletakkan dibawah folder /opt, misalnya /opt/share
  3. Matikan service Zimbra dan Samba
  4. Pindahkan folder /opt ke folder lain, misalnya /opt_save
  5. Buat folder /opt baru (mkdir /opt)
  6. Setting DRBD pada server zcspdc1 dan server zcspdc2. Format /ev/drbd0 menggunakan file system ext3 dan mounting /dev/drbd0 menjadi /opt
  7. Pindahkan isi /opt_save ke /opt
  8. Setting Heartbeat pada server zcspdc1 dan server zcspdc2. Berikut adalah isi file /etc/ha.d/haresources : zcspdc1 IPaddr::192.168.1.249/24/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/opt::ext3 named zimbra smb
  9. Matikan service Zimbra, Samba dan DNS agar tidak berjalan pada saat booting. Service ketiganya akan ditangani oleh Heartbeat

POST INSTALASI

  1. Buat symlink untuk file-file konfigurasi yang digunakan (antara lain : /etc/samba, /etc/ldap.conf, /etc/nssswitch.conf, /var/lin/named)
  2. Test apakah Heartbeat sudah berjalan dengan baik dengan perintah : service heartbeat stop pada server zcspdc1. Jika semua konfigurasi berjalan sempurna, sistem Zimbra akan beralih ke server zcspdc2
Pin It

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

Leave a Reply

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


*