I en av våre , dedikert til infrastrukturplanlegging ved implementering av Zimbra Collabortion Suite i en bedrift, ble det sagt at hovedbegrensningen i driften av denne løsningen er I/O-hastigheten til diskenheter i postlagring. Faktisk, i en tid hvor flere hundre ansatte i en bedrift samtidig får tilgang til den samme e-postlagringen, kan det hende at kanalbredden for å skrive og lese informasjon fra harddisker ikke er nok for responsiv drift av tjenesten. Og hvis for små installasjoner av Zimbra dette ikke vil være et spesielt problem, kan alt dette i tilfelle av store bedrifter og SaaS-leverandører føre til at e-post ikke svarer, og som et resultat, en reduksjon i ansattes effektivitet, så vel som et brudd av SLAer. Det er derfor, når du designer og drifter store Zimbra-installasjoner, bør spesiell oppmerksomhet rettes mot å optimalisere ytelsen til harddisker i postlagring. La oss se på to tilfeller og prøve å finne ut hvilke metoder for å optimalisere belastningen på disklagring som kan brukes i hver av dem.
1. Optimalisering ved utforming av en storskala Zimbra-installasjon
Under designfasen av en høylastende Zimbra-installasjon, må administratoren velge hvilket lagringssystem som skal brukes. For å bestemme deg for dette problemet, bør du vite at hovedbelastningen på harddisker kommer fra MariaDB DBMS inkludert i Zimbra Collaboration Suite, Apache Lucene-søkemotoren og blob-lagring. Derfor er det nødvendig å bruke høyhastighets og pålitelig utstyr for å kunne betjene disse programvareproduktene under høye belastningsforhold.
Under normale forhold kan Zimbra installeres både på RAID på harddisker og på lagring tilkoblet via NFS-protokollen. For svært små installasjoner kan du installere Zimbra på en vanlig SATA-stasjon. I sammenheng med store installasjoner viser imidlertid alle disse teknologiene ulike ulemper i form av redusert opptakshastighet eller lav pålitelighet, noe som verken er uakseptabelt for store bedrifter eller, spesielt for SaaS-leverandører.
Dette er grunnen til at det i store Zimbra-infrastrukturer er best å bruke et SAN. Det er denne teknologien som for øyeblikket er i stand til å gi den største gjennomstrømningen for lagringsenheter, og samtidig, takket være muligheten til å koble til en stor mengde cache, utgjør bruken praktisk talt ikke noen betydelig risiko for bedriften. Det er en god idé å bruke NVRAM, som brukes i mange SAN-er for å få fart på ting under skriving. Men det er bedre å deaktivere caching av innspilte data på selve diskene, da det kan føre til uopprettelig skade på media og tap av data hvis det oppstår strømproblemer.
Når det gjelder valg av filsystem, vil det beste valget være å bruke standard Linux Ext3/Ext4. Hovednyansen knyttet til filsystemet er at det skal monteres med parameteren -noatime. Dette alternativet vil deaktivere funksjonen for å registrere tidspunktet for siste tilgang til filer, noe som betyr at det vil redusere belastningen på lesing og skriving betraktelig. Generelt, når du oppretter et ext3- eller ext4-filsystem for Zimbra, bør du bruke følgende verktøyparametere kone2fs:
-j — For å opprette en filsystemjournal Lag filsystemet med en ext3/ext4-journal.
-L NAVN - For å lage et volumnavn for deretter å bruke i /etc/fstab
-O dir_index - Å bruke et hashed søketre for å øke hastigheten på filsøk i store kataloger
-m 2 — Å reservere 2 % av volumet i store filsystemer for rotkatalogen
-J størrelse=400 — Å lage et stort magasin
-b 4096 — For å bestemme blokkstørrelsen i byte
-jeg 10240 - For meldingslagring skal denne innstillingen samsvare med gjennomsnittlig meldingsstørrelse. Du bør være nøye med denne parameteren, siden verdien ikke kan endres senere.
Det anbefales også å aktivere dirsync for blob-lagring, Lucene-søke-metadatalagring og MTA-kølagring. Dette bør gjøres fordi Zimbra vanligvis bruker verktøyet fsync for garantert skriving av en blob med data til disk. Men når Zimbra-postbutikken eller MTA oppretter nye filer under levering av meldinger, blir det nødvendig å skrive endringene som skjer i de tilsvarende mappene til disk. Det er derfor, selv om filen allerede er skrevet til disk ved hjelp av fsync, kan det hende at registreringen av tillegget til katalogen ikke har tid til å bli skrevet til disken, og som et resultat kan den gå tapt på grunn av en plutselig serverfeil. Takket være bruken dirsync disse problemene kan unngås.
2. Optimalisering med Zimbra-infrastruktur i gang
Det hender ofte at etter flere år med bruk av Zimbra, øker antallet brukere betraktelig og tjenesten blir mindre og mindre responsiv hver dag. Veien ut av denne situasjonen er åpenbar: du trenger bare å legge til nye servere i infrastrukturen slik at tjenesten fungerer igjen like raskt som før. I mellomtiden er det ikke alltid mulig å umiddelbart legge til nye servere til infrastrukturen for å øke ytelsen. IT-ledere må ofte bruke lang tid på å koordinere innkjøp av nye servere med regnskaps- eller sikkerhetsavdelingen, i tillegg blir de ofte sviktet av leverandører som kan levere en ny server for sent eller til og med levere feil.
Selvfølgelig er det best å bygge din Zimbra-infrastruktur med en reserve for alltid å ha en reserve for utvidelse og ikke være avhengig av noen, men hvis en feil allerede er gjort, kan IT-sjefen bare jevne ut konsekvensene som mye som mulig. For eksempel kan en IT-sjef oppnå et lite produktivitetsløft ved midlertidig å deaktivere Linux-systemtjenester som regelmessig får tilgang til harddisker under drift og kan derfor påvirke Zimbras ytelse negativt. Så du kan midlertidig deaktivere:
autofs, netfs - Eksterne filsystemoppdagingstjenester
kopper — Utskriftstjeneste
xinetd, vsftpd - Innebygde *NIX-tjenester som du sannsynligvis ikke trenger
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Fjernprosedyreanropstjenester, som vanligvis brukes i forbindelse med nettverksfilsystemer
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplikater av hovedverktøyene som er inkludert i Zimbra Collaboration Suite
slocate/oppdatertb - Siden Zimbra lagrer hver melding i en egen fil, kan det å kjøre updatedb-tjenesten hver dag føre til problemer, og derfor er det mulig å gjøre dette manuelt under minst mulig belastning på serverne
Å spare systemressurser som et resultat av å deaktivere disse tjenestene vil ikke være særlig betydelig, men selv dette kan være svært nyttig under forhold nær force majeure. Når den nye serveren er lagt til Zimbra-infrastrukturen, anbefales det å aktivere de tidligere deaktiverte tjenestene på nytt.
Du kan også optimere driften av Zimbra ved å flytte syslog-tjenesten til en egen server slik at den under drift ikke laster harddiskene til e-postlager. Nesten hvilken som helst datamaskin er egnet for disse formålene, til og med en billig Raspberry Pi med ett bord.
Kilde: www.habr.com