Here's a quick Google result for Ceph Resource Agents packages in the
Debian unstable branch. These look to apply to 0.48, but could be used
as a base for a Resource Agent for RBD.
http://packages.debian.org/unstable/ceph-resource-agents
-----Original Message-----
From: James Harper <james.har...@bendigoit.com.au>
To: Benito Chamberlain <ben...@itcsnam.com>, ceph-us...@ceph.com
<ceph-us...@ceph.com>
Subject: Re: [ceph-users] Block device storage
Date: Mon, 5 Aug 2013 10:12:53 +0000
>
> Hi there
>
> I have a few questions regarding the block device storage and the
> ceph-filesystem.
>
> We want to cluster a database (Progress) on a clustered filesystem , but
> the database requires the
> operating system to see the clustered storage area as a block device ,
> and not a network storage area / filesystem.
> It refuses to create database volumes on something like GFS2 / Glusterfs
> , because it sees it as unfit - guessing due
> to the filesystem attributes, the block size is invalid. It complains
> about the size when trying to create the db and says that the max size
> for any volume is 0.
I think that's the wrong way to do it. I'm pretty sure postgres assumes you are
not running on a shared filesystem. You would use the rbd (which is a block
device and not a filesystem) with a regular filesystem on top
(ext3/xfs/whatever) and then make pacemaker or heartbeat control which node
mounted the filesystem, add the IP address, and run the database service. I
don't think postgres itself supports any sort of clustering (although it's been
a while since I looked at it).
I'm not an expert on pacemaker although I do use it regularly. I think you
would:
. Create an IP address resource for postgres
. Create a filesystem resource for /var/lib/postgres (or whatever)
. Create a service resource for postgres, listening on your clustered IP
. Group the above services together
You may also want to have a rbd resource (you'd probably need to write the RA
yourself - I've not seen one) to map the rbd in the above group, or just always
map on each node.
Lots of testing required, and it's a bit of a steep learning curve if you've
never used pacemaker or heartbeat before. Definitely don't ignore the advice on
STONITH.
This link explains how to do it http://clusterlabs.org/wiki/PostgresHowto (with
DRBD, but the rest of it should be applicable)
Another approach is run postgres in a VM and cluster that instead, so the VM
itself would fail over to another node. This is basically what I'm doing for
all my VMs. Of course neither approach protects you if the database itself got
corrupt (or the VM broke in the VM case), only if the active node itself failed.
James
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
NOTICE: Protect the information in this message in accordance with the
company's security policies. If you received this message in error, immediately
notify the sender and destroy all copies.
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
