Într-una dintre noastre , dedicat planificării infrastructurii la implementarea Zimbra Collaboration Suite într-o întreprindere, s-a spus că principala limitare în funcționarea acestei soluții este viteza de I/O a dispozitivelor de disc din depozitele de mail. Într-adevăr, într-un moment în care câteva sute de angajați ai unei întreprinderi accesează simultan aceeași stocare de corespondență, lățimea canalului pentru scrierea și citirea informațiilor de pe hard disk poate să nu fie suficientă pentru funcționarea receptivă a serviciului. Și dacă pentru instalațiile mici ale Zimbra aceasta nu va fi o problemă deosebită, atunci în cazul întreprinderilor mari și al furnizorilor SaaS, toate acestea pot duce la e-mailuri care nu răspund și, ca urmare, o scădere a eficienței angajaților, precum și o încălcare. a SLA-urilor. De aceea, atunci când se proiectează și se operează instalații Zimbra la scară largă, trebuie acordată o atenție deosebită optimizării performanței hard disk-urilor în stocarea e-mailurilor. Să ne uităm la două cazuri și să încercăm să aflăm ce metode de optimizare a încărcării stocării pe disc pot fi aplicate în fiecare dintre ele.
1. Optimizare la proiectarea unei instalații Zimbra la scară largă
În faza de proiectare a unei instalări Zimbra cu încărcare mare, administratorul va trebui să aleagă ce sistem de stocare să folosească. Pentru a decide cu privire la această problemă, trebuie să știți că sarcina principală de pe hard disk-ul provine de la SGBD-ul MariaDB inclus în Zimbra Collaboration Suite, motorul de căutare Apache Lucene și stocarea blob. De aceea, pentru a opera aceste produse software în condiții de încărcare mare, este necesar să folosiți echipamente de mare viteză și fiabile.
În condiții normale, Zimbra poate fi instalat atât pe RAID de hard disk, cât și pe stocarea conectată prin protocolul NFS. Pentru instalări foarte mici, puteți instala Zimbra pe o unitate SATA obișnuită. Totuși, în contextul instalațiilor mari, toate aceste tehnologii demonstrează diverse dezavantaje sub forma vitezei reduse de înregistrare sau a fiabilității scăzute, ceea ce nu este inacceptabil nici pentru întreprinderile mari și, în special, pentru furnizorii de SaaS.
Acesta este motivul pentru care în infrastructurile Zimbra la scară largă este cel mai bine să utilizați un SAN. Această tehnologie este în prezent capabilă să ofere cel mai mare debit pentru dispozitivele de stocare și, în același timp, datorită capacității de a conecta o cantitate mare de cache, utilizarea sa practic nu prezintă niciun risc semnificativ pentru întreprindere. Este o idee bună să folosiți NVRAM, care este folosit în multe SAN-uri pentru a accelera lucrurile în timpul scrierilor. Dar este mai bine să dezactivați stocarea în cache a datelor înregistrate pe discuri, deoarece poate duce la daune ireparabile ale suportului și la pierderea datelor dacă apar probleme de alimentare.
În ceea ce privește alegerea unui sistem de fișiere, cea mai bună alegere ar fi să utilizați standardul Linux Ext3/Ext4. Nuanța principală asociată cu sistemul de fișiere este că ar trebui să fie montat cu parametrul -noatime. Această opțiune va dezactiva funcția de înregistrare a timpului ultimului acces la fișiere, ceea ce înseamnă că va reduce foarte mult sarcina de citire și scriere. În general, atunci când creați un sistem de fișiere ext3 sau ext4 pentru Zimbra, ar trebui să utilizați următorii parametri de utilitate mke2fs:
-j — Pentru a crea un jurnal de sistem de fișiere. Creați sistemul de fișiere cu un jurnal ext3/ext4.
-L NUME - Pentru a crea un nume de volum pe care să îl utilizați apoi în /etc/fstab
-O dir_index - Pentru a utiliza un arbore de căutare cu hash pentru a accelera căutările de fișiere în directoare mari
-m 2 — Pentru a rezerva 2% din volumul în sistemele de fișiere mari pentru directorul rădăcină
-Mărimea J=400 — Pentru a crea o revistă mare
-b 4096 — Pentru a determina dimensiunea blocului în octeți
-i 10240 - Pentru stocarea mesajelor, această setare ar trebui să corespundă dimensiunii medii a mesajului. Ar trebui să acordați o atenție deosebită acestui parametru, deoarece valoarea acestuia nu poate fi modificată ulterior.
De asemenea, se recomandă activarea sincronizare directă pentru stocarea blob, stocarea metadatelor de căutare Lucene și stocarea în coadă MTA. Acest lucru ar trebui făcut deoarece Zimbra utilizează de obicei utilitarul fsync pentru scrierea garantată a unui blob cu date pe disc. Cu toate acestea, atunci când magazinul de e-mail Zimbra sau MTA creează noi fișiere în timpul livrării mesajelor, devine necesar să scrieți pe disc modificările care apar în folderele corespunzătoare. De aceea, chiar dacă fișierul a fost deja scris pe disc folosind fsync, este posibil ca înregistrarea adăugării sale în director să nu aibă timp să fie scrisă pe disc și, în consecință, se poate pierde din cauza unei defecțiuni bruște a serverului. Datorită utilizării sincronizare directă aceste probleme pot fi evitate.
2. Optimizare cu infrastructura Zimbra care rulează
Se întâmplă adesea ca, după câțiva ani de utilizare a Zimbra, numărul utilizatorilor săi să crească semnificativ, iar serviciul să devină din ce în ce mai puțin receptiv în fiecare zi. Ieșirea din această situație este evidentă: trebuie doar să adăugați noi servere la infrastructură, astfel încât serviciul să funcționeze din nou la fel de repede ca înainte. Între timp, nu este întotdeauna posibil să adăugați imediat noi servere la infrastructură pentru a crește performanța acesteia. Managerii IT trebuie adesea să petreacă mult timp coordonând achiziționarea de noi servere cu departamentul de contabilitate sau securitate; în plus, sunt adesea dezamăgiți de furnizori care pot livra un nou server cu întârziere sau chiar pot livra ceva greșit.
Desigur, cel mai bine este să vă construiți infrastructura Zimbra cu o rezervă pentru a avea întotdeauna o rezervă pentru extinderea ei și pentru a nu depinde de nimeni, totuși, dacă a fost deja făcută o greșeală, managerul IT nu poate decât să-și atenueze consecințele ca pe cât posibil. De exemplu, un manager IT poate obține o creștere mică a productivității prin dezactivarea temporară a serviciilor de sistem Linux care accesează în mod regulat hard disk-uri în timpul funcționării și, prin urmare, pot avea un impact negativ asupra performanței Zimbra. Deci, puteți dezactiva temporar:
autofs, netfs - Servicii de descoperire a sistemului de fișiere la distanță
cupe — Serviciu de imprimare
xinetd, vsftpd - Servicii *NIX încorporate de care probabil nu veți avea nevoie
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Servicii de apel de procedură la distanță, care sunt utilizate de obicei împreună cu sistemele de fișiere din rețea
porumbel, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicate ale principalelor utilități incluse în Zimbra Collaboration Suite
slocate/actualizateb - Deoarece Zimbra stochează fiecare mesaj într-un fișier separat, rularea serviciului updatedb în fiecare zi poate cauza probleme și, prin urmare, este posibil să faceți acest lucru manual în timpul celei mai mici încărcări pe servere
Economisirea resurselor sistemului ca urmare a dezactivării acestor servicii nu va fi foarte semnificativă, dar chiar și aceasta poate fi foarte utilă în condiții apropiate de forța majoră. Odată ce noul server este adăugat la infrastructura Zimbra, se recomandă reactivarea serviciilor dezactivate anterior.
De asemenea, puteți optimiza funcționarea Zimbra prin mutarea serviciului syslog pe un server separat, astfel încât în timpul funcționării să nu încarce hard disk-urile depozitelor de e-mail. Aproape orice computer este potrivit pentru aceste scopuri, chiar și un Raspberry Pi ieftin cu o singură placă.
Sursa: www.habr.com