Optimaliseer posberging in Zimbra Collaboration Suite

In een van ons vorige artikels, toegewy aan infrastruktuurbeplanning by die implementering van Zimbra Collabortion Suite in 'n onderneming, is gesê dat die hoofbeperking in die werking van hierdie oplossing die I/O-spoed van skyftoestelle in posbergings is. Inderdaad, in 'n tyd wanneer 'n paar honderd werknemers van 'n onderneming gelyktydig toegang tot dieselfde posberging het, is die kanaalwydte vir die skryf en lees van inligting vanaf hardeskywe moontlik nie genoeg vir die responsiewe werking van die diens nie. En as dit vir klein Zimbra-installasies nie 'n besondere probleem sal wees nie, dan kan dit alles in die geval van groot ondernemings en SaaS-verskaffers lei tot onreagerende e-pos en as gevolg daarvan 'n afname in werknemerdoeltreffendheid, sowel as 'n oortreding van SLA's. Dit is hoekom, wanneer grootskaalse Zimbra-installasies ontwerp en bedryf word, spesiale aandag gegee moet word aan die optimalisering van die werkverrigting van hardeskywe in posberging. Kom ons kyk na twee gevalle en probeer om uit te vind watter metodes vir die optimalisering van die lading op skyfberging in elk van hulle toegepas kan word.

Optimaliseer posberging in Zimbra Collaboration Suite

1. Optimalisering wanneer 'n grootskaalse Zimbra-installasie ontwerp word

Tydens die ontwerpfase van 'n hoëlading Zimbra-installasie sal die administrateur 'n keuse moet maak oor watter bergingstelsel om te gebruik. Om oor hierdie kwessie te besluit, moet u weet dat die hooflading op hardeskywe afkomstig is van die MariaDB DBMS wat by die Zimbra Collaboration Suite, die Apache Lucene-soekenjin en blobberging ingesluit is. Daarom is dit nodig om hoëspoed en betroubare toerusting te gebruik om hierdie sagtewareprodukte onder hoë lastoestande te bedryf.

Onder normale omstandighede kan Zimbra geïnstalleer word op beide RAID van hardeskywe en op berging wat via die NFS-protokol gekoppel is. Vir baie klein installasies kan jy Zimbra op 'n gewone SATA-stasie installeer. In die konteks van groot installasies toon al hierdie tegnologieë egter verskeie nadele in die vorm van verminderde opnamespoed of lae betroubaarheid, wat nie vir groot ondernemings of veral vir SaaS-verskaffers onaanvaarbaar is nie.

Dit is hoekom dit in grootskaalse Zimbra-infrastruktuur die beste is om 'n SAN te gebruik. Dit is hierdie tegnologie wat tans in staat is om die grootste deurset vir bergingstoestelle te verskaf en terselfdertyd, danksy die vermoë om 'n groot hoeveelheid kas te koppel, hou die gebruik daarvan feitlik geen noemenswaardige risiko's vir die onderneming in nie. Dit is 'n goeie idee om NVRAM te gebruik, wat in baie SAN'e gebruik word om dinge te bespoedig tydens skryf. Maar dit is beter om die kas van aangetekende data op die skywe self uit te skakel, aangesien dit kan lei tot onherstelbare skade aan die media en verlies van data as kragprobleme voorkom.

Wat die keuse van 'n lêerstelsel betref, sal die beste keuse wees om die standaard Linux Ext3/Ext4 te gebruik. Die belangrikste nuanse wat met die lêerstelsel geassosieer word, is dat dit met die parameter gemonteer moet word -noatime. Hierdie opsie sal die funksie van die opname van die tyd van die laaste toegang tot lêers deaktiveer, wat beteken dat dit die las op lees en skryf aansienlik sal verminder. Oor die algemeen, wanneer u 'n ext3- of ext4-lêerstelsel vir Zimbra skep, moet u die volgende nutsparameters gebruik mke2fs:

-j — Om 'n lêerstelseljoernaal te skep Skep die lêerstelsel met 'n ext3/ext4-joernaal.
-L NAAM - Om 'n volume naam te skep om dan in /etc/fstab te gebruik
-O dir_indeks - Om 'n hashed soekboom te gebruik om lêersoektogte in groot dopgehou te bespoedig
-m 2 — Om 2% van die volume in groot lêerstelsels vir die wortelgids te reserveer
-J grootte=400 — Om 'n groot tydskrif te skep
-b 4096 — Om die blokgrootte in grepe te bepaal
-ek 10240 - Vir boodskapberging moet hierdie instelling ooreenstem met die gemiddelde boodskapgrootte. U moet baie aandag gee aan hierdie parameter, aangesien die waarde daarvan nie later verander kan word nie.

