Оптимизация Хранения Почты В Zimbra Collaboration Suite

В одном из наших предыдущие статьи , посвященный планированию инфраструктуры при внедрении Zimbra Collabortion Suite на предприятии, было сказано, что основным ограничением в работе этого решения является скорость ввода-вывода дисковых устройств в почтовых хранилищах.

Ведь в то время, когда к одному и тому же почтовому хранилищу одновременно обращаются несколько сотен сотрудников предприятия, ширины канала записи и чтения информации с жестких дисков может не хватить для отзывчивой работы сервиса.

И если для небольших установок Zimbra это не будет особой проблемой, то в случае крупных предприятий и SaaS-провайдеров все это может привести к неотвечанию электронной почты и, как следствие, снижению эффективности работы сотрудников, а также нарушению правил.

соглашений об уровне обслуживания.

Именно поэтому при проектировании и эксплуатации масштабных установок Zimbra особое внимание следует уделять оптимизации производительности жестких дисков в хранилище почты.

Давайте рассмотрим два случая и попробуем выяснить, какие методы оптимизации нагрузки на дисковое хранилище можно применить в каждом из них.

Оптимизация хранения почты в Zimbra Collaboration Suite

1. Оптимизация при проектировании масштабной установки Zimbra На этапе проектирования установки Zimbra с высокой нагрузкой администратору придется сделать выбор, какую систему хранения использовать.

Чтобы определиться с этим вопросом, следует знать, что основная нагрузка на жесткие диски приходится на СУБД MariaDB, входящую в состав Zimbra Collaboration Suite, поисковую систему Apache Lucene и хранилище BLOB-объектов.

Именно поэтому для работы данных программных продуктов в условиях высокой нагрузки необходимо использовать быстродействующее и надежное оборудование.

В обычных условиях Zimbra можно установить как на RAID жестких дисков, так и на хранилище, подключенное по протоколу NFS. Для очень небольших установок вы можете установить Zimbra на обычный диск SATA. Однако в условиях крупных установок все эти технологии демонстрируют различные недостатки в виде пониженной скорости записи или низкой надежности, что неприемлемо ни для крупных предприятий, ни, тем более, для SaaS-провайдеров.

Вот почему в крупномасштабных инфраструктурах Zimbra лучше всего использовать SAN. Именно эта технология на данный момент способна обеспечить наибольшую пропускную способность для устройств хранения данных и при этом, благодаря возможности подключения большого объема кэша, ее использование практически не несет существенных рисков для предприятия.

Рекомендуется использовать NVRAM, которая используется во многих сетях SAN для ускорения записи.

Но лучше отключить кэширование записанных данных на самих дисках, так как это может привести к непоправимой порче носителя и потере данных при возникновении проблем с питанием.

Что касается выбора файловой системы, то лучшим выбором будет использование стандартного Linux Ext3/Ext4. Главный нюанс, связанный с файловой системой, заключается в том, что ее следует монтировать с параметром -нет времени .

Данная опция отключит функцию записи времени последнего доступа к файлам, а значит, значительно снизит нагрузку на чтение и запись.

В общем, при создании файловой системы ext3 или ext4 для Zimbra следует использовать следующие параметры утилиты: mke2fs :

-j — Для создания журнала файловой системы.
Создайте файловую систему с журналом ext3/ext4. -L ИМЯ - Чтобы создать имя тома для последующего использования в /etc/fstab -O индекс_каталога - Использовать хешированное дерево поиска для ускорения поиска файлов в больших каталогах.
-м 2 — Чтобы зарезервировать 2% объема в больших файловых системах для корневого каталога.
-Размер J = 400 — Создать большой журнал -б 4096 — Определить размер блока в байтах -я 10240 - Для хранения сообщений эта настройка должна соответствовать среднему размеру сообщения.
На этот параметр следует обратить пристальное внимание, так как его значение в дальнейшем изменить невозможно.

Также рекомендуется включить дирсинк для хранилища BLOB-объектов, хранилища метаданных поиска Lucene и хранилища очередей MTA. Это следует сделать, поскольку Zimbra обычно использует утилиту fsync для гарантированной записи блоба с данными на диск.

Однако когда почтовое хранилище Zimbra или MTA создают новые файлы во время доставки сообщения, возникает необходимость записать на диск изменения, происходящие в соответствующих папках.

Именно поэтому, даже если файл уже был записан на диск с помощью fsync , запись о его добавлении в каталог может не успеть записаться на диск и, как следствие, быть утеряна из-за внезапного сбоя сервера.

Благодаря использованию дирсинк этих проблем можно избежать.

2. Оптимизация с работающей инфраструктурой Zimbra. Часто бывает, что после нескольких лет использования Zimbra количество ее пользователей значительно увеличивается и сервис с каждым днем становится все менее отзывчивым.

Выход из этой ситуации очевиден: нужно просто добавить в инфраструктуру новые серверы, чтобы сервис снова работал так же быстро, как и раньше.

Между тем, не всегда есть возможность сразу добавлять в инфраструктуру новые серверы с целью повышения ее производительности.

ИТ-менеджерам часто приходится тратить длительное время на согласование покупки новых серверов с отделом бухгалтерии или безопасности; кроме того, их часто подводят поставщики, которые могут доставить новый сервер с опозданием или даже поставить не то.

Конечно, лучше всего строить свою инфраструктуру Zimbra с запасом, чтобы всегда иметь резерв на ее расширение и ни от кого не зависеть, однако, если ошибка уже была допущена, ИТ-менеджеру остается лишь сгладить ее последствия, поскольку как можно больше.

Например, ИТ-менеджер может добиться небольшого повышения производительности, временно отключив системные службы Linux, которые регулярно обращаются к жестким дискам во время работы и, следовательно, могут негативно повлиять на производительность Zimbra. Итак, вы можете временно отключить:

автофс, нетфс - Службы удаленного обнаружения файловой системы чашки — Услуги печати ксинетд, vsftpd - Встроенные службы *NIX, которые вам, вероятно, не понадобятся.
карта портов, rpcsvcgssd, rpcgssd, rpcidmapd — Службы удаленного вызова процедур, которые обычно используются совместно с сетевыми файловыми системами.
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Дубликаты основных утилит, входящих в состав Zimbra Collaboration Suite. slocate/updatedb - Поскольку Zimbra хранит каждое сообщение в отдельном файле, ежедневный запуск службы updateb может вызвать проблемы, в связи с чем есть возможность делать это вручную при минимальной нагрузке на серверы.

Экономия системных ресурсов в результате отключения этих служб будет не слишком существенной, но даже это может оказаться весьма полезным в условиях, близких к форс-мажорным обстоятельствам.

После добавления нового сервера в инфраструктуру Zimbra рекомендуется повторно включить ранее отключенные службы.

Также можно оптимизировать работу Zimbra, вынеся службу системного журнала на отдельный сервер, чтобы во время работы она не нагружала жесткие диски почтовых хранилищ.

Для этих целей подойдет практически любой компьютер, даже дешевый одноплатный Raspberry Pi. По всем вопросам, связанным с Zextras Suite, вы можете связаться с представителем Zextras Екатериной Триандафилиди по электронной почте [email protected]. Теги: #linux #оптимизация сервера #системное администрирование #оптимизация #электронная почта #zimbra #groupware