Gluster and RAID question
-
@scottalanmiller said in Gluster and RAID question:
@biggen said in Gluster and RAID question:
How can Distributed Gluster provide any fault tolerance if data isn't replicated across bricks (nodes)?
Why would there be something not replicated across the bricks?
RAID can't provide fault tolerance when data isn't written. RAIN can't either. That's why everything gets replicated.
https://docs.gluster.org/en/latest/Quick-Start-Guide/Architecture/
Distributed doesn't appear to replicate across bricks. It "distributes" files across bricks variously.
-
@biggen said in Gluster and RAID question:
@scottalanmiller said in Gluster and RAID question:
@biggen said in Gluster and RAID question:
How can Distributed Gluster provide any fault tolerance if data isn't replicated across bricks (nodes)?
Why would there be something not replicated across the bricks?
RAID can't provide fault tolerance when data isn't written. RAIN can't either. That's why everything gets replicated.
https://docs.gluster.org/en/latest/Quick-Start-Guide/Architecture/
Distributed doesn't appear to replicate across bricks. It "distributes" files across bricks variously.
Oh sorry, you mean the Gluster term distributed. There is no redundancy. Same as RAID 0.
Just like with RAID, RAIN has features like redundancy as an option, but not a requirement. There is nothing about any technology like this that automatically implies any safety.
-
@biggen said in Gluster and RAID question:
How can Distributed Gluster provide any fault tolerance if data isn't replicated across bricks (nodes)?
The simple answer is, it doesn't. The link that you said has this in bold: "Hence there is no data redundancy."
-
@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.
-
@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.
-
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.
-
@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.
-
@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.
-
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.
-
@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.
-
@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.
-
@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.
-
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?
-
@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?
-
@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.
-
@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?
-
@scottalanmiller it sounds like explaining the whole stack might be in order, and where Gluster/etc fall in that stack.
-
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?
-
@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.
-
@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: offThat 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_spaceand then share out that mount point via Samba from that same Gluster node?
