In een van onze , gewijd aan de planning van infrastructuur bij de implementatie van de Zimbra Collaboration Suite binnen een onderneming, werd aangegeven dat de belangrijkste beperking bij het gebruik van deze oplossing de in- en uitvoersnelheid van opslagapparaten in e-mailopslagplaatsen is. Inderdaad, in de situatie waarin meerdere honderden medewerkers van de onderneming tegelijkertijd toegang hebben tot dezelfde e-mailopslag, kan de bandbreedte voor het lezen en schrijven van informatie op harde schijven onvoldoende zijn voor een responsieve werking van de service. En als dit voor kleinere Zimbra-installaties geen groot probleem vormt, kan dit bij grote ondernemingen en SaaS-providers leiden tot een trage werking van de e-mail en, als gevolg daarvan, een vermindering van de efficiëntie van de medewerkers, evenals schending van SLA's. Daarom moet bij het ontwerpen en exploiteren van grootschalige Zimbra-installaties bijzondere aandacht worden besteed aan de optimalisatie van de werking van harde schijven in de e-mailopslag. Laten we twee casussen bekijken en proberen te achterhalen welke methoden voor het optimaliseren van de belasting op opslagmedia in elk geval kunnen worden toegepast.
1. Optimalisatie bij het ontwerpen van een grootschalige Zimbra-installatie
In de ontwerpfase van een hoogbelaste Zimbra-installatie moet de beheerder beslissen welke gegevensopslagsysteem te gebruiken. Om deze vraag te beantwoorden, moet men weten dat de belangrijkste belasting op harde schijven wordt veroorzaakt door de databasesystemen MariaDB, het zoek systeem Apache Lucene, en de opslag van BLOB-objecten die deel uitmaken van de Zimbra Collaboration Suite. Daarom is het noodzakelijk om snel en betrouwbaar materiaal te gebruiken voor het functioneren van deze softwareproducten onder hoge belasting.
Onder normale omstandigheden kan Zimbra zowel op RAID-harde schijven als op opslagmedia die via het NFS-protocol zijn verbonden, worden geïnstalleerd. Bij heel kleine installaties kan Zimbra op een reguliere SATA-schijf worden geïnstalleerd. Echter, in het geval van grote installaties vertonen al deze technologieën verschillende tekortkomingen in de vorm van verminderde schrijfsnelheid of lage betrouwbaarheid, wat onacceptabel is voor grote ondernemingen en, nog meer, voor SaaS-providers.
Daarom is het gebruik van een SAN in grootschalige infrastructuren van Zimbra het beste. Dit type opslag is momenteel in staat om de hoogste doorvoersnelheid voor opslagapparaten te bieden en, dankzij de mogelijkheid om een groot aantal caches aan te sluiten, brengt het gebruik ervan vrijwel geen significante risico's voor bedrijven met zich mee. Het is een goed idee om NVRAM te gebruiken, dat in veel SAN-systemen wordt toegepast om de prestaties tijdens het schrijven te versnellen. Het is echter beter om de caching van geschreven gegevens op de schijven zelf uit te schakelen, omdat dit kan leiden tot onherstelbare schade aan de media en gegevensverlies in geval van stroomproblemen.
Wat betreft de keuze van het bestandssysteem is de optimale keuze het gebruik van de standaard Linux Ext3/Ext4. Het belangrijkste punt met betrekking tot het bestandssysteem is dat je het moet mounten met de parameter -noatime. Deze parameter schakelt de functie voor het vastleggen van de tijd van de laatste toegang tot bestanden uit, waardoor de lees- en schrijflast aanzienlijk wordt verminderd. Over het algemeen moeten bij het aanmaken van een ext3- of ext4-bestandssysteem voor Zimbra de volgende parameters van de tool worden gebruikt: mke2fs:
-j — Voor het aanmaken van een besturingsjournal van het bestandssysteem. Maak het bestandssysteem aan met een ext3/ext4-journal.
-L NAAM — Voor het aanmaken van een volume-label, zodat het later in /etc/fstab kan worden gebruikt.
-O dir_index — Voor het gebruik van een gehasht zoekboom voor het versnellen van de bestandszoekopdrachten in grote directories.
-m 2 — Voor het reserveren van 2% van de ruimte in grote bestandssystemen voor de root-directory.
-J size=400 — Voor het aanmaken van een groot journal.
-b 4096 — Voor het bepalen van de blokgrootte in bytes.
-i 10240 — Voor de message storage moet deze parameter overeenkomen met de gemiddelde grootte van berichten. Het is belangrijk om deze parameter zorgvuldig te overwegen, aangezien de waarde later niet kan worden gewijzigd.
Daarnaast wordt aanbevolen om dirsync in te schakelen voor de BLOB-objectopslag, de metadatazoekopslag van Lucene en de wachtrijopslag van MTA. Dit moet gedaan worden omdat Zimbra doorgaans het hulpprogramma gebruikt fsync voor een gegarandeerde schrijfactie van blobs met gegevens naar de schijf. Echter, wanneer het e-mailopslag Zimbra of MTA nieuwe bestanden aanmaakt tijdens het afleveren van berichten, ontstaat er een noodzaak om de wijzigingen in de desbetreffende mappen naar de schijf te schrijven. Daarom kan het voorkomen dat, zelfs als het bestand al op de schijf is geschreven met behulp van fsync, de registratie van zijn toevoeging in de directory mogelijk niet op tijd naar de schijf is geschreven en daardoor verloren kan gaan door een plotselinge serverstoring. Dankzij het gebruik van dirsync kunnen deze problemen worden vermeden.
2. Optimalisatie bij een operationele Zimbra-infrastructuur
Het komt vaak voor dat na enkele jaren van gebruik het aantal Zimbra-gebruikers aanzienlijk toeneemt en de werking van de service elke dag minder responsief wordt. De oplossing voor deze situatie is duidelijk: er moeten gewoon nieuwe servers aan de infrastructuur worden toegevoegd, zodat de service weer zo snel functioneert als voorheen. Echter, het is beslist niet altijd mogelijk om direct nieuwe servers aan de infrastructuur toe te voegen om de prestaties te verbeteren. Vaak moeten IT-managers langdurig goedkeuring vragen voor de aanschaf van nieuwe servers bij de boekhouding of de beveiligingsafdeling, en bovendien zijn leveranciers soms niet betrouwbaar en kunnen ze een nieuwe server te laat leveren of zelfs iets totaal anders afleveren.
Het is vanzelfsprekend dat het het beste is om je Zimbra-infrastructuur met een buffer te bouwen, zodat je altijd ruimte hebt voor uitbreiding en niet van iemand anders afhankelijk bent, maar als de fout eenmaal is gemaakt, kan de IT-manager alleen maar proberen de gevolgen te verzachten. Zo kan de IT-manager bijvoorbeeld een kleine prestatieverbetering bereiken door tijdelijke uitschakeling van systeemdiensten in Linux, die tijdens hun werking regelmatig de harde schijven aanspreken en daardoor de snelheid van Zimbra negatief kunnen beïnvloeden. Tijdelijk kunnen de volgende diensten worden uitgeschakeld:
autofs, netfs — Diensten voor het detecteren van externe bestandssystemen
cups — De printservice
xinetd, vsftpd — Ingebouwde *NIX-diensten die je waarschijnlijk niet nodig hebt
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Diensten voor remote procedure calls die doorgaans worden gebruikt in combinatie met netwerklocatiesystemen
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Dubbele hoofdprogramma's die deel uitmaken van de Zimbra Collaboration Suite
slocate/updatedb — Aangezien Zimbra elke boodschap in een apart bestand opslaat, kan een dagelijkse uitvoering van de updatedb-service problemen veroorzaken. Daarom kan het het beste handmatig gedaan worden tijdens de momenten van de laagste belasting op de servers.
De besparing van systeembronnen door deze diensten uit te schakelen zal niet heel significant zijn, maar zelfs dit kan erg nuttig zijn in uitzonderlijke omstandigheden. Zodra de nieuwe server is toegevoegd aan de Zimbra-infrastructuur, wordt aangeraden om de eerder uitgeschakelde diensten weer in te schakelen.
Daarnaast kan de werking van Zimbra geoptimaliseerd worden door de syslog-service naar een aparte server te verplaatsen, zodat deze geen belasting legt op de harde schijven van de mailopslag tijdens het gebruik. Bijna elke computer kan hiervoor gebruikt worden, zelfs een goedkope single-board computer zoals de Raspberry Pi.
Bron: habr.com
