postmulti and vip with corosync/pacemaker

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

postmulti and vip with corosync/pacemaker

Olivier Brousselle
Hello,

I'm trying to install failover multi instances of postfix on a 2
machines Centos 6, with postfix 2.6, corosync and pacemaker and use of
virtual IP.
No SElinux enable.

Each instance use a virtual IP, and each virtual IP comes from
pacemaker. So only one machine have vip.
In my configuration, 192.168.1.100 is the virtual ip for the instance
postfix-mta (vip-mta.mydomain.fr).
and the result of postconf :

############## /etc/postfix/main.cf
alias_database =
alias_maps =
config_directory = /etc/postfix
inet_interfaces = loopback-only
inet_protocols = ipv4
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
master_service_disable = inet
multi_instance_directories = /etc/postfix-mta
multi_instance_enable = yes
multi_instance_wrapper = ${command_directory}/postmulti -p --
mydestination =
mydomain = mydomain.fr
myhostname = vm-test-postmulti.mydomain.fr
mynetworks = 127.0.0.1
myorigin = $mydomain
relayhost = [smtp.mydomain.fr]
transport_maps = hash:/etc/postfix/transport

############## /etc/postfix-mta/main.cf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
authorized_submit_users =
config_directory = /etc/postfix-mta
data_directory = /var/lib/postfix-mta
debug_peer_level = 2
default_destination_concurrency_limit = 20
default_destination_recipient_limit = 200
inet_interfaces = 192.168.1.100
inet_protocols = ipv4
master_service_disable =
multi_instance_enable = no
multi_instance_group = mta
multi_instance_name = postfix-mta
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = mydomain.fr
myhostname = vip-mta.mydomain.fr
mynetworks = 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24,
192.168.4.0/24, 192.168.5.0/24
mynetworks_style = host
queue_directory = /var/spool/postfix-mta
smtpd_banner = $myhostname - Serveur MTA
smtpd_client_restrictions = check_client_access
hash:/etc/postfix-mta/client_access
transport_maps = hash:/etc/postfix-mta/transportList,
ldap:/etc/postfix-mta/ldap-transport-1.cf,
ldap:/etc/postfix-mta/ldap-transport-2.cf
unknown_local_recipient_reject_code = 450
virtual_alias_maps = hash:/etc/postfix-mta/virtual,
ldap:/etc/postfix-mta/ldap-reecriture-listes.cf


Each instance is marked as disable, there is a script to activate
instances (postmulti -i postfix-mta -e enable ; postmulti -i postfix-mta
-e start) for using with pacemaker.

The problem is when i use postfix start. The default instance start
without any problem, but postfix reports "fatal: parameter
inet_interfaces: no local interface found for 192.168.1.100", and the
init script is marked as failed...
This is normal because the vip is not up, but my instance postfix-mta is
disabled.

Is there a way to configure all my instances with virtual ip, and when
starting postfix just start primary instance without failed message ?
The other instances will be started with pacemaker after starting vip on
one machine.

Thanks in advance...

--
Olivier Brousselle
Rectorat de Rouen - DSI - Equipe Infrastructures

Reply | Threaded
Open this post in threaded view
|

Re: postmulti and vip with corosync/pacemaker

Viktor Dukhovni
On Fri, Jan 18, 2013 at 09:57:37AM +0100, Olivier Brousselle wrote:

> Each instance is marked as disable, there is a script to activate
> instances (postmulti -i postfix-mta -e enable ; postmulti -i
> postfix-mta -e start) for using with pacemaker.

That is:

        # Turn it on for postmulti start
        postmulti -i postfix-mta -e enable

        # Start it.
        postmulti -i postfix-mta -p start

Another option is to never explicitly enable such instances, and
start them via "postfix -c /etc/postfix-mta start", (only when the
host is primary for the VIP). This way when the machine boots normal
system Postfix start does not enable the VIP instance, instead
you have separate start/stop code for that managed by the cluster
state.

