I en af vores , dedikeret til infrastrukturplanlægning ved implementering af Zimbra Collabortion Suite i en virksomhed, blev det sagt, at hovedbegrænsningen i driften af denne løsning er I/O-hastigheden af diskenheder i postlagre. Faktisk, på et tidspunkt, hvor flere hundrede ansatte i en virksomhed samtidig får adgang til det samme postlager, er kanalbredden til at skrive og læse information fra harddiske muligvis ikke nok til, at tjenesten reagerer. Og hvis for små installationer af Zimbra dette ikke vil være et særligt problem, så i tilfælde af store virksomheder og SaaS-udbydere, kan alt dette føre til ikke-svarende e-mail og som et resultat et fald i medarbejdernes effektivitet såvel som en krænkelse af SLA'er. Det er derfor, når man designer og driver store Zimbra-installationer, skal man være særlig opmærksom på at optimere ydeevnen af harddiske i postlagring. Lad os se på to tilfælde og forsøge at finde ud af, hvilke metoder til at optimere belastningen på disklager, der kan anvendes i hver af dem.
1. Optimering ved design af en storstilet Zimbra installation
Under designfasen af en Zimbra-installation med høj belastning skal administratoren træffe et valg om, hvilket lagersystem der skal bruges. For at tage stilling til dette spørgsmål, skal du vide, at hovedbelastningen på harddiske kommer fra MariaDB DBMS inkluderet i Zimbra Collaboration Suite, Apache Lucene-søgemaskinen og blob-lagring. Det er derfor, for at kunne betjene disse softwareprodukter under høje belastningsforhold, er det nødvendigt at bruge højhastigheds og pålideligt udstyr.
Under normale forhold kan Zimbra installeres både på RAID på harddiske og på lager tilsluttet via NFS-protokollen. Ved meget små installationer kan du installere Zimbra på et almindeligt SATA-drev. Men i forbindelse med store installationer viser alle disse teknologier forskellige ulemper i form af reduceret optagehastighed eller lav pålidelighed, hvilket hverken er uacceptabelt for store virksomheder eller især for SaaS-udbydere.
Derfor er det bedst at bruge et SAN i store Zimbra-infrastrukturer. Det er denne teknologi, der i øjeblikket er i stand til at levere den største gennemstrømning til lagerenheder og samtidig, takket være evnen til at forbinde en stor mængde cache, udgør dens brug praktisk talt ikke nogen væsentlige risici for virksomheden. Det er en god idé at bruge NVRAM, som bruges i mange SAN'er til at fremskynde tingene under skrivning. Men det er bedre at deaktivere caching af optagede data på selve diskene, da det kan føre til uoprettelig skade på mediet og tab af data, hvis der opstår strømproblemer.
Hvad angår valg af filsystem, ville det bedste valg være at bruge standard Linux Ext3/Ext4. Hovednuancen forbundet med filsystemet er, at det skal monteres med parameteren -noatime. Denne mulighed vil deaktivere funktionen til at registrere tidspunktet for den sidste adgang til filer, hvilket betyder, at det i høj grad vil reducere belastningen på læsning og skrivning. Generelt, når du opretter et ext3- eller ext4-filsystem til Zimbra, bør du bruge følgende hjælpeparametre mke2fs:
-j — For at oprette en filsystemjournal Opret filsystemet med en ext3/ext4-journal.
-L NAVN - For at oprette et volumennavn til derefter at bruge i /etc/fstab
-O dir_index - At bruge et hashed søgetræ til at fremskynde filsøgninger i store mapper
-m 2 — At reservere 2% af volumen i store filsystemer til rodmappen
-J størrelse=400 — At skabe et stort magasin
-b 4096 — For at bestemme blokstørrelsen i bytes
-jeg 10240 - For beskedlagring skal denne indstilling svare til den gennemsnitlige beskedstørrelse. Du bør være meget opmærksom på denne parameter, da dens værdi ikke kan ændres senere.
Det anbefales også at aktivere dirsync til blob-lagring, Lucene-søgemetadatalagring og MTA-kølagring. Dette bør gøres, fordi Zimbra normalt bruger værktøjet fsync for garanteret skrivning af en klat med data til disk. Når Zimbra-postbutikken eller MTA'en opretter nye filer under levering af beskeder, bliver det imidlertid nødvendigt at skrive de ændringer, der sker i de tilsvarende mapper, til disken. Det er derfor, selvom filen allerede er skrevet til disk ved hjælp af fsync, kan registreringen af dens tilføjelse til biblioteket ikke have tid til at blive skrevet til disken og kan som følge heraf gå tabt på grund af en pludselig serverfejl. Takket være brugen dirsync disse problemer kan undgås.
2. Optimering med Zimbra-infrastruktur kørende
Det sker ofte, at efter flere års brug af Zimbra stiger antallet af brugere markant, og tjenesten bliver mindre og mindre responsiv hver dag. Vejen ud af denne situation er indlysende: Du skal blot tilføje nye servere til infrastrukturen, så tjenesten fungerer igen lige så hurtigt som før. I mellemtiden er det ikke altid muligt umiddelbart at tilføje nye servere til infrastrukturen for at øge dens ydeevne. It-chefer skal ofte bruge lang tid på at koordinere indkøb af nye servere med regnskabs- eller sikkerhedsafdelingen, desuden bliver de ofte svigtet af leverandører, der kan levere en ny server for sent eller endda levere det forkerte.
Selvfølgelig er det bedst at bygge din Zimbra-infrastruktur med en reserve for altid at have en reserve til dens ekspansion og ikke være afhængig af nogen, men hvis der allerede er begået en fejl, kan it-chefen kun udjævne konsekvenserne som meget som muligt. For eksempel kan en it-chef opnå et lille produktivitetsløft ved midlertidigt at deaktivere Linux-systemtjenester, der regelmæssigt får adgang til harddiske under drift og derfor kan påvirke Zimbras ydeevne negativt. Så du kan midlertidigt deaktivere:
autofs, netfs - Fjernopdagelse af filsystemer
kopper — Printservice
xinetd, vsftpd - Indbyggede *NIX-tjenester, som du sandsynligvis ikke får brug for
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Fjernprocedureopkaldstjenester, som normalt bruges i forbindelse med netværksfilsystemer
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Dubletter af de vigtigste hjælpeprogrammer inkluderet i Zimbra Collaboration Suite
slocate/opdateretb - Da Zimbra gemmer hver besked i en separat fil, kan det give problemer at køre updatedb-tjenesten hver dag, og derfor er det muligt at gøre dette manuelt under den mindste belastning på serverne
Besparelse af systemressourcer som følge af deaktivering af disse tjenester vil ikke være særlig vigtig, men selv dette kan være meget nyttigt under forhold tæt på force majeure. Når den nye server er tilføjet til Zimbra-infrastrukturen, anbefales det at genaktivere de tidligere deaktiverede tjenester.
Du kan også optimere driften af Zimbra ved at flytte syslog-tjenesten til en separat server, så den under drift ikke indlæser harddiskene til postlagre. Næsten enhver computer er egnet til disse formål, selv en billig Raspberry Pi med enkelt bord.
Kilde: www.habr.com