Mengoptimalkan penyimpanan email di Zimbra Collaboration Suite

Di salah satu kami artikel sebelumnya, yang didedikasikan untuk perencanaan infrastruktur ketika mengimplementasikan Zimbra Collabortion Suite di suatu perusahaan, dikatakan bahwa batasan utama dalam pengoperasian solusi ini adalah kecepatan I/O perangkat disk di penyimpanan email. Memang, pada saat beberapa ratus karyawan suatu perusahaan mengakses penyimpanan email yang sama secara bersamaan, lebar saluran untuk menulis dan membaca informasi dari hard drive mungkin tidak cukup untuk pengoperasian layanan yang responsif. Dan jika untuk instalasi kecil Zimbra hal ini tidak menjadi masalah khusus, maka dalam kasus perusahaan besar dan penyedia SaaS, semua ini dapat menyebabkan email tidak responsif dan, sebagai akibatnya, penurunan efisiensi karyawan, serta pelanggaran. dari SLA. Oleh karena itu, ketika merancang dan mengoperasikan instalasi Zimbra skala besar, perhatian khusus harus diberikan untuk mengoptimalkan kinerja hard drive dalam penyimpanan email. Mari kita lihat dua kasus dan mencoba mencari tahu metode apa untuk mengoptimalkan beban penyimpanan disk yang dapat diterapkan di masing-masing kasus.

Mengoptimalkan penyimpanan email di Zimbra Collaboration Suite

1. Optimasi saat mendesain instalasi Zimbra skala besar

Selama tahap desain instalasi Zimbra dengan beban tinggi, administrator harus membuat pilihan tentang sistem penyimpanan mana yang akan digunakan. Untuk mengatasi masalah ini, Anda harus mengetahui bahwa beban utama pada hard drive berasal dari DBMS MariaDB yang disertakan dalam Zimbra Collaboration Suite, mesin pencari Apache Lucene, dan penyimpanan blob. Oleh karena itu, untuk mengoperasikan produk perangkat lunak ini dalam kondisi beban tinggi, perlu menggunakan peralatan berkecepatan tinggi dan andal.

Dalam kondisi normal, Zimbra dapat diinstal pada RAID hard drive dan pada penyimpanan yang terhubung melalui protokol NFS. Untuk instalasi yang sangat kecil, Anda dapat menginstal Zimbra pada drive SATA biasa. Namun, dalam konteks instalasi besar, semua teknologi ini menunjukkan berbagai kelemahan dalam bentuk berkurangnya kecepatan perekaman atau keandalan yang rendah, yang tidak dapat diterima baik oleh perusahaan besar maupun, terutama bagi penyedia SaaS.

Inilah sebabnya mengapa dalam infrastruktur Zimbra skala besar yang terbaik adalah menggunakan SAN. Teknologi inilah yang saat ini mampu memberikan throughput terbesar untuk perangkat penyimpanan dan pada saat yang sama, berkat kemampuan untuk menghubungkan cache dalam jumlah besar, penggunaannya praktis tidak menimbulkan risiko yang berarti bagi perusahaan. Sebaiknya gunakan NVRAM, yang digunakan di banyak SAN untuk mempercepat proses penulisan. Namun lebih baik menonaktifkan caching data yang direkam pada disk itu sendiri, karena dapat menyebabkan kerusakan yang tidak dapat diperbaiki pada media dan hilangnya data jika terjadi masalah daya.

Sedangkan untuk memilih sistem file, pilihan terbaik adalah menggunakan Linux standar Ext3/Ext4. Nuansa utama yang terkait dengan sistem file adalah ia harus dipasang dengan parameter -tidak ada waktu. Opsi ini akan menonaktifkan fungsi pencatatan waktu akses terakhir ke file, yang berarti akan sangat mengurangi beban membaca dan menulis. Secara umum, saat membuat sistem file ext3 atau ext4 untuk Zimbra, Anda harus menggunakan parameter utilitas berikut mke2fs:

