Implementarea oricărui sistem IT în cadrul unei companii începe cu proiectarea. În această etapă, managerul IT trebuie să calculeze numărul de servere și specificațiile acestora, astfel încât, pe de o parte, să fie suficiente pentru toți utilizatorii, iar pe de altă parte, să existe un raport optim între cost și calitate al acestor servere, astfel încât cheltuielile pentru crearea infrastructurii de calcul pentru noul sistem informațional să nu adâncească o breșă serioasă în bugetul IT al companiei. Să analizăm cum ar trebui să fie proiectată infrastructura pentru implementarea suitei Zimbra Collaboration în cadrul companiei.
Principala caracteristică a Zimbra în comparație cu alte soluții este că, în cazul ZCS, «gâtul de sticlă» rareori devine puterea procesorului sau memoria RAM. Principala limitare devine de obicei viteza de citire și scriere a discului dur, astfel că atenția principală ar trebui să fie acordată în special stocării datelor. Cerințele minime oficial declarate pentru Zimbra în medii de producție sunt un procesor pe 64 de biți cu 4 nuclee și 2 GHz, 10 GB pentru fișierele de sistem și jurnale, precum și minimum 8 GB RAM. De obicei, aceste specificații sunt suficiente pentru un server receptiv. Dar ce trebuie să faceți dacă doriți să implementați Zimbra pentru 10.000 de utilizatori? Ce servere și cum ar trebui implementate în acest caz?
Să începem cu faptul că infrastructura pentru 10.000 de utilizatori trebuie să fie multi-server. Infrastructura multi-server permite, pe de o parte, scalarea Zimbra, iar pe de altă parte, asigurarea funcționării receptive a sistemului informațional chiar și în cazul unui aflux mare de utilizatori. De obicei, este destul de dificil să preziceți câți utilizatori poate susține un server Zimbra în mod calitativ, deoarece depinde foarte mult de intensitatea activității lor cu calendarele și emailul, precum și de protocolul folosit. De aceea, pentru exemplu, vom implementa 4 stocări de email. În caz de deficit sau exces semnificativ de capacitate, se poate fie dezactiva, fie adăuga un altul.
Astfel, în proiectarea unei infrastructuri pentru 10.000 de oameni, va fi necesar să creați servere LDAP, MTA și Proxy, precum și 4 stocări de email. Este important de menționat că serverele LDAP, MTA și Proxy pot fi virtualizate. Acest lucru va reduce costurile cu echipamentele serverului și va facilita backup-ul și recuperarea datelor, însă, pe de altă parte, în cazul în care serverul fizic se defectează, riscați să rămâneți repede fără MTA, LDAP și Proxy. De aceea, alegerea între servere fizice sau virtuale ar trebui să se facă în funcție de timpul de nefuncționare pe care vă permiteți în caz de urgență. Stocările de email ar trebui, de asemenea, să fie plasate pe servere fizice, deoarece numărul principal de cicluri de scriere, care limitează performanța Zimbra, va avea loc pe acestea, iar o lățime de bandă mai mare va permite o creștere semnificativă a performanței Zimbra.
În principiu, după crearea servere LDAP, MTA, Proxy, stocări de rețea și integrarea acestora într-o singură infrastructură, Zimbra Collaboration Suite pentru 10.000 de utilizatori este pregătită pentru implementare. Schema de funcționare a acestei configurații va fi destul de simplă:
Schema ilustrează nodurile principale ale sistemului și fluxurile de date care vor circula între acestea. Cu o astfel de configurație, infrastructura nu va fi deloc protejată împotriva pierderii datelor, nefuncționării cauzate de defectarea oricărui server și așa mai departe. Să vedem cum putem proteja infrastructura de aceste probleme.
Metoda principală este redundanța hardware. Nodurile suplimentare MTA și Proxy pot, în caz de defectare a serverelor principale, prelua temporar rolul acestora. Duplicarea nodurilor unei infrastructuri critice este aproape întotdeauna o idee bună, dar nu întotdeauna poate fi implementată în volumul dorit. Un exemplu clar este rezervarea serverelor pe care este stocată poșta. În prezent, Zimbra Collaboration Suite Open-Source Edition nu suportă crearea de stocări redundante, așa că, în caz de defectare a uneia dintre aceste servere, nu se poate evita nefuncționarea, iar pentru a reduce timpul de nefuncționare provocat de defectarea stocării de email, IT managerul poate desfășura backup-ul acesteia pe un alt server. server.
Deoarece Zimbra OSE nu dispune de un sistem de backup încorporat, va fi necesar să folosim Zextras Backup, care suportă backup-uri în timp real, și un stoc external. Având în vedere că Zextras Backup, realizând backup-uri complete și incrementale, salvează toate datele în folderul /opt/zimbra/backup, ar fi rezonabil să montăm acolo un stoc extern, de rețea sau chiar în cloud, pentru a avea un suport cu o copie de rezervă actualizată la momentul incidentului în caz de cădere a unui dintre servere. Aceasta poate fi desfășurată atât pe un server fizic de rezervă, cât și pe o mașină virtuală sau în cloud. De asemenea, ar fi o idee bună să instalăm un MTA cu un filtru anti-spam înainte de serverul cu Zimbra Proxy, pentru a reduce cantitatea de trafic de gunoi care ajunge pe server.
În concluzie, infrastructura protejată Zimbra va arăta aproximativ astfel:
Cu această configurație, infrastructura Zimbra nu numai că va putea oferi servicii de calitate pentru 10.000 de utilizatori, dar în cazul apariției unei situații neprevăzute va permite eliminarea rapidă a efectelor acesteia.
Sursa: habr.com
