Implementarea oricărei soluții IT într-o întreprindere începe cu design. În această etapă, managerul IT va trebui să calculeze numărul de servere și caracteristicile acestora astfel încât, pe de o parte, să fie suficiente pentru toți utilizatorii, iar pe de altă parte, astfel încât raportul preț-calitate al acestor servere este optimă, iar costurile creării unei infrastructuri de calcul pentru noul sistem informatic nu fac o gaură serioasă în bugetul IT al întreprinderii. Să ne dăm seama cum să proiectăm infrastructura pentru implementarea întreprinderii a Zimbra Collaboration Suite.
Principala caracteristică a lui Zimbra în comparație cu alte soluții este că, în cazul ZCS, blocajul este rareori puterea procesorului sau RAM. Principala limitare este de obicei viteza de intrare și ieșire a hard disk-ului și, prin urmare, atenția principală trebuie acordată stocării datelor. Cerințele minime declarate oficial pentru Zimbra într-un mediu de producție sunt un procesor pe 4 nuclee pe 64 de biți cu o viteză de ceas de 2 gigaherți, 10 gigaocteți pentru fișierele și jurnalele de sistem și cel puțin 8 gigaocteți de memorie RAM. În mod obișnuit, aceste caracteristici sunt suficiente pentru ca serverul să funcționeze eficient. Dar dacă trebuie să implementați Zimbra pentru 10 mii de utilizatori? Ce servere și cum ar trebui să fie implementate în acest caz?
Să începem cu faptul că infrastructura pentru 10 mii de utilizatori trebuie să fie multi-server. Infrastructura multi-server, pe de o parte, permite Zimbra să fie scalabilă și, pe de altă parte, să realizeze o funcționare receptivă a sistemului informațional chiar și cu un aflux mare de utilizatori. De obicei, este destul de dificil să prezici cu exactitate câți utilizatori va putea servi eficient un server Zimbra, deoarece multe depind de intensitatea muncii lor cu calendare și e-mail, precum și de protocolul utilizat. De aceea, ca exemplu, vom implementa 4 stocări de mail. În caz de lipsă sau exces grav de capacitate, va fi posibilă fie dezactivarea, fie adăugarea unuia altul.
Astfel, atunci când proiectați o infrastructură pentru 10.000 de persoane, va trebui să creați servere LDAP, MTA și Proxy și 4 stocări de mail. Rețineți că serverele LDAP, MTA și Proxy pot fi făcute virtuale. Acest lucru va reduce costul hardware-ului serverului și va facilita copierea de rezervă și restaurarea datelor, dar, pe de altă parte, dacă serverul fizic eșuează, riscați să rămâneți imediat fără MTA, LDAP și Proxy. De aceea, alegerea între servere fizice sau virtuale ar trebui făcută în funcție de cât timp de nefuncționare vă puteți permite în caz de urgență. Stocările de e-mail ar fi cel mai bine plasate pe serverele fizice, deoarece pe acestea vor avea loc majoritatea ciclurilor de scriere, care limitează performanța Zimbra și, prin urmare, un număr mai mare de canale pentru transferul de date va crește semnificativ performanța Zimbra.
În principiu, după ce a creat LDAP, MTA, servere Proxy, stocarea în rețea și le-a combinat într-o singură infrastructură, Zimbra Collaboration Suite pentru 10000 de utilizatori este gata de punere în funcțiune. Funcționarea acestei configurații va fi destul de simplă:
Diagrama prezintă nodurile principale ale sistemului și fluxurile de date care vor circula între ele. Cu această configurație, infrastructura va fi complet neprotejată împotriva pierderii de date, a timpului de nefuncționare asociat cu defecțiunea oricăruia dintre servere și așa mai departe. Să aruncăm o privire la modul exact în care vă puteți proteja infrastructura de aceste probleme.
Metoda principală este redundanța hardware. Nodurile MTA și Proxy suplimentare pot, în caz de defecțiune a serverelor principale, să preia temporar rolul celor principale. Duplicarea nodurilor de infrastructură critică este aproape întotdeauna o idee grozavă, dar nu este întotdeauna fezabilă în măsura dorită. Un exemplu izbitor este rezervarea serverelor pe care este stocată corespondența. În prezent, Zimbra Collaboration Suite Open-Source Edition nu acceptă crearea de magazine duplicat, așa că dacă unul dintre aceste servere eșuează, timpul de nefuncționare nu va fi evitat și pentru a reduce timpul de nefuncționare cauzat de o defecțiune a magazinului de e-mail, managerul IT poate implementa backup-ul acestuia. copiați pe alt server.
Deoarece nu există un sistem de backup încorporat în Zimbra OSE, vom avea nevoie de Zextras Backup, care acceptă backup în timp real și stocare externă. Deoarece Zextras Backup, atunci când face copii de rezervă complete și incrementale, pune toate datele în folderul /opt/zimbra/backup, ar fi rezonabil să se monteze stocare externă, de rețea sau chiar în cloud, astfel încât, dacă unul dintre servere eșuează, veți avea suportul media cu o copie de rezervă care era curentă la momentul situației de urgență. Poate fi implementat pe un server fizic de rezervă, pe o mașină virtuală sau în cloud. De asemenea, este o idee bună să instalați un MTA cu un filtru de spam în fața serverului Zimbra Proxy pentru a reduce cantitatea de trafic nedorit care vine la server.
Drept urmare, infrastructura protejată Zimbra va arăta cam așa:
Cu această configurație, infrastructura Zimbra nu numai că va putea oferi servicii de înaltă calitate pentru 10.000 de utilizatori, dar și în cazul unei situații de urgență, va permite eliminarea cât mai rapidă a consecințelor acesteia.
Sursa: www.habr.com