Ang pagpapatupad ng anumang solusyon sa IT sa isang negosyo ay nagsisimula sa disenyo. Sa yugtong ito, kakailanganing kalkulahin ng tagapamahala ng IT ang bilang ng mga server at ang kanilang mga katangian upang, sa isang banda, sapat ang mga ito para sa lahat ng mga gumagamit, at sa kabilang banda, upang ang ratio ng kalidad ng presyo ng mga server na ito. ay pinakamainam at ang mga gastos sa paglikha ng isang imprastraktura ng computing para sa bagong sistema ng impormasyon ay hindi ginawang isang seryosong butas sa badyet ng IT ng negosyo. Alamin natin kung paano idisenyo ang imprastraktura para sa pagpapatupad ng enterprise ng Zimbra Collaboration Suite.
Ang pangunahing tampok ng Zimbra kumpara sa iba pang mga solusyon ay na sa kaso ng ZCS, ang bottleneck ay bihirang processor power o RAM. Ang pangunahing limitasyon ay karaniwang ang bilis ng input at output ng hard drive at samakatuwid ang pangunahing pansin ay dapat bayaran sa imbakan ng data. Ang opisyal na nakasaad na minimum na mga kinakailangan para sa Zimbra sa isang kapaligiran ng produksyon ay isang 4-core 64-bit na processor na may 2 gigahertz clock speed, 10 gigabytes para sa mga system file at log, at hindi bababa sa 8 gigabytes ng RAM. Kadalasan, sapat na ang mga katangiang ito para gumana nang tumutugon ang server. Ngunit paano kung kailangan mong ipatupad ang Zimbra para sa 10 libong mga gumagamit? Aling mga server at paano sila dapat ipatupad sa kasong ito?
Magsimula tayo sa katotohanan na ang imprastraktura para sa 10 libong mga gumagamit ay dapat na multi-server. Ang multi-server na imprastraktura, sa isang banda, ay nagpapahintulot sa Zimbra na maging scalable, at sa kabilang banda, upang makamit ang tumutugon na operasyon ng sistema ng impormasyon kahit na may malaking pagdagsa ng mga user. Kadalasan ay medyo mahirap hulaan nang eksakto kung gaano karaming mga user ang isang Zimbra server na makakapaglingkod nang mahusay, dahil marami ang nakasalalay sa intensity ng kanilang trabaho sa mga kalendaryo at email, pati na rin sa protocol na ginamit. Kaya naman, bilang halimbawa, magpapatupad kami ng 4 na imbakan ng mail. Sa kaso ng kakulangan o malubhang labis na kapasidad, posibleng i-off o magdagdag ng isa pa.
Kaya, kapag nagdidisenyo ng imprastraktura para sa 10.000 tao, kakailanganin mong lumikha ng LDAP, MTA at Proxy server at 4 na imbakan ng mail. Tandaan na ang LDAP, MTA at Proxy server ay maaaring gawing virtual. Mababawasan nito ang gastos ng hardware ng server at gawing mas madali ang pag-backup at pag-restore ng data, ngunit sa kabilang banda, kung nabigo ang pisikal na server, nanganganib kang mawalan kaagad ng MTA, LDAP at Proxy. Iyon ang dahilan kung bakit ang pagpili sa pagitan ng pisikal o virtual na mga server ay dapat gawin batay sa kung gaano karaming downtime ang maaari mong bayaran sa kaganapan ng isang emergency. Ang mga imbakan ng mail ay pinakamainam na mailagay sa mga pisikal na server, dahil sa kanila ang karamihan sa mga yugto ng pagsulat ay magaganap, na naglilimita sa pagganap ng Zimbra, at samakatuwid ang isang mas malaking bilang ng mga channel para sa paglilipat ng data ay makabuluhang magpapataas sa pagganap ng Zimbra.
Sa prinsipyo, pagkatapos gumawa ng LDAP, MTA, Proxy server, network storage at pagsama-samahin ang mga ito sa iisang imprastraktura, ang Zimbra Collaboration Suite para sa 10000 user ay handa na para sa commissioning. Ang pagpapatakbo ng pagsasaayos na ito ay magiging medyo simple:
Ipinapakita ng diagram ang mga pangunahing node ng system at ang mga daloy ng data na magpapalipat-lipat sa pagitan nila. Sa pagsasaayos na ito, ang imprastraktura ay ganap na hindi mapoprotektahan mula sa pagkawala ng data, downtime na nauugnay sa pagkabigo ng alinman sa mga server, at iba pa. Tingnan natin nang eksakto kung paano mo mapoprotektahan ang iyong imprastraktura mula sa mga problemang ito.
Ang pangunahing paraan ay ang hardware redundancy. Ang mga karagdagang MTA at Proxy node ay maaaring, kung sakaling mabigo ang mga pangunahing server, pansamantalang kunin ang tungkulin ng mga pangunahing server. Ang pagdoble ng mga node ng kritikal na imprastraktura ay halos palaging isang magandang ideya, ngunit hindi ito palaging magagawa sa nais na lawak. Ang isang kapansin-pansing halimbawa ay ang pagpapareserba ng mga server kung saan nakaimbak ang mail. Sa kasalukuyan, hindi sinusuportahan ng Zimbra Collaboration Suite Open-Source Edition ang paglikha ng mga duplicate na tindahan, kaya kung nabigo ang isa sa mga server na ito, hindi maiiwasan ang downtime, at upang mabawasan ang downtime na dulot ng pagkabigo sa mail store, maaaring i-deploy ng IT manager ang backup nito. kopyahin sa ibang server.
Dahil walang built-in na backup system sa Zimbra OSE, kakailanganin namin ang Zextras Backup, na sumusuporta sa real-time na backup, at external na storage. Dahil ang Zextras Backup, kapag gumagawa ng buo at incremental na pag-backup, ay naglalagay ng lahat ng data sa /opt/zimbra/backup na folder, makatuwirang i-mount dito ang external, network o kahit na cloud storage, upang kung mabigo ang isa sa mga server, magkakaroon ka ng media na may backup na kopya na kasalukuyan noong panahon ng emergency. Maaari itong i-deploy sa isang backup na pisikal na server, sa isang virtual machine, o sa cloud. Magandang ideya din na mag-install ng MTA na may spam filter sa harap ng Zimbra Proxy server upang mabawasan ang dami ng junk traffic na dumarating sa server.
Bilang resulta, ang protektadong imprastraktura ng Zimbra ay magiging ganito:
Sa pagsasaayos na ito, ang imprastraktura ng Zimbra ay hindi lamang makakapagbigay ng mga de-kalidad na serbisyo sa 10.000 mga gumagamit, kundi pati na rin sa kaganapan ng isang emergency na sitwasyon, ito ay magbibigay-daan sa mga kahihinatnan nito na maalis sa lalong madaling panahon.
Pinagmulan: www.habr.com