В един от нашите , посветен на планирането на инфраструктурата при внедряването на Zimbra Collabortion Suite в предприятие, беше казано, че основното ограничение в работата на това решение е I/O скоростта на дисковите устройства в хранилищата за поща. Наистина, в момент, когато няколкостотин служители на едно предприятие имат достъп едновременно до едно и също хранилище за поща, ширината на канала за запис и четене на информация от твърди дискове може да не е достатъчна за отзивчивата работа на услугата. И ако за малки инсталации на Zimbra това няма да представлява особен проблем, то в случай на големи предприятия и доставчици на SaaS всичко това може да доведе до неотговарящ имейл и в резултат на това намаляване на ефективността на служителите, както и нарушение на SLA. Ето защо, когато проектирате и управлявате широкомащабни инсталации на Zimbra, трябва да се обърне специално внимание на оптимизирането на производителността на твърдите дискове в хранилището за поща. Нека да разгледаме два случая и да се опитаме да разберем какви методи за оптимизиране на натоварването на дисковото хранилище могат да бъдат приложени във всеки от тях.
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 dir_index - Използване на хеширано дърво за търсене за ускоряване на търсенето на файлове в големи директории
-m 2 — За запазване на 2% от обема в големи файлови системи за основната директория
-J размер=400 — За създаване на голямо списание
-b 4096 — За определяне на размера на блока в байтове
-аз 10240 - За съхранение на съобщения тази настройка трябва да съответства на средния размер на съобщението. Трябва да обърнете голямо внимание на този параметър, тъй като стойността му не може да бъде променена по-късно.
Също така се препоръчва да активирате dirsync за съхранение на blob, съхранение на метаданни за търсене в Lucene и съхранение на MTA опашка. Това трябва да се направи, защото Zimbra обикновено използва помощната програма fsync за гарантирано записване на петно с данни на диск. Въпреки това, когато магазинът за поща на Zimbra или MTA създава нови файлове по време на доставка на съобщение, става необходимо да се запишат на диска промените, които се случват в съответните папки. Ето защо, дори ако файлът вече е записан на диск с помощта на fsync, записът за добавянето му към директорията може да няма време да бъде записан на диска и в резултат на това може да бъде загубен поради внезапна повреда на сървъра. Благодарение на използването 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.
Източник: www.habr.com