La efektivigo de ajna IT-solvo en entrepreno komenciĝas per dezajno. En ĉi tiu etapo, la IT-administranto devos kalkuli la nombron da serviloj kaj iliaj karakterizaĵoj por ke, unuflanke, ili sufiĉas por ĉiuj uzantoj, kaj aliflanke, por ke la prezo-kvalita rilatumo de ĉi tiuj serviloj estu optimuma kaj la kostoj de kreado de komputika infrastrukturo por nova informsistemo ne faris seriozan truon en la IT-buĝeto de la entrepreno. Ni eltrovu kiel desegni la infrastrukturon por efektivigi la Zimbra Collaboration Suite en entrepreno.
La ĉefa trajto de Zimbra kompare kun aliaj solvoj estas, ke en la kazo de ZCS, la botelkolo malofte fariĝas procesora potenco aŭ RAM. La ĉefa limigo estas kutime la eniga kaj eligo rapido de la malmola disko, kaj tial la ĉefa atento devus esti pagita al datumbutikoj. La oficiale deklaritaj minimumaj postuloj por Zimbra en produktadmedio estas 4-kerna 64-bita procesoro kun 2 GHz-horloĝrapideco, 10 gigabajtoj por sistemaj dosieroj kaj protokoloj, kaj 8 gigabajtoj da RAM. Tipe, ĉi tiuj karakterizaĵoj sufiĉas por respondema servila operacio. Sed kio se vi devas efektivigi Zimbra por 10 uzantoj? Kiuj serviloj kaj kiel devus esti efektivigitaj en ĉi tiu kazo?
Ni komencu per la fakto, ke la infrastrukturo por 10 mil uzantoj estu plur-servilo. Unuflanke, la plurservila infrastrukturo ebligas igi Zimbra skalebla, kaj aliflanke atingi respondeman funkciadon de la informsistemo eĉ kun granda enfluo de uzantoj. Kutime estas sufiĉe malfacile antaŭdiri precize kiom da uzantoj Zimbra servilo povos bone servi, ĉar multe dependas de la intenseco de ilia laboro kun kalendaroj kaj retpoŝto, kaj ankaŭ de la protokolo uzata. Tial, ekzemple, ni efektivigos 4 poŝtajn stokaĵojn. Okaze de manko aŭ grava troo de kapacito, eblos aŭ malŝalti aŭ aldoni alian.
Tiel, kiam vi desegnas infrastrukturon por 10.000 homoj, estos necese krei LDAP, MTA kaj Proxy-servilojn kaj 4 poŝtajn stokaĵojn. Notu, ke LDAP, MTA kaj Prokuraj serviloj povas fariĝi virtualaj. Ĉi tio reduktos la koston de servila aparataro kaj faciligos datumojn sekurkopion kaj reakiron, sed aliflanke, en la okazo de fizika servilo fiasko, vi riskas esti tuj sen MTA, LDAP kaj Proxy. Tial la elekto inter fizikaj aŭ virtualaj serviloj devus esti farita surbaze de kiom da malfunkcio vi povas pagi en kazo de krizo. Poŝtaj stokado, aliflanke, estus plej bone lokitaj sur fizikaj serviloj, ĉar estas sur ili, ke la ĉefa nombro da skribcikloj okazos, kiuj limigas la agadon de Zimbra, kaj tial pli granda nombro da kanaloj por transdono de datumoj signife. pliigi la agadon de Zimbra.
Principe, post kreado de LDAP, MTA, Prokuraj serviloj, retaj stokaĵoj kaj kombini ilin en ununuran infrastrukturon, la Zimbra Collaboration Suite por 10000 uzantoj estas preta por ekfunkciigo. La skemo de funkciado de tia agordo estos sufiĉe simpla:
La diagramo montras la ĉefajn nodojn de la sistemo kaj la datumfluojn kiuj cirkulos inter ili. Kun ĉi tiu agordo, la infrastrukturo estos tute senprotekta kontraŭ datumperdo, malfunkcio asociita kun malsukceso de iu ajn el la serviloj, ktp. Ni rigardu ĝuste kiel vi povas protekti vian infrastrukturon kontraŭ ĉi tiuj problemoj.
La ĉefa metodo estas hardvarredundo. Pliaj MTA kaj Proxy-nodoj povas, okaze de malsukceso de la ĉefaj serviloj, provizore transpreni la rolon de la ĉefaj. Duobligi kritikajn infrastrukturajn nodojn preskaŭ ĉiam estas bonega ideo, sed ne ĉiam farebla laŭ la mezuro kiun vi volas. Frapa ekzemplo estas la redundo de serviloj, kiuj stokas poŝton. Zimbra Collaboration Suite Open-Source Edition nuntempe ne subtenas la kreadon de duplikataj butikoj, do se unu el ĉi tiuj serviloj malsukcesas, malfunkciotempo ne povas esti evitita, kaj por redukti malfunkcion kaŭzitan de fiasko de poŝtbutiko, IT-administranto povas deploji sekurkopion de ĝi sur alia servilo.
Ĉar ne ekzistas enkonstruita rezerva sistemo en Zimbra OSE, ni bezonos Zextras Backup, kiu subtenas realtempan sekurkopion, kaj eksteran stokadon. Ĉar Zextras Backup, prenante plenajn kaj pliigajn sekurkopiojn, metas ĉiujn datumojn en la dosierujon /opt/zimbra/backup, estus racie munti eksteran, reton aŭ eĉ nuban stokadon en ĝin, tiel ke en la okazo unu el la serviloj. kraŝoj, vi havas amaskomunikilaron kun ĝisdata rezerva kopio en la momento de la krizo. Ĝi povas esti deplojita kaj sur redunda fizika servilo, kaj sur virtuala maŝino kaj en la nubo. Ankaŭ estas bona ideo instali MTA kun spamfiltrilo antaŭ la servilo kun Zimbra Proxy por redukti la kvanton da rubotrafiko eniranta la servilon.
Kiel rezulto, la sekura infrastrukturo de Zimbra aspektos kiel ĉi tio:
Kun ĉi tiu agordo, la infrastrukturo de Zimbra ne nur povos liveri kvalitajn servojn al 10.000 uzantoj, sed ankaŭ en kazo de kriz-situacio, ĝi permesos forigi siajn konsekvencojn kiel eble plej rapide.
fonto: www.habr.com