Katika moja ya yetu , kujitolea kwa upangaji wa miundombinu wakati wa kutekeleza Suite ya Ushirikiano wa Zimbra katika biashara, ilisemekana kuwa kizuizi kikuu katika uendeshaji wa suluhisho hili ni kasi ya I / O ya vifaa vya disk katika storages za barua. Hakika, wakati ambapo wafanyakazi mia kadhaa wa biashara wakati huo huo wanapata hifadhi ya barua sawa, upana wa kituo cha kuandika na kusoma habari kutoka kwa anatoa ngumu inaweza kuwa haitoshi kwa uendeshaji wa huduma. Na ikiwa kwa mitambo ndogo ya Zimbra hii haitakuwa shida fulani, basi katika kesi ya makampuni makubwa na watoa huduma wa SaaS, yote haya yanaweza kusababisha barua pepe isiyojibika na, kwa sababu hiyo, kupungua kwa ufanisi wa wafanyakazi, pamoja na ukiukwaji. ya SLAs. Ndio sababu, wakati wa kubuni na kufanya kazi kwa mitambo mikubwa ya Zimbra, tahadhari maalum inapaswa kulipwa ili kuboresha utendaji wa anatoa ngumu katika uhifadhi wa barua. Wacha tuangalie kesi mbili na jaribu kujua ni njia gani za kuongeza mzigo kwenye uhifadhi wa diski zinaweza kutumika katika kila moja yao.
1. Uboreshaji wakati wa kubuni usakinishaji wa kiwango kikubwa cha Zimbra
Wakati wa awamu ya usanifu wa usakinishaji wa Zimbra wenye mzigo wa juu, msimamizi atalazimika kufanya chaguo kuhusu mfumo gani wa kuhifadhi atatumia. Ili kuamua juu ya suala hili, unapaswa kujua kwamba mzigo kuu kwenye anatoa ngumu unatoka kwa MariaDB DBMS iliyojumuishwa katika Suite ya Ushirikiano ya Zimbra, injini ya utafutaji ya Apache Lucene, na hifadhi ya blob. Ndiyo maana ili kuendesha bidhaa hizi za programu chini ya hali ya juu ya mzigo, ni muhimu kutumia vifaa vya kasi na vya kuaminika.
Katika hali ya kawaida, Zimbra inaweza kusakinishwa kwenye RAID ya anatoa ngumu na kwenye hifadhi iliyounganishwa kupitia itifaki ya NFS. Kwa mitambo ndogo sana, unaweza kufunga Zimbra kwenye gari la kawaida la SATA. Hata hivyo, katika muktadha wa usakinishaji mkubwa, teknolojia hizi zote zinaonyesha hasara mbalimbali kwa njia ya kupunguza kasi ya kurekodi au kuegemea chini, ambayo haikubaliki wala kwa makampuni makubwa wala, hasa kwa watoa huduma wa SaaS.
Hii ndiyo sababu katika miundombinu mikubwa ya Zimbra ni bora kutumia SAN. Ni teknolojia hii ambayo kwa sasa ina uwezo wa kutoa njia bora zaidi ya vifaa vya uhifadhi na wakati huo huo, shukrani kwa uwezo wa kuunganisha idadi kubwa ya kache, matumizi yake kivitendo haitoi hatari yoyote kwa biashara. Ni wazo nzuri kutumia NVRAM, ambayo hutumiwa katika SANs nyingi kuharakisha mambo wakati wa kuandika. Lakini ni bora kuzima caching ya data iliyorekodi kwenye disks wenyewe, kwani inaweza kusababisha uharibifu usioweza kurekebishwa kwa vyombo vya habari na kupoteza data ikiwa matatizo ya nguvu hutokea.
Kuhusu kuchagua mfumo wa faili, chaguo bora itakuwa kutumia Linux ya kawaida Ext3/Ext4. Nuance kuu inayohusishwa na mfumo wa faili ni kwamba inapaswa kuwekwa na parameter -wakati wa mchana. Chaguo hili litazima kazi ya kurekodi wakati wa upatikanaji wa mwisho wa faili, ambayo ina maana itapunguza sana mzigo wa kusoma na kuandika. Kwa ujumla, wakati wa kuunda mfumo wa faili wa ext3 au ext4 wa Zimbra, unapaswa kutumia vigezo vifuatavyo vya matumizi. mke2fs:
-j β Kuunda jarida la mfumo wa faili Unda mfumo wa faili na jarida la ext3/ext4.
-L JINA - Kuunda jina la kiasi kisha kutumia ndani /etc/fstab
-O dir_index - Kutumia mti wa utafutaji wa haraka ili kuharakisha utafutaji wa faili katika saraka kubwa
-m 2 - Kuhifadhi 2% ya kiasi katika mifumo mikubwa ya faili kwa saraka ya mizizi
-J size=400 - Ili kuunda gazeti kubwa
-b 4096 - Kuamua saizi ya kizuizi kwa baiti
-I 10240 - Kwa uhifadhi wa ujumbe, mpangilio huu unapaswa kuendana na ukubwa wa wastani wa ujumbe. Unapaswa kuzingatia kwa makini parameter hii, kwani thamani yake haiwezi kubadilishwa baadaye.
Inapendekezwa pia kuwezesha dirsync kwa hifadhi ya blob, hifadhi ya metadata ya utafutaji wa Lucene, na hifadhi ya foleni ya MTA. Hii inapaswa kufanywa kwa sababu Zimbra kawaida hutumia matumizi fsync kwa uandishi wa uhakika wa blob iliyo na data hadi diski. Hata hivyo, wakati duka la barua la Zimbra au MTA linaunda faili mpya wakati wa utoaji wa ujumbe, inakuwa muhimu kuandika kwenye diski mabadiliko yanayotokea kwenye folda zinazofanana. Ndio sababu, hata ikiwa faili tayari imeandikwa kwa diski kwa kutumia fsync, rekodi ya kuongeza kwake kwenye saraka haiwezi kuwa na muda wa kuandikwa kwenye diski na, kwa sababu hiyo, inaweza kupotea kutokana na kushindwa kwa seva ya ghafla. Shukrani kwa matumizi dirsync matatizo haya yanaweza kuepukika.
2. Uboreshaji na miundombinu ya Zimbra inayoendesha
Mara nyingi hutokea kwamba baada ya miaka kadhaa ya kutumia Zimbra, idadi ya watumiaji wake huongezeka kwa kiasi kikubwa na huduma inakuwa chini na chini ya msikivu kila siku. Njia ya nje ya hali hii ni dhahiri: unahitaji tu kuongeza seva mpya kwenye miundombinu ili huduma ifanye kazi tena haraka kama hapo awali. Wakati huo huo, si mara zote inawezekana kuongeza seva mpya mara moja kwenye miundombinu ili kuongeza utendaji wake. Wasimamizi wa IT mara nyingi hulazimika kutumia muda mrefu kuratibu ununuzi wa seva mpya na idara ya uhasibu au usalama; kwa kuongezea, mara nyingi huachwa na wasambazaji ambao wanaweza kuwasilisha seva mpya kuchelewa au hata kutoa kitu kibaya.
Kwa kweli, ni bora kujenga miundombinu yako ya Zimbra na hifadhi ili kila wakati uwe na akiba ya upanuzi wake na usitegemee mtu yeyote, hata hivyo, ikiwa makosa tayari yamefanywa, meneja wa IT anaweza tu kurekebisha matokeo yake kama iwezekanavyo. Kwa mfano, meneja wa TEHAMA anaweza kufikia ongezeko dogo la tija kwa kuzima kwa muda huduma za mfumo wa Linux ambao hufikia mara kwa mara diski kuu wakati wa operesheni na kwa hivyo inaweza kuathiri vibaya utendakazi wa Zimbra. Kwa hivyo, unaweza kuzima kwa muda:
autofs, netfs - Huduma za Ugunduzi wa Mfumo wa Faili ya Mbali
vikombe - Huduma ya uchapishaji
xinetd, vsftpd - Huduma zilizojengwa ndani za *NIX ambazo labda hutahitaji
portmap, rpcsvcgssd, rpcgssd, rpcidmapd - Huduma za simu za utaratibu wa mbali, ambazo kwa kawaida hutumiwa kwa kushirikiana na mifumo ya faili ya mtandao
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap - Nakala za huduma kuu zilizojumuishwa katika Suite ya Ushirikiano ya Zimbra
slocate/updatedb - Kwa kuwa Zimbra huhifadhi kila ujumbe katika faili tofauti, kuendesha huduma ya updatedb kila siku kunaweza kusababisha matatizo, na kwa hiyo inawezekana kufanya hivyo kwa mikono wakati wa mzigo mdogo kwenye seva.
Kuokoa rasilimali za mfumo kama matokeo ya kuzima huduma hizi haitakuwa muhimu sana, lakini hata hii inaweza kuwa muhimu sana katika hali karibu na kulazimisha majeure. Mara seva mpya inapoongezwa kwenye miundombinu ya Zimbra, inashauriwa kuwasha tena huduma zilizozimwa hapo awali.
Unaweza pia kuboresha uendeshaji wa Zimbra kwa kuhamisha huduma ya syslog kwenye seva tofauti ili wakati wa operesheni haina kupakia anatoa ngumu za storages za barua. Karibu kompyuta yoyote inafaa kwa madhumuni haya, hata Raspberry Pi ya bodi ya bei nafuu.
Chanzo: mapenzi.com