http://packages.debian.org/unstable/ceph-resource-agents
|
|
From: James Harper <james.harper@xxxxxxxxxxxxxxxx>
To: Benito Chamberlain <benito@xxxxxxxxxxx>, ceph-users@xxxxxxxx <ceph-users@xxxxxxxx>
Subject: Re: 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
