Communication between web nodes and the database/caching layer

NOTE: This is a sub-page off the main redundant cloud hosting configuration guide. If you've arrived at this page first, I recommend reviewing the parent page first.

End goal of this step

When you've completed this portion of the guide, you should have the following:

  • a failover haproxy configuration for MySQL and memcached
  • GlusterFS client mounts

Configuring haproxy

As of this post's writing, Fedora 13 does not yet have haproxy 1.4.x packaged. I recommend haproxy 1.4.x because the support for checking MySQL is vastly improved. To get it running, we'll need to compile it. I like to install Fedora's package anyway as it gives you some helpful stuff out of the bag (I hate writing init scripts).

yum -y install gcc gcc-c++ make haproxy
wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.8.tar.gz
tar xzf haproxy-1.4.8.tar.gz
cd haproxy-1.4.8
make TARGET=linux26
make install

You'll need to flip one line in the /etc/init.d/haproxy file to get your compiled haproxy to start up:

exec="/usr/sbin/haproxy"          [original]
exec="/usr/local/sbin/haproxy"    [change to this]

Drop in the new haproxy configuration file:

# cat /etc/haproxy/haproxy.cfg
global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    # stats socket /var/lib/haproxy/stats
 
defaults
    mode                        http
    log                         global
    option                      dontlognull
    timeout connect             1000
    timeout client              300000
    timeout server              300000
    maxconn                     60000
    retries                     3
 
listen  admin_stats 0.0.0.0:5432
    mode                http
    stats uri           /stats
    stats realm         HAPROXY
    stats auth          youruser:htpasswd-password-hash
    stats refresh       5
 
listen mysql 127.0.0.1:3306
    mode tcp
    option mysql-check
    balance roundrobin
    server mysql1 10.1.100.10:3306 check port 3306
    server mysql2 10.1.100.15:3306 check port 3306 backup
 
listen memcached 127.0.0.1:11211
    mode tcp
    balance roundrobin
    server memcached1 10.1.100.10:11211 check port 11211
    server memcached2 10.1.100.15:11211 check port 11211 backup

Start haproxy and ensure it comes up on boot:

/etc/init.d/haproxy start
chkconfig haproxy on

Once it's running, test your connectivity from the web servers to the database servers using the MySQL client utility. You should be able to do something like this:

mysql --host=127.0.0.1 --port=3306 --user=root -p

To test memcached, just try telnetting to the port that haproxy opened for you on each web node:

# telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
MEOW
ERROR

At this point, you may want to reboot one of your database servers to ensure that your haproxy failover is working properly. You can check the haproxy stats page on port 5432 to see the current status.

GlusterFS client

As with the previous guide for the database servers, you'll want to snag the most recent GlusterFS RPM's from Gluster's FTP site. Once they're installed, make your GlusterFS client mountpoint and configure your /etc/fstab:

mkdir -p /mnt/glusterfs
echo "/etc/glusterfs/glusterfs.vol	/mnt/glusterfs	glusterfs	defaults,noatime,log-level=DEBUG	0 0" >> /etc/fstab

When you ran glusterfs-volgen during the database server steps, a file with "client" in the name should have been created. Copy that file to /etc/glusterfs/glusterfs.vol on both of your web nodes. You should be able to mount your GlusterFS volume now:

mount /mnt/glusterfs

On some distributions, you may need to run modprobe fuse to load the FUSE kernel module first (Fedora's mount scripts take care of this for you). When you're done, you should end up with a mounted GlusterFS volume:

# mount | grep gluster
/etc/glusterfs/glusterfs.vol on /mnt/glusterfs type fuse.glusterfs (rw,allow_other,default_permissions,max_read=131072)

You can test it out by dropping a file into your GlusterFS mount on the primary node and then check for it on the secondary node. If it appears on both, you're all set.

Conclusion

After finishing this step, you should have haproxy running on both web nodes providing a way for you to communicate with MySQL and memcached on both database nodes. Also, you should have replicated and highly available storage via GlusterFS for your web content and shared configuration files.

Printed from: http://rackerhacker.com/redundant-cloud-hosting-configuration-guide/communication-between-web-nodes-and-the-databasecaching-layer/ .
© Major Hayden 2012.

1 Comment   »

  • If you have the good fortune to be using a modern memcache client based on libmemcached, I'd advise actually using both memcached servers via the consistent hashing algorithm in the client. This will simplify the introduction of a third node later and will evenly(ish) split network I/O.

RSS feed for comments on this post , TrackBack URI

Leave a Reply

 

  • Welcome! I started this blog as a way to give back to all of the other system administrators who have taught me something in the past. Writing these posts brings me a lot of enjoyment and I hope you find the information useful. If you spot something that's incorrect or confusing, please write a comment and let me know. Drop me a line if there's something you want to know more about and I'll do my best to write a post on the topic.
    -- Major Hayden