Tulisan ini merupakan seri tulisan mengenai pengalaman melakukan upgrade sistem mail server. 2 tulisan sebelumnya adalah :
Setelah kegagalan proses upgrade di hari Jumat malam hingga Sabtu siang yang terjadi di kantor klien, saya meluangkan waktu untuk refreshing berkebun di markas alam Taman Bacaan Excellent. Untuk sementara saya mencoba bersantai, sebelum nantinya memikirkan dan mereview kembali apa yang menjadi sumber kegagalan sebelumnya.
Jika saya review, kegagalan sebelumnya terjadi karena beberapa faktor, antara lain :
- Tidak fokus. Sebelum melakukan upgrade, saya dan team meeting terlebih dahulu dengan klien lain di daerah Lebak Bulus. Dari sana baru meluncur ke Tanah Abang. Meski sekedar meeting, itu berarti saya berangkat lebih awal dan jadi lebih capek. Tidak fresh saat tiba di kantor klien. Untuk proses upgrade berikutnya, saya mengosongkan jadwal agar fokus pada pekerjaan utama
- Menyepelekan Persiapan. Meski tidak dimaksud menyepelekan, nyatanya saya menganggap enteng persiapan. Secara teori, kami tidak akan menghadapi kesulitan melakukan backup, apalagi “sekedar” install vCenter karena kami sudah berkali-kali melakukan instalasi. Meski vCenter 6 memiliki skema instalasi berbeda, saya beberapa kali melakukannya. Di markas Excellent pun ada cluster yang berjalan dengan vCenter 6. Nyatanya, instalasi vCenter menghabiskan waktu hingga berjam-jam karena ada masalah yang tidak ada di teori maupun di knowledge base VMware 🙂
- Terlalu PD. Secara prinsip ini sama saja menyepelekan persiapan. Saya berpikir bahwa proses backup nggak akan makan waktu lama. Tidak ada kesulitan. Bisa langsung salin kemudian tunggu waktu selesai. Ternyata ini jadi bottleneck utama saat upgrade.
Terkait hal diatas, akhirnya saya memutuskan beberapa strategi yang mungkin bisa dipersiapkan lebih awal agar kejadian gagal upgrade sebelumnya tidak terulang kembali. Berikut adalah beberapa persiapannya :
- Mengosongkan Jadwal. Pada schedule upgrade pekan berikutnya, saya mengosongkan jadwal team agar lebih fresh, siap dan cukup istirahat, apalagi dengan asumsi proses upgrade dilakukan menjelang malam hari
- Mendahulukan persiapan. Semua tahapan yang bisa dilakukan tanpa mematikan sistem atau bisa dilakukan secara paralel, saya lakukan lebih awal. Mulai hari Senin saya melakukan backup sistem. Untuk selisih data baru akan saya lakukan penyalinan ulang sebelum proses upgrade dilaksanakan. Jadi waktunya tidak habis diawal.
Saya juga mendahulukan proses update OS, download binary dan lain-lain agar waktu efektif untuk upgrade (timeframe yang diberikan oleh pihak manajemen klien untuk mematikan services) bisa dimanfaatkan sebaik-baiknya
- Membackup Data. Semua VM dan data plain (folder yang disalin via rsync) saya lakukan lebih awal, sehingga saya cukup percaya diri untuk eksekusi proses upgrade secara langsung
Informasi dari pihak klien, proses upgrade akan dilakukan Siang hari di Hari Sabtu pekan berikutnya hingga minggu pagi. Seminimal mungkin down time. Kalau bisa down time hanya saat upgrade saja. BTW, opsi upgrade tanpa down time nanti saya ceritakan diwaktu lain, belajar dari pengalaman yang terjadi ini.
Sabtu pagi saya meluncur bersama team Excellent, Ahmad Imanudin dan Muhammad Dhenandi ke kantor klien via KA Commuter Line. Sampai di kantor klien dalam kondisi fresh, karena Jumat malam saya sudah tidur lebih awal, jadi cukup istirahat.
Kami menjalankan proses yang sudah disiapkan dan disepakati secara lancar. Sempat terjadi hambatan saat menyalin VM berisi data HSM, karena besarnya data. Akhirnya prosesnya bisa kami by pass dengan melakukan rsync dengan beberapa exclude hidden folder sebagai parameter.
Setelah memeriksa integritas hasil backup, kami melakukan eksekusi upgrade, mulai dari LDAP Server, kemudian mailbox, Archive dan terakhir MTA/SMTP Server berikut Zimbra Proxy. Proses upgrade cukup lama terhambat di mailbox, namun ini sudah kami prediksi karena disini ada update database schema sekaligus pengecekan database integrity.
Pada upgrade mailbox juga sempat terjadi kendala karena installer tidak dapat mendeteksi file lisensi Zimbra NE, namun dapat kami atasi dengan menyalin file lisensi dari data backup. Hal yang sama terjadi juga pada mailbox kedua dengan jumlah user lebih banyak. Kali ini installer mendeteksi bahwa lisensi belum diaktivasi, karena aktivasi otomatis tidak dapat berjalan. Kami bisa mengatasinya dengan melakukan aktivasi secara manual.
Lepas dari proses upgrade mailbox server, proses upgrade VM yang lain berjalan lebih lancar. Setelah selesai semua, kami mengaktifkan kembali semua VM secara berurutan, kemudian validasi akhir dengan melakukan restart semua VM.
Setelah dicheck, secara umum sistem sudah berjalan sesuai harapan, namun ada beberapa bug yang syukurnya sudah terdokumentasi di wiki Zimbra maupun forum Zimbra. Saya bahkan tidak perlu kontak support Zimbra meskipun bisa, karena semuanya bisa kami atasi.
Beberapa custom config perlu disesuaikan namun itu juga sudah masuk dalam catatan finalisasi dan validasi kami, jadi tidak ada issue yang terjadi. Saat saya hendak bilang bahwa proses upgrade kali ini berjalan dengan lancar dan sukses, tiba-tiba pihak klien berkata, “Pak Vavai, email-email saya yang lama hilang semua nih. Kalau dilihat ada emailnya tapi setelah diklik tidak ada isinya alias blank”.
Saya segera mengecek ke log sistem. Disitu saya menemukan informasi bahwa Zimbra tidak dapat menemukan file msg yang terkait dengan mailbox tertentu. Saya check ternyata ini tidak random melainkan permanent. Semua email lama tidak dapat diakses. Saya hampir berkeringat dingin (terbayang proses roll back yang akan lebih sulit karena sudah sebagian diupgrade, belum lagi membayangkan kegagalan kedua kali, hehehe), namun setelah saya check, ternyata kegagalan ini karena adanya perubahan mount data HSM. Karena ada perubahan data folder di HSM, proses mount sempat diset manual dan jadi lepas saat dilakukan reboot sistem. Setelah dimasukkan kembali ke fstab kemudian mount, data email aman kembali dan data-data lama bisa diakses secara sempurna
Saya tidak berpuas diri. Saya minta ditest sekali lagi proses restart VM agar bisa dipastikan masalahnya selesai secara sempurna. Setelah proses restart dan hasil pengecekan menunjukkan proses upgrade berjalan lancar, barulah saya menyempatkan diri makan sambil ngobrol dengan pihak klien.
Pihak klien masih mengecek beberapa kali dan menghubungi beberapa pihak untuk validasi dari sisi internal. Setelah pengecekan berjalan dengan lancar, akhirnya pekerjaan ini dianggap selesai. Kami akhirnya pulang dengan hati tenang dan riang. Saya informasikan pada pihak klien bahwa di Senin pagi, saya akan mengirimkan 2 orang team Excellent sebagai stand by engineer untuk antisipasi jika terjadi beberapa kendala pasca upgrade.
Setelah 1 minggu proses monitoring relatif tanpa kendala, akhirnya berita acara penyelesaian pekerjaan ditandatangani oleh pihak klien. 2 minggu berikutnya, staff adm Excellent menginformasikan pada saya bahwa invoice yang dikirimkan sudah cair.
Alhamdulillah 😉