> The problem is when i use postfix start. The default instance start
> without any problem, but postfix reports "fatal: parameter
> inet_interfaces: no local interface found for 192.168.1.100", and
> the init script is marked as failed...

This is because "postconf" is unable to process the instance settings
due to:

    main.cf:
        # Presumed VIP
        inet_interfaces = 192.0.2.1

not being a local address. The solution for floating VIPs is:

    main.cf:
        # IP addresses set in master.cf
        inet_interfaces = all

    master.cf:
        192.0.2.1:smtp inet n - n - - smtpd
        ...

This way:

    - The instance is still able to drain its queue if storage is
      not shared via SAN (and unavailable when a slave).

    - The postconf command does not fail when parsing the instance
      parameters.

> Is there a way to configure all my instances with virtual ip, and
> when starting postfix just start primary instance without failed
> message ?

To avoid running "postfix check" on disabled instances, don't list
them as slaves in the default Postfix configuration. You can remove
them from the default instance list after you set them up, or just
manage them without "postmulti".

The "postmulti" command is designed for static multi-instance
configurations, where more than one Postfix instance starts via a
boiler-plate system start-script that need not be aware of instances.

Your dynamic cluster setup may be better off with "ships in the night"
instances, built by hand, and started explicitly via postfix(1) rather
than postmulti(1).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: postmulti and vip with corosync/pacemaker

Olivier Brousselle
Thanks for the reply,

So, I can just use postmulti to create instances and then detach them
with postmulti -i instance -e deport.
And finally modify init script to start instances with postfix -c
/directory/of/instance instead of postmulti -i instance -p start.

Greetings

--
Olivier


Le 18/01/2013 20:23, Viktor Dukhovni a écrit :

> On Fri, Jan 18, 2013 at 09:57:37AM +0100, Olivier Brousselle wrote:
>
>> Each instance is marked as disable, there is a script to activate
>> instances (postmulti -i postfix-mta -e enable ; postmulti -i
>> postfix-mta -e start) for using with pacemaker.
> That is:
>
> # Turn it on for postmulti start
> postmulti -i postfix-mta -e enable
>
> # Start it.
> postmulti -i postfix-mta -p start
>
> Another option is to never explicitly enable such instances, and
> start them via "postfix -c /etc/postfix-mta start", (only when the
> host is primary for the VIP). This way when the machine boots normal
> system Postfix start does not enable the VIP instance, instead
> you have separate start/stop code for that managed by the cluster
> state.
>
>> The problem is when i use postfix start. The default instance start
>> without any problem, but postfix reports "fatal: parameter
>> inet_interfaces: no local interface found for 192.168.1.100", and
>> the init script is marked as failed...
> This is because "postconf" is unable to process the instance settings
> due to:
>
>      main.cf:
> # Presumed VIP
> inet_interfaces = 192.0.2.1
>
> not being a local address. The solution for floating VIPs is:
>
>      main.cf:
> # IP addresses set in master.cf
> inet_interfaces = all
>
>      master.cf:
> 192.0.2.1:smtp inet n - n - - smtpd
> ...
>
> This way:
>
>      - The instance is still able to drain its queue if storage is
>        not shared via SAN (and unavailable when a slave).
>
>      - The postconf command does not fail when parsing the instance
>        parameters.
>
>> Is there a way to configure all my instances with virtual ip, and
>> when starting postfix just start primary instance without failed
>> message ?
> To avoid running "postfix check" on disabled instances, don't list
> them as slaves in the default Postfix configuration. You can remove
> them from the default instance list after you set them up, or just
> manage them without "postmulti".
>
> The "postmulti" command is designed for static multi-instance
> configurations, where more than one Postfix instance starts via a
> boiler-plate system start-script that need not be aware of instances.
>
> Your dynamic cluster setup may be better off with "ships in the night"
> instances, built by hand, and started explicitly via postfix(1) rather
> than postmulti(1).
>