Ühes meie , mis on pühendatud infrastruktuuri planeerimisele Zimbra Collabortion Suite'i juurutamisel ettevõttes, öeldi, et selle lahenduse toimimise peamiseks piiranguks on kettaseadmete I/O kiirus kirjamäludes. Tõepoolest, ajal, mil mitusada ettevõtte töötajat pääseb samaaegselt samale kirjasalvestusele juurde, ei pruugi kanali laius kõvaketastelt teabe kirjutamiseks ja lugemiseks olla teenuse kiireks toimimiseks piisav. Ja kui Zimbra väikeste installatsioonide puhul pole see eriline probleem, siis suurettevõtete ja SaaS-i pakkujate puhul võib see kõik kaasa tuua e-kirjade mittereageerimise ja selle tulemusena töötajate efektiivsuse vähenemise ning rikkumise. teenusepakkumislepingutest. Seetõttu tuleks suuremahuliste Zimbra installatsioonide kavandamisel ja käitamisel erilist tähelepanu pöörata kõvaketaste jõudluse optimeerimisele meilisalvestuses. Vaatame kahte juhtumit ja proovime välja selgitada, milliseid meetodeid kettasalvestuse koormuse optimeerimiseks saab mõlemal juhul rakendada.
1. Optimeerimine suuremahulise Zimbra paigalduse projekteerimisel
Suure koormusega Zimbra paigalduse projekteerimisetapis peab administraator tegema valiku, millist salvestussüsteemi kasutada. Selle probleemi üle otsustamiseks peaksite teadma, et kõvaketaste peamine koormus tuleneb MariaDB DBMS-ist, mis sisaldub Zimbra Collaboration Suite'is, Apache Lucene'i otsingumootorist ja blob-salvestusest. Seetõttu on nende tarkvaratoodete suure koormuse tingimustes kasutamiseks vaja kasutada kiireid ja töökindlaid seadmeid.
Tavatingimustes saab Zimbra installida nii kõvaketaste RAID-ile kui ka NFS-protokolli kaudu ühendatud salvestusruumile. Väga väikeste installide korral saate Zimbra installida tavalisele SATA-draivile. Kuid suurte installatsioonide kontekstis näitavad kõik need tehnoloogiad mitmesuguseid puudusi vähenenud salvestuskiiruse või madala töökindluse näol, mis pole vastuvõetav ei suurettevõtete ega eriti SaaS-i pakkujate jaoks.
Seetõttu on suuremahulistes Zimbra infrastruktuurides kõige parem kasutada SAN-i. Just see tehnoloogia on praegu võimeline pakkuma salvestusseadmetele suurimat läbilaskevõimet ja samal ajal tänu võimalusele ühendada suurel hulgal vahemälu ei kujuta selle kasutamine ettevõttele praktiliselt kaasa olulisi riske. Hea mõte on kasutada NVRAM-i, mida kasutatakse paljudes SAN-ides, et kiirendada kirjutamise ajal. Kuid parem on keelata ketastel endal salvestatud andmete vahemällu salvestamine, kuna see võib toiteprobleemide ilmnemisel põhjustada andmekandja korvamatut kahju ja andmete kadumist.
Mis puutub failisüsteemi valikusse, siis parim valik oleks kasutada standardset Linux Ext3/Ext4. Peamine failisüsteemiga seotud nüanss on see, et see peaks olema ühendatud parameetriga -noatime. See suvand keelab failidele viimase juurdepääsu aja salvestamise funktsiooni, mis tähendab, et see vähendab oluliselt lugemise ja kirjutamise koormust. Üldiselt peaksite Zimbra jaoks ext3 või ext4 failisüsteemi loomisel kasutama järgmisi utiliidi parameetreid mke2fs:
-j — failisüsteemi päeviku loomiseks. Loo failisüsteem ext3/ext4 päeviku abil.
-L NIMI - Köite nime loomiseks, mida seejärel kasutada failis /etc/fstab
-O dir_index - räsiotsingupuu kasutamine, et kiirendada failide otsimist suurtes kataloogides
-m 2 — reserveerida juurkataloogi jaoks 2% mahust suurtes failisüsteemides
-J suurus = 400 — Suure ajakirja loomiseks
-b 4096 — Ploki suuruse määramiseks baitides
- mina 10240 - Sõnumite salvestamiseks peaks see säte vastama sõnumi keskmisele suurusele. Seda parameetrit peaksite hoolikalt jälgima, kuna selle väärtust ei saa hiljem muuta.
Samuti on soovitatav lubada dirsync blob-salvestusruumi, Lucene'i otsingu metaandmete salvestusruumi ja MTA-järjekorra salvestusruumi jaoks. Seda tuleks teha, sest Zimbra kasutab tavaliselt utiliiti fsync andmetega blobi garanteeritud kirjutamiseks kettale. Kui aga Zimbra postipood ehk MTA loob sõnumite edastamise käigus uusi faile, tekib vajadus vastavates kaustades toimuvad muudatused kettale kirjutada. Sellepärast, isegi kui fail on juba kasutades kettale kirjutatud fsync, ei pruugi selle kataloogi lisamise kirjel olla aega kettale kirjutamiseks ja selle tulemusena võib see serveri äkilise rikke tõttu kaduda. Tänu kasutamisele dirsync neid probleeme saab vältida.
2. Optimeerimine töötava Zimbra infrastruktuuriga
Tihti juhtub, et pärast mitmeaastast Zimbra kasutamist suureneb selle kasutajate arv märkimisväärselt ja teenus muutub iga päevaga üha vähem reageerivaks. Väljapääs sellest olukorrast on ilmne: peate lihtsalt lisama infrastruktuuri uusi servereid, et teenus töötaks uuesti sama kiiresti kui varem. Samal ajal ei ole alati võimalik infrastruktuuri jõudluse suurendamiseks kohe uusi servereid lisada. IT-juhid peavad sageli kulutama pikka aega uute serverite ostu kooskõlastamisele raamatupidamis- või turvaosakonnaga, lisaks jätavad nad sageli alt tarnijad, kes võivad uue serveri tarnida hilja või koguni vale asja.
Loomulikult on kõige parem ehitada oma Zimbra taristu reserviga, et selle laiendamiseks oleks alati reservi ja mitte kellestki sõltuda, kuid kui viga on juba tehtud, saab IT-juht selle tagajärgi siluda ainult nii palju kui võimalik. Näiteks võib IT-juht saavutada väikese tootlikkuse tõusu, kui ajutiselt keelab Linuxi süsteemiteenused, mis pääsevad töö ajal regulaarselt kõvaketastele juurde ja võivad seetõttu Zimbra jõudlust negatiivselt mõjutada. Seega saate ajutiselt keelata:
autofs, netfs - Kaugfailisüsteemi avastamisteenused
karikad — Trükiteenus
xinetd, vsftpd - Sisseehitatud *NIX-i teenused, mida te tõenäoliselt ei vaja
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Kaugprotseduuride kõneteenused, mida tavaliselt kasutatakse koos võrgu failisüsteemidega
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Zimbra Collaboration Suite'i peamiste utiliitide duplikaadid
slocate/updatedb - Kuna Zimbra salvestab iga sõnumi eraldi faili, võib updatedb teenuse igapäevane käivitamine põhjustada probleeme ja seetõttu on võimalik seda teha käsitsi serverite minimaalse koormuse ajal
Süsteemiressursside säästmine nende teenuste keelamise tulemusena ei ole kuigi oluline, kuid isegi see võib olla väga kasulik vääramatu jõu lähedal asuvates tingimustes. Kui uus server on Zimbra infrastruktuuri lisatud, on soovitatav varem keelatud teenused uuesti lubada.
Zimbra tööd saate optimeerida ka syslogi teenuse eraldi serverisse viimisega, et see töötamise ajal ei laadiks meilimälude kõvakettaid. Nendel eesmärkidel sobib peaaegu iga arvuti, isegi odav ühe plaadiga Raspberry Pi.
Allikas: www.habr.com