I en av våra , tillägnad infrastrukturplanering vid implementering av Zimbra Collabortion Suite i ett företag, sades det att den huvudsakliga begränsningen i driften av denna lösning är I/O-hastigheten för diskenheter i e-postlagringar. Faktum är att vid en tidpunkt då flera hundra anställda i ett företag samtidigt får åtkomst till samma e-postlagring, kanske kanalbredden för att skriva och läsa information från hårddiskar inte räcker för att tjänsten ska fungera lyhört. Och om för små installationer av Zimbra detta inte kommer att vara ett särskilt problem, då i fallet med stora företag och SaaS-leverantörer, kan allt detta leda till att e-post inte svarar och, som ett resultat, en minskning av anställdas effektivitet, såväl som en kränkning av SLA. Det är därför, vid design och drift av storskaliga Zimbra-installationer, särskild uppmärksamhet bör ägnas åt att optimera prestanda för hårddiskar i postlagring. Låt oss titta på två fall och försöka ta reda på vilka metoder för att optimera belastningen på disklagring som kan användas i vart och ett av dem.
1. Optimering vid design av en storskalig Zimbra-installation
Under designfasen av en högbelastad Zimbra-installation måste administratören göra ett val om vilket lagringssystem som ska användas. För att ta ställning till den här frågan bör du veta att huvudbelastningen på hårddiskar kommer från MariaDB DBMS som ingår i Zimbra Collaboration Suite, Apache Lucene-sökmotorn och bloblagring. Det är därför för att kunna använda dessa mjukvaruprodukter under hög belastning, är det nödvändigt att använda höghastighets och pålitlig utrustning.
Under normala förhållanden kan Zimbra installeras både på RAID på hårddiskar och på lagring ansluten via NFS-protokollet. För mycket små installationer kan du installera Zimbra på en vanlig SATA-enhet. Men i samband med stora installationer uppvisar alla dessa tekniker olika nackdelar i form av minskad inspelningshastighet eller låg tillförlitlighet, vilket varken är oacceptabelt för stora företag eller, särskilt för SaaS-leverantörer.
Det är därför det är bäst att använda ett SAN i storskaliga Zimbra-infrastrukturer. Det är denna teknik som för närvarande kan ge den största genomströmningen för lagringsenheter och samtidigt, tack vare möjligheten att ansluta en stor mängd cache, innebär användningen praktiskt taget inga betydande risker för företaget. Det är en bra idé att använda NVRAM, som används i många SAN för att påskynda saker under skrivningar. Men det är bättre att inaktivera cachelagring av inspelade data på själva diskarna, eftersom det kan leda till irreparabel skada på media och förlust av data om strömproblem uppstår.
När det gäller att välja ett filsystem skulle det bästa valet vara att använda standard Linux Ext3/Ext4. Huvudnyansen förknippad med filsystemet är att det ska monteras med parametern -noatime. Det här alternativet kommer att inaktivera funktionen för att registrera tidpunkten för den senaste åtkomsten till filer, vilket innebär att det kommer att avsevärt minska belastningen på läsning och skrivning. I allmänhet, när du skapar ett ext3- eller ext4-filsystem för Zimbra, bör du använda följande verktygsparametrar mke2fs:
-j — För att skapa en filsystemsjournal Skapa filsystemet med en ext3/ext4-journal.
-L NAMN - För att skapa ett volymnamn att sedan använda i /etc/fstab
-O dir_index - Att använda ett hashat sökträd för att påskynda filsökningar i stora kataloger
-m 2 — Att reservera 2 % av volymen i stora filsystem för rotkatalogen
-J storlek=400 — Att skapa en stor tidning
-b 4096 — För att bestämma blockstorleken i byte
-jag 10240 - För meddelandelagring bör denna inställning motsvara den genomsnittliga meddelandestorleken. Du bör vara mycket uppmärksam på denna parameter, eftersom dess värde inte kan ändras senare.
Det rekommenderas också att aktivera dirsync för bloblagring, Lucene sökmetadatalagring och MTA-kölagring. Detta bör göras eftersom Zimbra vanligtvis använder verktyget fsync för garanterad skrivning av en blob med data till disk. Men när Zimbra postbutik eller MTA skapar nya filer under meddelandeleverans, blir det nödvändigt att skriva till disken de ändringar som sker i motsvarande mappar. Det är därför, även om filen redan har skrivits till disk med hjälp av fsync, kan det hända att registreringen av dess tillägg till katalogen inte hinner skrivas till disken och som ett resultat kan den gå förlorad på grund av ett plötsligt serverfel. Tack vare användningen dirsync dessa problem kan undvikas.
2. Optimering med Zimbra-infrastruktur igång
Det händer ofta att efter flera års användning av Zimbra ökar antalet användare avsevärt och tjänsten blir mindre och mindre responsiv för varje dag. Vägen ut ur denna situation är uppenbar: du behöver bara lägga till nya servrar till infrastrukturen så att tjänsten fungerar lika snabbt som tidigare. Samtidigt är det inte alltid möjligt att omedelbart lägga till nya servrar till infrastrukturen för att öka dess prestanda. IT-chefer får ofta lägga lång tid på att samordna inköp av nya servrar med ekonomi- eller säkerhetsavdelningen, dessutom blir de ofta svikna av leverantörer som kan leverera en ny server sent eller till och med leverera fel.
Naturligtvis är det bäst att bygga din Zimbra-infrastruktur med en reserv för att alltid ha en reserv för dess expansion och inte vara beroende av någon, men om ett misstag redan har begåtts kan IT-chefen bara jämna ut dess konsekvenser som så mycket som möjligt. Till exempel kan en IT-chef uppnå en liten produktivitetsökning genom att tillfälligt inaktivera Linux-systemtjänster som regelbundet kommer åt hårddiskar under drift och kan därför påverka Zimbras prestanda negativt. Så du kan tillfälligt inaktivera:
autofs, netfs - Fjärrupptäcktstjänster för filsystem
koppar — Utskriftstjänst
xinetd, vsftpd - Inbyggda *NIX-tjänster som du förmodligen inte kommer att behöva
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Fjärrproceduranropstjänster, som vanligtvis används i samband med nätverksfilsystem
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Dubletter av de viktigaste verktygen som ingår i Zimbra Collaboration Suite
slocate/updatedb - Eftersom Zimbra lagrar varje meddelande i en separat fil kan det orsaka problem att köra updatedb-tjänsten varje dag, och därför är det möjligt att göra detta manuellt under minsta belastning på servrarna
Att spara systemresurser till följd av att dessa tjänster inaktiveras kommer inte att vara särskilt betydande, men även detta kan vara mycket användbart under förhållanden nära force majeure. När den nya servern har lagts till i Zimbra-infrastrukturen, rekommenderas det att återaktivera de tidigare inaktiverade tjänsterna.
Du kan också optimera driften av Zimbra genom att flytta syslog-tjänsten till en separat server så att den under drift inte laddar hårddiskarna för e-postlagringar. Nästan vilken dator som helst är lämplig för dessa ändamål, även en billig Raspberry Pi med ett kort.
Källa: will.com