Normalmente los sitios que reciben una gran cantidad de email tienen una configuraci�n tipo "switch" como la que se coment� anteriormente en la secci�n "Organizaci�n con divisiones administrativas". En ese caso puede ser conveniente configurar varios computadores para que reciban la carga de mensajes entrantes y la redirijan a los computadores departamentales.
A fin de lograr esto, se suele aplicar dos t�cnicas, a saber, v�a DNS o mediante NAT. En el DNS es posible especificar varios servidores de switch para la organizaci�n con la misma preferencia. Siguiendo el ejemplo de la secci�n se�alada, habr�a que modificar esto:
; archivo de zona de inkacoca.org @ IN MX 10 switch switch IN A 18.1.3.41 lima IN MX 10 lima-mail lima-mail IN A 18.1.3.40 ...Por lo siguiente:
; archivo de zona de inkacoca.org @ IN MX 10 switch switch IN A 18.1.3.41 switch IN A 18.1.3.42 switch IN A 18.1.3.43 lima IN MX 10 lima-mail lima-mail IN A 18.1.3.40 ...Esto supone disponer de tres mailservers llamados "switch" asociados a las direcciones IP 18.1.3.4[123]. Bajo condiciones normales, esto balancear� la carga entre los tres servidores. Para m�s informaci�n, revise la referencia [2] en lo referente a "Round Robin Load Distribution".
El m�todo NAT consistir�a en nuestro ejemplo en redirigir las conexiones destinadas a la direcci�n 18.1.3.41 (no habr�a ning�n cambio en el DNS) hacia un grupo de otras direcciones (DNAT) que realmente est�n asociadas a los servidores de email. Los ruteadores normalmente disponen de estas facilidades (y por supuesto Linux cuando act�a como router, usando el comando iptables.) No lo explicaremos aqu�.
En sitios peque�os el intervalo debe ser corto a fin de asegurar el r�pido env�o (por ejemplo, 15 minutos.) En la mayor�a de sitios, sin embargo, una hora es un tiempo aceptable.
Como se indic�, el intervalo de Queue Run se especifica mediante opciones al ejecutarse sendmail (opci�n -q).
Cuando el intervalo de Queue Run es corto, cuando los mensajes encolados son muchos, y cuando los servidores remotos son lentos, Sendmail puede lanzar muchos procesos "queue runners" concurrentes que intentan en paralelo limpiar la cola. Esto normalmente debe autocontrolarse, pero en situaciones extremas el n�mero de "queue runners" puede ser muy elevado al punto de crear un peligro para el sistema.
La opci�n MaxQueueChildren permite especificar el m�ximo n�mero de procesos "hijos" de Sendmail encargados de procesar la cola simult�neamente. Normalmente no hay l�mite.
El valor m�s adecuado se debe obtener observando el comportamiento "usual" de los queue runners de Sendmail, por ejemplo, mediante un comando como el que se muestra:
[root@edithpiaf root]# ps ax | grep sendmail | grep queue | wc -l 7Esto se debe observar a distintas horas. Un valor razonable puede ser el m�ximo observado durante la semana multiplicado por dos.
Por otro lado, si el sistema constantemente tiene problemas de falta de memoria, y se sospecha que el problema est� asociado a un n�mero elevado de "queue runners", puede ser conveniente reducir esta opci�n gradualmente (quiz� reduciendo 10% al valor observado) a fin de aliviar este problema. Esto ocasionar� que algunos mensajes encolados tarden m�s en procesarse.
La opci�n "Timeout.queuewarn" determina el lapso que permanece un mensaje en cola para generar un mensaje de alerta al redactor del mismo. Esta alerta le permite saber que el mensaje no pudo ser enviado (default=4 horas.)
La opci�n "Timeout.queuereturn" determina el tiempo m�ximo que el sistema mantendr� el mensaje en la cola (intentando enviarlo.) Cuando este tiempo se cumple, el mensaje es eliminado de la cola y se env�a una alerta al redactor (default=5 d�as.)
Por consistencia, Timeout.queuewarn < Timeout.queuereturn.
A fin de que los mensajes "reboten" m�s aprisa (y la cola se libere m�s aprisa), es conveniente en ciertos casos reducir estos valores, por ejemplo:
En el archivo "cf":
O Timeout.queuewarn=2h O Timeout.queuereturn=1dEn M4:
define(`confTO_QUEUEWARN',`2h') define(`confTO_QUEUERETURN',`1d')
El acceso a disco generado por las colas puede ser considerable en sistemas grandes. Una forma de balancear esta carga y mejorar la performance consiste en utilizar discos f�sicos distintos, los cuales pueden montarse y usarse simult�neamente para la cola.
Esto se puede consiguir creando varios subdirectorios a partir de un directorio principal (por ejemplo bajo /var/spool/mqueue) y configur�ndolos en el archivo "cf" (o v�a M4.)
[root@edithpiaf mqueue]# ls -ld /var/spool/mqueue/ drwx------ 2 root mail 4096 oct 5 13:39 /var/spool/mqueue/ [root@edithpiaf mqueue]# cd /var/spool/mqueue [root@edithpiaf mqueue]# mkdir cola1 [root@edithpiaf mqueue]# mkdir cola2 [root@edithpiaf mqueue]# mkdir cola3 [root@edithpiaf mqueue]# chmod 700 cola* [root@edithpiaf mqueue]# mount /dev/sdX cola1 [root@edithpiaf mqueue]# mount /dev/sdY cola2 [root@edithpiaf mqueue]# mount /dev/sdZ cola3 [root@edithpiaf mqueue]# chown root.mail cola* [root@edithpiaf mqueue]# ls -l total 12 drwx------ 2 root mail 4096 oct 11 13:01 cola1 drwx------ 2 root mail 4096 oct 11 13:01 cola2 drwx------ 2 root mail 4096 oct 11 13:01 cola3En el archivo "cf" se colocar�a:
QueueDirectory=/var/spool/mqueue/cola*Por el m�todo M4:
define(`QUEUE_DIR',`/var/spool/mqueue/cola*')Tenga cuidado de no especificar "/var/spool/mqueue/*" pues esto har�a que Sendmail incluya (incorrectamente) los directorios "/var/spool/mqueue/." y "/var/spool/mqueue/..".
Si la carga del sistema se hace muy elevada, es conveniente limitar la operaci�n de Sendmail, al menos para los mensajes de menor prioridad.
Cuando un nuevo mensaje es recibido, Sendmail le calcula su prioridad inicial "PRI" con la f�rmula se�alada anteriormente.
Si la carga es muy elevada, Sendmail tiene la opci�n de no intentar enviar el mensaje, sino, simplemente encolarlo para un intento posterior. Esto ocurrir� si se verifican las siguientes condiciones:
1) La carga promedio del sistema (load average) es mayor que el indicado en la opci�n configurable "QueueLA" (cuyo default es ocho.) La carga promedio es un valor proporcionado por el sistema operativo que se puede obtener con el comando "uptime".
2) Se verifica la ecuaci�n:
PRI > QueueFactor /(LA-QueueLA+1)Recordar que un valor "PRI" m�s elevado es menor prioridad y por tanto hace m�s probable que la ecuaci�n anterior se verifique.
QueueFactor es una opci�n configurable cuyo valor por omisi�n es 600000.
En sistemas grandes puede ser necesario elevar el valor de QueueLA:
O QueueLA=15En M4:
define(`confQUEUE_LA',`15')
La opci�n "RefuseLA" permite especificar un l�mite para la carga promedio del sistema (load average) a partir del cual Sendmail simplemente rechaza los mensajes que se le env�an. Esto, evidentemente asume que quien se est� intentando conectar lo intentar� nuevamente m�s adelante.
El valor por omisi�n de esta opci�n es doce. En sistemas grandes puede ser necesario elevar este valor.
O RefuseLA=18En M4:
define(`confREFUSE_LA',`18')
La opci�n ConnectionRateThrottle permite "relentizar" las conexiones que llegan a un ritmo muy veloz. Por ejemplo, si este par�metro es igual a cinco, en caso de llegar m�s de cinco conexiones en menos de un segundo, s�lo las cinco son atendias inmediatamente. Otras cinco ser�n atendidas luego de un segundo, y as� sucesivamente.
Esta opci�n es adecuada cuando se usan las opciones QueueLA y RefuseLA.
O ConnectionRateThrottle=5En M4:
define(`confCONNECTION_RATE_THROTTLE',`5')