[Gluster-users] LSI Syncro CS with Glusterfs

[Niels de Vos]

On Wed, Aug 20, 2014 at 09:56:07AM -0400, Eric Horwitz wrote:
> 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?

I think you can do this with a layer of pacemaker and virtual 
ip-addresses. You need an absolute guarantee that only one storage 
server mounts the brick filesystem at the same time, you need 
a management layer like pacemaker for that anyway.

This is what I'd try out, a small pacemaker cluster with:
- nodes: server1 + server2 (use resource grouping if you add all nodes)
- appropriate fencing
- virtual IP-address
- shared disks (ha-lvm?) resource for the brick and /var/lib/glusterd
- pacemaker managed process for starting glusterd after mounting the 
  shared disks

It would work like:
1. server1 and server2 are both working
2. server1 has the virtual-IP, shared disks and gluster procs running
3. server1 fails
4. server2 takes the virtual-IP
5. server2 takes the shared disks
6. server2 mounts the shared disks
7. server2 starts the gluster services

This makes it possible to use the normal "gluster volume" commands, just 
use the virtual-IP instead of the real IP of the systems.

A setup like this surely sounds interesting, please keep us unformed 
about any tests and progress you make.

Thanks,
Niels


> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Aug 20, 2014 at 6:08 AM, Vijay Bellur <vbellur at redhat.com> 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
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users