I en af vores , som handlede om planlægning af infrastrukturen ved implementeringen af Zimbra Collaboration Suite i virksomheder, blev det nævnt, at den største begrænsning ved brugen af denne løsning er ind- og udlæsningstempoet for diskene i e-maillagrerne. Og i sandhed, når flere hundrede medarbejdere i virksomheden samtidig tilgår det samme e-maillager, kan båndbredden til at læse og skrive information til harddiske være utilstrækkelig for en responsiv service. Og hvis dette ikke bliver et stort problem for små Zimbra-installationer, kan det i tilfælde af store virksomheder og SaaS-udbydere føre til en uresponsiv e-mail og deraf følgende nedsat medarbejdereffektivitet samt overtrædelse af SLA. Derfor er det vigtigt at fokusere på at optimere harddiskarbejdet i e-maillageret ved design og drift af store Zimbra-installationer. Lad os se på to cases og forsøge at finde ud af, hvilke metoder til optimering af belastningen på diskstorage der kan anvendes i hver af dem.
1. Optimering ved design af en stor installation af Zimbra
Ved designfasen af en højbelastningsinstallation af Zimbra skal administratorerne vælge, hvilket datalagringssystem de vil anvende. For at afgøre dette spørgsmål er det vigtigt at vide, at den primære belastning på harddiskene skabes af databasen MariaDB, søgesystemet Apache Lucene samt opbevaringen af BLOB-objekter, som udgør Zimbra Collaboration Suite. Det er derfor nødvendigt at anvende hurtig og pålideligt udstyr til at køre disse softwareprodukter under høje belastninger.
Under almindelige forhold kan Zimbra installeres både på en RAID af harddiske og på lagre, der forbindes via NFS-protokollen. I tilfælde af meget små installationer kan Zimbra også installeres på en almindelig SATA-disk. Men under forholdene ved store installationer viser alle disse teknologier forskellige ulemper i form af nedsat skrivhastighed eller lav pålidelighed, hvilket er uacceptabelt hverken for store virksomheder eller, endnu mindre, for SaaS-udbydere.
Derfor er det bedst at bruge SAN i store Zimbra-infrastrukturer. Dette system kan i øjeblikket levere den største båndbredde til lagringsenheder, og ved mulighed for tilslutning af et stort antal cache-enheder bærer det næsten ingen væsentlige risici for virksomheden. Det ville være en god idé at anvende NVRAM, som bruges i mange SAN for at fremskynde skriveprocesser. For caching af data på selve diske er det derimod bedst at deaktivere det, da det kan føre til uoprettelig skade på medierne og datatab i tilfælde af strømafbrydelser.
Når det kommer til valg af filsystem, vil det optimale valg være at bruge de standard Linux-filsystemer Ext3/Ext4. Den vigtigste detalje ved filsystemet er, at det skal monteres med parameteren -noatime. Denne parameter deaktiverer funktionen til at registrere tidspunktet for den seneste adgang til filer, hvilket derfor reducerer belastningen på læse- og skriveoperationer betydeligt. Generelt bør man ved oprettelse af et ext3 eller ext4-filsystem til Zimbra bruge følgende parametre fra værktøjet mke2fs:
-j — Til at oprette et filsystem med et ext3/ext4 journal.
-L NAVN — For at oprette et volumen navn, så det senere kan bruges i /etc/fstab
-O dir_index — For at anvende et hash-baseret søgetræ for at fremskynde filsøgningsprocessen i store mapper
-m 2 — For at reservere 2% af kapaciteten i store filsystmer til rodkataloget
-J size=400 — For at oprette et stort journal
-b 4096 — For at bestemme blokkens størrelse i byte
-i 10240 — For meddelelsesopbevaring skal denne parameter svare til den gennemsnitlige størrelse af meddelelserne. Man bør være opmærksom på denne parameter, da dens værdi ikke kan ændres senere
Derudover anbefales det at aktivere dirsync til BLOB-objektlagring, Lucene-søgemetadataopbevaring og MTA-kølagring. Dette bør gøres, da Zimbra normalt anvender værktøjet fsync for guaranteed recording of blobs with data to disk. However, when the Zimbra mail storage or MTA creates new files during message delivery, there is a need to write to disk the changes made in the corresponding folders. That is why even if the file has already been recorded on disk using fsync, the record of its addition in the directories may not be written to disk in time and as a result, it may be lost due to a sudden server failure. Thanks to the use of dirsync these problems can be avoided.
2. Optimization in a Working Zimbra Infrastructure
It often happens that after several years of operation the number of users of Zimbra significantly increases and the service becomes less and less responsive day by day. The way out of this situation is obvious: it is necessary to simply add new servers to the infrastructure so that the service works as quickly as it did before. Meanwhile, it is not always possible to immediately add new servers to the infrastructure to improve its performance. Often, IT managers have to spend a long time coordinating the purchase af nye servere with accounting or the security department; moreover, suppliers often let you down, delivering a new server late or bringing something entirely different.
Of course, it is best to build your Zimbra infrastructure with a reserve, so that you always have a buffer for its expansion and do not depend on anyone, but if a mistake has already been made, the IT manager can only smooth over its consequences as much as possible. For example, the IT manager can achieve a slight increase in performance by temporarily disabling Linux system services that regularly access hard disks and can negatively affect Zimbra's speed. Temporarily, you can disable:
autofs, netfs — Remote file system discovery services
cups — Print service
xinetd, vsftpd — Built-in *NIX services that you are unlikely to need
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Remote procedure call services that are usually used in conjunction with network file systems
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicates of core utilities included in the Zimbra Collaboration Suite
slocate/updatedb Da Zimbra gemmer hver besked i en separat fil, kan en daglig kørsel af tjenesten updatedb føre til problemer, og det anbefales derfor at udføre dette manuelt i perioder med lavest belastning på serverne.
Spareressourcerne ved at deaktivere disse tjenester vil ikke være meget betydelige, men selv dette kan være nyttigt under næsten nødssituationer. Når den nye server er tilføjet til Zimbra-infrastrukturen, anbefales det at genaktivere de tidligere deaktiverede tjenester.
Det er også muligt at optimere Zimbras drift ved at flytte syslog-tjenesten til en separat server, så den ikke belaster harddiskene i maillagrene under driften. Næsten enhver computer, lige fra en billig enkeltskift Raspberry Pi, kan bruges til dette formål.
Kilde: habr.com
