Zimbra Proxy HA

Revision as of 16:04, 28 October 2015 by Frederic Maussion (talk | contribs) (Created page with "{{BC|Community Sandbox}} __FORCETOC__ <div class="col-md-12 ibox-content"> =Proxy Resiliency= {{KB|{{Unsupported}}|{{ZCS 8.0}}|{{ZCS 8.6}}|{{ZCS 8.5}}|}} {{WIP}} == User Stor...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Proxy Resiliency

   KB 22404        Last updated on 2015-10-28  




0.00
(0 votes)


User Story

When creating a multi-server architecture and you want to deploy the proxy service in the DMZ, you will probably want to make the service highly resilient. To provide high availibility to the Zimbra Proxy you can use the VIP method.

One of the easy solution is to crate a VIP that will go to the active server in a standard active-passive design Zimbra does not provide natively this kind of solution, so using an external tool you will have the possibility to migrate the VIP to the active proxy. One of the tool you can use is Keepalived . Many others are available.

Target solution

DNS Name IP Role
proxy01.zimbra.lab 192.168.239.10 Proxy
proxy02.zimbra.lab 192.168.239.20 Proxy
mbx.zimbra.lab 192.168.239.50 Mailstore
mail.zimbra.lab 192.168.239.30 VIP

Zimbra Proxy HA target solution.gif

Installation of Keepalived

Keepalived is available from the standard repositories.

RHEL/CentOS

yum install keepalived

Ubuntu

apt-get install keepalived

Configuration of Keepalived

You will need to configure one simple file on each server located
 /etc/keepalived/keepalived.conf 
for a standard installation.

Below the variables you need to adapt to reflect your environment

Variable Example content
notification_email admin@zimbra.lab
notification_email_from vrrp_proxy01@zimbra.lab
smtp_server mbx.zimbra.lab
interface eth0
mail.zimbra.lab 192.168.239.30
vrrp_unicast_bind 192.168.239.10
vrrp_unicast_peer 192.168.239.20
virtual_ipaddress 192.168.239.30 dev eth0 label Zimbra_VIP
auth_pass MY_SECURE_PASSWORD

This configuration should work on a cloud environment as we are using unicast for the vrrp

Master Server

global_defs {
  notification_email {
    admin@zimbra.lab
  }
  notification_email_from vrrp_proxy01@zimbra.lab
    smtp_server mbx.zimbra.lab
    smtp_connect_timeout 30
}

vrrp_script chk_nginx_service {
    script "killall -0 nginx"
    interval 3
}

vrrp_instance VI_1 {
    interface eth0
    state MASTER
    virtual_router_id 51
    priority 101
    advert_int 1
    #No Failback
    nopreempt
    #send an alert email
    smtp_alert
    vrrp_unicast_bind 192.168.239.10
    vrrp_unicast_peer 192.168.239.20
    virtual_ipaddress {
           192.168.239.30 dev eth0 label Zimbra_VIP
    }
    authentication {
           auth_type PASS
           auth_pass MY_SECURE_PASSWORD
    }
    track_script {
            chk_nginx_service
    }
}


Backup Server

global_defs {
  notification_email {
    admin@zimbra.lab
  }
  notification_email_from vrrp_proxy02@zimbra.lab
    smtp_server mbx.zimbra.lab
    smtp_connect_timeout 30
}

vrrp_script chk_nginx_service {
    script "killall -0 nginx"
    interval 3
}

vrrp_instance VI_1 {
    interface eth0
    state BACKUP
    priority 100
    virtual_router_id 51
    advert_int 1
    #No Failback
    nopreempt
    #send an alert email
    smtp_alert
    vrrp_unicast_bind 192.168.239.20
    vrrp_unicast_peer 192.168.239.10
    virtual_ipaddress {
           192.168.239.30
    }
    authentication {
           auth_type PASS
           auth_pass MY_SECURE_PASSWORD
    }
    track_script {
            chk_nginx_service
    }
}

Finally we start the service and put it at system startup

RHEL/CentOS

With standard init

chkconfig keepalived on
service keepalived start

With systemd

systemctl enable keepalived
systemctl start keepalived


Ubuntu

update-rc.d keepalived default

Testing & Validation

If you want to test your configuration, you simply have to kill the nginx process on the master server.

killall nginx

and check for the changes in the /var/log/messages for RHEL/CentOS or /var/log/syslog for Ubuntu.

Additional Notes

If you are planning a high load on the servers, you can use two VIP in addition of a DNS round robin method to provide a cross availibility service. If a node (the proxy) fails the VIP will pass to the other node and you will have a service that run in degrated mode but still available.

Verified Against: ZCS 8.0, ZCS 8.5, ZCS 8.6 Date Created: 11/28/2015
Article ID: https://wiki.zimbra.com/index.php?title=Zimbra_Proxy_HA Date Modified: 2015-10-28



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »


Jump to: navigation, search