En unu el niaj , dediĉita al infrastruktura planado dum efektivigo de Zimbra Collaboration Suite en entrepreno, oni diris, ke la ĉefa limigo en la funkciado de ĉi tiu solvo estas la I/O-rapideco de disko-aparatoj en poŝtaj stokejoj. Efektive, en tempo, kiam kelkcent dungitoj de entrepreno samtempe aliras la saman poŝtan stokadon, la kanallarĝo por skribi kaj legi informojn el malmolaj diskoj eble ne sufiĉas por la respondema funkciado de la servo. Kaj se por malgrandaj instalaĵoj de Zimbra ĉi tio ne estos aparta problemo, tiam en la kazo de grandaj entreprenoj kaj SaaS-provizantoj, ĉio ĉi povas konduki al neresponda retpoŝto kaj, kiel rezulto, malpliigo de dungita efikeco, kaj ankaŭ malobservo. de SLAoj. Tial, kiam oni desegnas kaj funkciigas grandskalajn instalaĵojn de Zimbra, oni devas prunti specialan atenton al optimumigo de la agado de malmolaj diskoj en poŝta stokado. Ni rigardu du kazojn kaj provu ekscii, kiajn metodojn por optimumigi la ŝarĝon sur disko-stokado povas esti aplikataj en ĉiu el ili.
1. Optimumigo dum desegnado de grandskala Zimbra-instalaĵo
Dum la dezajna fazo de altŝarĝa instalaĵo de Zimbra, la administranto devos fari elekton pri kiu stokada sistemo uzi. Por decidi pri ĉi tiu afero, vi devus scii, ke la ĉefa ŝarĝo sur malmolaj diskoj venas de la MariaDB DBMS inkluzivita en la Zimbra Collaboration Suite, la serĉilo Apache Lucene kaj blob-stokado. Tial por funkciigi ĉi tiujn programajn produktojn sub altaj ŝarĝaj kondiĉoj necesas uzi altrapidan kaj fidindan ekipaĵon.
En normalaj kondiĉoj, Zimbra povas esti instalita kaj sur RAID de malmolaj diskoj kaj sur stokado konektita per la NFS-protokolo. Por tre malgrandaj instalaĵoj, vi povas instali Zimbra sur regula SATA-disko. Tamen, en la kunteksto de grandaj instalaĵoj, ĉiuj ĉi tiuj teknologioj montras diversajn malavantaĝojn en la formo de reduktita registra rapideco aŭ malalta fidindeco, kio estas neakceptebla nek por grandaj entreprenoj nek, precipe por SaaS-provizantoj.
Tial en grandskalaj infrastrukturoj de Zimbra plej bone estas uzi SAN. Estas ĉi tiu teknologio, kiu nuntempe kapablas provizi la plej grandan trairon por stokaj aparatoj kaj samtempe, danke al la kapablo konekti grandan kvanton da kaŝmemoro, ĝia uzo preskaŭ ne prezentas gravajn riskojn por la entrepreno. Estas bona ideo uzi NVRAM, kiu estas uzata en multaj SANoj por akceli aferojn dum skribado. Sed estas pli bone malŝalti kaŝmemoron de registritaj datumoj sur la diskoj mem, ĉar ĝi povas konduki al neriparebla damaĝo al la amaskomunikilaro kaj perdo de datumoj se okazas potencproblemoj.
Pri elekto de dosiersistemo, la plej bona elekto estus uzi la norman Linukso Ext3/Ext4. La ĉefa nuanco asociita kun la dosiersistemo estas, ke ĝi devus esti muntita kun la parametro -noatime. Ĉi tiu opcio malŝaltos la funkcion registri la tempon de la lasta aliro al dosieroj, kio signifas, ke ĝi multe reduktos la ŝarĝon pri legado kaj skribo. Ĝenerale, kiam vi kreas dosiersistemon ext3 aŭ ext4 por Zimbra, vi devus uzi la jenajn utilajn parametrojn mke2fs:
-j — Por krei dosiersisteman ĵurnalon Kreu la dosiersistemon per ext3/ext4 ĵurnalo.
-L NOMO - Krei voluman nomon por poste uzi en /etc/fstab
-O dir_index - Uzi haŝitan serĉarbon por akceli dosierserĉojn en grandaj dosierujoj
-m 2 — Rezervi 2% de la volumo en grandaj dosiersistemoj por la radika dosierujo
-J grandeco=400 — Krei grandan revuon
-b 4096 — Por determini la blokgrandecon en bajtoj
- mi 10240 - Por konservado de mesaĝoj, ĉi tiu agordo devus respondi al la meza grandeco de mesaĝoj. Vi devas atenti ĉi tiun parametron, ĉar ĝia valoro ne povas esti ŝanĝita poste.
Ankaŭ rekomendas ebligi dirsync por blob-stokado, Lucene-serĉa metadatumo-stokado, kaj MTA-vicostokado. Ĉi tio devus esti farita ĉar Zimbra kutime uzas la ilon fsync por garantiita skribado de blob kun datumoj al disko. Tamen, kiam la poŝtvendejo de Zimbra aŭ MTA kreas novajn dosierojn dum la liverado de mesaĝoj, necesas skribi al disko la ŝanĝojn kiuj okazas en la respondaj dosierujoj. Tial, eĉ se la dosiero jam estis skribita al disko uzante fsync, la registro de ĝia aldono al la dosierujo eble ne havas tempon por esti skribita al la disko kaj, kiel rezulto, povas esti perdita pro subita servila fiasko. Danke al la uzo dirsync ĉi tiuj problemoj povas esti evititaj.
2. Optimumigo kun Zimbra-infrastrukturo funkcianta
Ofte okazas, ke post pluraj jaroj de uzado de Zimbra, la nombro de ĝiaj uzantoj signife pliiĝas kaj la servo fariĝas ĉiutage malpli kaj malpli respondema. La eliro el ĉi tiu situacio estas evidenta: vi nur bezonas aldoni novajn servilojn al la infrastrukturo, por ke la servo refunkciu tiel rapide kiel antaŭe. Dume, ne ĉiam eblas tuj aldoni novajn servilojn al la infrastrukturo por pliigi ĝian rendimenton. IT-administrantoj ofte devas pasigi longan tempon kunordigante la aĉeton de novaj serviloj kun la kontada aŭ sekureca fako; krome, ili ofte estas lasitaj de provizantoj, kiuj povas liveri novan servilon malfrue aŭ eĉ liveri la malĝustan aferon.
Kompreneble, estas plej bone konstrui vian Zimbra-infrastrukturon kun rezervo por ĉiam havi rezervon por ĝia ekspansio kaj ne dependi de iu ajn, tamen, se jam estis farita eraro, la IT-administranto povas nur glatigi ĝiajn konsekvencojn kiel kiom eble. Ekzemple, IT-manaĝero povas atingi malgrandan produktivecon provizore malfunkciigante Linuksan sistemservojn kiuj regule aliras durdiskojn dum operacio kaj povas tial negative influi la efikecon de Zimbra. Do, vi povas provizore malŝalti:
autofs, netfs - Malkovraj Servoj de Foraj Dosieraj Sistemoj
tasoj — Presa servo
xinetd, vsftpd - Enkonstruitaj *NIX-servoj, kiujn vi verŝajne ne bezonos
portmapo, rpcsvcgssd, rpcgssd, rpcidmapd — Foraj procedaj alvokaj servoj, kiuj estas kutime uzataj kune kun retaj dosiersistemoj
kolombejo, cyrus-imapd, sendmail, exim, postfix, ldap — Duplikatoj de la ĉefaj utilecoj inkluzivitaj en la Zimbra Kunlabora Suite
loki/ĝisdatigib - Ĉar Zimbra konservas ĉiun mesaĝon en aparta dosiero, ruli la ĝisdatigitan servon ĉiutage povas kaŭzi problemojn, kaj tial eblas fari tion permane dum la plej malgranda ŝarĝo en la serviloj.
Ŝpari sistemajn rimedojn kiel rezulto de malŝalto de ĉi tiuj servoj ne estos tre signifa, sed eĉ ĉi tio povas esti tre utila en kondiĉoj proksimaj al forto-majoro. Post kiam la nova servilo estas aldonita al la infrastrukturo de Zimbra, oni rekomendas reŝalti la antaŭe malfunkciigitajn servojn.
Vi ankaŭ povas optimumigi la funkciadon de Zimbra movante la syslog-servon al aparta servilo, por ke dum funkciado ĝi ne ŝarĝu la malmolajn diskojn de poŝtaj stokejoj. Preskaŭ ajna komputilo taŭgas por ĉi tiuj celoj, eĉ malmultekosta unutabulo Raspberry Pi.
fonto: www.habr.com