Implementimi i çdo zgjidhjeje IT në një ndërmarrje fillon me projektimin. Në këtë fazë, menaxheri IT duhet të llogarisë numrin e serverëve dhe karakteristikat e tyre, në mënyrë që ata, nga njëra anë, të jenë të mjaftueshëm për të gjithë përdoruesit, dhe nga ana tjetër, që raporti midis çmimit dhe cilësisë së këtyre serverëve të jetë optimal, duke mos i bërë shpenzimet për krijimin e infrastrukturës së përpunimit për sistemin e ri informatik një goditje serioze në buxhetin IT të ndërmarrjes. Le të shqyrtojmë se si të dizenjojmë infrastrukturën për implementimin në ndërmarrjen Zimbra Collaboration Suite.
Veçoria kryesore e Zimbra-s në krahasim me zgjidhje të tjera është se, për ZCS, zakonisht nuk është fuqia procesorike ose memoria e përkohshme që krijon ngërç. Kufiri kryesor zakonisht është shpejtësia e hyrjes dhe daljes së disque-ve të forta, prandaj vëmendja kryesore duhet t'i kushtohet saktësisht sistemeve të ruajtjes së të dhënave. Kërkesat minimale të shpallura zyrtarisht për Zimbra në ambientin e prodhimit janë një procesor 64-bit me 4 bërthama me 2 gigahertz frekuencë, 10 gigabyte për skedarët sistemikë dhe log-et, si dhe të paktën 8 gigabyte RAM. Zakonisht, këto karakteristika mjaftojnë për një funksionim të shpejtë të serverit. Por çfarë të bëni nëse jeni përballë implementimit të Zimbra për 10,000 përdorues? Cilat serverë dhe si duhet të implementohen në këtë rast?
Le të fillojmë me faktin se infrastruktura për 10,000 përdorues duhet të jetë multi-server. Infrastrukturë multi-server, nga njëra anë, lejon që Zimbra të jetë e shkallëzuar, dhe nga ana tjetër, të arrihet funksionimi reagues i sistemit informatik edhe në rast të një fluksi të madh përdoruesish. Zakonisht, është mjaft e vështirë të parashikohet se sa përdorues një server Zimbra mund të shërbejë cilësisht, pasi shumë gjëra varen nga intensiteti i punës së tyre me kalendarët dhe postën elektronike, si dhe nga protokolli i përdorur. Pikërisht për këtë arsye, për shembull, ne do të implementojmë 4 depo të postës. Në rast të mungesës ose tepricës së fuqive, mund të shkëputet ose të shtohet një tjetër.
Në këtë mënyrë, kur projektoni infrastrukturën për 10,000 njerëz, do të jetë e nevojshme të krijoni serverë LDAP, MTA dhe Proxy, si dhe 4 depo postare. Vlen të theksohet se serverët LDAP, MTA dhe Proxy mund të bëhen virtualë. Kjo do të ndihmojë në uljen e kostove për pajisjet server dhe do të lehtësojë rezervimin dhe rikuperimin e të dhënave, por, nga ana tjetër, në rastin e dështimit të serverit fizik, ju rrezikoni të ngecni pa MTA, LDAP dhe Proxy menjëherë. Prandaj, zgjedhja midis serverëve fizikë ose virtualë duhet të bëhet në përputhje me sa kohë ndalesë ju mund të lejoni në rast të një emergjence. Depo postare do të ishte më mirë të vendosen në servera fizikë, pasi aty do të ndodhin shumica e cikleve të shkruajtes që kufizojnë performancën e Zimbra, dhe kështu numri më i madh i kanaleve për transmetimin e të dhënave do të ndihmojë në rritjen e dukshme të performancës së Zimbra.
Në parim, pas krijimit serverësh LDAP, MTA, Proxy, depo mundesh dhe bashkimin e tyre në një infrastrukturë të vetme, Zimbra Collaboration Suite për 10,000 përdorues është gati për të hyrë në funksionim. Schemi i funksionimit të kësaj konfiguracioni do të jetë mjaft i thjeshtë:
Në diagram është paraqitur nyjet kryesore të sistemit dhe fluxet e të dhënave që do të qarkullojnë midis tyre. Me këtë konfiguracion, infrastruktura do të jetë krejtësisht e pambrojtur nga humbja e të dhënave, ndalesa që lidhet me dështimin e ndonjë serveri dhe kështu me radhë. Le të shohim se si mund ta mbrojmë infrastrukturën tonë nga këto probleme.
Metoda kryesore është te redundanca harduerike. Nyjet shtesë MTA dhe Proxy mund të marrin përkohësisht rolin e serverëve kryesorë në rastin e dështimit të atyre kryesorëve. Dublimi i nyjeve të infrastrukturës kritike për pothuajse gjithmonë është një ide e shkëlqyer, por nuk është gjithmonë e realizueshme në vëllimin e dëshiruar. Një shembull i qartë është rezervimi i serverëve, ku ruhet posta. Aktualisht, Zimbra Collaboration Suite Open-Source Edition nuk mbështet krijimin e depozita dubluese, prandaj në rastin e dështimit të njërit prej këtyre serverëve, nuk do të mund të shmangim ndalesën, dhe për të reduktuar kohën e ndalesës për shkak të dështimit të depo postare, menaxheri IT mund të rivendosë kopjen e saj rezervë në një tjetër server.
Duke se Zimbra OSE nuk ka një sistem të ndërtuar backup-i, do të duhet të përdorim Zextras Backup, i cili mbështet rezervimin në kohë reale, dhe një magazinë ekstern. Duke qenë se Zextras Backup ruan të dhënat në dosjen /opt/zimbra/backup, do të ishte e arsyeshme të bashkangjitet një magazinë ekstern, rrjetërore ose madje edhe në cloud, në mënyrë që në rast të dështimit të njërit nga serverët të kemi një mbështetje me një kopje rezervë të azhurnuar në momentin e emergjencës. Ajo mund të restaurohet si në një server fizik rezervë, ashtu edhe në një makinë virtuale ose në cloud. Një ide e mirë do të ishte gjithashtu të instalohej MTA me një filtrues spami përpara serverit me Zimbra Proxy, për të reduktuar sasinë e trafikut të padëshiruar që mbërrin në server.
Në përfundim, infrastruktura e mbrojtur Zimbra do të duket më shumë kështu:
Me këtë konfigurim, infrastruktura Zimbra jo vetëm që do të jetë në gjendje të ofrojë shërbime cilësore për 10.000 përdorues, por gjithashtu do të lejojë riparimin sa më shpejt të jetë e mundur në rast të një situate emergjente.
Burimi: habr.com
