Strategi Migrasi dan Upgrade Zimbra

Beberapa bulan yang lalu, saya beserta rekan saya Raihan melakukan upgrade dan migrasi Zimbra di salah satu klien. Total usernya tidak terlalu banyak. Sekitar 5000 account. Ditambah 500 an account sebagai tambahan. Total servernya sekitar 6-7 server. Total datanya lebih kurang 27 TB. Data tersebut merupakan data yang sudah didedup. Jika tanpa dedup, ukurannya bisa jadi 2 kali lipatnya. Bahkan lebih. Data backup bawaan Zimbra juga sudah ada. Totalnya lebih kurang 12 TB.

Yang jadi tantangan justru di sisi timeline. Timeline diset lebih kurang 1 bulan. Apakah 1 bulan cukup? bisa dibilang cukup “mepet”. Karena dalam rentang waktu tersebut, ada penyesuaian jadwal kick of meeting, persiapan server baru, dan yang lainnya. Hanya 2 minggu yang benar-benar dipakai untuk mulai proses upgrade dan migrasi.

Selain informasi di atas, OS dan versi Zimbra yang digunakan sudah obsolete. OS menggunakan RHEL/CentOS 7, dan Zimbra versi 9.

Dengan mepetnya timeline, adanya upgrade OS, upgrade Zimbra, minimum downtime, total data lumayan besar, maka dibuatlah beberapa skenario

1. Clone Cluster Existing

Dengan melakukan clone cluster existing, kelebihannya adalah semua konfigurasi dan yang lainnya akan disalin sama persis. Dengan total data 27 TB dibagi 2 server mailbox (server utama), dan asumsi 1 hari 25% progress clone, maka dibutuhkan waktu 4 hari per server. Dibulatkan menjadi 7 hari. Khawatir adanya fluktuasi data yang tersalin. Itu juga kalo prosesnya lancar.

Kekurangannya, bagaimana jika ditengah jalan proses clone failed? tentu proses clone harus dilakukan dari awal. Selain itu, OS yang digunakan masih sama persis. Masih harus ada proses upgrade OS setelahnya.

Jika proses clone sukses, prosedur yang dilakukan adalah penyesuaian IP address, DNS lokal, Upgrade Zimbra ke versi terbaru. Untuk mengatasi upgrade OS, bisa dibuatkan 1 disk baru, diinstall OS terbaru pada disk tersebut, install dependensi yang dibutuhkan Zimbra, lalu install Zimbra software only. Disk yang sudah ada data Zimbra, dimounting sesuai foldernya

2. Membuat Cluster baru dan Restore data dari Backup

Skenario ini bisa dibilang cukup clean. Data backup sudah ada. Tinggal buat cluster baru sesuai dengan server sizing. OS tentu sudah menggunakan versi terbaru yang disupport oleh Zimbra. Di permukaan terlihat lebih mudah prosesnya.

Tantangan muncul ketika data backup tidak compatible dengan Zimbra versi terbaru. Data backup masih menggunakan backup Zimbra NG (kerja sama dengan Zextras). Sedangkan Zimbra terbaru, sudah tidak menggunakan backup Zimbra NG dan hanya menggunakan backup Zimbra sebelumnya (non NG). Yang harus dilakukan pada cluster baru adalah install Zextras pada Zimbra 10 dan pastikan bisa berjalan dengan baik. Mengingat Zextras sudah tidak mengeluarkan Zextras installer untuk Zimbra 10. Jika hal tersebut tidak dapat dilakukan, maka harus dilakukan backup ulang menggunakan Zimbra non-NG pada cluster eksisting dengan data sebesar 27 TB. Setelahnya, data tersebut harus direstore ke cluster baru.

Dari sisi timeline, tentu lebih lama prosesnya. Apalagi jika ada kekhawatiran backup yang gagal dipertengahan. Begitu juga dengan restorenya yang gagal dipertengahan. Mengingat datanya cukup besar. Jika itu terjadi, proses backup/restore harus dimulai dari awal

3. Backup via Rsync/Rclone dan mounting NFS

Skenario ini menggunakan beberapa tahapan dan tools. Yaitu Rsync/Rclone untuk salin data parsial dan NFS untuk mounting data yang belum tersalin. Jika goal utamanya adalah upgrade OS dan upgrade Zimbra, maka cara ini lebih cepat. Data yang belum tersalin akan diproses pasca upgrade. Waktu 1 minggu sudah cukup. Berikut tahapannya

• Cluster baru dibuat sesuai dengan server sizing. OS sudah menggunakan versi terbaru
• Semua data disalin dari server lama ke server baru via rsync/rclone. Kecuali folder store. Dengan data 14 TB per mailbox, asumsi data pada folder store sekitar 13 TB – 13,5 TB. Jadi proses salin datanya lebih cepat. 1 hari sudah selesai seharusnya
• Karena Zimbra cluster eksisting masih versi 9, maka harus diupgrade terlebih dahulu ke versi 10. Masalahnya, OS versi terbaru tidak mendukung Zimbra versi 9.
• Untuk mengatasi kompatibilitas Zimbra versi 9, proses upgrade bisa dilakukan pada OS RHEL/CentOS 7 terlebih dahulu. Proses tersebut dapat dilakukan menggunakan Docker atau LXC. Proses upgrade 1 hari sudah cukup. Docker/LXC tersebut diinstall langsung pada cluster baru. Folder hasil salin data, bisa dimounting sebagai volume agar tidak perlu salin data ulang ke Docker/LXC
• Pada cluster baru, install Zimbra sebagaimana mestinya. Mulai dari persiapan, install dependensi, dan install Zimbra software only
• Pastikan Zimbra hasil upgrade pada Docker/LXC, dapat distart dengan normal di server induk (host). Saya menggunakan metode rsync to rsync migration: https://wiki.zimbra.com/wiki/ZCS_to_ZCS_rsync_Migration
• Setelah Zimbra pada cluster baru dengan versi terbaru ready, buat volume baru pada cluster eksisting (Zimbra 9). Misalnya volume dengan nama 2store diarahkan ke folder /opt/zimbra/2store
• Buat juga volume baru dengan nama yang sama di cluster baru (2store diarahkan ke folder /opt/zimbra/2store)
• Jadikan volume baru tersebut sebagai current volume. Nantinya semua data baru akan masuk ke dalam volume tersebut
• Setup cluster eksisting (mailbox server) sebagai NFS server. Share folder /opt/zimbra/store agar bisa dimounting via NFS dari cluster baru (mailbox server). Limit aksesnya hanya dari IP mailbox baru saja
• Ingat proses rsync/rclone tanpa folder store? nah di step ini folder store dimounting dari server lama sebagai share folder (nfs share) ke server baru (/opt/zimbra/store)
• Pada saat proses switching/migrasi, sisa data dapat disinkronisasi via imapsync atau via Zimbra Backup
• Setelah proses switching selesai, salin data folder store Zimbra lama ke cluster Zimbra baru dapat dijalankan. Misalnya disalin ke folder /mnt/store di cluster baru
• Setelah folder store selesai disalin ke cluster baru, stop Zimbra pada cluster baru, unmount NFS sebelumnya, pindahkan (mv /mnt/store) folder hasil salin dari cluster lama ke folder /opt/zimbra/store. Lalu start kembali services Zimbra-nya

Itulah beberapa skenario migrasi dan upgrade Zimbra yang disiapkan untuk project di salah satu klien. Masing-masing memiliki kelebihan dan kekurangannya. Yang jadi konsen utamanya adalah timeline-nya

Semoga bermanfaat 🙂