-j β€” Untuk membuat jurnal sistem file Buat sistem file dengan jurnal ext3/ext4.
-NAMA - Untuk membuat nama volume untuk kemudian digunakan di /etc/fstab
-O dir_index - Untuk menggunakan pohon pencarian hash untuk mempercepat pencarian file di direktori besar
-m 2 β€” Untuk mencadangkan 2% volume dalam sistem file besar untuk direktori root
-Ukuran J=400 β€” Untuk membuat majalah besar
-b 4096 β€” Untuk menentukan ukuran blok dalam byte
-aku 10240 - Untuk penyimpanan pesan, pengaturan ini harus sesuai dengan ukuran pesan rata-rata. Anda harus memperhatikan parameter ini karena nilainya tidak dapat diubah nanti.

Disarankan juga untuk mengaktifkannya dirsync untuk penyimpanan blob, penyimpanan metadata pencarian Lucene, dan penyimpanan antrean MTA. Ini harus dilakukan karena Zimbra biasanya menggunakan utilitas tersebut fsync untuk jaminan penulisan blob dengan data ke disk. Namun, ketika penyimpanan email Zimbra atau MTA membuat file baru selama pengiriman pesan, perubahan yang terjadi di folder terkait perlu ditulis ke disk. Itu sebabnya, meskipun file telah ditulis ke disk menggunakan fsync, catatan penambahannya ke direktori mungkin tidak sempat ditulis ke disk dan, akibatnya, mungkin hilang karena kegagalan server yang tiba-tiba. Berkat penggunaannya dirsync permasalahan-permasalahan tersebut dapat dihindari.

2. Optimasi dengan infrastruktur Zimbra yang berjalan

Sering terjadi setelah beberapa tahun menggunakan Zimbra, jumlah penggunanya meningkat secara signifikan dan layanan menjadi semakin tidak responsif setiap harinya. Jalan keluar dari situasi ini jelas: Anda hanya perlu menambahkan server baru ke infrastruktur agar layanan dapat berfungsi kembali secepat sebelumnya. Sementara itu, tidak selalu mungkin untuk segera menambahkan server baru ke infrastruktur guna meningkatkan kinerjanya. Manajer TI sering kali harus menghabiskan waktu lama untuk mengoordinasikan pembelian server baru dengan departemen akuntansi atau keamanan; selain itu, mereka sering kali dikecewakan oleh pemasok yang terlambat mengirimkan server baru atau bahkan mengirimkan barang yang salah.

Tentu saja, yang terbaik adalah membangun infrastruktur Zimbra Anda dengan cadangan agar selalu memiliki cadangan untuk ekspansi dan tidak bergantung pada siapa pun, namun jika kesalahan telah terjadi, manajer TI hanya dapat memuluskan konsekuensinya sebagai sebanyak mungkin. Misalnya, seorang manajer TI dapat mencapai sedikit peningkatan produktivitas dengan menonaktifkan sementara layanan sistem Linux yang secara teratur mengakses hard drive selama pengoperasian dan oleh karena itu dapat berdampak negatif terhadap kinerja Zimbra. Jadi, Anda dapat menonaktifkan sementara:

autofs, netfs - Layanan Penemuan Sistem File Jarak Jauh
cangkir β€” Layanan cetak
xinetd, vsftpd - Layanan *NIX bawaan yang mungkin tidak Anda perlukan
peta port, rpcsvcgssd, rpcgssd, rpcidmapd β€” Layanan panggilan prosedur jarak jauh, yang biasanya digunakan bersama dengan sistem file jaringan
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap β€” Duplikat utilitas utama yang disertakan dalam Zimbra Collaboration Suite
slokasi/updatedb - Karena Zimbra menyimpan setiap pesan dalam file terpisah, menjalankan layanan updateb setiap hari dapat menyebabkan masalah, dan oleh karena itu dimungkinkan untuk melakukannya secara manual dengan beban paling sedikit di server

Penghematan sumber daya sistem akibat penonaktifan layanan ini tidak akan terlalu signifikan, namun hal ini pun bisa sangat berguna dalam kondisi yang mendekati force majeure. Setelah server baru ditambahkan ke infrastruktur Zimbra, disarankan untuk mengaktifkan kembali layanan yang sebelumnya dinonaktifkan.

Anda juga dapat mengoptimalkan pengoperasian Zimbra dengan memindahkan layanan syslog ke server terpisah sehingga selama pengoperasian tidak memuat hard drive penyimpanan email. Hampir semua komputer cocok untuk tujuan ini, bahkan Raspberry Pi papan tunggal yang murah.

Sumber: www.habr.com

Tambah komentar