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?
@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?
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?
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 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 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.
@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.
Ok, yeah I don't know why I've been thinking JBOD as RAID 0. Thanks for setting me straight.
How can Distributed Gluster provide any fault tolerance if data isn't replicated across bricks (nodes)?
I guess I've been confusing the concept of JBOD with RAID 0 for the last 20 years then...
Trying to expand my knowledge a bit on clustered file systems. I've never had any experience working with them so I figured spinning up a couple test VMs would be a good starting point.
Anyway, one of the first question that popped into my head is how does RAID fit into the picture with Gluster? I understand that Gluster has three different types of architectures: Distributed (not-redundant), Replicated (redundant), and Distributed Replicated (an amalgamation of the two).
Am I understanding correctly that the Distributed type is similar to JBOD? Wouldn't RAID be necessitated under this type of architecture if one cared about resiliency? I'm trying to understand why one would use Distributed? Would its use case be for utilizing the maximum amount of underlying storage available similar to JBOD? Are Distributed Gluster deployments typically in Production?
Secondly, the Replicated architecture type seems to be quite interesting. Am I correct in assuming that RAID wouldn't be required in this scenario since we are essentially creating copies of the same data on every brick in the pool? To me this sounds essentially like a RAID mirror which seems pretty neat. Can the GlusterFS be built upon LVM? If so, adding storage to each node in order to expand the bricks at a later time would be pretty easy.
Finally, from doing some reading, it appears Gluster isn't known for its speed. Of course a lot of that depends on the network infrastructure its built on but I don't see how it could ever be as fast as local disks. What is the typically use case for something like Gluster? Massive storage requirements?
@Pete-S This is so helpful! Thank you very much.
I’m not sure the difference between a clone and a copy. I’ll look that up.
This seems much easier than having to create a vm from scratch using xo-cli. I guess using the xe commands means I’m running these directly on the host preferable from a Bash script when I get them working how I like?
@Pete-S I may decide to work backwards on this. Learn the Ansible/Salt/Puppet/whatever part first. Get that down and then learn VM provisioning.
Although, cloning a base install sure sounds easier. How do you deal with hostname/MAC address conflicts with the clones?
I’ll check out that book. Thanks for the help!
@Pete-S Thank you sir. Yeah, I've been playing around with xo-cli but documentation is really lacking. I'd imagine there are tons of examples using the built in xe tool I could find.
@scottalanmiller So I found out that xcp-ng does actually have an API for configuration/management of VMs via Xen Orchestra. Its called xo-cli.
What would be your preferred method of wanting to automate VM configuration Scott whilst utilizing the XO API? I mean, do I simply just put the commands into a Bash script?
It looks like the Terraform plugin for xcp-ng is experimental is not well/at all supported so that might be a bust unfortunately.
I'll do some more looking around.
@scottalanmiller Excellent! Thanks Scott!
It may be more than I really need to mess with since I don't really create many new VMs but I wanted to take some time to learn it at any rate. But I keep hearing all these "buzz words" like cloud-init, Salt, Packer, Anisble, etc... and I fell like I'm being left behind with not learning these new tools.
@scottalanmiller said in Getting started with automated provisioning?:
@biggen said in Getting started with automated provisioning?:
Just trying to wrap my head around the first steps, I understand how to install a Salt Master/Minion. I don’t understand how to get a VM provisioned BEFORE that portion in a somewhat automated fashion.
That's the trick, you don't. You just need to have the thing that holds the VMs also be managed from Salt / Ansible or whatever. In this case, the Xen host.
Ahh ok. That makes sense. So does the Xen host need some type of API running under the hood? Does something like this exist for xcp-ng?
I’d like to get started learning some automated processes when it comes to spinning up a VM. I have a single host xcp-ng environment. Right now, I create VMs the hard way: Sit through the entire OS install menu (usually use Debian) clicking away.
I only have a very high level abstract understanding of Salt/Ansible. I understand that you can create playbooks to have the target system install/configure services you define in the playbook. However, how do you actually create the VM first?
What would be the first steps I need to learn to actually provision the VM? I mean, I guess I could simply clone the base/virgin OS VM after an initial install. But I’d have to change hostnames, ips, etc... for the new VM I cloned.
Just trying to wrap my head around the first steps, I understand how to install a Salt Master/Minion. I don’t understand how to get a VM provisioned BEFORE that portion in a somewhat automated fashion.
There are so many variables but I really like KVM and xcp-ng. Both are rock stable and both have paid support (e.g. RHEL) if needed.
I lean more toward xcp-ng since it’s a bit less “dev ops” than KVM.