Viename iš mūsų , skirta infrastruktūros planavimui diegiant Zimbra Collabortion Suite įmonėje, buvo teigiama, kad pagrindinis šio sprendimo veikimo apribojimas yra disko įrenginių įvesties/išvesties greitis pašto saugyklose. Iš tiesų tuo metu, kai keli šimtai įmonės darbuotojų vienu metu pasiekia tą pačią pašto saugyklą, kanalo pločio informacijai rašyti ir skaityti iš standžiųjų diskų gali nepakakti, kad paslauga veiktų greitai. Ir jei mažiems „Zimbra“ įrenginiams tai nebus ypatinga problema, tada didelėms įmonėms ir „SaaS“ tiekėjams visa tai gali sukelti nereaguojantį el. paštą ir dėl to sumažėti darbuotojų efektyvumas, taip pat pažeidimas. SLA. Štai kodėl, projektuojant ir eksploatuojant didelio masto „Zimbra“ įrenginius, ypatingas dėmesys turėtų būti skiriamas standžiųjų diskų našumui pašto saugykloje optimizuoti. Pažvelkime į du atvejus ir pabandykime išsiaiškinti, kokius disko saugyklos apkrovos optimizavimo metodus galima pritaikyti kiekviename iš jų.
1. Optimizavimas projektuojant didelio masto Zimbra instaliaciją
Didelės apkrovos „Zimbra“ diegimo projektavimo etape administratorius turės pasirinkti, kurią saugojimo sistemą naudoti. Norėdami nuspręsti dėl šios problemos, turėtumėte žinoti, kad pagrindinė standžiųjų diskų apkrova kyla iš MariaDB DBVS, įtrauktos į „Zimbra Collaboration Suite“, „Apache Lucene“ paieškos variklį ir „blob“ saugyklą. Štai kodėl norint naudoti šiuos programinės įrangos produktus didelės apkrovos sąlygomis, būtina naudoti didelės spartos ir patikimą įrangą.
Įprastomis sąlygomis Zimbra gali būti įdiegta tiek standžiųjų diskų RAID, tiek NFS protokolu prijungtoje saugykloje. Labai mažiems įrenginiams galite įdiegti Zimbra į įprastą SATA diską. Tačiau didelių įrenginių kontekste visos šios technologijos demonstruoja įvairius trūkumus – sumažintą įrašymo greitį arba žemą patikimumą, o tai nepriimtina nei didelėms įmonėms, nei ypač SaaS tiekėjams.
Štai kodėl didelės apimties Zimbra infrastruktūrose geriausia naudoti SAN. Būtent ši technologija šiuo metu gali užtikrinti didžiausią saugojimo įrenginių pralaidumą ir tuo pačiu, dėl galimybės prijungti didelį kiekį talpyklos, jos naudojimas praktiškai nekelia reikšmingos rizikos įmonei. Gera idėja naudoti NVRAM, kuri naudojama daugelyje SAN, kad būtų pagreitintas rašymas. Tačiau geriau išjungti įrašytų duomenų kaupimą talpykloje pačiuose diskuose, nes tai gali sukelti nepataisomą žalą laikmenai ir duomenų praradimą, jei kiltų problemų dėl maitinimo.
Kalbant apie failų sistemos pasirinkimą, geriausias pasirinkimas būtų naudoti standartinį Linux Ext3/Ext4. Pagrindinis niuansas, susijęs su failų sistema, yra tai, kad ji turėtų būti prijungta su parametru -noatime. Ši parinktis išjungs paskutinės prieigos prie failų laiko įrašymo funkciją, o tai reiškia, kad tai labai sumažins skaitymo ir rašymo apkrovą. Apskritai, kurdami ext3 arba ext4 failų sistemą Zimbra, turėtumėte naudoti šiuos naudingumo parametrus žmona2fs:
-j — Norėdami sukurti failų sistemos žurnalą Sukurkite failų sistemą naudodami ext3/ext4 žurnalą.
-L VARDAS - Norėdami sukurti tomo pavadinimą, kurį vėliau naudosite /etc/fstab
-O dir_index - Norėdami pagreitinti failų paiešką dideliuose kataloguose, naudoti maišos paieškos medį
- 2 m — Rezervuoti 2% tūrio didelėse failų sistemose šakniniam katalogui
-J dydis = 400 — Sukurti didelį žurnalą
-b 4096 — Nustatyti bloko dydį baitais
- aš 10240 - Pranešimų saugojimui šis nustatymas turi atitikti vidutinį pranešimo dydį. Į šį parametrą turėtumėte atkreipti ypatingą dėmesį, nes vėliau jo reikšmės keisti negalima.
Taip pat rekomenduojama įjungti dirsync blob saugyklai, Lucene paieškos metaduomenų saugyklai ir MTA eilių saugyklai. Tai turėtų būti padaryta, nes Zimbra paprastai naudoja naudingumą fsync už garantuotą blob su duomenimis įrašymą į diską. Tačiau kai žinučių pristatymo metu Zimbra pašto parduotuvė arba MTA sukuria naujus failus, atsiranda būtinybė įrašyti į diską pakeitimus, kurie atsiranda atitinkamuose aplankuose. Štai kodėl, net jei failas jau buvo įrašytas į diską naudojant fsync, jo įtraukimo į katalogą įrašas gali nespėti įrašyti į diską ir dėl to gali būti prarastas dėl staigaus serverio gedimo. Naudojimo dėka dirsync šių problemų galima išvengti.
2. Optimizavimas veikiant Zimbra infrastruktūrai
Neretai nutinka taip, kad po kelerių metų naudojimosi Zimbra jos vartotojų gerokai padaugėja ir paslauga kasdien vis mažiau reaguoja. Išeitis iš šios situacijos akivaizdi: tereikia į infrastruktūrą įtraukti naujų serverių, kad paslauga vėl veiktų taip pat greitai, kaip anksčiau. Tuo tarpu ne visada galima iš karto pridėti naujų serverių į infrastruktūrą, siekiant padidinti jos našumą. IT vadovams dažnai tenka ilgai derinti naujų serverių pirkimą su buhalterijos ar saugos skyriumi, be to, dažnai juos nuvilia tiekėjai, galintys pristatyti naują serverį pavėluotai ar net pristatyti ne tą daiktą.
Žinoma, geriausia savo Zimbros infrastruktūrą kurti su rezervu, kad visada turėtum rezervą jos plėtrai ir nepriklausytum nuo niekuo, tačiau jei jau buvo padaryta klaida, IT vadovas gali tik išlyginti jos pasekmes. kiek įmanoma. Pavyzdžiui, IT vadovas gali šiek tiek padidinti produktyvumą laikinai išjungdamas „Linux“ sistemos paslaugas, kurios veikimo metu reguliariai pasiekia standžiuosius diskus ir todėl gali neigiamai paveikti „Zimbra“ našumą. Taigi galite laikinai išjungti:
autofs, netfs - Nuotolinės failų sistemos aptikimo paslaugos
puodeliai — Spausdinimo paslauga
xinetd, vsftpd - Integruotos *NIX paslaugos, kurių jums tikriausiai neprireiks
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Nuotolinių procedūrų iškvietimo paslaugos, kurios paprastai naudojamos kartu su tinklo failų sistemomis
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Pagrindinių paslaugų, įtrauktų į „Zimbra Collaboration Suite“, kopijos
slocate/updatedb - Kadangi Zimbra kiekvieną pranešimą išsaugo atskirame faile, kiekvieną dieną paleidus updatedb paslaugą gali kilti problemų, todėl tai galima padaryti rankiniu būdu per mažiausią serverių apkrovą
Sistemos išteklių taupymas dėl šių paslaugų išjungimo nebus labai reikšmingas, tačiau net ir tai gali būti labai naudinga esant force majeure aplinkybėms. Naują serverį įtraukus į Zimbra infrastruktūrą, rekomenduojama iš naujo įjungti anksčiau išjungtas paslaugas.
Taip pat galite optimizuoti Zimbra veikimą, perkeldami syslog paslaugą į atskirą serverį, kad veikimo metu ji neapkrautų pašto saugyklų standžiųjų diskų. Šiems tikslams tinka beveik bet kuris kompiuteris, net pigus vienos plokštės Raspberry Pi.
Šaltinis: www.habr.com