In een van onze , gewijd aan infrastructuurplanning bij de implementatie van Zimbra Collabortion Suite in een onderneming, werd gezegd dat de belangrijkste beperking in de werking van deze oplossing de I/O-snelheid van schijfapparaten in e-mailopslag is. In een tijd waarin honderden werknemers van een onderneming tegelijkertijd toegang hebben tot dezelfde e-mailopslag, is de kanaalbreedte voor het schrijven en lezen van informatie van harde schijven mogelijk niet voldoende voor de responsieve werking van de dienst. En als dit voor kleine installaties van Zimbra geen bijzonder probleem zal zijn, dan kan dit in het geval van grote ondernemingen en SaaS-providers leiden tot niet-reagerende e-mail en, als gevolg daarvan, een afname van de efficiëntie van werknemers, evenals een overtreding van SLA's. Daarom moet bij het ontwerpen en exploiteren van grootschalige Zimbra-installaties speciale aandacht worden besteed aan het optimaliseren van de prestaties van harde schijven in mailopslag. Laten we naar twee gevallen kijken en proberen erachter te komen welke methoden voor het optimaliseren van de belasting van schijfopslag in elk van deze gevallen kunnen worden toegepast.
1. Optimalisatie bij het ontwerpen van een grootschalige Zimbra-installatie
Tijdens de ontwerpfase van een zwaarbelaste Zimbra-installatie zal de beheerder een keuze moeten maken over welk opslagsysteem hij wil gebruiken. Om over dit probleem te beslissen, moet u weten dat de belangrijkste belasting van harde schijven afkomstig is van het MariaDB DBMS dat is opgenomen in de Zimbra Collaboration Suite, de Apache Lucene-zoekmachine en blob-opslag. Om deze softwareproducten onder hoge belasting te kunnen gebruiken, is het daarom noodzakelijk om snelle en betrouwbare apparatuur te gebruiken.
Onder normale omstandigheden kan Zimbra zowel op RAID van harde schijven als op opslag aangesloten via het NFS-protocol worden geïnstalleerd. Voor zeer kleine installaties kunt u Zimbra op een gewone SATA-schijf installeren. In de context van grote installaties vertonen al deze technologieën echter verschillende nadelen in de vorm van een lagere opnamesnelheid of een lage betrouwbaarheid, wat noch voor grote ondernemingen, noch vooral voor SaaS-aanbieders onaanvaardbaar is.
Daarom kun je in grootschalige Zimbra-infrastructuren het beste een SAN gebruiken. Het is deze technologie die momenteel in staat is om de grootste doorvoercapaciteit voor opslagapparaten te bieden en tegelijkertijd, dankzij de mogelijkheid om een grote hoeveelheid cache aan te sluiten, brengt het gebruik ervan praktisch geen noemenswaardige risico's voor de onderneming met zich mee. Het is een goed idee om NVRAM te gebruiken, dat in veel SAN's wordt gebruikt om de schrijfprocessen te versnellen. Maar het is beter om het cachen van opgenomen gegevens op de schijven zelf uit te schakelen, omdat dit kan leiden tot onherstelbare schade aan de media en gegevensverlies als zich stroomproblemen voordoen.
Wat het kiezen van een bestandssysteem betreft, zou de beste keuze zijn om de standaard Linux Ext3/Ext4 te gebruiken. De belangrijkste nuance die aan het bestandssysteem is gekoppeld, is dat het met de parameter moet worden aangekoppeld -noatijd. Deze optie schakelt de functie van het registreren van het tijdstip van de laatste toegang tot bestanden uit, wat betekent dat de belasting bij lezen en schrijven aanzienlijk wordt verminderd. Over het algemeen moet u bij het maken van een ext3- of ext4-bestandssysteem voor Zimbra de volgende hulpprogrammaparameters gebruiken mke2fs:
-j — Een bestandssysteemjournaal maken: Maak het bestandssysteem met een ext3/ext4-journaal.
-L NAAM - Om een volumenaam aan te maken die u vervolgens in /etc/fstab kunt gebruiken
-O dir_index - Om een gehashte zoekboom te gebruiken om het zoeken naar bestanden in grote mappen te versnellen
-m 2 — Om 2% van het volume in grote bestandssystemen te reserveren voor de hoofdmap
-J-maat=400 — Een groot tijdschrift maken
-b4096 — Om de blokgrootte in bytes te bepalen
-ik 10240 - Voor berichtopslag moet deze instelling overeenkomen met de gemiddelde berichtgrootte. U moet goed op deze parameter letten, omdat de waarde ervan later niet kan worden gewijzigd.
Het wordt ook aanbevolen om dit in te schakelen dirsync voor blobopslag, Lucene-opslag voor metagegevens en MTA-wachtrijopslag. Dit moet worden gedaan omdat Zimbra het hulpprogramma meestal gebruikt fsync voor gegarandeerd schrijven van een blob met gegevens naar schijf. Wanneer de Zimbra-mailopslag of MTA echter nieuwe bestanden aanmaakt tijdens de bezorging van berichten, wordt het noodzakelijk om de wijzigingen die in de overeenkomstige mappen plaatsvinden naar schijf te schrijven. Dat is de reden waarom, zelfs als het bestand al naar schijf is geschreven met behulp van fsync, heeft het record van de toevoeging aan de directory mogelijk geen tijd om naar de schijf te worden geschreven en kan als gevolg daarvan verloren gaan als gevolg van een plotselinge serverstoring. Dankzij het gebruik dirsync deze problemen kunnen worden vermeden.
2. Optimalisatie terwijl de Zimbra-infrastructuur actief is
Het komt vaak voor dat na een aantal jaren gebruik van Zimbra het aantal gebruikers aanzienlijk toeneemt en de service elke dag steeds minder responsief wordt. De uitweg uit deze situatie ligt voor de hand: u hoeft alleen maar nieuwe servers aan de infrastructuur toe te voegen, zodat de service weer net zo snel werkt als voorheen. Ondertussen is het niet altijd mogelijk om onmiddellijk nieuwe servers aan de infrastructuur toe te voegen om de prestaties ervan te verbeteren. IT-managers moeten vaak veel tijd besteden aan het afstemmen van de aanschaf van nieuwe servers met de boekhoud- of beveiligingsafdeling; bovendien worden ze vaak in de steek gelaten door leveranciers die een nieuwe server te laat kunnen leveren of zelfs het verkeerde kunnen leveren.
Het is natuurlijk het beste om uw Zimbra-infrastructuur met een reserve op te bouwen, zodat u altijd een reserve heeft voor de uitbreiding ervan en van niemand afhankelijk bent. Als er echter al een fout is gemaakt, kan de IT-manager de gevolgen ervan alleen gladstrijken als zoveel mogelijk. Een IT-manager kan bijvoorbeeld een kleine productiviteitsboost realiseren door Linux-systeemservices die tijdens bedrijf regelmatig toegang hebben tot harde schijven tijdelijk uit te schakelen en daardoor de prestaties van Zimbra negatief kunnen beïnvloeden. U kunt dus tijdelijk uitschakelen:
autofs, netfs - Services voor het op afstand zoeken van bestandssystemen
kopjes — Printservice
xinetd, vsftpd - Ingebouwde *NIX-services die u waarschijnlijk niet nodig zult hebben
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Remote procedure call-services, die gewoonlijk worden gebruikt in combinatie met netwerkbestandssystemen
duiventil, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicaten van de belangrijkste hulpprogramma's in de Zimbra Collaboration Suite
slocate/bijgewerktb - Omdat Zimbra elk bericht in een apart bestand opslaat, kan het dagelijks uitvoeren van de updateb-service problemen veroorzaken, en daarom is het mogelijk om dit handmatig te doen bij de minste belasting van de servers
Het besparen van systeembronnen als gevolg van het uitschakelen van deze services zal niet erg significant zijn, maar zelfs dit kan erg nuttig zijn in omstandigheden die bijna overmacht zijn. Zodra de nieuwe server aan de Zimbra-infrastructuur is toegevoegd, wordt aanbevolen om de eerder uitgeschakelde services opnieuw in te schakelen.
Je kunt de werking van Zimbra ook optimaliseren door de syslog-service naar een aparte server te verplaatsen, zodat deze tijdens het gebruik de harde schijven van mailopslagplaatsen niet belast. Bijna elke computer is geschikt voor deze doeleinden, zelfs een goedkope single-board Raspberry Pi.
Bron: www.habr.com