В одной из наших предыдущих статей, посвященной планированию инфраструктуры при внедрении на предприятии Zimbra Collabortion Suite, было сказано, что главным ограничением при работе этого решения является скорость ввода-вывода дисковых устройств в почтовых хранилищах. И действительно, в то время, когда несколько сотен работников предприятия одновременно обращаются к одному и тому же почтовому хранилищу, ширины канала для записи и чтения информации с жестких дисков может не хватать для отзывчивой работы сервиса. И если для небольших установок Zimbra это не станет особой проблемой, то в случае с крупными предприятиями и SaaS-провайдерами все это может привести к неотзывчивой работе электронной почты и, как следствие, снижению эффективности сотрудников, а также к нарушению SLA. Именно поэтому при проектировании и эксплуатации масштабных установок Zimbra следует уделить особое внимание вопросу оптимизации работы жестких дисков в почтовом хранилище. Давайте рассмотрим два кейса и попробуем выяснить, какие методы оптимизации нагрузки на дисковые хранилища можно применить в каждом из них.
1. Оптимизация при проектировании масштабной установки Zimbra
На этапе проектирования высоконагруженной установки Zimbra её администратору предстоит сделать выбор, какую систему хранения данных использовать. Для того, чтобы определиться с этим вопросом, следует знать, что основную нагрузку на жесткие диски создают входящие в состав Zimbra Collaboration Suite СУБД MariaDB, система поиска Apache Lucene, а также хранилище BLOB-объектов. Именно поэтому для работы этих программных продуктов в условиях высоких нагрузок необходимо использовать скоростное и надежное оборудование.
В обычных условиях Zimbra можно установить как на RAID из жестких дисков, так и на хранилища, соединенные по протоколу NFS. В случаях совсем небольших установок можно установить Zimbra на обычный SATA-диск. Однако в условиях крупных установок все эти технологии демонстрируют различные недостатки в виде пониженной скорости записи или низкой надежности, что неприемлемо ни для крупных предприятий, ни, тем более, для SaaS-провайдеров.
Именно поэтому в условиях масштабных инфраструктур Zimbra лучше всего будет использовать SAN. Именно она на данный момент способна обеспечить наибольшую пропускную способность для устройств хранения и при этом, благодаря возможности подключения большого количества кэша, ее использование практически не несет в себе каких-либо существенных рисков для предприятия. Хорошей идеей станет использование NVRAM, которая используется во многих SAN для ускорения работы во время записи. А вот кэширование записываемых данных на самих дисках лучше отключить, так как оно может привести к непоправимым повреждениям носителей и потере данных при возникновении проблем с питанием.
Что касается выбора файловой системы, то оптимальным выбором станет использование стандартных для Linux Ext3/Ext4. Главный нюанс, связанный с файловой системой заключается в том, что монтировать ее следует с параметром -noatime. Этот параметр отключит функцию фиксирования времени последнего обращения к файлам, а значит сильно сократит нагрузку на чтение и запись. В целом же при создании файловой системы ext3 или ext4 для Zimbra следует использовать следующие параметры утилиты mke2fs:
Кроме того рекомендуется включить dirsync для хранилища BLOB-объектов, хранилища мета-данных поиска Lucene и хранилища очереди MTA. Делать это следует по той причине, что обычно Zimbra использует утилиту fsync для гарантированной записи блоба с данными на диск. Однако когда почтовое хранилище Zimbra или MTA создают новые файлы во время доставки сообщений, возникает необходимость записи на диск изменений, произошедших в соответствующих папках. Именно поэтому даже в случае когда файл уже записан на диск при помощи fsync, запись о его добавлении в директории может не успеть записаться на диск и в результате может быть потеряна из-за внезапного отказа сервера. Благодаря использованию dirsync этих проблем можно избежать.
2. Оптимизация при работающей инфраструктуре Zimbra
Часто бывает так, что после нескольких лет эксплуатации Zimbra число её пользователей значительно возрастает и работа сервиса становится с каждым днем все менее и менее отзывчивой. Выход из такой ситуации очевиден: нужно просто добавить новые серверы в инфраструктуру, чтобы сервис вновь работал так же быстро, как и раньше. Меж тем, далеко не всегда имеется возможность сразу добавить в инфраструктуру новые серверы, чтобы повысить ее быстродействие. Зачастую ИТ-менеджерам приходится подолгу согласовывать приобретение новых серверов с бухгалтерией или отделом безопасности, кроме того, нередко подводят поставщики, которые могут привезти новый сервер с опозданием или вовсе доставить не то, что нужно.
Разумеется, что лучше всего строить свою инфраструктуру Zimbra с запасом, чтобы всегда иметь запас для её расширения и ни от кого при этом не зависеть, однако если ошибка уже совершена, ИТ-менеджеру остается только максимально сгладить ее последствия. Так, например, ИТ-менеджер может добиться небольшого роста производительности, используя временное отключение системных служб Linux, которые при работе регулярно обращаются к жестким дискам и вследствие этого могут негативно повлиять на скорость работы Zimbra. Так, на время можно отключить:
Экономия системных ресурсов в результате отключения данных сервисов получится не очень существенной, но даже это может сильно пригодиться в условиях близких к форс-мажорным. После того как новый сервер будет добавлен в инфраструктуру Zimbra, рекомендуется вновь включить отключенные ранее службы.
Также можно оптимизировать работу Zimbra за счет выноса службы syslog на отдельный сервер, чтобы во время работы она не нагружала жесткие диски почтовых хранилищ. Для этих целей подойдет практически любой компьютер, вплоть до дешевого одноплатника Raspberry Pi.
1. Оптимизация при проектировании масштабной установки Zimbra
На этапе проектирования высоконагруженной установки Zimbra её администратору предстоит сделать выбор, какую систему хранения данных использовать. Для того, чтобы определиться с этим вопросом, следует знать, что основную нагрузку на жесткие диски создают входящие в состав Zimbra Collaboration Suite СУБД MariaDB, система поиска Apache Lucene, а также хранилище BLOB-объектов. Именно поэтому для работы этих программных продуктов в условиях высоких нагрузок необходимо использовать скоростное и надежное оборудование.
В обычных условиях Zimbra можно установить как на RAID из жестких дисков, так и на хранилища, соединенные по протоколу NFS. В случаях совсем небольших установок можно установить Zimbra на обычный SATA-диск. Однако в условиях крупных установок все эти технологии демонстрируют различные недостатки в виде пониженной скорости записи или низкой надежности, что неприемлемо ни для крупных предприятий, ни, тем более, для SaaS-провайдеров.
Именно поэтому в условиях масштабных инфраструктур Zimbra лучше всего будет использовать SAN. Именно она на данный момент способна обеспечить наибольшую пропускную способность для устройств хранения и при этом, благодаря возможности подключения большого количества кэша, ее использование практически не несет в себе каких-либо существенных рисков для предприятия. Хорошей идеей станет использование NVRAM, которая используется во многих SAN для ускорения работы во время записи. А вот кэширование записываемых данных на самих дисках лучше отключить, так как оно может привести к непоправимым повреждениям носителей и потере данных при возникновении проблем с питанием.
Что касается выбора файловой системы, то оптимальным выбором станет использование стандартных для Linux Ext3/Ext4. Главный нюанс, связанный с файловой системой заключается в том, что монтировать ее следует с параметром -noatime. Этот параметр отключит функцию фиксирования времени последнего обращения к файлам, а значит сильно сократит нагрузку на чтение и запись. В целом же при создании файловой системы ext3 или ext4 для Zimbra следует использовать следующие параметры утилиты mke2fs:
-j — Для создания журнала файловой системыCreate the file system with an ext3/ext4 journal.
-L НАЗВАНИЕ — Для создания названия тома, чтобы затем использовать его в /etc/fstab
-O dir_index — Для использования хешированного дерева поиска для ускорения работы поиска файлов в больших директориях
-m 2 — Для резервирования 2% объема в больших файловых системах под корневой каталог
-J size=400 — Для создания большого журнала
-b 4096 — Для определения размера блока в байтах
-i 10240 — Для хранилища сообщений этот параметр должен соответствовать среднему размеру сообщений. Следует внимательно отнестись к этому параметру, так как впоследствии его значение нельзя будет изменить
Кроме того рекомендуется включить dirsync для хранилища BLOB-объектов, хранилища мета-данных поиска Lucene и хранилища очереди MTA. Делать это следует по той причине, что обычно Zimbra использует утилиту fsync для гарантированной записи блоба с данными на диск. Однако когда почтовое хранилище Zimbra или MTA создают новые файлы во время доставки сообщений, возникает необходимость записи на диск изменений, произошедших в соответствующих папках. Именно поэтому даже в случае когда файл уже записан на диск при помощи fsync, запись о его добавлении в директории может не успеть записаться на диск и в результате может быть потеряна из-за внезапного отказа сервера. Благодаря использованию dirsync этих проблем можно избежать.
2. Оптимизация при работающей инфраструктуре Zimbra
Часто бывает так, что после нескольких лет эксплуатации Zimbra число её пользователей значительно возрастает и работа сервиса становится с каждым днем все менее и менее отзывчивой. Выход из такой ситуации очевиден: нужно просто добавить новые серверы в инфраструктуру, чтобы сервис вновь работал так же быстро, как и раньше. Меж тем, далеко не всегда имеется возможность сразу добавить в инфраструктуру новые серверы, чтобы повысить ее быстродействие. Зачастую ИТ-менеджерам приходится подолгу согласовывать приобретение новых серверов с бухгалтерией или отделом безопасности, кроме того, нередко подводят поставщики, которые могут привезти новый сервер с опозданием или вовсе доставить не то, что нужно.
Разумеется, что лучше всего строить свою инфраструктуру Zimbra с запасом, чтобы всегда иметь запас для её расширения и ни от кого при этом не зависеть, однако если ошибка уже совершена, ИТ-менеджеру остается только максимально сгладить ее последствия. Так, например, ИТ-менеджер может добиться небольшого роста производительности, используя временное отключение системных служб Linux, которые при работе регулярно обращаются к жестким дискам и вследствие этого могут негативно повлиять на скорость работы Zimbra. Так, на время можно отключить:
autofs, netfs — Службы обнаружения удаленных файловых систем
cups — Служба печати
xinetd, vsftpd — Встроенные службы *NIX, которые скорее всего вам не понадобятся
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Службы удаленного вызова процедур, которые обычно используются в связке с сетевыми файловыми системами
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Дубликаты основных утилит, входящих в состав Zimbra Collaboration Suite
slocate/updatedb — Поскольку Zimbra хранит каждое сообщение в отдельном файле, ежедневный запуск службы updatedb может привести к появлению проблем, и поэтому можно делать это вручную во время наименьшей нагрузки на серверы
Экономия системных ресурсов в результате отключения данных сервисов получится не очень существенной, но даже это может сильно пригодиться в условиях близких к форс-мажорным. После того как новый сервер будет добавлен в инфраструктуру Zimbra, рекомендуется вновь включить отключенные ранее службы.
Также можно оптимизировать работу Zimbra за счет выноса службы syslog на отдельный сервер, чтобы во время работы она не нагружала жесткие диски почтовых хранилищ. Для этих целей подойдет практически любой компьютер, вплоть до дешевого одноплатника Raspberry Pi.