activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Samplonius <>
Subject Re: SAN Hardware for Master/Slave Architecture
Date Sat, 11 Aug 2007 03:02:20 GMT

----- "RobBugh" <> wrote:
> I'm going to install ActiveMQ in a shared file system Master/Slave
> configuration. I see on the ActiveMQ web site that SAN is suggested as
> the
> shared file system. Unfortunately, I don't know much about SAN
> technology
> and what choices I have. Is there anyone using SAN that would be
> willing to
> share what hardware you are using and any pros and cons to using it,
> especially as it relates to file level locking?

  Well, if you are going to use a SAN/NAS device, you will have to get a good one, as it will
shared between your servers.  If it fails, both servers are useless.

  You really have three choices:  NAS:  CIFS or NFS; SAN:  GFS (cluster file system).  If
you want to go NAS, a Netapp filer is probably the best, and CIFS/NFS locking works.  If you
want to go SAN with a cluster filesystem, well, I can't really recommend GFS.  The requirements
for GFS are quite extensive.

  But even if you go with a SAN solution, you don't need to use file locking and ActiveMQ
Master/Slave.  You could configure the ActiveMQ using a cluster toolset.  On Solaris, the
Cluster Suite could easily mount up the volume of a failed node, and start any services (ActiveMQ
included) that the failed node was doing.

  Personally, I'd avoid the NAS/SAN thing, and use drdb to replicate the volume containing
the ActiveMQ message store to another server.  And then use Hearbeat to start ActiveMQ on
the backup server, if the primary fails.  Nothing is shared this way.

  drdb is the solution recommended by the MySQL company for master database failover too.
 It is a pretty mature solution, but Linux only.

  You should get a Systems Analyst involved earlier on in this project.  Calling in a SAN
specialist afterwards is even more expensive.  And SAN specialists hate SANs setup by people
who didn't fully research or understand the technology they deployed.



View raw message