В одній із наших , присвяченій плануванню інфраструктури при впровадженні на підприємстві Zimbra Collabortion Suite, було сказано, що головним обмеженням при роботі цього рішення є швидкість вводу-виводу дискових пристроїв у поштових сховищах. І справді, у той час, коли кілька сотень працівників підприємства одночасно звертаються до одного і того ж поштового сховища, ширини каналу для запису та читання інформації з жорстких дисків може не вистачати для чуйної роботи сервісу. І якщо для невеликих установок Zimbra це не стане особливою проблемою, то у випадку з великими підприємствами та SaaS-провайдерами все це може призвести до нечуйної роботи електронної пошти та, як наслідок, зниження ефективності співробітників, а також порушення SLA. Саме тому при проектуванні та експлуатації масштабних установок Zimbra слід приділити особливу увагу оптимізації роботи жорстких дисків у поштовому сховищі. Розгляньмо два кейси і спробуємо з'ясувати, які методи оптимізації навантаження на дискові сховища можна застосувати в кожному з них.
1. Оптимізація під час проектування масштабної установки Zimbra
На етапі проектування високонавантаженої установки Zimbra її адміністратор має зробити вибір, яку систему зберігання даних використовувати. Для того, щоб визначитися з цим питанням, слід знати, що основне навантаження на жорсткі диски створюють СУБД MariaDB, система пошуку Apache Lucene, а також сховище BLOB-об'єктів, що входять до складу Zimbra Collaboration Suite. Саме тому для роботи цих програмних продуктів в умовах високих навантажень необхідно використовувати швидкісне та надійне обладнання.
У звичайних умовах 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 — Для використання хешованого дерева пошуку для прискорення пошуку файлів у великих директоріях
-м 2 - Для резервування 2% обсягу у великих файлових системах під кореневий каталог
-J size=400 — Для створення великого журналу
-б 4096 - Для визначення розміру блоку в байтах
-я 10240 — Для сховища повідомлень цей параметр має відповідати середньому розміру повідомлень. Слід уважно поставитися до цього параметра, оскільки згодом його значення не можна буде змінити
Крім того, рекомендується включити dirsync для сховища BLOB-об'єктів, сховища мета-даних пошуку Lucene та сховища черги MTA. Робити це слід з тієї причини, що зазвичай Zimbra використовує утиліту фсинк для гарантованого запису блобу з даними на диск. Однак, коли поштове сховище Zimbra або MTA створюють нові файли під час доставки повідомлень, виникає потреба запису на диск змін, що відбулися у відповідних папках. Саме тому навіть якщо файл вже записаний на диск за допомогою фсинк, запис про його додавання до директорії може не встигнути записатися на диск і в результаті може бути втрачена через раптову відмову сервера. Завдяки використанню dirsync цих проблем можна уникнути.
2. Оптимізація при працюючій інфраструктурі Zimbra
Часто буває так, що після кількох років експлуатації Zimbra кількість її користувачів значно зростає і робота сервісу стає з кожним днем дедалі менш чуйною. Вихід із такої ситуації очевидний: потрібно просто додати нові сервери до інфраструктури, щоб сервіс знову працював так само швидко, як і раніше. Тим часом далеко не завжди є можливість відразу додати в інфраструктуру нові сервери, щоб підвищити її швидкодію. Найчастіше ІТ-менеджерам доводиться довго погоджувати придбання нових серверів з бухгалтерією або відділом безпеки, крім того, нерідко підводять постачальники, які можуть привезти новий сервер із запізненням або доставити не те, що потрібно.
Зрозуміло, що найкраще будувати свою інфраструктуру Zimbra із запасом, щоб завжди мати запас для її розширення і ні від кого при цьому не залежати, проте якщо помилка вже скоєна, ІТ-менеджер залишається тільки максимально згладити її наслідки. Так, наприклад, ІТ-менеджер може досягти невеликого зростання продуктивності, використовуючи тимчасове відключення системних служб Linux, які під час роботи регулярно звертаються до жорстких дисків і внаслідок цього можуть негативно вплинути на швидкість роботи Zimbra. Так, на якийсь час можна відключити:
autofs, netfs — Служби виявлення віддалених файлових систем
чашки - Служба друку
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.
Джерело: habr.com