Xenserver and Storage
-
@scottalanmiller said in Xenserver and Storage:
@jrc said in Xenserver and Storage:
VSAN would be a management VSA ...
So what happens if it's just the dedicated link that dies? Will all my VMs be running on both hosts on my network (causing a ton of issues)? And how does this setup cope with the data getting out sync if a host fails?
I hate all these terms. LOL. VSAN is just a normal SAN, but virtualized. You can just use SAN and that, hopefully, answers all questions alone.
It does not, and yes I hate these acronyms as well.
How do SANs normally cope with losing connectivity to each other?
I've no clue as I have only ever worked with the one I have, an it is a single unit multipathed to my 2 hosts. So are you saying that real SANs also sync data between themselves?? So the 2 VMs (what I called VSAs) are like 2 physical SANs?
Look I get that VSAN = SAN in all functionality once setup. It's the setup, and the possible ramifications of said setup that I am unclear on.
I am trying to work out the best path from my current, fragile setup, to one that is more reliable and fault tolerant.
-
@jrc said in Xenserver and Storage:
I've no clue as I have only ever worked with the one I have, an it is a single unit multipathed to my 2 hosts. So are you saying that real SANs also sync data between themselves??
Of course, if you want high availability. That's the only path to HA. Any storage device that you want protection against system failure needs a synced unit that you can fail over to. That's why we say SANs generally only make sense when you have zero or two. A single unit is a single point of failure and most SANs aren't as reliable as normal servers, so generally a really fragile single point of failure.
So if you don't care about HA, you don't need two SANs or two VSANs. They are literally the same things. If you do want HA, you need at least two of either. VSAN can have the benefit of being RLS, which a hardware SAN cannot, so VSAN has the possibility of being way safer, even if you have only one. Fewer points of failure.
-
@jrc said in Xenserver and Storage:
So the 2 VMs (what I called VSAs) are like 2 physical SANs?
Yes, a SAN or a NAS is just a storage server, nothing else. There is no magic. And a virtualized server is exactly like a physical server, but with better design and abstraction. Nothing changes in reality.
-
@jrc said in Xenserver and Storage:
I am trying to work out the best path from my current, fragile setup, to one that is more reliable and fault tolerant.
For reliable storage in any small to moderate sized setup (that is, under ~20 physical servers in a single cluster) the only good answer is RLS. RLS is the big "magic" answer. How you get to RLS isn't critical. You can do VSAN, native RLS (like DRBD), VSA (virtualized NAS), or whatever. Systems like Scale HC3 or RHEV or HA-Lizard use native RLS via RAIN or Network RAID. Starwind does native on Hyper-V or VSAN on non-Hyper-V. VMware does VSAN. HPE does VSA. All of them work. Don't get caught up in "how" each does what they do, that's not very important. What matters is the RLS.
http://www.smbitjournal.com/2013/07/replicated-local-storage/
-
@scottalanmiller said in Xenserver and Storage:
@jrc said in Xenserver and Storage:
I am trying to work out the best path from my current, fragile setup, to one that is more reliable and fault tolerant.
For reliable storage in any small to moderate sized setup (that is, under ~20 physical servers in a single cluster) the only good answer is RLS. RLS is the big "magic" answer. How you get to RLS isn't critical. You can do VSAN, native RLS (like DRBD), VSA (virtualized NAS), or whatever. Systems like Scale HC3 or RHEV or HA-Lizard use native RLS via RAIN or Network RAID. Starwind does native on Hyper-V or VSAN on non-Hyper-V. VMware does VSAN. HPE does VSA. All of them work. Don't get caught up in "how" each does what they do, that's not very important. What matters is the RLS.
Your response is like saying "Don't worry about the how to drive, what matters is that the car works and is safe to drive" Perfectly true, but completely useless if you have no idea how to drive and need to get from A to B.
So I get what you are saying, that RLS is what I need, I already knew this (maybe without the acronym), and I am on board with this. The whole point of this post was to try and work out how to get to an RLS setup, and which option would work best for our needs. I am solid on the concept of having replicated data on both hosts, makes perfect sense.
To extend my analogy of the car, I am perfectly aware of why I need a working safe car in order to get from A to B, so I don't need any more info on why it is needed. I now need info on how to drive the damn thing.
The technologies you list all have their pros and cons, so knowing what these are is what I really need to know. How do they handle a node failure? Out of sync data etc? How easy are they to implement? How much do they roughly cost?
-
@jrc said in Xenserver and Storage:
Your response is like saying "Don't worry about the how to drive, what matters is that the car works and is safe to drive" Perfectly true, but completely useless if you have no idea how to drive and need to get from A to B.
Not really. It's more like asking when you should drive in the left hand lane, and what I'm telling you is that you should just stay in the right hand lane and not worry about what the left hand lane is for.
RLS is the key to the architectural improvements. Picking the right product for your RLS is important, but how that product does it is of zero concern to you. That's under the hood. It might be interesting, but it doesn't matter. Kind of like worrying about how many inches of displacement your engine has. That never matters, ever. It's interesting, but what actually matters is reliability, efficiency, power, etc. You are getting stuck looking at how the engineers at these vendors are doing their under the hood designs. Certainly interesting, but doesn't affect you here.
-
@jrc said in Xenserver and Storage:
The technologies you list all have their pros and cons, so knowing what these are is what I really need to know. How do they handle a node failure? Out of sync data etc? How easy are they to implement? How much do they roughly cost?
That's kind of the point. VSAN vs. Native vs. VSA and RAID vs. RAIN do have pros and cons, but they are trivial and under the hood. They are background noise, a distraction. What matters to you (or to anyone) is actual, real world implementations and what is available, not how it works. For example, Starwind uses VSAN and Network RAID, but if they use VSA and RAIN, you'd not care at all. All you care about is the resulting performance, scale, reliability and cost. Does that make more sense?
So for you, it all comes down to actual products and how they meet your needs, not how they are doing that job.
-
I hate to say it, because I love Xen, but it might really be worth leaving Xen behind. The solutions for it are few and far between and often rather complicated. KVM or Hyper-V have what you want, for free, from Starwind done in a really good way for what you need. And if you need or want support, you have that option from them. And they are active here, as well. So loads of choices.
-
Going with Xen, you are far more limited to just a few options. With raw Xen, you have more options. With XenServer, they specifically remove or disallow certain common solutions like DRBD.
-
DRBD is working with XS via HA Lizard, XOSAN coming in stable soon, people also working on Ceph (don't know the progress on this one, won't be hyperconvergence however).
I'm not sure there is a ton of solution for a 2 node setup anyway. Even in VMWare (you need a "witness appliance" which is basically the arbiter node of Gluster).
Maybe I missed something?
-
@olivier said in Xenserver and Storage:
DRBD is working with XS via HA Lizard, XOSAN coming in stable soon, people also working on Ceph (don't know the progress on this one, won't be hyperconvergence however).
So one that has been known to not be very good and two that aren't out yet. Seems like that kind of answers that. Xen has a future, but not a present. Nothing wrong with that. But he needs to deploy today.
-
@olivier said in Xenserver and Storage:
I'm not sure there is a ton of solution for a 2 node setup anyway. Even in VMWare (you need a "witness appliance" which is basically the arbiter node of Gluster).
No one is considering VMWare, but no one needs three nodes. VMware, Hyper-V and KVM all have Starwind and other options, at two nodes.
-
XOSAN is just weeks from release
How Starwind deals with split brain in 2 nodes scenario? Why it would be better than VSAN? (which is somehow a leader in the VMWare market itself IIRC)
edit: those are true questions, not rhetorical. I'm curious about how to deal with some cases in 2 nodes.
-
@olivier said in Xenserver and Storage:
How Starwind deals with split brain in 2 nodes scenario? Why it would be better than VSAN? (which is somehow a leader in the VMWare market itself IIRC)
I wouldn't use the term VSAN as that is a generic word (like SAN) and both Starwind's and VMware's solutions are called VSAN
So which is better, VSAN or VSAN?Starwind has done a lot of work to deal with split brain management with two nodes, VMware has not. Starwind is in the business of making things cost effective and focusing on small shops. VMware is in the business of selling sprawl and focusing on large customers. VMware's smallest purchase increment is three nodes. So they have totally different intended user bases and purposes. VMware deals with split brain the easy way, but having a witness node at all times. This can just be on a desktop, though, it need not be anything hard core. Starwind simply has a lot more intelligence under the hood to arbitrate a scenario where both nodes are alive but severed.
Starwind has the pretty massive advantage of being free, running on free products, and bring vendor agnostic. VMware VSAN is not free, requires more nodes, runs only on expensive products, and is vendor locked in.
-
I would be curious to understand how it's possible to deal with a replication link failure in 2 nodes scenario. I don't see a lot of options:
- you stop writes to avoid split brain
- you write data in both nodes but if you have one LUN for mutliple VMs, you are doomed to discard one node data
Do you have more details or documentation on how it works?
-
Best to have @KOOLER explain the mechanism, I don't want to get that part wrong.
-
And in short, because Starwind doesn't support XenServer, you think it's better to discard XenServer
Why not, maybe in 2 nodes scenario it's an acceptable point of view ^^ -
@olivier said in Xenserver and Storage:
And in short, because Starwind doesn't support XenServer, you think it's better to discard XenServer
Why not, maybe in 2 nodes scenario it's an acceptable point of view ^^What's the other option? HA-Lizard is only available for two nodes. Nothing else is on the market. Starwind, like everyone else, is expected to have something out for Xen in the future, but no one seems to have solutions today. DRBD does work, but isn't ideal and XenServer specifically disavows it. Leaving a weird situation where we can come up with solutions, but we lack elegance or support. When switching out Xen seems to be the obvious solution making all of this moot.
-
HP VSA might have been available on Xen, but they've pulled it.
-
@scottalanmiller said in Xenserver and Storage:
@olivier said in Xenserver and Storage:
And in short, because Starwind doesn't support XenServer, you think it's better to discard XenServer
Why not, maybe in 2 nodes scenario it's an acceptable point of view ^^What's the other option? HA-Lizard is only available for two nodes. Nothing else is on the market. Starwind, like everyone else, is expected to have something out for Xen in the future, but no one seems to have solutions today. DRBD does work, but isn't ideal and XenServer specifically disavows it. Leaving a weird situation where we can come up with solutions, but we lack elegance or support. When switching out Xen seems to be the obvious solution making all of this moot.
2 node isn't the objective? So why discard that option?
