Gluster and RAID question

scottalanmiller

Using RAID to provide the resilience for a RAIN system would be like buying a Ferrari but then deciding to have a Ford tow it around instead of driving the Ferrari that you already paid for. It'll work, but it won't work as well and it makes having bought the Ferrari make no sense.

Gluster can do resiliency so much more advanced than RAID can. That's the primary reason you'd be looking at it. Why would you want Gluster, but then not want to use it?

RAID can't do a fraction of what RAIN can do. So in this case you'd keep all of the performance impact of RAIN, and the resilience of the RAID would not be nearly as good as what RAID could do alone, nor anything like what RAIN can do. It would be a very crappy level of resiliency that no one would be okay with.

biggen

@scottalanmiller said in Gluster and RAID question:

@biggen said in Gluster and RAID question:

@scottalanmiller No problem. So I'm guessing if one really wanted to use the "distributed" type than RAID would really need to be required if you wanted redundancy. I think I'm wrapping my head around this now.

I think you are thinking about this all wrong.

First, you never use RAIN and RAID together. So anything that's making you think of using RAID with Gluster means you are thinking about it fundamentally wrong. It's not that it's physically impossible, but that it makes no sense.

Second, you never choose distributed if you want redundancy. So never would there be a case where you'd have the distributed type AND want redundancy. You'd choose the redundancy option instead.

So this takes me all the way back to my OP:

Are Distributed Gluster deployments typically in Production?

I guess if one didn't care about redundancy that would be the only use case for that specific architecture. Because the only way to provide it would be with RAID, and you say that running RAID under RAIN isn't the way to ever run RAIN to begin with. So using the "distributed" type of Gluster with RAID to provide redundancy would be a poor choice to ever use with like I was thinking.

scottalanmiller

@biggen said in Gluster and RAID question:

I guess if one didn't care about redundancy that would be the only use case.

Same as with RAID 0. You only skip redundancy when you have no need for it. But there are plenty of cases where there is no need for it.

biggen

Ok. Great thanks Scott. Gives me something to think about. I think I'll play around with a couple VMs today using Gluster and see how it goes.

I have no use case for it. But i figure just experimenting with it for a bit can't hurt.

scottalanmiller

@biggen said in Gluster and RAID question:

I have no use case for it. But i figure just experimenting with it for a bit can't hurt.

It's cool tech, for sure.

stacksofplates

@biggen said in Gluster and RAID question:

@scottalanmiller said in Gluster and RAID question:

@biggen said in Gluster and RAID question:

@scottalanmiller No problem. So I'm guessing if one really wanted to use the "distributed" type than RAID would really need to be required if you wanted redundancy. I think I'm wrapping my head around this now.

I think you are thinking about this all wrong.

First, you never use RAIN and RAID together. So anything that's making you think of using RAID with Gluster means you are thinking about it fundamentally wrong. It's not that it's physically impossible, but that it makes no sense.

Second, you never choose distributed if you want redundancy. So never would there be a case where you'd have the distributed type AND want redundancy. You'd choose the redundancy option instead.

So this takes me all the way back to my OP:

Are Distributed Gluster deployments typically in Production?

I guess if one didn't care about redundancy that would be the only use case for that specific architecture. Because the only way to provide it would be with RAID, and you say that running RAID under RAIN isn't the way to ever run RAIN to begin with. So using the "distributed" type of Gluster with RAID to provide redundancy would be a poor choice to ever use with like I was thinking.

You can do distributed and replicated for a volume. It's not just one or the other.

scottalanmiller

@stacksofplates said in Gluster and RAID question:

You can do distributed and replicated for a volume. It's not just one or the other.

They call the options Distributed, Replicated, and Distributed Replicated.

It's a bit like having RAID 0, RAID 1, and RAID 10.

biggen

Played around with it a bit today. Sharing it out via SAMBA seems a little complicated since you also need to layer CTBD. Is that the standard way to share it out to Windows clients?

scottalanmiller

@biggen said in Gluster and RAID question:

Sharing it out via SAMBA seems a little complicated since you also need to layer CTBD.

Why do you need that?

scottalanmiller

@biggen said in Gluster and RAID question:

Is that the standard way to share it out to Windows clients?

No, that would not be common. The common way is to have Samba in a VM that uses Gluster as a backing share.

biggen

@scottalanmiller Ok, it seems most of the tutorials show it being done with CTBD. I’ve found a couple that just create a standard samba share and export it. I’ll play with that route.

So would samba be installed on each node and then shared out? To which samba node do the clients connect to?

Dashrender

@scottalanmiller it sounds like explaining the whole stack might be in order, and where Gluster/etc fall in that stack.

biggen

Creating a two node Gluster volume was real easy. Its the sharing that I'm having an issue with.

Do you install Samba on both nodes and create identical smb.conf file in order to share out the volume? To which nodes are the Samba clients supposed to connect with? Does it matter?

JaredBusch

@biggen said in Gluster and RAID question:

