La implementació de qualsevol solució informàtica en una empresa comença amb el disseny. En aquesta fase, el responsable informàtic haurà de calcular el nombre de servidors i les seves característiques perquè, d'una banda, siguin suficients per a tots els usuaris, i d'altra banda, perquè la relació qualitat-preu d'aquests servidors sigui òptim i els costos de creació d'una infraestructura informàtica per a un nou sistema d'informació no fan un forat greu en el pressupost informàtic de l'empresa. Anem a descobrir com dissenyar la infraestructura per implementar la Suite de col·laboració Zimbra en una empresa.
La característica principal de Zimbra en comparació amb altres solucions és que en el cas de ZCS, el coll d'ampolla rarament es converteix en potència del processador o RAM. La principal limitació sol ser la velocitat d'entrada i sortida del disc dur i, per tant, s'ha de prestar una atenció principal als magatzems de dades. Els requisits mínims establerts oficialment per a Zimbra en un entorn de producció són un processador de 4 nuclis de 64 bits amb una velocitat de rellotge de 2 GHz, 10 gigabytes per a fitxers i registres del sistema i 8 gigabytes de RAM. Normalment, aquestes característiques són suficients per al funcionament del servidor sensible. Però, què passa si heu d'implementar Zimbra per a 10 usuaris? Quins servidors i com s'han d'implementar en aquest cas?
Comencem pel fet que la infraestructura per a 10 mil usuaris hauria de ser multiservidor. D'una banda, la infraestructura multiservidor permet fer Zimbra escalable i, d'altra banda, aconseguir un funcionament sensible del sistema d'informació fins i tot amb una gran afluència d'usuaris. Sol ser bastant difícil predir amb exactitud quants usuaris podrà servir bé un servidor Zimbra, ja que depèn molt de la intensitat del seu treball amb calendaris i correu electrònic, així com del protocol utilitzat. És per això que, per exemple, implementarem 4 emmagatzematges de correu. En cas d'escassetat o d'excés d'aforament greu, es podrà desactivar o afegir-ne un altre.
Així, a l'hora de dissenyar una infraestructura per a 10.000 persones, caldrà crear servidors LDAP, MTA i Proxy i 4 emmagatzematges de correu. Tingueu en compte que els servidors LDAP, MTA i Proxy es poden fer virtuals. Això reduirà el cost del maquinari del servidor i facilitarà la còpia de seguretat i la recuperació de dades, però d'altra banda, en cas d'error físic del servidor, correu el risc de quedar-vos immediatament sense MTA, LDAP i Proxy. És per això que l'elecció entre servidors físics o virtuals s'ha de fer en funció del temps d'inactivitat que et puguis permetre en cas d'emergència. Els emmagatzematges de correu, en canvi, estarien millor situats en servidors físics, ja que és en ells on es produirà el principal nombre de cicles d'escriptura, que limiten el rendiment de Zimbra i, per tant, un nombre més gran de canals per a la transferència de dades serà significativament augmentar el rendiment de Zimbra.
En principi, després de crear LDAP, MTA, servidors intermediaris, emmagatzematge de xarxa i combinar-los en una única infraestructura, la Zimbra Collaboration Suite per a 10000 usuaris està preparada per a la posada en funcionament. L'esquema de funcionament d'aquesta configuració serà bastant senzill:
El diagrama mostra els nodes principals del sistema i els fluxos de dades que circularan entre ells. Amb aquesta configuració, la infraestructura quedarà completament desprotegida de la pèrdua de dades, temps d'inactivitat associat a la fallada de qualsevol dels servidors, etc. Vegem exactament com podeu protegir la vostra infraestructura d'aquests problemes.
El mètode principal és la redundància de maquinari. Els nodes MTA i Proxy addicionals poden, en cas de fallada dels servidors principals, assumir temporalment el paper dels principals. Duplicar nodes d'infraestructura crítica és gairebé sempre una gran idea, però no sempre és factible en la mesura que vulgueu. Un exemple sorprenent és la redundància dels servidors que emmagatzemen el correu. Zimbra Collaboration Suite Open-Source Edition no admet actualment la creació de botigues duplicades, de manera que si un d'aquests servidors falla, no es pot evitar el temps d'inactivitat i, per reduir el temps d'inactivitat causat per una fallada de la botiga de correu, un gestor de TI pot desplegar-ne una còpia de seguretat. un altre servidor.
Com que no hi ha cap sistema de còpia de seguretat integrat a Zimbra OSE, necessitarem Zextras Backup, que admet còpies de seguretat en temps real i emmagatzematge extern. Atès que Zextras Backup, en fer còpies de seguretat completes i incrementals, posa totes les dades a la carpeta /opt/zimbra/backup, seria raonable muntar-hi emmagatzematge extern, de xarxa o fins i tot en núvol, de manera que en cas que un dels servidors en cas de bloqueig, teniu un suport amb còpia de seguretat actualitzada en el moment de l'emergència. Es pot desplegar tant en un servidor físic redundant, com en una màquina virtual i al núvol. També és una bona idea instal·lar un MTA amb un filtre de correu brossa davant del servidor amb Zimbra Proxy per reduir la quantitat de trànsit brossa que entra al servidor.
Com a resultat, la infraestructura segura de Zimbra tindrà un aspecte semblant a això:
Amb aquesta configuració, la infraestructura de Zimbra no només podrà donar serveis de qualitat a 10.000 usuaris, sinó que, en cas d'emergència, permetrà eliminar les seves conseqüències el més ràpidament possible.
Font: www.habr.com