Thanks Patrick, In that sort of configuration, wouldn't having a failover configuration where one server can take over another servers brick negate the need for replication? or, wouldn't replicating negate the need for the corosync/pacemaker config, i.e. server 1 goes down, no problem since replication will sync it up once it comes back online? Thanks, Mike -----Original Message----- From: Patrick Irvine [mailto:pirv at cybersites.ca] Sent: Friday, October 22, 2010 2:48 PM To: Mike Hanby; gluster-users at gluster.org Subject: RE: Question about Volume Type when bricks are on SAN Hi mike -----Original Message----- From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of Mike Hanby Sent: Friday, October 22, 2010 12:23 PM To: gluster-users at gluster.org Subject: Question about Volume Type when bricks are on SAN >One final question, is there were a way in Gluster to have a Distributed >with failover, where if server2 dies, server1 can mount server2's LUN, once >server2 was back online, server1 could be told to stop hosting the brick >and return it to server2. In gluster (bye it's self) ... no, but through corosync/pacemaker yes. I am currently doing just that but with ISCSI. In my case: 2 Gluster servers A & B 5 Gluster clients 1 to 5 A and B each attach individual ISCSI targets, mount them and then server them with gluster The clients 1 to 5 then mount a replicated gluster share made from servers A & B If A should go down, then B will attach to the ISCSI target A was using and then re-server it for the clients. When A comes backup up, B stops servering A's resources and disconnects from A's ISCSI target so A can bring it all back online as normal. As a note I am using corosync/pacemaker to control starting, stopping and moving of the required resource. I hope this helps Pat
