Pada tahun 2010, ada salah satu klien perusahaan besar dibidang pertambangan yang menghubungi saya terkait implementasi  mail server. Mereka bertanya sekaligus berdiskusi dengan saya mengenai sistem mail server berbasis Exchange Server yang sudah berjalan. Mengingat perusahaan tambang tersebut memiliki site dengan jumlah user beragam di berbagai tempat, mereka bertanya pada saya mengenai 2 hal, yaitu :

1. Apakah Zimbra bisa co-exist dengan Exchange, jadi sebagian user ada di Exchange dan sebagian lagi ada di Zimbra
2. Apakah Zimbra memiliki feature yang dimiliki  Exchange, yaitu memisahkan mailbox diberbagai tempat sedangkan authentikasi utama tetap kepusat. Misalnya ada beberapa site di Kalimantan, Bangka, Sulawesi dan Surabaya  sedangkan kantor pusat di Jakarta

Saat itu saya masih cupu (sekarangpun masih, malah lebih parah, hehehe…). Jangan-jangan Zimbra tidak punya feature seperti Exchange.

Ternyata untuk point 1  mudah dilakukan. Bisa dibaca disini artikelnya : Tips Integrasi Zimbra dengan Microsoft Exchange atau Aplikasi Mail Server Lain

Untuk masalah point 2, solusi sapu jagat adalah menempatkan seluruh sistem di kantor pusat di Jakarta sedangkan cabang lain cukup menggunakan webmail atau mail client untuk mengaksesnya. Cara ini memang menyelesaikan masalah namun tidak efektif dan efisien, karena :

1. Penggunaan bandwidth tidak efisien karena pengiriman email ke sesama site (misalnya sesama Kalimantan) harus lari ke Jakarta, padahal mungkin di Kalimantan meja pengirima dan meja penerima bersebelahan 🙂
2. Koneksi di berbagai tempat di Indonesia tidak merata kecepatannya. Pengiriman attachment meski hanya dari kantor cabang ke kantor pusat akan memakan waktu, apalagi jika ukurannya besar

Masalah untuk point 2 baru terpikirkan setelah saya hari Sabtu kemarin presentasi mengenai Workshop “Membangun Linux Active Directory, Domain Controller & File Server Berbasis Samba 4″, Sabtu, 6 Oktober 2012 dan kemudian membaca mengenai implementasi Zimbra Mail Server di kantor Mozilla : Re-imagining Zimbra email at Mozilla.

Ternyata solusinya ya itu dia, implementasi Zimbra Multi Server yang diterapkan untuk keperluan multi site. Untuk case Mozilla, mereka punya 2 server Zimbra, yaitu satu di San Jose, USA dan satu lagi di Beijing, China. Skemanya bisa dilihat pada ilustrasi gambar dibawah ini (credit gambar ada di Mozilla ya).

How things were, As of 15 January 2012

Two servers.  San Jose is the primary server, hosting all Zimbra components and almost all of the accounts.  The Beijing server serves only as local mailbox storage and SMTP for users in the Beijing office.

Two weeks worth of backups are stored on a NetApp filer, and then written to tape from there for long term storage.

Dengan skema diatas, email dari sesama staff Mozilla di Beijing tidak perlu lari-lari ke San Jose untuk kemudian kembali lagi ke Beijing dan sebaliknya. Email baru keluar jika account tersebut tidak ada di mailbox internal di site masing-masing.

Dalam skala lebih sederhana, hal diatas bisa diterapkan untuk skema kantor cabang dan kantor pusat seperti yang saya bicarakan diawal. Misalnya untuk Jakarta sebagai pusat, service yang diinstall adalah LDAP Server untuk semua authentikasi, MTA server untuk Jakarta dan Mailbox untuk Jakarta sedangkan untuk kota lain cukup mailbox server (dan jika perlu, MTA server).

Model multi server ini akan mudah diextend, berapapun banyaknya site yang harus dicover. Jika satu waktu ada tambahan site baru di Papua, kita cukup melakukan instalasi mailbox server dan MTA server di Papua. Site di Jakarta hanya untuk keperluan authentikasi saja.

Meski banyak site, aksesnya tetap bisa menggunakan 1 nama domain dan juga 1 akses. Misalnya sama-sama mengakses ke http://mail.excellent.co.id, nantinya user yang ada di Kalimantan akan secara otomatis menggunakan mailbox server Kalimantan yang memuat data mailbox user tersebut. Mekanisme ini menggunakan fasilitas Zimbra Proxy dan Zimbra Memcached yang sudah dibahas pada workshop hari Sabtu, 03 November 2012 lalu di Taman Bacaan Excellent.

Wah, kalau authentikasi teteup ke Jakarta, tetap ada kemungkinan lambat dong? Nah disini baru nanti kita bicara soal pembuatan LDAP replica. LDAP replica ini akan menyalin data-data di LDAP server utama untuk digunakan di site lokal. Untuk LDAP replica ini tutorialnya akan saya tuliskan di artikel berikutnya.

Note :

1. Pengalaman pribadi, saya pernah menolak permintaan klien untuk deployment sistem Zimbra Mail Server berbasis multi server disekitaran tahun 2009/2010. Alasannya? Karena saya belum capable dan nggak yakin dengan pemahaman saya mengenai multi server. Kalau sekarang ada perusahaan yang membutuhkan solusi diatas, duh, proposal bisa langsung terkirim 🙂
2. Klien yang saya bicarakan diawal masih menjadi klien Excellent saat ini. Mereka menggunakan model Zimbra High Availability Server (Cluster+Fail Over). Untuk implementasi multi site belum dilakukan. Saatnya mengirimkan proposal kesana, hehehe…
3. Skema diatas merupakan skema implementasi Zimbra di Mozilla sebelum diredesign. Sekarang Mozilla sudah menggunakan Zimbra dengan cluster berbasis VMWare vSphere. Mangstap kan 🙂
   

   How we are currently, As of 26 March 2012
   The new Phoenix installation consists of a VMWare ESX cluster, with each of the Zimbra components separated into their own VMs to allow scaling, components which can be configured redundantly placed behind the load balancer, and multiple mailbox servers to handle the number of user accounts we have.

   San Jose remains the master for now, and new accounts are currently created on the standalone physical server in Phoenix, which was added to pick up load in mid-January before the new ESX cluster was ready.

   We are now ready to start moving mailboxes off of the standalone servers in San Jose and Phoenix into the new cluster in Phoenix.