В един от нашите , посветена на планирането на инфраструктурата при внедряването на Zimbra Collaboration Suite в предприятия, беше посочено, че основното ограничение при работата на това решение е скоростта на входно-изходните операции на дисковите устройства в пощенските хранилища. И наистина, когато няколко стотин служители на предприятията активно използват едно и също пощенско хранилище, може да не е достатъчна широчината на канала за запис и четене на информация от твърдите дискове за бърза работа на услугата. И ако за малки инсталации на Zimbra това не би било особен проблем, то в случай на големи предприятия и SaaS доставчици всичко това може да доведе до неотзивчива работа на имейлите и, следователно, до намаляване на ефективността на служителите, както и до нарушение на SLA. Именно затова при проектирането и експлоатацията на мащабни инсталации на Zimbra трябва да се обърне особено внимание на оптимизацията на работата на твърдите дискове в пощенските хранилища. Нека разгледаме два случая и да опитаме да разберем какви методи за оптимизация на натоварването на дисковите хранилища могат да се приложат в тях.
1. Оптимизация при проектирането на мащабна инсталация на Zimbra
На етапа на проектиране на високо натоварена инсталация на Zimbra, администраторът трябва да направи избор каква система за съхранение на данни да използва. За да се определи този въпрос, е важно да се знае, че основното натоварване на твърдите дискове идва от базите данни на Zimbra Collaboration Suite, системата за търсене Apache Lucene, както и хранилището на BLOB обекти. Именно затова за работата на тези софтуерни продукти в условия на високи натоварвания е необходимо да се използва бързо и надеждно оборудване.
При нормални условия Zimbra може да бъде инсталирана както на RAID от твърди дискове, така и на хранилища, свързани по протокол NFS. В случаи на много малки инсталации, Zimbra може да бъде инсталирана на стандартен SATA диск. Въпреки това, при условия на големи инсталации, всичките тези технологии показват различни недостатъци под формата на намалена скорост на запис или ниска надеждност, което е неприемливо нито за големи предприятия, нито, още по-малко, за SaaS доставчици.
Затова, в условия на мащабни инфраструктури, Zimbra е най-добре да използва SAN. Именно тя в момента е способна да осигури най-висока пропускателна способност за устройствата за съхранение и при това, благодарение на възможността за свързване на голямо количество кеш, използването й практически не носи съществени рискове за предприятието. Добра идея е да се използва NVRAM, която се използва в много SAN за ускоряване на работата по време на запис. Вместо това, кеширането на записваните данни на самите дискове е най-добре да се изключи, тъй като то може да доведе до непоправими повреди на носителите и загуба на данни при възникване на проблеми с електрическото захранване.
Що се отнася до избора на файловата система, оптималният избор е да се използват стандартните за Linux Ext3/Ext4. Основният нюанс, свързан с файловата система, е, че тя трябва да бъде монтирана с параметъра -noatime. Този параметър ще деактивира функцията на записване на последното време на достъп до файловете, което значително ще намали натоварването на четенето и записа. В общи линии, при създаването на файловата система ext3 или ext4 за Zimbra, трябва да се използват следните параметри на утилитата mke2fs:
-j — За създаване на журнал на файловата система. Създайте файловата система с журнал ext3/ext4.
-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.
Източник: habr.com
