Servidor de correo empresarial, como?

[Horst von Brand]

Juan Martínez <jeugenio en umcervantes.cl> wrote:
> El jue, 08-06-2006 a las 22:18 -0400, Claudio Bustos Bravo escribió:
> > On Thu, 2006-06-08 at 16:40 -0400, Horst von Brand wrote:
> > > cbustosb en articlynx.cl wrote:

> > > > Me pregunto, que usa la utfsm para procesar todos los correos? 
> > > > cluster de servidores?, round robin en DNS?. Como lo hacen para el
> > > > failover?, replicas?

[...]

> > > Si quieres mayor redundancia, instala un segundo cacharro que acepte
> > > correo y lo encole (MX secundario) /lejos/ (en terminos de red) de
> > > tus maquinas principales.

> Esa medida es muy util a mi juicio.

Ni tanto. Se usa solo cuando el principal no esta alcanzable, y te permite
manejar las cosas alli (p.ej. quedas fuera de la red 6 dias, puedes
extender /alli/ el plazo para rebote, etc). Pero fuera de eso...


Ojo, ideas brillantes estilo varias maquinas y round-robin via DNS solo
llevan a confusion, porque despues tienes tu mbox desparramado entre todas
ellas. O si haces eso, tenerlas para procesamiento pesado (filtros de spam,
antivirus, ...) y luego entregar el flujo ya lavado a /una/ maquina.

> > Muchas gracias, despejas varias dudas acerca del /poderio/ necesario >
> > para un sistema mediano-grande de correo.

> Mira, el poderio yo lo miro del punto de vista de capacidad de memoria y
> secundaria y velocidad de procesamiento.

Y RAM.

> Eso sin duda depende del requerimiento. Si vas necesitas un sistema para
> requerimientos escalables,

Que es "requerimientos escalables"?

>                           lo que debes pensar es en un cluster

No sirve de mucho, realmente... tienes que dividir el trabajo, y eso no es
nada tan facil.

>                                                                (a demas
> un cluster te puede entregar alta disponibilidad).

Cluster == procesamiento paralelo, o cluster == alta disponibilidad? Se usa
el termino en ambos sentidos, que son requerimientos /totalmente/
diferentes, y no se pueden simplemente meter en el mismo saco.

> Una cosa es la cantidad de informacion que necesito procesar (a una
> determinada velocidad ciertamente) y otra es que tan disponible en el
> tiempo debe estar esa informacion.

Exacto.

Y para los requerimientos que encontraras en este (pequen~o) pais, con un
tarro /grande/ (AMD64 x 4, 16GiB RAM, etc) tienes para largo rato.

> En el modelo que plantea el Profesor HvB, me parece que esta mirado
> desde el punto de vista de la cantidad a procesar y no tanto la alta (o
> ilimitada en lo ideal) disponibilidad. la alta disponibilidad puede ser
> muy cara... ;-)

Fail over, etc. Las tecnicas son conocidas, y perfectamente se pueden
aplicar en lo anterior.

> Cuando hablas de un servidor "empresarial" debes acotar cuantas cuentas
> de usuario necesitas, servicios a prestar, cuanto espacio necesita la
> informacion a almacenar...

Mas bien: Volumen de correo a manejar, numero de usuarios concurrentemente
martillando IMAP, taman~os de mboxes a manejar (si, un pastel con un mbox de
1GiB que tiene la genial idea de revisar cada 30s te pone de rodillas
cualquier cacharro...)

> Perfectamente puedo tener un sistema con 20 usuarios, algunos cuantos GB
> de espacio, pero con alta disponibilidad...Puede que no tenga sentido,
> pero en algunos casos muy puntuales, si lo puede tener (por ejemplo, un
> servidor de email para un equipo de gobierno de un pais).

> Entonces a mi juicio, alta disponibilidad con alta capacidad/velocidad
> de almacenamiento/procesamiento no van necesariamente de la mano.

Ya dije antes que son dos requerimientos separados...

> Todo depende del requerimiento una vez mas. Si son para cuentas de
> correo, y el requerimiento dice:

> "2000 usuarios, 500MB de cuota por usuario, aprox 10% de concurrencia en
> los usuarios"...Entonces pienso en un gran tarro.

Define "grande"... un AMD64 con un par de discos rapidos y suficiente RAM
debiera dar.

> Pero si nadie se enoja si de cada muy vez en cuando el tarro se echa a
> perder (por problemas de HW) y eso significa tener el servicio
> deshabilitado unas cuantas horas, entonces la alta disponibilidad puede
> que no sea importante...

Si "muy de vez en cuando" es una vez cada dos an~os...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513