Optimering av arbetet med e-postlagringssystem i Zimbra Collaboration Suite

I en av våra tidigare artiklar., som handlar om planeringen av infrastrukturen vid implementeringen av Zimbra Collaboration Suite i företag, nämndes att den största begränsningen vid användningen av denna lösning är läshastigheten för lagringsenheter i e-postlagren. Och faktiskt, under de tider när flera hundra anställda på företaget får tillgång till samma e-postlager samtidigt, kan bandbredden för läsning och skrivning av information från hårddiskarna bli otillräcklig för en responsiv tjänst. Om detta kanske inte är ett stort problem för små installationer av Zimbra, så kan det i fallet med stora företag och SaaS-leverantörer leda till att e-posten blir oresponsiv och därmed minska de anställdas effektivitet, samt bryta SLA. Just därför är det viktigt att vid design och drift av storskaliga Zimbra-installationer fokusera på att optimera hårddiskarnas arbete i e-postlagret. Låt oss titta på två fall och försöka ta reda på vilka metoder för att optimera belastningen på lagringsenheterna som kan tillämpas i vart och ett av dem.

1. Optimering vid planering av en storskalig Zimbra-installation

Vid designfasen av en högbelastad Zimbra-installation måste dess administratör fatta beslut om vilken lagringssystem som ska användas. För att avgöra detta behöver man veta att den största belastningen på hårddiskarna kommer från databashanteringssystemet MariaDB, söksystemet Apache Lucene samt lagringen av BLOB-objekt inom Zimbra Collaboration Suite. Just därför är det nödvändigt att använda snabb och pålitlig hårdvara för dessa programvaror under hög belastning.

Under normala omständigheter kan Zimbra installeras både på en RAID av hårddiskar och på lagringssystem som är kopplade med NFS-protokollet. I fall av mycket små installationer kan Zimbra installeras på en vanlig SATA-disk. Men under förhållanden med stora installationer visar alla dessa teknologier olika nackdelar i form av minskad skrivhastighet eller låg tillförlitlighet, vilket är oacceptabelt för stora företag och ännu mer för SaaS-leverantörer.

Det är därför SAN är det bästa valet för Zimbra i storskaliga infrastrukturer. Just nu kan det erbjuda den högsta genomströmningen för lagringsenheter och tack vare möjligheten att ansluta stora mängder cache innebär dess användning i princip inga betydande risker för företaget. En bra idé är att använda NVRAM, som används i många SAN för att påskynda skrivprocesser. Att aktivera cachelagring av skrivna data på diskar bör dock göras med försiktighet, eftersom det kan leda till oåterkalleliga skador på medierna och dataförlust vid strömproblem.

När det gäller valet av filsystem är standarderna för Linux, Ext3/Ext4, det optimala valet. Den viktigaste punkten gällande filsystemet är att den bör monteras med parametern -noatime. Denna parameter inaktiverar funktionen för att registrera tidpunkten för senaste åtkomst till filer, vilket kraftigt minskar belastningen på läsning och skrivning. Generellt bör följande parametrar användas vid skapande av ext3 eller ext4 filsystem för Zimbra mke2fs:

-j — För att skapa en filsystemjournal, skapa filsystemet med en ext3/ext4-journal.
-L NAMN — För att ge volymen ett namn som sedan används i /etc/fstab.
-O dir_index — För att använda en hash-trädstruktur för att påskynda sökningar i stora kataloger.
-m 2 — För att reservera 2% av utrymmet i stora filsystem för rotkatalogen.
-J size=400 — För att skapa en stor journal.
-b 4096 — För att bestämma blockstorleken i byte.
-i 10240 — För meddelandebehållaren ska denna parameter motsvara det genomsnittliga meddelandestorleken. Var försiktig med denna parameter, eftersom den inte kan ändras senare.

Dessutom rekommenderas det att aktivera dirsync för BLOB-behållare, mete-data sökning med Lucene och MTA:s köbehandlare. Detta bör göras av den anledningen att Zimbra ofta använder verktyget. fsync för att säkerställa att blob-data skrivs till disken. Men när Zimbra-postlagring eller MTA skapar nya filer vid leveransen av meddelanden, uppstår behovet av att skriva ändringar till disken som har inträffat i respektive mappar. Det är därför som även om filen redan har skrivits till disken med hjälp av fsync, kan registreringen av dess tillägg i katalogen misslyckas med att skrivas till disken och i resultatet kan gå förlorad på grund av ett plötsligt serverfel. Tack vare användningen av dirsync kan dessa problem undvikas.

2. Optimering av den fungerande Zimbra-infrastrukturen

Ofta händer det att antalet användare av Zimbra ökar betydligt efter flera års drift, och tjänstens responsivitet blir sämre för varje dag. Lösningen på denna situation är uppenbar: det krävs att nya servrar läggs till i infrastrukturen så att tjänsten åter kan fungera lika snabbt som tidigare. Däremot har man inte alltid möjlighet att omedelbart lägga till nya servrar i infrastrukturen för att öka dess prestanda. Ofta måste IT-chefer spendera lång tid på att få godkännande för inköp nya servrar från ekonomidepartementet eller säkerhetsavdelningen, dessutom kan leverantörer ofta ställa till problem, genom att leverera en ny server för sent eller till och med något helt annat än vad som behövs.

Självklart är det bäst att bygga sin Zimbra-infrastruktur med en buffert, så man alltid har kapacitet för att utöka den och inte är beroende av någon annan, men om misstaget redan har gjorts, är det upp till IT-chefen att mildra konsekvenserna så mycket som möjligt. Till exempel kan en IT-chef uppnå en liten ökning av prestandan genom att tillfälligt stänga av systemtjänster i Linux som regelbundet begär åtkomst till hårddiskarna och därmed kan påverka hastigheten på Zimbra negativt. Så, under en tid kan man stänga av:

autofs, netfs — Tjänster för upptäckte av fjärrfilsystem
cups — Utskriftstjänst
xinetd, vsftpd — Inbyggda tjänster i *NIX som sannolikt inte kommer att behövas
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Tjänster för fjärrproceduranrop som vanligtvis används i samband med nätverksfilsystem
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicerade grundläggande verktyg som ingår i Zimbra Collaboration Suite
slocate/updatedb Eftersom Zimbra lagrar varje meddelande i en separat fil kan en daglig körning av tjänsten updatedb leda till problem, och därför kan detta göras manuellt under perioder med låg belastning på servrarna.

Besparingen av systemresurser som resultat av att inaktivera dessa tjänster kommer inte att vara särskilt betydande, men även detta kan vara mycket användbart under svåra förhållanden. När den nya servern har lagts till i Zimbra-infrastrukturen rekommenderas det att återaktivera de tidigare inaktiverade tjänsterna.

Det är också möjligt att optimera Zimbra:s prestanda genom att flytta syslog-tjänsten till en separat server, så att den under drift inte belastar hårddiskarna i e-postlagringen. För detta syfte passar nästan vilken dator som helst, till och med en billig enkortsdator som Raspberry Pi.

Källa: habr.com