Okay so this is as I speculated. There would not be an automated way to do this that is already built into gluster.
Maybe this is really a feature request then..... Wouldn't it be advantageous to be able to replicate the path through 2 servers to the same brick instead of replicating the data on the brick. The assumption being there is a HA failover path built into the hardware to the storage. server1(M) -----> /dev/brick1 <------ server2(S) server3(M) -----> /dev/brick2 <------ server4(S) Active server nodes are server1 and server3 Slave server nodes are server2 and server4 If server1 went down server2 would take over to build this volume would use syntax like: *# volume create glfs1 stripe 2 server1,server2:/dev/brick1 server3,server4:/dev/brick2* The point to all of this is cost savings by using active-active storage without needing to replicate data. Active-active storage is more expensive than a typical JBODs however, I wouldn't need 2 JBODs for the same space with replication thereby reducing $/GiB cost. Thoughts? On Wed, Aug 20, 2014 at 6:08 AM, Vijay Bellur <[email protected]> wrote: > On 08/20/2014 02:15 AM, Eric Horwitz wrote: > >> Well the idea is to build a dual server cluster in a box using hardware >> meant more for Windows storage server 2012. This way we do not need to >> replicate data across the nodes since the 2 servers see the same block >> storage and you have active failover on all the hardware. Dataon has a >> system for this and they even suggest using gluster however, I cannot >> seem to figure out how to implement this model. All gluster nodes would >> need to be active and there doesn't seem to be a master - slave failover >> model. Thoughts? >> >> > One way of doing this could be: > > - Both servers have to be part of the gluster trusted storage pool. > > - Create a distributed volume with a brick from one of the servers, say > server1. > > - Upon server failover, replace/failover the brick by bringing in a new > brick from server2. Both old and new bricks would need to refer to the same > underlying block storage. I am not aware of what hooks Syncro provides to > perform this failover. Brick replacement without any data migration can be > achieved by: > > volume replace-brick <volname> <src-brick> <dst-brick> commit force > > -Vijay >
_______________________________________________ Gluster-users mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-users