Dit word ook aanbeveel om te aktiveer dirsync vir blobberging, Lucene-soekmetadataberging en MTA-waglysberging. Dit moet gedoen word omdat Zimbra gewoonlik die hulpprogram gebruik fsinc vir gewaarborgde skryf van 'n blob met data na skyf. Wanneer die Zimbra-poswinkel of MTA egter nuwe lêers tydens boodskapaflewering skep, word dit nodig om die veranderinge wat in die ooreenstemmende vouers plaasvind, op skyf te skryf. Dit is hoekom, selfs al is die lêer reeds na skyf geskryf met behulp van fsinc, die rekord van die byvoeging daarvan tot die gids het dalk nie tyd om na die skyf geskryf te word nie en kan as gevolg daarvan verlore gaan as gevolg van 'n skielike bedienerfout. Danksy die gebruik dirsync hierdie probleme kan vermy word.

2. Optimalisering met Zimbra-infrastruktuur aan die gang

Dit gebeur dikwels dat na 'n paar jaar van gebruik van Zimbra die aantal gebruikers aansienlik toeneem en die diens elke dag minder en minder reageer. Die uitweg uit hierdie situasie is voor die hand liggend: jy hoef net nuwe bedieners by die infrastruktuur te voeg sodat die diens weer so vinnig werk soos voorheen. Intussen is dit nie altyd moontlik om onmiddellik nuwe bedieners by die infrastruktuur te voeg om die werkverrigting daarvan te verhoog nie. IT-bestuurders moet dikwels 'n lang tyd spandeer om die aankoop van nuwe bedieners met die rekeningkunde- of sekuriteitsafdeling te koördineer; boonop word hulle dikwels in die steek gelaat deur verskaffers wat 'n nuwe bediener laat kan lewer of selfs die verkeerde ding kan lewer.

Natuurlik is dit die beste om jou Zimbra-infrastruktuur met 'n reserwe te bou om altyd 'n reserwe vir die uitbreiding daarvan te hê en nie van enigiemand afhanklik te wees nie, maar as daar reeds 'n fout gemaak is, kan die IT-bestuurder net die gevolge daarvan glad maak as soveel as moontlik. Byvoorbeeld, 'n IT-bestuurder kan 'n klein produktiwiteitshupstoot bereik deur Linux-stelseldienste wat gereeld toegang tot hardeskywe kry tydens werking tydelik te deaktiveer en kan dus Zimbra se werkverrigting negatief beïnvloed. So, jy kan tydelik deaktiveer:

autofs, netfs - Afgeleë lêerstelsel-ontdekkingsdienste
koppies — Drukdiens
xinetd, vsftpd - Ingeboude *NIX-dienste wat u waarskynlik nie benodig nie
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Afgeleë prosedure-oproepdienste, wat gewoonlik saam met netwerklêerstelsels gebruik word
duikie, cyrus-imapd, sendmail, exim, postfix, ldap — Duplikate van die hoofhulpprogramme wat in die Zimbra Collaboration Suite ingesluit is
slaat/bygewerkb - Aangesien Zimbra elke boodskap in 'n aparte lêer stoor, kan die loop van die updatedb-diens elke dag probleme veroorsaak, en daarom is dit moontlik om dit met die hand te doen tydens die minste las op die bedieners

Die spaar van stelselhulpbronne as gevolg van die deaktivering van hierdie dienste sal nie baie belangrik wees nie, maar selfs dit kan baie nuttig wees in toestande naby aan force majeure. Sodra die nuwe bediener by die Zimbra-infrastruktuur gevoeg is, word dit aanbeveel om die voorheen gedeaktiveerde dienste te heraktiveer.

Jy kan ook die werking van Zimbra optimaliseer deur die syslog-diens na 'n aparte bediener te skuif sodat dit nie die hardeskywe van posbergings tydens werking laai nie. Byna enige rekenaar is geskik vir hierdie doeleindes, selfs 'n goedkoop enkelbord Raspberry Pi.

Bron: will.com

Voeg 'n opmerking