Sa isa sa aming , na nakatuon sa pagpaplano ng imprastraktura kapag nagpapatupad ng Zimbra Collabortion Suite sa isang enterprise, sinabi na ang pangunahing limitasyon sa pagpapatakbo ng solusyon na ito ay ang bilis ng I/O ng mga disk device sa mga imbakan ng mail. Sa katunayan, sa panahon na ilang daang empleyado ng isang enterprise ang sabay-sabay na nag-access sa parehong imbakan ng mail, ang lapad ng channel para sa pagsusulat at pagbabasa ng impormasyon mula sa mga hard drive ay maaaring hindi sapat para sa tumutugon na operasyon ng serbisyo. At kung para sa maliliit na pag-install ng Zimbra hindi ito magiging isang partikular na problema, kung gayon sa kaso ng malalaking negosyo at mga provider ng SaaS, ang lahat ng ito ay maaaring humantong sa hindi tumutugon na email at, bilang isang resulta, isang pagbawas sa kahusayan ng empleyado, pati na rin ang isang paglabag ng mga SLA. Iyon ang dahilan kung bakit, kapag nagdidisenyo at nagpapatakbo ng malakihang pag-install ng Zimbra, ang espesyal na atensyon ay dapat bayaran sa pag-optimize ng pagganap ng mga hard drive sa imbakan ng mail. Tingnan natin ang dalawang kaso at subukang malaman kung anong mga pamamaraan para sa pag-optimize ng pag-load sa imbakan ng disk ay maaaring mailapat sa bawat isa sa kanila.
1. Pag-optimize kapag nagdidisenyo ng malakihang pag-install ng Zimbra
Sa yugto ng disenyo ng isang high-load na pag-install ng Zimbra, ang administrator ay kailangang pumili kung aling storage system ang gagamitin. Upang makapagpasya sa isyung ito, dapat mong malaman na ang pangunahing load sa mga hard drive ay mula sa MariaDB DBMS na kasama sa Zimbra Collaboration Suite, ang Apache Lucene search engine, at blob storage. Iyon ang dahilan kung bakit upang mapatakbo ang mga produktong ito ng software sa ilalim ng mga kondisyon ng mataas na pagkarga, kinakailangan na gumamit ng mataas na bilis at maaasahang kagamitan.
Sa ilalim ng normal na mga kondisyon, maaaring i-install ang Zimbra sa parehong RAID ng mga hard drive at sa storage na konektado sa pamamagitan ng NFS protocol. Para sa napakaliit na pag-install, maaari mong i-install ang Zimbra sa isang regular na SATA drive. Gayunpaman, sa konteksto ng malalaking pag-install, ang lahat ng mga teknolohiyang ito ay nagpapakita ng iba't ibang mga disadvantages sa anyo ng pinababang bilis ng pag-record o mababang pagiging maaasahan, na hindi katanggap-tanggap alinman sa malalaking negosyo o, lalo na para sa mga provider ng SaaS.
Ito ang dahilan kung bakit sa malakihang mga imprastraktura ng Zimbra pinakamainam na gumamit ng SAN. Ito ang teknolohiyang ito na kasalukuyang may kakayahang magbigay ng pinakamalaking throughput para sa mga storage device at sa parehong oras, salamat sa kakayahang kumonekta sa isang malaking halaga ng cache, ang paggamit nito ay halos hindi nagdudulot ng anumang makabuluhang panganib para sa negosyo. Magandang ideya na gumamit ng NVRAM, na ginagamit sa maraming SAN upang mapabilis ang mga bagay sa panahon ng pagsusulat. Ngunit mas mahusay na huwag paganahin ang pag-cache ng mga naitala na data sa mga disk mismo, dahil maaari itong humantong sa hindi na mapananauli na pinsala sa media at pagkawala ng data kung may mga problema sa kuryente.
Kung tungkol sa pagpili ng file system, ang pinakamainam na pagpipilian ay ang paggamit ng mga karaniwang file system para sa Linux Ext3/Ext4. Ang pangunahing nuance na nauugnay sa file system ay dapat itong mai-mount gamit ang parameter na -noatime. Ang pagpipiliang ito ay hindi paganahin ang pag-andar ng pag-record ng oras ng huling pag-access sa mga file, na nangangahulugang ito ay lubos na magbabawas sa pagkarga sa pagbabasa at pagsusulat. Sa pangkalahatan, kapag gumagawa ng ext3 o ext4 file system para sa Zimbra, dapat mong gamitin ang sumusunod na mga parameter ng utility mke2fs:
-j — Upang lumikha ng isang file system journal.
-L NAME - Upang lumikha ng pangalan ng volume na gagamitin sa /etc/fstab
-O dir_index - Upang gumamit ng hash na puno ng paghahanap upang pabilisin ang mga paghahanap ng file sa malalaking direktoryo
-m 2 — Upang magreserba ng 2% ng volume sa malalaking file system para sa root directory
-J size=400 — Upang lumikha ng isang malaking magazine
-b 4096 — Upang matukoy ang laki ng bloke sa mga byte
-ako 10240 - Para sa imbakan ng mensahe, ang setting na ito ay dapat tumugma sa average na laki ng mensahe. Dapat mong bigyang-pansin ang parameter na ito, dahil hindi na mababago ang halaga nito sa ibang pagkakataon.
Inirerekomenda din na paganahin dirsync para sa blob storage, Lucene search metadata storage, at MTA queue storage. Dapat itong gawin dahil karaniwang ginagamit ng Zimbra ang utility fsync para sa garantisadong pagsulat ng isang blob na may data sa disk. Gayunpaman, kapag ang Zimbra mail store o MTA ay lumikha ng mga bagong file sa panahon ng paghahatid ng mensahe, kinakailangan na isulat sa disk ang mga pagbabagong nagaganap sa kaukulang mga folder. Iyon ang dahilan kung bakit, kahit na ang file ay naisulat na sa disk gamit fsync, ang rekord ng pagdaragdag nito sa direktoryo ay maaaring walang oras upang maisulat sa disk at, bilang resulta, ay maaaring mawala dahil sa isang biglaang pagkabigo ng server. Salamat sa paggamit dirsync maiiwasan ang mga problemang ito.
2. Pag-optimize gamit ang imprastraktura ng Zimbra na tumatakbo
Madalas mangyari na pagkatapos ng ilang taon ng paggamit ng Zimbra, ang bilang ng mga gumagamit nito ay tumataas nang malaki, at ang serbisyo ay nagiging mas mahina nang hindi tumutugon. Ang solusyon sa sitwasyong ito ay malinaw: magdagdag lamang ng mga bagong server sa imprastraktura upang maibalik ang bilis ng serbisyo. Gayunpaman, hindi laging posible na agad na magdagdag ng mga bagong server sa imprastraktura upang mapabuti ang pagganap nito. Ang mga IT manager ay madalas na kailangang gumugol ng mahabang oras sa pag-coordinate ng pagbili. mga bagong server Bukod pa rito, kadalasang nahuhuli sa paghahatid ng bagong server ang mga supplier o kaya naman ay maling produkto ang naihahatid nila, kahit pa sa mga departamento ng accounting o seguridad.
Siyempre, mas mainam na itayo ang iyong imprastraktura ng Zimbra nang may reserba, para lagi kang may puwang para sa pagpapalawak at hindi mo na kailangang umasa sa kahit sino. Gayunpaman, kung may nagawa nang pagkakamali, ang IT manager ay maaari lamang bawasan ang mga kahihinatnan nito hangga't maaari. Halimbawa, ang isang IT manager ay maaaring makamit ang maliit na pagtaas ng pagganap sa pamamagitan ng pansamantalang pag-disable ng mga serbisyo ng system. Linux, na regular na nag-a-access sa mga hard drive habang ginagamit at, bilang resulta, maaaring negatibong makaapekto sa performance ng Zimbra. Halimbawa, maaari mong pansamantalang i-disable ang:
autofs, netfs - Remote File System Discovery Services
tasa — Serbisyo sa pag-print
xinetd, vsftpd - Built-in na *NIX na mga serbisyo na malamang na hindi mo kakailanganin
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Remote procedure call services, na kadalasang ginagamit kasama ng network file system
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Mga duplicate ng mga pangunahing utility na kasama sa Zimbra Collaboration Suite
slocate/na-updateb - Dahil iniimbak ng Zimbra ang bawat mensahe sa isang hiwalay na file, ang pagpapatakbo ng updatedb service araw-araw ay maaaring magdulot ng mga problema, kaya maaari mong gawin ito nang manu-mano kapag ang mga server ay hindi gaanong abala
Ang pag-save ng mga mapagkukunan ng system bilang isang resulta ng hindi pagpapagana ng mga serbisyong ito ay hindi magiging napakahalaga, ngunit kahit na ito ay maaaring maging lubhang kapaki-pakinabang sa mga kondisyong malapit sa force majeure. Kapag naidagdag na ang bagong server sa imprastraktura ng Zimbra, inirerekumenda na muling paganahin ang mga dating na-disable na serbisyo.
Maaari mo ring i-optimize ang pagpapatakbo ng Zimbra sa pamamagitan ng paglipat ng serbisyo ng syslog sa isang hiwalay na server upang sa panahon ng operasyon ay hindi nito mai-load ang mga hard drive ng mga imbakan ng mail. Halos anumang computer ay angkop para sa mga layuning ito, kahit isang murang single-board na Raspberry Pi.
Pinagmulan: www.habr.com
