¿Cómo construir un sistema Postfix de alta disponibilidad?


12

Necesito configurar un espejo remoto para un servidor postfix (donde el contenido de ambos servidores de correo debe ser el mismo en cualquier momento).

La idea es que si el servidor principal se cae en algún momento, el servidor espejo tomará su lugar, administrará los nuevos correos entrantes, y cuando el servidor de correo electrónico vuelva a aparecer, lo actualizará con los nuevos correos electrónicos y regresará Es el control para gestionar los nuevos correos entrantes.

Los servidores de correo estarán alojados en diferentes lugares (es decir, maindomain.com, themirrorsite.com).

Obtener un servidor de respaldo simple no parece demasiado difícil:

Pero el problema es que esta configuración no haría que el sitio de respaldo sea un espejo completo del servidor de correo principal (contendrá solo los correos electrónicos recibidos mientras el servidor principal está inactivo).

¿Hay alguna manera de lograr la configuración requerida?

Respuestas:


22

El resultado que desea lograr y la manera en que ha decidido hacerlo son cosas muy diferentes. Para ser franco, lo que desea implementar es una mala idea, y si de alguna manera puede lograr que funcione, no funcionará por mucho tiempo (o muy bien).

Lo que hace que esta pregunta sea difícil de responder es que ha saltado directamente a la implementación y no ha descrito nada útil sobre su entorno o lo que está tratando de lograr. Por favor, no hagas eso, obtendrás mejores resultados aquí si "muestras tu trabajo".

Sin embargo, permítanme plantear un par de escenarios para darle una idea de lo que es posible, práctico y útil:

  • Asegurarse de que no se pierda ningún correo: (No creo que esto sea lo que necesita, ya que la documentación a la que hace referencia lo cubre adecuadamente) Todo lo que quiere tener aquí es asegurarse de que, independientemente de cuánto tiempo esté inactiva su infraestructura de administración y entrega de correo, no devuelve cualquier correo y puede controlar cuándo se realiza la entrega. Para esto, un MX de respaldo "simple" fuera del sitio funcionará adecuadamente. Digo "simple" porque necesita replicar una gran cantidad de datos en la copia de seguridad (toda la lógica antispam, información válida de usuario / alias para que pueda devolver correctamente el correo no válido en el momento SMTP, ese tipo de cosas), pero todo es programable , automatizable y bastante trivialmente implementable con un poco de cuidado. Mientras tenga suficiente disco para poner en cola todo el correo,
  • Garantizar la disponibilidad total del sistema de correo : Parece que esto es lo que desea, pero no es simple ni bonito. Básicamente, desea poder proporcionar un servicio de correo "completo" a su base de usuarios en caso de una falla completa del sitio. En principio, esto es realmente imposible, porque la replicación no es instantánea, pero al menos puede alcanzar un nivel razonable de confiabilidad. Sin embargo, lo difícil no es el MTA; Es la tienda de correo en sí. Tendrá que encontrar una manera de replicar todas las operaciones de almacenamiento de correo (entrega de correo nuevo, cambios de estado del mensaje, eliminación) en el segundo sitio en tiempo casi real, y hacerlo en ambos sentidos, dependiendo de qué sitio esté activo . Puede tomar la opción barata, de una rsync periódica (con el riesgo de que cualquier cosa realizada desde la última rsync desaparezca para siempresi necesita una conmutación por error), o busque varias técnicas de replicación a nivel de archivo o de bloque para intentar mantener las cosas sincronizadas casi en tiempo real (reduciendo la cantidad de pérdida de datos a cambio de una configuración y operación significativamente más complicadas) . Algunos sistemas de correo tienen soporte para algún tipo de replicación incorporada, lo que puede facilitar la vida. Luego está todo el tema de conmutación por error, y cómo se hace eso, y luego no volver , que es más duro de nuevo, y finalmente tienes que probarlo periódicamente, para asegurarse de que la actualización del sistema operativo que hizo hace un tiempo no lo hizo romper cualquier cosa ...

Básicamente, la última opción es dolorosa y molesta. Mi preferencia personal, si puedes salirte con la tuya (y te sorprenderías con la frecuencia que puedes) es poner todos tus huevos en una canasta, después de asegurarte de que tienes una canasta realmente buena y resistente (ingeniería de sistemas adecuada ), tener a mano un inventario de parches y herramientas para cestas (enfocándose en la alta capacidad de recuperación ), y asegurarse de que las personas sepan que de vez en cuando, algunos huevos pueden romperse y realmente lo lamenta, pero la vida no es perfecta (No haga garantías de SLA que no sean razonables).

Hay momentos en que necesita una disponibilidad ultra alta, y he creado sistemas que lo aseguran, pero no son simples y, en muchos casos, no son rentables, para eso estamos aquí. Sí, HA es genial y sexy, y obtienes credibilidad geek por construir una monstruosa monstruosidad de complejidad, pero no estamos aquí para acariciar nuestros egos. Estamos aquí para ofrecer valor comercial, y lo siento, pero un clúster de correo multisitio de alta disponibilidad de Rube Goldberg no proporcionará tanto valor como un servicio de correo simple y robusto y el ocasional "nosotros" Perdón por la interrupción del servicio de correo, tendremos los sistemas de vuelta en una hora, no dude en tomar un café y un panecillo con nosotros ".


2
No podría haberlo dicho mejor.
voretaq7

44
Lo siento, solo puedo ofrecer un +1
mailq

Creo que un NAS básicamente resuelve el problema del almacenamiento de correo y la sincronización, ¿no? Especialmente si su almacén de correo se hace grande y está alojando correo para numerosos dominios.
Ernie

No, un NAS representa aproximadamente el 5% de todo el problema y perjudica su rendimiento y escalabilidad.
womble

1

Puede lograr esto mediante MX DNS failover + un sistema de replicación de datos.

Para la conmutación por error MX: dos servidores de correo, necesitan ayuda con la configuración de DNS para el respaldo

Para la replicación de datos: http://www.drbd.org/docs/install/

PS


¿Funcionaría drbd con servidores que no están en la misma LAN? El servidor principal y el servidor de conmutación por error deben comunicarse solo a través de Internet, por lo que no estoy seguro de si esto funcionará en ese caso.
VanHackman

DRBD tiene un producto proxy patentado que mejora enormemente la replicación de WAN; no es barato y no se garantiza que mantenga todo actualizado en todas partes.
womble

1

He usado dbmail para lograr una solución similar. dbmail almacena todo el correo electrónico en una base de datos. Puede configurar la replicación de la base de datos para asegurarse de que sus correos electrónicos también estén almacenados en la ubicación remota. Hace que la administración del sistema de correo sea más complicada, ya que debe administrar la base de datos y el correo electrónico.


0

Lo que quieres es la replicación de Postfix, que no creo que Postfix admita de forma nativa. La solución que he visto usar a otras personas es replicar los archivos de datos Postfix entre servidores que usan un sistema de archivos distribuido.


3
Mirroring Postfix es fácil. Pero ese no es el problema. Lo difícil es cómo sincronizar el almacenamiento de correo (mbox o Maildir). Almacenar correos en NFS para IMAP es casi imposible y lleva a tener un punto único de falla nuevamente.
mailq
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.