Saturday 9 March 2013

A couple more clustered services (Squid and Sendmail)

I wanted to cluster a couple of more services that I hadn't needed to originally. One was Squid so I could make sure my Internet proxy service was highly available. And the other was sendmail.

Clustered Squid
Clustering Squid is relatively trivial. I created a clustered logical volume for Squid with an ext4 filesystem (exactly like I had for my previous services) but suitable in size for your cache directory requirements. Then I had in my /etc/sysconfig/squid file (both nodes):

SQUID_CONF="/data/squid/etc/squid/squid.conf"

I copied a /etc/squid to /data/squid/etc/squid preserving permissions.

In this /data/squid/etc/squid/squid.conf I had the following lines (as well as anything else I needed for squid):


http_port corp01clusquid:3128
tcp_outgoing_address 10.1.2.2


# Cache Dir                                                                     
cache_dir ufs /data/squid/var/cache/squid 76800 16 256
                                                                                
# Log directories
cache_access_log /data/squid/var/log/squid/access.log
cache_log /data/squid/var/log/squid/cache.log
cache_store_log /data/squid/var/log/squid/store.log



visible_hostname corp01clusquid

These direct all the logs and cache to the clustered filesystem, so all these subdirectories must exist under /data/squid i.e /data/squid/var/log , /data/squid/var/log/squid/ , /data/squid/var/cache/squid etc with the permissions taken as per the original filesystem ones.

Also the corp01clusquid is what your clients will connect to and so needs to be in DNS (and/or a CNAME to this) and have the IP address of the cluster service (in this case 10.1.2.2). This is also the IP (by the above parameters) that outgoing requests will come from. 

Here are the fragments from the cluster.conf required for this:


<ip address="10.1.2.2" monitor_link="0"/>
                        <fs device="/dev/cluvg00/lv00squid" force_fsck="1" force_unmount="1" mountpoint="/data/squid" name="squidfs" nfslock="1" options="acl" quick_status="0" self_fence="0"/>
               
 <service autostart="1" domain="corp01clusB" exclusive="0" name="squid" recovery="relocate">
                        <script file="/etc/init.d/squid" name="squid"/>
                        <ip ref="10.1.2.2"/>
                        <fs ref="squidfs"/>
</service>

Clustered Sendmail
Sendmail is also relatively easy to cluster, with one wrinkle. I still want both my nodes to locally to be able to send email even if they don't hold the sendmail service.

With this service I again create a clustered logical volume for sendmail with an ext4 filesystem (exactly like I had for my previous services) but suitable in size for your mail spooling needs.

The fragments from my cluster.conf required for this:

 <ip address="10.1.2.3" monitor_link="0"/>          
 <fs device="/dev/cluvg00/lv00sendmail" force_fsck="1" force_unmount="1" mountpoint="/data/sendmail" name="mailfs" nfslock="1" options="acl" quick_status="0" self_fence="0"/>

<service autostart="1" domain="corp01clusB" exclusive="0" name="mail" recovery="relocate">
                        <script file="/etc/init.d/sendmail" name="mail"/>
                        <ip ref="10.1.2.3"/>
                        <fs ref="mailfs"/>
</service>

Then in my sendmail.mc I need lines to redirect my queue and my alias file to the clustered directory. I also have a line to allow sendmail to listen on my clustered IP:

define(`ALIAS_FILE', `/data/sendmail/etc/aliases')dnl
define(`QUEUE_DIR', `/data/sendmail/var/spool/mqueue')dnl

DAEMON_OPTIONS(`Port=smtp,Addr=10.1.2.3, Name=MTA')dnl
CLIENT_OPTIONS(`Family=inet, Address=10.1.2.3')dnl

I don't do local delivery on this box but if you do you may well want to set local delivery to the clustered directory, you'll need to find a suitable sendmail m4 option to do this.

I put aliases in the clustered directory so I'd only have to edit a single copy of this (i.e. not on both nodes). You'll then have to ensure you create all the directories referred to in the options above and ensure their permissions and ownerships match the originals in the filesystem.

Now to ensure both nodes can still locally send email (useful for alerts etc), you need to have in submit.mc:

FEATURE(`msp', `mailhub.my.domain')dnl
define(`SMART_HOST',`mailhub.my.domain')dnl

Where mailhub.my.domain resolves to the clustered service IP (in this case 10.1.2.3). This will cause the local submit to send mail via the service IP on which ever node it's running at the time. 

Ensure sendmail.mc and submit.mc (and anything else you need in /etc/mail that is locally configured for you) are copied to both nodes in /etc/mail. Then you should be done.


No comments:

Post a Comment