În unul dintre studiile noastre , dedicat planificării infrastructurii pentru implementarea suitei Zimbra Collaboration în întreprindere, s-a menționat că principala limitare a acestei soluții este viteza de citire și scriere a dispozitivelor de stocare din hranele poștale. Și într-adevăr, în momentul în care câteva sute de angajați ai întreprinderii accesează simultan aceeași hrână poștală, lățimea de bandă pentru scrierea și citirea informațiilor de pe hard diskuri poate fi insuficientă pentru o funcționare responsive a serviciului. Și, dacă pentru instalațiile mici Zimbra acest lucru nu va fi o problemă majoră, în cazul marilor întreprinderi și al furnizorilor SaaS, toate acestea pot duce la o funcționare nerespunsă a poștei electronice și, ca urmare, la scăderea eficienței angajaților, precum și la încălcarea SLA-ului. De aceea, atunci când se proiectează și se operează instalații de mari dimensiuni Zimbra, este necesar să se acorde o atenție specială optimizării funcționării hard diskurilor în hrana poștală. Să analizăm două cazuri și să încercăm să descoperim ce metode de optimizare a încărcării pe stocările de discuri pot fi aplicate în fiecare dintre ele.
1. Optimizarea în proiectarea unei instalații mari Zimbra
În etapa de proiectare a unei instalații Zimbra cu încărcare mare, administratorul acesteia trebuie să decidă ce sistem de stocare a datelor să utilizeze. Pentru a se hotărî în această privință, este important să știe că principala încărcare pe hard diskuri este generată de sistemele de gestionare a bazelor de date MariaDB, sistemul de căutare Apache Lucene, precum și de stocarea obiectelor BLOB incluse în Zimbra Collaboration Suite. De aceea, pentru funcționarea acestor produse software în condiții de încărcări mari, este necesar să se utilizeze echipamente rapide și fiabile.
În condiții obișnuite, Zimbra poate fi instalat atât pe un RAID din hard diskuri, cât și pe stocări conectate prin protocol NFS. În cazuri de instalații foarte mici, Zimbra poate fi instalat pe un hard disk SATA obișnuit. Totuși, în condițiile instalațiilor mari, toate aceste tehnologii demonstrează diverse dezavantaje, precum viteza scăzută de scriere sau fiabilitate scăzută, ceea ce este inacceptabil atât pentru marile întreprinderi, cât și, cu atât mai mult, pentru furnizorii SaaS.
De aceea, în condițiile infrastructurilor mari, cel mai bine este să folosești SAN pentru Zimbra. Aceasta este în prezent capabilă să ofere cea mai mare lățime de bandă pentru dispozitivele de stocare și, datorită capacității de a conecta o cantitate mare de cache, utilizarea sa nu implică riscuri semnificative pentru companie. O idee bună ar fi utilizarea NVRAM, care este utilizată în multe SAN pentru a accelera operațiunile de scriere. În schimb, ar trebui să dezactivezi caching-ul datelor scrise pe discuri, deoarece acesta poate cauza daune iremediabile suporturilor și pierderi de date în caz de probleme de alimentare.
În ceea ce privește alegerea sistemului de fișiere, cea mai bună opțiune va fi utilizarea standardelor pentru Linux Ext3/Ext4. Principalul detaliu legat de sistemul de fișiere este că acesta trebuie montat cu parametrul -noatime. Acest parametru va dezactiva funcția de înregistrare a ultimei accesări a fișierelor, ceea ce va reduce semnificativ încărcătura de citire și scriere. În general, atunci când creezi un sistem de fișiere ext3 sau ext4 pentru Zimbra, ar trebui să folosești următorii parametri ai utilitarului mke2fs:
-j — Pentru a crea jurnalul sistemului de fișiere Create the file system with an ext3/ext4 journal.
-L NUME — Pentru a crea un nume de volum, care va fi folosit ulterior în /etc/fstab
-O dir_index — Pentru a folosi un arbore de căutare hash pentru accelerarea căutării fișierelor în directoare mari
-m 2 — Pentru a rezerva 2% din volum în sistemele mari de fișiere pentru directorul rădăcină
-J size=400 — Pentru a crea un jurnal mare
-b 4096 — Pentru a defini mărimea blocului în biți
-i 10240 — Pentru depozitul de mesaje, acest parametru trebuie să corespundă dimensiunii medii a mesajelor. Este important să acorzi atenție acestui parametru, deoarece ulterior valoarea sa nu va putea fi modificată.
De asemenea, se recomandă activarea dirsync pentru depozitul obiectelor BLOB, depozitul de metadate de căutare Lucene și depozitul de coadă MTA. Aceasta ar trebui făcută deoarece, de obicei, Zimbra folosește utilitarul fsync pentru a asigura înregistrarea garantată a blob-ului de date pe disc. Cu toate acestea, atunci când depozitul de e-mail Zimbra sau MTA creează noi fișiere în timpul livrării mesajelor, apare necesitatea de a scrie pe disc modificările survenite în folderele corespunzătoare. De aceea, chiar și atunci când fișierul a fost deja scris pe disc prin fsync, înregistrarea adăugării sale în director poate să nu fie suficient de rapidă pentru a se scrie pe disc și, în consecință, poate fi pierdută din cauza unei defecțiuni bruște a serverului. Datorită utilizării dirsync aceste probleme pot fi evitate.
2. Optimizarea într-o infrastructură Zimbra funcțională
Adesea, după câțiva ani de utilizare a Zimbra, numărul utilizatorilor săi crește semnificativ, iar performanța serviciului devine din ce în ce mai puțin responsivă. Soluția pentru această situație este evidentă: trebuie pur și simplu să adăugați noi servere în infrastructură pentru ca serviciul să funcționeze din nou la fel de rapid ca înainte. Totuși, nu este întotdeauna posibil să se adauge imediat noi servere în infrastructură pentru a-i îmbunătăți performanța. Adesea, managerii IT trebuie să obțină avizele necesare pentru achiziții noilor servere de la contabilitate sau departamentul de securitate, și nu de puține ori furnizorii întârzie livrarea unui nou server sau chiar aduc ceva complet diferit.
Desigur, cel mai bine este să construiești infrastructura Zimbra cu un surplus, astfel încât să ai întotdeauna rezerve pentru extindere și să nu depinzi de nimeni, dar dacă greșelile au fost deja făcute, managerul IT nu îi rămâne decât să minimizeze consecințele. De exemplu, managerul IT poate realiza o mică creștere a performanței prin dezactivarea temporară a serviciilor de sistem Linux, care, prin funcționarea lor, accesează regulat hard disk-urile și pot influența negativ viteza de lucru a Zimbra. Așadar, temporar, pot fi dezactivate:
autofs, netfs — Servicii de detectare a sistemelor de fișiere externe
cups — Serviciu de imprimare
xinetd, vsftpd — Servicii integrate *NIX, care probabil nu vor fi necesare
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Servicii de apeluri de proceduri la distanță, care sunt de obicei folosite în legătură cu sistemele de fișiere de rețea
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicate ale utilitarelor de bază incluse în Zimbra Collaboration Suite
slocate/updatedb — Deoarece Zimbra stochează fiecare mesaj într-un fișier separat, rularea zilnică a serviciului updatedb poate provoca probleme, așa că este recomandat să se facă manual în timpul unei perioade de încărcare minimă pe servere.
Economisirea resurselor sistemului prin dezactivarea acestor servicii nu va fi foarte semnificativă, însă chiar și așa poate fi de mare ajutor în condiții de forță majoră. După ce noul server a fost adăugat în infrastructura Zimbra, este recomandat să se reactiveze serviciile dezactivate anterior.
De asemenea, se poate optimiza funcționarea Zimbra prin mutarea serviciului syslog pe un server separat, astfel încât să nu obosească discurile fixe ale stocării poștei în timpul utilizării. Orice computer, inclusiv un Raspberry Pi ieftin, este potrivit pentru aceste scopuri.
Sursa: habr.com