Creating a two node Gluster volume was real easy. Its the sharing that I'm having an issue with.

Do you install Samba on both nodes and create identical smb.conf file in order to share out the volume? To which nodes are the Samba clients supposed to connect with? Does it matter?

If I am understanding WTF you are trying to do, n o you create the Gluster volume and then go into your hypervisor and attach that volume as the datastore, just like you would do for a RAID array.

biggen

@JaredBusch Once the volume is up and running how the heck does one share it out? That what I'm trying to do. I have a successful two node system running:

joe@glusternode1:/mnt$ sudo gluster volume info

Volume Name: gv0
Type: Replicate
Volume ID: ab19d123-eb34-4186-8a03-316a3fc790e3
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: glusternode1:/data/xvdb1/brick
Brick2: glusternode2:/data/xvdb1/brick
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

That volume must now be mounted "somewhere" to access it. How do I mount it so Windows clients can access it? Do I simply mount the share in one of the nodes under /mnt/big_ole_gluster_space and then share out that mount point via Samba from that same Gluster node?

stacksofplates

@biggen said in Gluster and RAID question:

@JaredBusch Once the volume is up and running how the heck does one share it out? That what I'm trying to do. I have a successful two node system running:
joe@glusternode1:/mnt$ sudo gluster volume info

Volume Name: gv0
Type: Replicate
Volume ID: ab19d123-eb34-4186-8a03-316a3fc790e3
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: glusternode1:/data/xvdb1/brick
Brick2: glusternode2:/data/xvdb1/brick
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
That volume must now be mounted "somewhere" to access it. How do I mount it so Windows clients can access it? Do I simply mount the share in one of the nodes under /mnt/big_ole_gluster_space and then share out that mount point via Samba from that same Gluster node?

The preferred way is to use the GlusterFS FUSE client. Last I knew it's the only one that automatically handles failover and HA.

travisdh1

@biggen said in Gluster and RAID question:

@JaredBusch Once the volume is up and running how the heck does one share it out? That what I'm trying to do. I have a successful two node system running:
joe@glusternode1:/mnt$ sudo gluster volume info

Volume Name: gv0
Type: Replicate
Volume ID: ab19d123-eb34-4186-8a03-316a3fc790e3
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: glusternode1:/data/xvdb1/brick
Brick2: glusternode2:/data/xvdb1/brick
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
That volume must now be mounted "somewhere" to access it. How do I mount it so Windows clients can access it? Do I simply mount the share in one of the nodes under /mnt and then share out that mount point via Samba?

If you want to experiment with it properly, you'll want to follow https://docs.gluster.org/en/latest/Administrator Guide/Accessing Gluster from Windows/

Creating the storage is just the first piece, if you want to share the storage and have it be fault tolerant, then there is a whole lot of other hoops to jump through. Which is also why everyone is saying to just mount it on one of the gluster boxes and create a normal samba share.

biggen

This was the piece of the puzzle I was missing. It explains at the bottom how to configure a simple Samba share.

When one types in "samba gluster" in Google, this unwieldy page is the very first hit. And since its from the official Gluster docs, it makes it seems that is the RIGHT way to do it. That was my confusion when I asked earlier about CTDB.

If one doesn't want to mess with CTDB then sharing out a simple Samba share on one of the Gluster nodes is real easy as I just found out. There is no fault tolerance as far as Samba goes since you are only dealing with a single Samba connection however.

scottalanmiller

@biggen said in Gluster and RAID question:

And since its from the official Gluster docs, it makes it seems that is the RIGHT way to do it.

It's a bit of a conceptual break. Gluster is the wrong place to be looking. That's a filesystem. In no other circumstance, ever, do you look at filesystem documentation (NTFS, XFS, EXT4, etc.) to ask about SMB networking.

So looking at Gluster in this way will be confusing because it doesn't really make any sense. Gluster is a filesystem. Samba is an SMB server. It just reads Gluster the same as any other filesystem if you want.

How do you share out from XFS, ZFS, NTFS, etc.? You do the same way with Gluster. However you answer the first part, is how you will normally answer the second part.

scottalanmiller

@biggen said in Gluster and RAID question:

There is no fault tolerance as far as Samba goes since you are only dealing with a single Samba connection however.

That's because you are "being weird" and acting like Gluster is replacing your hypervisors and virtualization. Since when do we build file servers without virtualizing them? Virtualize Samba and you solve it that way at the platform level. Or make Samba failover the way that Samba normally does.

Basically you are acting like Gluster is a special case, but it is not. Ignore that Gluster is the mechanism that you are using and everything gets really simple. Get fixated and Gluster, and you'll be looking for Gluster-specific answers to all the normal problems.

It's a bit like looking for a guide on how to drive a Ford. But you'll never find one. You'll just find guides to driving cars. The brand of car just doesn't matter, it's all the same. If you are convinced that you need a guide that is specific to steering a Ford, you'll be forever lost and confused thinking that it can't be done when, in reality, it's so simple that no guide exists outside of basic steering guides.