Soy Oscar Mas y hoy os quiero ensañar como desplegar un sistema Multi-Server basado en la plataforma de Zimbra, sobre la infraestructura de Amazon Web Services (AWS). El despliegue se basa en dos servidores:
- 192.168.100.10: con las funcionalidades de MTA, Proxy, MemCache, etc.
- 192.168.200.10: tendrá las funcionalidades de LDAP, Storage, etc.
Es aconsejable que antes de sumergirnos en la implementación de un sistema Zimbra Multi-Server en AWS (Amazon Web Services), tengamos una fuerte base de los dos productos, tanto a nivel de AWS como de Zimbra. Para facilitar el despliegue, he dividido en varias partes el procedimiento:
- Configuración del Networking
- Creación del MTA
- Creación del Storage
- Creación del enrutamiento y sistema de firewall
El esquema lógico quedaría de la siguiente manera: 
[alert style=”blue”]Nota: Esta configuración no está soportada oficialmente por Zimbra, por lo tanto todas las pruebas y entorno que se configure sobre Amazon tendrá que estar soportado por vosotros mismos.[/alert]
Configuración del Networking
Una de las primeras cosas a realizar, es la configuración de nuestro VPC (Virtual Private Cloud) desde la consola de AWS (Amazon Web Services), a la cual le asignaremos el rango de red 192.168.0.0/16:
Seguidamente definiremos dos subnets. Una subnet (192.168.100.0/24) donde ubicaremos el servidor que hará las funcionalidades de MTA en nuestra plataforma de Zimbra:
Y otra subnet (192.168.200.0/24) donde ubicaremos el equipo que hará las funcionalidades de Storage:
Como he indicado anteriormente, la red pública (192.168.100.0/24) tendrá acceso a Internet. Por consiguiente haremos que se asigne un IP pública a los equipos que ubiquemos en dicha red. Cabe destacar que en la red Privada no le haremos este procedimiento, ya que el equipo que ubiquemos en dicha red tendrá acceso a Internet a través del servidor de Zimbra MTA.
Creación del MTA
Para la creación del equipo virtual que hará las funcionalidades de MTA en nuestra plataforma de Zimbra, he usado una AMI basada en una CentOS 7. Es aconsejable no usar las instancias t2, ya que no ofrecen un rendimiento lo suficientemente estable para tener en producción una plataforma de Zimbra, lo aconsejable es usar una instancia igual o superior a la m3.
Mientras desplegamos el AMI nos solicitará los datos del Networking. Recordad que este equipo ha de estar ubicado en la Red Pública (192.168.100.0/24), por consiguiente se lo indicaremos. Aprovecharemos para asignarle una IP Privada, que en nuestro caso será la 192.168.100.10 y la protegeremos ante la posibilidad de eliminar todo el equipo si le indicamos Terminar (Protect against accidental termination) desde la consola de EC2
Ampliaremos el disco duro, ya que por defecto viene con 8GB y para un servidor en producción no es suficiente. Le asignaremos un espacio de 20GB para la partición Raíz de nuestro sistema operativo.
Siguiendo el Wizard, nos solicitará los puertos que deseamos abrir (Security Group), solo dejaremos el acceso por SSH ya que más adelante lo acabaremos de configurar. Y una vez acabada de crear la instancia, le asignaremos nuestro Key Pair.
Creación del Storage
La crearemos del mismo tipo que el anterior una m3.medium y ubicaremos la AMI en nuestra red privada. Al igual que hemos hecho en la creación del servidor de MTA, le asignaremos una IP Privada, la cual será la 192.168.200.10
[alert style=”green”]Nota: Jorge recomienda para Storage instancias del tipo i2 (listas y preparadas para un uso intensivo de Storage como es un Mailbox)[/alert]
Al ser un servidor de Storage, lo que haremos es ampliarle la partición Raíz a 20GB y le añadiremos una nueva partición donde ubicaremos el sistema de Zimbra (/opt)
Siguiendo el Wizard, nos solicitará los puertos que deseamos abrir (Security Group), solo dejaremos el acceso por SSH ya que más adelante lo acabaremos de configurar. Y una vez acabada de crear la instancia, le asignaremos nuestro Key Pair.
Una vez acabados de crear los dos equipos, obtendremos el siguiente resultado en nuestra consola de EC2:
Configuración del enrutamiento y sistema de firewall
Lo que realizaremos ahora, es la gestión de todo el tráfico de nuestra plataforma y la gestión de nuestro firewall.
Todo el tráfico de Internet hacia nuestra plataforma será gestionado por nuestro servidor de Zimbra MTA (192.168.100.10). Ya que no es necesario que nuestro sistema de Storage (192.168.200.10) esté expuesto a Internet, pero sí que es necesario que nuestro servidor de Storage (192.168.200.10) pueda acceder a internet para descargarse los paquetes de Zimbra y sus correspondientes dependencias. Lo que haremos es enrutar todo el tráfico de nuestra red privada (192.168.200.10/24) contra nuestro servidor de Zimbra de MTA (192.168.100.10). Para que nuestro servidor de Storage (192.168.200.10) pueda acceder a Internet sin necesidad de estar expuesto, le permitiremos a nuestro servidor de MTA (192.168.100.10) que gestione el tráfico y nos dé acceso a Internet.
El esquema lógico quedaría de la siguiente manera:
Desde la consola VPC, nos crearemos un Internet Gateway el cual nos dará acceso a Internet.
Le añadiremos nuestra VPC, para realizar el enlace lógico:
En nuestra tabla de enrutamiento, le indicaremos que todo el tráfico (0.0.0.0/0), lo envíe a nuestro Internet Gateway. De esta manera conseguiremos que nuestro VPC disponga de acceso a Internet
Añadiendo a nuestra tabla de enrutamiento el Internet Gateway que hemos realizado con anterioridad, conseguimos que nuestro equipo ZCS MTA, tenga acceso a internet y por consiguiente nosotros ya tengamos acceso a nuestra instancia. Recordad que NO le hemos asignado una Elastic IP, por consiguiente cada vez que apaguemos el equipo, se renovará la IP Pública que nos ha asignado Amazon.
En la siguiente captura, podréis observar que desde la instancia: 192.168.200.10, no tenemos acceso a Internet:
El problema que nos encontraremos, es que no tenemos acceso a internet desde nuestro equipo que hará las funcionalidades de Storage. Para conseguir que el equipo de Storage tenga acceso a internet, enrutaremos todo el tráfico de la Red Privada al equipo que hace las funcionalidades de MTA y a este le tendremos que modificar ciertas opciones que veremos más adelante, para que enrute el tráfico hacia internet
En la instancia que nos ha de dar acceso a Internet (192.168.100.10), le deshabilitaremos el “Source/Destination Check”, el cual nos permitirá aceptar paquetes de cualquier destino o origen.
Le indicaremos que queremos deshabilitar la opción:
Accederemos por SSH a nuestro servidor de MTA (192.168.100.10), en el cual configuraremos el masquerading para que el equipo que hace las funcionalidades de Storage salga con la IP correcta y habilitaremos el “IP Forward”, para permitir que los paquetes sean atravesados:
[centos@ip-192-168-100-10 ~]$ sudo bash
[root@ip-192-168-100-10 centos]# vim /etc/rc.local
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.200.0/24 -j MASQUERADE
[root@ip-192-168-100-10 centos]# chmod +x /etc/rc.d/rc.local
[root@ip-192-168-100-10 centos]# vim /etc/sysctl.conf
net.ipv4.ip_forward=1
Desde la tabla de enrutamiento, le asignaremos a nuestro VPC la subnet 192.168.100.0/24:
Crearemos una nueva tabla de rutas y le asociaremos nuestra red privada (192.168.200.0/24)
Ahora solamente nos queda indicarle a nuestra tabla de enrutamiento que está asignada a nuestra red privada (192.168.200.0/24), que todo el tráfico lo enrute hacia nuestro servidor de Zimbra MTA (192.168.100.10)
Habilitaremos en nuestro Security Group, el acceso total de la red 192.168.200.0/24, así si en un futuro queremos añadir otro Storage no necesitaremos reconfigurar nuestro Security Group.
Una vez realizados los pasos anteriores, podremos observar que todo el tráfico de nuestro sistema de Storage (192.168.200.10) fluye atreves de nuestro servidor de Zimbra MTA (192.168.100.10)
A partir de aquí, podremos usar cualquiera de los manuales que ha publicado Jorge para levantar los servicios de Zimbra. Acordaros que hay que abrir los correspondientes puertos en nuestro Security Group, para poder acceder a los servicios de Zimbra.
Muchas gracias por compartir esta información, adicional a esto un tema que hasta ahora no logro dar con la solución es como configurar un registro inverso para la IP elastica que brinda AWS.
Intente creando una zona con una entrada PTR de la forma z.y.x.in-addr.arpa en Route53, pero aun no resuelve.
Tendás algun tip de como lo estas haciendo?
Muy Buen Articulo, gracias por compartir tus conocimientos, una consulta, todo lo que has implementados en AWS cuanto ha sido el costo total?,
Saludos Juan,
Todo dependerá del servidor que escojas, como sabes los MTA y LDAP pueden ir en estancias más básicas, mientras que los Mailboxes será mejor que los pongas en disco rápido, que saldrá algo más caro.
Quizá compensa poner todo en digitalocean o similares? O incluso en AWS Lightsail.
Un saludo
Que tal Jorge, Gracias por tu respuesta, saludos
Hola Jorge, gracias por la respuesta, saludos