In one of our in Infrastructure Planning for Enterprise Implementation of the Zimbra Collabortion Suite, it was said that the main limitation for this solution is the I/O speed of disk devices in mail stores. Indeed, at a time when several hundred employees of the enterprise simultaneously access the same mail storage, the bandwidth for writing and reading information from hard drives may not be enough for the responsive operation of the service. And if for small installations of Zimbra this will not be a particular problem, then in the case of large enterprises and SaaS providers, all this can lead to unresponsive email and, as a result, a decrease in employee efficiency, as well as violation of SLA. That is why when designing and operating large-scale Zimbra installations, special attention should be paid to the issue of optimizing the operation of hard drives in mail storage. Let's look at two cases and try to find out what methods of optimizing the load on disk storage can be applied in each of them.
1. Optimization when designing a large-scale Zimbra installation
During the design phase of a highly loaded Zimbra installation, its administrator will have to make a choice which storage system to use. In order to determine this issue, you should know that the main load on hard drives is created by the MariaDB DBMS included in the Zimbra Collaboration Suite, the Apache Lucene search system, and blob storage. That is why for the work of these software products in conditions of high loads it is necessary to use high-speed and reliable equipment.
Under normal conditions, Zimbra can be installed both on RAID from hard drives and on NFS-connected storages. In cases of very small installations, you can install Zimbra on a regular SATA drive. However, in the conditions of large installations, all these technologies show various disadvantages in the form of reduced write speed or low reliability, which is unacceptable either for large enterprises or, even more so, for SaaS providers.
That is why, in conditions of large-scale infrastructures, Zimbra is best to use SAN. It is she who is currently able to provide the greatest bandwidth for storage devices, and at the same time, due to the ability to connect a large amount of cache, its use practically does not carry any significant risks for the enterprise. It's a good idea to use NVRAM, which is used in many SANs to speed up write times. But it is better to disable caching of write data on the disks themselves, as it can lead to irreparable damage to media and data loss in case of power problems.
As for the choice of file system, the best choice would be to use the standard for Linux Ext3/Ext4. The main nuance associated with the file system is that it should be mounted with the parameter -noatime. This option will disable the function of fixing the time of the last access to files, which means that it will greatly reduce the load on reading and writing. In general, when creating an ext3 or ext4 file system for Zimbra, you should use the following utility parameters wife2fs:
-j - Create the file system with an ext3/ext4 journal.
-L NAME - To create a volume name, then to use it in /etc/fstab
-O dir_index - To use a hashed search tree to speed up the search for files in large directories
-m 2 - To reserve 2% of the volume in large file systems under the root directory
-Jsize=400 - To create a large magazine
-b 4096 - To determine the block size in bytes
-i 10240 - For the message store, this setting should match the average message size. You should carefully consider this parameter, since later its value cannot be changed.
In addition, it is recommended to enable dirsync for blob storage, Lucene search metadata storage, and MTA queue storage. This should be done for the reason that Zimbra usually uses the utility fsync to ensure that the data blob is written to disk. However, when the Zimbra mail store or MTA creates new files during message delivery, it becomes necessary to write to disk the changes that have occurred in the corresponding folders. That is why, even in the case when the file is already written to disk using fsync, the record of adding it to the directory may not have time to be written to disk and, as a result, may be lost due to a sudden server failure. Through the use dirsync these problems can be avoided.
2. Optimization with a running Zimbra infrastructure
It often happens that after several years of using Zimbra, the number of its users increases significantly and the service becomes less and less responsive every day. The way out of this situation is obvious: you just need to add new servers to the infrastructure so that the service again works as fast as before. Meanwhile, it is far from always possible to immediately add new servers to the infrastructure in order to increase its performance. Often, IT managers have to coordinate the purchase of new servers with the accounting department or the security department for a long time, in addition, suppliers often fail, who can bring a new server late or deliver the wrong thing at all.
Of course, it is best to build your Zimbra infrastructure with a margin so that you always have a margin for its expansion and do not depend on anyone, but if a mistake has already been made, the IT manager can only mitigate its consequences as much as possible. So, for example, an IT manager can achieve a small performance boost by temporarily disabling Linux system services that regularly access hard drives during operation and, as a result, can negatively affect the speed of Zimbra. So, for a while you can disable:
autofs, netfs - Services for detecting remote file systems
cups - Print Service
xinetd, vsftpd - Built-in *NIX services that you probably won't need
portmap, rpcsvcgssd, rpcgssd, rpcidmapd - Remote procedure call services that are commonly used in conjunction with network file systems
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap - Duplicates of the main utilities included in the Zimbra Collaboration Suite
slocate/updatedb - Since Zimbra stores each message in a separate file, running the updatedb service daily can cause problems, and therefore it is possible to do this manually during the least load on the servers
Saving system resources as a result of disabling these services will not be very significant, but even this can be very useful in conditions close to force majeure. After the new server is added to the Zimbra infrastructure, it is recommended to re-enable previously disabled services.
You can also optimize Zimbra by moving the syslog service to a separate server so that it does not load the mail storage hard drives during operation. For these purposes, almost any computer is suitable, up to a cheap single-board Raspberry Pi.
Source: habr.com