Someone doesn't like local storage for large amounts of data
-
@Dashrender said in Someone doesn't like local storage for large amounts of data:
What do you propose to do for backup of that NAS, or whatever remote storage you use?
Rsynced, clustered storage, agent based, anything you would normally do.
-
@olivier said in Someone doesn't like local storage for large amounts of data:
@Dashrender Naah. Just a physical NAS/SAN, exposed in SMB/NFS. Let's name it the filer.
This filer is mounted in any VMs you like, that's it. You can even having a VM to rsync those files to another filer for you backup, just simple as that.
A filer will have sense for large collection of files (like a company shared folder).
The alternative would be to have a cluster FS on every XenServer to act as a local SR "shared" on all hosts. That would be doable with SMAPIv3, but for now, it's overcomplicated and not really secure/consistent/powerful.
edit: I don't know if I'm a clear. I don't speak about SR in XenServer terms. That's another thing. I only speaking about a dedicated network share for files. Period
But if you put the filer in a VM, are you proposing not backing it up? and instead using rysnc as the backup solution?
This whole discussion came about because of the poor performance of backups in XS.
-
@stacksofplates said in Someone doesn't like local storage for large amounts of data:
@Dashrender said in Someone doesn't like local storage for large amounts of data:
What do you propose to do for backup of that NAS, or whatever remote storage you use?
Rsynced, clustered storage, agent based, anything you would normally do.
Is rsync or clustered storage a backup?
of course agent based backups would be a backup - assuming backup, yada yada..
-
@Dashrender as I said, your poor backup perfs are not the perfs for everyone. Your case is not global, don't forget that
Why I would put the filer in the VM? I would avoid it ^^
-
My point is to split different those problems into 2 different things: compute and storage. They are not the same thing and in general, and it's not a bad idea to split those stuff.
-
@olivier said in Someone doesn't like local storage for large amounts of data:
@Dashrender as I said, your poor backup perfs are not the perfs for everyone. Your case is not global, don't forget that
You did mention that - I wonder how those not having perf problems solved their problems?
-
@olivier said in Someone doesn't like local storage for large amounts of data:
My point is to split different those problems into 2 different things: compute and storage. They are not the same thing and in general, and it's not a bad idea to split those stuff.
Hmm... this flies in the face of hundreds if not thousands of posts on this forum.
-
@Dashrender said in Someone doesn't like local storage for large amounts of data:
Hmm... this flies in the face of hundreds if not thousands of posts on this forum.
That's my opinion, I don't care if it's shared or not. That's what I can see on the field. I won't create VMs with disks of hundreds of GBs. Or without knowing the pain it will cause if there is any operation to do on this VM (migration, backup, restore, whatever)
-
To recap:
- For XenServer SR (aka VM disks): local storage or remote storage, doesn't really matters, because we always have the ability to migrate the VDIs when needed
- Having large VDIs will reduce this flexibility. So it's better to use small VDIs and use NAS/SAN for mounting large space filled with a lot or big files.
-
@Dashrender said in Someone doesn't like local storage for large amounts of data:
As those who have been around ML for a while know, the general consensus around here is to use local storage for your VM workloads when possible.
He still is. He didn't move from using local, nor from VMs on local. He's talking about file servers he recommends a NAS instead of a file server.
-
@olivier said in Someone doesn't like local storage for large amounts of data:
- Having large VDIs will reduce this flexibility. So it's better to use small VDIs and use NAS/SAN for mounting large space filled with a lot or big files.
That doesn't really make sense because NAS or SAN have all the same (or more) limitations in failing over large workloads as local storage does. It just introduces more overhead and risk having the extra equipment.
-
Yes, whatever how you name it, but a physical appliance/machine which will serve a large bunch of files.
-
@olivier said in Someone doesn't like local storage for large amounts of data:
@Dashrender said in Someone doesn't like local storage for large amounts of data:
Hmm... this flies in the face of hundreds if not thousands of posts on this forum.
That's my opinion, I don't care if it's shared or not. That's what I can see on the field. I won't create VMs with disks of hundreds of GBs. Or without knowing the pain it will cause if there is any operation to do on this VM (migration, backup, restore, whatever)
So this is all worded strangely because of the OP. Basically you are advocating physical storage devices instead of virtual, nothing more than that.
Problem is... all of those migration, backup, restore, etc. operations don't improve by going physical. They just don't get as many advantages going virtual. That large file servers aren't the best virtualization targets is accepted. That they don't still benefit from being virtual, though, is what is disputed. You've listed why virtual not better by as large of a margin as normal, but is any downside in play? Or simply not as overwhelmingly any upsides?
-
@scottalanmiller I don't agree and that's not my point either. If a filer is overcrowded, that's not a virt vs physical issue, that's a capacity planning issue.
Here, I'm talking about general architecture, not implementation details.
-
@olivier said in Someone doesn't like local storage for large amounts of data:
Yes, whatever how you name it, but a physical appliance/machine which will serve a large bunch of files.
But why not virtualize that one machine to get the benefits of virtualization? What's the advantage to giving up the extra benefits?
-
@olivier said in Someone doesn't like local storage for large amounts of data:
@scottalanmiller I don't agree and that's not my point either. If a filer is overcrowded, that's not a virt vs physical issue, that's a capacity planning issue.
Here, I'm talking about general architecture, not implementation details.
It's physics. NAS and SAN are just local storage themselves. They have no magic. Anything they can do to aid failover, local storage can do without the extra overhead.
-
@scottalanmiller What's the point of a virtual filer if you can't easily move it. Very large VDIs defeats the flexibility of virtualization.
-
@scottalanmiller I think there is a misunderstanding somewhere, I don't get your point. I'm not talking about performances limits at all.
-
@olivier said in Someone doesn't like local storage for large amounts of data:
@scottalanmiller What's the point of a virtual filer if you can't easily move it. Very large VDIs defeats the flexibility of virtualization.
Not at all, because those are "icing" benefits, not the cake benefits. Being able to move things isn't the core value in virtualization. And even if so, you are just saying why it isn't overwhelmingly better, but not saying why physical is better. If advocating physical, what is the actual benefit?
http://www.smbitjournal.com/2012/11/virtualization-as-a-standard-pattern/
http://www.smbitjournal.com/2015/04/virtualizing-even-a-single-server/
-
Okay, let's imagine your NAS is on a larger VMs talking all space of your local storage of your XenServer/ESXi/whatever host. And exposing mounts to all other VMs on other hosts. That's doable but that's not my point. For me, this setup is almost the same of having a physical NAS/SAN.
My point is: for ALL your VMs, it's better to have smaller VDIs everywhere and mount a filer elsewhere if needed.
