Dalam salah satu daripada kami , khusus untuk perancangan infrastruktur apabila melaksanakan Zimbra Collabortion Suite dalam perusahaan, dikatakan bahawa had utama dalam pengendalian penyelesaian ini ialah kelajuan I/O peranti cakera dalam storan mel. Sesungguhnya, pada masa beberapa ratus pekerja sebuah perusahaan mengakses storan mel yang sama secara serentak, lebar saluran untuk menulis dan membaca maklumat daripada cakera keras mungkin tidak mencukupi untuk operasi responsif perkhidmatan tersebut. Dan jika untuk pemasangan kecil Zimbra ini tidak akan menjadi masalah tertentu, maka dalam kes perusahaan besar dan penyedia SaaS, semua ini boleh menyebabkan e-mel tidak responsif dan, akibatnya, penurunan kecekapan pekerja, serta pelanggaran daripada SLA. Itulah sebabnya, apabila mereka bentuk dan mengendalikan pemasangan Zimbra berskala besar, perhatian khusus harus diberikan untuk mengoptimumkan prestasi cakera keras dalam storan mel. Mari kita lihat dua kes dan cuba cari kaedah untuk mengoptimumkan beban pada storan cakera yang boleh digunakan dalam setiap daripadanya.
1. Pengoptimuman apabila mereka bentuk pemasangan Zimbra berskala besar
Semasa fasa reka bentuk pemasangan Zimbra beban tinggi, pentadbir perlu membuat pilihan tentang sistem storan yang hendak digunakan. Untuk memutuskan isu ini, anda harus tahu bahawa beban utama pada cakera keras datang daripada DBMS MariaDB yang disertakan dalam Zimbra Collaboration Suite, enjin carian Apache Lucene dan storan gumpalan. Itulah sebabnya untuk mengendalikan produk perisian ini dalam keadaan beban tinggi, perlu menggunakan peralatan berkelajuan tinggi dan boleh dipercayai.
Di bawah keadaan biasa, Zimbra boleh dipasang pada RAID pemacu keras dan pada storan yang disambungkan melalui protokol NFS. Untuk pemasangan yang sangat kecil, anda boleh memasang Zimbra pada pemacu SATA biasa. Walau bagaimanapun, dalam konteks pemasangan besar, semua teknologi ini menunjukkan pelbagai kelemahan dalam bentuk kelajuan rakaman yang dikurangkan atau kebolehpercayaan yang rendah, yang tidak boleh diterima baik untuk perusahaan besar mahupun, terutamanya untuk penyedia SaaS.
Inilah sebabnya mengapa dalam infrastruktur Zimbra berskala besar adalah yang terbaik untuk menggunakan SAN. Teknologi inilah yang pada masa ini mampu memberikan daya pemprosesan terbesar untuk peranti storan dan pada masa yang sama, terima kasih kepada keupayaan untuk menyambungkan sejumlah besar cache, penggunaannya secara praktikal tidak menimbulkan sebarang risiko yang ketara untuk perusahaan. Adalah idea yang baik untuk menggunakan NVRAM, yang digunakan dalam banyak SAN untuk mempercepatkan perkara semasa penulisan. Tetapi adalah lebih baik untuk melumpuhkan caching data yang dirakam pada cakera itu sendiri, kerana ia boleh membawa kepada kerosakan yang tidak boleh diperbaiki pada media dan kehilangan data jika masalah kuasa berlaku.
Bagi memilih sistem fail, pilihan terbaik ialah menggunakan Linux Ext3/Ext4 standard. Nuansa utama yang dikaitkan dengan sistem fail ialah ia harus dipasang dengan parameter -notime. Pilihan ini akan melumpuhkan fungsi merakam masa akses terakhir kepada fail, yang bermaksud ia akan mengurangkan beban membaca dan menulis dengan banyak. Secara umum, apabila mencipta sistem fail ext3 atau ext4 untuk Zimbra, anda harus menggunakan parameter utiliti berikut mke2fs:
-j β Untuk mencipta jurnal sistem fail. Cipta sistem fail dengan jurnal ext3/ext4.
-L NAMA - Untuk mencipta nama volum untuk kemudian digunakan dalam /etc/fstab
-Wahai dir_index - Untuk menggunakan pepohon carian dicincang untuk mempercepatkan carian fail dalam direktori besar
-m 2 β Untuk menyimpan 2% daripada volum dalam sistem fail besar untuk direktori akar
-Saiz J=400 - Untuk mencipta majalah besar
-b 4096 β Untuk menentukan saiz blok dalam bait
-saya 10240 - Untuk storan mesej, tetapan ini harus sepadan dengan purata saiz mesej. Anda harus memberi perhatian kepada parameter ini, kerana nilainya tidak boleh diubah kemudian.
Ia juga disyorkan untuk membolehkan dirsync untuk storan gumpalan, storan metadata carian Lucene dan storan baris gilir MTA. Ini harus dilakukan kerana Zimbra biasanya menggunakan utiliti fsync untuk menjamin penulisan gumpalan dengan data ke cakera. Walau bagaimanapun, apabila stor mel Zimbra atau MTA mencipta fail baharu semasa penghantaran mesej, ia menjadi perlu untuk menulis kepada cakera perubahan yang berlaku dalam folder yang sepadan. Itulah sebabnya, walaupun fail itu telah ditulis ke cakera menggunakan fsync, rekod penambahannya pada direktori mungkin tidak mempunyai masa untuk ditulis pada cakera dan, akibatnya, mungkin hilang disebabkan kegagalan pelayan secara tiba-tiba. Terima kasih kepada penggunaan dirsync masalah ini dapat dielakkan.
2. Pengoptimuman dengan infrastruktur Zimbra berjalan
Ia sering berlaku bahawa selepas beberapa tahun menggunakan Zimbra, bilangan penggunanya meningkat dengan ketara dan perkhidmatan menjadi kurang responsif setiap hari. Jalan keluar dari situasi ini adalah jelas: anda hanya perlu menambah pelayan baharu pada infrastruktur supaya perkhidmatan itu berfungsi semula secepat sebelumnya. Sementara itu, tidak selalu mungkin untuk menambah pelayan baharu pada infrastruktur dengan segera untuk meningkatkan prestasinya. Pengurus IT selalunya perlu menghabiskan masa yang lama untuk menyelaraskan pembelian pelayan baharu dengan jabatan perakaunan atau keselamatan; di samping itu, mereka sering dikecewakan oleh pembekal yang boleh menghantar pelayan baharu lewat atau menghantar perkara yang salah.
Sudah tentu, adalah yang terbaik untuk membina infrastruktur Zimbra anda dengan rizab agar sentiasa mempunyai rizab untuk pengembangannya dan tidak bergantung kepada sesiapa, namun, jika kesilapan telah dilakukan, pengurus IT hanya boleh melancarkan akibatnya sebagai sebanyak mungkin. Sebagai contoh, pengurus IT boleh mencapai peningkatan produktiviti yang kecil dengan melumpuhkan sementara perkhidmatan sistem Linux yang kerap mengakses cakera keras semasa operasi dan oleh itu boleh memberi kesan negatif kepada prestasi Zimbra. Jadi, anda boleh melumpuhkan buat sementara waktu:
autofs, netfs - Perkhidmatan Penemuan Sistem Fail Jauh
cawan β Perkhidmatan cetak
xinetd, vsftpd - Perkhidmatan *NIX terbina dalam yang mungkin anda tidak perlukan
portmap, rpcsvcgssd, rpcgssd, rpcidmapd β Perkhidmatan panggilan prosedur jauh, yang biasanya digunakan bersama dengan sistem fail rangkaian
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap β Pendua utiliti utama yang disertakan dalam Suite Kolaborasi Zimbra
slocate/updatedb - Memandangkan Zimbra menyimpan setiap mesej dalam fail berasingan, menjalankan perkhidmatan updatedb setiap hari boleh menyebabkan masalah, dan oleh itu adalah mungkin untuk melakukan ini secara manual semasa memuatkan paling sedikit pada pelayan
Menjimatkan sumber sistem akibat daripada melumpuhkan perkhidmatan ini tidak akan menjadi sangat penting, tetapi ini juga boleh menjadi sangat berguna dalam keadaan yang hampir dengan force majeure. Setelah pelayan baharu ditambahkan pada infrastruktur Zimbra, adalah disyorkan untuk mendayakan semula perkhidmatan yang dilumpuhkan sebelum ini.
Anda juga boleh mengoptimumkan operasi Zimbra dengan mengalihkan perkhidmatan syslog ke pelayan yang berasingan supaya semasa operasi ia tidak memuatkan cakera keras storan mel. Hampir mana-mana komputer sesuai untuk tujuan ini, malah Raspberry Pi papan tunggal yang murah.
Sumber: www.habr.com