Во една од нашите , посветен на планирање на инфраструктурата при имплементација на Zimbra Collabortion Suite во претпријатие, беше речено дека главното ограничување во работењето на ова решение е брзината на влез/излез на уредите со диск во складиштата за пошта. Навистина, во време кога неколку стотици вработени во едно претпријатие истовремено пристапуваат до истото складирање пошта, ширината на каналот за пишување и читање информации од хард дискови можеби не е доволна за одговорно работење на услугата. И ако за малите инсталации на Zimbra ова нема да биде посебен проблем, тогаш во случајот на големите претпријатија и давателите на SaaS, сето ова може да доведе до неодговорна е-пошта и, како резултат на тоа, намалување на ефикасноста на вработените, како и прекршување на SLA. Затоа, при дизајнирање и ракување со големи инсталации на Zimbra, посебно внимание треба да се посвети на оптимизирање на перформансите на хард дисковите во складирањето пошта. Ајде да погледнеме два случаи и да се обидеме да откриеме кои методи за оптимизирање на оптоварувањето на складирањето на дискот може да се применат во секој од нив.
1. Оптимизација при дизајнирање на инсталација од големи размери Zimbra
За време на фазата на дизајнирање на инсталацијата на Zimbra со големо оптоварување, администраторот ќе треба да избере кој систем за складирање да го користи. За да одлучите за ова прашање, треба да знаете дека главното оптоварување на хард дисковите доаѓа од MariaDB DBMS вклучени во пакетот за соработка на Zimbra, пребарувачот Apache Lucene и складирањето на blob. Затоа, за да се работи со овие софтверски производи под услови на големо оптоварување, неопходно е да се користи опрема со голема брзина и доверливост.
Во нормални услови, Zimbra може да се инсталира и на RAID на хард дискови и на складирање поврзано преку протоколот NFS. За многу мали инсталации, можете да инсталирате Zimbra на обичен SATA-диск. Меѓутоа, во контекст на големите инсталации, сите овие технологии покажуваат различни недостатоци во форма на намалена брзина на снимање или мала доверливост, што е неприфатливо ниту за големите претпријатија ниту, особено за давателите на SaaS.
Ова е причината зошто во големите инфраструктури на Зимбра најдобро е да се користи SAN. Токму оваа технологија во моментов е способна да обезбеди најголема пропусност за уредите за складирање и во исто време, благодарение на можноста за поврзување на голема количина кеш, нејзината употреба практично не претставува значителен ризик за претпријатието. Добра идеја е да се користи NVRAM, кој се користи во многу SAN за да се забрзаат работите за време на пишувањето. Но, подобро е да се оневозможи кеширањето на снимените податоци на самите дискови, бидејќи може да доведе до непоправлива штета на медиумот и губење на податоците ако се појават проблеми со напојувањето.
Што се однесува до изборот на датотечен систем, најдобриот избор би бил да се користи стандардниот Linux Ext3/Ext4. Главната нијанса поврзана со датотечен систем е тоа што треба да се монтира со параметарот - Ноавреме. Оваа опција ќе ја оневозможи функцијата за снимање на времето на последниот пристап до датотеките, што значи дека во голема мера ќе го намали оптоварувањето на читањето и пишувањето. Општо земено, кога креирате датотечен систем ext3 или ext4 за Zimbra, треба да ги користите следниве параметри за комунални услуги mke2fs:
-j — За да креирате дневник за датотечен систем Креирајте го датотечниот систем со дневник ext3/ext4.
-Л ИМЕ - За да креирате име на волумен за потоа да го користите во /etc/fstab
-О дир_индекс - Да се користи хаширано дрво за пребарување за да се забрза пребарувањето на датотеки во големи директориуми
-м 2 — За да резервирате 2% од волуменот во големите датотечни системи за root директориумот
-J големина=400 — Да се создаде големо списание
-б 4096 — За да се одреди големината на блокот во бајти
-и 10240 - За складирање пораки, оваа поставка треба да одговара на просечната големина на пораката. Треба да обрнете големо внимание на овој параметар, бидејќи неговата вредност не може да се промени подоцна.
Исто така, се препорачува да се овозможи dirsync за складирање на дамки, складирање на метаподатоци за пребарување Lucene и складирање на редици MTA. Ова треба да се направи затоа што Zimbra обично ја користи алатката fsync за гарантирано запишување на дупка со податоци на диск. Меѓутоа, кога продавницата за пошта Zimbra или MTA создава нови датотеки за време на испораката на пораките, станува неопходно да се запишуваат на дискот промените што се случуваат во соодветните папки. Тоа е причината зошто, дури и ако датотеката е веќе напишана на диск со користење fsync, записот за неговото додавање во директориумот може да нема време да се запише на дискот и, како резултат на тоа, може да се изгуби поради ненадеен дефект на серверот. Благодарение на употребата dirsync овие проблеми може да се избегнат.
2. Оптимизација со вклучена инфраструктура на Зимбра
Често се случува после неколку години користење на Zimbra, бројот на нејзини корисници значително да се зголеми и услугата да станува сè помалку респонзивна секој ден. Излезот од оваа ситуација е очигледен: само треба да додадете нови сервери во инфраструктурата, така што услугата повторно работи брзо како порано. Во меѓувреме, не е секогаш можно веднаш да се додадат нови сервери во инфраструктурата за да се зголемат нејзините перформанси. ИТ-менаџерите често мора да поминат долго време координирајќи го купувањето на нови сервери со одделот за сметководство или безбедност; покрај тоа, тие често се изневеруваат од добавувачите кои можат да достават нов сервер доцна или дури и да испорачаат погрешна работа.
Се разбира, најдобро е да ја изградите инфраструктурата на Зимбра со резерва за секогаш да имате резерва за нејзино проширување и да не зависите од никого, меѓутоа, ако веќе е направена грешка, ИТ менаџерот може само да ги израмни нејзините последици како колку што е можно. На пример, ИТ менаџер може да постигне мало зголемување на продуктивноста со привремено оневозможување на системските услуги на Linux кои редовно пристапуваат до хард дисковите за време на работата и затоа може негативно да влијаат на перформансите на Zimbra. Значи, можете привремено да го оневозможите:
autofs, netfs - Услуги за откривање на датотечниот систем од далечина
чаши — Услуга за печатење
xinetd, vsftpd - Вградени *NIX услуги кои веројатно нема да ви требаат
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Услуги за повици за далечинска процедура, кои обично се користат заедно со мрежни датотечни системи
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Дупликати од главните комунални услуги вклучени во пакетот за соработка на Zimbra
slocate/updatedb - Со оглед на тоа што Zimbra ја складира секоја порака во посебна датотека, извршувањето на услугата updatedb секој ден може да предизвика проблеми и затоа е можно тоа да се направи рачно при најмало оптоварување на серверите
Заштедата на системските ресурси како резултат на оневозможувањето на овие услуги нема да биде многу значајно, но дури и ова може да биде многу корисно во услови блиски до виша сила. Откако ќе се додаде новиот сервер во инфраструктурата на Зимбра, се препорачува повторно да се активираат претходно оневозможените услуги.
Можете исто така да ја оптимизирате работата на Zimbra со преместување на услугата syslog на посебен сервер за да не ги вчита тврдите дискови на складишта за пошта за време на работата. Речиси секој компјутер е погоден за овие цели, дури и евтин Raspberry Pi со една плоча.
Извор: www.habr.com