En un dels nostres , dedicada a la planificació d'infraestructures a l'hora d'implementar Zimbra Collaboration Suite en una empresa, es va dir que la principal limitació en el funcionament d'aquesta solució és la velocitat d'E/S dels dispositius de disc en emmagatzematge de correu. De fet, en un moment en què diversos centenars d'empleats d'una empresa accedeixen simultàniament al mateix emmagatzematge de correu, l'amplada del canal per escriure i llegir informació dels discs durs pot ser que no sigui suficient per al funcionament sensible del servei. I si per a petites instal·lacions de Zimbra això no serà un problema particular, aleshores en el cas de les grans empreses i proveïdors de SaaS, tot això pot provocar un correu electrònic que no respon i, com a resultat, una disminució de l'eficiència dels empleats, així com una violació. dels SLA. És per això que, a l'hora de dissenyar i operar instal·lacions de Zimbra a gran escala, s'ha de prestar especial atenció a l'optimització del rendiment dels discs durs a l'emmagatzematge de correu. Vegem dos casos i intentem esbrinar quins mètodes per optimitzar la càrrega de l'emmagatzematge en disc es poden aplicar en cadascun d'ells.
1. Optimització a l'hora de dissenyar una instal·lació Zimbra a gran escala
Durant la fase de disseny d'una instal·lació de Zimbra d'alta càrrega, l'administrador haurà de triar quin sistema d'emmagatzematge utilitzarà. Per decidir sobre aquest tema, hauríeu de saber que la càrrega principal dels discs durs prové del SGBD MariaDB inclòs a Zimbra Collaboration Suite, el motor de cerca Apache Lucene i l'emmagatzematge de blobs. És per això que per fer funcionar aquests productes de programari en condicions de càrrega elevada, cal utilitzar equips fiables i d'alta velocitat.
En condicions normals, Zimbra es pot instal·lar tant en RAID de discs durs com en emmagatzematge connectat mitjançant el protocol NFS. Per a instal·lacions molt petites, podeu instal·lar Zimbra en una unitat SATA normal. Tanmateix, en el context de les grans instal·lacions, totes aquestes tecnologies mostren diversos inconvenients en forma de velocitat d'enregistrament reduïda o baixa fiabilitat, cosa que no és acceptable ni per a les grans empreses ni, especialment, per als proveïdors de SaaS.
És per això que a les infraestructures de Zimbra a gran escala el millor és utilitzar una SAN. És aquesta tecnologia la que actualment és capaç de proporcionar el major rendiment per als dispositius d'emmagatzematge i, al mateix temps, gràcies a la capacitat de connectar una gran quantitat de memòria cau, el seu ús pràcticament no suposa cap risc significatiu per a l'empresa. És una bona idea utilitzar NVRAM, que s'utilitza en moltes SAN per accelerar les coses durant les escriptures. Però és millor desactivar la memòria cau de les dades enregistrades als propis discs, ja que pot provocar danys irreparables als suports i pèrdua de dades si es produeixen problemes d'alimentació.
Pel que fa a l'elecció del sistema de fitxers, l'opció òptima seria utilitzar els estàndard per a Linux Ext3/Ext4. El principal detall associat amb el sistema de fitxers és que s'ha de muntar amb el paràmetre -noatime. Aquesta opció desactivarà la funció d'enregistrament de l'hora de l'últim accés als fitxers, la qual cosa significa que reduirà molt la càrrega de lectura i escriptura. En general, quan creeu un sistema de fitxers ext3 o ext4 per a Zimbra, hauríeu d'utilitzar els següents paràmetres d'utilitat mke2fs:
-j — Per crear un diari del sistema de fitxers. Creeu el sistema de fitxers amb un diari ext3/ext4.
-L NOM - Per crear un nom de volum per utilitzar-lo després a /etc/fstab
-O dir_index - Utilitzar un arbre de cerca amb hash per accelerar les cerques de fitxers en directoris grans
-m 2 — Reservar el 2% del volum en sistemes de fitxers grans per al directori arrel
-Talla J=400 — Crear una gran revista
-b 4096 — Per determinar la mida del bloc en bytes
-I 10240 - Per a l'emmagatzematge de missatges, aquesta configuració hauria de correspondre a la mida mitjana del missatge. Heu de parar molta atenció a aquest paràmetre, ja que el seu valor no es pot canviar més endavant.
També es recomana activar sincronització directa per a l'emmagatzematge de blob, l'emmagatzematge de metadades de cerca Lucene i l'emmagatzematge de cua MTA. Això s'ha de fer perquè Zimbra normalment utilitza la utilitat fsync per garantir l'escriptura d'un blob amb dades al disc. Tanmateix, quan el magatzem de correu de Zimbra o l'MTA crea fitxers nous durant el lliurament del missatge, es fa necessari escriure al disc els canvis que es produeixen a les carpetes corresponents. És per això que, fins i tot si el fitxer ja s'ha escrit al disc utilitzant fsync, el registre de la seva incorporació al directori pot no tenir temps d'escriure al disc i, com a resultat, es pot perdre a causa d'una fallada sobtada del servidor. Gràcies a l'ús sincronització directa aquests problemes es poden evitar.
2. Optimització amb la infraestructura de Zimbra en funcionament
Sovint passa que després de diversos anys d'ús de Zimbra, el nombre d'usuaris augmenta significativament i el servei esdevé cada cop menys sensible. La solució a aquesta situació és òbvia: simplement afegir nous servidors a la infraestructura per restaurar la velocitat del servei. Tanmateix, no sempre és possible afegir immediatament nous servidors a la infraestructura per millorar-ne el rendiment. Els gestors de TI sovint han de dedicar molt de temps a coordinar la compra. nous servidors A més, els proveïdors sovint no lliuren un servidor nou amb retard o fins i tot lliuren l'article equivocat, fins i tot amb els departaments de comptabilitat o seguretat.
Per descomptat, és millor construir la infraestructura de Zimbra amb una reserva, de manera que sempre tingueu marge d'expansió i no hàgiu de dependre de ningú. Tanmateix, si ja s'ha comès un error, el gestor de TI només pot mitigar les seves conseqüències tant com sigui possible. Per exemple, un gestor de TI pot aconseguir un petit augment de rendiment desactivant temporalment els serveis del sistema. Linux, que accedeixen regularment als discs durs durant el funcionament i, com a resultat, poden afectar negativament el rendiment de Zimbra. Per exemple, podeu desactivar temporalment:
autofs, netfs - Serveis de descoberta del sistema de fitxers remots
tasses - Servei d'impressió
xinetd, vsftpd - Serveis *NIX integrats que probablement no necessitareu
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Serveis de trucada de procediments remots, que s'utilitzen normalment conjuntament amb sistemes de fitxers de xarxa
colom, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicats de les principals utilitats incloses a Zimbra Collaboration Suite
ubicar/actualitzarb - Com que Zimbra emmagatzema cada missatge en un fitxer independent, executar el servei updatedb cada dia pot causar problemes, de manera que podeu fer-ho manualment quan els servidors estiguin menys ocupats
L'estalvi de recursos del sistema com a conseqüència de la desactivació d'aquests serveis no serà molt significatiu, però fins i tot això pot ser molt útil en condicions properes a la força major. Un cop afegit el nou servidor a la infraestructura de Zimbra, es recomana tornar a habilitar els serveis desactivats anteriorment.
També podeu optimitzar el funcionament de Zimbra movent el servei syslog a un servidor independent perquè durant el funcionament no carregui els discs durs dels emmagatzematges de correu. Gairebé qualsevol ordinador és adequat per a aquests propòsits, fins i tot un Raspberry Pi barat d'una sola placa.
Font: www.habr.com
